Wymagania stawiane oprogramowaniu

Źródło Ian Sommerville; „Inżynieria oprogramowania” W-wa 2003

Cele

Celem tego rozdziału jest przedstawienie zagadnienia wymagań stawianych systemowi oprogramowania i opisanie różnych sposobów wyrażania tych wymagań. Po przeczytaniu tego rozdziału będziesz:

• rozumieć pojęcie wymagań użytkownika i wymagań systemowych oraz wiedzieć, dlaczego te dwa rodzaje wymagań mogą być zapisywane za pomocą różnych notacji;

• rozumieć różnice między wymaganiami funkcjonalnymi i niefunkcjonalnymi;

• znać dwie metody zapisywania wymagań, tzn. strukturalny język naturalny i opisy oparte na językach programowania;

• wiedzieć, jak wymagania mogą być zorganizowane w dokumentacji wymagań stawianych oprogramowaniu.

Zawartość

1. Wymagania funkcjonalne i niefunkcjonalne

2. Wymagania użytkownika

3. Wymagania systemowe

4. Dokumentacja wymagań stawianych oprogramowaniu

Problemy, które mają rozwiązywać inżynierowie oprogramowania, są często bardzo złożone. Zrozumienie ich natury może być trudne, zwłaszcza w wypadku nowych systemów. Trudno jest zatem dokładnie ustalić, co system powinien robić. Opisy usług i ograniczeń są wymaganiami stawianymi systemowi. Proces wynajdowania, analizowania, dokumentowania oraz sprawdzania tych usług i ograniczeń nosi nazwę inżynierii wymagań. W tym rozdziale skoncentruję się na wymaganiach i sposobach ich opisu. Proces inżynierii wymagań przedstawiłem w rozdziale 3; omówię go bardziej szczegółowo w rozdziale 6.

W przemyśle informatycznym pojęcie wymaganie nie jest stosowane konsekwentnie. Niekiedy wymaganie jest postrzegane jako zapisane na wysokim poziomie, abstrakcyjne określenie usług, które system powinien oferować, albo ograniczenie działania systemu. Niektórzy określają wymaganie jako szczegółową, matematycznie formalną definicję funkcji systemu. Davis (1993) wyjaśnia, dlaczego występują takie rozbieżności:

Jeśli firma chce podpisać kontrakt na wielkie przedsięwzięcie budowy oprogramowania, to musi najpierw określić swoje wymagania w odpowiednio abstrakcyjny sposób, aby z góry nie definiować rozwiązań. Wymagania muszą być spisane, aby różni wykonawcy mogli ubiegać się

ten kontrakt, być może oferując różne sposoby spełnienia oczekiwań firmy-klienta. Gdy kontrakt jest już podpisany, wykonawca musi zapisać dla klienta definicję systemu, podając więcej szczegółów, aby klient mógł zrozumieć i zweryfikować to, co system będzie robił. Oba te dokumenty mogą nosić nazwę dokumentacji wymagań stawianych systemowi.

Niektóre kłopoty pojawiające się w trakcie procesu inżynierii wymagań są konsekwencją braku jasnego rozróżnienia tych dwóch poziomów opisu. Rozgraniczam je za pomocą dwóch pojęć - wymagań użytkownika, które oznaczają abstrakcyjne wymagania wysokiego poziomu, i wymagań systemowych, które są szczegółowym opisem, co system ma robić. Oprócz tych dwóch rodzajów dokumentów może powstać bardziej szczegółowy opis (specyfikacja projektu oprogramowania), który pomaga zapełnić lukę między czynnościami inżynierii wymagań i projektowania. Wymagania użytkownika, wymagania systemowe i specyfikacja projektu oprogramowania mogą być zdefiniowane następująco:

1. Wymagania użytkownika to wyrażenia w języku naturalnym oraz diagramy o usługach oczekiwanych od systemu oraz o ograniczeniach, w których system ma działać.

2. Wymagania systemowe szczegółowo ustalają usługi systemu i ograniczenia. Dokumentacja wymagań systemowych, zwana czasem specyfikacją funkcjonalną, powinna być precyzyjna. Może służyć za kontrakt między nabywcą systemu a wytwórcą oprogramowania.

3. Specyfikacja projektu oprogramowania jest abstrakcyjnym opisem projektu oprogramowania, który jest podstawą bardziej szczegółowego projektu implementacji. Ta specyfikacja dodaje nowe informacje do specyfikacji wymagań systemowych.

Rysunek 5.1 Wymagania użytkownika i systemowe

Rysunek 5.2 Czytelnicy różnych rodzajów specyfikacji

Różne poziomy specyfikacji systemu są użyteczne, ponieważ służą do przekazania informacji o systemie różnym rodzajom czytelników. Na rysunku 5.1 zilustrowano różnice między wymaganiami użytkownika i wymaganiami systemowymi. Pokazano, jak wymaganie użytkownika może być rozszerzone na kilka wymagań systemowych.

Wymagania użytkownika należy pisać dla menedżerów klienta i zleceniobiorcy, którzy nie mają szczegółowej wiedzy technicznej o systemie (rys. 5.2). Specyfikacja wymagań systemowych powinna być przeznaczona dla wyższego rangą personelu technicznego i menedżerów przedsięwzięcia. Tak jak w poprzednim wypadku, ten dokument będzie używany zarówno przez pracowników klienta, jak i zleceniobiorcy. Użytkownicy systemu mogą czytać obydwa te dokumenty. Specyfikacja projektu oprogramowania jest poświęcona głównie implementacji. Powinna być pisana dla inżynierów oprogramowania, którzy będą budować system.

5.1. Wymagania funkcjonalne i niefunkcjonalne

Wymagania stawiane systemom oprogramowania są zwykle dzielone na wymagania funkcjonalne, niefunkcjonalne i dziedzinowe:

1. Wymagania funkcjonalne są stwierdzeniami, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach. W niektórych wypadkach wymagania funkcjonalne określają, czego system nie powinien robić.

2. Wymagania niefunkcjonalne to ograniczenia usług i funkcji systemu. Obejmują ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd.

3. Wymagania dziedzinowe pochodzą z dziedziny zastosowania systemu i odzwierciedlają jej charakterystykę. Mogą być funkcjonalne lub niefunkcjonalne.

W praktyce rozróżnienie między tymi trzema rodzajami wymagań nie jest tak jednoznaczne, jak sugerują to te proste definicje. Wymaganie użytkownika dotyczące zabezpieczeń może pojawić się jako niefunkcjonalne. W wyniku dalszych prac może jednak prowadzić do wymagań z pewnością funkcjonalnych, takich jak potrzeba mechanizmu weryfikacji tożsamości użytkowników. Chociaż to rozróżnienie jest pomocne w czasie omówienia wymagań, należy jednak pamiętać, że ten podział jest w istocie sztuczny.

5.1.1. Wymagania funkcjonalne

Wymagania funkcjonalne stawiane systemowi opisują funkcjonalność lub usługi, które system powinien oferować. Zależą od rodzaju tworzonego oprogramowania, spodziewanych użytkowników oprogramowania i rodzaju wytwarzanego systemu. Gdy mają postać wymagań użytkownika, ich opis jest zwykle bardziej ogólny, natomiast funkcjonalne wymagania systemowe szczegółowo definiują funkcje systemu, jego wejścia, wyjścia, wyjątki itd.

Wymagania funkcjonalne stawiane systemowi oprogramowania mogą być wyrażone na kilka różnych sposobów. Oto trzy wymagania funkcjonalne stawiane systemowi biblioteki uniwersyteckiej (Kotonya i Sommerville, 1998), który ma umożliwić studentom i pracownikom zamawianie książek i dokumentów z innych bibliotek:

