Inżynieria oprogramowania

Inżynieria wymagań systemów

informatycznych

Slajd 2

Plan wykładu

• Co to jest inżynieria wymagań ?
• Trudności w określaniu wymagań
• Iteracyjność pozyskiwania wymagań
• Metody zbierania informacji
• Zalecenia dotyczące rozmów z pracownikami

klienta

• Opis wymagań
• Typy wymagań
• Wymagania funkcjonalne
• Wymagania niefunkcjonalne
• Dokumentacja wymagań

Slajd 3

Co to jest inżynieria wymagań ?

Slajd 4

Inżynieria wymagań

(ang. requirements engineering)

•

Inżynieria wymagań

Inżynieria wymagań (IW) reprezentuje całość działań
związanych

z pozyskiwaniem, reprezentowaniem,

analizą i zarządzaniem wymaganiami

w ramach

kontekstu wyznaczonego przez cykl życia systemu
inf.

• W większości organizacji zajmujących się budową

systemów

jakość procesów IW jest

niska; wynika

to często z lekceważenia wszelkiej działalności
różnej od kodowania, a z drugiej strony wymuszana
jest często przez krótkowzroczne oczekiwania
klientów, którzy gotowi są płacić jedynie za fizyczne
oprogramowanie

Slajd 5

Inżynieria wymagań

(ang. requirements engineering)

• Błędy popełnione

podczas określania wymagań mogą

być

bardzo kosztowne

; przyjmuje się, że rosną one

zgodnie z zasadą 1:N w miarę rozwoju projektu

(przykładowo: wykrycie poważnego błędu dopiero na

etapie

projektowania jest N - razy

kosztowniejsze niż

odpowiednia analiza wymagań, ale już wykrycie tego

samego błędu na

etapie programowania

może być

nawet

N*N

kosztowniejsze)

• W ocenie niektórych specjalistów,

IW jest

najtrudniejszą częścią projektu

związanego z

wytworzeniem systemu informatycznego - zwłaszcza w

przypadku dużych projektów. Od jej poprawności i

efektywności często zależy powodzenie całych

projektów

Slajd 6

Specyfikowanie

oprogramowania

• W procesie inżynierii wymagań możemy

wyróżnić cztery główne fazy:

– Studium wykonalności
– Określenie i analiza wymagań
– Specyfikowanie wymagań
– Zatwierdzanie wymagań

Slajd 7

Proces inżynierii wymagań

Modele

systemu

Modele
system
u

Dokumen
tacja
wymagań

Określenie i analiza
wymagań

Specyfikacja
wymagań

Modele
systemu

Wymagani
a
użytkownik
a
i
systemowe

Zatwierdza
nie
wymagań

Raport o
wykonywalności

Studium

wykonalnoś
ci

Dokumentacja
wymagań

Slajd 8

Trudności w określaniu

wymagań

Slajd 9

Proces określania i analizowania

wymagań

Początek

procesu

Rozpoznanie

dziedziny

Zbieranie

wymagań

Klasyfikacja

Usuwanie

sprzeczności

Nadawanie

priorytetów

Sprawdzenie

wymagań

Specyfikacja

wymagań

Dokumentacja

wymagań

Slajd 10

Trudności w określaniu

wymagań

• Klient z reguły

nie wie

dokładnie w jaki sposób osiągnąć

założone cele

• Cele

klienta zwykle mogą być

osiągnięte na wiele

sposobów

• Duże systemy są

wykorzystywane przez wielu

użytkowników

, których cele są często sprzeczne;

różni

użytkownicy

mogą posługiwać się

inną terminologią

mówiąc o tych samych problemach

• Zleceniodawcy i użytkownicy są to często inne osoby

;

głos zleceniodawców jest oczywiście decydujący, ale nie
zawsze potrafią oni właściwie przewidzieć potrzeby
przyszłych użytkowników

Slajd 11

Trudności w określaniu

wymagań

• Najtrudniej wykryć wymagania, których

użytkownicy nie są świadomi

(prowadzi to

do powstawania luk w specyfikacji)

• Często pracownicy obawiają się zmian

