Dokument specyfikacji wymagań

Copyright © Jerzy R. Nawrocki

Dokument specyfikacji wymagań Dokument specyfikacji wymagań

[email protected]/jnawrocki/wsb-asi

Analiza systemów informatycznych

Wykład 2

J.Nawrocki, Dokument specyfikacji wymagań

Struktura SRS

1. Wprowadzenie2. Ogólny opis produktu3. Wymagania funkcjonalne4. Wymagania pozafunkcjonalneDodatkiIndeks

IEEE Std 830-1998


Plan wykładu

•SRS – Wprowadzenie •SRS – Ogólny opis produktu•SRS – Wymagania funkcjonalne•Przypadki użycia•Wymagania pozafunkcjonalne•Dobre praktyki dotyczące dokumentu SRS

•Kontrola jakości•Szacowanie rozmiaru i•Standardy serii ISO 9000•Modele CMM/CMMI•Inżynieria wymagań•Zarządzanie projektami •Personal Software Process•Team Software Process•Zwinne metodyki•Rational Unified Process•Projekty dyplomowe


Plan wykładu




Struktura SRS

1. Wprowadzenie1.1 Cel dokumentu1.2 Zakres produktu1.3 Definicje, akronimy i skróty1.4 Odwołania do literatury1.5 Omówienie dokumentu

2. Ogólny opis produktu3. Wymagania funkcjonalne4. Wymagania pozafunkcjonalneDodatkiIndeks

IEEE Std 830-1998


1.1 Cel dokumentu

Rola dokumentu specyfikacji wymagań + czytelnicy

Niniejszy dokument prezentuje wymagania dotyczące oprogramowania, czyli opisuje funkcjonalność budowanego oprogramowania i warunki, jakie ono musi spełniać.

Dokument ten został napisany z myślą o potencjalnych użytkownikach, projektantach, programistach, osobach zajmujących się testowaniem i autorach dokumentacji użytkowej.


1.2 Zakres produktu• Identyfikacja produktu programistycznego poprzez nazwę.• Co produkt będzie, a czego nie będzie robił.• Zastosowanie specyfikowanego oprogramowania.

Wizja produktu:• Na czym polega problem?• Kogo dotyczy?• Jakie są jego implikacje?• Jaki jest pomysł na jego rozwiązanie?


1.2 Zakres produktu• Identyfikacja produktu programistycznego poprzez nazwę.• Co produkt będzie, a czego nie będzie robił.• Zastosowanie specyfikowanego oprogramowania.

Polskie Towarzystwo Literackie ma ponad 10 tys. członków. Członkowie często zmieniają swoje dane adresowe i są kłopoty z ich szybką aktualizacją. Problem dotyczy zarówno członków towarzystwa (ok. 500 osób rocznie zmienia swoje dane), jak też zarządu, który ma kłopoty z komunikacją. Konsekwencją tego stanu rzeczy są zaległości składkowe rzędu 15 tys. zł. Rozwiązaniem ma być system internetowy e-Member umożliwiający aktualizację danych adresowych poprzez Internet.


1.3 Definicje, akronimy i skróty

ASAP – Tak szybko, jak to możliwe (od ang. As Soon As Possible)

Explorer – patrz MS Explorer...MS Explorer – Oprogramowanie firmy Microsoft umożliwiające

czytanie stron internetowychNIP – Numer identyfikacji podatkowejPTL – Polskie Towarzystwo Literackie

Uporządkować alfabetycznie!


1.4 Odwołania do literatury

System powinien podawać wartość średnią i odchylenie standardowe [Montgomery97].

[Montgomery97] D.Montgomery, Introduction to Statistical Quality Control, John Wiley & Sons, Boston, 1997.

[ustawa2000] Ustawa z dnia 16.11.2000 o przeciwdziałaniu wprowadzaniu do obrotu finansowego wartości majątkowych pochodzących z nielegalnych lub nieujawnionych źródeł oraz o przeciwdziałaniu finansowaniu terroryzmu, Dz.U. z dnia 22 grudnia 2000.


