Dokument specyfikacji wymagań

Dokument specyfikacji wymagań Dokument specyfikacji wymagań

Jerzy.Nawrocki@put.poznan.plwww.cs.put.poznan.pl/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

Urządzenie

Systemzewnętrzny

ENV1: UżytkownicySystem będzie wykorzystywany przez

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

Wszyscy użytkownic

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

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

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.

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.

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ć?

Dokument specyfikacji wymagań

Documents

Transcript of Dokument specyfikacji wymagań

SPECYFIKACJA TECHNICZNA WYKONANIA I ODBIORU ROBÓT ... · 1. Wymagania ogólne. 1.1 Przedmiot specyfikacji technicznej. Przedmiotem niniejszej specyfikacji technicznej są wymagania

Skrócona instrukcja instalacji - SUSE Linux …1 SLES 12 SP1 Skrócona instrukcja instalacji SUSE Linux Enterprise Server 12 SP1 Dokument zawiera spis wymagań systemowych oraz przewodnik

STANDARDY WYMAGAŃ BĘDĄCE PODSTAWĄ ...

Przykładowy Projekti - torus.uck.pk.edu.pltorus.uck.pk.edu.pl/~fkruzel/wp-content/.../Przykładowy_Projekt.pdf · Niniejszy dokument ma na celu przedstawienie specyfikacji projektu

Zbieranie wymagań

Klasyfikacja wymagań jako sposób zarządzania nimi

Pozyskiwanie i dokumentowanie wymagań

drukuj ten dokument

Prace dotyczące specyfikacji szerokopasmowego, globalnego ...

Zakres wymagań konkursów przedmiotowych i tematycznych w ...gimnazjum6bp.pl/userfiles/file/2016-2017/Zakres wymagań z...Zakres wymagań konkursów przedmiotowych i tematycznych

OPRACOWANO NA PODSTAWIE PROGRAMU MATEMATYKA Z PLUSEM …sp1sokolka.pl/images/2020/pso/matematyka/dl_mat_5.pdf · 2020. 9. 3. · WRAZ Z OKREŚLENIEM WYMAGAŃ EDUKACYJNYCH Dokument

Dz.U. 1999 Nr 53 poz. 549 USTAWA Rozdział 1 Art. 1. · 6. Wydanie specyfikacji technicznej, pozbawienie cech użytkowych oraz dokona- Wydanie specyfikacji technicznej, pozbawienie

Publikacja Szkoła wobec wymagań państwa

Poufny dokument ITU

Procesy Inżynierii Wymagań

Nowy dokument tekstowy

Opis wymagań kwalifikacyjnych

alla dokument

DOSTOSOWANIE WYMAGAŃ EDUKACYJNYCH – KONFERENCJA DLA RODZICÓW

NOWY OBOWIĄZKOWY DOKUMENT: Program wychowawczo … · UOO113 Nowy obowiązkowy dokument v2.indd 1 27.06.2017 05:32. Nowy obowiązkowy dokument: program wychowawczo- -profilaktyczny.