Proces inżynierii wymagań

Prezentacja na temat: "Proces inżynierii wymagań"— Zapis prezentacji:

1 Proces inżynierii wymagań
Służy do określania, analizowania i zatwierdzania wymagań stawianych systemowi.

2 Cele Rozumieć podstawowe czynności inżynierii wymagań i związki między nimi. Znać kilka metod określania i analizowania wymagań. Rozumieć znaczenie zatwierdzania wymagań oraz to, jak w tym procesie używa się przeglądów wymagań. Rozumieć, dlaczego zarządzanie wymaganiami jest niezbędne oraz to, jak wspomaga ono inne czynności inżynierii wymagań.

3

4 Zawartość Studium wykonalności Określanie i analizowanie wymagań
Zatwierdzanie wymagań Zarządzanie wymaganiami

5 Proces inżynierii wymagań
Obejmuje wszystkie czynności niezbędne do opracowania i aktualizacji dokumentacji wymagań systemowych. Istnieją cztery ogólne czynności wysokiego poziomu w procesie inżynierii wymagań: studium wykonalności określenie i analizowanie wymagań specyfikowanie i dokumentowanie wymagań zatwierdzanie wymagań

6 Proces inżynierii wymagań c.d.
Studium wykonalności Określanie i analizowanie wymagań Specyfikowanie wymagań Zatwierdzanie wymagań Raport o wykonalności Model systemu Wymagania użytkownika i wymagania systemowe Dokumentacja wymagań

7 Studium wykonalności Wynikiem tego studium powinien być raport, który zaleca albo nie zaleca kontynuacji procesu inżynierii wymagań i tworzenia systemu. Studium wykonalności to krótkie, skumulowane opracowanie, w którym staramy się odpowiedzieć na kilka pytań: Czy system przyczyni się do realizacji ogólnych celów przedsiębiorstwa? Czy system może być zaimplementowany z użyciem dostępnych technologii, w ramach ustalonego budżetu i ograniczeń czasowych? Czy system może być zintegrowany z istniejącymi systemami, które już zainstalowano?

8 Przeprowadzanie studium wykonalności
Obejmuje określenie i zebranie informacji oraz pisanie raportu Kilka przykładów pytań: Jak firma poradziłaby sobie, jeśli system nie byłby zaimplementowany? Jakie problemy występują w obecnie przyjętych procesach i jak nowy system ma pomóc w ich eliminacji? Jaki byłby bezpośredni wkład systemu w osiąganie celów gospodarczych? Czy można przekazywać informacje do i z innych systemów przedsiębiorstwa? Czy system wymaga technologii, których wcześniej w firmie nie stosowano? Co system musi wspomagać, a czego nie musi?

9 Określanie i analizowanie wymagań
Po wstępnych studiach wykonalności następna fazą inżynierii wymagań jest określanie i analizowanie wymagań. W trakcie tej czynności techniczni budowniczowie oprogramowania pracują z klientem i użytkownikami systemu nad badaniem dziedziny zastosowania i usług, które system ma oferować, pożądanej efektywności, ograniczeniach sprzętowych itd. W określaniu i analizowaniu wymagań mogą wziąć udział osoby z różnych stanowisk w firmie. Pojęcie uczestnik odnosi się do każdego, kto powinien mieć pewien pośredni lub bezpośredni wpływ na wymagania systemowe.

10 Problemy analizy wymagań
Uczestnicy często nie wiedzą, czego tak naprawdę oczekują od systemu komputerowego. Uczestnicy systemu w naturalny sposób wyrażają wymagania za pomocą własnych pojęć. Różni uczestnicy mogą stawiać różne wymagania. Czynniki polityczne mogą mieć wpływ na system Środowisko ekonomiczne i gospodarcze, w którym prowadzi się analizę, jest dynamiczne. Nieuchronnie zmienia się w trakcie procesu analizy.

11 Proces określania i analizowania wymagań
Specyfikacja wymagań Sprawdzenie wymagań Nadawanie priorytetów Rozpoznanie dziedziny Początek procesu Dokumentacja wymagań Usuwanie sprzeczności Zbieranie wymagań Klasyfikacja

12 Czynności procesu Rozpoznanie dziedziny Zbieranie wymagań Klasyfikacja
Usuwanie sprzeczności Nadawanie priorytetów Sprawdzanie wymagań