1.5 Omówienie dokumentu

Omówić organizację pozostałej części dokumentu.

W rozdziale 2. omówiono ogólnie produkt wraz z krótką charakterystyką użytkowników i funkcjonalności, jaką będzie im udostępniał budowany system. Rozdział 3. jest poświęcony szczegółowemu opisowi wymagań funkcjonalnych, które zostały podzielone na grupy wg klas użytkowników (ról). Wymagania te są punktem wyjścia do opisu wymagań pozafunkcjonalnych, które przedstawiono w rozdziale 4.


Plan wykładu




Struktura SRS

1. Wprowadzenie2. Ogólny opis produktu

2.1 Kontekst funkcjonowania2.2 Charakterystyka użytkowników2.3 Główne funkcje produktu2.4 Ograniczenia2.5 Założenia i zależności

3. Wymagania funkcjonalne4. Wymagania pozafunkcjonalneDodatkiIndeks

IEEE Std 830-1998


2.1 Kontekst funkcjonowania

Omawiany system ma współpracować z systemem PolCard w zakresie płatności elektronicznych. Diagram kontekstu przedstawiono na rys. 1.

E-MemberE-MemberCzłonek

Zarząd

PolCard


2.2 Charakterystyka użytkowników

Można wyróżnić następujące role:

Członek towarzystwa – Gros członków PTL (ponad 80%) jest w przedziale od 30 do 55 lat. Część z nich ma problemy ze wzrokiem. Z przeprowadzonej ostatnio ankiety wynika, że 80% członków ma w domu komputer i umie lub chce się nauczyć korzystać z Internetu.

Zarząd – Wszyscy członkowie zarządu mają komputery i potrafią korzystać z Internetu.


2.3 Główne funkcje produktu

Produkt udostępnia funkcje opisane poniżej.

Członek PTL może za pomocą e-Member:• Czytać swoje dane przechowywane w systemie• Aktualizować swoje dane

Zarząd PTL może:• Wysyłać do członków PTL korespondencję zbiorową


2.4 Ograniczenia

System musi spełniać wymagania stawiane przez ustawę o ochronie danych osobowych [ustawa-osob].


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

Prezentowane wymagania dotyczą stanu prawnego na dzień 1 września 2005 roku.


Plan wykładu




Struktura SRS

1. Wprowadzenie2. Ogólny opis produktu3. Wymagania funkcjonalne 3.1 Opis otoczenia 3.2.1 Członek PTL 3.2.1.1 Czytanie danych 3.2.1.2 Aktualizacja danych 3.2.2 Zarząd PTL 3.2.2.1 Wysyłanie korespondencji4. Wymagania pozafunkcjonalneDodatkiIndeks

IEEE Std 830-1998


Struktura SRS


IEEE Std 830-1998


Środowisko operacyjne

SystemSystemUżytkownik

Użytkownik

ENV1

Urządzenie

Systemzewnętrzny

ENV2



ENV1: UżytkownicySystem będzie wykorzystywany przez

następujących użytkowników: Główna księgowa Prezes Dyrektor handlowy

Wszyscy użytkownic

y


Wszystkie urządzenia i

systemy zewn.


ENV2: Urządzenia i systemy zewn.

System będzie się komunikował z następującymi urządzeniami i systemami zewnętrznymi:

• SAP R/3

ENV2: Urządzenia i systemy zewn.

System będzie się komunikował z następującymi urządzeniami i systemami zewnętrznymi:

• SAP R/3



Użytkownik

SystemSystem



ENV3: Operacje głównej księgowej:

Główna księgowa może zainicjować wykonanie następujących operacji:

Pobranie faktury . . .

Wszystkie operacje.

Użytkownik, urządzenie. lub system zewn.


Metafora systemu

Jak opisaćpobranie faktury?

Producent Konsument

SystemSystem


Metafora systemu

Co muszę wiedziećo systemie, aby

opisać jego operacje?

Segregator z fakturamiSegregator z fakturami

SystemSystem


Metafora systemu

