Ten fragment dokumentacji opisuje rozwijany system z punktu widzenia potrzeb użytkownika, które będzie zaspokajał, wskazuje jego relacje z istniejącymi systemami i sposób w jaki będzie używany.

2.1 Istniejący system lub sytuacja

Należy krótko opisać system (systemy), który ma być zastąpiony przez nowy system lub opisać działania, które są wykonywane manualnie, a które będą wspomagane lub zastąpione przez nowy system.

2.2 Opis nowego lub modyfikowanego systemu

Krótki opis systemu, jego celu, słownik podstawowych pojęć występujących w dziedzinie projektu.

środowisko działania i jego charakterystyka (diagram kontekstowy)
główne komponenty systemu i wzajemne połączenia (diagram wstępny)
interfejsy do zewnętrznych systemów
możliwości/funkcje systemu
diagramy opisujące wejścia, wyjścia przepływające dane, itp.
charakterystyka wydajności (szybkość, liczba rekordów, itd.)
cechy jakościowe: częstotliwość występowania błędów, łatwość konserwacji, elastyczność, przenośność, łatwość użytkowania, wydajność
bezpieczeństwo, zabezpieczenia, działanie w sytuacjach ekstremalnych

2.3 Użytkownicy

Wskazanie użytkowników przyszłego systemu

Identyfikacja roli właściciela, użytkownika.

2.4 Scenariusze operacyjne

Scenariusze pracy systemu, interakcji z użytkownikami.

Stany, tryby działania systemu.

Zdarzenia, bodźce i odpowiedzi na nie (MSC)

2.5 Analiza proponowanego systemu

wyliczenie zalet
wyliczenie wad
kompromisy przy rozwoju
alternatywy działania

3. SSS - specyfikacja wymagań systemu

Ten fragment dokumentacji opisuje wymagania dotyczące systemu (podsystemu) i metody jakie mają być stosowane dla zapewnienia, że każde wymaganie zostanie zaspokojone. Wymagania dotyczące zewnętrznego interfejsu systemu mogą zostać wydzielone w postaci IRS (specyfikacji wymagań interfejsu).

Uwaga należy raczej przedstawić wymagania w sposób możliwie ogólny (np.: wyliczenie funkcji z krótkim komentarzem). Bardziej szczegółowy opis wymagań powinien być zawarty w SRS.

3.1 Opis wymagań

3.1.1 Wymagane stany i tryby działania systemu

Opisane są stany i tryby działania. (Np.: gotowy, aktywny, bezczynny, oczekujący, sieciowy, jednostanowiskowy). Tryby mogą występować wewnątrz stanów (i na odwrót).

3.1.2 Wyliczenie możliwości (funkcji) systemu)

Należy wymienić kolejne mozliwosci/funkcje systemu, jeśli funkcje dzielą się na podfunkcje lub podtypy należy je wymieniać w kolejnych podakapitach.

3.1.3 Opis poszczególnych funkcji

3.1.3.1 Funkcja (klasa) pierwsza

3.1.3.2 Funkcja (klasa) druga

....

3.1.3.x Funkcja (klasa) x

3.2 Wymagania dotyczące zewnętrznych interfejsów systemu

Ta część (jeśli ma zastosowanie) może zostać wydzielona jako IRS lub opisana analogicznie.

Interfejsy zewnętrzne są narzucone poza systemem. Przykłady interfejsów:

format wymiany danych
format zapytań do baz danych
format wiadomości przesyłanych podczas komunikacji

3.3 Wymagania dotyczące wewnętrznych interfejsów systemu

Ta część (jeśli ma zastosowanie) może zostać wydzielona jako IRS lub opisana analogicznie.

Interfejsy wewnętrzne dotyczą komunikacji pomiędzy komponentami systemu (modułami CSCI)

3.3.1 Wymagania dotyczące danych wewnętrznych systemu

Decyzje dotyczące danych wewnętrznych mogą zostać podjęte w kolejnych fazach lub częściowo już tu.

3.3.2 Wymagania dotyczące zasobów komputerowych

wymagania sprzętowe
wymagania dotyczące platformy oprogramowania
wymagania dotyczące komunikacji (modem, sieć)

3.3.3 Ograniczenia projektowe

użycie szczególnej architektury systemu
użycie standardów projektowania, dokumentacji, języków programowania, bibliotek

4. SSDD - opis architektury systemu

Ten fragment dokumentacji opisuje decyzje projektowe dotyczące całego systemu i projekt jego architektury.

4.1 Decyzje projektowe dotyczące całego systemu

4.1.1 Wejścia i wyjścia

