Niech się coś drukuje…
Zasłyszane w jednej z firm:
Programiści dostali specyfikację, w której jedno z wymagań było opisane szkicem ekranu z przyciskiem "Drukuj". Dociekliwy programista zaczął się zastanawiać, co ma przez to rozumieć? Drukowanie na drukarce? Drukowanie do pliku tekstowego? Może do PDF'a? Jakiś wzorzec ma być wybrany? I najważniejsze: co w zasadzie ma być wydrukowane? Na szczęście programista okazał się proaktywny, sięgnął po słuchawkę i zadzwonił do analityka odpowiedzialnego za to wymagania. Mniej więcej tak wyglądała ta rozmowa:
- Ja w sprawie wymagania ABC123.
- Słucham, w czym problem?
- Zastanawiam się, co, w jaki sposób i na czym ma być wydrukowane. Niestety z zapisanego wymagania to nie wynika.
- Hmmm...no niech się coś po prostu tam drukuje.
Czy tylko mi ręce opadają?
Co musisz wiedzieć o planowaniu etapu zbierania wymagań?
Oto zbiór pięciu praktyk podanych przez firmę IAG, które pomogą Wam lepiej zaplanować zbieranie wymagań w Twoim kolejnym projekcie:
1. Zasoby projektu:
- Opisz wszystkich udziałowców projektu oraz uczestników procesu zbierania wymagań.
- Każdemu wymienionemu uczestnikowi przypis odpowiednią rolę oraz odpowiedzialność.
2. Strategia dla każdej czynności:
- Wskaż najlepsze podejście do każdej fazy zbierania wymagań.
- Wskaż narzędzia, z których będziesz korzystał.
- Zdefiniuj standardy oraz metryki z których będziesz korzystał.
3. Komunikacja:
- Opisz w jaki sposób będzie prowadzona komunikacja z wszystkimi uczestnikami projektu, w szczególności z klientem, architektem oraz kierownictwem projektu.
4. Plan pracy:
- Zdefiniuj szczegółowy plan pracy.
- Przygotuj się do dokumentowania czasu, jaki będzie wykorzystywany w czasie sesji zbierania wymagań (może się przydać, gdy będziesz przeprowadzał takie spotkania w kolejnych projektach).
5. Strategia podziału pracy:
- Zdefiniuj i opisz podejście do podziału pracy oraz przydziału zadań do poszczególnych osób w przypadku, gdy więcej niż jeden analityk bierze udział w projekcie.
Skąd się wzięły przypadki użycia?
Na swoim blogu Ivar Jacobson pisze o tym skąd się wziął pomysł na zapisywanie wymagań za pomocą przypadków użycia. Jacobson pisze:
"In 1986, Use Case was the solution to the problem that traditional functional specifications were immense and not testable. To start from the users and find their different use cases made the specifications understandable, while we also at the same time found the test cases. The result was a good way to do test-driven development, now being popular in agile teams."
Polecam zresztą cały najnowszy post Jacobsona, w którym pisze o tym, że problem jest ważniejszy niż samo rozwiązanie (o czym wspominałem wcześniej tutaj).
A najczęściej używana notacja to…
Patrząc przez ramię
Ile razy zastanawialiście się, w jaki sposób modelować Wasze wymagania? Która notacja będzie najlepsza? Który sposób modelowania powinienem\am wybrać? Ile razy zaglądaliście przez ramię koleżanki lub kolegi, żeby zobaczyć jak oni to robią? Czy nie fajnie by było spojrzeć przez ramię prawie 200 innych analityków i zobaczyć, z czego oni korzystają w swojej pracy z wymaganiami?
Ale jak to zrobić?
Na szczęście panowie Colin J. Neill oraz Phillip A. Laplante z Penn State University postanowili dowiedzieć się czegoś więcej na temat najczęściej stosowanych praktyk inżynierii wymagań. Stworzyli internetową ankietę, która składała się z 22 pytań i zaprosili do jej wypełnienia prawie 2000 osób (głównie absolwentów PennState University). Odpowiedzi udzieliły 194 osoby (m.in. z takich firm jak SAP, Boeing, Dupont, Simens Medical Systems) i odpowiedzi te były podstawą artykułu "Requirements Engineering: The State of the Practice", który ukazał się w 2003 roku.
A zwycięzcą jest...
Jako, że cały dokument jest dostępny tutaj, to nie będę rozwodził się nad poszczególnymi wnioskami, tylko przedstawię najciekawsze (moim zdaniem) wyniki, i tak:
- 60% osób biorących udział w ankiecie stosowało w jakimś stopniu prototypowanie.
- 35% respondentów powiedziało, że wykorzystują podejście kaskadowe.
- W projektach, które trwały dłużej niż dwa lata najpopularniejsze było podejście iteracyjne.
- 33% osób stwierdziło, że nie korzystają z żadnej metodologii
- 51% respondentów powiedziało, że stosują nieformalne sposoby zapisu wymagań, 27% sposoby półformalne, a 7% stosują notacje formalne.
- W 59% przypadków stosuje się inspekcje, jako sposób na podniesienie jakości wymagań.
- 52% osób stwierdziło, że w ich firmach za mało uwagi poświęca się na inżynierię wymagań.
- Ponad 50% osób wykorzystuje przypadki użycia i/lub scenariusze do zapisu wymagań.
Tak wyglądają wyniki badań po drugiej stronie oceanu, ciekaw jestem jak to wyglądałoby u nas? Bylibyście zainteresowani wzięciem udziału w takim badaniu? Dajcie znać w komentarzach lub mailowo.
Śledzenie wymagań
We wpisie Jaki powinien być Twój SRS? napisałem, że jedną z cech poprawnego dokumentu wymagań jest "łatwość śledzenia (ang. traceability)". Nie dla wszystkich z Was może być jasne, o co w tym wyrażeniu chodzi, więc spieszę z wyjaśnieniem.
SRS jest łatwy do śledzenia jeśli pochodzenie każdego wymagania jest jasne i oraz jeśli dokument ułatwia odwoływanie się do poszczególnych wymagań podczas jego edycji. Trzeba pamiętać, o tym, że mamy:
- łatwość śledzenia wstecz - jasne wskazanie na źródło wymagania;
- łatwość śledzenia wprzód - każde wymaganie powinno mieć unikalną nazwę oraz identyfikator, aby łatwo można się było do niego odwołać.
W kontekście tego, dobrze jest przypomnieć sobie wpis nie podmieniaj!
Jaki powinien być Twój SRS?
Twój SRS powinien być (*):
- Poprawny
- Jednoznaczny
- Kompletny
- Spójny
- Uporządkowany według ważności i/lub stabilności wymagań
- Weryfikowalny
- Modyfikowalny
- Łatwy do śledzenia (ang. traceable) [zna ktoś może lepsze tłumaczenie?]
Czy możesz szczerze powiedzieć, że Twój ostatni SRS miał wszystkie powyższe cechy?
(*) Na podstawie standardu IEEE 830-1998.
Walidacja czy weryfikacja?
W kontekście sprawdzania jakości wymagań często mówi się o weryfikacji oraz o walidacji. Co oznaczają te dwa pojęcia? Znaczą one to samo, czy może coś innego?
Walidacja pozwala nam sprawdzić, czy oprogramowania jest zgodne z tym czego oczekuje klient; pozwala nam odpowiedzieć na pytanie "czy budujemy dobre oprogramowanie?".
Weryfikacja pozwala nam stwierdzić, czy budowane oprogramowanie zgodne jest z zebranymi przez nad wymaganiami; pozwala nam odpowiedzieć na pytanie "czy dobrze budujemy oprogramowanie?".
Jako przykład możemy wziąć sobie proste okienko logowania. W takim wypadku możemy wykorzystać weryfikację, aby sprawdzić, czy okienko przyjmuje dobre dane i czy wyświetla odpowiedni komunikat o błędzie. Walidacja natomiast każe nam się zastanowić, czy to okno logowania jest nam w ogóle potrzebne? czy spełnia ono jakiś konkretny cel klienta?
Requirements Interchange Format (RIF)
Podczas konferencji "Requirements Engineering 2009", o której pisałem w zeszłym tygodniu miałem okazję wysłuchać prezentacji na temat ciekawego formatu wymiany/przenoszenia wymagań. Format ten nazywany jest RIF (Requirements Interchange Format), powstał 2004 i od tamtego czasu jest aktywnie rozwijany i wykorzystywany, szczególnie przez firmy motoryzacyjne oraz medyczne. Skąd wzięła się potrzeba stworzenia takiego formatu? Okazuje się, że często firmy mają sporą liczbę podwykonawców, z których każdy dysponuje innymi narzędziami do zarządzania wymaganiami. Problemem jest tworzenie, przesyłanie oraz modyfikacja wymagań w takim środowisku. Stąd też pomysł na format, który bazowałby na XML'u i który pozwalałby w łatwy sposób przenosić wymagania między różnymi narzędziami, co pozwoliłoby zmniejszyć nakłady czasowego oraz finansowe na zarządzanie wymaganiami. Co ważne RIF'em zainteresowała się OMG, więc jest szansa, że wkrótce format ten stanie się standardem firmowanym właśnie przez OMG.
5 x „C”
Firma IAG na swoim blogu proponuje zasadę pięciu "C", która pozwala zadbać o wysoką jakość wymagań. Oto one:
- Wyrażaj się jasno (be Clear)
- prowadź dyskusje w logiczny sposób
- używaj prostych słów
- unikaj eufemizmów
- używaj stwierdzeń pozytywnych
- sprawdzaj, czy każdy punkt jest wystarczająco jasny i kompletny (w izolacji od pozostałej treści)
- Bądź spójny (be Concise)
- twórz prostą specyfikację
- korzystaj w wypunktowań
- wykorzystuj słowa, których używasz na co dzień
- używaj raczej określeń szczegółowych niż wyrażeń ogólnych
- unikaj powtarzania treści
- Bądź konkretny (be Concrete)
- wykorzystuj przykłady oraz scenariusze
- unikaj jargonu
- miej zawsze jasne przesłanki
- miej zawsze jasno określony cel
- unikaj mylących złożonych stwierdzeń
- unikaj stwierdzeń negatywnych
- Bądź kompletny (be Complete)
- używaj list kontrolnych oraz technik walidacji
- dokumentuj wszystkie możliwe wyjątki, warunki oraz odpowiedzi
- szukaj opisów operacji bez jasno i w pełni określonych wyników
- szukaj opisów operacji bez określonych dla nich zdarzeń
- specyfikuj wszystkie elementy danych
- Bądź konsekwentny (be Consistent)
- nie używaj wielu określeń dla tej samej rzeczy
- korzystaj z tych samych stylów i czcionek w całym dokumencie
Trzeci rozdział „Requirements by Collaboration”
Trzeci rozdział książki "Requirements by Collaboration: Workshops for Defining Needs", którą obecnie czytam przynosi nam zbiór składników, które powinny być częścią każdego dobrego warsztatu wymagań. Oto one:
- Wspólny cel. Zadbaj, aby każdy z uczestników rozumiał cel każdego ze spotkań warsztatowych. Zawsze zaczynaj mając na względzie końcowy efekt, jaki chcesz osiągnąć poprzez spotkanie.
- Odpowiedni ludzie. Pamiętaj, aby w każdym spotkaniu brali udział przedstawiciele klienta, użytkowników końcowych oraz dostawcy oprogramowania. Każda z tych grup ma inną wiedzę, inne doświadczenia oraz inne cele. Jeśli uda Ci się zebrać ich razem i umożliwisz im efektywną współpracę, to każde spotkanie przyniesie wymierną wartość.
- Współdzielona przestrzeń. Zadbaj o to, żeby wszyscy uczestnicy warsztatów byli zebrani w tym samym pomieszczeniu podczas spotkań. Coraz więcej mówi się o zaletach rozproszonych zespołów, ale jeśli chcesz osiągnąć sukces podczas swoich spotkań, to fizyczna obecność wszystkich osób w jednym pokoju może zdecydowanie pomóc.
- Mądre grupy. Pamiętaj, że jako grupa jesteście w stanie wymyślić więcej niż każdy z was z osobna.
- Praca wstępna. Staraj się, żeby każdy z uczestników spotkania miał do zrobienia pewną pracę wstępną, którą będzie się mógł podzielić podczas spotkania. Dzięki temu przyspieszy to spotkanie i wymusi na każdym uczestniku odpowiednie przygotowanie się oraz przemyślenie celu spotkania.
- Dobre pytania. Odpowiednie pytania są kluczem do dobrej komunikacji podczas warsztatów. Pamiętaj o tym!
- "Poważna" gra. Jeśli jest to możliwe, to pozwól uczestnikom na "zabawę" podczas spotkań. Niech puszczą wodze wyobraźni, niech mimo powagi spotkania poczują się swobodnie.
- Zaufanie. Zaufanie jakim darzą się uczestnicy spotkania pozwala oszczędzić czas, zwiększa jakość oraz efektywność spotkań, a także pozwala szybciej podnieść się po ewentualnych porażkach lub chwilowych problemach.
- Zróżnicowanie procesów. Podczas spotkań staraj się korzystać z różnych technik aby podtrzymać innowacyjność oraz motywację grupy. Niech czasem pracują indywidualnie, czasem w parach, a czasem w małych grupach. Czasami ty zadawaj pytania, a czasem niech oni zastanowią się nad dobrymi pytaniami. Czasem niech coś tworzą, a czasem niech sprawdzają prace innych.
- Testowanie efektów końcowych. Zawsze musisz wiedzieć, kiedy osiągnąłeś zadowalające Cię efekty. Jeśli chcesz na przykład, żeby efektem były diagramy przypadków użycia, to musisz wiedzieć wcześniej jaki poziom szczegółowości Cię zadowoli i do takiego poziomu będziesz dążył podczas spotkania.
- Wspólne decyzje. Staraj się tak prowadzić spotkanie, aby decyzje podejmowała cała grupa, a nie jedynie osoby ze szczebla kierowniczego.
- Elastyczna struktura. Każde spotkanie powinno być odpowiednio przemyślane i zaplanowane, ale nigdy nie wiadomo co wydarzy się podczas warsztatu, więc musisz zawsze być przygotowany na ewentualne zmiany, które będzie trzeba wprowadzić.
- Korzystanie z obu półkul mózgowych. Jeśli uda Ci się pobudzić obie półkule mózgowe uczestników zespołu, to z pewnością takie spotkanie przyniesie lepsze efekty a także będzie bardziej satysfakcjonujące dla całej grupy.
- Częste omówienia. Staraj się w miarę często podsumowywać pracę. Niech uczestnicy sprawdzają siebie nawzajem, pozwól również na wzajemną konstruktywną krytykę.