13 Modelowanie systemu Określanie i analizowanie wymagań jest procesem iteracyjnym z ustawicznym przekazywaniem informacji zwrotnej między czynnościami. Cykl procesu rozpoczyna się od rozpoznania dziedziny, a kończy na sprawdzeniu wymagań. Stopień zrozumienia dziedziny przez analityków rośnie z każdym cyklem.

14 Określanie oparte na punktach widzenia
Średnie i wielkie systemy maja zwykle kilku różnych użytkowników. Wielu uczestników w jakiś sposób interesuje się wymaganiami systemowymi.

15 System bankomatowy - przykład
Służy do automatycznego dokonywania operacji bankomatowych. W uproszczonej wersji służy wielu zwykłym klientom i oferuje bardziej skomplikowane usługi wybranym klientom. Usługi obejmują: wypłatę, wpłatę, przekazywanie informacji.

16 Uczestnicy systemu bankomatowego
Obecni klienci banku Przedstawiciele innych banków Dyrektorzy oddziałów banków Pracownicy obsługi klienta w oddziałach Administratorzy baz danych Osoby odpowiedzialne za bezpieczeństwo w banku Dział marketingu banku Inżynierowie pielęgnacji sprzętu i oprogramowania

17 Różne punkty widzenia Źródło lub przeznaczenie danych
Osoba mająca taki punkt widzenia użytkuje lub produkuje dane. W tym wypadku analiza polega na rozpoznawaniu wszystkich takich punktów widzenia, danych, które są produkowane lub użytkowane, oraz przeprowadzanym przetwarzaniu. Zrąb reprezentacji Osoba mająca taki punkt widzenia jest związana z konkretnym typem modelu systemu. Odbiorca usług W tym wypadku punkty widzenia są zewnętrzne wobec systemu; osoby mające ten punkt widzenia korzystają z usług systemu.

18 Model zewnętrznych punktów widzenia
Reprezentanci tych punktów widzenia współpracują z systemem przez otrzymywanie usług od systemu oraz przekazywanie do systemu danych i sygnałów sterujących. Punkty widzenia są zewnętrzne wobec systemu, stanowią zatem naturalny sposób strukturalizacji procesu określania wymagań. Dość łatwo jest stwierdzić, czy coś jest punktem widzenia, czy nie. Reprezentanci punktów widzenia muszą bowiem w pewien sposób oddziaływać na system. Punkty widzenia i usługi stanowią dobry sposób strukturalizacji wymagań niefunkcjonalnych. Każda usługa może być powiązana z wymaganiami niefunkcjonalnymi.

19 Method-based analysis
Widely used approach to requirements analysis. Depends on the application of a structured method to understand the system. Methods have different emphases. Some are designed for requirements elicitation, others are close to design methods A viewpoint-oriented method (VORD) is used as an example here. It also illustrates the use of viewpoints

20 Etapy metody VORD Identyfikacja punktów widzenia Strukturalizacja
Dokumentacja punktów widzenia Przyporządkowywanie punktów widzenia do systemu

21 Etapy metody VORD c.d. Identyfikacja punktów widzenia
Znajdowanie punktów widzenia, których reprezentanci korzystają z usług systemu, oraz na wyszukiwaniu szczególnych usług oferowanych reprezentantom konkretnych punktów widzenia. Strukturalizacja punktów widzenia Polega na grupowaniu podobnych punktów widzenia w hierarchie. Dokumentacja punktów widzenia Udoskonalanie opisu znalezionych punktów widzenia i usług. Przyporządkowywanie punktów widzenia do systemu Znajdowanie obiektów w projekcie obiektowym za pomocą związanej z punktami widzenia informacji o usługach.

22 Szablony formularzy i punktów widzenia
Szablon do usług Odnośnik: Nazwa usługi Uzasadnienie: Przyczyna oferowania usługi Specyfikacja: Odnośnik do listy specyfikacji usług, które mogą być opisane za pomocą różnych notacji Punkty Lista nazw punktów widzenia, widzenia: których reprezentanci korzy- stają z usługi Wymagania Odnośnik do zbioru wymagań niefunkcjo- niefunkcjonalnych ogranicza- nalne: jących usługę Dostawca: Odnośnik do listy obiektów systemu, które oferują tę usługę Szablon do punktów widzenia Odnośnik: Nazwa punktu widzenia Atrybuty: Atrybuty z informacją o punkcie widzenia Zdarzenia: Odnośnik do zbioru scenariu- szy zdarzeń opisujących, jak system reaguje na zdarzenia w ramach tego punktu widzenia Usługi: Odnośnik do zbioru opisów usługi Podrzędne Nazwy podrzędnych PW: punktów widzenia