Decyzje projektowe dotyczące wejść i wyjść systemu (diagram kontekstowy) w tym interfejsy z innymi systemami, modułami oprogramowania i użytkownikami

4.1.2 Zachowanie

Zachowanie przejawiane przez system w odpowiedzi na wejścia lub warunki, czasy odpowiedzi, obsługa niedopuszczalnych wartości na wejściu.

4.1.3 Wizualny interfejs systemu

Decyzje w jaki sposób dane lub rekordy baz danych będą wizualizowane na potrzeby użytkownika

4.2 Projekt architektury systemu

4.2.1 Komponenty systemu

identyfikacja komponentów (CSCI, HWCI) (baza danych może być traktowana jako część CSCI lub odrębny CSCI)
pokazanie relacji pomiędzy komponentami
ustalenie zadań każdego komponentu
identyfikacja statusu komponentu (w rozwoju, reuse, itd.)
przydział zasobów komputera do komponentu (np.: procentowy)

4.2.2 Koncepcja wykonania

Opis przepływu danych, sterowania, wywołania usług komponentów.

4.2.3 Projekt interfejsu

Ta część (jeśli ma zastosowanie) może zostać wydzielona jako IDD lub opisana analogicznie.

5. SRS specyfikacja wymagań oprogramowania

Ten fragment dokumentacji specyfikuje wymagania dotyczące modułu oprogramowania

5.1 Wymagania

Należy opisać wymagania i relacje pomiędzy nimi omijając szczegóły, które mogą zostać ustalone w fazie projektowania. Zazwyczaj te, które są kryterium akceptacji modułu oprogramowania.

5.2 Wymagana stany i tryby działania

Jeśli moduł działa w różnych stanach/trybach i istnieją odrębne wymagania dla poszczególnych stanów lub trybów należy je podać i wyliczyć (np.: w formie tabeli).

5.3 Wyliczenie wymagań dotyczących możliwości modułu oprogramowania

Przez "możliwość" należy rozumieć tu funkcję, temat, klasę, obiekt, rekord. W przypadku dekompozycji, należy załączyć odpowiednie diagramy i opisać "pod-możliwości" (np.: podfunkcje, obiekty zgrupowane przez klasę nadrzędną) w kolejnych podrozdziałach.

5.4 Kolejne wymagania dotyczące możliwości

5.4.1 .....

5.4.2 .....

.....

5.4.x .....

5.5 Wymagania dotyczące zewnętrznych interfejsów CSCI

Ta część (jeśli ma zastosowanie) może zostać wydzielona jako IRS lub opisana analogicznie.

5.6 Wymagania dotyczące wewnętrznych interfejsów CSCI

Ta część (jeśli ma zastosowanie) może zostać wydzielona jako IRS lub opisana analogicznie.

5.6.1 Wymagania dotyczące danych wewnętrznych CSCI

Decyzje dotyczące przetwarzanych danych wewnętrznych (słownik danych, struktury danych, danych globalnych)

5.6.2 Wymagania dotyczące zasobów komputerowych

wymagania sprzętowe
wymagania dotyczące platformy oprogramowania
wymagania dotyczące komunikacji (modem)

5.6.3 Ograniczenia projektowe

użycie szczególnej architektury CSCI (jak biblioteka MFC)
użycie standardów projektowania, dokumentacji, języków programowania, bibliotek

6. SDD opis projektu oprogramowania

6.1 Ogólne decyzje projektowe dotyczące modułu oprogramowania (diagram wstępny)

W kolejnych podrozdziałach należy przedstawić decyzje dotyczące projektu zachowania (funkcjonalnego CSCI), tj.: jak moduł będzie się zachowywał z punktu widzenia użytkownika i w jaki sposób stawiane wcześniej wymagania będą zaspokajane.

Przykłady ogólnych decyzji projektowych:

wejścia i wyjścia modułu oprogramowania, w tym interfejsy z innymi systemami
sposób reakcji modułu na wejście (podjęte działania, czasy odpowiedzi i inne charakterystyki wydajności)
decyzje w jaki sposób bazy danych lub ich rekordy będą prezentowane użytkownikowi
sposób obsługi błędów, zapewnienie bezpieczeństwa, ochrona danych

6.2 Projekt architektury CSCI

6.2.1 Składniki CSCI

Opis obejmuje:

Identyfikator (nazwę, numer) jednostki programowej (klasy, funkcji)
Pokazanie relacji pomiędzy jednostkami (dziedziczenie, agregacja, asocjacje, dekompozycja funkcjonalna)
Opisanie celu każdej jednostki programowej
Określenie statusu (jednostka rozwijana, użyta powtórnie, planowana w fazie budowy nr XX)
Określenie planowanego zużycia zasobów (pamięć, dysk, czas procesora)

