Wymagania stawiane oprogramowaniu
● Opis i specyfikacja
oprogramowania
Inżynieria oprogramowania - 5
Slide 1
●
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 2
●
Wymagania funkcjonalne i niefunkcjonalne
●
Wymagania użytkownika
●
Wymagania systemowe
●
Dokumentacja wymagań stawianych oprogramowaniu Inżynieria oprogramowania - 5
Slide 3
●
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 4
●
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 5
●
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 6
Definicja wymagań użytkownika
1. Oprogramowanie musi zapewniać mechanizmy reprezentowania i dostępu do plików zewnętrznych tworzonych przez inne narzędzia Specyfikacja wymagań systemowych
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 7
Menedżerowie klienta
Wymagania
Użytkownicy systemu
użytkownika
Inżynierowie klienta
Menedżerowie zleceniobiorcy
Architekci systemu
Użytkownicy systemu
Wymagania
Inżynierowie klienta
systemowe
Architekci systemu
Twórcy oprogramowania
Inżynierowie klienta (być może)
Specyfikacja projektu
Architekci systemu
oprogramowania
Twórcy oprogramowania
Inżynieria oprogramowania - 5
Slide 8
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 9
●
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 10
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 11
●
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 12
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 13
●
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 14
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 15
Typy wymagań niefunkcjonalnych Wymagania
niefunkcjonalne
Wymagania
Wymagania
Wymagania
produktowe
organizacyjne
zewnętrzne
Wymagania
Wymagania
Wymagania
Wymagania
Wymagania
sprawnościowe
niezawodności
przenośności
współpracy
etyczne
Wymagania
Wymagania
Wymagania
Wymagania
Wymagania
użyteczności
dostawy
implementacyjne
standardów
prawne
Wymagania
Wymagania
Wymagania
Wymagania
efektywnościowe
pamięciowe
ochrony
zabezpieczeń
prywatności
Inżynieria oprogramowania - 5
Slide 16
●
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 17
●
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 18
●
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 19
●
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 20
●
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 21
●
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 22
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 23
●
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 24
●
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 25
●
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ń
•
Syste m 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 26
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
•
Struktu ra języka naturalnego jest nieadekwatna do struktury opisu wymagań systemowych (podział wymagań i powiązania wymagań) Inżynieria oprogramowania - 5
Slide 27
●
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 28
●
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 29
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 30
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 31
●
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 32
●
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 33
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 34
●
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ć
Inżynieria oprogramowania - 5
Slide 35
Użytkownicy dokumentacji wymagań Określają wymaganie i czytają je
Klienci
aby sprawdzić, czy odpowiadają
systemu
ich potrzebą. Określają także
zmiany wymagań
Używają dokumentacji wymagań
Menadżerowi
do planowania oferty budowy
systemu i do planowania procesu
jego tworzenia
Inżynierowie
Używają wymagań aby
systemów
zrozumieć jaki system ma być
zbudowany
Inżynierowie
Używają wymagań aby
testów systemu
opracować testy zatwierdzające
system
Inżynierowie
Używają wymagań jako pomocy
pielęgnacji systemu
w zrozumieniu systemu i
związków między jego częściami
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 37
●
Wstęp
●
Ogólny opis
●
Specyfikacja wymagań
●
Dodatki
●
Skorowidz
Inżynieria oprogramowania - 5
Slide 38
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 39
●
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 40
●
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
Inżynieria oprogramowania - 5
Slide 41