1. Użytkownik będzie mógł przeszukać zbiór wszystkich baz danych lub wybrać tylko ich podzbiór.

2. System udostępni odpowiednie narzędzia do oglądania, aby użytkownik mógł czytać dokumenty z magazynu.

3. Każde zamówienie będzie oznaczone unikatowym identyfikatorem (ORDER JD), który będzie można skopiować do pamięci trwałej konta użytkownika.

Są to wymagania użytkownika definiujące konkretne udogodnienia oczekiwane od systemu. Wzięto je z dokumentacji wymagań użytkownika. Pokazują, że wymagania funkcjonalne mogą być zapisywane na rozmaitych poziomach szczegółowości (porównaj wymagania 1 i 3).

Wiele problemów inżynierii oprogramowania wynika z braku ścisłego określenia specyfikacji wymagań. Natura programisty każe mu interpretować niejednoznaczne wymagania tak, aby uprościć implementację. Zwykle nie jest to jednak to, czego chciał klient. Należy opracować nowe wymagania i dokonać zmian w systemie. Opóźnia to dostarczenie systemu i podnosi koszty.

Rozważmy drugie na tej liście wymaganie stawiane systemowi biblioteki, które mówi o „odpowiednich narzędziach do oglądania" zawartych w systemie. System biblioteki może dostarczać dokumenty w rozmaitych formatach. Celem tego wymagania jest zapewnienie narzędzia do oglądania wszystkich tych formatów. Wymaganie to jest jednak zapisane niejednoznacznie i nie stwierdza jasno, że należy dostarczyć narzędzia do każdego formatu dokumentu. Programista działający pod presją czasu może udostępnić po prostu narzędzie do oglądania tekstu i ogłosić spełnienie wymagania.

W zasadzie specyfikacja wymagań funkcjonalnych stawianych systemowi powinna być kompletna i spójna. Kompletność oznacza, że wszystkie potrzebne użytkownikowi usługi powinny być zdefiniowane. Spójność oznacza, że wymagania nie powinny mieć sprzecznych definicji. W praktyce w wypadku wielkich złożonych systemów nie da się osiągnąć kompletności i spójności. Przyczynami tego są swoista złożoność tych systemów oraz fakt, że różne punkty widzenia (por. rozdział 6) są związane ze sprzecznymi potrzebami. Te sprzeczności nie muszą być oczywiste przy pierwszej specyfikacji wymagań. Komplikacje wyłaniają się dopiero po głębszej analizie. Po ich wykryciu w późniejszych fazach cyklu życia należy je wyeliminować z dokumentacji wymagań.

5.1.2. Wymagania niefunkcjonalne

Wymagania niefunkcjonalne, zgodnie ze swoją nazwą, nie dotyczą bezpośrednio konkretnych funkcji systemu. Mogą być związane z pojawiającymi się właściwościami systemu, takimi jak niezawodność, czas reakcji i zajmowanie pamięci. Mogą także definiować ograniczenia systemu, takie jak możliwości urządzeń wejścia-wyjścia i reprezentacje danych używane przez interfejsy systemu.

Wiele wymagań niefunkcjonalnych dotyczy systemu jako całości, a nie poszczególnych cech systemu. Oznacza to, że są one bardziej istotne niż poszczególne wymagania funkcjonalne. Niespełnienie jednego wymagania funkcjonalnego może pogorszyć system, niespełnienie wymagania niefunkcjonalnego systemu może natomiast uczynić go bezużytecznym. Jeśli system samolotu nie spełnia, na przykład, wymagań niezawodności, to nie dostanie certyfikatu bezpieczeństwa. Jeśli system sterujący czasu rzeczywistego nie osiągnie wymaganej efektywności, to funkcje sterujące nie będą działały poprawnie.

Wymagania niefunkcjonalne nie zawsze jednak dotyczą budowanego systemu oprogramowania. Niektóre z nich mogą ograniczać proces tworzenia systemu. Przykładami wymagań stawianych procesowi są specyfikacja standardów jakości, których należy użyć w procesie, stwierdzenie, że projekt należy opracować za pomocą konkretnego zbioru narzędzi CASE, i opis procesu, którego należy przestrzegać.

Wymagania niefunkcjonalne wynikają z potrzeb użytkownika, ograniczeń budżetowych, strategii firmy, konieczności współpracy z innymi systemami sprzętu lub oprogramowania, czynników zewnętrznych, takich jak przepisy o bezpieczeństwie, ustawy chroniące prywatność itd. Na rysunku 5.3 przedstawiono klasyfikację różnych typów wymagań niefunkcjonalnych, które można spotkać.

Rysunek 5.3 Typy wymagań niefunkcjonalnych

Różne typy wymagań niefunkcjonalnych z rys. 5.3 podzieliłem według ich pochodzenia:

1. Wymagania produktowe określają zachowanie produktu. Przykładami są wymagania efektywnościowe dotyczące szybkości działania systemu i jego zapotrzebowania na pamięć, wymagania niezawodności ustalające akceptowalną częstość awarii, wymagania przenośności oraz wymagania użyteczności.

2. Wymagania organizacyjne, które wynikają ze strategii i procedur w firmie - kliencie i w firmie - wytwórcy. Przykładami są standardy procesu, które należy uwzględnić, wymagania implementacyjne, takie jak oczekiwany język programowania lub metoda projektowania, oraz wymagania dostawy, które określają, kiedy należy dostarczyć produkt i jego dokumentację.

3. Wymagania zewnętrzne. Ta szeroka kategoria mieści wszystkie wymagania wynikające z czynników zewnętrznych dla systemu i procesu jego tworzenia. Obejmuje wymagania współpracy, które definiują interakcje systemu z systemami innych firm, wymagania prawne, które należy spełnić, aby system działał zgodnie z prawem, oraz wymagania etyczne, które zapewniają akceptację systemu przez jego użytkowników i społeczeństwo.

Przykład

Wymaganie produktowe

4.C.8. Wszelka niezbędna komunikacja między APSE i użytkownikiem powinna dać się wyrazić za pomocą standardowego zestawu symboli Ady

Wymaganie organizacyjne

9.3.2. Proces tworzenia systemu i końcowe dokumenty powinny być zgodne z procesem i produktami zdefiniowanymi w XYZCo-SP-STAN-95

Wymaganie zewnętrzne

7.6.5. System nie powinien ujawniać operatorom żadnych danych osobowych klientów oprócz nazwisk i numerów identyfikacyjnych

Na rysunku 5.4 przedstawiono przykłady wymagań produktowych, organizacyjnych i zewnętrznych. Wymaganie produktowe dotyczy środowiska wspomagającego programowanie w Adzie (APSE). Ogranicza to swobodę projektantów APSE w wyborze symboli używanych w interfejsie użytkownika APSE. Wymaganie to nie mówi natomiast nic o funkcjonalności APSE i oczywiście jest ograniczeniem, a nie funkcją. Wymaganie organizacyjne ustala, że system ma być tworzony zgodnie ze standardowym w firmie procesem oznaczonym jako XYZCo-SP-STAN-95. Wymaganie zewnętrzne wynika z konieczności spełnienia przez system praw dotyczących ochrony prywatności. Stwierdza, że operatorzy systemu nie powinni mieć dostępu do informacji, która nie jest im niezbędna.

Powszechnie występującym problemem z wymaganiami niefunkcjonalnymi jest fakt, że czasem trudno je zweryfikować. Mogą one być zapisywane w sposób odzwierciedlający ogólne dążenia klienta, takie jak łatwość użycia, zdolność do naprawy po awarii i szybka reakcja na działania użytkownika. Takie wymagania stanowią kłopot dla wytwórców systemu, ponieważ pozostawiają duży margines dla interpretacji i późniejszych konfliktów po dostarczeniu systemu. Rozważmy rys. 5.5 ilustrujący ten problem. Przedstawiono na nim cel systemu dotyczący