,

które spowoduje wprowadzenie systemu i
postrzegają analityków jako nieprzyjaciół

• Czasami próbuje się

załatwić przy okazji

realizacji określonego przedsięwzięcia
inne sprawy

niezwiązane z projektem

PYTANIE

• Dlaczego tak trudno o dobre specyfikacje

wymagań i dlaczego mają one krytyczne

znaczenie dla projektu?

–Muszą stanowić spójną platformę komunikacji

pomiędzy częstokroć

odległymi grupami

zawodowymi i kompetencyjnymi

–Adresowane są do stosunkowo

szerokiego

kręgu

odbiorców

–Wymagają określania i definiowania

w sytuacji

minimum wiedzy

o przedsięwzięciu.

–Ich

błędy generują

krytyczne, strukturalne i

najbardziej kosztowne zmiany

Slajd 13

Iteracyjność pozyskiwania

wymagań

Slajd 14

Iteracyjność pozyskiwania

wymagań

Pozyskiwanie

wymagań,

analiza

i tworzenie

specyfikacji

Proces

rozwoju

systemu

Klient

Klient

Wykonawc

Wykonawc

a

a

Funkcjonuj

ąca

organizacj

a

Przyszli

użytkownicy systemu

Zleceniodawcy

Dokumentacja

wymagań

Cele biznesowe, potrzeby

i problemy do

rozwiązania, możliwości i

ograniczenia

Wiedza i

umiejętności

rozwiązywania

problemów

(doświadczenie,

personel),

technologia

Analitycy

(realizowalność,

koszt, ryzyko)

Zarządzani

e,

ograniczeni

a

Slajd 15

Metody zbierania

informacji

Slajd 16

Metody zbierania informacji

1. Lektura:

• raporty z wcześniejszych analiz
• opisy stanowisk pracy lub

obowiązków pracowników

• różne dokumenty wewnętrzne
• opis struktury organizacyjnej
• dokumentacja funkcjonującego

oprogramowania

• akty prawne

Slajd 17

Metody zbierania informacji

2.

Obserwacja

• formalna (stosowanie różnych

technik pomiarowych)

• nieformalna

Slajd 18

Metody zbierania informacji

Cele obserwacji nieformalnej:

• uzyskanie ogólnego obrazu
• odkrycie potencjalnych ekspertów (osób

kompetentnych i otwartych)

• jak (naprawdę) realizowane są procesy w firmie
• przebieg przetwarzania związanego z pojedynczym

dokumentem

• wykrycie związków
• zidentyfikowanie możliwych zakłóceń oraz reakcji

na sytuacje nietypowe

• zmiany w obciążeniu pracą
• magazyny danych - kartoteki

Slajd 19

Metody zbierania informacji

3. Próbkowanie:

• ilość i częstotliwość napływu

danych

• tendencje zmian
• wartości średnie i ekstremalne
• ustalenie stopnia zautomatyzowania

organizacji

• ustalenie podziału czasu pomiędzy

poszczególne czynności

Slajd 20

Metody zbierania informacji

4. Ankiety

• tylko gdy jest to uzasadnione
• dobre stosunki z pracownikami
• gdy ankietowani będą mieć czas na

ich wypełnienie

Slajd 21

Metody zbierania informacji

Zalecenia do ankietowania:
• najpierw sprecyzować dlaczego wysyłamy

ankiety i czego chcemy się dowiedzieć

• następnie przygotować pytania (najlepiej

proste pytania z wyborem odpowiedzi)

• nie pytać o sprawy oczywiste
• pismo przewodnie (cel, data zwrotu)
• warto przetestować na

współpracownikach

• nie zaniżać kosztów ankietowania

Slajd 22

Metody zbierania informacji

5. Rozmowy - wywiady

Slajd 23

Zalecenia dotyczące rozmów z

pracownikami klienta

Slajd 24

Zalecenia dotyczące rozmów z

pracownikami klienta

Przed rozmową:

• zaczynać zawsze od kierownictwa i

dopiero póżniej schodzić na niższe
szczeble

