Wynikiem wstępnej analizy wymagań udziałowców systemu jest Definicja systemu (produktu). Dokument ten definiuje system na wysokim poziomie abstrakcji wskazując, jakie będą główne korzyści z jego realizacji i dla kogo, opisuje jego podstawowe charakterystyki w kontekście zamierzonego użytkowania, a także dokonuje dekompozycji elementów systemu na mniejsze fragmenty i odpowiadające im działania projektowe. Dokument ten jest punktem wyjścia do szczegółowych działań, związanych z rozpoznaniem wymagań, stanowi podstawę do ustalenia harmonogramu projektu i oszacowania zasobów wymaganych do jego realizacji.

Przykładowy wzór Definicji systemu (produktu) zawiera tabela 1.

Powyższy wzór wymaga dostosowania do konkretnej rzeczywistości projektu. Tworząc taki dokument, należy kierować się podstawową zasadą: Co muszę wiedzieć i co z tego muszę zapisać, aby ci, którzy po mnie będą czytać ten dokument, mogli kontynuować projekt bez ryzyka niepowodzenia i nie tracili czasu na zbędne pytania.

Inżynieria wymagań

Główną przyczyną niskiej jakości, przekroczenia kosztów projektów i opóźnień w dostawach produktów do użytkownika są niepoprawne, niekompletne i fałszywe wymagania. Zmiany wymagań na etapie projektowania czy nawet kodowania pociągają za sobą konieczność przeprojektowania dużych części systemu, co oznacza wykonanie dodatkowej, nie uwzględnionej w harmonogramie i budżecie pracy oraz - oczywiście - wyrzucenie do "kosza" dotychczasowych osiągnięć.

Inżynieria wymagań jest określeniem, pod którym kryją się wszystkie działania zmierzające do wypracowania i przeprowadzenia racjonalnych i systematycznych procedur pozyskiwania, analizy, specyfikacji i weryfikacji wymagań. Pojęcie to odnosi się do ogólnej metodyki zdobywania wszelkich informacji, mających charakter wymagań, a w szczególności do etapu analizy wymagań oprogramowania, który jest naturalnym rozwinięciem fazy ogólnej definicji systemu.

Pozyskiwanie wymagań jest procesem, w którym klienci i/lub przyszli użytkownicy przy pomocy twórców systemu odkrywają, poznają i artykułują swoje wymagania. Ogólny schemat tego procesu przedstawiono poniżej:

1. Identyfikacja źródeł wymagań

2. Komunikacja, zbieranie, gromadzenie danych

3. Analiza zdobytych informacji

4. Potwierdzenie właściwego zrozumienia wymagań

5. Sformułowanie wymagań

Analiza wymagań jest procesem głębszego poznawania wymagań, tworzenia modelu przyszłego systemu oraz wykrywania w pierwotnym zestawie wymagań wszelkich błędów, braków, konfliktów i nielogiczności, a także odkrywania wzajemnych związków między wymaganiami.

Specyfikacja wymagań jest procesem zapisywania wymagań w określonej formie językowej, symbolicznej lub graficznej, umożliwiającej możliwie najwierniejsze odtworzenie modelu wyobrażeniowego systemu opracowanego na etapie analizy.

Weryfikacja wymagań jest procesem zatwierdzania wymagań przez klienta i/lub użytkownika jako zgodnych z jego oczekiwaniami i sprawdzonych pod względem poprawności i kompletności.

Istnieje wiele gotowych inżynierskich metod pozyskiwania, analizy i specyfikacji wymagań, takich jak JAD, RAD, analiza strukturalna, analiza obiektowa, metodyka Jacksona, SADT, OMT, Boocha, UML itd. Metody te oferują sprawdzone w praktyce rozwiązania szczegółowych działań, prowadzących do pomyślnego określenia wymagań użytkownika oraz odwzorowania ich na specyfikację pozwalającą na realizację systemu.

Metody te formalnie są elementem cyklu życia projektu i należą do konkretnego procesu produkcji oprogramowania. Z punktu widzenia zarządzania projektem istotne jest tylko to, że dostarczają specyfikacji wymagań, która jest podstawą do projektowania konkretnego systemu. Powodzenie projektu zależy więc od poprawności, kompletności, spójności, czytelności, weryfikowalności i modyfikowalności specyfikacji wymagań. Każda specyfikacja musi podlegać weryfikacji, aby w razie wykrycia błędów zaplanować działania korygujące. Z drugiej strony wymagania użytkownika zawsze będą się zmieniać, gdyż każdy system jest w ruchu, podlega modyfikacjom, adaptacjom, rozszerzeniom, a system informatyczny jest tylko częścią kontekstu działań użytkownika. Oznacza to, że w trakcie projektu konieczne jest systematyczne i przemyślane zarządzanie wymaganiami.