Wcześniej omówiliśmy główne 4 czynności inżynierii wymagań.

Inżynieria wymagań jest procesem zbierania i definiowania usług, które powinny być dostarczane przez system.

W praktyce, inżynieria wymagań nie jest procesem sekwencyjnym, jest to proces iteracyjny, w którym czynności są przeplatane.

Na przykład, iterujemy najpierw nad wymaganiami użytkownika; elicytacją, specyfikacją i walidacją, a następnie powtarzamy te same kroki dla wymagań systemowych.

Wcześniej w procesie, większość wysiłku zostanie poświęcona na zrozumienie wysokopoziomowych wymagań biznesowych i wymagań użytkownika. W późniejszym etapie procesu, więcej wysiłku zostanie poświęconego na elicytację i zrozumienie szczegółowych wymagań systemowych.

Niektórzy uważają, że inżynieria wymagań jest procesem zastosowania metody analizy strukturalnej, takiej jak analiza obiektowa. Obejmuje to analizę systemu i opracowanie zestawu graficznych modeli systemu, takich jak modele przypadków użycia, które następnie służą jako specyfikacja systemu.

Mimo że metody strukturalne odgrywają pewną rolę w procesie inżynierii wymagań, w inżynierii wymagań jest znacznie więcej niż to, co jest objęte tymi metodami.

Analiza i projektowanie zorientowane obiektowo zostaną omówione w innej serii samouczków.

Wymagania użytkownika i systemu

Typowo, wymagania są przedstawiane na dwóch poziomach szczegółowości; wymagania użytkownika i wymagania systemu, gdzie użytkownik potrzebuje wysokopoziomowych deklaracji wymagań, podczas gdy twórcy systemu potrzebują bardziej szczegółowej specyfikacji systemu. Tak więc, wymagania użytkownika i wymagania systemowe są po prostu odnoszone do różnych poziomów szczegółowości.

Mając różne poziomy szczegółowości jest użyteczne, ponieważ przekazuje informacje o tworzonym systemie dla różnych typów czytelników.

Tak więc, użytkownicy końcowi nie będą zajmować się szczegółami, potrzebują ogólnego, wyabstrahowanego wymagania w formie pisemnej.

Podczas gdy ludzie, którzy są zaangażowani w rozwój, potrzebują tego, co dokładnie system powinien robić.

Prawdopodobnie skończysz z wieloma problemami i nieporozumieniami, jeśli nie będziesz miał jasnego rozdziału pomiędzy różnymi poziomami szczegółowości.

Wymagania użytkownika

Opisuje usługi, które system powinien dostarczać i ograniczenia, pod którymi musi działać. Nie spodziewamy się zobaczyć żadnego poziomu szczegółowości, lub co dokładnie system będzie robił, Jest to bardziej ogólne wymaganie.

Zazwyczaj jest napisane w języku naturalnym i dostarczone przez diagramy.

W dalszej części tej serii omówimy różne sposoby określania wymagań.

Wymagania systemowe

Wymagania systemowe oznaczają bardziej szczegółowy opis usług systemowych i ograniczeń operacyjnych, takich jak sposób, w jaki system będzie używany, oraz ograniczeń rozwojowych, takich jak języki programowania.

Ten poziom szczegółowości jest potrzebny tym, którzy są zaangażowani w rozwój systemu, jak inżynierowie, architekci systemu, testerzy, itp.

Wymagania funkcjonalne &Wymagania niefunkcjonalne

Wymagania oprogramowania są klasyfikowane na wymagania funkcjonalne i wymagania niefunkcjonalne.

Wymagania funkcjonalne

Obejmują główne funkcje, które powinny być zapewnione przez system. Kiedy są wyrażane jako wymagania użytkownika, są zwykle opisywane w sposób abstrakcyjny.

Jednakże bardziej konkretne wymagania funkcjonalne systemu opisują funkcje systemu, jego wejścia, przetwarzanie; jak będzie reagował na określone wejście i jakie jest oczekiwane wyjście.

Wymagania niefunkcjonalne

Są to ograniczenia na funkcje dostarczane przez system.

Wymagania, jak wiele procesów system może obsłużyć (wydajność), jakie są (bezpieczeństwo) problemy, którymi system musi się zająć, takie jak wstrzyknięcia SQL …

Szczęstotliwość awarii (niezawodność), jakie są języki i narzędzia, które będą używane (rozwój), jakie są zasady, których musisz przestrzegać, aby zapewnić, że system działa zgodnie z prawem organizacji (legislacja).

Wymagania niefunkcjonalne są często krytyczne niż poszczególne wymagania funkcjonalne. Użytkownicy zazwyczaj mogą znaleźć sposób na obejście funkcji systemu, która nie do końca spełnia ich potrzeby. Jednak niespełnienie wymagania niefunkcjonalnego może oznaczać, że cały system jest bezużyteczny.

Na przykład, jeśli samolot nie spełnia wymagań niezawodnościowych, nie będzie bezpieczny w eksploatacji, lub jeśli wbudowany system sterowania nie spełnia wymagań wydajnościowych, funkcje sterowania nie będą działać prawidłowo.

Wymagania niefunkcjonalne powinny być mierzalne

Wszędzie, gdzie to możliwe, powinniśmy pisać wymagania niefunkcjonalne ilościowo, tak aby można je było przetestować. Można je zmierzyć podczas testowania systemu, aby sprawdzić, czy system spełnia swoje wymagania niefunkcjonalne.

W praktyce, klienci systemu często mają trudności z przełożeniem swoich celów na mierzalne wymagania. Nie rozumieją, czym jest jakaś liczba określająca wymaganą szybkość lub niezawodność. Dla niektórych celów, takich jak utrzymywalność, nie ma metryk, których można użyć.

Koszty weryfikacji mierzalnych wymagań niefunkcjonalnych mogą być bardzo wysokie, a klienci mogą nie uważać, że te koszty są uzasadnione.

Wymagania niefunkcjonalne i funkcjonalne są zależne

Wymagania niefunkcjonalne często są sprzeczne, wchodzą w interakcje lub nawet generują inne wymagania funkcjonalne lub niefunkcjonalne.

Wymaganie użytkownika dotyczące bezpieczeństwa, takie jak ograniczenie dostępu do systemu do autoryzowanych użytkowników, może generować inne wymagania, które są funkcjonalne, takie jak potrzeba włączenia do systemu urządzeń uwierzytelniających użytkownika.

Rozróżnienie między wymaganiami funkcjonalnymi i niefunkcjonalnymi

W praktyce trudno jest rozdzielić wymagania funkcjonalne i niefunkcjonalne. Rozróżnienie nie jest jasne, jak sugerują ich definicje.

Rozróżnienie pomiędzy wymaganiami funkcjonalnymi i niefunkcjonalnymi

Jeśli wymagania niefunkcjonalne są podane oddzielnie od wymagań funkcjonalnych, związek pomiędzy nimi może być trudny do zrozumienia.

Powinniśmy jednak wyraźnie wyróżnić wymagania, które są wyraźnie związane z emergentnymi właściwościami systemu, takimi jak wydajność lub niezawodność.

Właściwości emergentne są właściwościami systemu jako całości, a nie właściwościami, które można wyprowadzić z właściwości poszczególnych komponentów systemu.

.