Etap tworzenia wymagań w procesie tworzenia oprogramowania jest Specyfikacje wymagań oprogramowania (SRS) (tzw dokument wymagań ). Raport ten kładzie podwaliny pod działania związane z inżynierią oprogramowania i buduje się, gdy zbierane i analizowane są całe wymagania. SRS to formalny raport, który działa jako reprezentacja oprogramowania, która umożliwia klientom sprawdzenie, czy jest ono zgodne z ich wymaganiami. Zawiera także wymagania użytkownika dotyczące systemu, a także szczegółowe specyfikacje wymagań systemowych.

SRS to specyfikacja konkretnego oprogramowania, programu lub zestawu aplikacji, które wykonują określone funkcje w określonym środowisku. Służy kilku celom, w zależności od tego, kto go pisze. Po pierwsze, SRS może zostać napisany przez klienta systemu. Po drugie, SRS może zostać napisany przez twórcę systemu. Obie metody stwarzają zupełnie odmienne sytuacje i wyznaczają całkowicie odmienne cele dokumentu. Pierwszy przypadek, SRS, służy do określenia potrzeb i oczekiwań użytkowników. Drugi przypadek, SRS, jest napisany do różnych celów i służy jako dokument umowy między klientem a programistą.

Charakterystyka dobrego SRS

Oto cechy dobrego dokumentu SRS:

1. Poprawność: Przegląd użytkownika służy zapewnieniu dokładności wymagań określonych w SRS. Mówi się, że SRS jest doskonały, jeśli pokrywa wszystkie potrzeby, jakich rzeczywiście oczekuje się od systemu.

2. Kompletność: SRS jest kompletny wtedy i tylko wtedy, gdy zawiera następujące elementy:

(1). Wszystkie istotne wymagania dotyczące funkcjonalności, wydajności, projektu, ograniczeń, atrybutów lub interfejsów zewnętrznych.

wyloguj się z konta Google na Androidzie

(2). Definicja ich reakcji oprogramowania na wszystkie możliwe do zrealizowania klasy danych wejściowych we wszystkich dostępnych kategoriach sytuacji.

Uwaga: Istotne jest określenie odpowiedzi zarówno na wartości prawidłowe, jak i nieprawidłowe.

(3). Pełne etykiety i odniesienia do wszystkich rysunków, tabel i diagramów w SRS oraz definicje wszystkich terminów i jednostek miar.

3. Konsystencja: SRS jest spójny wtedy i tylko wtedy, gdy żaden podzbiór indywidualnych wymagań nie jest opisany w jego konflikcie. Istnieją trzy rodzaje możliwych konfliktów w SRS:

(1). Określone cechy obiektów świata rzeczywistego mogą powodować konflikty. Na przykład,

(a) Format raportu wyjściowego można określić w jednym wymaganiu jako tabelaryczny, a w innym jako tekstowy.

(b) Jeden warunek może stanowić, że wszystkie światła mają być zielone, podczas gdy inny stanowi, że wszystkie światła mają być niebieskie.

(2). Może istnieć uzasadniony lub tymczasowy konflikt pomiędzy dwoma określonymi działaniami. Na przykład,

(a) Jeden wymóg może określić, że program doda dwa dane wejściowe, a inny może określić, że program je pomnoży.

(b) Jeden warunek może stanowić, że „A” musi zawsze następować po „B”, podczas gdy inny wymaga, aby „A i B” występowały wspólnie.

(3). Dwa lub więcej wymagań może definiować ten sam obiekt świata rzeczywistego, ale używać różnych terminów dla tego obiektu. Na przykład żądanie programu dotyczące wprowadzenia danych przez użytkownika można nazwać „podpowiedź” w jednym wymaganiu i „wskazówką” w innym. Stosowanie standardowej terminologii i opisów sprzyja spójności.

4. Jednoznaczność: SRS jest jednoznaczny, gdy każdy ustalony wymóg ma tylko jedną interpretację. Sugeruje to, że każdy element jest interpretowany w sposób unikalny. W przypadku stosowania metody z wieloma definicjami, raport wymagań powinien określać implikacje w SRS, tak aby była jasna i łatwa do zrozumienia.

5. Ranking pod względem ważności i stabilności: SRS jest klasyfikowany pod względem ważności i stabilności, jeśli każde zawarte w nim wymaganie ma identyfikator wskazujący znaczenie lub stabilność tego konkretnego wymagania.

Zazwyczaj nie wszystkie wymagania są równie ważne. Niektóre wymagania wstępne mogą być niezbędne, szczególnie w zastosowaniach o znaczeniu krytycznym, inne zaś mogą być pożądane. Należy zidentyfikować każdy element, aby te różnice były jasne i wyraźne. Innym sposobem uszeregowania wymagań jest rozróżnienie klas elementów na istotne, warunkowe i opcjonalne.

