Oszczędzaj! Zaciskaj pasa! Idzie kryzys! A później – już jest kryzys, musimy oszczędzać! Ilu z nas nie słyszało w ostatnim czasie tych haseł. Samonapędzający się kryzys zmusza kolejne przedsiębiorstwa do zaciskania pasa, co wiąże się z redukcją zatrudnienia, albo najczęściej zmniejszeniem funduszy na wdrażanie projektów w owym przedsiębiorstwie, bo przecież przedsiębiorstwo musi się rozwijać.
I tutaj pojawia się pierwszy zgrzyt – Klient chce wdrożyć rozwiązanie usprawniające pracę, dzięki któremu Firma zaoszczędzi konkretne pieniądze, jednak najlepiej jeśli koszta związane z wdrożeniem rozwiązania nie doprowadzą do naruszenia już i tak kryzysowego budżetu Firmy. Jak tego dokonać? Odpowiedź wydaje się bardzo prosta- wystarczy poszukać takich punktów w projekcie, z których możemy zrezygnować w celu obcięcia kosztów.
Część pierwsza – „tniemy koszty”
Z cięciem kosztów w projekcie czasami jest jak z zamówieniem garnituru u bardzo dobrego krawca. Bez koniecznej kontroli długości nogawek spodni może się czasami okazać, że zamiast spodni od garnituru zamówiliśmy szorty, za które nota bene musimy zapłacić, i je nosić dumnie wyznaczając nowe standardy ubioru biurowego, co może być trudne, jeśli nie jesteśmy właścicielem poważanej Firmy na rynku, która takie trendy wyznacza. Cóż zatem możemy z takim fantem zrobić? Możemy zmienić organizację naszej firmy tworząc sztucznie obok „Casual Day”, „Short Day”, albo przyznać się do własnej porażki, zapłacić za bardzo drogie szorty, pójść do innego krawca i w pełni zaufać mu w kwestii długości nogawek. Jednym słowem cokolwiek byśmy nie zrobili i tak poniesiemy koszty, których moglibyśmy uniknąć gdyby nie brak naszego zaufania do profesjonalizmu krawca. No dobrze, ale jak do tego doszło. Może prześledźmy w skrócie owe skracanie tych naszych nieszczęsnych nogawek, bowiem sprawa wydaje się bardzo prosta.
Wybraliśmy najlepszego krawca w mieście wierząc, że uda nam się uszyć włoski garnitur na miarę naszych potrzeb. Oczywiście nie pozwoliliśmy się wymierzyć krawcowi z braku czasu, tylko podaliśmy wymiary dotychczasowych noszonych garniturów, na bazie których krawiec miał uszyć nowy. W końcu nadszedł dzień mierzenia spodni. Mierzymy spodnie, stojąc boso i mówimy: „Za długie – skrócić”, krawiec zaleca jednak przed wykonaniem polecenia zmierzyć ponownie spodnie wraz z butami. Mierzymy, jednak nadal nie słuchając zaleceń profesjonalisty, że taka długość spodni jest wystarczająca każemy nadal skrócić. Krawiec jednak nie poddaje się i oświadcza, że owszem wykona skrócenie spodni, jednak mamy się zastanowić i za dwa dni dać mu ostateczną odpowiedź. Zamiast zaufać profesjonaliście szukamy wsparcia wśród: „doradców”, którzy mówią: „Masz rację”, w celu upewniania się co do swoich racji szukamy pomocy w Internecie i dostrzegamy taki sam model garnituru, który zamówiliśmy wraz z podanymi wymiarami, nie dostrzegając subtelnej różnicy, że my mamy 190 cm wzrostu, a wymiary garnituru, który znaleźliśmy w Internecie są podane dla osoby o wzroście 160 cm. Bez namysłu dzwonimy do naszego krawca i podajemy dokładne wymiary garnituru, w ogóle nie zwracając uwagi na to co mówi krawiec. W końcu nadchodzi dzień odbioru garnituru oraz zapłaty za wykonaną pracę i oto nasze zdziwienie, kiedy krawiec podaje nam szorty. W pierwszej chwili myślimy, że to pomyłka bo zamawialiśmy przecież włoski garnitur a nie szorty, po czym nasz krawiec ze stoickim spokojem przypomina nasz feralny telefon, w którym podawaliśmy dokładne wymiary garnituru i oto mamy nasze zamówienie.
Ta krótka historyjka pokazuje do czego może doprowadzić brak śledzenia skutków owego skracania spodni na ostateczny wygląd naszego garnituru.
Wróćmy na chwilę do naszego cięcia kosztów. Bardzo często zdarza się, że chcąc zaoszczędzić na wdrożeniu rozwiązania szukamy oszczędności tam, gdzie już więcej zaoszczędzić nie można, bowiem w przeciwnym wypadku rozwiązanie, które zamawiamy będzie niefunkcjonalne – tak samo jak zamówione szorty. Najprościej zrezygnować z czegoś co wydaje nam się zbędne, jak pośrednie mierzenie spodni po skróceniu, nie widząc, że wyrzucenie tego procesu ma znaczący wpływ na ostateczny kształt produktu, który został przez nas zamówiony. Z czego najczęściej Klienci rezygnują? Z etapu przygotowania do projektu, czyli z ANALIZY.
Część druga – brak analizy w projekcie
Rola analityka biznesowego w Firmie jest rozumiana błędnie przez większość Zleceniodawców i bardzo często jest bagatelizowana ze względu na to, że wynikiem analizy biznesowej i systemowej jest dokument, a patrząc oczami Zleceniodawcy droga do produktu jest jeszcze daleka.
W celu zrozumienia, w jaki sposób jest postrzegany Analityk w projekcie wystarczy sięgnąć po stereotypy, jakie już funkcjonują. Jak myślę o stereotypach od razu przypomina mi się jeden ze skeczów brzuchomówcy Jeff’a Dunhama, który za pomocą pacynki imieniem Peanut prezentuje w trzech żołnierskich zdaniach czym zajmuje się analityk biznesowy. Peanut: „Aaa czyli wchodzisz do Firmy rozglądasz się i po chwili mówisz: Hmmm, Hmmm, Hmmm macie biznes”. Jednym słowem według stereotypu analityk biznesowy/systemowy zajmuje się stwierdzeniem rzeczy oczywistych. Oczywiście jest to stereotyp pokazany w krzywym zwierciadle, bowiem dla części zleceniodawców analityk biznesowy/systemowy zajmuje się masową produkcją zbędnej ich zdaniem dokumentacji, która zawiera jakieś diagramy, jakieś ludziki z chmurkami (jak określają diagram przypadków użycia), jakieś całkowicie niezrozumiałe nazwy w tekście (jak określają nazwy pól w bazie danych, w których będą przechowywane dane). Nie dość, że produkują tą masę dokumentacji, ze scenariuszami testowymi to jeszcze każą to czytać, zrozumieć i co najgorsze podpisać jak jakąś umowę.
Niewielu z nich zastanawia się co tak naprawdę zawiera ten momentami stustronicowy dokument i jak jego brak wpływa na projekt. Dlatego z taką łatwością albo bagatelizują zapisy w dokumentach, albo w ogóle pomijają ten etap projektu, bo przecież o ile szybciej byłoby gdyby reprezentant Zleceniodawcy spotkałby się od razu z programistą, który pisałby linijki kodu, później najwyżej zostałaby zrobiona jakaś notatka, zrzuty ekranu z programu i wszyscy byliby zadowoleni, a ile pieniędzy zostałoby zaoszczędzone. Oczywiście zaoszczędzone tylko pozornie, bo programista nie będzie się zastanawiał co się stanie linijkę dalej, czy pisana funkcjonalność po tzw. commicie na bazie nie spowoduje jej zawieszenia, albo co gorsza czy przypadkiem inne funkcjonalności nie odmówią współpracy, a w przypadku tworzenia nowego rozwiązania dedykowanego dla naszego Zleceniodawcy czy w ogóle po zakończeniu jego pisania w ogóle zadziała. Wcześniej wspomniana dokumentacja zawiera przemyślane funkcjonalności, model logiczny rozwiązania, dzięki czemu programista pisząc program nie będzie zastanawiał się co się stanie linijkę dalej, bo wierzy, że analityk przewidział wszelkie alternatywne działania.
No właśnie, wiara i zaufanie…..Zaufanie programisty do dokumentacji powinna być taka jak cukiernika do przepisu na ciasto. Jeśli proporcje w cieście oraz składniki są szczegółowo opisane, opisana jest logika działania, czyli który składnik jest w jaki sposób obrabiany, że najpierw należy rozpuścić np. 125 g kostki margaryny firmy X, a później dodać resztę składników, że należy piec wyrobione składniki w temperaturze 180 stopni przez 50 minut, to nie ma możliwości, aby ciasto się nie udało. No chyba, że w przepisie któryś składnik został pominięty, ale to wywód na inny artykuł. Co by było, gdyby taki cukiernik na zasadzie prób i błędów dobierał składniki, aby upiec wcześniej wspomniane ciasto? Ile czasu by mu to zajęło, nie mówiąc już o poniesionych kosztach.
Czy zatem z taką łatwością możemy jednoznacznie powiedzieć, że analiza jest zbędnym etapem, albo etapem, który możemy zbagatelizować poprzez nieczytanie wytworzonej dokumentacji? W pierwszej chwili może pozornie nam się wydawać, że dzięki temu zaoszczędzimy czas i pieniądze, czy na pewno?
Wyobraźmy sobie sytuację, kiedy może nie tyle pomijamy etap analizy co ją po prostu bagatelizujemy. Niestety takie sytuacje mają miejsce. Weźmy choćby przykład dość głośnej „analizy”, która później została zrealizowana. W 2011 roku policjanci z drogówki z czterech największych miast Polski mogli cieszyć się nowymi motocyklami wyposażonymi z nowoczesny sprzęt umożliwiający komunikację z centralą oraz patrolami. Ku ich zdziwieniu okazało się, że sprzęt nie nadaje się do użycia, bowiem nikt nie zauważył, że motocykle zostały wyposażone w system analogowy, podczas gdy centrala obsługiwana jest przez system cyfrowy. Brak dokładnej analizy oraz właśnie wcześniej przeze mnie wspomniana ignorancja dokumentacji spowodowała podniesienie kosztów projektu, nie mówiąc już o czasie wdrożenia, czyli oddania produktu do użycia. Czy owe subtelne różnice nie doprowadziły nas do otrzymania szortów zamiast garnituru? O ile łatwiej jest wprowadzić zmianę na etapie dokumentu po zauważeniu takiego braku doprecyzowania i analizy niż ponieść koszta związane z wdrożeniem poprawek.
Podobna sytuacja miała miejsce w 2002 roku w Swanick, gdzie wdrażano system kontroli ruchu lotniczego, który miał zarządzać wszystkimi trasami lotniczymi przebiegającymi nad Anglią i Walią. Przy jego realizacji znacznie przekroczono budżet – zamiast planowanych 35 mln funtów wydano ostatecznie 623 mln, a realizację ukończono z 6 letnim opóźnieniem. Dwie główne i najważniejsze poprawki umożliwiające w ogóle poprawne funkcjonowanie rozwiązania wprowadzono do systemu w czasie, kiedy trwało już szkolenie personelu kontroli lotów.
Do podobnych sytuacji dochodzi bardzo często, bowiem niewielu zleceniodawców traktuje dokument analityczny jak pewnego rodzaju umowę, nawet o wiele bardziej wiążącą niż ta, która zawiera koszty projektu. To właśnie w dokumentacji znajduje się dokładny opis produktu, jaki jest zamawiany przez Zlecającego oraz zasady jego działania, elementy jakie będzie zawierać oraz opis co się stanie jeśli np. w polu nr telefonu komórkowego zamiast cyfr wpiszemy litery- i czy w ogóle to będzie możliwe.
Jak zatem zmierzyć to co z początku wydaje nam się niemierzalne? Wyobraźmy sobie, że zamiast rozważania analizy chcemy zmierzyć np. wiatr – coś co jest niewidoczne, podobnie jak analiza (oczywiście jedynie niewidoczna dla Zleceniodawców). Miarą wiatru będą skutki jakie wynikają z jego działania, bądź też jego braku. Tak samo dzieje się z analizą. Jej brak może być brzemienna w skutkach tak samo jak jej zbytnia troska o rzeczy nieistotne –mogą spowodować więcej zamieszania i bałaganu niż jej brak. Ale jak poznać czy wykonana analiza jest dobra? Musimy sięgnąć po mierniki jej jakości.
W celu dokładniejszego zobrazowania skutków braku analizy, bądź jej znikomej zawartości przedstawiam dość znany obrazek prezentowany najczęściej przez wykładowców na uczelniach, w celu uświadomienia rozmiarów konsekwencji, jakie wynikają z braku dokumentacji oraz zrozumienia potrzeb Klienta:
Część trzecia – pokaż mi swój dokument a powiem Ci czy projekt się uda
„Potrzeba jest matką wynalazku” – większość norm zasad oraz zapisów powstało właśnie dlatego, że ktoś jakiś czas temu zadał sobie trud zapytania: „Co to znaczy, że ten dokument jest dobry?”. W poszukiwaniu odpowiedzi powstawały i nadal powstają zapisy, które starają „zmierzyć” jakość dokumentu. Zanim o metodach mierzenia może najpierw sprecyzujmy pojęcie: „dobry dokument”. Wszystko zależy od tego kto tworzy tą definicję, bowiem dla każdego będzie oznaczała co innego w zależności od tego co chciałby zobaczyć w takim dokumencie:
– Klient liczy na to, że zapisy w dokumencie objęły wszystkie jego wymagania biznesowe, które zostały przedstawione Analitykowi,
– Analityk ma nadzieję, że spisał wymagania funkcjonalne,
– Programista liczy, że w analizie oprócz wymagań funkcjonalnych znajdzie również wymagania niefunkcjonalne,
Gdyby każdego z wyżej wymienionych zapytać co oznacza dla nich „dobry dokument analityczny” usłyszelibyśmy: od Klienta – dokument powinien zawierać zbiór moich potrzeb biznesowych oraz receptę na ich usprawnienie, od Analityka – spis wymagań funkcjonalnych, od Programisty zaś – spis wymagań niefunkcjonalnych oraz niefunkcjonalnych, jeszcze od Testera dowiedzielibyśmy się, że spisanie wymagań wielowymiarowo funkcjonalności pozwala nam określić dokument jako kompletny.
Jak widać każdy z nich widzi tylko pewien obszar dokumentu, który jest dla nich istotny nie dostrzegając całości. Analogicznie jest w bajce o słoniu i ślepcach.
Jest to bajka o sześciu niewidomych mężczyznach, którzy napotykają słonia po raz pierwszy. Ponieważ nikt nie widział go nigdy przedtem postanowili sprawdzić i opisać kim jest słoń. Każdy z nich dotknął innej części słonia. Pierwszy z nich owinął ręce wokół nogi słonia i powiedział: „Słoń jest jak wielkie drzewo”. „Nie” – odpowiedział drugi, który złapał słonia za ogon, „Słoń jest jak sznur”. Trzeci zaś oparł się o bok słonia i mówi – „Nie znacie się, słoń jest jak wielki mur”. Czwarty mężczyzna chwycił trąbę słonia i oświadczył: „Jesteście w błędzie. Słoń jest jak gigantyczny wąż”. Piąty mężczyzna przetarł kieł słonia i powiedział: „Myślę jednak, że słoń przypomina wygiętą włócznię”. „Nie, nie, nie!” – krzyknął szósty człowiek, który dotknął ucha słonia: „Słoń jest wielkim wachlarzem!”.
Trudno się nie zgodzić z nimi, bowiem słoń posiadał wszystkie cechy przez nich opisane, ale żadna z nich nie oddawała w pełni opisu słonia, bowiem ograniczała się do określonej części ciała słonia i tylko całościowy pogląd na przedstawione opisy pozwala nam na stworzenie pełnego opisu wyglądu słonia.
Analogicznie jest z dokumentem analitycznym. Każdy wymieniony fragment przez Klienta, Analityka i Programistę oraz Testera są ważne, ale dopiero w połączeniu stanowią pełny dokument. Niestety bardzo często dokumenty o ile takowe powstają zawierają tylko jeden wymiar opisu, co prowadzi do szeregu nieporozumień, niejasności itp.
W związku z powyższym w 1998 roku w Institute of Electrical and Electronics Engineers ( IEEE) został utworzony standard zawierający kryteria dobrej specyfikacji określony jako: IEEE Std 830-1998, na którym dokumenty wzorowane są do dzisiaj.
Standard IEEE Std 830-1998 określił ramy nie tylko dokumentu poprzez przygotowanie wzorca dokumentu, ale przedstawił zbiór 7 cech jakie powinna zawierać poprawna specyfikacja:
1. Poprawna
Najprościej ujmując – tworzona dokumentacja nie może być niezgodna z prawem czy z ogólnymi standardami przyjętymi przez Firmę. Dokument nie może być w sprzeczności z innymi już funkcjonującymi dokumentami. Jest to bardzo ogólna definicja, ale co tak naprawdę oznacza w praktyce? Wyobraźmy sobie tworzenie wymagań dla zegarka cyfrowego, który będzie wyświetlał datę oraz czas. Dodatkowo zakładamy, że ów zegarek będzie wyświetlał poprawnie wszystkie 24 strefy czasowe znajdujące się na kuli ziemskiej. Ostatnie wymaganie bazuje na błędnym założeniu, że stref jest właśnie tyle, co jest niezgodne z prawdą, bowiem stref jest znacznie więcej – na niektórych obszarach strefy czasowe wyznaczone są w podziale półgodzinnym a nie godzinnym. Co zrobić w takiej sytuacji? Tak naprawdę są dwa wyjścia – pierwsze wymaga dopisania zasadności zawężenia liczby stref czasowych o podziale godzinnym do 24 , co może być podyktowane np. wydajnością danego wymagania. Drugim rozwiązaniem jest całkowite usunięcie zapisu w specyfikacji, że na kuli ziemskiej obowiązują 24 strefy czasowe.
2. Jednoznaczna
Jest to arybut wymagań, który najczęściej jest powodem niepowodzeń w projekcie. Wymaganie jednoznaczne to takie, które napisane jest w taki sposób, że wszyscy czytelnicy mają taką samą jego interpretację. Dlatego zalecane jest, aby wymaganie było napisane w sposób prosty, zwięzły z uwzględnieniem dziedziny problemu. Często analitycy podczas specyfikowania wymagania wpadają w pułapkę chęci napisania wymagania, aby brzmiało „inteligentnie”. Szansa, że ktoś zrozumie sens naszego przesłania wówczas się zmniejsza. Dlatego łatwiej jest przy małych projektach pisać językiem naturalnym opisujący sens przedstawianego problemu. W przypadku większych projektów musimy posłużyć się metodami formalnymi, które są rzadko wykorzystywane ze względów ekonomicznych. Idea metod formalnych opiera się na matematycznym ujęciu problemu, który następnie jest weryfikowany z wykorzystaniem metod matematycznych. Za metodami formalnymi przemawia obserwacja Dijkstry’ego, który powiedział: „Testowaniem nie można wykazać braku błędów, można w ten sposób jedynie wykazać ich obecność.” Zatem korzystając z metod matematycznych można pokazać, że program jest zgodny ze specyfikacją. Oczywiście wykorzystanie metod formalnych do specyfikacji wymagań musi być podyktowane samą specyfiką zagadnienia. Przykładem niejednoznaczności jest specyfikacja już wcześniej wspomnianego zegarka elektronicznego, dla którego jedno z wymagań zakłada, że synchronizacja czasu będzie zgodna ze bieżącą strefą czasową. Pojawia się zatem pytanie czy zegarek powinien również uwzględnić automatycznie czas letni? W celu wyeliminowania niejednoznaczności analityk powinien umieścić w wymaganiu zapis czy podczas synchronizacji ma być uwzględniany czas letni czy nie.
Innym przykładem niejednoznaczności są pojęcia używane w dokumencie. Użycie sformułowania: „Klient”, „Użytkownik”, „System” obarczone jest wieloznacznością, bowiem poprzez Klienta można rozumieć Zamawiającego, bądź też Klienta, który będzie obsługiwany przez Zamawiającego. W takiej sytuacji niezbędne jest zdefiniowanie słownika pojęć i skrótów używanych w dokumencie, który jednoznacznie zdefiniuje używane pojęcia.
3. Kompletna
Każde wymaganie musi dokładnie oraz w pełni określać funkcjonalność, która będzie dostarczona. W praktyce oznacza, że opisywane wymaganie uwzględnia wszystkie możliwe scenariusze, włącznie z sytuacjami wyjątkowymi. Przykładem braku kompletności wymagania jest specyfikacja naszego zegarka elektronicznego, która nie określa jak ma się zachować synchronizacja czasu na granicy dwóch stref czasowych. Nie można bowiem wykluczyć takiej sytuacji, a programista musi wiedzieć jak aplikacja powinna zareagować. W celu poprawienia wymagania należy dodać wymaganie, zgodnie z którym synchronizacja zegarka z bieżącą strefą czasową odbywa się nie częściej niż co 5 minut.
4. Spójna
Podczas weryfikowania wymagania pod kątem spójności musimy zwrócić uwagę na kilka aspektów: spójność wymagania względem całości dokumentu oraz spójność z innymi dokumentami opisującymi już zaimplementowane, bądź planowane funkcjonalności.
Najczęściej niespójność wymagania wynika z trzech czynników:
- braku jednoznaczności – w tworzonym dokumencie ten sam obiekt jest opisywany różnymi sformułowaniami, np. w jednym miejscu opisywane są dane Użytkownika, w innym miejscu dane rejestracyjne. Mimo, że mieliśmy na myśli to samo dla programisty są to dwa różne wymagania,
- braku logiki, która bardzo często jest powiązana również z brakiem jednoznaczności
i brakiem kompletności. Opisując wymaganie możemy wpaść w pułapkę braku logiki poprzez sprzeczne opisanie w dwóch różnych miejscach zachowania danej funkcji, np. raz opisujemy, że funkcja może dodawać dwie liczby, w innym miejscu ma je mnożyć. Ten brak logiki może wynikać z faktu, albo z braku przemyślenia rozwiązania, albo braku kompletności wymagania. Należy wówczas wykluczyć sytuację, w której w danym kontekście funkcja może oprócz dodawania również mnożyć liczby. Jednak najczęściej okazuje się, że to brak logiki opisywanego rozwiązania jest przyczyną niespójności wymagania, - braku kompletności wymagania – w dokumencie opisujemy ten sam obiekt w różny sposób: raz format danych wejściowych dla funkcji opisany jest jako plik csv, w innym miejscu jako plik xml. Analogicznie jak w poprzednich przypadkach należy zbadać czy opisane wymaganie wymaga od nas uszczegółowienia, bo podczas pisania okazało się, że nie wzięliśmy pod uwagę wszystkich czynników i wówczas należy uzupełnić zapis o dodatkowe informacje o dopuszczalnych danych wejściowych, czy może nie zostało poprawnie przemyślane rozwiązanie.
Przykładem niespójności wymagań jest jedno z wymagań dla naszego zegarka elektronicznego, dla którego zostało zdefiniowane wymaganie, by oprogramowanie zegarka nie zawierało żadnych defektów. Nie zostało zawarta informacja o możliwości aktualizowania oprogramowania. Taki zapis wymagania nie jest możliwe do weryfikacji, bowiem zweryfikowanie takiego wymagania wymagałoby użycia nadmiernej ilości zasobów.
5. Uporządkowana wg. ważności
Każde wymaganie powinno mieć przypisany własny priorytet, dzięki czemu można ocenić w jakim stopniu dana funkcjonalność jest ważna dla Klienta. Priorytetyzacja umożliwia również programistom na zaplanowanie dostarczenia poszczególnych elementów systemu – w pierwszej kolejności zostaną dostarczone te elementy, które posiadają najwyższy priorytet, a dopiero później te z niższym priorytetem. Najlepiej jest stosować 3 stopnie ważności wymagań. Im więcej stopni tym trudniej jest odróżnić, które z wymagań są kluczowe.
Przykład kategorii priorytetów:
- Stopień 1 (wysoki priorytet) – funkcje z tej grupy muszą być z powodzeniem zaprezentowane podczas testów akceptacyjnych Klienta. Stanowią kryterium odbioru systemu,
- Stopień 2 ( pośredni priorytet) – funkcje, z tej grupy muszą być wzięte pod uwagę w czasie projektowania systemu i obiektów. Najczęściej są to wymagania ściśle związane z wymaganiami o stopniu 1,
- Stopień 3 (niski priorytet) – funkcje z tej grupy to tzw. kosmetyka. Są to wymagania, które uwzględniają samą wizualizację rozwiązania, natomiast nie wpływają bezpośrednio na funkcjonalność rozwiązania,
Pojawia się pytanie czym kierować się podczas nadawania priorytetu dla wymagania. Należy kierować się opinią Klienta oraz opinią programistów. W celu pogodzenia tych wydawałoby się sprzecznych potrzeb można posłużyć się macierzą, która została zaproponowana przez Wiegers’a na podstawie zasad podanych przez S.Covey’a:
Macierz wprowadza podział wymagań według kryteriów ważności oraz pilności. No dobrze, ale co z wymaganiem: „nie rób tego” skoro stosujemy tylko 3 stopniową gradację? Jest to wymaganie, które jest najmniej ważne i najczęściej podczas ostatecznego czytania dokumentu z Klientem jest albo wyrzucane z implementacji, bądź jest deklasowane na zasadzie: „Nice to have”, czyli dobrze by było jakby udało się zaimplementować, jednak jego brak w produkcie końcowym nie będzie stanowiło punktu zapalnego w protokole odbioru produktu. Takie sytuacje zdarzają się rzadko, bo jeśli jakieś wymaganie posiada priorytet: „nie rób tego”, to najczęściej są dwie drogi: albo klasyfikuje się wymaganie z priorytetem: „niski”, albo całkowicie z niego rezygnuje.
6. Modyfikowalna
Struktura dokumentu powinna umożliwiać wprowadzenie modyfikacji wymagania w wielu miejscach bez konieczności całkowitego przebudowywania dokumentu. Nie możemy bowiem założyć, że początkowe wymagania nie zmienią się. Statystyki pokazują, że średnio 25% wymagań w projektach ulega zmianie. W związku z tym takie ważne jest odpowiednie rozplanowanie wymagań w dokumencie. Można tutaj posłużyć się podejściem strukturalnym: „od ogóły do szczegółu” (top –down). Podstawowym sposobem podejścia jest uchwycenie podstawowej funkcji systemu a następnie rozbijanie jej na sekwencję funkcji składowych. Oczywiście najczęściej hierarchia funkcji jest tekstowa, jednak w celu ułatwienia odszukania zależności między funkcją główną a poszczególnymi podfunkcjami można dodać hierarchię graficzną.
Dla przykładu zostało wyszczególnione wymaganie związane z systemem podatkowym, który przedstawiamy w formie graficznej:
Takie wyszczególnienie podfunkcji umożliwia łatwe przeniesienie podfunkcji zdefiniowanych dla funkcji nadrzędnej „Zeznania” do funkcji nadrzędnej: „Podatnicy” bez konieczności przebudowywania całej struktury.
Dana funkcja powinna być dekomponowana na tylko te funkcje, które są niezbędne dla jej wykonania. Dodatkowo wykonanie funkcji nadrzędnej nie musi oznaczać wykonania funkcji składowych w każdej sytuacji. Kolejność podfunkcji nie ma większego znaczenia. Na podstawie tego opisu możemy zauważyć, że budowanie funkcji nadrzędnej i jej relacji z poszczególnymi podfunkcjami jest zbliżona do tworzenia „Use case”. Dodatkowo użycie w dokumencie diagramów i połączenie ich z opisaniem poszczególnych funkcji daje nam możliwość weryfikacji na bieżąco tworzonego wymagania, bowiem zmusza nas do pytań o zależności między poszczególnymi funkcjami a tym samym o ich spójność.
7. Możliwa do śledzenia
W celu zapewnienia możliwości śledzenia danego wymagania należy oprócz dobrego uporządkowania poszczególnych funkcji (Patrz punkt Modyfikowalna) należy zapewnić możliwość przechowywania historii zmian wymagań oraz kontrolować wersję dokumentu. W celu zapewnienia powiązania między poszczególnymi funkcjami każde zdefiniowane wymaganie musi być indywidualnie oznakowane w taki sposób, aby można było stosować do niego odnośniki w pozostałych wymaganiach. Dzięki zależnościom między poszczególnymi wymaganiami możemy w szybki sposób określić, jaki wpływ na system ma zmiana konkretnego wymagania. W celu ułatwienia śledzenia powiązań można do tego celu wykorzystać macierz, która zawiera tyle wierszy i kolumn ile jest wymagań.
Obecnie śledzenie wymagań jest wspomagane poprzez narzędzia zarządzania wymaganiami.
Podsumowanie
Rezygnacja przez Klientów z przeprowadzenia w projekcie analizy, bądź też nie zrobienie jej z należytą starannością ostatecznie podnosi koszty całego projektu nie mówiąc o samym czasie wdrożenia.
Badania przeprowadzone w kilku firmach pokazują, że koszt wykrycia i naprawienia błędu podczas etapu określania wymagań jest pięciokrotnie mniejszy niż w przypadku wykrycia błędu na dalszych etapach.
Przedstawione kryteria dobrej dokumentacji stanowią jedynie wskazówki jej weryfikacji, natomiast standard IEEE Std 830-1998 nie opisuje w jaki sposób można stworzyć dokument spełniający powyższe kryteria. O tym traktuje metodyka pozyskiwania i specyfikowania wymagań, ale to temat na osobny artykuł.
Bibliografia:
[1] C.Larman – UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji. Wydanie III, 2011,
[2] B.Bruegge, A.H. Dutoit, Inżynieria oprogramowania w ujęciu obiektowym. UML, wzorce projektowe i Java, 2011
[3] Sommerville, Ian; Sawyer, Requirements Engineering – A Good Practice Guide, 1997,
[4] IEEE 830-1998,
[5] P.G.Neumann, Computer-Related Risks, Addison-Wesley,Reading, MA, 1995
