W projekcie każdy ma swoje ważne zadanie, w którym musi dać z siebie wszystko. Na końcu czeka osoba, która potrzebuje efektów Twojej pracy. Czy, jako analitycy przygotowujący wymagania, możemy z czystym sercem przekazać wymagania? Trzeba zapewnić, że są odpowiedniej jakości, czyli poddać je procesowi weryfikacji.
W świecie programistów znany jest motyw żółtej kaczuszki. Pluszowe lub nadające się do kąpieli, stoją często na biurkach, gotowe do użycia. Tłumaczenie kaczce, co właśnie się programuje, pomaga spojrzeć na własną pracę z innej perspektywy, wypowiedzieć myśli na głos i często znaleźć błędy, które pozostawały niezauważone. W rolę kaczki mogą się też wcielać koledzy z zespołu. Zapewnianiu jakości pomagają też przeglądy kodu przez bardziej doświadczone lub dedykowane do tego zadania osoby, pilnujące właściwej formy, trzymania się ustalonych w zespole reguł.
Analitykom nie mniej potrzebna jest żółta kaczuszka i przeglądy. Także w tym przypadku potrzebne są inne osoby. Oczywiście nikt nie wykona przeglądu wymagań lepiej, niż ci, na których głowy spadną później ewentualne wynikające z nich niedociągnięcia.
- Architekci – wykrywają niespójności i problemy z wykonalnością na poziomie struktury systemu,
- Programiści – przeglądają wymagania skrupulatnie, ponieważ na nich spadnie ostateczny ciężar przygotowania oprogramowania spełniającego wymagania i wybronienia go przed dociekliwymi testerami,
- Testerzy – wyłapują braki wszelkich informacji, które będą utrudniać testowanie, takie jak np. nie- dookreślone formaty, zakresy danych, zależności,
- Analitycy – oczywiście nikt bardziej skrupulatnie nie będzie pilnował formy zapisu wymagań i wszystkich charakterystyk, jakimi dobre wymaganie powinno się odznaczać.
Wymagania odnośnie wymagań, czyli co mamy sprawdzać
Znamy szereg wymagań do wymagań, tj. jakie powinny być, aby były dobrej jakości (wg BABOK Guide 2.0):
- Kompletne,
- Spójne,
- Poprawne,
- Wykonalne,
- Modyfikowalne,
- Jednoznaczne,
- Testowalne.
Poniżej kilka pomysłów, jak jako analitycy możemy sprawdzić spełnienie tych wymagań jakościowych przez nasze wymagania.
Kompletność
Sprawdzenie kompletności polega na zweryfikowaniu, czy w zakresie są wszystkie istotne wymagania. Możemy to sprawdzić za pomocą odniesienia ich do celu projektu – czy zbiór wymagań pozwala na osiągnięcie celu? Odwołując się do procesów biznesowych wery kujemy czy czynności, które chcemy zautomatyzować zostały pokryte wymaganiami. Kolejnym pomysłem jest wykonanie przeglądu wymagań zgłoszonych przez różnych udziałowców (czy te, które miały wejść do zakresu zostały uwzględnione).
Każde wymaganie z osobna także powinno być kompletne. Dlatego w jego zakresie zwracamy uwagę na przewidzenie wszystkich możliwości. W przypadku opisu przypadków użycia będzie to przemyślenie wszystkich kroków, przewidzenie przebiegów alternatywnych czy sytuacji wyjątkowych, a także efektów końcowych. Do tego zadanie bardzo pomocny okazuje się diagram aktywności, na którym łatwiej dostrzec jest możliwości alternatywne do podstawowego przebiegu. Przy każdym kroku pytamy „A co jeśli…” i tworzymy diagram rozgałęziony na tyle, ile opcji należy wziąć pod uwagę. Wyniki końcowe także powin- ny uwzględniać wszystkie możliwe warianty.
Przy opisywaniu możliwych stanów obiektu biznesowego i działań wprowadzających zmiany w tych stanach, nieodłączne staje się po prostu narysowanie diagramu stanów. To niesamowi- cie proste rozwiązanie na problemy z ewidencją statusów i uchwycenia wszystkich przejść między nimi. Połączenie na diagramie jest, lub go nie ma, więc analiza kompletności staje się prosta.
Modelując procesy czy przepływy aktywności, warto sprawdzić, czy zawarliśmy wszystkie opcje – np. co się stanie, jeśli nie znaleziono żadnego, znaleziono jeden lub więcej niż jeden obiekt, itd.
Weryfikacja kompletności diagramów UML będzie polegała na sprawdzeniu, czy zostały uwzględnione:
- Nazwy elementów,
- Połączenia między elementami,
- Typy połączeń (strzałka o odpowiednim znaczeniu),
- Liczności relacji,
• Inne elementy wymagane przez diagram danego typu.
Z kolei analizując kompletność diagramów w UML za pomocą innych diagramów w UML, możemy posłużyć się następującymi zależnościami:
- Diagram stanów,
- Diagram sekwencji,
- Diagram komunikacji,
- Diagram stanów.
Spójność
Badając spójność sprawdzamy, czy różne wymagania nie opisują tego samego, czy któreś nie są sprzeczne między sobą oraz czy poziom szczegółowości jest we wszystkich taki sam. Na część z tych wyzwań odpowiedzią będzie dobra pamięć i zdrowy rozsądek. Na problem opisywania tego samego wymagania innymi słowami być może pomoże wbudowany w narzędzia CASE słownik pojęć. Jeśli dodawać ważne pojęcia do słownika oraz nimi zarządzać, znacznie łatwiej będzie wykryć niespójność. Używanie słowników w języku polskim jest o tyle ciekawe, że każdy wyraz trzeba odmienić przez liczby i przypadki. Wymaganie, wymagania, wymaganiu, wymaganiem, wymagań, wymaganiom, wymaganiami, wymaganiach. Ale kiedy się już człowiek przemęczy, efekt jest ciekawy – śledzone jest każde wystąpienie w całym modelu.
Wykonalność
Wykonalności nikt nie zbada tak żarliwie jak programiści i architekci znający ograniczenia projektu. Tudzież wtajemniczony lider zespołu czy kierownik projektu. Przy wymaganiach jakościowych pomocni będą administratorzy systemowi. Zweryfikują oni czy wymaganie jest możliwe do spełnienia przy istniejącej infrastrukturze, budżecie, czasie i dostępnych zasobach.
Modyfikowalność
Mody kowalność kontrolujemy poprzez analizę grupowania wymagań. Jeśli wymagania pozostające w ścisłym związku ze sobą są blisko, logicznie uporządkowane, wprowadzanie zmian będzie znacznie prostsze.
Jednoznaczność
Przy badaniu jednoznaczności, niezastąpieni są testerzy, programiści, puryści językowi i wszyscy czepialscy dla zasady. Daj wymagania do weryfikacji największym malkontentom i złośnikom. Jeśli przejdą przez ich sito, będą jak perełki.
Szczególną uwagę warto zwrócić na ujednolicenie nazewnictwa. Często projekty powstają na styku kilku różnych grup interesariuszy – zamawiającego, odbierającego, użytkowników, dostawców, itd. Każde z pojęć powinno być jednoznacznie zinterpretowane przez wszystkich interesariuszy, dlatego tak ważne są wspólne i dostępne definicje.
Abstrakcyjne, ogólne zasady mogą być niekiedy trudne do zrozumienia. Podanie przykładu może rozwiać wątpliwości i umożliwić zrozumienie zasady we właściwy sposób.
Testowalność
Bez dwóch zdań, mistrzami w wery kacji testowalności będą testerzy. To oni najlepiej ocenią, czy na podstawie przedstawionego wymagania są w stanie przygotować sprawdzający je test. Przebywanie z nimi powoduje, że analityk z czasem również wytwarza w sobie małego testera, który siedząc z tyłu głowy podszeptuje mu coraz lepsze formy wymagań.
Kiedy i jak weryfikować
Weryfikacja może zacząć się, naturalnie, po przygotowaniu przez analityka porcji wymagań. Najlepiej, jeśli są ze sobą powiązane (cały zakres projektu lub cały pakiet), aby sprawdzić także zależności między wymaganiami. Za efekt odpowie- dzialny jest analityk – może zlecać prace innym, ale to on ostatecznie odpowiada za poprawność modeli czy dokumentacji.
W jaki sposób przygotować się do wykonywania weryfikacji wymagań w organizacji? Proponuję poniższe sposoby.
Gotowa lista rzeczy do weryfikacji
Możemy przygotować gotową listę aspektów, które mogą zostać poddane wery kacji. Chodzi o to, aby lista zawierała wszystkie znane sposoby. Wpisy na liście podzielić można na kategorie wg obszaru, jaki jest oceniany. Może to być dokumentacja lub modele. Dalej – procesy, wymagania biznesowe, funkcjonalne, itd. Diagramy klas, sekwencji, stanów, itd. Wery kacja spójności, kompletności, testowalności, itd. Do każdej metody wery kacji warto dołączyć opis sposobu przeprowadzenia, np. w formie odnośnika do materiałów w sieci, książce czy rmowym intranecie. Można także przypisać proponowaną rolę w projekcie, która dokona kontroli daną metodą.
Tak przygotowana lista może funkcjonować jako kanon wyznaczający trendy przeprowadzania weryfikacji wymagań w organizacji. Warto, by był to kanon żyjący, to znaczy taki, który zostaje wzbogacany po kolejnych projektach o kolejne propozycje. Nowe pomysły mogą wynikać z zauważonych na późniejszych etapach powtarzających się problemów, których nie wychwyciła poprzednia weryfikacja, albo ze zdobywania nowych kompetencji i poznawania nowych możliwości.
Oczywiście nie wszystko na raz
Recz jasna, nie chodzi o to, by w najmniejszym projekcie przeprowadzać wery kację na miarę badań naukowych do doktoratu. Warto oznaczyć na naszej liście te techniki, które są bardzo ważne, wychwytują wiele błędów i powinny być wykonywane w każdym przedsięwzięciu oraz te, które będą pomocne, ale być może w większych projektach, przy większym zapasie czasu lub dużym ryzyku i większych oczekiwaniach co do zapewnienia wysokiej jakości wymagań.
Do każdego projektu powinniśmy z głową wybrać sposoby wery kacji, które będą do niego odpowiednie.
Zapewnienie zasobów
Pamiętaj, że nie jesteś sam. Wybierając metody wery kacji należy uwzględnić, że w odpowiednim czasie będą potrzebne odpowiednie zasoby. Mam tu na myśli osoby w różnych rolach w projekcie, dostęp do modelu i narzędzia, w jakim jest wykonany, itp. Warto poinformować zawczasu kierownika projektu, lidera zespołu, jak i samych zainteresowanych, że będą potrzebni – do czego, kiedy i na jak długo.
Dobry czy niedobry
Ocena oceny, czyli chodzi tu podsumowanie jaki wybrana metoda weryfikacji przyniosła efekt. Ile błędów zostało zidentyfikowanych? Jakiej wagi? Czy może skuteczność metody zależy od przeprowadzającego wery kację? Posiadając takie informacje możemy uwzględniać je przy wyborze najskuteczniejszych metod do projektów, gdzie mamy ograniczone zasoby czy potrzeby w kontekście sprawdzania jakości wymagań.
Śledź efekty
Skoro zadaliśmy sobie już tyle trudu wykonując wery kację wymagań, wprowadzając propozycje usprawnień, warto zastanowić się, czy to coś dało. Oczywiście poprawiając błędy, uwzględniając uwagi, czujemy, że bez tego mogłyby się pojawić na późniejszych etapach problemy. Dobrze jednak mieć bardziej rzetelne informacje odnośnie skuteczności wery kacji. Możemy zliczać trudności, które pojawiły się w późniejszych etapach projektu w związku z wymaganiami. Brzmi jak kolejna przesadna formalność? Można na to też spojrzeć jak na wstawienie „+1” w jakimś przygotowanym na te okazje arkuszu w odpowiedniej kolumny (błąd niewielki, spory lub tragiczny w skutkach) za każdym razem, kiedy rozpęta się burza rozwiązywania dylematu, którego by nie było, gdyby nie te wymagania… A to przecież nie jest często 😉
0 komentarze “Weryfikacja wymagań”
Pomocny artykuł. Bywa że coś przeoczę – potem jestem ścigany przez różnych ludzi, którzy chcą mnie skrócić o głowę :).
Być może jest to temat na inną rozprawkę, ale jak w praktyce udaje Ci się zwerbować do weryfikacji takie szerokie grono? Zazwyczaj mogę jedynie pomarzyć o asyście innego analityka, albo co gorsza wspierałem sam siebie. Przekazujesz innym osobom dokumenty, czy organizujesz spotkania i opowiadasz?
Jeśli chodzi o weryfikację kompletności przy pomocy diagramów, to w sumie czy to nie diagram powinien być tym głównym elementem opisującym wymaganie (lub ich zbiór)? Dołączasz później takie weryfikujące diagramy do dokumentacji?
No właśnie 🙂 Dla nas czasem małe przeoczenie, dla innych później poważniejsze konsekwencje. Ściganie poniekąd wpisane jest w nasz zawód. Bywa to nieprzyjemne (jeśli nie z zewnątrz to własny zawód, że powinienem na to wpaść!), ale zawsze pomaga mi myśl, że a) mamy wspólny cel – rozwiązanie spełniające postawione wymagania – więc nie ma się co boczyć, tylko poprawiać 🙂 Każda uwaga nas do tego celu przybliża. b) inni też robią błędy. Pech chciał, że jesteśmy pierwsi w łańcuszku i nasze błędy widzą wszyscy po kolei – architekci, projektanci, programiści, testerzy, klienci.
Weryfikacji nie robię zawsze w wersji „full”. Wiadomo, pociąga to ze sobą koszty. Trzeba rozważyć, na ile krytyczne są to wymagania, część rozwiązania czy cały projekt. Jeśli jest skomplikowany, albo o poważnych konsekwencjach dla biznesu w razie błędów, to wtedy dobrze zaangażować w ten proces innych. Jak mi się to udaje? Tych, z którymi pracuję w ramach jednej struktury organizacyjnej, po prostu proszę 🙂 Do innych zespołów można dotrzeć przez ich przełożonego. Jeśli praca jest w strukturze projektowej, to po prostu kierownikowi projektu wystarczy przedstawić argumenty za weryfikacją i czas się znajdzie. Niektórym wystarczy powiedzieć, że jak tego nie zrobią, to wszystkie błędy będą mieli na swojej głowie później 🙂 A to niefajne ani dla programistów, ani dla testerów, więc często chętnie w tym wspierają. Angażowanie innych analityków jest tym bardziej przydatne, im mniej doświadczony jest ten, któremu się weryfikuje, i bardziej doświadczony ten, który weryfikuje. Ale każda druga para oczu zawsze jest pomocna, nawet jeśli jesteście na jednym poziomie, albo osoba weryfikująca jest mniej doświadczona – nauczy się jak Ty piszesz.
Raczej przekazuję dokumenty do weryfikacji. Nie jest mi potrzebna weryfikacja na gorąco na spotkaniu, ale bardzo szczegółowa. Chcę jak najwięcej jak najbardziej szczegółowych błędów. To wymaga skupienia i czasu. Jednak spotkania to też jakieś wyjście, jeśli czasu jest mniej, a nie chcemy całkowicie odpuszczać weryfikacji. Tylko trzeba liczyć się z tym, że znalezionych błędów będzie mniej i będą bardziej ogólne, bo nie będzie wiele czasu na zastanowienie i rozpatrzenie wszystkich warunków.
Do opisywania wymagań oczywiście podejść jest wiele. Można niby obejść się bez tekstu i wszystko przedstawić na diagramach albo w komentarzach na diagramach. Mi jednak bardzo pasują opisy przypadków użycia w tabelach. Podobne informacje mamy niby na diagramach aktywności, ale późniejsza modyfikacja wydaje mi się nieco sprawniejsza w tabeli niż przy edycji diagramu. Staram się nie robić diagramów wszystkiego, ale tych rzeczy, które rzeczywiście wnoszą wartość. Oczywiście dołączam do dokumentacji diagramy, które są. Je łatwiej się weryfikuje niż tekst, jeśli komuś z tego tekstu nie jest łatwo wyobrazić sobie odpowiedniego modelu w głowie.
Dzięki za tak wyczerpującą odpowiedź :).
Zdecydowanie najcięższy jest wewnętrzny zawód, szczególnie w przypadkach popełniania tego samego błędu kolejny raz. Boczyć się faktycznie nie ma sensu i nawet nie ma za co – w końcu to mój błąd :). Poza tym takie wpadki można zamienić w dobrą okazję do nauki.
Słusznie zauważasz, że jesteśmy pierwsi w łańcuszku (stąd nasze błędy mogą być bardzo groźne), a mimo to spotykałem się już z przekonaniem, iż wystarczającą weryfikacją jest zatwierdzenie dokumentacji przez klienta (w końcu jak będzie coś nie tak to zwróci z uwagami). A klient w końcu też człowiek.
Struktura projektowa faktycznie ułatwiłaby weryfikację, szczególnie gdy osoby zainteresowane są dosłownie pod ręką. Nie tak łatwo, gdy trzeba udać się do innej komórki – tu już dużo zależy od przełożonego, a ten nie zawsze jest zainteresowany poświęcaniem czasu zespołu na wyłapywanie „cudzych” błędów. W efekcie najczęściej mogę liczyć na rozwiązanie pół na pół: weryfikacja programisty niczym „zwiad bojem”, już w czasie implementacji (i to pod warunkiem, że „zasób ludzki wytwarzający kod” jest dociekliwy ;)).
Koniec końców wszystko się rozbija o ludzi i to czy potrafimy ze sobą rozmawiać i współpracować (wydawałoby się oczywiste, ale nie zawsze tak jest: konflikty osobowości, polityka, czy wręcz lenistwo potrafią bardzo komplikować życie :/).
Co do sposobu weryfikacji to faktycznie: na gorąco można przeważnie określić wykonalność danego wymagania. W pozostałych przypadkach omawiając mógłbym nawet przeszkodzić: np. gdy w dokumencie stosuję niejasny skrót myślowy, który w trakcie spotkania jestem w stanie na tyle płynnie przedstawić, iż problem nie rzuci się w oczy weryfikującego (a w końcu nie zawsze będę dostępny, aby wyjaśnić o co chodziło autorowi).
W pytaniu o diagramy chodziło mi o to, że jeśli mogę coś w łatwy sposób zweryfikować diagramem, to czy przypadkiem właśnie on nie powinien być główną składową wymagania? Rzecz jasna, nie wszędzie będzie to pasować. Sam też „wychowałem” się na tabelkach i bardzo je cenię za ich uporządkowanie (dobrze mi przy tym współgrają z diagramami rozrysowanymi na ogólnym poziomie szczegółowości):).