Wymaganie (inżynieria) – Wikipedia, wolna encyklopedia

Ten artykuł dotyczy inżynierii. Zobacz też: Potrzeba.

Wymaganie – pojedyncza, udokumentowana potrzeba określonego produktu czy usługi albo sposobu ich działania. Formalnie jest to wykorzystywane powszechniej w inżynierii systemów lub w inżynierii oprogramowania. Jest to stwierdzenie identyfikujące potrzebne cechy, możliwości, charakterystyki lub jakość systemu, aby był on wartościowy i pożyteczny dla użytkownika. W klasycznej inżynierii, zbiór wymagań jest wykorzystywany w fazie projektowania nowego produktu. Wymagania pokazują, jakie elementy i funkcje są niezbędne w konkretnym projekcie.

Faza opracowywania wymagań może być poprzedzona studium wykonalności lub koncepcyjną fazą projektu. Faza wymagań może być podzielona na gromadzenie wymagań (zbieranie wymagań od interesariuszy), analizowanie (sprawdzenie spójności i kompletności), specyfikowanie (dokumentowanie wymagań) oraz zatwierdzanie (upewnienie się, że wymagania są poprawne)^[1].

Projekty są podmiotem trzech rodzajów wymagań.

Wymagania biznesowe opisują w terminologii handlowej co ma być dostarczone lub wykonane w celu uzyskania wartości.

Wymagania produktowe opisują system lub produkt, który na jeden z możliwych sposobów wypełnia wymagania biznesowe.

Wymagania procesowe opisują procesy, które organizacja musi zrealizować i ograniczenia, które muszą być respektowane.

Wymagania produktowe i procesowe są ściśle powiązane. Wymagania procesowe często są narzucone jako droga osiągnięcia niektórych wymagań produktowych. Na przykład maksymalny wymagany koszt wytworzenia (wymaganie procesowe) może być wymuszone przez maksymalną cenę zbytu (wymaganie produktowe); wymaganie na produkt ma być utrzymane (wymaganie produktowe), ale może być realizowane różnymi metodami, jak np. programowanie obiektowe, różne style, różne procesy kontroli (wymagania procesowe).

W inżynierii systemów wymaganie może być opisem tego co system musi wykonywać w postaci wymagania funkcjonalnego. Inny typ wymagania specyfikuje sam system i jak dobrze wykonuje on swoje funkcje. Takie wymagania są często nazywane wymaganiami pozafunkcjonalnymi, ‘wydajnościowymi’ lub ‘jakościowymi’. Przykładami takich wymagań są przydatność, dostępność, niezawodność, podatność na testowanie, możliwości utrzymania oraz (jeśli jest to zdefiniowane w sposób umożliwiający jednoznaczną weryfikację i pomiar) łatwość użytkowania.

Zbiór wymagań definiuje charakterystyki lub cechy oczekiwanego systemu. ‘Dobra’ lista wymagań generalnie nie mówi jak wymagania są implementowane, pozostawiając to projektantowi systemu. Opis jak system powinien być zrealizowany są znane jako tendencja implementacji lub „inżynieria rozwiązań”. Jednak ograniczenie realizacyjne (znane także jako wymagania rozwiązań) mogą być celowo wyrażone przez przyszłego użytkownika, na przykład w celu zapewnienia zgodności z innymi już posiadanymi produktami. W inżynierii oprogramowania ma zastosowanie to samo znaczenie wymagań, lecz w odniesieniu do oprogramowania.

Wymagania są zazwyczaj klasyfikowane na typy produkowane na różnych etapach rozwoju, z taksonomią w zależności od ogólnego modelu, który został użyty. Przykładem tego jest schemat opracowany przez International Institute of Business Analysis(inne języki) w „A Guide to the Business Analysis Body of Knowledge(inne języki)”^[2].

• Wymagania architektoniczne wyjaśniają, co należy zrobić identyfikując niezbędną integrację struktury systemów i zachowania systemów, tj. Systems architecture(inne języki). W inżynierii oprogramowania nazywane są Architecturally significant requirements(inne języki), które definiuje się jako te wymagania, które mają wymierny wpływ na architekturę systemu oprogramowania^[3].
• Wymagania biznesowe definiują oczekiwania i rezultaty, jakie powinny być zrealizowane by osiągnąć cel. Mogą dotyczyć całości organizacji, obszaru biznesowego lub określonej inicjatywy. Wymagania biznesowe są na poziomie organizacji i nie określają wymagań, które są specyficzne dla konkretnej grupy interesariuszy. Często podawane w uzasadnieniu Business case^[4].
• Wymagania funkcjonalne opisują funkcje, możliwości, które w systemie będziemy potrzebować, a system ma realizować. Istotne jest używanie przy określaniu wymagań konkretnych, precyzyjnych, jednoznacznych i dających się następnie zweryfikować stwierdzeń. Na przykład formatowanie tekstu, modulowanie sygnału, formaty zapisów danych, możliwości wydruku, przeglądanie faktur za dany okres^[5].
• Wymagania pozafunkcjonalne inaczej wymagania dotyczące jakości usług. Zwykle szczegółowe stwierdzenia warunków, w których rozwiązanie musi pozostać skuteczne, cechy, które musi posiadać rozwiązanie, lub ograniczenia, w których musi działać^[6]. Przykłady obejmują: niezawodność, łatwość konserwacji, testowalność oraz dostępność.
• Wymagania ograniczeń określają granice rozwiązania. Niezależnie od tego jak problem jest rozwiązany, ograniczenia muszą być respektowane.

