Jakie powinny być idealne wymagania? Pytanie idealnie zachęcające do dyskusji, prawda? 🙂 Niby najprostsza i zarazem najpełniejsza odpowiedź zawiera się w jednym zdaniu:

Idealne wymagania powinny być tak napisane, by w pełny sposób opisywały oczekiwany system i by w ten sam sposób rozumiał je zarówno biznes jak i developerzy.

Niestety, na codzień sprawa jest ciut bardziej skomplikowanam bo “słowo słowie nie równe, a język naturalny jest okrutnie nieprecyzyjny”, więc proponuję rozwinąć nieco temat jakości wymagań.

Na codzień, podczas pracy z wymaganiami, można natknąć się na szereg problemów i trudności, które – o ile sobie z nimi nie poradzimy – mogą wpłynąć na realizacje projektu. Ktoś coś nie tak zrozumie, użyje niejednoznacznego słowa, nie doprecyzuje jakiegoś terminu, pozostawi jakąś “ślepą ścieżkę” w procesie i tak, problemik do problemiku, zbierze się materiał na całkiem spory Problem. A Problem ten, warto o tym pamiętać, może się utrzymać potem w dokumencie specyfikacji, potem w procesie wytwarzania (implementacji, testów) aż wyjdzie na jaw (przy testach, demo albo po wdrożeniu!), że coś ktoś powiedział nie tak, ktoś inny nie dopytał, nie doprecyzował i.. masz babo placek, trzeba wnosić poprawkę. A każda poprawka – kosztuje. Im większy Problem, tym większy koszt związany z jego naprawą. W ekstremalnej sytuacji ukończony kawałek produktu trzeba pisać od nowa.

Literatura (poparta życiem;) ) wymienia listę najczęściej występujących problemów z wymaganiami. I sądzę – na podstawie swoich doświadczeń – że warto te problemy znać, by zawsze z tyłu głowy mieć świadomość, co może wpłynąć na poprawność opisywanej dziedziny..

Problemy z wymaganiami

Do najczęściej wymienianych problemów należą:

• niejasne cele projektu
• problemy komunikacyjne
• bariery językowe
• bariery wiedzy
• niejasne formułowanie wymagań
• zmienność wymagań
• niska jakość wymagań
• niewystarczające zaangażowanie interesariuszy
• pominięte klasy interesariuszy
• błędne planowanie
• niewystarczająca specyfikacja rozwiązania

 

Niejasne cele projektu

Nie znając kontekstu biznesowego lub/i wartości biznesowej wprowadzanego rozwiązania ciężko jest poprawnie określić wymaganie. Bardzo ważne jest właściwe ukierunkowanie działań zarządzania wymaganiami.

 

Problemy komunikacyjne

“Użytkownik doskonale wie, czego chce, tylko nie wie, jak to powiedzieć”. Może się zdarzyć, że klient nie jest w stanie odpowiednio precyzyjnie wyjaśnić “o co mu chodzi”, wyrazić swoich potrzeb, intencji. Niesie to za sobą ogromne ryzyko, szczególnie jeśli osoba zbierająca wymagania nie wykryje na czas tego zagrożenia i nie pomoże klientowi w określeniu jego  wymagań.

 

Bariery językowe

Szczególnie dotyczy projektów międzynarodowych, gdy w grę wchodzi porozumiewanie się w języku obcym. Niestety może też spotkać zespoły mówiące w tym samym języku (np z uwagi na regionalizmy).

 

Bariery wiedzy

“Jesteś tak dobrym analitykiem jak dobrze znasz dziedzine, w której prowadzisz specyfikacje”. Bariera wiedzy stwarza ogromne zagrożenie ze strony analityka, jeśli ten nie zna dziedziny biznesowej, której ma dotyczyć projekt. Zagrożenie jest jeszcze większe, jeśli analityk nie ma świadomości, że tej dziedziny nie zna lub że w ogóle powinien ją poznać:)  Ze strony klienta natomiast problem może dotyczyć braku znajomości procesu wytwarzania oprogramowania. Jeśli klient nie ma świadomości jak istotne jest precyzyjne wyrażenie swoich wymagań(oczekiwań) , zmienność wymagań lub zbyt późne przekazywanie kolejnych danych może istotnie wpłynąć na sukces w realizacji projektu.

 