MET1: Architektura wewnętrznaSystem będzie składał się z

następujących elementów: Segregator z fakturami (pusty lub

niepusty) . . .

Wszystkieelementy

i ich stany.


Struktura SRS


IEEE Std 830-1998


Funkcje systemu

STOP

0.1234

Funkcja (Operacja)

Nie do nas! Dokładność?

Efekty uboczne

Wej. Wyj.


Funkcje systemu

FUN1: Pobranie faktury

WEJŚCIE: -WARUNEK: Segregator faktur jest niepusty. WYJŚCIE: Faktura (wzorzec WF-1/2001.09)EFEKT UBOCZNY: Pobrana faktura jest usuwana z

segregatora. Jeśli jest to jedyna faktura w segregatorze, segregator staje się pusty.

PRZETWARZANIE: -DOKŁADNOŚĆ: Cześć ułamkowa każdej kwoty ma dwie

cyfry po przecinku.


Plan wykładu




Ivar Jacobson

1967: Ericsson, systemy telekomunikacyjne

1985: Ph.D., Dep. of Computer Systems, The Royal Institute of Tech., Stockholm

1987: Założyciel Objectory AB

1995: Objectory AB łączy się z Rationalem

2003: IBM kupuje Rationala

http://www.analisi-disegno.com/uml/JacobsonInterview.htmlhttp://www.jaczone.com/


Ivar Jacobson

Addison-Wesley, 1992


Przykładowy przypadek użycia

Zarejestruj IOZarejestruj IOAktorAktor: Rejestrator IOCelCel: Zarejestrować w systemie nową IO.ZdarzenieZdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariuszGłówny scenariusz1.1. Rejestrator IORejestrator IO: Wprowadza NIP lub REGON IO.2.2. SystemSystem: Sprawdza poprawność wprowadzonego NIP/REGON.3.3. RejestratorRejestrator: Wprowadza pozostałe dane identyfikacyjne IO.4.4. SystemSystem: Weryfikuje poprawność składniową wprowadzonych

danych.5.5. RejestratorRejestrator: Wprowadza dane dotyczące jednostek IO.RozszerzeniaRozszerzenia2a.2a. NIP/REGON jest niepoprawny 2a1.2a1. System wyświetla komunikat i wracamy do kroku 1.


Ten sam cel

Przypadki użycia a scenariusze

Scenario #1

Scenario #2

Scenario #3

Przypadek użycia


Przykładowy przypadek użycia

Zarejestruj IOZarejestruj IOAktorAktor: Rejestrator IOCelCel: Zarejestrować w systemie nową IO.ZdarzenieZdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariuszGłówny scenariusz1.1. Rejestrator IORejestrator IO: Wprowadza NIP lub REGON IO.2.2. SystemSystem: Sprawdza poprawność wprowadzonego NIP/REGON.3.3. RejestratorRejestrator: Wprowadza pozostałe dane identyfikacyjne IO.4.4. SystemSystem: Weryfikuje poprawność składniową wprowadzonych

danych.5.5. RejestratorRejestrator: Wprowadza dane dotyczące jednostek IO.RozszerzeniaRozszerzenia2a.2a. NIP/REGON jest niepoprawny 2a1.2a1. System wyświetla komunikat i wracamy do kroku 1.


Zalety przypadków użycia

• Są półformalne. Wprowadzają strukturę do opowieści.

• Opisują także sytuacje błędne.

• Są podstawą do szacowania pracochłonności, specyfikacji szczegółowych wymagań, projektowania interfejsów i scenariuszy testowych.


Źle napisany przypadek użycia

Zapisz się na przedmiot (Główny scen.)

1. Wyświetl pusty plan zajęć.2. Wyświetl listę wszystkich zajęć w następujący sposób: Lewe okno

pokazuje wszystkie przedmioty w systemie uporządkowane alfabetycznie. Dolne okno pokazuje godziny, w których podświetlony przedmiot jest dostępny. Trzecie okno pokazuje wszystkie przedmioty znajdujące się obecnie w planie zajęć.

3. Wykonaj.4. Student klika na przedmiot.5. Aktualizuj dolne okno aby pokazać godziny, w których przedmiot jest

dostępny.6. Student klika na godziny a potem na przycisk „Dodaj przedmiot” .


1. Wyświetl pusty plan zajęć.2. Wyświetl listę wszystkich zajęć w następujący sposób: Lewe okno

pokazuje wszystkie przedmioty w systemie uporządkowane alfabetycznie. Dolne okno pokazuje godziny, w których podświetlony przedmiot jest dostępny. Trzecie okno pokazuje wszystkie przedmioty znajdujące się obecnie w planie zajęć.

3. Wykonaj.4. Student klika na przedmiot.5. Aktualizuj dolne okno aby pokazać godziny, w których przedmiot jest

dostępny.6. Student klika na godziny a potem na przycisk „Dodaj przedmiot” .

Źle napisany przypadek użycia

Za dużo szczegółów dot. GUI


Inne często popełniane błędy

Za dużo niskopoziomowych przypadków użycia („Authorize user”).

Stosowanie przypadków użycia do prezentacji informacji nie-behawioralnej (np. opis formularzy – do dodatków).

Za długie (powinny być krótkie, zazwyczaj 3-9 kroków).

Fragmenty zdań (np. pomijanie nazwy aktora w opisie kroków).


Krótki format

AktorAktor

Administrator

Przypadek użyciaPrzypadek użycia

UstawParametryMonito

WybierzMonitor

OpisOpis

Osoba monitorująca i kontrolująca system

sterowania zadaniami.

OpisOpis

Umożliwia administratorowi podanie zakresu

i dokładności monitorowanych elementów

Wybierz przedmiot monitorowania (np.

proces albo kolejkę oczekujących procesów)


Plan wykładu




Wymagania poza funkcjonalne

F

U

R

P

S

unctionality - fukcjonalność

sability - użyteczność

eliability - niezawodność

performance - wydajność

ecurity - bezpieczeństwo

4.1 Użyteczność4.2 Niezawodność4.3 Wydajność4.4 Bezpieczeństwo


Plan wykładu




Klasyfikacja dobrych praktyk

Dokument SRS

Zbieranie wymagań

Analiza i negocjacja wymag.

Opisywanie wymagań

Modelowanie systemu

Walidacja wymagań

Zarządzanie wymaganiami

IW dla systemów krytycznych

Podst. Pośred. Zaaw.

8

6

54

3

4

4

2

36

-

6

21

3

3

3

3

21

-

1

1-

-

1

2

4

9


Dokument wymagań

Zdefiniuj standardową strukturę dokumentuWyjaśnij, jak korzystać z dokumentuDołącz streszczenie wymagańOpracuj uzasadnienie biznesowe dla systemuZdefiniuj terminy specjalistyczneWybierz czytelny szablon dokumentuPomóż czytelnikom znaleźć informacjęUczyń dokument łatwym do zmiany


Klasyfikacja dobrych praktyk

Dokument SRS

Zbieranie wymagań

Analiza i negocjacja wymag.

Opisywanie wymagań

Modelowanie systemu

Walidacja wymagań

Zarządzanie wymaganiami

IW dla systemów krytycznych

Podst. Pośred. Zaaw.

8

6

54

3

4

4

2

36

-

6

21

3

3

3

3

21

-

1

1-

-

1

2

4

9


Opisywanie wymagań

Zdefiniuj standardowe szablony dla opisu wymag.Pisz prosto i krótkoOdpowiednio korzystaj z diagramówWzbogacaj język naturalny innymi formami opisuSpecyfikuj wymagania ilościowo


Podsumowanie

•Struktura dokumentu SRS•Przypadki użycia•Dobre praktyki Sommerville’a


Ocena wykładu

1. Wrażenie ogólne (1 - 6)2. Za szybko czy za wolno?3. Czy dowiedziałeś się czegoś ważnego?4. Co i jak poprawić?

Documents

Dokument specyfikacji wymagań