Podstawy Inżynierii Oprogramowania
Wykład 2
1. Wymagania na oprogramowanie
2. Model przypadków użycia (PU) w UML:
% definicja
% struktura PU
% specyfikacja zachowania PU
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
1
Podstawy Inżynierii Oprogramowania
Problem: jakie sÄ… rzeczywiste wymagania
klienta
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
2
Podstawy Inżynierii Oprogramowania
Inżynieria wymagań
DEFINICJA:
systematyczny proces opracowywania wymagań realizo-
wany przez iteracyjną współpracę między procesami:
Øð analizy problemu,
Øð dokumentowania koÅ„cowych obserwacji w postaci
różnorodnych formatów prezentacji oraz
Øð sprawdzania dokÅ‚adnoÅ›ci uzyskanych informacji
Inżynieria wymagań jest działalnością, która przekształca potrzeby i
życzenia (zwykle niekompletne i wyrażone nieformalnie) klienta i
potencjalnego użytkownika systemu komputerowego w kompletną
precyzyjną i spójną specyfikację, i o ile to możliwe, zapisaną w
formalnej notacji.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
3
Podstawy Inżynierii Oprogramowania
Inżynieria wymagań  procesy i artefakty
Specyfikacja
Potrzeby Własności
Slajd
udziałowców systemu
6wymagań
Model przypadków
Propozycja systemu
Dokument wizji użycia
Model biznesowy
systemu Wymagania dodatkowe
Lista wymagań
Model analizy
kandydujÄ…cych
SÅ‚ownik
Udziałowcy
Odkrywanie Specyfikacja Walidacja
wymagań wymagań wymagań
Dziedzina problemu
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
4
Podstawy Inżynierii Oprogramowania
Wymaganie - definicja
Wymaganie (IEEE 610):
- warunek lub własność, której potrzebuje
użytkownik do rozwiązania problemu lub
osiągnięcia celu,
- warunek lub własność, którą musi posiadać
system lub jego komponent, aby spełnić kontrakt,
standard, specyfikacjÄ™ lub inny, formalnie
wyrażony, dokument,
- reprezentacja (w postaci dokumentu) warunku lub
własności opisanych w punktach
Øð Pożądana cecha, wÅ‚asność lub
zachowanie SYSTEMU
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
5
Podstawy Inżynierii Oprogramowania
Piramida wymagań
Dziedzina
problemu
Problem  różnica
pomiędzy subiektywnym
postrzeganiem świata, a
rzeczywistością
Potrzeba  sposób
rozwiÄ…zania
Potrzeby
problemu
Usługa (cecha) systemu,
zwiÄ…zana z
Własności
zaspokojeniem jednej
lub więcej potrzeb.
Uszczegółowiona usługa
systemu, wyrażona jako
Wymagania
ograniczenie na produkt lub
w terminach interakcji
aktora z systemem,
[Cockburn, 2003]
realizujÄ…ca jednÄ… lub wiele
własności
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
6
Podstawy Inżynierii Oprogramowania
Klasyfikacja wymagań na system
Wymagania na Wymagania Wymagania FUNKCJONALNE
produkt na cechy
programowy wbudowane
Wymagania
na cechy
przypisane
[ISO/IEC 25030:06]
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
7
Wymagania na OPROGRAMOWANIE
Wymagania na SYSTEM
Podstawy Inżynierii Oprogramowania
Kategorie/perspektywa WYMAGAC