23 Burza mózgów w trakcie identyfikacji punktów widzenia
Dziennik transakcji Baza danych klientów Wypłata gotówki Odczyt transakcji Pytanie o saldo Zwrot karty Zamówienie czeków Zdalna aktualizacja oprogramowania Menedżer Zasoby maszyny Informacje o koncie Dziennik komunikatów Kasa banku Rozmiar oprogramowania Interfejs użytkownika Obcy klient Nieuprawniony użytkownik Drukarka Koszt systemu Pielęgnacja oprogramowania Zabezpieczenia Właściciel konta Zamówienie wyciągu Karta skradziona Zatrzymanie karty Przelew środków Przekazywanie komunikatów Zdalna diagnostyka Aktualizacja konta Niezawodność Weryfikacja karty

24 Informacja o usługach przypisanych do punktów widzenia
KASA BANKU WŁAŚCICIEL KONTA OBCY KLIENT Lista usług Lista usług Lista usług Wypłata gotówki Pytania o saldo Zamówienie czeków Wysyłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków Wypłata gotówki Pytania o saldo Diagnostyka Dodanie gotówki Dodanie papieru Wysłanie komunikatu

25 Dane wejściowe i dane sterujące związane z punktami widzenia
WŁAŚCICIEL KONTA Dane sterujące Dane wejściowe Rozpocznij transakcje Informacje z karty Anuluj transakcje PIN Zakończ transakcje Żądana kwota Wybór usługi Komunikat

26 Hierarchia punktów widzenia
Wszystkie PW Usługi Klient Personel banku Pytanie o saldo Wypłata gotówki Kasa Menedżer Inżynier Usługi Zamówienie czeków Wysyłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków Właściciel konta Klient obcy

27 Opis punktu widzenia klienta i opis usługi wypłaty gotówki
Odnośnik: Klient Atrybuty: Numer konta PIN Zdarzenia: Zacznij transakcję Wybór usługi Anuluj transakcję Zakończ transakcję Usługi: Wypłata gotówki Pytanie o saldo Podrzędne PW: Właściciel konta Odnośnik: Wypłata gotówki Uzasadnienie: Celem jest ulepszenie obsługi klienta i zmniejszenie liczby dokumentów papierkowych Specyfikacja: Użytkownicy wybierają tę usługę przez naciśnięcie przycisku „wypłata gotówki”. Następnie wprowadzają żądaną kwotę. Potwierdza się ją i jeśli na koncie są odpowiednie środki następuje wypłata PW: Klient Wymagania niefunkcjonalne: Wypłacić gotówkę najpóźniej po 1 minucie od potwierdzenia kwoty Dostawca: Wypełnić później

28 Scenariusze Ludzie zwykle wolą przykłady wzięte z życia niż abstrakcyjne opisy Inżynierowie wymagań mogą skorzystać z informacji zebranych w trakcie dyskusji do formułowania rzeczywistych wymagań systemowych. Scenariusze są szczególnie użyteczne przy uszczegóławianiu przeglądowego opisu wymagań. Są opisami przykładowych sesji interakcyjnych. Każdy scenariusz obejmuje jedną lub najwyżej kilka możliwych interakcji.

29 Cechy scenariusza Opis stanu systemu na początku scenariusza.
Opis normalnego następstwa zdarzeń scenariusza. Opis tego, co może pójść źle, i jak to jest obsługiwane. Informacje o innych czynnościach, które można wykonywać w tym samym czasie. Opis stanu systemu po zakończeniu scenariusza.

30 Scenariusze zdarzeń Scenariusze zdarzeń są używane w VORD do dokumentowania zachowania systemu, gdy zajdą konkretne zdarzenia. Każde odrębne zdarzenie w interakcji, takie jak wsunięcie karty do bankomatu albo wybranie usługi, może być udokumentowane za pomocą oddzielnego scenariusza zdarzenia. Obejmują opis przepływu danych, akcji systemu i wyjątków, które mogą się pojawić. Aby zapoznać się z przykładem scenariusza zdarzenia rozważmy schemat, na którym przedstawiono scenariusz zdarzenia „Zacznij transakcję”.