Przykład

Cel systemu

System powinien być łatwy w użyciu dla doświadczonych kontrolerów, a sposób jego organizacji powinien zmniejszać liczbę błędów użytkownika

Weryfikowalne wymaganie niefunkcjonalne

Doświadczeni kontrolerzy powinni móc używać wszystkich funkcji systemu po szkoleniu trwającym dwie godziny. Po tym szkoleniu średnia liczba błędów robionych przez doświadczonych użytkowników nie powinna przekroczyć dwóch dziennie

użyteczności systemu oraz sposób jego wyrażenia tak, aby był weryfikowalnym wymaganiem niefunkcjonalnym. Takie wymaganie może być sprawdzone za pomocą testów, co umożliwia stwierdzenie, czy system spełnia cele nakreślone przez użytkownika.

Najlepiej jest, aby wymagania niefunkcjonalne były wyrażone ilościowo za pomocą miar, które można obiektywnie testować. Na rysunku 5.6 przedstawiono kilka sensownych miar, których można użyć do specyfikowania właściwości niefunkcjonalnych systemu. Pomiary wykonywane w trakcie testowania systemu umożliwiają sprawdzenie, czy system spełnia te wymagania.

Właściwość	Miara
Szybkość	Liczba przetworzonych transakcji na sekundę Czas reakcji na zdarzenie wywołane przez użytkownika Czas odświeżenia ekranu
Rozmiar	Kilobajty Liczba układów pamięci RAM
Łatwość użycia	Czas szkolenia Liczba okien pomocy
Niezawodność	Średni czas bez awarii Prawdopodobieństwo niedostępności Częstość błędów Dostępność
Solidność	Czas uruchomienia po awarii Ułamek zdarzeń powodujących awarie Prawdopodobieństwo zniszczenia danych po awarii
Przenośność	Procent poleceń zależnych od platformy Liczba docelowych systemów

Rysunek 5.6 Miary do specyfikowania wymagań niefunkcjonalnych

W praktyce specyfikowanie wymagań ilościowych jest raczej trudne. Klienci mogą nie być w stanie przetłumaczyć swoich celów na wymagania ilościowe. W wypadku niektórych celów, np. łatwości pielęgnacji, nie istnieją miary, których można by użyć. Koszt obiektywnej weryfikacji ilościowych wymagań niefunkcjonalnych może być bardzo wysoki. Dokumentacja wymagań często zawiera zatem określenia celów przemieszane z wymaganiami. Te cele mogą być przydatne dla programistów, ponieważ przekazują pewne wskazówki o priorytetach klienta. Należy jednak powiedzieć klientom, że takie cele mogą być źle zrozumiane i nie da się ich obiektywnie zweryfikować.

Wymagania niefunkcjonalne są często sprzeczne lub powiązane z innymi wymaganiami funkcjonalnymi. Wymaganiem może być na przykład, aby system korzystał z pamięci nie większej niż 4 megabajty, ponieważ cały system będzie umieszczony w pamięci tylko do odczytu i zainstalowany na statku kosmicznym. Innym wymaganiem może być żądanie napisania systemu w Adzie, który jest językiem programowania przeznaczonym do budowania krytycznego oprogramowania czasu rzeczywistego. Skompilowanie programu w Adzie o oczekiwanej funkcjonalności i rozmiarze 4 megabajtów może jednak nie być możliwe. Trzeba przyjąć pewne kompromisy między tymi wymaganiami - wybrać inny język programowania lub dodać do systemu więcej pamięci.

W zasadzie należy odróżnić wymagania funkcjonalne i niefunkcjonalne w dokumentacji wymagań. W praktyce jest to jednak trudne. Jeśli wymagania niefunkcjonalne są postawione niezależnie od wymagań funkcjonalnych, czasem trudno jest zauważyć związki między nimi. Jeśli wymagania funkcjonalne są postawione razem z wymaganiami funkcjonalnymi, może być trudno oddzielić od siebie zagadnienia funkcjonalne i niefunkcjonalne oraz rozpoznać wymagania, które dotyczą systemu jako całości. Należy znaleźć odpowiedni punkt równowagi, który zależy od rodzaju tworzonego systemu. Wymagania, które są oczywiście związane z pojawiającymi się właściwościami systemu, powinny być oznaczone. Można to zrobić, umieszczając je w oddzielnym punkcie dokumentacji wymagań albo jakoś wyróżniając je pośród innych wymagań.

5.1.3. Wymagania dziedzinowe

Wymagania dziedzinowe wynikają bardziej z dziedziny zastosowania systemu niż z konkretnych potrzeb użytkowników. Mogą być nowymi wymaganiami funkcjonalnymi, ograniczać istniejące wymagania funkcjonalne albo ustalać sposób wykonywania konkrrtnych obliczeń. Wymagania dziedzinowe są istotne, ponieważ odzwierciedlają podstawy dziedziny zastosowania. Jeżeli nie są spełnione, to system nie może działać w sposób zadawalający.

Rozważmy następujące wymagania stawiane systemowi biblioteki jako przykłady wymagań dziedzinowych:

1. Wszystkie bazy danych powinny być dostępne przez jednolity interfejs użytkownika, którego podstawą jest standard Z39.50.

2. Ze względu na ochronę praw autorskich niektóre dokumenty należy skasować natychmiast po ich otrzymaniu. Zależnie od wymagań użytkownika, dokumenty te będą drukowane lokalnie na serwerze systemowym i przekazywane do rąk czytelnika albo wysyłane na drukarkę sieciową.

Pierwsze z tych wymagań jest ograniczeniem wymagania funkcjonalnego stawianego systemowi. Stwierdzono w nim, że interfejs użytkownika bazy danych musi być zaimplementowany zgodnie z określonym standardem bibliotecznym. Drugie z tych wymagań pojawiło się ze względu na prawa autorskie dotyczące zawartości bibliotek. Ustalono w nim, że system musi mieć wbudowany mechanizm „skasuj przy drukowaniu" dla niektórych kategorii dokumentów.

Na rysunku 5.7 przedstawiono przykład wymagania dziedzinowego określającego, jak należy przeprowadzić pewne obliczenia. Wzięto je ze specyfikacji automatycznego systemu bezpieczeństwa ruchu pociągów. Ten system samoczynnie zatrzymuje pociąg, jeśli minie on opuszczony semafor. Wymaganie to ustala, w jaki sposób system oblicza tempo zmniejszania prędkości pociągu. Jest sformułowane za pomocą pojęć charakterystycznych dla tej dziedziny. Aby je zrozumieć, trzeba mieć pewną wiedzę na temat działania systemów kolejowych i właściwości pociągów

Rysunek 5.7 Wymagania dziedzinowe z systemu bezpieczeństwa ruchu pociągów

Tempo zmniejszania prędkości pociągu jest wyznaczane następująco:

Dpociągu = Dsterowania + Dnachylenia

przy czym Dnachylenja wynosi 9,81 m/s¹ * wyrównane nachylenie/alfa,

a 9,81 m/s2/alfa są znane dla różnych typów pociągów

To wymaganie stawiane systemowi kolejowemu ilustruje zasadniczy problem z wymaganiami dziedzinowymi. Są one wyrażane za pomocą języka specyficznego dla dziedziny zastosowania, co sprawia, że inżynierowie oprogramowania często ich nie rozumieją. Eksperci z danych dziedzin mogli pominąć tę informację, ponieważ po prostu jest dla nich oczywista. Może nie być jednak oczywista dla twórców systemu, którzy mogą to wymaganie zaimplementować w sposób niesatysfakcjonujący.

