Chciałam pisać o tym, jakie powinny być idealne wymagania, ale przecież temat wymagań powinniśmy zacząć od początku, czyli najpierw wyjaśnić sobie, co to jest to całe “wymaganie”.

Wymagania – definicja

Książkowe definicje,  a w sumie jedna z najczęściej cytowanych definicji wymagań (standard IEEE610) opisuje wymaganie jako:

1. Warunek lub umiejętność potrzeba użytkownikowi by rozwiązać problem lub osiągnąć cel
2. Warunek lub umiejętność która musi być spełniona przez system lub komponent systemu aby wypełnić założenia umowy, standardu, specyfikacji lub innego formalnego
3. Udokumentowana reprezentacja warunku lub umiejętności opisanych w 1. lub 2.

Ogólnie rzecz biorąc:

Wymaganie jest pewnym opisem rozwiązania (jego charakterystyką) – zbiorem jego cech wymaganych przez użytkownika, klienta lub innego interesariusza do osiągnięcia założonego celu.

 

Wymaganie jest podstawowym wyrazem oczekiwań interesariuszy, w tym klienta, stanowi podstawowy składnik umów, zamówień, planów projektowych itd. Dostarcza też podstawę do oceny, planowania, przeprowadzania i monitorowania czynności projektowych. Precyzyjne i mierzalne wyrażanie wymagań jest niezwykle istotne. Wymagania określają granice systemu, zakres danego produktu czy te zakontraktowane usługi serwisowe, w związku  z czym mają wpływ na wymiarowanie zakresu projektu. Istotne jest rejestrowanie informacji dotyczących wymagań w postaci umożliwiającej dzielenie się nimi.

 

Podział wymagań

Standard IEE830 dzieli wymagania na projektowe i produktowe. Bardzo ważne jest rozróżnienie wymagań projektowych od produktowych!

źródło: opracowanie własne na podstawie wymienionej literatury

Wymagania projektowe

Wymagania projektowe -opisują porozumienie między zamawiającym a producentem, dotyczące aspektów kontaktowych związanych z procesem wytwarzania lub utrzymywania produktu. Obejmować mogą budżet, dokumentacje, sposób realizacji projektu (fazy, etapy, czynności, konkretne metody projektowania czy implementacji). Nie stanowią części specyfikacji wymagań, są zazwyczaj dokumentowane w postaci planów projektowych, planów wytwarzania lub czynności zapewnienia jakości lub dokumentu deklaracji pracy. Oczywiście istotnie wpływają na tworzenie wymagań produktowych, jednak nie są bezpośrednio związane z planowanym rozwiązaniem. Częścią łączącą wymagania projektowe i produktowe mogą być wymagania przejścia (bardziej szczegółowo omówione niżej). Identyfikowanie wymagań projektu należy do wspólnych obowiązków analityka biznesowego oraz managera projektu, jednak zwykle odpowiada za nie właśnie menedżer projektu.

Wymagania produktowe

Wymagania produktowe- (ang. requirements) dotyczą charakterystyk samego produktu. Zgodnie z przyjętym w BABOK v3 podziałem, obejmują: wymagania biznesowe, użytkowników(interesariuszy), rozwiązania/systemowe(funkcjonalne i niefunkcjonalne) oraz wyżej wspomniane wymagania przejścia.

Uwaga! Innym funkcjonującym podziałem jest rozróżnienie wymagań na wymagania produktowe (funkcjonalne i niefunkcjonalne) oraz ograniczenia (techniczne i biznesowe). 

 

Wymagania biznesowe (ang. business requirements)-  wysokopoziomowe wymagania przedstawicieli biznesu dotyczące opisu problemu biznesowego.  Są zwykle przedstawiane w dokumencie wizji i zakresu. Określają, DLACZEGO organizacja zaimplementuje system. Przedstawiają korzyści biznesowe, jakie organizacja chce osiągnąć. Skupiają się na CELACH BIZNESOWYCH.

 

Wymagania użytkowników (ang. stakeholders requirements)– określają możliwe do osiągnięcia cele lub zadania, które będą musieli realizować użytkownicy za pomocą produktu. Do sposobów przedstawienia wymagań użytkowników można zaliczyć przypadki użycia, opowieści użytkowników oraz tabele zdarzenie-reakcja. Wymagania te opisują CO użytkownicy będą mogli zrobić za pomocą systemu.

 

Wymagania rozwiązania/systemu (ang. solution requirements) – opisujące funkcjonalności rozwiązania niezbędne do spełnienia wymagań biznesowych. Dzielą się na wymagania funkcjonalne i niefunkcjonalne (jakościowe).