6. Modyfikowalność: SRS powinien być możliwie modyfikowalny i powinien w pewnym stopniu umożliwiać szybkie wprowadzanie zmian w systemie. Modyfikacje powinny być doskonale zindeksowane i powiązane.

7. Weryfikowalność: SRS jest poprawny, jeśli określone wymagania można zweryfikować za pomocą opłacalnego systemu w celu sprawdzenia, czy końcowe oprogramowanie spełnia te wymagania. Wymagania weryfikowane są za pomocą recenzji.

8. Identyfikowalność: SRS jest identyfikowalny, jeśli pochodzenie każdego z wymagań jest jasne i jeśli ułatwia odniesienie do każdego warunku w przyszłej dokumentacji rozwojowej lub udoskonalającej.

Istnieją dwa rodzaje identyfikowalności:

wyk

1. Możliwość śledzenia wstecznego: Zależy to od tego, czy każde wymaganie wyraźnie odwołuje się do źródła we wcześniejszych dokumentach.

2. Możliwość śledzenia w przyszłości: Zależy to od tego, czy każdy element w SRS ma unikalną nazwę lub numer referencyjny.

Możliwość śledzenia przyszłości SRS jest szczególnie istotna, gdy oprogramowanie wchodzi w fazę eksploatacji i konserwacji. W przypadku modyfikacji normy i dokumentu projektowego konieczna jest możliwość ustalenia pełnego zestawu wymagań, których mogą dotyczyć te modyfikacje.

9. Niezależność projektu: Powinna istnieć możliwość wyboru spośród wielu alternatywnych rozwiązań projektowych dla ostatecznego systemu. Mówiąc dokładniej, SRS nie powinien zawierać żadnych szczegółów dotyczących wdrożenia.

10. Testowalność: SRS powinien być napisany w taki sposób, aby na podstawie raportu można było łatwo wygenerować przypadki testowe i plany testów.

11. Zrozumiałe dla Klienta: Użytkownik końcowy może być ekspertem w swojej dziedzinie, ale może nie być przeszkolony w zakresie informatyki. Dlatego też należy w miarę możliwości unikać celów formalnych oznaczeń i symboli. Język powinien być prosty i jasny.

tablica obiektów w Javie

12. Właściwy poziom abstrakcji: Jeśli SRS jest napisany dla etapu wymagań, szczegóły powinny zostać wyraźnie wyjaśnione. Natomiast w przypadku studium wykonalności można zastosować mniej analiz. Zatem poziom abstrakcji zmienia się w zależności od celu SRS.

Właściwości dobrego dokumentu SRS

Zasadnicze właściwości dobrego dokumentu SRS są następujące:

Zwięzły: Raport SRS powinien być zwięzły, a jednocześnie jednoznaczny, spójny i kompletny. Rozwlekłe i nieistotne opisy zmniejszają czytelność, a także zwiększają ryzyko błędów.

Zbudowany: Powinno być dobrze zorganizowane. Dobrze zorganizowany dokument jest łatwy do zrozumienia i modyfikacji. W praktyce dokument SRS podlega kilku zmianom, aby sprostać wymaganiom użytkownika. Często wymagania użytkowników zmieniają się z biegiem czasu. Dlatego też, aby ułatwić wprowadzanie zmian w dokumencie SRS, ważne jest, aby raport miał dobrą strukturę.

Widok czarnej skrzynki: Powinien jedynie definiować, co system powinien robić, i nie podawać, jak to zrobić. Oznacza to, że dokument SRS powinien definiować zewnętrzne zachowanie systemu, a nie omawiać kwestie implementacyjne. Raport SRS powinien postrzegać tworzony system jako czarną skrzynkę i określać widoczne z zewnątrz zachowanie systemu. Z tego powodu raport SRS nazywany jest także specyfikacją czarnej skrzynki systemu.

Integralność koncepcyjna: Powinien wykazywać integralność pojęciową, tak aby czytelnik mógł ją jedynie zrozumieć. Reakcja na niepożądane zdarzenia: powinna charakteryzować akceptowalne reakcje na niepożądane zdarzenia. Nazywa się to reakcją systemu na wyjątkowe warunki.

Sprawdzalny: Wszystkie wymagania systemu, udokumentowane w dokumencie SRS, powinny być prawidłowe. Oznacza to, że powinna istnieć możliwość podjęcia decyzji, czy wymagania zostały spełnione w ramach wdrożenia.