Przygotowanie specyfikacji wymagań na system to działania, które powinny skończyć się w miarę jasnym przekazem dla programistów co i 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ć przeprowadzana w sposób iteracyjny. Z moich doświadczeń wynika, że bardzo rzadko była taka sytuacja, że po jednym spotkaniu miałem komplet wymagań. Czasem tych spotkań było kilka. W każdym z nich lepiej poznawałem oczekiwania klienta. Klient też wchodząc w coraz większe szczegóły był coraz bardziej precyzyjny.
Celem fazy określenia wymagań jest ustalenie wymagań klienta wobec tworzonego systemu i zapisanie ich w postaci zrozumiałego dla obydwu stron (klienta i wykonawcy) spójnego dokumentu. 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ągniecie jego celów i innych czynników, o których mówię dalej, 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ń zgodnie z postawionymi celami.
W przypadku na zamówienie analitycy mają bezpośredni takt z przedstawicielami klienta. Faza określania wymagań wymaga i ekspertów w dziedzinie.
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 wynikają z wielu czynników.
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.
Po drugie, 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.
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.
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 i użytkownicy to często inne osoby. Glos 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 na przykład z różnych potrzeb różnych użytkowników) poprzez kompromisy technologiczne
ograniczeń czasowych.
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
Definicja wymagań przybiera na ogół postać dokumentu opracowanego w języku naturalnym. Opis taki jest rezultatem wstępnych rozmów z klientem, badania dostępnej dokumentacji, systemów spadkowych itp.
Specyfikacja wymagań to częściowo ustrukturalizowany 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 pewnym formularzu) na krótkie punkty, których interpretacja nie powinna nastręczać trudności lub prowadzić do niejednoznaczności. Formalna specyfikacja powinna stanowić podstawę dla fazy testowania.
Przygotowanie koncepcji wymagań to realizacja kilku kroków:
diagramy aktywności
Krok 1. Przygotowanie wymagań systemowych
W tym kroku identyfikowane są na podstawie koncepcji rozwiązania, wymagania funkcjonalne i niefunkcjonalne oraz przypadki użycia. Krok jest wykonywany przy współudziale Interesariuszy, a zwłaszcza klienta
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ń.
Krok 3. Przygotowanie innych artefaktów
W kroku przygotowywane są inne artefakty opisujące działanie systemu takie jak:
- ekrany
- diagramy stanów
- diagramy aktywności
- tablice decyzyjne
Powyższy katalog artefaktów jest opcjonalny i nie wyczerpuje katalogu potrzebnych w danych 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.
Krok 5. 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.
Gdy znane są już wymagania na system warto jest pochylić się nad projektem aplikacji, o czym piszę już w kolejnym wpisie.
Spis treści:
