Inżynieria oprogramowania - 5 Slide 1
Wymagania stawiane oprogramowaniu
. Opis i specyfikacja
oprogramowania
Inżynieria oprogramowania - 5 Slide 2
Cele
. Wprowadzenie pojęć wymagania użytkownika i
wymagania systemowe
. Opisanie wymagań funkcjonalnych i
niefunkcjonalnych
. Wyjaśnienie technik opisu wymagań systemowych
. Wyjaśnienie w jaki sposób wymagania stawiane
oprogramowaniu mogą być przedstawione w postaci
dokumentacji
Inżynieria oprogramowania - 5 Slide 3
Zawartość
. Wymagania funkcjonalne i niefunkcjonalne
. Wymagania użytkownika
. Wymagania systemowe
. Dokumentacja wymagań stawianych oprogramowaniu
Inżynieria oprogramowania - 5 Slide 4
Inżynieria wymagań
. Proces definiowania, analizowania i dokumentowania
usług, które odbiorca wymaga od systemu wraz z
opisem ograniczeń w ramach których system działa i
ewoluuje
. Wymagania są w istocie opisami usług systemu i jego
ograniczeń generowanymi w trakcie procesu
inżynierii wymagań
Inżynieria oprogramowania - 5 Slide 5
Czym jest wymaganie?
. Może być to opis usługi lub ograniczenia systemu
formułowany na różnych poziomach szczegółowości
od ogólnych stwierdzeń na wysokim poziomie
abstrakcji po szczegółowy zapis matematyczny
specyfikacji funkcjonalnej
. Opis wymagań może służyć dwóm celom
. Może stanowić podstawę zapytania ofertowego . w tym przypadku
powinien być dość ogólny
. Może stanowić załącznik do umowy . w tym przypadku musi być
zdefiniowany bardzo szczegółowo
. Oba te opisy można nazwać wymaganiami
Inżynieria oprogramowania - 5 Slide 6
Rodzaje wymagań
. Wymagania użytkownika
. Zdania napisane w języku naturalnym wraz z diagramami opisujące
usługi realizowane przez system oraz ograniczenia jakim podlega.
Przeznaczone dla klienta
. Wymagania systemowe
. Uporządkowany dokument zawierający szczegółowe opisy usług
systemowych. Stanowi załącznik do umowy pomiędzy zleceniodawcą
(klientem) a wykonawcą
. Specyfikacja oprogramowania
. Szczegółowy opis oprogramowania mogący służyć jako podstawa do
projektowania i implementacji. Przeznaczony dla wykonawcy
Inżynieria oprogramowania - 5 Slide 7
Definicje i specyfikacje
Definicja wymagań użytkownika
Specyfikacja wymagań systemowych
1. Oprogramowanie musi zapewniać mechanizmy reprezentowania i dostępu do plików
zewnętrznych tworzonych przez inne narzędzia
1.1. Użytkownik powinien mieć możliwość definiowania typów plików zewnętrznych
1.2. Każdy typ pliku zewnętrznego może mieć przypisane narzędzie do obróbki takich plików
1.3. Każdy typ pliku zewnętrznego może być przedstawiony w postaci charakterystycznej
ikony na ekranie użytkownika
1.4. Należy zapewnić udogodnienia do definiowania przez użytkownika ikon
odpowiadających typom plików zewnętrznych
1.5. Gdy użytkownik wybierze ikonę powiązaną z plikiem zewnętrznym, następuje
zastosowanie do tego pliku narzędzia skojarzonego z typem tego pliku
Inżynieria oprogramowania - 5 Slide 8
Czytelnicy wymagań
Wymagania
użytkownika
Wymagania
systemowe
Specyfikacja projektu
oprogramowania
Menedżerowie klienta
Użytkownicy systemu
Inżynierowie klienta
Menedżerowie zleceniobiorcy
Architekci systemu
Użytkownicy systemu
Inżynierowie klienta
Architekci systemu
Twórcy oprogramowania
Inżynierowie klienta (być może)
Architekci systemu
Twórcy oprogramowania
Inżynieria oprogramowania - 5 Slide 9
Wymagania funkcjonalne i niefunkcjonalne
. Wymagania funkcjonalne
. Określenie usług, które system powinien realizować, sposobu w jaki
system powinien reagować na określone zdarzenia na wejściu oraz
sposobu w jaki system powinien się zachować w określonych
sytuacjach.
. Wymagania niefunkcjonalne
. Ograniczenia usług i funkcji oferowanych przez system takich jak
ograniczenia czasowe, ograniczenia na proces rozwoju systemu,
standardy itp.
. Wymagania dziedzinowe
. Wymagania pochodzące z dziedziny zastosowania systemu,
odzwierciedlające właściwości dziedziny
Inżynieria oprogramowania - 5 Slide 10
Wymagania funkcjonalne
. Opisują funkcjonalności lub usługi systemu
. Zależą od rodzaju oprogramowania, oczekiwań
użytkowników oraz rodzaju systemu, w którym
oprogramowanie jest wykorzystywane
. Wymagania funkcjonalne użytkownika mogą
stanowić deklaracje co system powinien robić ale
wymagania funkcjonalne systemu powinny opisywać
usługi szczegółowo
Inżynieria oprogramowania - 5 Slide 11
Przykłady wymagań funkcjonalnych
. System powinien dysponować odpowiednimi
przeglądarkami umożliwiającymi użytkownikowi
czytanie dokumentów przechowywanych w systemie.
. Każde zamówienie powinno posiadać unikalny
identyfikator (ORDER_ID), który użytkownik
powinien móc skopiować do obszaru zapisów
nieusuwalnych.
Inżynieria oprogramowania - 5 Slide 12
Nieprecyzyjność wymagań
. Jeżeli wymagania nie są precyzyjnie określone
pojawiają się problemy
. Niejednoznaczne wymagania mogą być
interpretowane w różny sposób przez użytkowników i
projektantów
. Przykładowe określenie .odpowiednia przeglądarka.
. Intencja użytkownika . specjalnego przeznaczenia przeglądarka dla
każdego typu dokumentu
. Interpretacja projektanta . przeglądarka tekstu umożliwiająca
pokazanie zawartości dokumentu
Inżynieria oprogramowania - 5 Slide 13
Kompletność i spójność wymagań
. Zasadniczo wymagania powinny być zarówno
kompletne jak i spójne
. Kompletność
. Powinny zawierać opisy wszystkich wymaganych usług
. Spójność
. Nie powinno być konfliktu ani sprzeczności w definicjach usług
systemu
. W praktyce jest niemożliwym uzyskać kompletny i
spójny dokument z wymaganiami
Inżynieria oprogramowania - 5 Slide 14
Wymagania niefunkcjonalne
. Definiują właściwości systemu i jego ograniczenia np.
niezawodność, czas reakcji, zajętość pamięci itp. Ograniczenia
mogą być związane z możliwościami urządzeń I/O czy
reprezentacją danych używanych przez interfejsy systemu
. Wymagania związane z procesem tworzenia oprogramowania
wymuszające stosowanie określonego zbioru narzędzi CASE,
języków programowania czy metod budowy oprogramowania
. Wymagania niefunkcjonalne mogą być bardziej krytyczne od
wymagań funkcjonalnych. Niespełnienie tych wymagań czyni
system bezużytecznym
Inżynieria oprogramowania - 5 Slide 15
Klasyfikacja wymagań niefukcjonalnych
. Wymagania produktowe
. Wymagania, które określają zachowanie się produktu . prędkość
wykonania, niezawodność itp.
. Wymagania organizacyjne
. Wymagania będące konsekwencją polityki organizacyjnej i procedur
w firmie (zarówno wytwórcy jak i klienta) . procesy, wymagania
implementacyjne, itp.
. Wymagania zewnętrzne
. Wymagania wynikające z czynników zewnętrznych w stosunku do
systemu i procesu jego tworzenia . interakcje z innymi systemami,
wymogi prawne, itp.
Inżynieria oprogramowania - 5 Slide 16
Typy wymagań niefunkcjonalnych
Wymagania
niefunkcjonalne
Wymagania
produktowe
Wymagania
organizacyjne
Wymagania
zewnętrzne
Wymagania
sprawnościowe
Wymagania
niezawodności
Wymagania
przenośności
Wymagania
współpracy
Wymagania
etyczne
Wymagania
dostawy
Wymagania
implementacyjne
Wymagania
standardów
Wymagania
prawne
Wymagania
użyteczności
Wymagania
pamięciowe
Wymagania
efektywnościowe
Wymagania
ochrony
prywatności
Wymagania
zabezpieczeń
Inżynieria oprogramowania - 5 Slide 17
Cele i wymagania
. Wymagania niefunkcjonalne mogą być bardzo trudne do
precyzyjnego określenia i zarazem trudne do zweryfikowania.
. Cel
. Ogólna intencja użytkownika taka jak łatwość użycia
. Sprawdzalne wymagania niefunkcjonalne
. Stwierdzenia, które można obiektywnie testować za pomocą określonych miar
. Sformułowanie celów jest pomocne projektantom ponieważ
informuje ich o intencjach użytkowników systemu
Inżynieria oprogramowania - 5 Slide 18
Stosowane miary
. Szybkość . ilość transakcji/sek, czas reakcji na zdarzenie, czas odświeżania
ekranu
. Rozmiar . objętość kodu w kbajtach, ilość układów pamięci
. Łatwość użycia . czas szkolenia, liczba okien pomocy
. Niezawodność . średni czas bez awarii, prawdopodobieństwo
niedostępności, częstość błędów
. Solidność . czas uruchomienia po awarii, prawdopodobieństwo zniszczenia
danych w wyniku awarii
. Przenośność . procent poleceń zależnych od platformy, liczba docelowych
systemów
Inżynieria oprogramowania - 5 Slide 19
Interakcje wymagań
. Konflikty pomiędzy wymaganiami niefunkcjonalnymi
w złożonych systemach
. System dla potrzeb kosmonautyki
. Minimalizacja wagi prowadzi do minimalizowania liczby układów
elektroniki systemu
. Minimalizacja poboru energii wymaga zastosowania układów o
niskim jej poborze
. Zastosowanie układów o niski poborze energii może prowadzić do
zwiększenia ich ilości w systemie (co jest bardziej krytyczne dla
systemu?)
Inżynieria oprogramowania - 5 Slide 20
Wymagania dziedzinowe
. Wynikają ze specyfiki dziedziny i opisują właściwości
i cechy systemu odzwierciedlające dziedzinę
. Mogą to być nowe wymagania funkcjonalne,
ograniczenia na istniejące wymagania czy specyficzny
sposób przetwarzania danych
. Jeżeli wymagania dziedzinowe nie są spełnione
system nie może działać w sposób zadowalający
Inżynieria oprogramowania - 5 Slide 21
Problemy
. Zrozumiałość
. Wymagania są wyrażone językiem specyficznym dla dziedziny
problemu
. Są one często niezrozumiałe dla inżynierów oprogramowania
budujących system
. Jawność wymagań
. Specjaliści danej dziedziny rozumieją zagadnienia z nią związane tak
dobrze, że nie zawsze potrafią sformułować wymagania w sposób
wyraźny
Inżynieria oprogramowania - 5 Slide 22
Wymagania użytkownika
. Powinny opisywać funkcjonalne i niefunkcjonalne
wymagania tak jak są one rozumiane przez
użytkownika nie posiadającego szczegółowej wiedzy
technicznej
. Wymagania użytkownika definiuje się przy użyciu
języka naturalnego, tabel i diagramów
Inżynieria oprogramowania - 5 Slide 23
Problemy z językiem naturalnym
. Brak jasności
. Precyzja wymaga zawiłych sformułowań
. Sprzeczność wymagań
. Wymagania funkcjonalne i niefunkcjonalne mieszają się wzajemnie
. Łączenie wymagań
. Różne wymagania mogą być opisane jako jedno wymaganie
Inżynieria oprogramowania - 5 Slide 24
Opis wymagań - porady
. Opracuj standardowy format i wykorzystuj go do
opisu wszystkich wymagań
. Używaj języka konsekwentnie. Używaj słów .ma. i
.będzie. dla wymagań obowiązkowych a słowa
.powinien. dla wymagań oczekiwanych
. Stosuj wyróżnienia do zaznaczania kluczowych
fragmentów wymagań
. Unikaj używania żargonu informatycznego
Inżynieria oprogramowania - 5 Slide 25
Wymagania systemowe
. Bardziej szczegółowe od wymagań użytkownika
. Służą jako podstawa do projektowania systemu
. Mogą być elementem umowy na dostawę systemu
. Mogą zawierać różne modele systemu (model
obiektowy, model przepływu danych itp.)
Inżynieria oprogramowania - 5 Slide 26
Wymagania a projekt
. Zasadniczo wymagania powinny określać co system
powinien robić a projekt jak to wykonać
. W praktyce specyfikacja wymagań i projekt systemu
są trudno rozdzielne
. Projekt architektury systemu może określać strukturę wymagań
. System może współdziałać z innymi systemami co wpływa na
wymagania projektowe
. Zastosowanie specyficznego sposobu projektowania może być
wymogiem dziedzinowym
Inżynieria oprogramowania - 5 Slide 27
Problemy ze specyfikowaniem w NL
. Niejednoznaczność
. Twórcy opisu i czytelnicy muszą interpretować te same słowa w ten
sam sposób. Język naturalny jest z natury niejednoznaczny co stwarza
duże trudności.
. Zbytnia elastyczność
. Te same informacje można przedstawić w specyfikacji na wiele
różnych sposobów
. Brak modularności
. Struktura języka naturalnego jest nieadekwatna do struktury opisu
wymagań systemowych (podział wymagań i powiązania wymagań)
Inżynieria oprogramowania - 5 Slide 28
Alternatywne rozwiązania
. Strukturalny język naturalny (szablony i formularze)
. Języki opisu projektu (podobne do języków
programowania)
. Notacje graficzne (przypadki użycia)
. Specyfikacje matematyczne (pojęcia matematyczne -
maszyny stanowe lub zbiory)
Inżynieria oprogramowania - 5 Slide 29
Strukturalny język naturalny
. Ograniczona postać języka naturalnego
. Eliminuje niektóre problemy wynikające z
niejednoznaczności i elastyczności; zapewnia pewien
stopień jednolitości specyfikacji
. Wykorzystuje podejście oparte na formularzach
Inżynieria oprogramowania - 5 Slide 30
Specyfikacja w oparciu o formularze
. Definicja funkcji lub obiektów
. Opis wejść i ich źródeł
. Opis wyjść i ich przeznaczenia
. Wskazanie pozostałych wymaganych elementów
. Warunki początkowe i końcowe (jeżeli istotne)
. Efekty uboczne (jeśli występują)
Inżynieria oprogramowania - 5 Slide 31
Przykład specyfikacji
ECLIPSE/Workstation/Tools/DE/FS/3.5.1
Function Add node
Description Adds a node to an existing design. The user selects the type of node, and its position.
When added to the design, the node becomes the current selection. The user chooses the node position by
moving the cursor to the area where the node is added.
Inputs Node type, Node position, Design identifier.
Source Node type and Node position are input by the user, Design identifier from the database.
Outputs Design identifier.
Destination The design database. The design is committed to the database on completion of the
operation.
Requires Design graph rooted at input design identifier.
Pre-condition The design is open and displayed on the user's screen.
Post-condition The design is unchanged apart from the addition of a node of the specified type
at the given position.
Side-effects None
Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1
Inżynieria oprogramowania - 5 Slide 32
Specyfikacja wymagań w PDL
. PDL (Program Description Language)
. Wymagania mogą być zdefiniowane przy pomocy języka
podobnego do języka programowania przy zachowaniu
większej elastyczności opisu
. Przydatność
. Kiedy operacje opisywane są jako sekwencja działań i istotna jest ich
kolejność
. Kiedy musimy wyspecyfikować interfejsy sprzętowe i programowe
. Wady
. Język PDL może nie umożliwić definiowania pojęć dziedzinowych
. Opis wymagań jest bardziej specyfikacją projektu niż specyfikacją wymagań
. Notacja zrozumiała dla osób znających podstawy języków programowania
Inżynieria oprogramowania - 5 Slide 33
Specyfikacja interfejsów
. Większość systemów musi działać z innymi
systemami i ich interfejsy muszą być zdefiniowane
jako część wymagań systemowych
. Należy zdefiniować trzy typy interfejsów:
. Interfejsy proceduralne
. Struktury danych przekazywane pomiędzy systemami
. Reprezentacje danych
. Precyzja - notacje formalne, PDL, język naturalny
Inżynieria oprogramowania - 5 Slide 34
Opis interfejsu w PDL
interface PrintServer {
// defines an abstract printer server
// requires: interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter
void initialize ( Printer p ) ;
void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer
Inżynieria oprogramowania - 5 Slide 35
Dokumentacja wymagań
. Dokumentacja wymagań stanowi oficjalny dokument
dla projektantów systemu
. Powinna zawierać zarówno definicję jak i
specyfikację wymagań
. Nie jest dokumentem projektowym. Tak dalece jak to
tylko możliwe powinna opisywać co system ma robić
a nie w jaki sposób ma to robić
Użytkownicy dokumentacji wymagań
Klienci
systemu
Menadżerowi
Inżynierowie
systemów
Określają wymaganie i czytają je
aby sprawdzić, czy odpowiadają
ich potrzebą. Określają także
zmiany wymagań
Używają dokumentacji wymagań
do planowania oferty budowy
systemu i do planowania procesu
jego tworzenia
Używają wymagań aby
zrozumieć jaki system ma być
zbudowany
Inżynierowie
testów systemu
Inżynierowie
pielęgnacji systemu
Używają wymagań aby
opracować testy zatwierdzające
system
Używają wymagań jako pomocy
w zrozumieniu systemu i
związków między jego częściami
Inżynieria oprogramowania - 5 Slide 37
Wymagania dla dokumentacji wymagań
. Powinna określać zachowanie systemu na zewnątrz
. Powinna określać ograniczenia implementacji
. Powinno być ją łatwo zmieniać
. Powinna być narzędziem dla konserwatorów systemu
. Powinna przewidywać przyszłe zmiany
. Powinna określać reakcje na niepożądane zdarzenia
Inżynieria oprogramowania - 5 Slide 38
Standard wymagań IEEE
. Wstęp
. Ogólny opis
. Specyfikacja wymagań
. Dodatki
. Skorowidz
Inżynieria oprogramowania - 5 Slide 39
Struktura dokumentacji wymagań
. Wprowadzenie
. Słownik
. Definicje wymagań użytkownika
. Architektura systemu
. Specyfikacja wymagań systemowych
. Modele systemu
. Ewolucja systemu
. Dodatki
. Skorowidz
Inżynieria oprogramowania - 5 Slide 40
Główne tezy
. Wymagania określają co system powinien robić i
definiują ograniczenia jego działania
. Wymagania funkcjonalne definiują usługi które
system powinien dostarczyć
. Wymagania niefunkcjonalne nakładają ograniczenia
na sposób w jaki system zostanie zaprojektowany oraz
na proces jego tworzenia
. Wymagania użytkownika są opisem na wysokim
poziomie abstrakcji tego co system powinien robić
Inżynieria oprogramowania - 5 Slide 41
Główne tezy
. Wymagania użytkownika powinny być opisane za pomocą
języka naturalnego, tabel i diagramów
. Wymagania systemowe przekazują precyzyjne informacje o
funkcjach, które system powinien realizować
. Wymagania systemowe mogą być zapisane w strukturalnym
języku naturalnym, PDL lub języku formalnym
. Dokumentacja wymagań stawianych oprogramowaniu jest
uzgodnionym zapisem wymagań systemowych