Wprowadzenie
Przygotowanie specyfikacji wymagań na system to działania, które powinny skończyć się w miarę jasnym przekazem dla programistów co, jak i kiedy powinni zrobić. Nie jest to łatwe zadanie. Określanie wymagań klienta wobec przyszłego systemu jest zadaniem o kluczowym znaczeniu dla powodzenia projektu. Jest też zadaniem trudnym ze względu na ciągłą zmienność wymagań oraz trudności w uświadomieniu i zwerbalizowaniu przez klienta jego oczekiwań w stosunku do projektowanego systemu.
Faza określania wymagań, w której dokonywana jest identyfikacja wymagań oraz ich dokumentacja w sposób możliwie precyzyjny, powinna być przeprowadzana przy znacznym zaangażowaniu klienta. Zbieranie wymagań powinno być realizowane w sposób iteracyjny. Z doświadczenia wynika, że bardzo rzadko spotyka się sytuację, gdy po jednym spotkaniu udaje się zgromadzić komplet wymagań. Zazwyczaj takich spotkań jest kilka, a nawet kilkanaście. W trakcie każdego z nich lepiej poznajemy oczekiwania klienta, a klient wchodząc w coraz większe szczegóły, staje się coraz bardziej precyzyjny. Wszyscy uczestnicy procesu stopniowo coraz lepiej rozumieją, o co tak naprawdę chodzi w projekcie.
Cel i istota specyfikacji wymagań
Celem fazy określenia wymagań jest ustalenie wymagań klienta wobec tworzonego systemu i zapisanie ich w postaci zrozumiałej dla obydwu stron (klienta i wykonawcy) w spójnym dokumencie. Podczas identyfikowania i definiowania wymagań dokonywana jest zamiana celów klienta określonych w fazie strategicznej na konkretne wymagania zapewniające osiągnięcie tych celów.
Z powodu trudności w pozyskiwaniu wymagań, trudności w ustaleniu, jakie wymagania zapewnią osiągnięcie celów biznesowych i innych czynników omówionych poniżej, faza określania wymagań nie jest prostym zbieraniem wymagań, lecz procesem, w którym klient wspólnie z przedstawicielem dostawcy oprogramowania konstruuje zbiór wymagań zgodny z postawionymi celami i potrzebami biznesowymi.
W przypadku systemów tworzonych na zamówienie, analitycy mają bezpośredni kontakt z przedstawicielami klienta. Faza określania wymagań wymaga zaangażowania ekspertów dziedzinowych, którzy dobrze znają specyfikę danego obszaru biznesowego.
Trudności w zbieraniu wymagań
Jak już zostało wspomniane, określanie wymagań jest etapem o bardzo dużym znaczeniu dla powodzenia projektu, a jednocześnie etapem niezwykle trudnym do poprawnej realizacji. Trudności w określaniu i zbieraniu wymagań wynikają z wielu czynników:
1. Niejasność wymagań i niejednoznaczność rozwiązań
Pierwsza trudność polega na tym, że klient z reguły nie wie dokładnie, w jaki sposób osiągnąć założone cele strategiczne, czyli jakie powinny być wymagania odnośnie funkcjonowania systemu. Dochodzi do tego jeszcze niejednoznaczność rozwiązań polegająca na tym, że cele klienta mogą być osiągnięte na wiele sposobów.
Wspomniana niejednoznaczność może zostać zniwelowana dzięki wcześniejszym etapom procesu wytwórczego. W fazie wizji doprecyzowuje się potrzeby biznesowe, a w fazie koncepcji rozwiązania powstają wymagania biznesowe i wstępnie identyfikuje się (a nawet modeluje) docelowe procesy biznesowe. Dzięki temu niejednoznaczność rozwiązania zostaje ograniczona do minimum.
2. Problemy komunikacyjne
Aby osiągnąć sukces, konieczne jest wzajemne zrozumienie między klientem a wykonawcą. Wykonawca, aby mógł zaprojektować i wykonać system spełniający prawidłowo oczekiwania klienta, musi je dobrze poznać i zrozumieć. Dlatego tak ważny jest dialog między użytkownikiem a zespołem projektowym.
Niedopuszczalna jest sytuacja, w której biznes nie ma czasu na spotkania z zespołem wytwórczym (wykonawcą) lub wydaje polecenie „zróbcie jak uważacie”. Musi to być dialog, musi to być rozmowa, bo w inny sposób nie powstanie jakościowy produkt. Ta komunikacja jest szczególnie akcentowana w podejściach zwinnych (Agile), np. w Scrumie, gdzie Product Owner komunikuje wymagania zespołowi deweloperów.
3. Trudności w precyzyjnym wyrażaniu oczekiwań
Klient musi w sposób precyzyjny, spójny i zrozumiały dla obydwu stron wyrazić swoje oczekiwania wobec budowanego systemu. Niestety, zwerbalizowanie wymagań przez klienta, nawet gdy wie on, czego oczekuje od systemu, nie zawsze jest łatwe.
4. Rozbieżność celów różnych interesariuszy
Dodatkowo duże systemy są wykorzystywane przez wielu użytkowników. Ich cele są często sprzeczne. Różni użytkownicy mogą posługiwać się inną terminologią mówiąc o tych samych problemach. Zleceniodawcy (sponsorzy) i użytkownicy systemu to często inne osoby. Głos zleceniodawców może być w tej fazie decydujący, chociaż nie zawsze potrafią oni właściwie przewidzieć potrzeby przyszłych użytkowników.
Rola projektanta systemu jest więc rolą polegającą na poszukiwaniu i uzgadnianiu wielu kompromisów. Kompromisy te dotyczą wielu obszarów, począwszy od kompromisów w definicji wymagań (wynikających np. z różnych potrzeb różnych użytkowników), poprzez kompromisy technologiczne, aż po ograniczenia czasowe i zasobowe.
Tak więc podczas określania wymagań mamy do czynienia z jednej strony z trudnościami w samej identyfikacji i wyborze wymagań, z drugiej zaś z ich udokumentowaniem w taki sposób, by mogły one posłużyć do zaprojektowania oczekiwanego systemu.
Formy specyfikacji wymagań
Specyfikacja wymagań to częściowo ustrukturyzowany zapis wykorzystujący zarówno język naturalny, jak i proste, częściowo przynajmniej sformalizowane notacje. Specyfikacja oprogramowania to formalny opis wymagań.
Formalna specyfikacja oznacza bardzo dokładne zdekomponowanie wymagań (najlepiej w określonym formularzu) na krótkie punkty, których interpretacja nie powinna nastręczać trudności ani prowadzić do niejednoznaczności. Formalna specyfikacja powinna stanowić podstawę dla fazy testowania.
Cechy dobrego opisu wymagań
Dobry opis wymagań powinien charakteryzować się następującymi cechami:
- Być kompletny oraz niesprzeczny
- Opisywać zewnętrzne zachowanie się systemu, a nie sposób jego realizacji
- Obejmować ograniczenia, przy jakich musi pracować system
- Być łatwy w modyfikacji
- Brać pod uwagę przyszłe możliwe zmiany wymagań wobec systemu
Jednym z najbardziej typowych błędów popełnianych w tej fazie jest koncentrowanie się na sytuacjach typowych i pomijanie wyjątków oraz przypadków granicznych. Zarówno użytkownicy, jak i analitycy mają tendencję do niezauważania sytuacji nietypowych lub skrajnych, być może dlatego, że występują one stosunkowo rzadko.
Proces przygotowania specyfikacji wymagań
Przygotowanie specyfikacji wymagań można podzielić na kilka kluczowych kroków:
Krok 1: Przygotowanie wymagań systemowych
W tym kroku, na podstawie koncepcji rozwiązania, identyfikowane są wymagania funkcjonalne i niefunkcjonalne oraz przypadki użycia. Krok jest wykonywany przy współudziale interesariuszy, a zwłaszcza klienta i użytkowników końcowych.
Działania:
- Analiza otrzymanych artefaktów pod kątem zakresu zmian w systemie/systemach
- Wstępna identyfikacja nowych lub modyfikowanych wymagań systemowych
- Wprowadzenie nowych wymagań systemowych do repozytorium lub aktualizacja istniejących
- Mapowanie wymagań systemowych na wymagania biznesowe (aby sprawdzić, czy wszystkie wymagania biznesowe są adresowane przez wymagania systemowe)
- Przeniesienie dodanych wymagań systemowych na diagram wymagań w repozytorium modyfikacji
- Weryfikacja wpływu nowych/zmienionych wymagań na istniejące artefakty
Wynik: Przygotowane nowe lub zmodyfikowane wymagania systemowe.
Krok 2: Przygotowanie przypadków użycia
Celem opracowania modelu przypadków użycia jest identyfikacja i zamodelowanie planowanych i/lub zmienianych funkcji w systemie. Model przypadków użycia prezentowany jest interesariuszom w celu potwierdzenia i uszczegółowienia realizacji ich wymagań.
Specyfikacja przypadków użycia opisuje przypadek użycia w zakresie:
- Identyfikatora pozwalającego w jednoznaczny sposób odwoływać się do przypadku użycia
- Nazwy określającej cel przypadku użycia
- Opisu określającego cel i odpowiedzialność przypadku użycia
- Przepływu zdarzeń (scenariusza głównego i alternatywnych)
- Warunków wstępnych i końcowych
W szczególnym przypadku, zamiast scenariuszy opisanych słownie, mogą być one przedstawione w postaci diagramu aktywności lub diagramu procesów w notacji BPMN.
Działania dla nowego przypadku użycia:
- Dodanie nowego przypadku użycia z krótkim opisem
- Przeniesienie nowo powstałego przypadku użycia na diagram w repozytorium modyfikacji
- Mapowanie wymagań systemowych na przypadek użycia
- Dodanie scenariuszy głównych, alternatywnych oraz warunków początkowych i końcowych
Działania dla istniejącego przypadku użycia:
- Utworzenie odpowiedniego diagramu i przeniesienie na niego istniejących przypadków użycia, które będą modyfikowane
- Zmiana statusu przypadku użycia (np. na „change”)
- Mapowanie wymagań systemowych na istniejący przypadek użycia
- Przegląd zmian w przypadku użycia i opisanie zakresu zmian
- Naniesienie zmian na scenariusze
Wynik: Model przypadków użycia.
Krok 3: Przygotowanie innych artefaktów
W tym kroku przygotowywane są inne artefakty opisujące działanie systemu, takie jak:
- Ekrany (interfejs użytkownika)
- Diagramy stanów
- Diagramy aktywności
- Tablice decyzyjne
- Model kanoniczny danych
- Model dziedziny
Powyższy katalog artefaktów jest opcjonalny i nie wyczerpuje katalogu potrzebnych w danym przedsięwzięciu artefaktów. Analityk, w zależności od złożoności modyfikacji, wybiera odpowiednie artefakty. Może także dodać inne artefakty spoza listy.
Działania:
- Identyfikacja artefaktów do zmiany
- Budowa odpowiednich modeli lub modyfikacja konkretnych elementów (np. tworzenie interfejsu użytkownika lub opisu jego zmian)
Wynik: Dodatkowe artefakty analityczne.
Krok 4: Przygotowanie dokumentacji
Celem tego działania jest przygotowanie i wygenerowanie specyfikacji wymagań. Zakres danych w dokumentacji powinien być dostosowany do złożoności przedsięwzięcia. Opis ten przedstawia, w jaki sposób system powinien zostać zaimplementowany, aby spełnić wymagania stawiane przed zmianami w systemach.
Zawartość specyfikacji wymagań:
- Model przypadków użycia
- Lista wymagań funkcjonalnych i niefunkcjonalnych
- Opcjonalnie: model GUI
- Opcjonalnie: model maszyny stanowej
- Opcjonalnie: procesy biznesowe (zwłaszcza te uwzględniające integrację)
Warto wykorzystywać narzędzia CASE, takie jak Enterprise Architect lub inne, które pozwalają zautomatyzować proces tworzenia specyfikacji wymagań.
Wynik: Dokument specyfikacji wymagań, który doprecyzowuje oczekiwania użytkowników systemu odnośnie modyfikacji w systemach lub utworzenia nowych systemów. Jest to podstawa do przygotowania przypadków testowych, a także podstawa do wykonania prac implementacyjnych.
Podsumowanie
Specyfikacja wymagań jest kluczowym elementem procesu wytwarzania oprogramowania, zapewniającym zrozumienie potrzeb użytkowników i przekształcenie ich w konkretne wymagania systemowe. Właściwie przygotowana specyfikacja wymagań pozwala na:
- Jednoznaczne zrozumienie oczekiwań klienta
- Określenie zakresu systemu
- Ustalenie podstawy do szacowania kosztów i harmonogramu
- Stworzenie punktu odniesienia dla weryfikacji i walidacji systemu
- Minimalizację ryzyka niezrozumienia wymagań
Pamiętajmy, że proces zbierania i specyfikacji wymagań jest iteracyjny i wymaga ciągłej komunikacji między wszystkimi zainteresowanymi stronami. Tylko dzięki temu możemy stworzyć system, który rzeczywiście spełni oczekiwania użytkowników i przyniesie wartość biznesową.
Spis treści:
