Software Requirements

Definiowanie wymagań

funkcjonalnych oraz

niefunkcjonalnych; metody

ich pozyskiwania"

Autorzy: Maciej

Michalczyk(s3768)

Łukasz Hryniewiecki(s3829)

Spis Wykładu

1) Co to jest wymaganie

2) Cele

3) Inżynieria wymagań

4) Typy wymagań

5) Wymagania funkcjonalne i

niefunkcjonalne

6) Rady dla piszących wymagania

Co to jest wymaganie



Może być zarówno abstrakcyjnym wysokiego

poziomu opisem usługi jak również precyzyjnym

matematycznym opisem działania konkretnej

funkcji



Jest to nieuniknione gdyż wymagania mogą służyć

w różnych celach



Podstawa do podpisania kontraktu, czyli wymaganie

otwarte



Podstawa do stworzenia oprogramowania, czyli

precyzyjne wymaganie zamknięte



Oba te zdania opisują coś co nazywa się wymaganiami

Co to jest wymóg?



Pojęcie stosowane niekonsekwentnie



Zapisane na wysokim poziomie,

abstrakcyjne określenie usług, które

system powinien oferować, albo

ograniczenie działania systemu.



Niektórzy określają wymaganie jako

szczegółową, matematycznie formalną

definicję funkcji systemu.

Istotność etapu analizy

wymagań

Najistotniejsze problemy procesu rozwoju oprogramowania

Źródło:

D. Leffingwell,

D. Widrig:

Managing

Software

Requirements

Addison-

Wesley 1999

Koszty błędnych wymagań

Źródło:

D. Leffingwell,

D. Widrig:

Managing

Software

Requirement

Addison-

Wesley 1999

„

Mały błąd na początku wielkim jest na końcu”

(Arystoteles)

Cele



Rozumienie pojęć wymagań użytkownika i

wymagań systemowych



Rozumienie różnic pomiędzy wymaganiami

funkcjonalnymi i niefunkcjonalnymi



Poznanie dwóch metod zapisywania

wymagań



Wiedza, jak wymagania mogą być

organizowane w dokumentacji

Inżynieria wymagań



Proces ustalenia jakich usług użytkownik

oczekuje od systemu i ograniczeń, które

system musi spełniać zarówno podczas

tworzenia jak i podczas działania



Wymagania to opisy usług, które system

ma udostępniać i ograniczeń, które musi

spełniać

Typy wymagań



Wymagania użytkownika



Wyrażenia w języku naturalnym oraz diagramy o usługach

oczekiwanych od systemu oraz o ograniczeniach. Pisane

dla klienta



Wymagania systemowe



Precyzyjna dokumentacja opisująca szczegółowo wszystkie

usługi systemu i ograniczenia. Część kontraktu pomiędzy

klientem a dostawcą



Specyfikacja projektu oprogramowania



Abstrakcyjny opis projektu oprogramowania, który jest

podstawą bardziej szczegółowego projektu i implementacji.

Pisana dla programistów

Zawartość



Wymagania funkcjonalne i

niefunkcjonalne



Wymagania użytkownika



Wymagania systemowe



Dokumentacja wymagań stawianych

oprogramowaniu

Definicje i specyfikacje

Definicja wymagań użytkownika

Specyfikacja wymagań systemowych

1. Oprogramowanie musi zapewnić mechanizmy reprezentowania i

dostępu do plików zewnętrznych tworzonych przez inne
narzędzia

a. Użytkownik powinien mieć możliwość definiowania typów plików

zewnętrznych

b. Każdy typ pliku zewnętrznego może mieć przypisane narzędzie

do obróbki tego typu plików

c. Każdy typ pliku zewnętrznego może być przedstawiony w

postaci charakterystycznej ikony na ekranie użytkownika

d. Należy zapewnić udogodnienia do definiowana przez

użytkownika ikon odpowiadających typom plików zewnętrznych

e. Gdy użytkownik wybierze ikonę powiązaną z plikiem

zewnętrznym, następuje zastosowanie do tego pliku narzędzia
skojarzonego z typem tego pliku

Czytelnicy różnych wymagań

Wymagania

użytkownika

Wymagania

systemowe

Specyfikacja

projektu