5.2. Wymagania użytkownika

Wymagania użytkownika stawiane systemowi powinny określać wymagania funkcjonalne i niefunkcjonalne tak, aby były zrozumiałe dla użytkowników systemu, którzy nie mają szczegółowej wiedzy technicznej. Powinny ustalać jedynie zewnętrzne zachowanie systemu, unikając w największym możliwym stopniu charakterystyki projektu systemu. Wymagania użytkownika nie powinny być zatem definiowane za pomocą modelu implementacyjnego. Należy je zapisywać w języku naturalnym, używając formularzy i prostych intuicyjnych diagramów.

Rozmaite problemy mogą się jednak pojawić, gdy zapisujemy wymagania za pomocą języka naturalnego:

1. Brak jasności – czasami trudno jest wyrażać sie w języku naturalnym precyzyjnie i jednoznacznie bez czynienia dokumentów gadatliwymi i nieczytelnymi

2. Sprzeczność wymagań – Trudno jest jasno rozgraniczyć wymagania funkcjonalne, wymagania niefunkcjonalne, cele systemu i elementy projektu.

3. Łączenie wymagań – Kilka różnych wymagań może być zapisanych razem jako jedno wymaganie.

Ilustracja – jedno z wymagań

4.A.5 Baza danych powinna wspomagać generowanie obiektów sterujących i konfiguracyjnych, tzn obiektów, które same są grupami innych obiektów bazy danyc. Udogodnienia do sterowania konfiguracją powinny umożliwiać dostęp do obiektów w pewnej wersji grupy za pomocą niepełnej nazwy.

Wymaganie to obejmuje informacje zarówno pojęciowe, jak i szczegółowe. Wyraża żądanie, aby integralną częścią APSE były udogodnienia do sterowania konfiguracją. Zawiera także szczegółowe życzenie, aby te udogodnienia umożliwiały dostęp do obiektów w wersji grupy bez podania ich pełnej nazwy. Ten szczegół lepiej było tu pominąć i uwzględnić go w specyfikacji wymagań systemowych.

Dobrym zwyczajem jest oddzielanie w dokumentacji wymagań - wymagań użytkownika od bardziej szczegółowych wymagań systemowych. Jeśli tego nie zrobimy, to zwykli czytelnicy wymagań użytkownika będą przytłoczeni detalami, które są istotne tylko dla techników. Na rysunku 5.9 zilustrowano taki chaos. Ten przykład pochodzi z dokumentacji wymagań stawianych narzędziu CASE do edycji modeli projektów oprogramowania. Użytkownik może zażądać wyświetlenia siatki, aby byty były starannie rozmieszczane na diagramie.

2.6. Udogodnienia siatki. Przez opcję panelu sterowania użytkownik może uaktywnić siatkę w centymetrach lub calach, która będzie pomagała w umieszczaniu bytów na diagramie. Siatka może być włączana i wyłączana w dowolnej chwili sesji edycji; to samo dotyczy przełączania między calami i centymetrami. Opcja siatki będzie dostępna w widoku „zmniejsz, aby dopasować", ale liczba linii siatki będzie wówczas zmniejszona, aby uniknąć zapełnienia małego diagramu liniami siatki

Rys. 5.9 Wymagania stawiane siatce edytora

Pierwsze zdanie łączy trzy różne rodzaje wymagań.

1. Pojęciowe wymaganie funkcjonalne określa, że system edycji powinien udostępniać siatkę. Zawiera uzasadnienie jej potrzeby.

2. Wymaganie niefunkcjonalne ze szczegółową informacją o jednostkach tej siatki (cale lub centymetry).

3. Wymaganie niefunkcjonalne stawiane interfejsowi użytkownika, które określa, jak użytkownik włącza i wyłącza siatkę.

Wymaganie z rys. 5.9 zawiera także pewną, chociaż niepełną informację

inicjowaniu. Stwierdza, że na początku siatka jest wyłączona. Nie definiuje jednak jednostki, której należy użyć po włączeniu. Zawiera szczegółową informację o tym, że użytkownik może zmieniać jednostkę, ale nie podaje odległości między liniami siatki.

Jeśli wymagania użytkownika zawierają zbyt wiele informacji, to ograniczają wolność twórców systemu w wyborze innowacyjnych rozwiązań oraz utrudniają zrozumienie wymagań. Wymagania użytkownika powinny się po prostu koncentrować na głównych oczekiwanych udogodnieniach. Zilustrowano to na rys. 5.10, na którym przedstawiłem wymaganie stawiane siatce edytora przepisane tak, aby omawiano w nim jedynie główne cechy systemu.

Uzasadnienia związane z wymaganiami są istotne. Pomagają wytwórcom i konserwatorom systemu w zrozumieniu, dlaczego takie wymaganie się pojawiło, i w ocenie wpływu zmiany tego wymagania. W uzasadnieniu z rys. 5.10 stwierdzono, że siatka aktywna, przy której układane obiekty automatycznie przeskakują do linii siatki, może być użyteczna. Jednocześnie zdecydowanie odrzucono tę opcję na rzecz układania ręcznego. Gdy w przyszłości pojawi

2.6. Siatka

2.6.1. Edytor będzie udostępniał siatkę, tzn. matrycę linii poziomych i pionowych jako tło okna edytora. Ta siatka powinna być pasywna, tzn. za układanie bytów odpowiada użytkownik

Uzasadnienie: Siatka pomaga użytkownikowi w tworzeniu schludnego diagramu ze starannie poukładanymi bytami. Chociaż siatka aktywna, przy której byty przeskakują do linii siatki, może być użyteczna, jednak wówczas układ diagramu jest nieprecyzyjny. Użytkownik jest najwłaściwszą osobą do decydowania o położeniu bytów

Specyfikacja: ECLIPSE/WS/Tools/DE/FS Punkt 5.6

się propozycja zmiany tej decyzji, będzie jasne, że wybór siatki pasywnej był rozmyślny, a nie implementacyjny.

Kolejny przykład specyficznego wymagania użytkownika, które również definiuje część systemu edycyjnego, przedstawiono na rys. 5.11. Jest to bardziej szczegółowa specyfikacja funkcji. W tym wypadku definicja zawiera listę czynności użytkownika. Jest to czasem niezbędne, aby wszystkie funkcje były realizowane w spójny sposób. Szczegóły implementacyjne nie powinny pojawić się w tej dodatkowej informacji. Ta definicja nie określa zatem, jak ma się poruszać symbol i wskaźnik oraz w jaki sposób następuje wybór typu.

3.5.1. Dodawanie węzłów do projektu

Edytor będzie udostępniał użytkownikom udogodnienia do dodawania do swoich projektów węzłów określonego typu

Sekwencja czynności, które prowadzą do dodania węzła, powinna być następująca:

1. Użytkownik powinien wybrać typ węzła, jaki należy dodać

2. Użytkownik powinien przesunąć wskaźnik do przybliżonego miejsca nowego węzła na diagramie i zalecić dodanie symbolu węzła w tym punkcie

3. Użytkownik powinien następnie przeciągnąć węzeł do jego ostatecznego położenia

Uzasadnienie: Użytkownik jest najwłaściwszą osobą do decydowania o położeniu węzłów na diagramie. Takie podejście daje użytkownikowi całkowite panowanie nad wyborem typu węzła i jego umiejscowieniem

Specyfikacja: ECLIPSE/WS/Tools/DE/FS Punkt 3.5.1

Aby uniknąć nieporozumień przy zapisywaniu wymagań użytkownika, proponuję stosować się do następujących prostych rad:

1. Opracuj standardowy format i spraw, aby wszystkie definicje wymagań były z nim zgodne. Standaryzacja formatu zmniejsza prawdopodobieństwo przeoczeń i zwiększa łatwość weryfikacji wymagań. Format, którego używasz, obejmuje wytłuszczenie wstępnego wymagania, dodawanie zdania uzasadniającego do każdego wymagania użytkownika oraz dodawanie odnośnika do bardziej szczegółowej specyfikacji wymagania systemowego.

2. Konsekwentnie używaj języka. W szczególności rozróżnij wymagania obowiązkowe od wskazanych. Zwykle używa się słowa „będzie" do wymagań obowiązkowych, a „powinien" do oczekiwanych, tak jak na rys. 5.11. System musi zatem obowiązkowo zawierać udogodnienia do dodawania węzłów do projektu. Oczekuje się przy tym, że sekwencja czynności będzie taka, jak wyspecyfikowano. Nie jest to jednak absolutnie niezbędne, jeśli będą ważne powody, dla których nie można zrobić tego w ten sposób.

3. Stosuj wyróżnienia (wytłuszczenia i kursywy) do zaznaczania głównych części wymagania.

4. Unikaj, jak tylko się da, żargonu komputerowego. Nieuniknione jest jednak stosowanie w wymaganiach użytkownika szczegółowych technicznych terminów używanych w dziedzinie zastosowania systemu.

5.3. Wymagania systemowe

Wymagania systemowe są bardziej szczegółowymi opisami wymagań użytkownika. Mogą być podstawą kontraktu na implementację systemu, powinny być zatem pełną i niesprzeczną specyfikacją całego systemu. Są traktowane przez inżynierów oprogramowania jako punkt wyjścia do projektowania systemu.

Specyfikacja wymagań systemowych może zawierać różne modele systemu, takie jak model obiektów lub model przepływu danych. W rozdziale 7 opisuję różne modele, które mogą być użyte w specyfikacji wymagań systemowych.

W zasadzie wymagania systemowe powinny określać, co system ma robić, a nie, jak powinien być zaimplementowany. Poziom szczegółowości niezbędny do wyspecyfikowania systemu w pełni jest tak wysoki, że jest niemal niemożliwe całkowite pominięcie informacji projektowych. Istnieje kilka przyczyn takiej sytuacji:

W dokumentacji wymagań można zdefiniować wstępną architekturę systemu, aby nadać specyfikacji odpowiednią strukturę. Wymagania systemowe są zorganizowane zgodnie z podziałem na podsystemy wchodzące w skład systemu.

W większości wypadków systemy muszą współpracować z innymi istniejącymi systemami. Ograniczają one projekt, co implikuje dodatkowe wymagania stawiane nowemu systemowi.

Użycie specyficznego projektu (np. omówione w rozdziale 18 programowanie w N wersjach, aby osiągnąć niezawodność) może być zewnętrznym wymaganiem systemowym.

Język naturalny jest często używany do pisania specyfikacji wymagań systemowych. Oprócz komplikacji wymienionych w punkcie 5.2, mogą pojawić się dalsze kłopoty z językiem naturalnym, gdy stosuje się go do pisania bardzo szczegółowych specyfikacji:

1. Rozumienie języka naturalnego zależy od tego, czy czytelnicy i autorzy specyfikacji używają tych samych słów do oznaczenia tych samych pojęć.

Niejednoznaczność języka naturalnego prowadzi do nieporozumień. Jackson (1995) daje wyśmienity przykład takiej sytuacji, opisując symbole wyświetlane przez ruchome schody. Mówią one „buty trzeba założyć" i „psy trzeba nieść". Pozostawiam czytelnikowi poszukiwanie sprzecznych interpretacji tych wyrażeń.

Specyfikacje wymagań w języku naturalnym są zbyt elastyczne. Tę samą rzecz można wyrazić na kilka zupełnie różnych sposobów. Do czytelnika należy stwierdzenie, czy dwa wymagania są takie same, czy też się od siebie różnią.

Nie ma łatwego sposobu podziału wymagań w języku naturalnym na moduły. Znalezienie wszystkich powiązanych wymagań może być trudne. Poszukiwanie konsekwencji zmian może wymagać przejrzenia każdego wymagania, a nie jedynie grupy powiązanych wymagań.

Z powodu tych kłopotów specyfikacje wymagań zapisane w języku naturalnym powodują nieporozumienia, które najczęściej pozostają ukryte aż do późnych faz procesu tworzenia oprogramowania i mogą sprawić wiele trudności przy ich wyjaśnianiu.

Notacja	Opis
Strukturalny język naturalny	To podejście polega na definiowaniu standardowych formularzy i szablonów do wyrażania specyfikacji wymagań
Języki opisu projektu	W tym podejściu używa się języka podobnego do języka programowania, ale z bardziej abstrakcyjnymi elementami do specyfi kowani a wymagań poprzez model operacyjny sytemu
Notacje graficzne	Do definiowania wymagań funkcjonalnych stawianych systemowi używa się języka graficznego z tekstowymi dopiskami. Przykładem jednego z pierwszych takich języków graficznych jest SADT (Ross, 1977; Schoman i Ross, 1977). Ostatnio używa się przypadków użycia (Jacobsen i inni; 1993). Omówię je w następnym rozdziale
Specyfikacje matematyczne	Są to notacje oparte na pojęciach matematycznych, takich jak skończone maszyny stanowe lub zbiory. Takie jednoznaczne specyfikacje zmniejszają spory na temat funkcjonalności między klientem a zleceniobiorcą. Większość klientów nie rozumie jednak formalnych specyfikacji i jest niechętna przyjęciu ich jako kontraktu na budowę systemu. Formalne specyfikacje omówię w rozdziale 9

Istnieją rozmaite sposoby alternatywne wobec języka naturalnego, które nadają specyfikacji strukturę i pomagają w redukcji niejednoznaczności. Wymieniono je na rys. 5.12.

Powstały także inne podejścia, np. wyspecjalizowane języki wymagań (Teichrow i Hershey, 1977; Alford, 1977; Bell i inni, 1977; Alford, 1985), ale obecnie są rzadko używane. Davis (1990) podsumowuje i porównuje różne podejścia do specyfikacji wymagań. W tym rozdziale skoncentruję się na dwóch pierwszych metodach, tzn. na strukturalnym języku naturalnym i użyciu języka opisu projektu.

5.3.1. Strukturalny język naturalny

Strukturalny język naturalny jest ograniczoną postacią języka naturalnego, przeznaczoną do zapisywania wymagań systemowych. Zaletą tego podejścia jest to, że - zachowując wyrazistość i zrozumiałość języka naturalnego - zapewnia w pewnym stopniu jednolitość specyfikacji. Notacje oparte na języku strukturalnym mogą ograniczać używaną terminologię i obejmować szablony do spe- cyfikowania wymagań systemowych. Zawierają zwykle konstrukcje sterujące podobne do spotykanych w językach programowania i graficzne wyróżnienia do podziału specyfikacji.

Jedno z przedsięwzięć, w którym do specyfikowania wymagań systemowych zastosowano strukturalny język naturalny, opisał Heninger (1980). Opracowano specjalne formularze do opisywania danych wejściowych, danych wyjściowych i funkcji systemu komputerowego samolotu. Wymagania systemowe wyspecyfikowano za pomocą tych formularzy.

Aby stosować oparte na formularzach podejście do specyfikowania wymagań systemowych, trzeba zdefiniować jeden lub więcej standardowych formularzy lub szablonów do zapisywania tych wymagań. Specyfikacja może być zbudowana wokół obiektów przetwarzanych przez system, funkcji wykonywanych przez system lub zdarzeń obsługiwanych przez system. Przykład takiej formularzowej specyfikacji pokazano na rys. 5.13. Jest to bardziej szczegółowa

ECLIPSE/Workstation/Tools/DE/FS/3.5.1