• Wymagania funkcjonalne (ang. functional requirements)- opisują funkcje (zachowanie) produktu, czyli definiują “co robi produkt”. Opisują CO programiści powinni zaimplementować, by użytkownicy (=biznes) mogli wykonywać swoje obowiązki (czyli spełnić wymagania użytkowników). Wymagania te są opisywane przez analityka biznesowego w specyfikacji wymagań oprogramowania SRS (ang. software requirements specification), która powinna w możliwie pełny sposób opisywać spodziewane zachowania systemu.
• Wymagania niefunkcjonalne (ang. non-functional requirements)– opisują atrybuty niefunkcjonalne produktu, zwane często celami lub atrybutami jakościowymi. Wyjaśniają, JAK produkt ma realizować swoje funkcje.

 

Wymagania przejścia (ang. transition requirements)- precyzują jakie warunki muszą być spełnione by umożliwić przejście od stanu obecnego do przyszłego. Omawiają procedury przejścia ze starego systemu na nowy, w tym migracji i konwersji danych, konfiguracji bezpieczeństwa, niezbędnych szkoleń itd. Są o tyle nietypowe, że cechuje je tymczasowość.

 

Atrybuty wymagań

Opis to zwykle za mało, by dokładnie zrozumieć wymaganie. Opis nie daje informacji o autorze, statusie, złożoności, znaczeniu dla biznesu. W tym celu do wymagania dodaje się atrybuty, umożliwiające zarządzanie wymaganiami oraz dające dodatkowe informacje o nich.

Najczęściej spotykany (cytując z książki K. Zmitrowicz – minimalny!)  zestaw atrybutów wymagań powinien zawierać:

• Identyfikator – numer jednoznacznie identyfikujący wymaganie
• Priorytet – znaczenie biznesowe wymagania, określone przez klienta. Najczęściej określa się je w skali: wysoki, średni, niski. Uwaga: jeśli dane wymaganie ma różny priorytet dla różnych klas interesariuszy, powinni oni ustalić wspólny priorytet drogą negocjacji.
• Krytyczność – atrybut określający jak ważne jest dane wymaganie dla sukcesu produktu jako całości. Mimo, że pozornie ten atrybut jest bardzo podobny do “priorytetu”, opisuje jednak inne aspekty wymagania i tak wymaganie o wysokim priorytecie może mieć niski znaczenie dla funkcjonowania dla systemu (i odwrotnie).
• Wykonalność – określana na podstawie dostępności gotowych komponentów niezbędnych do implementacji wymagania. Analiza wykonalności często obejmuje też określenie ryzyka zwiżanego z danym wymaganiem.
• Ryzyko – warto oceniać wymagania pod względem potencjalnego ryzyka, związanego np. Ze stratami finansowymi, wpływem na środowisko, bezpieczeństwem danych osobowych, zgodności ze standardami itd..
• Źródło – określa pochodzenie danego wymagania. Przeważnie większość wymagań pochodzi od zamawiającego(klienta), ale są także wymagania wynikające z przepisów prawa, czy wymagań technicznych. Określenie “właściciela” wymagania zdecydowanie ułatwia późniejsze zarządzanie nim – w tym doprecyzowywanie czy modyfikacje.
• Status – określa etap cyklu życia wymagania. Dzięki temu można szybko sprawdzić, czy wymaganie jest zatwierdzone, czy jest na etapie doprecyzowania czy na przykład zostało odrzucone.

Ważne – wymagań nie należy usuwać z dokumentacji, gdyż zaciemnia to obraz całości i może zaburzyć rozumienie tworzonego dokumentu. Zdecydowanie lepiej jest nadać status “odrzucony” wymaganiu, które było planowane ale z jakiś przyczyn w późniejszym terminie zostało zaniechane.

• Planowana iteracja realizacji – wstępnie i zgrubnie określony czas, w którym planowana jest realizacja danego wymagania. (ps: Temat planowania i harmonogramowania projektu jest tak rozległy, że zdecydowanie wykracza poza niniejszy artykuł i wymaga oddzielnego wpisu 😉 )
• Poziom skomplikowania – określenie złożoności wymagania. Pomaga zaplanować prace developerskie (na przykład w kontekście czasu niezbędnego do realizacji danego wymagania) oraz zarządzać ryzykiem związanym z wymaganiami.
• Koszt realizacji – estymacja planowanego kosztu realizacji danego wymagania, służąca najczęściej do wstępnego szacowania kosztu wytwarzania.
• Autor – precyzyjnie określona osoba odpowiadająca za wymaganie (oraz jej opis).
• Właściciel – wskazanie, kto (osoba lub dział) będzie korzystać z implementacji danego wymagania.

 

W części drugiej “wymagań po ludzku” wezmę na warsztat kwestie jakości wymagań, stay tuned!

Bibliografia:

• BABOK v3 
• Inżynieria wymagań w praktyce, K. Zmitrowicz, B. Chrabski, PWN 2015
• Specyfikacja oprogramowania – inżynieria wymagań, K. Wiegers, J. Beatty, Helion 2014
• Analityk systemów, K. Zmitrowicz, PWN 2015
• Inżynieria oprogramowania, zarządzanie wymaganiami, D. Leffingwell, D. Widrig, WNT 2000