31 Konsekwencje dotyczące diagramów scenariuszy zdarzeń
Dane odbierane i przekazywane do reprezentantów punktów widzenia są przedstawione w postaci elips. Informacja sterująca wchodzi w każdy prostokąt od góry, a opuszcza z dołu.. Dane opuszczają prostokąty z prawej strony. Jeśli te dane nie są otoczone elipsą, oznacza to, że są wewnętrzne dla systemu. Wyjątki są pokazywane na dole prostokątów. Jeśli tych wyjątków jest kilka, to oznacza się je prostokątem. Nazwa następnego zdarzenia oczekiwanego po zakończeniu scenariusza jest przedstawiana w cieniowanym prostokącie.

32 Opis wyjątków Część metody nie zawiera opisu wyjątków
W tym przykładzie: Przekroczenie limitu czasu. Klient może nie wprowadzić PIN przed upływem wyznaczonego czasu. Karta jest zwracana. Karta nieważna. Nie rozpoznano karty. Karta jest zwracana. Karta ukradziona. Rozpoznano kartę jako skradzioną. Karta jest zatrzymywana.

33 Przypadki użycia Przypadek użycia jest metodą opartą na scenariuszach, służącą do określania wymagań. Po raz pierwszy użyto jej w metodzie Objectory (Jacobson i inni, 1993). Obecnie stała się podstawowym elementem notacji UML do opisywania obiektowych modeli systemu. W najprostszej postaci w przypadku użycia definiuje się aktorów biorących udział w interakcji i wskazuje typ tej interakcji.

34 Przypadek użycia Wypożyczanie
Obsługa wypożyczania

35 Przypadki użycia biblioteki
Obsługa wypożyczania Czytelnik Zarządzanie użytkownikami Personel biblioteki Obsługa katalogu Dostawa c

36 Diagramy przebiegu Zdefiniowane w UML diagramy przebiegu mogą służyć do dodawania szczegółowej informacji do przypadku użycia. Na takich diagramach przedstawia się aktorów biorących udział w interakcji, obiektyw systemie, z którymi komunikują się aktorzy, oraz operacje powiązane z tymi obiektami. Rysunek zawiera przykład takiego diagramu- interakcję obejmującą nabywanie i katalogowanie książek w bibliotece.

37 Diagram przebiegu zarządzania katalogiem
Składnik: Składnik biblioteki Książki: Katalog Sprzedawca książek Katalogujący: Personel biblioteki : Nowy Nabądź Kataloguj składnik Usuń Usuń składnik z katalogu

38 Przykłady Na rysunku pokazano dwa obiekty klas Składnik biblioteki i Katalog, które biorą udział w przypadku użycia Zarządzanie katalogiem. Akcje są wykonywane w kolejności z góry na dół, a etykietki na strzałkach między aktorami i obiektami są nazwami operacji. Po zakupie książki, wykonuje się zatem operację Nowy na katalogu Nabądź i na Składniku. Gdy książka jest już dostępna, na Składniku wykonuje się operację Kataloguj składnik.

39 Etnografia To metoda obserwacji, która może służyć do rozpoznawania wymagań społecznych i organizacyjnych. Analityk pogrąża się w środowisku pracy, w którym system będzie używany. Obserwuje codzienną pracę i odnotowuje podstawowe zadania wykonywane przez pracowników. Zaleta etnografii jest to, że pomaga odkrywać niejawne wymagania systemowe odzwierciedlające rzeczywiste, a nie formalne procesy, w których biorą udział ludzie.

40 Skoncentrowana etnografia
Rozwinięta w projekcie badającym proces kontroli lotów. Łączy etnografię z prototypowaniem. Prototypowanie pomaga w pokierowaniu etnografią przez identyfikowanie problemów i pytań, które potem mogą być rozważone przez etnografa. Wadą etnografii jest to, że bada ona istniejące zachowania, które mogą mieć jakieś historyczne podłoże, które nie jest już odpowiednie.

41 Etnografia i prototypowanie
Analiza etnograficzna Narady Szczegółowa etnografia Ocena prototypu Prototypowanie systemu Ogólne tworzenie systemu

42 Cele etnografii Opis wymagań wynikających z rzeczywistego sposobu pracy osób, a nie ze sposobu zalecanego formalne definicje procesów. Opis wymagań, które wynikają z kooperacji i świadomości czynności innych osób.

