Wymaganie w inżynierii , jest pojedynczą, udokumentowaną potrzebą 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].

Wymagania produktowe a procesowe

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).

Wymagania w inżynierii systemów i oprogramowania

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.

Niektóre zagadnienia opracowywania wymagań

Klasyfikacja

Wymagania są dzielone na następujące kategorie:

• Wymagania funkcjonalne opisują funkcjonalność, którą system ma realizować, na przykład formatowanie tekstu lub modulowanie sygnału. Czasami są znane jako możliwości.
• Wymagania pozafunkcjonalne specyfikują kryteria osądzania działania systemu. Są one znane jako wymagania jakościowe.
• 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.

Dobre wymagania

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 ^[2][3][4][5].

Weryfikacja

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 moga być wykryte droga odrębnych analiz, inspekcji i recenzji.

Analiza wymagań lub inżynieria wymagań

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.

Dokumentacja wymagań

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 story)

Zmiany wymagań

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

Dyskusje odnośnie potrzeby dyscypliny w zakresie wymagań na oprogramowanie

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 story) (krótkie opisy na indeksowanych kartach, wyjaśniające co system powinien wykonywać) oraz serie testów akceptacyjnych dla tych historii.

Zobacz też

• FURPS – model klasyfikacji jakości oprogramowania
• Analiza wymagań
• Zarządzanie wymaganiami
• Przypadek użycia

Bibliografia

1. ↑ Karl E. Wiegers, Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle, Second Edition, Microsoft Press 2003
2. ↑ Boehm, B.W. and Papaccio, P.N., 1988, Understanding and controlling software costs, IEEE Trans of Software Engineering, 14(10), 1462-1477
3. ↑ Bridges, W., 1995, Managing Transitions, Making the most of change, Nicholas Brealey Publishing, UK.
4. ↑ Sjaak Brinkkemper 1996, Method engineering: engineering of information systems development methods and tools, Inf. Software Technol., 38(4), 275-280.
5. ↑ Davis, A.M., 1993, Software Requirements: Analysis and Specification, Prentice Hall, second Edition, 1993.

Linki zewnętrzne

• RalphYoung.net , witryna o zagadnieniach wymagań
• Discovering System Requirements
• The International Institute for Business Analysis and The IIBA's Business Analysis Body of Knowledge