Specyfikacja wymagań w Inżynierii Oprogramowania

09:21 Jakub Bauman 4 Comments

Aby powstał czy raczej został wdrożony jakiś program, z którego mają w ściśle określonym celu korzystać użytkownicy należy najpierw sprecyzować do czego on ma służyć, jakie funkcje ma realizować.
Użytkownicy czy potencjalni użytkownicy muszą w pewien sposób przekazać programistom czego oczekują od projektowanego rozwiązania czyli przedstawić wymagania dotyczące systemu. Wymagania te, aby ich na przykład nie zapomnieć należy zapisać jako tak zwaną "Specyfikację wymagań".
Wymaganie opisuje co system powinien robić, a specyfikacja stanowi zbiór.
Można więc założyć, że gdy spiszemy co system powinien robić to klient otrzyma oprogramowanie jakiego potrzebuje.
Niestety nie jest tak do końca. Istnieją przynajmniej dwa problemy.

Po pierwsze. Używana przez klienta terminologia często będzie przez nas niezrozumiała lub nie będziemy w stanie stwierdzić o co tak naprawdę chodzi. Gdy np. klient sprecyzuje, że chciałby aby system generował raport sprzedaży. Czy z takiego zapisu będziemy w stanie domyślić się jakie dane ma prezentować ten raport? Klient może użyć na przykład pojęć takich jak: Faktura, raport miesięczny, WZ, PZ, korekta faktury, nota korygująca, SAD, czas przygotowawczo-zakończeniowy, numer LOT. Niektóre z nich zapewne rozszyfrujemy, inne będą dla nas co najmniej zagadkowe.
Po drugie pewne działania wykonywane przez użytkownika mogą być dla niego tak oczywiste, że nie będzie w stanie przekazać nam niezbędnych szczegółów.

Niezrozumienie intencji klienta na etapie projektowania rozwiązania może doprowadzić nie tylko do niezgodnego z oczekiwaniami działania aplikacji, ale również do konfliktów wynikających z opóźnień lub nadmiernej pracochłonności.

Wniosek jest taki, że aby doprecyzować co tak naprawdę ma robić program potrzebujemy dobrze i w sposób zrozumiały zarówno dla klienta jak i dla nas specyfikacji wymagań.
Nietrudno się domyślić, że specyfikację wymagań należy opracować w porozumieniu z klientem.

Nasuwa się pytanie, kogo wysłać aby ustalił z klientem specyfikację wymagań. Nasz programista, nie mający zielonego pojęcia o tym, o czym będzie mówił klient raczej nie jest dobrym pomysłem. Powinniśmy wysłać tam analityka, który życzenia klienta będzie w stanie przedstawić w formie czytelnej dla programisty.

Nasz analityk powinien być:
- doświadczony w zakresie opracowywania specyfikacji wymagań,
- obeznany z funkcjonowaniem branży klienta,
- otwarty na porady ekspertów,
- znający wiele tzw "dobrych praktyk" czyli sprawdzonych metod działania programów.

Mówiąc analityk mamy na myśli niekoniecznie jedną osobę. Może to być, a często nawet powinien być zespół analityków.

Mówiąc o wymaganiach klient przede wszystkim będzie zwracał uwagę na wymagania funkcjonalne czyli charakteryzujące sposób działania systemu. My jako inżynierowie musimy zwrócić uwagę również na pozafunkcjonalne wymagania stawiane oprogramowaniu takie jak związane z bezpieczeństwem, stabilnością, wydajnością, niezawodnością.


Trzy podejścia do zapisu specyfikacji wymagań

Bardzo często wymagania specyfikuje się w jednej z trzech form:

- "System powinien"
- Funkcje systemu
- Przypadki użycia.

System powinien

Specyfikacja wymagań w tej formie to nic innego jak lista zapisów tego co powinien robić system.

- System powinien umożliwiać wystawienie faktury
- System powinien umożliwiać zmianę faktury
- System powinien drukować raport sprzedaży
...

Podejście ma jedną zaletę jaką jest łatwość zapisywania informacji, ma natomiast poważne wady takie jak:
- słaba czytelność,
- trudność sprawdzenia spójności i kompletności wymagań.

Funkcje systemu

Specyfikacja wymagań może być również zapisana za pomocą tzw. funkcji systemu. Definiuje się tu funkcje, które są tzw. czarnymi skrzynkami. Specyfikując system podajemy parametry wejściowe i oczekiwane dane wyjściowe tych funkcji, a czasem również efekty uboczne.


To podejście ma następujące wady. Funkcje są:
- słabo czytelne,
- trudne do zrozumienia.

Przypadki użycia

Metoda zapisywania specyfikacji wymagań w postaci przypadków użycia jest uznawana za najlepszą z tych trzech. Eliminuje ona błędy jakie posiadają poprzednio wymienione sposoby. Dodatkowo jest bardzo precyzyjna. Jako wadę można tu w zasadzie podać tylko pracochłonność i czasochłonność opracowania. Jednak zdaniem autora czas poświęcony na opracowanie przypadków użycia nie będzie czasem straconym.
Wśród zalet tej metody można wymienić:
- łatwość spisywania,
- czytelność,
- łatwość zrozumienia i wyobrażenia sobie przyszłego systemu.

Przykład jednego prostego przypadku użycia przedstawiono poniżej:

UC1: Wystawianie faktury
Główny scenariusz:
1. Sprzedawca pragnie wystawić fakturę.
2. Sprzedawca wpisuje pozycje faktury.
3. System podlicza fakturę, nadaje jej nowy numer i zapisuje w rejestrze
4. Sprzedawca drukuje fakturę.
Zapis przypadku użycia powinien mieć ustrukturyzowaną formę. Powinien zawierać:
- nazwę,
- identyfikator,
- główny scenariusz,
- rozszerzenia,
- atrybuty.


UC1: Wystawianie faktury
Atrybuty:
Główny aktor: Użytkownik
Priorytet: Wysoki
Źródło: Łukasz Nowak
Główny scenariusz:
1. Sprzedawca pragnie wystawić fakturę.
2. Sprzedawca wpisuje pozycje faktury.
3. System podlicza fakturę, nadaje jej nowy numer i zapisuje w rejestrze.
4. Sprzedawca drukuje fakturę.
Rozszerzenia:
3.A. Sprzedawca nie dodał żadnej pozycji
3.A.1. System prosi o ponowne
wprowadzenie pozycji (powrót do 2.)

Więcej informacji o przypadkach użycia będzie można odnaleźć w kolejnych artykułach.