43 Zatwierdzanie wymagań
Zatwierdzanie wymagań polega na wykazaniu, że wymagania naprawdę definiują system, którego chce użytkownik. Ponieważ błędy w dokumentacji wymagań mogą przyczynić się do poważnych kosztów powtarzania prac po sukcesywnym wykrywaniu tych błędów w trakcie tworzenia lub nawet po rozpoczęciu korzystania z systemu.

44 Sprawdzenie wymagań Sprawdzenie ważności. Użytkownik może być przekonany, że system powinien spełniać pewne funkcje. Sprawdzenie niesprzeczności. Wymagania zapisane w dokumentacji nie powinny być sprzeczne. Sprawdzenie kompletności. Dokumentacja wymagań powinna zawierać wymagania, w których zdefiniowano wszystkie funkcje i ograniczenia zamierzone przez użytkownika systemu. Sprawdzenie realności. Znając obecną wiedze techniczną, należy sprawdzić, czy wymagania mogą być naprawę zaimplementowane. Możliwość weryfikacji. Aby uniknąć późniejszych sporów między klientem a zleceniobiorcą, wymagania systemowe zawsze powinny być napisane tak, aby można było je weryfikować.

45 Modele zatwierdzania wymagań
Przeglądy wymagań Zespół recenzentów systematycznie analizuje wymagania. Prototypowanie W tym podejściu do zatwierdzania przedstawia się użytkownikom i klientom wykonywalny model systemu. Generowanie testów Idealnie byłoby, aby wymagania dało się testować. Zautomatyzowane sprawdzanie sprzeczności Jeśli wymagania wyrażono w modelu systemu za pomocą strukturalnej lub formalnej notacji, to narzędzia CASE mogą sprawdzić niesprzeczność systemu.

46 Przeglądy wymagań Przegląd wymagań jest ręcznym procesem, w którym wielu czytelników, zarówno ze strony klienta, jak i zleceniobiorcy, sprawdza dokumentację wymagań w poszukiwaniu anomalii i pominięć. Można też zorganizować go w większej skali z wieloma uczestnikami sprawdzającymi różne części dokumentacji. Przeglądy wymagań mogą być formalne albo nieformalne. Przeglądy nieformalne polegają na tym, że zleceniobiorcy rozmawiają o wymaganiach z największą liczbą uczestników, jak to jest możliwe.

47 Sprawdzenie wymagań Możliwość weryfikacji. Czy wymaganie wyrażono tak, aby można je praktycznie sprawdzić? Zrozumiałość. Czy klienci i użytkownicy systemu właściwie zrozumieli wymaganie? Pochodzenie. Czy jawnie zaznaczono źródło, z którego pochodzi wymaganie? Giętkość. Czy wymaganie może być zmienione bez znaczącego wpływu na inne wymagania systemowe?

48 Zautomatyzowane sprawdzanie niesprzeczności wymagań
Wymagania zapisane w języku formalnym Raport o błędach w wymaganiach Procesor wymagań Analizator wymagań Baza danych wymagań

49 Zarządzanie wymaganiami
Wymagania stawiane wielkim systemom oprogramowania zawsze się zmieniają. Jedną z przyczyn takiej sytuacji jest to, że systemy te są zwykle budowane po to, aby rozwiązać problemy „złośliwe”. W trakcie procesu tworzenia oprogramowania stopień zrozumienia problemu stale się zmienia, a zmiany te mają zwrotny wpływ na wymagania.

50 Wymagania stawiane wielkim systemom
Z wielkich systemów korzysta zwykle bardzo urozmaicona społeczność użytkowników. Różni użytkownicy stawiają różne wymagania i przypisuje im inne priorytety i może to prowadzić do zmiany wymagań. Ludzie, którzy płacą za system, i jego użytkownicy to zwykle różni klienci. Klienci systemu formułują wymagania wynikające z ograniczeń organizacyjnych i budżetowych. Te wymagania mogą być w konflikcie z wymaganiami użytkowników. Otoczenie technologiczne i gospodarcze systemu zmienia się. Te zmiany muszą być odzwierciedlone w samym systemie.

51 Ewolucja wymagań Zmienione Wstępne rozumienie zrozumienie problemu
wymagania Wstępne wymagania Czas

52 Wymagania stałe i zmienne
Wymagania stałe to względnie stabilne wymagania, które wynikają z podstawowej działalności firmy i bezpośrednio odnoszą się do dziedziny systemu. W szpitalu zawsze będą wymagania dotyczące pacjentów, lekarzy, pielęgniarek, terapii, itp. Wymagania zmienne to wymagania, które prawdopodobnie ulegną zmianie w trakcie tworzenia systemu albo po przekazaniu go do użytkowania. Takimi wymaganiami są na przykład wymagania, które wynikają z polityki zdrowotnej rządu.

