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:
- Priorytet:
- najwyższy (np. 3.) – niespełnienie tego wymagania czyni rozwiązanie całkowicie nieprzydatnym do celu w jakim powstaje
- średni (np. 2.) – niespełnienie tego wymagania powoduje ograniczenie przydatności rozwiązania
- niski (np. 1.) – niespełnienie tego wymagania pogorszy jakość korzystania z rozwiązania
- Status:
- Zgłoszone
- Uznane
- Odrzucone (ale nie usunięte)
- Źródło:
- analiza (dokumentów, procesów, inne samodzielne efekty pracy analityka)
- osoba (konkretne źródło informacji po stronie analizowanej organizacji)
- Rodzaj (te na różnych etapach):
- biznesowe
- wobec rozwiązania
- funkcjonalne
- jakościowe
- 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).
“Moje początkowe opory do stosowania” bardzo słuszne opory 🙂
Jak zawsze zapytam: po co ? 🙂
Jeśli te diagramy robi klient to ok., a jak nie to jest to bez sensu.
Tabelka z kilkoma kolumnami np. id, priorytet i opis; świetnie daje sobie radę. I tu widzę jedynie pole do popisu dla telepatii 🙂
problem w większych projektach to szybkie (automatyczne) sprawdzenie “pokrycia” wymaganiami zakresu projektu, a wymagania maja SMART wiec nie jest to proste, już gdy wymagań jest kilkanaście, ręczne “sprawdzanie” pokrycia wymaganiami staje problemem podobnym do ręcznego sprawdzania literówek w dużym tekście. Nie ma sensu robienie takich diagramów tylko po to by powstały, maja one głęboki sens gdy modele (a nie obrazki) powstają w systemie typu CASE i kontrola spójności, poprawności itp. jest wykonywana automatycznie.
Oczywiście, że taki dokument powstaje (ma to sens) po stronie zamawiającego, bo to na zamawiającym spoczywa “jakość wymagań”.
Jedno pytanie: dokumentacja wymagań czy dokumentacja projektu? Autor w cytowanym artykule wskazje o potrzebie dokumentacji wymagań, ich analizy, nadania priorytetów, a potem wspomina o tym, że nie ma standardu dokumentacji projektu… Problemy, o których pisze autor pasują bardziej do rozpatrzenia w dokumentacji projektowej (podział prac, kolejność działań, harmonogram, cel projektu). W dokumentacji projektowej można ustalić w jaki sposób będą zapisane wymagania, a do tego można już wykorzystać wiele różnych sposobów i metod.
Faktem jest, że Michał chyba przemieszał byt jakim jest specyfikacja wymagań z bytem jakim jest dokumentacja projektu analizy wymagań, kontekst ‘braku standardy” odebrałem dosłownie do wymagań. Inna sprawa, że nie spotkałem się nie tylko “w Polsce” z tezą, że “standardowy” proces “zbierania wymagań” nie istnieje, jest to często określane jako “gap” pomiędzy analizą biznesową a projektem lub “wymaganiami”. Wiele metodyk inżynierii oprogramowania (w tym RUP) opisuje proces od wymagań do powstania kodu jednak nie opisuje “skąd są wymagania”. W każdym razie skutecznej recepty nie ma.
A.”ręczne ?sprawdzanie? pokrycia wymaganiami staje problemem podobnym do ręcznego sprawdzania literówek w dużym tekście.”
Autentycznie, nie wyobrażam sobie automatycznego sprawdzania pokrycia wymagań w dostarczonym produkcie:) Jedyne co mi przychodzi do głowy to wczesne budowanie automatycznych testów, które będą wspólnie zarządzane przez klienta.
Czy mógłby Pan przesłać np. jakiś link z większą informacją na temat takich narzędzi?
B.”…proces ?zbierania wymagań? nie istnieje, jest to często określane jako ?gap? pomiędzy analizą biznesową a projektem lub ?wymaganiami?.”
A czyż analiza biznesowa nie powinna dostarczyć zestawu wymagań – oczywiście na poziomie biznesowym? Wraz z dokładnymi parametrami/współczynnikami jakie powinniśmy osiągnąć po wdrożeniu danego projektu.
Np. Podczas analizy biznesowej procesu fakturowania wychodzi, że dziennie będziemy przetwarzać 1000 faktur. I mamy wymaganie.
Analiza biznesowa oczywiście powinna dostarczyć “zestaw wymagań”, problem w tym, że wymaganie “system ma pozwalać na wystawianie faktur” można zrealizować na nieskończenie wiele sposobów, developer startując w przetargu, do takiego wymagania wybierze najtańszy, czyli z reguły najgorszy, sposób implementacji. W wielu dziedzinach inżynierii już dawno to zauważono, dlatego developerowi nie daje się “wymagań” do realizacji a “projekt”.
Co do sprawdzania w narzędziach CASE pokrycia np. wymagań itp. to jest to funkcja śladowania, która potrafi sprawdzić ścieżkę od czynności i danych w modelu procesu do niemalże każdej klasy implementującej każde wymaganie, niestety nie mogą to być “obrazki” w wordzie a muszą to być modele w narzędziu klasy CASE. Ja używam http://www.visual-paradigm.com/solution/. Na powyższym diagramie, jako przykład pokazałem skojarzenie wymagania z konkretną klasą dziedzinową.
Co do testów, widywałem systemy, które przeszły testy automatyczne a nie przechodziły testów odbiorczych z użytkownikiem, dlatego mam do nich ograniczone zaufanie. W projektach programistycznych bardzo kiepsko jest, gdy jedynym “dokumentem” opisującym oprogramowanie jest jego kod bo to znaczy, że programiści siadający do kodowania zaczynają po prostu od zera czyli od “na początek nie wiem nic”… bo czym jest dla programisty wymaganie: “system ma pomagać wystawiać faktury VAT”????
Korzystam z SysML-a do modelowania wymagań już od dłuższego czasu. Doświadczenia mam różne, ale z przewagą pozytywnych. Z pewnością wprowadzanie relacji pomiędzy wymaganiami ułatwia ich rozbijanie na mniejsze, niezależne, nadające się choćby do testów elementy np. automatycznych. Wymagania biznesowe często mają postać zapisów, w których spisano wiele oczekiwań od rozwiązania – SysML ułatwia analitykowi zapanowanie na takimi zapisami, pokazując wizualnie hierarchię identyfikowanych wymagań systemowych oraz zależności pomiędzy nimi.
Jeśli chodzi o pokazywanie takich SysML-owych diagramów osobom, które definiowały wymagania biznesowe, czy choćby deweloperom, to tutaj nie mam dobrych doświadczeń. Większość nie analizowała diagramów przechodząc od razu do treści wymagań. W sumie to doszedłem do wniosku, że diagramy SysML dla wymagań są narzędziem, które wspiera głównie pracę analityka i to on czerpie z niego największe korzyści.
Oczywiście używanie tej notacji do modelowania wymagań wymaga wiele uwagi i konsekwencji, ponieważ nie wiele zyskamy z analizy pokrycia wymagań np. przypadkami użycia, testami czy też innymi elementami, jeżeli nie będziemy konsekwentnie śladowali zdefiniowanych wymagań na elementy projektu.
Co do narzędzi CASE również polecam Visual Paradigm.
“W sumie to doszedłem do wniosku, że diagramy SysML dla wymagań są narzędziem, które wspiera głównie pracę analityka i to on czerpie z niego największe korzyści.” – i pozostaje mi się tym zgodzić :), ale też (ja także) utwierdzam się w przekonaniu, że mało kogo interesuje przebieg analizy, klientów interesują produkty analiz, a te są pisane ostatecznie “ich językiem” w postaci “raportu z analizy” i chyba tak powinno być. Od dłuższego czasu moje raporty to kilkadziesiąt stron “wordem” z obrazkami i komplet diagramów z opisami jako załącznik. CASE jako narzędzie powala jednak uzyskać wysokiej jakości, spójne, przetestowane modele i specyfikacje, daleko lepsze i bezpieczniejsze niż produkty sesji JAD, wywiadów, ankiet czy burz mózgów…
Dziękuję za fajne opracowanie tematu.