Jak napisać dobre wymaganie - część 2
Kontynuujemy temat tworzenia wymagań rozpoczęty w pierwszej części tego artykułu. W tej części opowiem o schematach wymagań, jakich słów i zwrotów nie używać oraz co jeszcze musi zawierać wymaganie, żeby dało się nim zarządzać. Na koniec przedstawię Wam kilka przykładów poprawnych i niepoprawnych wymagań.
Schemat wymagania
Dobrą praktyką przy tworzeniu wymagań jest bazowanie na ustandaryzowanym schemacie. Przykład takiego schematu zaprezentowałem poniżej. Skrajne (wyszarzone) kafelki są opcjonalne i reprezentują bardziej rozbudowany przypadek wymagania. Pozostałe składają się na warianty dobrze napisanych wymagań.
Dla poprawnej interpretacji wymagania kluczowe jest użycie słów “musi” (ang. shall) oraz “powinien” (ang. should). Istnieje kilka konwencji użycia innych słów, natomiast tutaj skupimy się na tych dwóch podstawowych.
Pierwsze z nich zwyczajowo oznacza sztywne wymaganie, którego spełnienie jest obowiązkowe z punktu widzenia realizacji projektu. Drugie reprezentuje pożądaną właściwość lub zdolność systemu, która nie musi zostać spełniona.
Słowa, których unikać
Inną dobrą praktyką jest unikanie pewnych słów i zwrotów, które ze swej natury są niekonkretne, czyli tzw. “słabych zwrotów” (ang. weak phrases). Większość z nich stosujemy potocznie, co powoduje, że naturalnie wplatamy je również w języku pisanym. Wylistowałem poniżej kilka przykładów takich słów i zwrotów, wraz z krótkim komentarzem, dla lepszego zrozumienia problemu:
łatwy, adekwatny, odpowiedni - te słowa nie reprezentują żadnej mierzalnej właściwości lub zdolności systemu, a odnoszą się tylko do subiektywnej oceny.
zdolność, zdolny do - te zwroty są dodatkiem, który nic nie wnosi do treści wymagania, w związku z czym nie powinny być używane. W niepoprawnym wymaganiu moglibyśmy napisać: "System musi posiadać zdolność do liczenia kroków.", a powinniśmy: "System musi liczyć kroki."
maksymalnie, minimalnie, średnio - te części mowy pozornie reprezentują liczebniki, a w praktyce nie dają żadnej konkretnej informacji, którą bylibyśmy w stanie jednoznacznie zinterpretować oraz zweryfikować.
Inne ważne elementy wymagania
Kiedy wiemy już jak powinna wyglądać treść dobrze napisanego wymagania, możemy się zająć pozostałymi ważnymi elementami wymagania. W tym miejscu skupię się na tych, które uważam za najważniejsze. Zaznaczam jednak, że nie jest to wyczerpująca lista. Jeśli ze sposobu pracy zespołu lub z wewnętrznych procesów firmy wynika potrzeba innych parametrów, to można tę listę rozszerzać. Warto jednak zawsze się zastanowić jaka jest tego wartość. Każde kolejne pole, które musimy wypełnić, utrzymywać i modyfikować, zabiera czas i kosztuje.
Unikalny identyfikator
Z założenia, każde wymaganie musi posiadać unikalny identyfikator, który pozwala nam, jak sama nazwa wskazuję, na jego identyfikację, jak i również na tworzenie jednoznacznych wiązań z innymi wymaganiami. Mowa tutaj o wiązaniach do wymagań wyższego i niższego rzędu, które są rodzicami lub dziećmi danego wymagania.
Nadawanie i utrzymywanie unikalnych identyfikatorów, jest jedną z podstawowych funkcji narzędzi do zarządzania wymaganiami. W związku z tym, jeśli zdecydujemy się na chociażby podstawowe narzędzie, to tę kwestię powinniśmy mieć z głowy.
Uzasadnienie
Nieodłączną częścią wymagania jest uzasadnienie. Ja lubię mówić, że:
Wymaganie powstaje dopiero wtedy, gdy ma zdefiniowaną treść oraz uzasadnienie. Sama treść bez uzasadnienia to bezpodstawne twierdzenie.
Nierzadko sformułowanie odpowiedniego uzasadnienia dla wymagania jest porównywalnym wyzwaniem co zdefiniowanie jego treści.
Autor
Ważnym aspektem w przypadku zarządzania wymaganiami jest informacja o autorze i osobach modyfikujących wymagania. Niejednokrotnie zespół projektowy wraca do jakiegoś wymagania zachodząc w głowę, kto stworzył to wymagania i z czego ono wynika. Jest to dodatkowo uciążliwe jeśli uzasadnienie w takowym jest niepełne lub niejasne. W takim przypadku informacja o autorze (zakładając możliwość kontaktu z tą osobą) pozwala zrewidować pierwotne założenia i zastanowić się nad ich sensownością.
Metoda weryfikacji
Inną ważną czynnością przy definiowaniu wymagania jest równoczesne myślenie o sposobie jego weryfikacji. Wymaganie koniecznie musi mieć zdefiniowaną metodę weryfikacją lub metody, jeśli kilka ma w danym przypadku zastosowanie. Na temat samej weryfikacji wymagań napiszę więcej przy innej okazji.
Wymagania w przykładach
Chciałbym zostawić Cię po tej lekturze nie tylko z teorią, ale również z praktyczną wiedzą. Poniżej prezentuję kilka przykładów poprawnych i niepoprawnych wymagań.
Poprawne wymagania
Przykłady poprawnie sformułowanych wymagań:
ID: REQ-001 Treść wymagania: Masa rakiety, w konfiguracji mokrej (z zatankowanym paliwem i utleniaczem), musi być równa lub niższa niż 10 000 kg. Uzasadnienie: Ograniczenie wynika z nośności infrastruktury transportowej na kosmodromie.
ID: REQ-0127 Treść wymagania: Samochód musi umożliwiać kierowcy kontrolę kierunku jazdy. Uzasadnienie: Kluczowe założenie dotyczące funkcji samochodu.
ID: REQ-121 Treść wymagania: Balkon musi wytrzymać obciążenie 4000 N przyłożone pionowo w jego centralnym punkcie Uzasadnienie: Obciążenie wynikające z sumarycznej masy największej liczby osób, które pomieszczą się na balkonie o tej powierzchni, powiększone o współczynnik bezpieczeństwa. Przyjęte wartości: średnia masa dorosłego mężczyzny: 80kg; maksymalna liczba osób na 1m2: 5 (zgodnie z normą …); współczynnik bezpieczeństwa 3 (zgodnie z normą [numer normy]).
Niepoprawne wymagania
Przykłady niepoprawnie sformułowanych wymagań:
ID: REQ-1 Treść wymagania: Masa satelity musi być odpowiednia. Uzasadnienie: Zbyt wysoka masa satelity będzie skutkowała podwyższonymi kosztami wyniesienia na rakiecie.
ID: REQ-X Treść wymagania: Sposób działania podnośnika musi bazować na mechanizmie nożycowym. Uzasadnienie: brak
ID: brak Treść wymagania: Kontroler silnika musi ważyć mniej niż 0.5 kg i musi się mieści w obwiedni 200mm x 300mm x 250mm Uzasadnienie: Ograniczenia narzucone przez projekt obudowy silnika.