oprogramowania

Menedżerowie klienta
Użytkownicy systemu
Inżynierowie klienta
Menedżerowi zleceniodawcy
Architekci systemu

Użytkownicy systemu
Inżynierowie klienta
Architekci systemu
Twórcy oprogramowania

Inżynierowie klienta (być może)
Architekci systemu
Twórcy oprogramowania

Wymagania funkcjonalne i

niefunkcjonalne



Wymagania funkcjonalne



Stwierdzenia opisujące, jakie usługi ma oferować

system, jak ma reagować na określone dane wejściowe

oraz jak ma reagować w określonych sytuacjach



Wymagania niefunkcjonalne



Ograniczenia usług i funkcji systemu obejmujące:

ograniczenia czasowe, ograniczenia dotyczące procesu

tworzenia, standardy itd.



Wymagania dziedzinowe



Wymagania pochodzące z dziedziny zastosowania

systemu i odzwierciedlające jego charakterystykę

Wymagania funkcjonalne



Opisują funkcjonalność lub usługi, które system

powinien oferować



Zależą od rodzaju tworzonego

oprogramowania, spodziewanych

użytkowników oprogramowania i rodzaju

wytwarzanego systemu



Wymagania użytkownika mają zazwyczaj

postać ogólną, ,natomiast systemowe

szczegółowo definiują funkcje systemu, wejścia

wyjścia wyjątki itd..

Przykłady wymagań

funkcjonalnych



Użytkownik będzie mógł przeszukać zbiór

wszystkich danych lub wybrany podzbiór.



System dostarczy narzędzi do przeglądania

dokumentów ze magazynu dokumentów.



Każde zamówienie będzie oznaczone

unikatowym identyfikatorem (ORDER_ID),

który będzie można skopiować do pamięci

trwałej konta użytkownika.

Nieprecyzyjność wymagań



Kiedy wymagania nie są precyzyjnie

wyrażone powstają problemy



Nieprecyzyjne wymagania są różnie

interpretowane przez użytkowników i

programistów



Rozważ użycie ‘odpowiedniego rzecznika’



Intencje użytkownika



Interpretacja programisty

Spójność i pełność wymagań



W założeniach wymagania powinny być spójne

i pełne



Pełność



Powinny opisywać wszystkie wymagane

oczekiwania



Pełne



Nie powinno być sprzeczności pomiędzy

opisywanymi oczekiwaniami



W praktyce nie można stworzyć spójnego i

pełnego opisu wymagań

Wymagania niefunkcjonalne



Opisują właściwości i ograniczenia systemu np.

niezawodność, czas odpowiedzi, ilość miejsca

na dysku.



Wymagania stawiane procesowi mogą

specyfikować użycie określonego narzędzia,

języka programowania lub metodologii

projektowej.



Wymagania niefunkcjonalne mogą być

istotniejsze od funkcjonalnych. Jeśli nie będą

spełnione system będzie bezużyteczny.

Klasyfikacja wymagań

niefunkcjonalnych



Dotyczące produktu



Wymagania określające jak ma się zachowywać

produkt. Np. wydajność, niezawodność



Dotyczące organizacji



Wynikające ze strategii i procedur w firmach np.

standardy procesu, wymagana dokumentacja, metoda

projektowania.



Wymagania zewnętrzne



Wynikające z czynników zewnętrznych dla systemu np.

interakcja z systemami innych firm, wymagania

prawne.

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

zabezpieczeń

Wymagania

prawne

Wymagania

ochrony

prywatności

Wymagania

implementacyjne

Wymagania

standardów

Wymagania

dostawy

Wymagania

użyteczności

Wymagania

efektywnościowe

Wymagania

pamięciowe

Miary do specyfikowania

wymagań niefunkcjonalnych

Właściwość

Miara

Szybkość

Rozmi
ar

Łatwość użycia

Niezawodność

Solidność

Przenośn
ość

Liczba przetworzonych transakcji na sekundę
Czas reakcji na zdarzenie wywołane przez użytkownika
Czas odświeżenia ekranu

Kilobajty
Liczba układów
pamięci

Czas szkolenia
Liczba okien pomocy

  Średni czas bez awarii
  Prawdopodobieństwo