• umawiać się na rozmowy
• określić temat, cel i czas rozmowy
• być przygotowanym (poznać co

najmniej trochę dyskutowany temat,
ustalić co chcemy się dowiedzieć,
sporządzić listę pytań, ...)

Slajd 25

Zalecenia dotyczące rozmów z

pracownikami klienta

Sama rozmowa:

• odpowiednie zachowanie ( być punktualnym, nie

zapomnieć się przedstawić, starać się stwarzać miłą
atmosferę, okazywać szacunek rozmówcy)

• pytania otwarte (np. dlaczego?) zadawane

pojedynczo, modyfikowane w razie potrzeby

• kieruj rozmową, ale unikaj przerywania
• używaj terminologii rozmówcy, nie udawaj

“eksperta od wszystkiego”

• proś o wyjaśninia w przypadku niejasności oraz

kopie dokumentów o których mówi rozmówca

• staraj się odróżnić fakty od opinii
• nie wyrażaj własnych opinii

Slajd 26

Zalecenia dotyczące rozmów z

pracownikami klienta

Po rozmowie:

• udokumentowanie i autoryzacja

rozmowy

• ustalenie listy otwartych spraw
• weryfikacja uzyskanych danych

Slajd 27

Opis

wymagań

Slajd 28

Określanie wymagań

• Zamiana celów

klienta na konkretne

wymagania

wobec

tworzonego systemu

zapewniające

osiągnięcie tych celów

• Określanie wymagań

należy

rozumieć jako

proces

, w którym klient

wspólnie z analitykami

konstruuje zbiór

wymagań zgodny z

postawionymi celami

• Oprogramowanie

na

zamówienie

- bezpośredni

kontakt analityków z przyszłymi

użytkownikami;

niezbędne

duże zaangażowanie ze

strony klienta

• Oprogramowanie rynkowe

-

korzystny jak najszerszy

kontakt z potencjalnymi

klientami oraz ekspertami

z

danej dziedziny

Oprogramowanie

na konkretne

zamówienie

sprzedawane

“z półki”

Slajd 29

Poziomy szczegółowości opisu

Definicja

Definicja

wymagań

wymagań

(ogólny opis w języku

naturalnym, rezultat

wstępnych rozmów z klientem)

Specyfikacja wymagań

Specyfikacja wymagań

(częściowo ustrukturalizowany zapis, wykorzystujący

język naturalny oraz częściowo sformalizowane

notacje)

Specyfikacja oprogramowania

Specyfikacja oprogramowania

(w pełni formalny opis, rzadko wykonywana w

praktyce)

W

zr

o

st

s

zc

ze

g

ó

ło

w

o

śc

i

Slajd 30

Cechy opisu wymagań

Dobry opis wymagań:

• kompletny

oraz

niesprzeczny

• opisujący

zachowanie się systemu widziane z

zewnątrz

, a nie sposób jego realizacji

• obejmujący

ograniczenia

przy jakich musi pracować

system

• łatwy w modyfikacji

oraz uwzględniający przyszłe

możliwe zmiany wymagań wobec systemu.

• opisujący zachowanie systemu w

sytuacjach

niepożądanych lub skrajnych

Najczęstszym błędem

Najczęstszym błędem

jest koncentrowanie się

jest koncentrowanie się

na sytuacjach typowych i pomijanie wyjątków lub

na sytuacjach typowych i pomijanie wyjątków lub

przypadków granicznych

przypadków granicznych

Slajd 31

Typy

wymagań

Slajd 32

Typy wymagań

• Wymagania użytkownika

– To wyrażenia w języku naturalnym oraz diagramy

o usługach oczekiwanych od systemu oraz o

ograniczeniach, w których system ma działać.

• Wymagania systemowe

– Szczegółowo ustalają usługi systemu i

ograniczenia. Dokumentacja wymagań

systemowych, zwana czasem specyfikacją

funkcjonalną, powinna być precyzyjna.

• Specyfikacja projektu oprogramowania

– Jest abstrakcyjnym opisem projektu

oprogramowania, który jest podstawą bardziej

szczegółowego projektu i implementacji.

Slajd 33