Niejasne formułowanie wymagań

Zawiłe opisy wymagań, zdania wielokrotne złożone, zależności między zdaniami, niejednoznaczne skróty mogą sprawić trudność w jednoznacznym rozumieniu opisanych wymagań.

 

Zmienność wymagań

Sama w sobie “zmienność” nie jest zła, ale gorzej jeśli wymagania zmieniają się co chwilę uniemożliwiając dostarczenie odpowiedniego rozwiązania. Wysoka zmienność wymagań może wynikać z niewłaściwie poprowadzonej identyfikacji i analizy lub z przyczyn zewnętrznych – np. duża zmienność dziedziny biznesowej.

 

Niska jakość wymagań

Niestety niska jakość wymagań bezpośrednio przekłada się na tworzone rozwiązanie. Czyli niespójne, niekompletne, niejasne, sprzeczne wymagania utrudnią lub uniemożliwią implementację poprawnego, oczekiwanego przez klienta produktu. Przyczyną niskiej jakości wymagań może być brak umiejętności analityka w zakresie identyfikacji i analizy wymagań lub brak zapewnienia czasu na właściwe przeprowadzenie analizy (napięty harmonogram projektu, bagatelizowanie obszaru zbierania wymagań itd).

 

Niewystarczające zaangażowanie interesariuszy

Jeśli interesariusze nie zaangażują się w procesie zbierania wymagań, szczególnie we wczesnych etapach projektu, projektowane rozwiązanie może nie spełniać ich rzeczywistych oczekiwań lub że ich wymagania nie zostaną w ogóle odkryte co w późniejszym czasie spowoduje konieczność wprowadzenia rozległych zmian.

 

Pominięte klasy interesariuszy

Po ludzku – jeśli nie dotrzesz do kogoś, kto ma jakieś wymagania, to tych wymagań nie poznasz i nie zaplanujesz ich zaspokojenia. Książkowo – jeśli na etapie identyfikacji interesariuszy pominięta zostanie jakaś grupa uczestników projektu, istnieje ogromne ryzyko, że projekt nie będzie realizował ich procesów biznesowych, a w efekcie nie spełni oczekiwań, nie zostaną zamodelowane funkcjonalności realizujące ich potrzeby.

 

Błędne planowanie

Problem związany z błędnym szacowaniem czasu niezbędnego na szczegółową analizę i wytwarzanie. Niewłaściwe sklasyfikowanie wymagań pod względem stopnia złożoności bezpośrednio przełoży się na czas zaplanowany na realizację danej funkcjonalności. Niestety, takie błędne oszacowane wymagania będzie oznaczało opóźnienia (lub niską jakość produktu) podczas ich realizacji – przykładowo, jeśli wymaganie zostało określone jako “nieskomplikowane” a podczas wytwarzania okaże się, że to tak na prawdę jest duża lub/i skomplikowana funkcjonalność, to na jego implementacje trzeba znacznie więcej czasu niż wynika to z przyjętego harmonogramu.

 

Niewystarczająca specyfikacja rozwiązania

Specyfikacja jest ważna! Niezależnie od tego, jakie mity panują w zakresie podejścia agile! Agile oznacza gotowość na zmiany, a nie odrzucenie specyfikacji i dokumentacji. Jeśli organizacja zaniedba obszar zarządzania wymaganiami, nie będzie przygotowywała wystarczająco dokładnej specyfikacji, wyżej będzie cenić implementację nad zbieranie wymagań, to istnieje ogromne ryzyko, że:

1. końcowy produkt nie będzie spełniał oczekiwań klienta w oczekiwanym stopniu,

2. produkt spełni ogólne oczekiwania klienta, ale okaże się że nie zostało zaplanowanych wiele innych funkcji, które można było przewidzieć na etapie analizy