Perspektywa wymagań:
Øð klienta:
podane/pochodzÄ…ce od klienta (? kto to)
Øð wytwórcy:
kreowane przez zespół tworzący
oparte o wymagania Klienta
Klasyfikacja wymagań:
Øð dotyczÄ…ce produktu: funkcjonalne,
niefunkcjonalne
Øð dotyczÄ…ce procesu
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
8
Podstawy Inżynierii Oprogramowania
Autorzy wymagań
Dokument Specyfikacji
Wymagań (IEEE 610)
1.Wprowadzenie
klient
2. Ogólny opis potrzeb
3. Konkretne wymagania
4. Dodatkowe informacje
wytwórcy
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
9
Podstawy Inżynierii Oprogramowania
Wymagania funkcjonalne dla produktu
określają, jakie
Funkcje (= Usługi), produkt programowy
powinien oferować jego
użytkownikom/udziałowcom,
i które będą realizowane:
- właściwie (odpowiedni zbiór funkcji do wykonania zadań),
- z odpowiednią precyzją (dostarczać wyniki),
- we współpracy (z jednym/wieloma systemami).
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
10
Podstawy Inżynierii Oprogramowania
Wymagania niefunkcjonalne dla produktu
Rodzaj wymagania Przykład
Wydajność System wielodostępny do 20 użytkowników
(efficiency) ze średnim czasem odpowiedzi poniżej 0.2 s
Zabezpieczenia System dokonuje autoryzacji użytkowników
(security)
Skalowalność Początkowa wersja systemu ma obsłużyć 50
(scalability) użytkowników; docelowo 150 użytkowników
Rozszerzalność Aplikacja jest przystosowana do poszerzania
(extensibility) funkcjonalności za pomocą mech.  plug-in
Kompatybilność Program ma działać w systemach Win9x, Win2000,
(compatibility) WinNT, XP z minimum 16 MB Ram oraz 200 MB dysku
Użyteczność Aplikacja zawiera moduł  Pomoc on-line , który
(usability) wspomaga 90% opcji
Współpraca Program ma importować dane z systemu XXX
(cooperation - z urzÄ…dzeniami, systemami)
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
11
Podstawy Inżynierii Oprogramowania
Kategorie wymagań FURPS
Functional requirements: wymagania funkcjonalne, np. główne
cechy systemu, zabezpieczenia, możliwości.
Usability requirements: wymagania dotyczące estetyki, spójności
interfejsu użytkownika, dostępności
dokumentacji i materiałów szkoleniowych
Reliability requirements: wymagania dotyczące niezawodności
aplikacji, odzyskiwania systemu.
Performance requirements: wymagania wydajnościowe nałożone
na wymagania funkcjonalne.
Supportability requirements: wymagania dodatkowe dotyczÄ…ce
rozszerzalności produktu, jego
testowania, instalacji, konserwacji i
pielęgnacji.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
12
Podstawy Inżynierii Oprogramowania
Problemy z wymaganiami
Øð wymagania nie sÄ… Å‚atwe do identyfikacji, majÄ… wiele
z
ródeł;
Øð trudno je opisać/okreÅ›lić jednoznacznie;
Øð istnieje wiele różnych typów wymagaÅ„ (na różnym
poziomie szczegółowości opisu systemu);
Øð wymagania sÄ… czÄ™sto powiÄ…zane miÄ™dzy sobÄ… (
zależne);
Øð wymagania siÄ™ zmieniajÄ….
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
13
Podstawy Inżynierii Oprogramowania
Wymagania na WYMAGANIA :)
Wymaganie powinno :
Øð być jasno i jednoznacznie sformuÅ‚owane
Øð być wyrażone w sposób mierzalny (ważne
zwłaszcza dla wymagań niefunkcjonalnych)
Øð mieć nadany priorytet
Øð mieć oszacowany koszt realizacji
Øð być dostarczone do etapu projektu
Øð być rozpoznawalne w kodzie
Øð być weryfikowalne: stowarzyszone z testem,
testowalne w izolacji oraz Å‚Ä…cznie z innymi
wymaganiami
Øð być walidowalne po zbudowaniu systemu
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
14
Podstawy Inżynierii Oprogramowania
Sposoby formułowania (= specyfikacji) wymagań
1. Nieformalne  opis tekstowy w języku
naturalnym
2. Półformalne  wykorzystujące języki o
dobrze zdefiniowanej
składni i semantyce
wyrażanej w j. naturalnym
(UML)
3. Formalne - języki o dobrze zdefiniowanej
składni i semantyce np. języki
Z, CCS, VDM
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
15
Podstawy Inżynierii Oprogramowania
Nieformalny opis potrzeb klienta - przykład
Wytworzyć system informatyczny, który  na podstawie danych
demograficznych zaimportowanych z innych systemów 
umożliwia generację raportów dotyczących liczby osób
pozostajÄ…cych w zwiÄ…zkach (formalnych, nieformalnych) oraz ich
potomstwa.
Projekt jest powiÄ…zany z projektem zainicjowanym przez pismo
Demografia. Powstaje przy współpracy Głównego Urzędu
Statystycznego (GUS).
Motywacja:
Problemy
a) Trudny dostęp do aktualnej informacji demograficznej o
danym regionie. NiezadowalajÄ…cy czas oczekiwania na
informacje demograficzne.
b) Czasochłonna realizacja wniosków o udostępnienie
informacji publicznej przez GUS. IstniejÄ…cy system BDR
nie pozwala opracować wszystkich potrzebnych raportów.
c)Niska popularność i znajomość pisma Demografia.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
16
Podstawy Inżynierii Oprogramowania
Nieformalna specyfikacja wymagań klienta
FEAT 1 (<>)  Raportowanie: System udostępnia
raporty dotyczÄ…ce danych demograficznych i ich zmian w czasie.
FEAT 2 (<>)  Import danych: System pobiera i
przechowuje kopie wybranych danych z systemu BDR.
FEAT 3 (<>)  System jest dostępny w typowych
przeglÄ…darkach internetowych (minimum Explorer, FireFox)
FEAT 4 (<>)  System jest dostępny w polskiej i
angielskiej wersji językowej
FEAT 5 (<>)  Rejestracja do systemu: Dostęp do
systemu mają tylko uprawnieni użytkownicy.
NREQ1  System udostępnia żądane raporty w czasie poniżej 12 s
przy transmisji powyżej 56KB przy zalogowanych maksymalnie 10
użytkownikach (z
ródło: FEAT 8)
NREQ2a  Åšredni czas wykonania prostego raportu dla
zalogowanego użytkownika nie przekracza 1 min (z
ródło: FEAT 9).
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
17
Podstawy Inżynierii Oprogramowania
Wymaganie funkcjonalne Ä…ð PRZYPADEK
UŻYCIA
Øð Kompletny zbiór akcji
Øð Wykonywany przez SYSTEM
Øð Inicjowany przez AKTORA
Øð Który dostarcza widocznych korzyÅ›ci (Aktorowi)
AKTOR jest kimÅ› lub czymÅ›, na zewnÄ…trz systemu, co
wchodzi w interakcje z SYSTEMEM
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
18
Podstawy Inżynierii Oprogramowania
Model PRZYPADKÓW UŻYCIA
" Ilustruje
 zbiór przypadków użycia
