Weryfikacja wymagań

11 maja 2015

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.

Weryfikacja ma za zadanie potwierdzić, że wyma- gania są odpowiedniej jakości, tj. dobrze napisane czy zamodelowane. W odróżnieniu od walidacji, która to poświadcza, że wymagania są odpowied- nie dla odbiorców (klientów, użytkowników), czyli wspierają spełnienie celu.
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.
W przypadku wymagań funkcjonalnych dla systemów świetnie sprawdzają się w tej roli:

  • 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:

kompletność diagramu klas jest sprawdzana przez:

  • 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.

Spójność na poziomie atrybutów przy przypadkach użycia jednego obiektu biznesowego, np. dodawanie faktury, edycja faktury, użycie faktury, pomaga sprawdzić diagram klas. Jest niezastąpiony w tworzeniu „jednej wersji wydarzeń”. Opisując wymagania tekstem możemy pogubić się w tym, co ten obiekt ma, czego nie ma i wprowadzić niespójność. Tworząc klasę i dodając jej atrybuty, przy każdym użyciu (dodaj, edytuj, użyj), odwołujemy się do jednego miejsca, gdzie potwierdzamy spójność i przy okazji też kompletność.

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ń.

Wymaganie powinno być sformułowane w taki sposób, aby możliwe było obiektywne, jednoznaczne stwierdzenie, czy jest ono spełnione, czy nie. Pomaga w tym rozbijanie na mniejsze części, z których każdą jest łatwiej ocenić. Warto stosować także priorytety (np. skalę MoSCoW), aby określać, które wymagania muszą być konieczne spełnione, aby rozwiązanie zostało zaakceptowane, a które są mniej ważne. Jeśli wymaganie może być spełnione na różnym poziomie, można wprowadzić skalę i przypisać każdemu z poziomów znaczenie – np. spełnione w 90%, wystarczająco, itp.

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.

Na końcu pamiętajmy też o sobie. Wery kacja oznacza, że mogą pojawić się błędy brzemienne w skutkach lub drobniejsze uwagi, które tak czy inaczej wymagają poprawek i naszej uwagi. Zarezerwujmy sobie zatem także chwilę na wprowadzenie uwag i zaprowadzenie jeszcze wyższej jakości wymagań.

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 😉

Cześć, jestem Hania.

Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.

Może zaciekawi Cię także:

www.analizait.pl by ProjectUP (C) 2020