6.2.2 Koncepcja wykonania

Należy pokazać koncepcję wykonania (scenariusze przepływu danych, komunikatów, sterowania) pomiędzy jednostkami programowymi.

6.2.3 Projekt interfejsu

W kolejnych punktach należy opisać interfejsy łączące poszczególne jednostki programowe, interfejs użytkownika, interfejs do innych systemów. Ta część może być także zawarta w dokumentacji DD.

6.3 Decyzje szczegółowe dotyczące projektu CSCI

W kolejnych podrozdziałach można opisać decyzje szczegółowe dotyczące kolejnych jednostek programowych.

Decyzje dotyczące projektu interfejsu mogą zostać opisane w IDD.

Decyzje dotyczące projektu bazy danych opisane w DBDD

6.3.1 Identyfikator jednostki programowej lub grupy

Proponowany zakres opisu może obejmować:

1. Użyte algorytmy

2. Ograniczenia, przypadki szczególne

3. Jeśli jednostka programowa zawiera lub wykonuje komendy (systemu operacyjnego, systemu baz danych, itp.) należy wyjaśnić ich użycie.

4. Jeśli jednostka otrzymuje lub wysyła dane, należy dołączyć opis danych, rekordów danych, np.: w postaci słownika.

5. Jeśli jednostka posiada logikę sterowania (FSM) można wskazać sygnały wejściowe, wyjściowe, podejmowane akcje, przejścia między stanami.

6. Obsługa błędów i sytuacji wyjątkowych.

6.4 Źródła decyzji projektowych

Należy wskazać, które wymaganie jest zaspokajane przez poszczególne decyzje projektowe.

7. IRS - specyfikacja wymagań interfejsu

7.1 Wymagania

W kolejnych podrozdziałach wymienione są wymagania narzucone na interfejsy łączące ze sobą systemy, podsystemy, moduły oprogramowania i ich komponenty.

7.1.1 Identyfikacja interfejsów i ich diagramy

Podrozdział zawiera opis sprzężonych obiektów (systemy, moduły oprogramowania, użytkownicy) stwierdzając, który z nich mają ustalony interfejs, a który jest w trakcie rozwoju. W przypadku ustalonego interfejsu należy podać jego numer identyfikacyjny, np.: WinSocket X.X.

7.1.2 Opis kolejnych interfejsów

Przez "grupę elementów danych" rozumiane są tu elementy, które posiadają wewnętrzna strukturę, przez "elementy danych" rozumiane są tu dane proste (czyli elementy, które nie maja wewnętrznej struktury).

(a) typ (zapis i odczyt danych, transfer w czasie rzeczywistym)

(b) charakterystyka poszczególnych elementów danych, które współpracujące elementy będą dostarczały, wysyłały, otrzymywały

1. Nazwa, identyfikator, nazwa w języku potocznym

2. Typ danych

3. Rozmiar i format

4. Zakres wartości

5. Dokładność

6. Priorytety, ograniczenia czasowe

7. Źródła (jednostki ustawiające wartość) i odbiorcy (jednostki otrzymujące, używające )

( c) charakterystyki grup elementów danych (rekordy, komunikaty, pliki, tabele, ekrany graficzne raporty) które współpracujące elementy będą dostarczały, wysyłały, otrzymywały

1. Elementy danych w grupie, ich struktura

2. Medium (dysk) i ich struktura zapisu

3. Charakterystyki wizualne ekranów, kolory, układ fonty...

4. Relacje między grupami elementów danych (sortowanie, dostęp, użycie)

5. Priorytety, ograniczenia czasowe

6. Źródła (jednostki ustawiające wartość) i odbiorcy (jednostki otrzymujące, używające )

(d) Charakterystyki metod komunikacji

1. Identyfikator

2. Połączenia, media i ich charakterystyka

3. Formatowanie komunikatów

4. Sterowanie przepływem

5. Szybkość przesyłu danych

6. Adresowanie, marszrutowanie

(e) Protokoły

1. Identyfikator

2. Warstwa protokołu

3. Podział na pakiety, scalanie pakietów, marszrutowanie, adresowanie

4. Sprawdzanie legalności dostępu, obsługa błędów, procedury naprawy błędów

5. Synchronizacja, ustalanie połączenia, obsługa połączenia, zakończenie

8. IDD - opis projektu interfejsu

Opis projektu interfejsu jest skonstruowany analogicznie do IRS. Różnicą jest stopień dokładności, która jest zwiększona dla IDD.

Przykład