Funkcja. Dodaj węzeł

Opis. Dodaje węzeł do istniejącego projektu. Użytkownik wybiera typ i położenie węzła. Po dodaniu do projektu węzeł jest zaznaczony. Użytkownik wybiera miejsce węzła przesuwając wskaźnik na obszar, w którym dodano węzeł

Dane wejściowe. Typ węzła, Położenie węzła, Identyfikator projektu

Źródło. Typ węzła i Położenie węzła pochodzą od użytkownika, a Identyfikator projektu z bazy danych

Dane wyjściowe. Identyfikator projektu

Przeznaczenie. Baza danych projektów. Projekt jest utrwalany w bazie danych po zakończeniu operacji

Wymagania. Korzeniem grafu projektu musi być dany identyfikator projektu

Warunek początkowy. Projekt jest otwarty i wyświetlony na ekranie użytkownika

Warunek końcowy. Projekt nie uległ zmianie z wyjątkiem dodania węzła zadanego typu o zadanym położeniu

Efekty uboczne. Nie ma

Definicja: ECLIPSE/Workstation/Tools/DE/RD/3.5.1

definicja funkcji dodania węzła w systemie edycji projektów przedstawionej na rys. 5.11.

Jeśli korzysta się ze standardowych formularzy do definiowania wymagań funkcjonalnych, to należy zawrzeć w nich następujące informacje:

Opis specyfikowanej funkcji lub bytu.

Opis jej danych wejściowych i źródło ich pochodzenia.

Opis jej danych wyjściowych i miejsce ich przeznaczenia.

Określenie, z których innych bytów się korzysta (część wymaga).

Jeśli użyto podejścia funkcjonalnego, to jest wywołany warunek początkowy, który musi być prawdziwy przed wywołaniem tej funkcji, oraz warunek końcowy, który musi być prawdziwy po wywołaniu funkcji.

Opis efektów ubocznych operacji (jeśli występują).

Stosowanie formatowanych specyfikacji pozwala uniknąć pewnych problemów związanych ze specyfikacjami w języku naturalnym, ponieważ zmniejsza zmienność specyfikacji i ułatwia efektywny podział wymagań. Pewne niejednoznaczności mogą jednak w specyfikacjach pozostać. Inne metody, które obejmują korzystanie z bardziej strukturalnych notacji, takich jak PDL (omówiony poniżej), idą dalej w rozwiązywaniu problemu niejednoznaczności. Niespecja- liści uważają je jednak za trudniejsze do zrozumienia.

5.3.2. Specyfikacje wymagań w PDL

Niejednoznaczności charakterystycznych dla języka naturalnego można uniknąć przez opisywanie wymagań operacyjnie za pomocą języka opisu programów (Program Description Language, PDL). PDL jest językiem podobnym do języków programowania takich jak Java i Ada. Może zawierać dodatkowe, abstrakcyjne konstrukcje, które zwiększają jego wyrazistość. Zaletą użycia PDL jest możliwość automatycznej kontroli składniowej i znaczeniowej za pomocą narzędzi programowych. Na podstawie wyników tego sprawdzenia można przewidzieć przeoczenia i sprzeczności w wymaganiach.

Specyfikacje zapisane w języku PDL są bardzo szczegółowe, a czasami zbyt bliskie implementacji, aby zamieścić je w dokumentacji wymagań. Proponuję używać PDL w dwóch następujących sytuacjach:

Gdy operacja jest specyfikowana jako ciąg prostszych akcji, których kolejność wykonania jest istotna. Opisy takich sekwencji w języku naturalnym są czasami mylące, zwłaszcza gdy te ciągi obejmują zagnieżdżone warunki i pętle. Pokazano to na rys. 5.14, na którym przedstawiono część specyfikacji bankomatu. Użyłem Javy jako PDL, ale celowo pominąłem pewne fragmenty, aby oszczędzić miejsce. Pełny opis bankomatu w Javie można ściągnąć z witryny WWW tej książki.

Gdy trzeba wyspecyfikować interfejsy sprzętowe i programowe. W wielu wypadkach interfejsy między podsystemami są definiowane w specyfikacji wymagań systemowych. PDL umożliwia definiowanie typów i obiektów interfejsowych.

