Rodzaje wymagań

W poprzednim wpisie określiłem kilka definicji, którymi będę się posługiwał w cyklu tekstów o inżynierii wymagań. Czas podział wymagań.

Wymagania dzielę na wymagania funkcjonalne i wymagania niefunkcjonalne (zwane także wymaganiami jakościowymi). Ponadto identyfikuję ograniczenia.

Wymagania funkcjonalne określają funkcjonalność tworzonego oprogramowania.

Wymagania funkcjonalne mogą być podzielone na wymagania funkcjonalne, wymagania dotyczące zachowania systemu oraz wymagania dotyczące danych.

Wymagania niefunkcjonalne określają pożądane cechy tworzonego systemu i często mają bardziej znaczący wpływ na wybór architektury dla tworzonego systemu niż wymagania funkcjonalne. Wymagania jakościowe dotyczą min. wydajności, dostępności, niezawodności, skalowalności i przenośności.

Ograniczenia dotyczą bezpośrednio tworzonego systemu (np. System musi być zaimplementowany jako usługa WEB) lub procesu produkcyjnego (np. System musi być dostarczony do końca roku 2013).

Ograniczenia w przeciwieństwie do wymagań funkcjonalnych i jakościowych nie są implementowane w systemie, a dotyczą przestrzegania limitów rozwiązań i zasobów w procesie produkcyjnym oprogramowania.

Definicja: Wymaganie funkcjonalne

Wymaganie funkcjonalne jest to wymaganie dotyczące wyniku zachowania systemu, który powinien zostać dostarczony przez funkcję systemu.

Definicja: Wymaganie jakościowe

Wymaganie jakościowe to wymaganie, które dotyczy jakości tworzonego oprogramowania, które nie zostało określone przez wymagania funkcjonalne.

Definicja: Ograniczenie

Ograniczenie to wymaganie, które ogranicza przestrzeń rozwiązań poza to, co konieczne jest do spełnienia wymagań funkcjonalnych i jakościowych.

Poprawne zdefiniowanie wymagań jakościowych pozwala na obiektywne określenie jakości wytworzonego oprogramowania oraz określenie mierzalnych kryteriów akceptacji oprogramowania w trakcie jego realizacji.

Zazwyczaj wiele różnych pożądanych cech dla tworzonego systemu jest klasyfikowanych jako wymaganie jakościowe. W celu ułatwienia strukturyzacji i zarządzania wymaganiami jakościowymi zostało zaprezentowanych wiele różnych schematów klasyfikacyjnych dla wymagań jakościowych, jak np. Standard ISO 9126.

Typowe kategorie dla wymagań jakościowych

  • Wymagania określające jakość systemu w odniesieniu do bezpieczeństwa, dokładności obliczeń, interoperacyjności oraz zgodności z obowiązującymi standardami.
  • Wymagania określające niezawodność systemu w szczególności w odniesieniu do odporności na awarie, tolerancji dla błędów, czy odzyskania pełnej funkcjonalności systemu po wystąpieniu awarii
  • Wymagania dotyczące użytkowania systemu, takie jak wymagania dotyczące łatwości użytkowania aplikacji, łatwości nauczenia się korzystania z systemu
  • Wymagania, które określają efektywność systemu w odniesieniu do zachowania w czasie (np. czasu obliczeń) lub wykorzystania zasobów
  • Wymagania określające zmienność systemu w odniesieniu do stabilności i sprawdzalności systemu, zdolności do analizy i zmiany
  • Wymagania określające możliwości przenoszenia systemu w szczególności dotyczące zdolności adaptacyjnych, zdolności instalacyjnych, możliwości zastąpienia i odpowiedniej zgodności z obowiązującymi standardami

Wymagania pozyskiwane od klientów muszą zostać utrwalone w dokumentacji oraz przekazane do zespołu tworzącego oprogramowanie. Przekazywanie informacji wymaga wykorzystania określonego kodu, który będzie zrozumiały dla tworzącego informację oraz odbiorcy informacji.

Najpopularniejszym sposobem wymiany informacji pomiędzy dwoma osobami jest wykorzystanie języka naturalnego. Efektywna komunikacja z wykorzystaniem języka naturalnego wymaga spełnienia kilku warunków: wykorzystanie tego samego języka (np.: język polski), występowanie takich samych uwarunkowań kulturowych oraz podobnego doświadczenia.

Język naturalny jest najbardziej naturalnym medium przekazywania informacji pomiędzy ludźmi. Sukces komunikacji werbalnej opiera się na redundancji informacji (np. gestykulacja, informacja zwrotna) w przeciwieństwie do utrwalonej dokumentacji technicznej, która opiera się na zminimalizowanej redundancji oraz ograniczonej informacji zwrotnej.

Sukces w definiowaniu wymagań to przede wszystkim zapewnienie warunków do efektywnej komunikacji (uwarunkowań kulturowych i podobnego doświadczenia interesariuszy) może być bardzo trudne, szczególnie w przypadku posługiwania się terminami specyficznymi dla dziedziny problemu. Warto stosować  słowniki określających znaczenie wykorzystywanych w komunikacji terminów, które mogą być niezrozumiałe dla wszystkich interesariuszy lub różnie przez nich interpretowane oraz użyć formalnego języka do opisu problemu, np. Unified Modeling Language (UML).

Tekst zainspirowany książką: Klaus Pohl, Chris Rupp „Requirements engineering fundamentals : a study guide for the Certified Professional for Requirements Engineering exam : foundation level”, IREB compliant Wydawnictwo: Rocky Nook Inc, 2011

Podobne wpisy
Jesienny The Rational Edge ezine

Właśnie ukazał się jesienny The Rational Edge ezine (http://ibm.com/developerworks/ecma/campaign/er.jsp?id=376126&imid=68950291&end). Dla fanów RSA jest bardzo ciekawy artykuł, w którym Steve Arnold więcej

Podstawowe dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to podstawowe dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Średniozaawansowane dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to średniozaawansowane dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Zaawansowane dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to zaawansowane dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Reklama
MODESTO - licencje Enterprise Architect
Scroll to Top