systemu
Sprzedaż
" Identyfikuje
 aktorów, którzy wchodzą w
interakcje z systemem
" Definiuje
Statystyka sprzedaży Kierownik
Sprzedawca
 jakie działania podejmuje
system - przypadki użycia
 to, co istnieje na zewnÄ…trz
systemu - aktorów
Statystyka klientów
" Wyrażony diagramem
System sprzedaży
przypadków użycia
granica systemu
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
19
Podstawy Inżynierii Oprogramowania
Model PRZYPADKÓW UŻYCIA  składowe (1/3)
Aktor
 ktoÅ› (osoba) lub
 coÅ› (inny system lub urzÄ…dzenie),
 który wchodzi w interakcje (wysyła i
odbiera komunikaty - wymienia
informacje) z systemem
 oznaczenie w UML
Aktor
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
20
Podstawy Inżynierii Oprogramowania
Model PRZYPADKÓW UŻYCIA  składowe (2/3)
Przypadek użycia
 definicja
" specyfikacja zbioru sekwencji akcji,
wykonywanych przez system, których celem jest
dostarczenie pewnej wartości aktorowi
" reprezentuje pełną funkcjonalność z punktu
widzenia aktora
 Charakterystyka
" jest zawsze inicjowany przez aktora
 Oznaczenie w UML
NazwaPrzypadkuUżycia
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
21
Podstawy Inżynierii Oprogramowania
Model PRZYPADKÓW UŻYCIA  składowe (3/3)
Opis:
 Uzasadnienie przypadku użycia
" zaangażowane obiekty
" cele, które mają być osiągnięte
 Jak przypadek użycia jest aktywowany