Wymagania niefunkcjonalne mogą być dalej klasyfikowane według tego czy są to wymagania użyteczności, wymagania wyglądu i odczuwania, wymagania humanitarne, wymagania wydajnościowe, wymagania eksploatacyjne, wymagania utrzymywania, wymagania bezpieczeństwa, wymagania niezawodnościowe lub jeden z wielu innych typów wymagań.

W inżynierii oprogramowania ta klasyfikacja jest użyteczna, gdyż tylko wymagania funkcjonalne są bezpośrednio implementowane w programach. Wymagania niefunkcjonalne są kontrolowane przez inne aspekty systemu. Na przykład niezawodność systemu komputerowego zależy od ilości usterek sprzętu, wydajność zależy od wydajności procesora i pamięci. Wymagania niefunkcjonalne mogą być, w pewnych przypadkach, dekomponowane na jedno lub kilka wymagań funkcjonalnych. Pokazuje to model klasyfikacji jakości oprogramowania FURPS. Dodatkowo wymagania niefunkcjonalne, nie posiadające miary, mogą być przekształcane w wymagania procesowe. Na przykład możliwości utrzymania systemu mogą być dekomponowane na ograniczenia składników systemu lub na liczbę wierszy kodu programu.

Charakterystyki dobrych wymagań są różnie przedstawiane przez różnych autorów, przy czym każdy generalne wiąże to ogólnymi rozważaniami lub określoną domeną techniczną, której to dotyczy. Następujące charakterystyki są ogólnie akceptowane^{[7][8][9][10]}.

Wszystkie wymagania powinny być weryfikowalne. Najpowszechniejszą metodą weryfikacji jest badanie. Jeśli nie ma to zastosowania inna metoda może być użyta (tj. analiza, pokaz, oględziny lub recenzja projektu).

Pewne wymagania są nieweryfikowalne z powodu ich struktury. Obejmuje to wymagania mówiące, że system „nigdy” lub „zawsze” będzie miał określoną właściwość. Odpowiednie przebadanie tych wymagań może potrzebować nieokreślonego cyklu testowania. Takie wymagania muszą być sformułowane ponownie, aby były weryfikowalne. Zgodnie z powyższymi stwierdzeniami wszystkie wymagania muszą być weryfikowalne.

Wymagania niefunkcjonalne, nieweryfikowalne na poziomie programu, muszą być zachowane jako dokumentacja intencji klienta. Mogą być przekształcone na wymagania procesowe jako sposób ich praktycznego wypełnienia. Na przykład niefunkcjonalne wymaganie zabezpieczenia przed tylnym wejściem (backdoor) może być zastąpione przez programowanie w parach (pair programming). Inne wymagania niefunkcjonalne mogą prowadzić do składników systemu i weryfikacji na tym poziomie. Na przykład niezawodność systemu jest często weryfikowana przez analizy na poziomie składników systemu. Programy awioniki z ich skomplikowanymi wymaganiami bezpieczeństwa muszą wypełniać wymagania procesu DO-178B.

Weryfikowalność wymagań jest konieczna, ale są i inne ważne zagadnienia. Stwierdzenie samej weryfikowalności nie eliminuje niepoprawnych wymagań, co może prowadzić do nieodpowiednich wyników. Więcej, weryfikacja jest fałszywa gdy jakieś wymagania pominięto. Przypadki takie mogą być wykryte droga odrębnych analiz, inspekcji i recenzji.

Wymagania mogą być niejednoznaczne, niekompletne i niespójne. Są znane techniki, które pomagają uporać się z tymi niedoskonałościami. Usunięcie niejednoznaczności, niekompletności i braku spójności na etapie tworzenia wymagań kosztuje o rząd wielkości mniej niż ich poprawianie w późniejszych fazach rozwijania produktu. Analiza wymagań temu służy.

Przeciwieństwem niejasności wymagań jest ich wielka szczegółowość, która prowadzi do tego, że:

1. ich wytworzenie zajmuje dużo czasu,
2. ograniczają dostępne możliwości realizacji,
3. ich wytworzenie jest kosztowne.

Analiza wymagań pod tym kątem pozwala na inżynierski kompromis.

Wymagania są zwykle pisane w celu komunikacji pomiędzy różnymi interesariuszami. Oznacza to, że wymagania powinny być łatwe do zrozumienia zarówno przez użytkowników, jak i projektantów. Drogą wspólnego dokumentowania wymagań jest stwierdzenie co system będzie robił. Przykład: „Dostawca ma dostarczyć produkt nie później niż dnia xyz.” Innymi możliwościami są przypadki użycia lub historie użytkowników (user stories).

Generalnie wymagania zmieniają się z czasem. Wymagania zdefiniowane i zatwierdzone powinny podlegać kontroli zmian. W wielu projektach wymagania były zmienianie przed ukończeniem systemu. Częściowo wynika to ze złożoności oprogramowania i faktu, że użytkownicy nie wiedzą co chcą zanim tego nie zobaczą. Te charakterystyki wymagań podlegają zarządzaniu wymaganiami.

Niektóre nowoczesne metodyki inżynierii oprogramowania jak programowanie ekstremalne kwestionują potrzebę rygorystycznego opisywania wymagań na oprogramowanie, które są uważane za ruchomy cel. Zamiast tego opisują wymagania nieformalnie wykorzystując historie użytkowników (user stories) (krótkie opisy na indeksowanych kartach, wyjaśniające co system powinien wykonywać) oraz serie testów akceptacyjnych dla tych historii.

• RalphYoung.net, witryna o zagadnieniach wymagań
• Discovering System Requirements. gd4.tuwien.ac.at. [zarchiwizowane z tego adresu (2009-05-24)].
• The International Institute for Business Analysis and The IIBA’s Business Analysis Body of Knowledge