niedostępności
  Częstość błędów
  Dostępność

  Czas uruchamiania po awarii
  Ułamek zdarzeń powodujących awarie
  Prawdopodobieństwo zniszczenia danych
po awarii

Procent poleceń zależnych od
platformy
Liczba docelowych systemów

Cele i wymagania



Wymagania niefunkcjonalne mogą być trudne

do precyzyjnego zapisania a nieprecyzyjne

wymagania mogą być trudne do zweryfikowania



Cel



Generalna intencja aby system coś spełniał



Weryfikowalne wymaganie niefunkcjonalne



Stwierdzenie używające jakiejś miary, która może

być obiektywne zmierzona



Cele mogą być przydatne dla programistów,

gdyż przekazują wskazówki o priorytetach

klienta

Przykłady



Cel



System powinien być łatwy w użyciu dla

doświadczonych kontrolerów, a sposób organizacji

powinien zmniejszać liczbę błędów użytkownika



Weryfikowalne

wymaganie

Weryfikowalne

wymaganie

niefunkcjonalne



Doświadczeni kontrolerzy powinni móc używać

wszystkich funkcji systemu po szkoleniu trwającym

dwie godziny. Po tym szkoleniu średnia liczba błędów

robionych przez doświadczonych użytkowników nie

powinna przekroczyć dwóch dziennie.

Zależności między

wymaganiami



W dużych systemach często występują konflikty

pomiędzy wymaganiami funkcjonalnymi i

niefunkcjonalnymi



System stacji kosmicznej



Dla zminimalizowania wagi liczba chipów powinna być

jak najmniejsza



Dla oszczędności energii chipy powinny być

energooszczędne



Ale energooszczędne chipy będą zajmowały więcej

miejsca, gdyż będzie ich potrzeba więcej. Które

wymaganie jest ważniejsze?

Wymagania dziedzinowe



Wynikają bardziej z dziedziny

zastosowania systemu niż z konkretnych

potrzeb użytkowników



Mogą być nowymi wymaganiami

funkcjonalnymi, ograniczać istniejące albo

ustalać sposób wykonania konkretnych

obliczeń



Jeśli będą niespełnione system może być

bezużyteczny

Problemy z wymaganiami

dziedzinowymi



Zrozumienie



Wymagania są wyrażone w języku typowym

dla dziedziny



To często nie jest zrozumiałe dla

programistów tworzących system



Milczące założenia



Specjaliści w dziedzinie są tak

przyzwyczajeni do danego wymagania, że

często nie wyrażają go w postaci dokumentu

Wymagania użytkownika



Powinny opisywać funkcjonalne i

niefunkcjonalne wymagania tak, aby

były zrozumiałe dla użytkowników

systemu nie posiadających wiedzy

technicznej



Należy je zapisywać w języku

naturalnym używając formularzy i

intuicyjnych diagramów

Problemy z językiem

naturalnym



Brak jasności



Trudno uzyskać precyzję bez czynienia

dokumentów nieczytelnymi i gadatliwymi



Sprzeczność wymagań



Wymagania funkcjonalne i niefunkcjonalne

łatwo się mieszają



Łączenie wymagań



Kilka wymagań może być wyrażonych

wspólnie

Problemy z wymaganiami



Wymagania dla bazy danych zawierają

zarówno opisy ogólne jak i szczegółowe



Opisują koncepcję sterowania



Zawierają szczegóły o tym, że grupy powinny być

dostępne za pomocą niepełnych nazw



Wymagania dla edytora siatki łączą trzy grupy

wymagań



Pojęciowe wymagania funkcjonalne



Wymaganie niefunkcjonalne



Niefunkcjonalne wymaganie stawiane interfejsowi

użytkownika

Rady dla piszących

wymagania



Opracuj standard i używaj go dla

wszystkich wymagań



Konsekwentnie używaj języka. Używaj

„będzie” dla wymagań obowiązkowych a

„powinien” dla oczekiwanych.



Stosuj wyróżnienia do zaznaczania

głównych części wymagania



Unikaj żargonu komputerowego

Wymagania systemowe



Dokładniejsze wyrażenie wymagań

użytkownika



Służą jako podstawa do zaprojektowania

systemu



