Kolejna książka, tym razem coś w rodzaju podręcznika, zbioru metod. Jest to praca zbiorowa. Polecam wszystkim osobom, których rolą jest między innymi dokumentowanie architektury systemów IT. Wiele przykładów opartych o UML, SysML oraz planowany do upowszechnienia AADL (Architecture Analysis and Design Language). Ten ostatni jest w sferze planów, zobaczymy… (more…)

Niedawno mój serdeczny kolega napisał:

Samo zebranie wymagań to ważny etap. Schody zaczynają się jednak dalej. Trzeba zweryfikować pozyskane wymagania, uszczegółowić, nadać priorytety. Gdzie te schody? […] Nie mamy w Polsce standardu dokumentowania projektów. Czegoś na co można się powołać. (Inżynieria wymagań ? certyfikat | Michał Wolski).

jak to mówią “święte słowa”. Jednak mamy standard dokumentowania wymagań, który można wykorzystać. Jaki? Moje początkowe opory do stosowania “kolejnej notacji” były jednak chyba przesadzone. SysML to obiektowe (w sensie paradygmatu) rozszerzenie UML. Pomijając kwestie samej notacji, jeden z jej diagramów, diagram wymagań, pozwala na uporządkowanie “listy wymagań”. To jednak mała zaleta. Dużą zaletą jest spójność pojęciowa z metodami obiektowymi, ale może dosyć “trudnych terminów”.

Wymagania  to hierarchiczna lista “oczekiwań wobec potrzebnego rozwiązania”. Zobrazowanie listy wymagań na diagramie pomaga pokazać wzajemne związki pomiędzy wymaganiami oraz związki wymagań z następnymi elementami projektu takimi jak testy odbiorcze i elementy modelu opisujące realizacje tych wymagań:

Powyższy diagram pozwala po pierwsze “zobaczyć” wymagania, po drugie pokazuje związki tych wymagań z produktami kolejnych kroków projektu. Po co? Przede wszystkim sprawdzimy, że te związki są, że są spójne i kompletne (nie brakuje żadnego). Zapewne wielu z Was woli postać tabeli:

i słusznie, do czytania jak najbardziej ale ta tabela, gdyby powstała jako jedyna, nie pozwoli na weryfikację kompletności implementacji wymagań i testów.

Cechy wymagań to bardzo  ważne elementy zarządzania wymaganiami, zalecam stosowanie:

1. Priorytet:
   1. najwyższy (np. 3.) – niespełnienie tego wymagania czyni rozwiązanie całkowicie nieprzydatnym do celu w jakim powstaje
   2. średni (np. 2.) – niespełnienie tego wymagania powoduje ograniczenie przydatności rozwiązania
   3. niski (np. 1.) – niespełnienie tego wymagania pogorszy jakość korzystania z rozwiązania
2. Status:
   1. Zgłoszone
   2. Uznane
   3. Odrzucone (ale nie usunięte)
3. Źródło:
   1. analiza (dokumentów, procesów, inne samodzielne efekty pracy analityka)
   2. osoba (konkretne źródło informacji po stronie analizowanej organizacji)
4. Rodzaj (te na różnych etapach):
   1. biznesowe
   2. wobec rozwiązania
      1. funkcjonalne
      2. jakościowe
      3. dziedzinowe

(więcej o klasyfikacji wymagań)

Mamy IEEE 830-1998, który opisuje dokumentowanie wymagań. Często się mówi, że wymagania mają być FURPS i SMART ale jak to osiągnąć? Pomaga w tym nie rysunek a model, czyli nie tylko zobrazowanie ale także interpretowanie.

Osobna kwestią jest to jak pozyskujemy wymagania. Mogą to być wywiady, sesje JAD itp. Ja osobiście jestem zwolennikiem analiz dokumentów, a potem wyjaśniam je i ich role  z wykonawcami procesów, ale o tym już było (i nie raz pewnie będzie ;)).

Na koniec ważna rzecz: nie wolno utracić panowania nad szczegółami, których nie powinno być zbyt wiele…

Gdyby ktoś zapytał: a po co kolejny diagram, odpowiem: model to system obiektów, ich powiązań i cech. Ani tabela ani tym bardziej ilustrowany obrazkami tekst nam tego nie da, a bez tych powiązań nie sprawdzimy ani kompletności wymagań ani tego czy ich implementacja jest spójna.

Aha, ile tych diagramów ma być? Nie za wiele, ale muszą być dobre? jak książeczka do gry w szachy a do niej opis czego oczekujemy od naszych szachistów? (Ile tego ma być ? analiza i model procesów biznesowych).