Wymagania systemowe

Oprogramowanie musi zapewniać mechanizmy reprezentowania i
dostępu do plików zewnętrznych tworzonych przez inne narzędzia.

Specyfikacja wymagań
systemowych

1.

Użytkownik powinien mieć możliwość definiowania typów plików zewnętrznych.

2 Każdy typ pliku zewnętrznego może mieć przypisane narzędzie do obróbki takich
plików.
3 Każdy typ pliku zewnętrznego może być przedstawiony w postaci
charakterystycznej ikony na ekranie użytkownika.
4 Należy zapewnić udogodnienia do definiowania przez użytkownika ikon
odpowiadających typom plików zewnętrznych.
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.

Slajd 34

Czytelnicy różnych rodzajów

specyfikacji

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

Architekci systemu

Twórcy oprogramowania

Slajd 35

Wymagania funkcjonalne i

niefunkcjonalne

• Wymagania funkcjonalne

– Są stwierdzeniami, jakie usługi ma oferować system,

jak ma reagować na określone dane wejściowe oraz

jak ma się zachowywać w określonych sytuacjach. W

niektórych wypadkach wymagania funkcjonalne

określają, czego system nie powinien robić.

• Wymagania niefunkcjonalne

– To ograniczenia usług i funkcji systemu. Obejmują

ograniczenia czasowe, ograniczenia dotyczące

procesu tworzenia, standardy itd.

• Wymagania dziedzinowe

– Pochodzą z dziedziny zastosowania systemu

odzwierciedlają jej charakterystykę. Mogą być

funkcjonalne lub niefunkcjonalne.

Slajd 36

Dwa typy wymagań

• określają to, co system ma

realizować

• dotyczą rezultatów

oczekiwanych przez

użytkowników podczas

interakcji z systemem

• opisują funkcje, czynności oraz

operacje wykonywane przez

system

• mogą również określać jakie

efekty funkcjonalne nie są

dopuszczalne

• mogą być bardzo liczne

Funkcjon

Funkcjon

alne

alne

Niefunkcjo

Niefunkcjo

nalne

nalne

• opisują różnorodne

ograniczenia, przy

zachowaniu których system

powinien realizować swoje

funkcje

• w pewnych sytuacjach

umożliwienie ich spełnienia

ma znaczący wpływ na

przyjęte rozwiązania

projektowe i programowe

• nie należy ich lekceważyć

Slajd 37

Wymagania

funkcjonalne

Slajd 38

Wymagania funkcjonalne

• Definiują funkcjonalność oferowaną

przez system

użytkownikowi, nie

jest

istotne w jaki sposób jest ona
technicznie realizowana

(np. część tej

funkcjonalności może być realizowana
przy użyciu systemów zewnętrznych)

Slajd 39

Wymagania funkcjonalne

Określenie wymagań funkcjonalnych obejmuje m.in.

następujące kwestie:

• Określenie wszystkich rodzajów użytkowników

,

którzy będą korzystać z systemu, a także tych, którzy są

niezbędni do poprawnego funkcjonowania systemu

(obsługa, wprowadzanie danych, administrowanie, ...)

• Dla każdego rodzaju użytkownika

określenie

niezbędnych lub pożądanych funkcji

oraz sposobów

korzystania z planowanego systemu

• Określenie systemów zewnętrznych

(np.

zewnętrznych źródeł danych), z którymi system będzie

współpracował w celu osiągnięcia założonych celów

• Ustalenie struktur organizacyjnych, przepisów

prawnych, statutów, zarządzeń, instrukcji

, itd.,

które pośrednio lub bezpośrednio określają (lub

wpływają na) funkcje wykonywane przez planowany

system

Slajd 40

Metody specyfikacji wymagań

•

Język naturalny

Język naturalny

- często stosowany. Główne

wady to niejednoznaczność (różne rozumienie
tego samego tekstu) oraz zbytnia elastyczność
(wyrażenie tych samych treści na wiele
sposobów)

•

Formalizm matematyczny

Formalizm matematyczny

- rzadko stosowany,

tylko do specyficznych celów