Mogą być użyte jako część kontraktu



Można je przedstawiać za pomocą

modeli

Strukturalny język naturalny



Ograniczona postać języka naturalnego,

przeznaczona do zapisywania wymagań

systemowych



Usuwa niektóre z niejednoznaczności i

elastyczności języka naturalnego

zapewniając w pewnym stopniu

jednolitość specyfikacji



Często wspierany przez szablony

Specyfikacje w PDL



Wymagania są określane przy użyciu języka opisu

programów, który zawiera instrukcje zwiększające

wyrazistość.



Do stosowania gdy:



Funkcja jest ciągiem akcji, a kolejność wykonania tych

akcji jest istotna



Trzeba wyspecyfikować interfejsy programowe lub

sprzętowe



Wady



W PDL nie da się wyrazić wymagań dziedzinowych



Specyfikacja jest traktowana jako projekt a nie jako

specyfikacja

Wady PDL



PDL

nie jest wystarczający do wyrażania

wymagań w sposób zrozumiały



Notacja jest zrozumiała dla ludzi

znających języki programowania



Wymagania są traktowane jako projekt,

a nie jako model mający na celu

zrozumienie systemu

Specyfikacja interfejsów



Większość systemów musi współpracować z

innymi systemami a interfejsy między nimi

są częścią specyfikacji



Można wyróżnić trzy typy interfejsów



Proceduralne



Wymieniane struktury danych



Reprezentacje danych



Formalne notacje umożliwiają definiowanie

interfejsów w sposób jednoznaczny

Dokumentacja wymagań



Dokumentacja wymagań stawianych

oprogramowaniu jest oficjalną deklaracją

tego, co jest wymagane od wytwórców

systemu



Powinien zawierać zarówno wymagania

użytkownika jak i wymagania systemowe



Nie jest częścią projektu. Powinien mówić

CO zrobić a nie JAK to zrobić.

Użytkownicy

dokumentacji

wymagań

Klienci

Menedżerowie

Inżynierowie

systemu

Inżynierowie

testów

Inżynierowie

pielęgnacji

Określają wymagania i czytają je, aby sprawdzić, czy odpowiadają
ich potrzebom. 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

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

Dokumentacja wymagań



Określa zachowanie systemu jedynie z

zewnątrz



Określa ograniczenia implementacji



Łatwo ją modyfikować



Jest informatorem dla konserwatorów systemu



Obejmuje przewidywania przyszłego cyklu

życia systemu



Charakteryzuje reakcje na niepożądane

zdarzenia

Struktura dokumentacji

wymagań



Przedmowa



Wstęp



Słownik



efinicja wymagań użytkownika



Architektura systemu



Specyfikacja wymagań systemowych



Modele systemu



Ewolucja systemu



Dodatki



Skorowidz

Standard wymagań

IEE



Wstęp



Ogólny opis



Szczegółowe wymagania



Dodatki



Skorowidz



To jest ogólna struktura, która musi być

dopasowana do konkretnych systemów

Podsumowanie



W wymaganiach stawianych systemowi

określa się, co powinien system robić oraz

definiuje ograniczenia



Wymagania funkcjonalne opisują usługi,

których system ma dostarczać



Wymagania niefunkcjonalne opisują

ograniczenia w jakich system ma działać



Wymagania użytkownika są stwierdzeniami

wysokiego poziomu i opisują oczekiwania

użytkowników

Podsumowanie cd.



Wymagania użytkownika zapisuje się w języku

naturalnym z pomocą tabel i diagramów



Wymagania systemowe opisują wszystkie

funkcje jakich system musi dostarczać



Wymagania systemowe można zapisywać za

pomocą strukturalnego języka naturalnego, PDL

lub innych języków stworzonych w tym celu



Dokumentacja wymagań stawianych

oprogramowaniu jest uzgodnionym zapisem

wymagań systemowych

Bibliografia:

1 Internet (Google)

2 D. Leffingwell,D. Widrig:

Managing Software

3 Inżynieria oprogramowania. Autor: Andrzej

Jaszkiewicz

4 Wikipedia

Dziękujemy za uwagę !!!

Maciej Michalczyk s3768

Łukasz Hryniewiecki s3829

Document Outline