1. Wstęp

We wstępie znajdują się informacje ogólne pomagające czytelnikom zrozumieć, jak zorganizowany jest SRS i jak z niego korzystać.

1.1. Cel

Zidentyfikuj (łącznie z numerem wersji lub wydania) produkt albo aplikację, których wymagania zostały w tym dokumencie wyspecyfikowane. Jeśli SRS dotyczy tylko części złożonego systemu, zidentyfikuj tę część albo podsystem. Opisz różne grupy czytelników, takie jak programiści, menedżerowie projektu, pracownicy działu marketingu, użytkownicy, testerzy albo autorzy dokumentacji, dla których przeznaczony jest ten dokument.

1.2. Konwencje użyte w dokumencie

Opisz wszelkie standardy oraz użyte w dokumencie konwencje typograficzne. Wytłumacz znaczenie poszczególnych stylów tekstu, wyróżnień i notacji. Jeśli oznaczenia wymagań są dodawane ręcznie, możesz tu wyjaśnić użyty w tym celu format, dzięki czemu każdy, kto zechce dodać w przyszłości nowe wymaganie, będzie mógł to zrobić.

1.3. Zakres projektu

Zamieść krótki opis specyfikowanego oprogramowania oraz jego cel. Odnieś oprogramowanie do celów użytkowników albo firmy oraz do celów i strategii biznesowych. Jeśli dostępny jest odrębny dokument wizji i zakresu lub podobna dokumentacja, nie powielaj tu ich zawartości, lecz zamieść do niego odsyłacz. SRS specyfikujący przyrostowe wydanie ewoluującego produktu powinien zawierać własną deklarację zakresu w postaci podzbioru długoterminowej, strategicznej wizji produktu.

Możesz zamieścić tutaj także wysokopoziomowe podsumowanie głównych funkcjonalności, które zawiera dane wydanie produktu, albo ważne funkcje, które produkt ten pełni.

1.4. Materiały uzupełniające

Wymień wszystkie dokumenty oraz inne zasoby, do których odwołuje się SRS. Jeśli mają one stałe lokalizacje, zamieść do nich łącza. Materiałami tymi mogą być przewodniki po stylach interfejsu użytkownika, kontrakty, standardy, specyfikacje wymagań systemowych, specyfikacje interfejsów albo specyfikacje SRS podobnych produktów. Zamieść informacje, na podstawie których użytkownik będzie mógł dotrzeć do każdego z tych materiałów, takie jak ich tytuły, autorzy, numery wersji, daty, źródła, miejsca przechowywania albo adresy URL.

2. Opis ogólny

W sekcji tej znajduje się wysokopoziomowe omówienie produktu oraz środowiska, w którym będzie on używany, jego użytkowników oraz znanych ograniczeń, założeń i zależności.

2.1. Perspektywa produktu

Opisz kontekst produktu i jego pochodzenie. Czy jest on nowym członkiem rozrastającej się linii produktów, kolejną wersją dojrzałego systemu, zastępstwem istniejącej aplikacji, czy może zupełnie nowym rozwiązaniem? Jeśli SRS definiuje składnik większego systemu, napisz, jaki jest związek tego oprogramowania z całością systemu oraz zidentyfikuj najważniejsze interfejsy, które je łączą. Weź pod uwagę możliwość dołączenia modeli graficznych (opisanych w rozdziale 5.), takich jak diagram kontekstowy albo mapa ekosystemu, ukazujących związki produktu z innymi systemami.

2.2. Klasy oraz charakterystyki użytkowników

Zidentyfikuj różne klasy użytkowników, którzy zgodnie z Twoimi oczekiwaniami będą korzystać z tego produktu, i opisz ich najważniejsze cechy.

Niektóre wymagania mogą odnosić się wyłącznie do określonych klas użytkowników. Zidentyfikuj klasy uprzywilejowane. Klasy użytkowników reprezentują podzbiory interesariuszy opisanych w dokumencie wizji i zakresu. Opisy tych klas są zasobami wielokrotnego użytku. Jeśli dostępny jest główny katalog klas użytkowników, możesz nie uwzględniać opisów tych klas, tylko odesłać czytelnika do katalogu, dzięki czemu informacje nie zostaną w tym miejscu powielone.

2.3. Środowisko operacyjne