•

Język naturalny strukturalny

Język naturalny strukturalny

- ograniczone

słownictwo i składnia; zagadnienia
wyspecyfikowane w punktach i podpunktach
(układ hierarchiczny)

Slajd 41

Metody specyfikacji wymagań

•

Formularze, tablice

Formularze, tablice

(zwykle dwuwymiarowe) -

kojarzą różne aspekty (np. tablica pokazująca
zależność pomiędzy typem użytkownika i rodzajem
usługi)

•

Diagramy blokowe

Diagramy blokowe

- forma graficzna pokazująca

cykl przetwarzania

•

Diagramy kontekstowe

Diagramy kontekstowe

- ukazują system w postaci

jednego bloku oraz jego powiązania z otoczeniem,
wejściem i wyjściem (część składowa analizy
strukturalnej)

•

Diagramy przypadków użycia

Diagramy przypadków użycia

- poglądowy sposób

przedstawienia aktorów i funkcji systemu (używana
zwłaszcza w podejściu obiektowym)

Slajd 42

Hierarchie wymagań

funkcjonalnych

• Opierają się na obserwacji faktu, że pewne funkcje

wykonywane przez system są

składowymi innych

ogólnych funkcji

• Na odpowiadających poziomach

ten sam stopień

szczegółowości

• Wykonanie funkcji nadrzędnej

nie musi oznaczać

wykonania wszytkich funkcji składowych

• Funkcje mogą być

wykonywane wielokrotnie

i

mogą pojawiać się w wielu funkcjach nadrzędnych

• Wyszczególniane są tylko funkcje widoczne dla

użytkowników

(zewnętrzne funkcje systemu)

Slajd 43

Hierarchie wymagań

funkcjonalnych

Funkcja f1

Funkcja f1.1

Funkcja f1.1.1

Funkcja f1.2

Funkcja f1.3

Funkcja f1.1.2

Funkcja f1.1.3

Funkcja f1

Funkcja f1.1

Funkcja f1.1.1

Funkcja f1.2

Funkcja f1.3

Funkcja f1.1.2Funkcja f1.1.3

Slajd 44

Wymagania niefunkcjonalne

Slajd 45

Wymagania niefunkcjonalne

Rodzaje wymagań

niefunkcjonalnych:

• Dotyczące

produktu

produktu

(np. wynikające

ze specyfiki sprzętu
wykorzystywanego przez klienta)

• Dotyczące

procesu

procesu

(np. zgodność z

systemem prawnym lub z
narzuconymi standardami)

•

Zewnętrzne

Zewnętrzne (określają zasady
współpracy z innymi systemami)

Slajd 46

Wymagania niefunkcjonalne

Przykłady wymagań:

•

Rozmiar

Rozmiar

: liczba terminali i jednocześnie pracujących

użytkowników; liczba kontrolowanych urządzeń

(czujników); rozmiar przechowywanych danych

•

Szybkość działania

Szybkość działania

: średni (maksymalny) czas operacji lub ich

sekwencji; liczba operacji na jednostkę czasu

•

Dokładność

Dokładność

: stopień precyzji pomiarów lub przetwarzania

(wymagana dokładność wyników)

•

Ograniczenia

Ograniczenia

:

– interfejsy komunikacyjne - sieć, protokoły, wydajność sieci;

– jakościowe

– sprzętowe - istniejące elementy, fizyczne ograniczenia,

wydajność, odporność (wilgotność, temperatura, ...)

– interfejsy oprogramowania - zgodność z sys. oper., innym

oprogramowaniem, ...

– związane z interakcją człowiek-komputer (typ interfejsu

użytkownika, ...)

Slajd 47

Wymagania niefunkcjonalne

•

Adaptowalność

Adaptowalność

: reakcja na zmiany

wymagań

•

Bezpieczeństwo

Bezpieczeństwo

: sposób zapewnienia

poufności (systemy identyfikacji
użytkowników i określania praw dostępu),
wykrywanie nieuprawnionego dostępu,
odporności na ataki z zewnątrz, wirusy, ...

•

Odporność na awarie

Odporność na awarie