" który aktor
" w jakiej sytuacji
 Przepływ wiadomości pomiędzy aktorami i systemem
 Alternatywne przepływy wiadomości
 Jak przypadek użycia się kończy i jaką wartość zwraca aktorowi
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
22
Podstawy Inżynierii Oprogramowania
Struktura opisu PRZYPADKU UŻYCIA
Start Przypadku użycia
Przepływ podstawowy
Przepływ alternatywny 3
Przepływ alternatywny 1
Przepływ alternatywny 2
Przepływ alternatywny 4
Koniec Przypadku użycia
Koniec Przypadku użycia
Koniec Przypadku użycia - OCZEKIWANY
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
23
Podstawy Inżynierii Oprogramowania
Model PRZYPADKÓW UŻYCIA - relacje
ØðAsocjacja komunikacyjna
Przypadek użycia
Aktor
ØðGeneralizacja
" Aktorów
" Przypadków użycia
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
24
Podstawy Inżynierii Oprogramowania
Model PRZYPADKÓW UŻYCIA - relacje
ØðAsocjacje przypadków użycia
Rozszerzenie Ä…ð <>
Zawieranie Ä…ð <>
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
25
Podstawy Inżynierii Oprogramowania
Strukturalizowany diagram PRZYPADKÓW UŻYCIA
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
26
Podstawy Inżynierii Oprogramowania
Poziomy przypadków użycia
POZIOMY PU Charakter UC
Ogólne
Chmur
podsumowanie
Podsumowanie
Latawca
Definiuj
zamówienie
Cel użyt-
Morza
kownika
SMART PU
Pod-funkcja
Ryby
Wybierz
produkt
Zbyt
Kraba
szczegółowe
[Cockburn]
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
27
Podstawy Inżynierii Oprogramowania
Styl PRZYPADKU UŻYCIA: dwie kolumny
Akcje Aktora Akcje Systemu
" Start z inicjatywy Aktora " Odpowiedz
na akcje aktora
" Może być wiele akcji aktora " Nie podaje się wskazówek jak
zanim System odpowie odpowiedz
będzie implemen-
towana (BLACK BOX!)
Dialog Aktora z Systemem;
Dobry dla specyfikacji Przypadku użycia
wysokiego poziomu;
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
28
Podstawy Inżynierii Oprogramowania
Styl PU: dwie kolumny - przykład
Aktor System
1 Przypadek użycia rozpoczyna się 2 Wyświetla wykaz dopuszczalnych akcji
gdy aktor otrzymuje główny
dokument wejściowy inicjujący
sprawÄ™.
3 Wybiera opcję tworzenia nowej 4 Wyświetla formularz Nowa Sprawa
sprawy
5 Wprowadza dane z dokumentu 6 Dla wybranego typu sprawy prezentuje pod-
inicjujÄ…cego sprawÄ™ wybierajÄ…c formularz do zarejestrowania specyficznych
m.in. typ sprawy. danych w zależności od typu sprawy
7 Rejestruje dane specyficzne dla 8 Stwierdza, że wybrany typ sprawy nie wymaga
wybranego typu sprawy żadnych załączników obowiązkowych.
Ustawia status sprawy na  przyjęta .
9 Stwierdza, że ten typ sprawy nie przewiduje
żadnych załączników opcjonalnych.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
29
Podstawy Inżynierii Oprogramowania
Styl PRZYPADKU UŻYCIA: specyfikacja pełna
ØðAktor
ØðUdziaÅ‚owcy i ich interesy
ØðWarunki wstÄ™pne
ØðGwarancja sukcesu (warunki koÅ„cowe)
ØðGłówny scenariusz sukcesu
ØðRozszerzenia
ØðWymagania specjalne
ØðTechnologia i wykaz zmiennoÅ›ci danych
ØðCzÄ™stość wystÄ™powania
ØðSprawy nieustalone
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
30
Podstawy Inżynierii Oprogramowania
Styl PU: specyfikacja pełna - przykład
Identyfikator PU 005
Nazwa Raportowanie
Aktorzy Użytkownik
Krótki opis Przypadek użycia służy do przygotowania wybranego raportu danych
demograficznych dla zadanego roku lub okresu z określonego regionu (region
jest ustalony arbitralnie podczas importu danych).
Warunki wstępne Użytkownik jest zalogowany
Warunki końcowe Brak
Scenariusz główny
1.Użytkownik chce poznać raport danych demograficznych.
2.System pyta o właściwości raportu danych demograficznych.
3.Użytkownik podaje właściwości raportu danych demograficznych.
4.System stwierdza, że właściwości raportu danych demograficznych są
poprawne.
5.System stwierdza, że dane żądane przez użytkownika są dostępne,
przygotowuje i odpowiednio wizualizuje raport.
Scenariusz 4a. System stwierdza, że właściwości raportu podane przez użytkownika są
alternatywny 1  niepoprawne
niepoprawne dane 5a. System informuje użytkownika o popełnionym błędzie
właściwości raportu Powrót do kroku 2
Wyjątek 1  brak 5a. System stwierdza, że dane żądane przez użytkownika nie są dostępne i
dostępu do danych informuje o tym użytkownika.
Koniec scenariusza
Wymagania NREQ1, NREQ2a, NREQ3, NREQ4, NREQ5, NREQ6
specjalne
y
ródło FEAT 1
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
31
Podstawy Inżynierii Oprogramowania
Proces specyfikacji wymagań
Identyfikacja aktorów i Strukturalizacja modelu
przypadków użycia przypadków użycia
Analityk systemu
Nadawanie priorytetów
przypadkom użycia
Architekt
Uszczegółowienie
poszczególnych
Specyfikator
przypadków użycia
przypadków użycia
Prototyp interfejsu
użytkownika
Projektant interfejsu
użytkownika
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
32
Podstawy Inżynierii Oprogramowania
Proces specyfikowania wymagań
ZarzÄ…dzanie wymaganiami - systematyczny proces, w
którym następuje wykrycie, zorganizowanie i
udokumentowanie wymagań.
Główne czynności wykonywane w procesie zarządzania
wymaganiami to:
Øð analiza problemu;
Øð zrozumienie potrzeb klientów;
Øð zdefiniowanie wymagaÅ„ na systemu;
Øð zdefiniowanie wymagaÅ„ na oprogramowanie;
Øð zarzÄ…dzanie atrybutami wymagaÅ„ jak: priorytet,
trudność, ryzyko;
Øð zarzÄ…dzanie zmianami wymagaÅ„.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
33
Podstawy Inżynierii Oprogramowania
Specyfikacja wymagań  ocena jakości
Opis wymagań powinien być:
jasny, weryfikowalny i wyrażony w sposób mierzalny
(specyfikacja wymagań niefunkcjonalnych).
Ocenie jakości podlega:
" jednoznaczność specyfikacji i spójność wewnętrzna wymagań,
" zewnętrzna spójność (z modelem biznesowym),
" minimalność (unikanie przespecyfikowania),
" kompletność:
" cele  czy system zaspokaja potrzeby użytkowników
" reguły lub fakty modelowanej dziedziny  czy system jest
poprawnym modelem dziedziny
" ograniczenia  ich pominięcie może prowadzić do
nieprawidłowego działania systemu
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
34
Podstawy Inżynierii Oprogramowania
Weryfikacja kompletności wymagań 
macierz  śladowania
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
35
Podstawy Inżynierii Oprogramowania
WYMAGANIA - podsumowanie
WYMAGANIE opisuje warunek lub zdolności, które
system musi spełniać (posiadać); zostaje
wywnioskowane bezpośrednio z potrzeb użytkownika,
bÄ…dz
jest deklarowane w kontrakcie, normie,
specyfikacji, lub innym formalnie ustalonym
dokumencie
Øð Pożądana cecha, wÅ‚asność lub zachowanie SYSTEMU
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
36
Podstawy Inżynierii Oprogramowania
Efektywne zarzÄ…dzanie wymaganiami - podsumowanie
Øð uzgodnienie wspólnego sÅ‚ownika pojęć pomiÄ™dzy
klientem i analitykami.
Øð stworzenie wizji systemu, który opisuje w jaki sposób
rozwiązać problem (-y).
Øð pozyskanie potrzeb klientów.
Øð ustalenie typów wymagaÅ„ wraz z atrybutami i ich
wartościami
Øð wybranie formatu wyrażania wymagaÅ„
Øð wskazanie osób odpowiedzialnych za modyfikacje
typów wymagań.
Øð ustanowienie procedury rozwiÄ…zujÄ…cej zmiany
wymagań.
Øð okreÅ›lenie mechanizmu Å›ledzenia historii wymagaÅ„.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
37
Podstawy Inżynierii Oprogramowania
Przypadki Użycia - podsumowanie
Øð Model przypadków użycia opisuje wymagania funkcjonalne i
takie wymagania niefunkcjonalne, które są specyficzne dla
poszczególnych przypadków użycia.
Øð Na model przypadków użycia skÅ‚ada siÄ™: opis tekstowy
aktorów i usług, zbiór diagramów oraz szczegółowy opis
(scenariusz) każdego PU
ØðSpecyfikacja wymagaÅ„ dodatkowych opisuje takie
wymagania niefunkcjonalne, które nie są związane z żadnym
poszczególnym przypadkiem użycia
ØðSpecyfikacja wymagaÅ„ jest weryfikowana m.in. prototypem
interfejsu
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
38