3. wręcz niemożliwe będzie zarządzanie zmianą, bo w przypadku braku śledzenia wymagań jak szybko i precyzyjnie określić, która funkcjonalność wpływa na inną i w jaki sposób?

4. pojawią się duże trudności z utrzymywaniem działającego programu, szczególnie w kontekście zmienności zespołów lub utrzymywania systemu przez inny zespół niż zespół realizujący.

 

Kryteria jakości Wymagań

Wymagania, które specyfikujemy, powinny spełniać szereg kryteriów jakości, takich jak:

• poprawność
• konieczność
• wykonalność
• jednoznaczność
• weryfikowalność
• spriorytetyzowanie
• jednostkowość
• zgodność
• zrozmiałość
• abstrakcyjność
• aktualność

Niby wszystko to samo, ale jednak dotyczą innych aspektów danego wymagania, i tak:

Poprawność  – oznacza, że wymaganie powinno odpowiednio przekazywać potrzebę klienta.

Konieczność – oznacza, że powinno się specyfikować to, czego klient faktycznie potrzebuje w sensie spełnienia określonej potrzeby biznesowej. Wymaganie jest konieczne, jeśli jego brak wpływa na kompletność działania produktu.

Wykonalność  – oznacza, że wymaganie musi być możliwe do zaimplementowania.

Jednoznaczność – oznacza, że wymaganie musi mieć tylko jedną interpretację.

Weryfikowalność – oznacza, że wymaganie musi być możliwe do przetestowania.

Spriorytetyzowanie – oznacza, że musi mieć określoną wartość dla klienta.

Jednostkowość – oznacza, że opis musi dotyczyć tylko jednego pojedynczego wymagania.

Zgodność – oznacza, że wymaganie musi być adekwatne do innych wymagań lub dokumentów projektu.

Zrozumiałość – oznacza, że przekaz jest jasny dla odbiorcy (bez niewyjaśnionych skrótów, specjalistycznych terminów itd.).

Abstrakcyjność – oznacza, że wymaganie powinno być opisane niezależne od sposobu implementacji. Ma pokazywać co chcemy robić, a nie jak to zrobić, nie wnikamy w aspekty techniczne.

Aktualność – oznacza, że dane wymaganie nie dezaktywuje się z upływem czasu.

 

Kryteria jakości Opisu Wymagań

Opis wymagań powinien być:

• prosty
• spójny
• zrozumiały
• zwięzły

Co to oznacza, tak .. na co dzień?

Prostota – piszmy bez zbędnych warunków i struktur!

Spójność – trzeba zachować konsekwencję w stosowanej terminologii w całej dokumentacji projektu – każdy dokument powinien tak samo “rozumieć” określony nazwy ról, klas itd

Zrozumiałość – najprościej byłoby napisać, że opis powinien być zrozumiały tak samo dla klienta jak i developera.. Ale w tym punkcie chodzi także o to, by nie pomijać specyfiki danej dziedziny biznesowej wymagania (o której developer lub tester może nie mieć pojęcia) a także żeby uważać na pułapki tzw “oczywistych oczywistości”, czyli wymagań, które dla biznesu i/lub analityka są tak oczywiste, że szkoda o nich pisać, a które potem są przyczyną wielu nieporozumień w czasie implementacji czy demo dla klienta…

Zwięzłość – opisy powinny być możliwe krótkie i treściwe, bez zbędnych słowotoków 🙂

 

W kolejnej części “wymagań po ludzku” – przykłady pułapek w specyfikacji wymagań, zapraszam 🙂

 

Źródła:

• BABOK v3 (!!!!)
• Inżynieria wymagań w praktyce, B. Chrabski, K. Zmitrowicz, PWN2015
• Analityk systemów, K. Zmitrowicz, PWN 2015
• Zarządzanie wymaganiami, D. Leffingwell, D. Widrig, NT2003
• specyfikacja oprogramowania – inżynieria wymagań, K. Wiegers, J. Beatty, Helion2014

… i doświadczenia własne 😉