: konsekwencje

błędów w oprogramowaniu lub innych
zdarzeń (przerwy w zasilaniu), zapewnienie
integralności danych, kopie zabezpieczające,
dzienniki zmian, ...

Slajd 48

Wymagania niefunkcjonalne

•

Standardy

Standardy

: formaty plików, polonizacja,

standardy procesów i produktów, ...

•

Zasoby

Zasoby

: Określenie ograniczeń

finansowych, ludzkich i materiałowych.

•

Skala czasowa

Skala czasowa

: ograniczenia na czas

wykonania systemu, czas szkolenia,
wdrażania

Slajd 49

Wymagania niefunkcjonalne

• Należy

dążyć do umożliwienia

weryfikacji

weryfikacji

wymagań

; powinna istnieć możliwość

sprawdzenia lub zmierzenia czy system
rzeczywiście spełnia oczekiwania

• Przykładowo wymagania

: “system ma być

łatwy w obsłudze”, „system ma być
niezawodny”, „system ma być dostatecznie
szybki”, itd. nie są praktycznie weryfikowalne

• Konieczne jest

posługiwanie się

wielkościami mierzalnymi

w celu określania

wymagań tego typu

Slajd 50

Typy wymagań niefunkcjonalnych

Wymagania

niefunkcjonalne

Wymagania

przenośności

Wymagania

niezawodności

Wymagania

sprawnościowe

Wymagania

etyczne

Wymagania

zewnętrzne

Wymagania

współpracy

Wymagania

produktowe

Wymagania

organizacyjne

Wymagania

efektywnościowe

Wymagania

użyteczności

Wymagania

dostawy

Wymagania

implementacyjne

Wymagania

standardów

Wymagania

prawne

Wymagania

pamięciowe

Wymagania

ochrony

prywatności

Wymagania

zabezpieczeń

Slajd 51

Miary do specyfikowania

wymagań niefunkcjonalnych

Właściwość

Miara

Szybkość

Rozmiar

Łatwość użycia

Niezawodność

Solidność

Przenośność

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 w
czasie awarii

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

Slajd 52

Dokumentacja

wymagań

Slajd 53

Dokument opisu wymagań

• Zawartość dokumentu opisu wymagań

:

– wprowadzenie zawierające

cel, kontekst oraz zakres

systemu,

– ogólny opis

zawierający m.in. charakterystykę użytkowników,

walory użytkowe i oferowane możliwości, przyjęte założenia i
zależności, ...

– opis

ewolucji

systemu,

– opisy wymagań

funkcjonalnych i niefunkcjonalnych

,

– model

(architektura) systemu

– słownik

wykorzystanych pojęć (terminy, skróty, akronimy)

wraz z ich precyzyjnym wyjaśnieniem w kontekście projektu;
należy zwrócić uwagę zwłaszcza na te, które mogą powodować
nieporozumienia wynikające z braku wzajemnego zrozumienia

– dodatki

(wymagania sprzętowe, wymagania dotyczące bazy

danych, ...)

• Plan testów systemu

(ewentualnie)

Slajd 54

Klienci systemu

Menedżerowie

Inżynierowie systemów

Inżynierowie testów systemu

Inżynierowie

pielęgnacji systemów

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

Użytkownicy
dokumentacji
wymagań

Slajd 55

Kluczowe czynniki sukcesu

• Zaangażowanie właściwych osób ze strony klienta

oraz kompetentnego personelu własnego (analityków,
konsultantów)

• Pełne rozpoznanie wymagań

, wykrycie sytuacji

szczególnych i nietypowych

(najczęstszy błąd popełniany w

tej fazie polega na koncentrowaniu się na sytuacjach typowych)

• Sprawdzenie kompletności i spójności wymagań

(przed przystąpieniem do dalszych prac, wymagania powinny
zostać przejrzane pod kątem ich kompletności i spójności)

• Określenie wymagań niefunkcjonalnych

w sposób,

który umożliwi ich weryfikację

• Przekonanie o sensowności

całego przedsiewzięcia

zarówno po stronie klienta jak i wykonawcy