53 Klasyfikacja wymagań zmiennych
Wymagania zmieniające się Zmieniają się na skutek zmian środowiska, w którym działa firma. Wymagania pojawiające się Pojawiają się w trakcie procesu tworzenia w miarę coraz lepszego rozumienia systemu przez klienta. Wymagania wynikowe Wynikają z wdrożenia systemu komputerowego. Wymagania zgodności Zależą mów lub procesów gospodarczych wewnątrz firmy.

54 Planowanie zarządzania wymaganiami
W trakcie tej fazy zarządzania wymaganiami należy podjąć decyzje dotyczące następujących zagadnień: Oznakowanie wymagań Każde wymaganie musi być unikatowo oznakowane tak, aby można było robić do niego odnośniki z innych wymagań i używać tego wymagania przy ocenianiu pochodzenia. Proces zarządzania zmianami Jest to zbiór czynności szacowania wpływu i kosztu zmian. Strategia śledzenia pochodzenia Te strategie definiują zależności między wymaganiami i projektem systemu, które należy odnotowywać. Użycie narzędzi CASE Zarządzanie wymaganiami polega na przetwarzaniu ogromnych ilości informacji o wymaganiach.

55 Pochodzenie Możliwość śledzenia pochodzenia jest ogólną cechą specyfikacji wymagań Trzy typy informacji o pochodzeniu, które warto gromadzić Informacje o uczestnikach, którzy zaproponowali dane wymagania, wraz z ich uzasadnieniem.. Informacje o uzależnieniu wymagań wiążą w dokumentacji wymagań te wymagania, które od siebie zależą. Informacje o uzależnieniu projektu wiążą wymagania z modułami projektu, które implementują te wymagania.

56 Macierz zależności Id wymagań 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 U R

57 Korzystanie z narzędzi CASE w zarządzaniu wymaganiami
Przechowywania wymagań Wymagania należy gromadzić w zabezpieczonej i administrowanej składnicy danych, która jest dostępna dla wszystkich biorących udział w procesie inżynierii wymagań. Zarządzania zmianami Proces zarządzania zmianami jest znacznie prostszy, gdy aktywnie korzysta się ze wspomagania narzędzi. Zarządzania zależnościami Wspomaganie narzędzi przy śledzeniu zależności umożliwia wykrywanie powiązanych wymagań.

58 Zarządzanie zmianami wymagań
Zarządzanie zmianami wymagań należy zastosować do wszystkich postulowanych zmian wymagań. Trzy podstawowe kroki: Analiza problemu i specyfikacja zmiany. Proces rozpoczyna się od rozpoznania problemu z wymaganiem lub czasem od konkretnej propozycji zmiany. Analiza zmiany i ocena kosztów. Korzystając z informacji o uzależnieniu i ogólnej wiedzy o wymaganiach systemowych, ocenia się wpływ proponowanej zmiany. Implementacja zmiany. Modyfikuje się dokumentacje wymagań oraz, jeśli zachodzi taka potrzeba, również projekt i implementacje systemu.

59 Zarządzanie zmianami wymagań
Skorygowane wymagania Rozpoznany problem Analiza problemu i specyfikacja zmiany Analiza zmiany i ocena kosztów Implementacja zmiany

60 Główne tezy Proces inżynierii wymagań obejmuje studium wykonalności, określanie i analizowanie wymagań, specyfikowanie wymagań, zatwierdzanie wymagań oraz zarządzanie wymaganiami. Analizowanie wymagań to proces iteracyjny, który obejmuje rozpoznanie dziedziny, zbieranie wymagań, klasyfikację, strukturalizację, nadawanie priorytetów i zatwierdzanie.

61 Główne tezy Różni użytkownicy systemu mogą stawiać różne wymagania. Wszystkie złożone systemy należy więc analizować z kilku punktów widzenia. Punkty widzenia odpowiadają źródłom lub przeznaczeniom danych, różnym reprezentacjom systemu albo bytom spoza systemu, które korzystają z jego usług. Czynniki społeczne i organizacyjne mają silny wpływ na wymagania systemowe i od nich głównie zależy, czy system będzie faktycznie używany, czy nie.