W IRS przedstawiany jest ogólny wygląd okna użytkownika, w IDD projektowane są szczegółowe kreacje

9. DBDD - opis projektu bazy danych

9.1 Ogólne decyzje projektowe dotyczące bazy danych

1. Opis wejść lub zapytań, które będą kierowane do bazy danych

2. Opis zachowania w odpowiedzi na wejście lub zapytanie.

3. Sposób wizualizacji tabel/rekordów

4. Użyty system zarządzania bazą danych DBMS.

5. Sposób dostępu do bazy danych (klient/serwer) uaktualnianie rekordów, transakcje, zapewnienie spójności i synchronizacji.

6. Sposób sporządzania kopii zapasowych, odzyskiwanie danych, dopuszczalne operacje w trakcie wykonywania tych czynności

7. Normalizacja, pakowanie danych, sortowanie, indeksowanie, synchronizacja, strategie optymalizacji rozmiarów, założenia dotyczące rozmiarów, liczby rekordów, zużycia mediów.

9.2 Szczegółowy projekt bazy danych

W kolejnych podpunktach należy opisać poszczególne elementy danych i grupy elementów danych. Przez "grupę elementów danych" rozumiane są tu: obiekty, rekordy, wiersze, tabele, relacje, schematy bazy, pola. Przez "elementy danych" rozumiane są tu atrybuty, pola, komórki (czyli elementy, które nie maja wewnętrznej struktury).

9.2.1 Opis kolejnej części składowej projektu bazy danych

Opis poszczególnych elementów danych występujących w części składowej projektu

1. Nazwa, identyfikator, nazwa w języku potocznym

2. Typ danych

3. Rozmiar, format

4. Jednostki miary

5. Zbiór dopuszczalnych wartości

6. Dokładność

7. Źródła (jednostki ustawiające wartość) i odbiorcy (jednostki otrzymujące, używające )

Charakterystyka grup elementów danych

1. Nazwa, identyfikator, nazwa w języku potocznym

2. Elementy danych w grupie, ich struktura

3. Medium (dysk) i ich struktura zapisu

4. Charakterystyki wizualne ekranów, kolory, układ fonty...

5. Relacje między grupami elementów danych (sortowanie, dostęp, użycie) (ERD)

6. Źródła (jednostki ustawiające wartość) i odbiorcy (jednostki otrzymujące, używające )

9.3 Szczegółowy projekt jednostek programowych użytych do manipulacji bazą danych

Jak 6.3.1.

9.4 Źródła decyzji projektowych

Należy wskazać, które wymaganie jest zaspokajane przez poszczególne decyzje projektowe.

Uwagi

W zależności od konkretnego projektu można się spotkać z architekturą systemu jak na Rys. 1 lub jak na Rys. 2. Ta ostatnia konfiguracja jest odpowiednia np.: dla systemów złożonych z kilku niezależnych programów - jak system nadawcy i odbiorcy dla komunikacji przez sieć (modem), wielostanowiskowy system obsługi biblioteki, itp.

Rys. 1 System złożony z jednego modułu

Rys. 2 System złożony z kilku modułów

W przypadku (Rys. 1.) wymagania stawiane systemowi przenoszą się na jedyny moduł oprogramowania (powinny zostać uściślone w SRS).

W przypadku (Rys. 2. ) wymagania stawiane systemowi są rozdzielone pomiędzy moduły składowe.

Przykład:

Zdecydowano (w SSDD), że system obsługi biblioteki składa się z modułów (samodzielnych programów): Katalog, Wypożyczenia, Zwroty, ZarządzanieKsięgozbiorem. ZarządzanieCzytelnikami

Ustalony w kolejnych dokumentach SRS podział wymagań jest następujący

Katalog wyszukiwanie książek
wysyłanie zamówień

Wypożyczenia realizacja zamówień, rejestracja wypożyczanych książek i czasopism

Zwroty rejestracja zwróconych książek i czasopism

ZarządzanieKsięgozbiorem Wprowadzanie nowych pozycji, usuwanie zniszczonych, itd.

ZarządzanieKsięgozbiorem Dodawanie czytelników
Upomnienia
Blokady kont

Każdy z modułów powinien mieć wówczas odrębny dokument SRS i SDD.

Katalog	wyszukiwanie książek wysyłanie zamówień
Wypożyczenia	realizacja zamówień, rejestracja wypożyczanych książek i czasopism
Zwroty	rejestracja zwróconych książek i czasopism
ZarządzanieKsięgozbiorem	Wprowadzanie nowych pozycji, usuwanie zniszczonych, itd.
ZarządzanieKsięgozbiorem	Dodawanie czytelników Upomnienia Blokady kont