Wymaganie (inżynieria)

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

Wymagania produktowe a procesowe

[edytuj | edytuj kod]

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

[edytuj | edytuj kod]

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ń

[edytuj | edytuj kod]

Klasyfikacja

[edytuj | edytuj kod]

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.

Dobre wymagania

[edytuj | edytuj kod]

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

Charakterystyka Wyjaśnienie
Spójność Wymaganie odnosi się do jednej i tylko jednej sprawy.
Kompletność Wymaganie wszystko określa w jednym miejscu, bez brakującej informacji.
Zgodność Wymaganie jest niesprzeczne jakimkolwiek innym wymaganiem i w pełni zgodne z wymaganą zewnętrzną dokumentacją.
Poprawność Wymaganie wypełnia wszystkie lub część potrzeb biznesowych określonych przez interesariuszy.
Aktualność Wymaganie nie starzeje się z upływem czasu.
Zewnętrzna zauważalność Wymaganie specyfikuje charakterystyki produktu, które są zewnętrznie dostrzegalne lub doświadczane przez użytkownika. „Wymagania”, które specyfikują wewnętrzną architekturę, sposób projektowania i realizacji oraz kryteria badań są odpowiednimi ograniczeniami i powinny być umieszczone części dokumentu wymagań zawierającej ograniczenia.
Wykonalność Wymaganie może być zrealizowane w ramach ograniczeń projektu.
Jednoznaczność Wymaganie jest sformułowane precyzyjne, bez używania żargonu technicznego, akronimów (poza zdefiniowanymi w dokumencie wymagań) lub innego słownictwa ezoterycznego. Wyraża ono obiektywne fakty, a nie subiektywne opinie. Może być ono interpretowane dokładnie na jeden sposób. Należy unikać niejasnych pojęć, przymiotników, przyimków, czasowników i subiektywnych wyrażeń. Zdania przeczące i złożone są zabronione.
Obowiązkowość Wymaganie reprezentuje charakterystyki zdefiniowane przez interesariuszy, których brak spowoduje niedoskonałość, która nie może być naprawiona.
Weryfikowalność Realizacja wymagania może być sprawdzona jedną z czterech możliwych metod: oględziny, analizy, pokazy lub badania. Zwykle oczekiwanymi metodami są badania lub pokazy. Oględziny i analizy są wykonywane w specjalnych przypadkach.

Weryfikacja

[edytuj | edytuj kod]

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.

Analiza wymagań lub inżynieria wymagań

[edytuj | edytuj kod]

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ń

[edytuj | edytuj kod]

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

Zmiany wymagań

[edytuj | edytuj kod]

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 do potrzeby dyscypliny w zakresie wymagań stawianych oprogramowaniu

[edytuj | edytuj kod]

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.

Przypisy

[edytuj | edytuj kod]
  1. ↑ Karl E. Wiegers, Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle, Second Edition, Microsoft Press 2003.
  2. ↑ International Institute of Business Analysis., A guide to the Business analysis body of knowledge (BABOK guide)., wyd. Version 2.0, Toronto: International Institute of Business Analysis, 2009, ISBN 978-0-9811292-1-1, OCLC 426221913 [dostęp 2019-06-08].
  3. ↑ Lianping Chen, Muhammad Ali Babar, Bashar Nuseibeh, Characterizing Architecturally Significant Requirements, „IEEE Software”, 30 (2), 2013, s. 38–45, DOI: 10.1109/ms.2012.174, ISSN 0740-7459 [dostęp 2019-06-08].
  4. ↑ Wymagania biznesowe a wymagania systemowe | Michał Wolski [online], www.michalwolski.pl [dostęp 2019-06-08].
  5. ↑ Wymagania użytkownika [online], zasoby.open.agh.edu.pl [dostęp 2019-06-08].
  6. ↑ Kalle Lyytinen i inni red., Design Requirements Engineering: A Ten-Year Perspective, „Lecture Notes in Business Information Processing”, 2009, DOI: 10.1007/978-3-540-92966-6, ISSN 1865-1348 [dostęp 2019-06-08].
  7. ↑ Boehm, B.W. and Papaccio, P.N., 1988, Understanding and controlling software costs, IEEE Trans of Software Engineering, 14(10), 1462-1477.
  8. ↑ Bridges, W., 1995, Managing Transitions, Making the most of change, Nicholas Brealey Publishing, UK.
  9. ↑ Sjaak Brinkkemper 1996, Method engineering: engineering of information systems development methods and tools, Inf. Software Technol., 38(4), 275-280.
  10. ↑ Davis, A.M., 1993, Software Requirements: Analysis and Specification, Prentice Hall, second Edition, 1993.

Linki zewnętrzne

[edytuj | edytuj kod]