Opisz środowisko, w którym oprogramowanie będzie funkcjonować, łącznie z platformą sprzętową, systemami operacyjnymi i ich wersjami, położeniami geograficznymi użytkowników, serwerów i baz danych, a także organizacjami hostującymi spokrewnione bazy danych, serwery oraz strony internetowe. Wymień pozostałe składniki oprogramowania albo aplikacje, z którymi Twój system będzie musiał pokojowo współistnieć. Jeśli podczas opracowywania nowego systemu muszą zostać przeprowadzone rozległe prace związane z infrastrukturą techniczną, zastanów się nad utworzeniem odrębnej specyfikacji wymagań, która doprecyzuje te prace.

2.4. Ograniczenia projektu oraz implementacji

Zdarzają się sytuacje, w których należy użyć określonego języka programowania, konkretnej biblioteki kodu, na której opracowanie poświęcono czas itd. Opisz wszystkie przesłanki kryjące się za ograniczeniami oraz czynniki, które będą limitować opcje dostępne dla programistów. Wymagania, które zamiast potrzeb zawierają pomysły na ich rozwiązanie albo zostały napisane w postaci rozwiązań, często niepotrzebnie narzucają ograniczenia projektowe, zwracaj zatem na nie szczególną uwagę.

2.5. Założenia i zależności

Założenie to stwierdzenie, które jest uważane za prawdziwe w przypadku braku rozstrzygających dowodów albo informacji na jego temat. Jeśli założenia są błędne, nieaktualne, ulegną zmianie albo będą inaczej postrzegane przez różne osoby, mogą pojawić się problemy, które przełożą się na ryzyka projektowe. Jeden z czytelników specyfikacji SRS może przyjąć, że produkt będzie zgodny z pewnym wzorcem interfejsu użytkownika, podczas gdy drugi czytelnik założy coś innego. Programista może zakładać, że określony zestaw funkcjonalności zostanie specjalnie napisany pod konkretną aplikację, analityk biznesowy będzie pewien, że funkcjonalności te zostaną przeniesione z wcześniejszego projektu, a menedżer projektu będzie oczekiwać, że będą one pochodzić z komercyjnej biblioteki z funkcjami.

Uwzględniane w tej sekcji założenia dotyczą funkcjonalności systemu; założenia biznesowe mają swoje miejsce w dokumencie wizji i zakresu.

Zidentyfikuj zależności Twojego systemu albo projektu od czynników zewnętrznych bądź składników, na które nie ma on wpływu. Zależność występuje na przykład wtedy, gdy przed uruchomieniem Twojej aplikacji należy zainstalować platformę Microsoft .NET Framework w wersji 4.5 lub nowszej.

3. Funkcjonalności systemu

Istnieją różne możliwości uporządkowania wymagań funkcjonalnych. Płaskie (jeden wykaz funkcji), według obszarów funkcjonalności, przepływów procesów, przypadków użycia, trybów działania, klas użytkowników, bodźców i reakcji. Możliwe jest także hierarchiczne łączenie tych elementów, jak na przykład uwzględnienie przypadków użycia w obrębie klas użytkowników. Nie istnieje jedyny słuszny wybór. Przyjmij taką metodę podziału, która ułatwi czytelnikom dokumentu zrozumienie planowanych funkcjonalności systemu.

Schemat funkcjonalności systemu opiszemy na przykładzie.

3.x. Funkcjonalność X

W kilku słowach zdefiniuj nazwę funkcjonalności, np. „3.1. Kontrola pisowni”. Dla każdej

funkcjonalności systemu powtórz sekcję 3.x razem z sekcjami 3.x.1 i 3.x.2.

3.x.1. Opis

Podaj krótki opis danej funkcjonalności i określ jej priorytet (wysoki, średni albo niski). Priorytety często są dynamiczne i zmieniają się podczas trwania prac nad projektem. Jeśli korzystasz z narzędzia do zarządzania wymaganiami, zdefiniuj atrybut wymagania opisujący priorytet.

3.x.2. Wymagania funkcjonalne

Wymień wymagania funkcjonalne związane z daną funkcjonalnością. Są to możliwości oprogramowania, które powinny zostać zaimplementowane, zanim użytkownik będzie mógł skorzystać z tej funkcjonalności albo zrealizować przypadek użycia. Opisz, jak produkt powinien reagować na możliwe do przewidzenia błędy oraz niewłaściwe dane wprowadzane przez użytkownika i jego nieprawidłowe zachowania. Każde wymaganie funkcjonalne oznacz niepowtarzalną etykietą, jak to opisano wcześniej w tym rozdziale.