class Bankomat { // tu deklaracje

public static void main (String args[]) throws ZłaKarta { try {

taKarta.odczytaj(); // może zgłosić wyjątek ZłaKarta pin = Klawiatura.odczytajPin(); próby = 1; while (!taKarta.pin.equals(pin) & próby < 4)

{ pin = Klawiatura.odczytajPin(); próby = próby + 1;

}

if (ItaKarta. pin.equals(pin)) throw new ZłaKarta („Zły PIN"); toSaldo = taKarta.odczytajSaldo(); do { Ekran.pytanie(„Wybierz usługę"); usługa = Ekran.dotkniętyKlawisz(); switch (usługa) {

case Usługi.wypłataZPokwitowaniem:

wymaganePokwitowanie = true; case Usługi.wypłataBezPokwitowania: kwota = Klawiatura.odczytajKwotę(); if (kwota > toSaldo)

{ Ekran.wyświetlKomunikat(„Za małe saldo"); break;

}

Kaseta, dostarcz (kwota); noweSaldo = toSaldo - kwota; if (wymaganePokwitowanie)

Pokwitowanie.drukuj(kwota, noweSaldo); break;

// tu opisy innych usług

default: break;

}

}

while (usługa != Usługi.koniec);

taKarta.zwróćUżytkownikowi(„Odbierz proszę swoją kartę");

}

catch (ZłaKarta w)

{ Ekran. wyświetlKomunikat(„Zła karta lub PIN"); }

// tu obsługa innych wyjątków

} // main() } // Bankomat

Jeśli czytelnik wymagań systemowych zna PDL użyty do ich zapisania, to ten sposób formułowania wymagań sprawia, że są one bardziej jednoznaczne i łatwiejsze do zrozumienia. Jeśli ten PDL jest oparty na języku implementacji, to przejście od wymagań do projektu jest naturalne. Zmniejsza to możliwości nieporozumień. Autorzy specyfikacji nie muszą poznawać kolejnego języka opisu.

Są także pewne wady tego podejścia do specyfikowania wymagań:

Język używany do zapisu specyfikacji może nie być wystarczająco wyrazisty, aby określić funkcjonalność systemu.

Notacja jest zrozumiała jedynie dla osób, które znają podstawy języków programowania.

3. Wymaganie może być potraktowane jako specyfikacja projektu, a nie jako model, który ma pomóc użytkownikom w zrozumieniu systemu.

Dobrym sposobem stosowania tego podejścia do specyfikowania jest połączenie go z używaniem strukturalnego języka naturalnego. Do ogólnej specyfikacji systemu można użyć metody opartej na formularzach. PDL może służyć do bardziej szczegółowego definiowania sekwencji sterujących i interfejsów.

5.3.3. Specyfikacja interfejsów

Większość systemów oprogramowania musi współdziałać z innymi systemami, które już zaimplementowano i zainstalowano w ich środowisku. Jeśli nowy system i istniejące systemy muszą pracować razem, to interfejsy istniejących systemów muszą być precyzyjnie wyspecyfikowane. Te specyfikacje powinny powstać we wczesnych fazach procesu i znaleźć się (być może w dodatku) w dokumentacji wymagań.

Są trzy typy interfejsów, które należy zdefiniować:

Interfejsy proceduralne, dzięki którym istniejące podsystemy oferują usługi dostępne przez wywoływanie procedur interfejsowych.

Struktury danych, które są przekazywane między podsystemami. W tym celu można użyć PDL opartego na Javie, przy czym struktury danych są opisywane jako definicje klas, w których atrybuty reprezentują pola struktury. Sądzę jednak, że do tego typu opisów lepiej nadają się diagramy encja-związek opisane w rozdziale 7.

Reprezentacje danych (np. porządek bitów), które określono dla istniejących podsystemów. Java nie umożliwia specyfikowania reprezentacji tak szczegółowo. Odradzam więc używanie w tym celu PDL opartego na Javie.

Formalne notacje, omówione w rozdziale 9, umożliwiają definiowanie interfejsów w sposób jednoznaczny, ale ich wyspecjalizowana natura oznacza, że są niezrozumiałe bez odrębnego szkolenia. Rzadko stosuje się je w praktyce, chociaż, moim zdaniem, świetnie się do tego celu nadają. Mniej formalne opisy interfejsów w PDL są kompromisem między zrozumiałością a precyzją, ale na pewno są bardziej precyzyjne niż specyfikacje interfejsów w języku naturalnym.

Na rysunku 5.15 pokazano przykład definicji interfejsu pierwszego z tych dwóch typów. W tym wypadku jest to interfejs proceduralny serwera drukowania, który zarządza kolejką zleceń wydruku plików na kilku drukarkach. Użytkownicy mogą badać stan kolejek związanych z drukarkami i usuwać z kolejek zlecenia drukowania. Mogą także przenieść zlecenie z jednej kolejki do drugiej.

Specyfikacja z rys. 5.15 jest abstrakcyjnym modelem serwera drukowania, który nie ujawnia szczegółów interfejsu. Funkcjonalność operacji tego interfejsu może być zdefiniowana za pomocą strukturalnego języka naturalnego (rys. 5.10), PDL opartego na Javie (rys. 5.14) lub formalnej notacji omówionej w rozdziale 9.

interface SerwerDrukowania {

// definiuje abstrakcyjny serwer drukowania // wymaga: interface Drukarka, interface DokumentDoWydruku // udostępnia: inicjuj, drukuj, wyswietIKolejkęZadań, anulujZadanieDrukowania, // zmieńDrukarkę

void inicjuj (Drukarka d);

void drukuj (Drukarka d, DokumentDoWydruku w); void wyswietIKolejkęZadań (Drukarka d);

void anulujZadanieDrukowania (Drukarka d, DokumentDoWydruku w); void zmieńDrukarkę (Drukarka d1, Drukarka d2, DokumentDoWydruku w); } // SerwerDrukowania

5.4. Dokumentacja wymagań stawianych oprogramowaniu

Dokumentacja wymagań stawianych oprogramowaniu (nazywana czasem specyfikacją wymagań stawianych oprogramowaniu lub Software Reąuirements Specification, SRS) jest oficjalną deklaracją tego, co jest wymagane od wytwórców systemu. Powinna zawierać zarówno wymagania użytkownika stawiane systemowi, jak i szczegółową specyfikację wymagań systemowych. W niektórych wypadkach wymagania użytkownika i wymagania systemowe mogą być połączone w jeden opis. W pozostałych wypadkach wymagania użytkownika stanowią wstęp do specyfikacji wymagań systemowych. Jeśli liczba wymagań jest bardzo duża, to szczegółowe wymagania systemowe mogą być umieszczone w oddzielnych dokumentach.

Dokumentacja wymagań ma różnych użytkowników, od głównych menedżerów firmy, która płaci za system, do inżynierów odpowiedzialnych za tworzenie systemu. Na rysunku 5.16 wziętym z książki Kotonya i Sommerville'a, (1998) przedstawiono prawdopodobnych użytkowników tego dokumentu i sposób, w jaki z niego korzystają.

Heninger (1980) proponuje sześć wymagań, które powinny być spełnione przez dokumentację wymagań:

Powinna określać zachowanie systemu jedynie z zewnątrz.

Powinna określać ograniczenia implementacji.

Powinno być łatwo ją zmieniać.

Powinna być informatorem dla konserwatorów systemu.

Powinna obejmować przewidywania przyszłego cyklu życia systemu.

Powinna charakteryzować akceptowalne reakcje na niepożądane zdarzenia.

Chociaż ta lista ma więcej niż 20 lat, wciąż zawiera cenne rady. Czasem jest jednak trudno wyspecyfikować system przez to, co będzie robić (jego zewnętrzne zachowanie). Z powodu ograniczeń wynikających z obecności istniejących systemów, nie da się uniknąć ograniczeń projektu systemu, które muszą być odzwierciedlone w dokumentacji wymagań. Inne rady, takie jak konieczność zapisywania przewidywań co do cyklu życia systemu, są powszechnie akceptowane, ale niezbyt często stosowane przy formułowaniu dokumentacji wymagań.

Kilka różnych wielkich organizacji, takich jak Departament Obrony Stanów Zjednoczonych i IEEE, zdefiniowało standardy dokumentacji wymagań. Davis (1993) omawia niektóre z nich i porównuje ich zawartość. Najbardziej znanym standardem jest IEEE/ANSI 830-1993 (IEEE, 1993). Thayer i Dorfman (1997) w swoich wyśmienitych artykułach o inżynierii wymagań zamieścili pełną specyfikację tego standardu. Proponuje on następującą strukturę dokumentacji wymagań:

Wstęp

Przeznaczenie tej dokumentacji wymagań

Zakres produktu

Definicje, akronimy i skróty

Odnośniki

Przegląd pozostałej części dokumentu

Ogólny opis

2.1. Wizja produktu

Funkcje produktu

Charakterystyka użytkowników

Ogólne ograniczenia

Założenia i zależności

Szczegółowe wymagania obejmujące wymagania funkcjonalne, niefunkcjonalne i interfejsy. Jest to niewątpliwie najbardziej istotna część dokumentu, ale - ze względu na ogromną różnorodność praktyki w firmach - definiowanie standardowej struktury tego punktu nie jest właściwe. W wymaganiach można udokumentować interfejsy zewnętrzne, opisać funkcjonalność i efektywność systemu, wyspecyfikować oczekiwania wobec logicznej bazy danych, ograniczenia projektowe, pojawiające się właściwości systemu i charakterystyki jakości.

Dodatki

Skorowidz

Standard IEEE nie jest idealny, zawiera jednak bardzo wiele cennych rad, jak pisać wymagania i unikać problemów. Jest zbyt ogólny, aby sam mógł być standardem firmowym. Można go jednak dostosować i zaadaptować tak, aby uzyskać definicję standardu, który można wykorzystać dla potrzeb konkretnego przedsiębiorstwa. Na rysunku 5.17 przedstawiono przykładową strukturę dokumentacji wymagań opartej na standardzie IEEE. Rozszerzyłem ją jednak tak, żeby zgodnie z sugestią Heningera zawrzeć w niej również informacje o przewidywanej ewolucji systemu.

Informacja zawarta w dokumentacji wymagań musi zależeć od typu budowanego oprogramowania i zastosowanego podejścia do tworzenia. Jeśli przyjęto na przykład ewolucyjne wytwarzanie produktu programowego, to dokumentacja wymagań nie obejmie wielu spośród zaproponowanych wcześniej szczegółowych rozdziałów. W takim wypadku projektanci i programiści muszą polegać na swoim rozsądku, gdy podejmują decyzje, jak spełnić ogólnikowe wymagania użytkownika stawiane systemowi.

Gdy budowane oprogramowanie jest częścią wielkiego przedsięwzięcia inżynierii systemów obejmującego interakcje systemów sprzętu i oprogramowania, zwykle niezbędne jest definiowanie wymagań na bardzo dużym poziomie szczegółowości. Oznacza to', że dokumentacja wymagań będzie zapewne bardzo długa. Powinna wówczas zawierać większość z rozdziałów wymienionych na rys. 5.17. W długich dokumentach należy koniecznie umieścić wyczerpujący spis treści i skorowidz, aby czytelnicy mogli łatwo odnaleźć interesującą ich informację.

Rozdział	Opis 1
Przedmowa	Należy się w niej określić, dla jakich czytelników jest ten dokument, oraz opisać historię jego wersji wraz z uzasadnieniem tworzenia każdej nowej wersji i podsumowaniem zmian wprowadzonych w każdej wersji
Wstęp	Należy w nim wyjaśnić, dlaczego ten system jest potrzebny. Należy krótko opisać funkcje systemu i sposób jego współpracy z innymi systemami. Należy również przedstawić, jak system przystaje do ogólnych celów gospodarczych i strategicznych firmy, która go kupuje
Słownik	Należy tu zdefiniować techniczne pojęcia używane w dokumencie. Nie należy robić żadnych założeń o doświadczeniach i wiedzy czytelnika
Definicja wymagań użytkownika	W tym punkcie należy opisać usługi dostarczane użytkownikowi i wymagania niefunkcjonalne systemu. W tym opisie można posłużyć się językiem naturalnym, diagramami lub inną notacją zrozumiałą dla klientów. Powinno się także określić obowiązujące standardy dotyczące produktu i procesu
Architektura systemu	W tym rozdziale należy przedstawić ogólny przegląd spodziewanej architektury systemu, z której wynika podział funkcji między modułami systemu. Należy wyróżnić ponownie użyte komponenty architektoniczne
Specyfikacja wymagań systemowych	Tu należy bardziej szczegółowo opisać wymagania funkcjonalne i niefunkcjonalne. Jeśli jest to konieczne, to można uszczegółowić także wymagania niefunkcjonalne, np. zdefiniować interfejsy do innych systemów
Modele systemu	Tu należy ustalić jeden lub więcej modeli systemu, w których odzwierciedlono związki między jego komponentami oraz system i jego środowisko. Mogą to być modele obiektowe, modele przepływu danych lub znaczeniowe modele danych
Ewolucja systemu	Powinno się tu opisać główne założenia systemu i przewidywane modyfikacje, które nastąpią w wyniku ewolucji sprzętu, zmiany potrzeb użytkowników itd.
Dodatki	Należy w nich przedstawić szczegółową, specyficzną informację związaną z budowanym programem użytkowym. Przykładami dodatków są opisy sprzętu i opisy bazy danych. W wymaganiach sprzętowych definiuje się konfiguracje minimalną i optymalną. W wymaganiach bazy danych określa się logiczną organizację danych używanych przez system i związki między tymi danymi
Skorowidz	Do dokumentu można dołączyć kilka skorowidzów. Oprócz skorowidza alfabetycznego mogą to być skorowidz diagramów, skorowidz funkcji itd.

GŁÓWNE TEZY

I W wymaganiach stawianych systemowi oprogramowania robić, oraz definiuje ograniczenia działania i implementac

I Wymagania funkcjonalne to charakterystyki usług, które sposobu przeprowadzania pewnych obliczeń. Wymagania cjonalne, wynikające z cech dziedziny zastosowania.

I Wymagania niefunkcjonalne dzieli się na wymagania pr dowany system, wymagania procesu, które dotyczą proc zewnętrzne. Zwykle są powiązane z pojawiającymi się w stosują się do systemu jako całości.

I Wymagania użytkownika są przeznaczone dla osób, które w system. Należy spisać je za pomocą języka naturalnego zrozumiałe.

I Wymagania systemowe służą do poinformowania w prei re system ma spełniać. Aby uniknąć niejednoznaczność jakiegoś języka strukturalnego. Może to być strukturalna oparty na języku programowania wysokiego poziomu lub s wymagań.

I Dokumentacja wymagań stawianych oprogramowaniu jest systemowych. Należy nadać jej odpowiednią strukturę, a przez klientów systemu, jak i wytwórców oprogramowania

SUGEROWANE LEKTURY

Requirements Engineering: Processes and Techniques. W książ cesu inżynierii wymagań i przedstawiono szczególne techni tonya, I. Sommerville, 1998, John Wiley and Sons)

Software Requirements Engineering. Jest to wybór artykułów, m.in. „Recommended practice for software requirements spe< standard dokumentacji wymagań opracowany przez IEEE. 1997, IEEE Computer Society Press)

ĆWICZENIA

5.1. Przemyśl problemy związane z użyciem języka naturalni kownika i wymagań systemowych. Korzystając z przykłś struktury językowi naturalnemu za pomocą formularzy

GŁÓWNE TEZY

I W wymaganiach stawianych systemowi oprogramowania ustala się, co system powinien robić, oraz definiuje ograniczenia działania i implementację.

I Wymagania funkcjonalne to charakterystyki usług, które system ma oferować, albo opisy sposobu przeprowadzania pewnych obliczeń. Wymagania dziedzinowe to wymagania funkcjonalne, wynikające z cech dziedziny zastosowania.

) Wymagania niefunkcjonalne dzieli się na wymagania produktowe, które ograniczają budowany system, wymagania procesu, które dotyczą procesu tworzenia, oraz wymagania zewnętrzne. Zwykle są powiązane z pojawiającymi się właściwościami systemu, a zatem stosują się do systemu jako całości.

I Wymagania użytkownika są przeznaczone dla osób, które mają używać i zaopatrywać się w system. Należy spisać je za pomocą języka naturalnego, tabel i diagramów tak, aby były zrozumiałe.

I Wymagania systemowe służą do poinformowania w precyzyjny sposób o funkcjach, które system ma spełniać. Aby uniknąć niejednoznaczności, można je zapisać za pomocą jakiegoś języka strukturalnego. Może to być strukturalna postać języka naturalnego, język oparty na języku programowania wysokiego poziomu lub specjalny język do specyfikowania wymagań.

I Dokumentacja wymagań stawianych oprogramowaniu jest uzgodnionym zapisem wymagań systemowych. Należy nadać jej odpowiednią strukturę, aby mogła być używana zarówno przez klientów systemu, jak i wytwórców oprogramowania.

Wymagania dziedzinowe wynikają bardziej z dziedziny zastosowania systemu niż z konkretnych potrzeb użytkowników. Mogą być nowymi wymaganiami funkcjonalnymi, ograniczać istniejące wymagania funkcjonalne albo ustalać sposób wykonywania konkretnych obliczeń. Wymagania dziedzinowe są istotne, ponieważ odzwierciedlają podstawy dziedziny zastosowania. Jeśli nie są spełnione, to system nie może działać w sposób zadowalający.

Rozważmy następujące wymagania stawiane systemowi biblioteki jako przykłady wymagań dziedzinowych:

1. Wszystkie bazy danych powinny być dostępne przez jednolity interfejs użytkownika, którego podstawą jest standard Z39.50.

1. Brak jasności. Czasem trudno jest wyrażać się w języku naturalnym precyzyjnie i jednoznacznie bez czynienia dokumentów gadatliwymi i nieczytelnymi.

2. Sprzeczność wymagań. Trudno jest jasno rozgraniczyć wymagania funkcjonalne, wymagania niefunkcjonalne, cele systemu i elementy projektu.

3. Łączenie wymagań. Kilka różnych wymagań może być zapisanych razem jako jedno wymaganie.

Jako ilustrację takich problemów rozważmy jedno z wymagań stawianych środowisku programisty w Adzie przedstawione na rys. 5.8.

4.A.5. Baza danych powinna wspomagać generowanie obiektów sterujących i konfiguracyjnych, tzn. obiektów, które same są grupami innych obiektów bazy danych. Udogodnienia do sterowania konfiguracją powinny umożliwiać dostęp do obiektów w pewnej wersji grupy za pomocą niepełnej nazwy

---