Jeśli korzystasz z narzędzia do zarządzania wymaganiami, dla każdego wymagania funkcjonalnego możesz utworzyć wiele atrybutów, takich jak jego przesłanki, pochodzenie albo status.

4. Wymagania dotyczące danych

Systemy informacyjne tworzą nowe wartości, przetwarzając dane. W tej sekcji szablonu opisz różne aspekty danych, które system będzie pobierać na wejściu, w jakiś sposób przetwarzać albo tworzyć je na wyjściu.

Stephen Withall (Withall Stephen. 2007. Software Requirement Patterns, Redmond, WA, Microsoft Press.) szczegółowo opisuje różne wzorce dokumentowania wymagań dotyczących danych (nazywanych także informacjami).

4.1. Logiczny model danych

Model danych jest wizualną reprezentacją obiektów i zbiorów danych, które system będzie przetwarzać, oraz relacji, jakie między nimi zachodzą. Istnieje wiele notacji wykorzystywanych w modelowaniu danych, w tym diagramy związków encji oraz diagramy UML klas.

W sekcji tej możesz zamieścić model danych opisujący operacje biznesowe przeprowadzane w systemie albo logiczną reprezentację danych, które system będzie przetwarzać. Takie ujęcie nie jest tożsame z implementacyjnym modelem danych, który będzie realizowany w postaci projektu bazodanowego.

4.2. Słownik danych

Słownik danych definiuje budowę struktur danych oraz znaczenie, typy, długości, formaty i dozwolone wartości danych tworzących te struktury. Komercyjne narzędzia do modelowania danych często zawierają moduł słownika danych. W wielu przypadkach lepszym rozwiązaniem będzie przechowywanie słownika danych w odrębnym dokumencie niż umieszczanie go w samym środku SRS. Taki zabieg zwiększa również możliwość powtórnego użycia słownika w innych projektach.

4.3. Raporty

Jeśli Twoja aplikacja będzie generować raporty, zidentyfikuj je i opisz ich właściwości. Jeżeli raport musi być zgodny z określonym z góry formatem, możesz taki format wyspecyfikować jako ograniczenie i ewentualnie podać jego przykład. W przeciwnym razie skup się na zawartości raportu, kolejności sortowania, poziomach sum pośrednich itd., odkładając uszczegółowienie układu raportu na późniejszy etap projektowania.

4.4. Pozyskiwanie, integralność, przechowywanie i usuwanie danych

Jeśli ma to znaczenie, opisz, jak w systemie są pozyskiwane i przetwarzane dane. Na przykład na początku procesu zasilania danymi może wystąpić konieczność wstępnego przesłania wszystkich danych do systemu odbiorczego, po czym przeprowadzania kolejnych transmisji danych uwzględniających wyłącznie zmiany. Opisz wszystkie wymagania odnoszące się do potrzeby ochrony integralności danych systemu. Zidentyfikuj konkretne techniki, które będą potrzebne w aplikacji, takie jak tworzenie kopii bezpieczeństwa lub migawek systemu, mirroring oraz weryfikacja dokładności danych. Określ polityki, które będą musiały być przestrzegane w systemie w celu przechowywania albo usuwania danych, w tym dotyczące danych tymczasowych, metadanych, danych szczątkowych (takich jak usunięte rekordy), danych podręcznych, kopii lokalnych, archiwów i tymczasowych kopii zapasowych.

5. Wymagania interfejsów zewnętrznych

W sekcji tej znajdują się informacje mające na celu zagwarantowanie prawidłowej komunikacji systemu z użytkownikami oraz zewnętrznymi elementami oprogramowania i składnikami sprzętowymi.

Osiągnięcie porozumienia w kwestii zewnętrznych i wewnętrznych interfejsów systemu zostało uznane za najlepszą praktykę branży oprogramowania (Browm, 1996). Złożony system o wielu składnikach powinien mieć odrębną specyfikację interfejsu albo architektury. Dokumentacja interfejsu może zawierać odsyłacze do materiałów z innych dokumentów. Można na przykład wskazać podręcznik obsługi urządzenia zawierający listę kodów błędów, które urządzenie to może wysyłać do Twojego systemu.

Ostatnia modyfikacja: poniedziałek, 22 marca 2021, 22:43