Zarządzanie Projektem

Teleinformatycznym

Specyfikacja wymagań

dr inż. Konrad Jackowski

e-mail:

[e-mail]

C3 111

Wymagania

• Wymagania są jednym z najczęściej błędnie rozumianych pojęć choć

jednocześnie pełnią kluczową rolę w projekcie informatycznym

• Wymagania definiują: do system informatyczny powinien robić i

jakie są ograniczenia związane z jego funkcjonalnością lub sposobem
ich implementacji

• Zdefiniowanie wymagań jest podstawą podjęcia prac projektowych:

– ustaleniem szczegółowego planu projektu
– określeniem architektury systemu
– wyboru metodologii wykonania
– Sprzętu
– …

Wymagania

• Dokumentacja wymagań pełni istotną rolę z

socjologicznego punktu widzenia

• Jest opracowywana na podstawie wywiadów z osobami:

– mówiącymi różnymi językami
– operującymi różnymi zestawem pojąć
– dostrzegającym te same zagadnienia z różnej perspektywy

• Jest przeznaczona dla odbiorców:

– …

Wymagania

• Przystępując do realizacji projektu informatycznego zawsze należy

zakładać że:

– Klient (użytkownik) nie zna do końca swoich wymagań
– Klient (użytkownik) nie potrafi sprecyzować swoich wymagań

Zarządzanie wymaganiami

• Powodzenie projektu zależy od poprawności, kompletności,

spójności, czytelności, weryfikowalności i modyfikowalności

specyfikacji wymagań.

• Wymagania użytkownika zawsze będą się zmieniać, co oznacza, że w

trakcie projektu konieczne jest systematyczne i przemyślane

zarządzanie wymaganiami.

• Obejmuje ono następujące działania:

– zarządzanie procesem pozyskiwania, analizy, specyfikacji i

weryfikacji wymagań

– stworzenie systemu identyfikacji i śledzenia wymagań
– stworzenie standardu specyfikacji wymagań
– zarządzanie specyfikacją na różnych poziomach projektu
– utrzymanie zgodności pomiędzy różnymi poziomami specyfikacji
– zarządzanie zmianami

Metody opisu wymagań

• Język naturalny
• Język strukturalny
• Specyfikacja w oparciu o formularze
• Modele graficzne

Opis wymagań językiem naturalnym

• Opis językiem naturalnym jest najłatwiejszym sposobem opisu

wymagań

• Nie jest jednak rekomendowany ze względu na:

– niejednoznaczność i brak przejrzystości – dokładny opis

zagadnienia wymaga rozbudowanych opisów z wykorzystaniem

nieustandaryzowanego słownictwa

– brak jednoznacznej identyfikacji różnego typu wymagań (np.

funkcjonalnych i poza-funkcjonalnych)

– możliwość łączenia wymagań

– nadmierną elastyczność – to samo wymaganie może być opisane

na kilka różnych sposobów

Opis wymagań językiem strukturalnym

• Swoboda opisu jest istotnie ograniczona poprzez

zastosowanie wzorca opisu

• Wszystkie wymagania mają ustandaryzowany

układ i zawartość

• Można narzucić ograniczenia dotyczące

stosowanej terminologii

• Podstawowym zaletą tego modelu jest

ograniczenie możliwości pojawienia się
niejednoznaczności

Specyfikacja w oparciu o formularze

• Wykorzystywana w szczególności do opisu funkcji

i encji modelu danych

• Wykorzystywana do strukturalnej analizy

przepływu danych i analizy procesów

• Zawiera dokładne definicje wejścia i wyjścia

opisywanego procesu

• Precyzuje relacje pomiędzy danymi

Szablon specyfikacji wymagań Volere

Dokumentacja projektu

na podstawie szablonu specyfikacji
wymagań Volere

• Robertson S., Robertson J., Mastering the Requirements

Process,

Addison-Wesley, 2006.

• http://www.volere.co.uk/

Specyfikacja wymagań – zawartość (1)

1.

Czynniki sterujące projektem

1.

Przesłanki i cele projektu

2.

Interesariusze projektu

2.

Ograniczenia projektu

1.

Narzucone ograniczenia

2.

Konwencje nazewnicze i definicje

3.

Założenia i fakty powiązane

Specyfikacja wymagań – zawartość (2)

3.

Wymagania funkcjonalne

1.

Zakres prac

2.

Biznesowy model danych

3.

Zakres produktu

4.

Wymagania funkcjonalne

4.

Wymagania poza-funkcjonalne

1.

Wymagania estetyczne

2.

Wymagania ergonomii i wygody

3.

Wymagania wydajnościowe

4.

Wymagania dotyczące środowiska pracy

5.

Wymagania utrzymania i wsparcia

6.

Wymagania bezpieczeństwa

7.

Wymagania kulturowe i polityczne

8.

Wymagania prawne

Specyfikacja wymagań – zawartość (3)

5.

Problemy

1.

Problemy otwarte

2.

Rozwiązania alternatywne

3.

Nowe problemy

4.

Wymagania dotyczące szkoleń i dokumentacji

5.

Poczekalnia

6.

Zadania

7.

Ryzyka

8.

Koszty

Czynniki sterujące projektem

• Przesłanki i cele projektu

– Krótki opis założeń projektu, środowiska i

kontekstu, w którym projekt ma być
uruchomiony, bezpośrednie powody
uruchomienia projektu.

Czynniki sterujące projektem
Przesłanki i cele projektu - Przykład

• Podstawą uruchomienia prac nad projektem jest przeświadczenie, że

stworzenie zunifikowanego i przyjaznego dla użytkownika systemu
realizacji płatności za wybrane usługi komunalne przyczyni się do
poprawy ściągalności opłat. Dodatkowe korzyści z wdrożenia systemu
będą wynikać również z możliwości szerokiej analizy aktualnych i
wiarygodnych informacji rejestrowanych w systemie, co przełoży się
na zwiększenie efektywności zarządzania usługami objętymi
płatnościami za pomocą karty. Oddanie do rąk użytkowników kary
wpłynie również na budowę pozytywnego wizerunku miasta jako
miasta przyjaznego dla jego mieszkańców oraz osób go
odwiedzających. Otwartość systemu oraz akcja promocyjna karty ma
pociągnąć za sobą stałe poszerzanie palety usług opłacanych za jej
pomocą. Szeroki wachlarz usług oferowanych w systemie pozwoli
miastu osiągnąć pozycję pioniera i lidera w skali kraju we wdrożeniu
systemów podobnej klasy.

Czynniki sterujące projektem
Cele projektu

• To kilka najistotniejszych powodów, dla których projekt jest

uruchamiany.

• Odniesienie do biznesu. Cele powinny dokładnie odnosić się do

korzyści jakie są oczekiwane po wdrożeniu systemu dla klienta.

• Czytelność celów. Jasno zdefiniowane cele są niezbędną podstawą

do opracowania specyfikacji wymagań funkcjonalnych oraz zasad

sterowania projektem.

• Mierzalność realizacji celów. Cele należy sformułować w taki

sposób aby można było jednocześnie zaproponować obiektywną

miarę jego osiągnięcia.

PAM – Purpose, Advantage, Measurement

Czynniki sterujące projektem
Cele projektu - Przykład

Cel 1

•

Oddanie do rąk użytkowników przyjaznego i atrakcyjnego narzędzia pozwalającego na realizację

płatności za wybrane usługi świadczone w mieście. Karta ma pozwolić na usprawnienie ściągalności

opłat za usługi.

Miara

•

W chwili wdrożenia wszystkie płatności za usługi komunikacji miejskiej mają być realizowane za

pomocą karty.

Cel 2

•

Optymalizacja zarządzania wybranymi zasobami zarządzanymi przez jednostki podległe poprzez

wdrożenie efektywnych narzędzi dostarczających rzetelnych i bieżących informacji na temat

wykorzystania tych zasobów.

Miara

•

W pierwszym miesiącu funkcjonowania systemu w środkach komunikacji miejskiej powstanie

szczegółowa analiza obciążenia i rentowności wszystkich linii autobusowych i tramwajowych,

przygotowana za pomocą narzędzi zintegrowanych.

Cel 3

•

Stworzenie oraz wdrożenie otwartej platformy informatycznej pozwalającej na późniejszą

integrację z systemem wybranych aplikacji obsługujących płatności za inne usługi.

Miara

•

W pierwszym roku funkcjonowania systemu zostanie zainicjowany co najmniej jeden projekt

integracji nowej usługi.

Interesariusze

•

Interesariusze to wszystkie osoby mogące być zaangażowane bezpośrednio lub
pośrednio w proces realizacji projektu lub produktem końcowym

–

Klienci – firmy lub osoby finansujący bezpośrednio realizację projektu

–

Nabywcy – firmy lub osoby kupujący gotowy produkt
(Klient nie musi być tym samym podmiotem co nabywca)

–

Użytkownicy

–

Inni interesariusze

• Testerzy oprogramowania

• Analitycy biznesowi

• Eksperci

• Projektanci systemów

• Analitycy rynku

• Przedstawiciele kooperantów

• …

Interesariusze – wymagane informacje

• Interesariusze powinnni być opisani następującymi informacjami:

– Identyfikator (może odnosić się do pełnionej w projekcie roli,

stanowiska pracy, nazwy organizacji/firmy, imienia i nazwiska)

– Wymagana wiedza lub umiejętności

– Stopień zaangażowania w projekcie (może być opisowa lub za

pomocą zdefiniowanego słownika określającego stopień)

Ograniczenia

• Ograniczenia systemu – rozwiązania

– Określają wszystkie ograniczenia nałożone na sposób realizacji

systemu. Mogą dotyczyć technologii wykonania, wersji systemów,

bazy sprzętowej. Podając ograniczenia należy uzasadnić powody

ich wprowadzenia.

• Przykład

– Opis: Moduł przedstawiciela handlowego powinien być aplikacją

działającą na urządzeniach przenośnych

– Uzasadnienie: Aplikacja będzie wykorzystywana w podróżach

służbowych, również w terenie.

– Kryterium spełnienia: Aplikacja powinna być wykonana dla

urządzeń typu smartphone

Ograniczenia

• Ograniczenia dotyczące architektury rozwiązania

– Opisuje fizyczne i technologiczne środowisko, w którym system

powinien działać. Powinien zawierać opis urządzeń wchodzących

w skład systemu wraz z relacjami pomiędzy nimi

– Nie jest to opis architektury wynikający z analizy wymagań,

dotyczy wyłącznie założeń wstępnych (np.: posiadanej bazy

serwerowej, urządzeń mobilnych, infrastruktury sieciowej lub

poczynionych z góry założeń ich dotyczących)

• Przykład

– Do opisu można wykorzystać diagramy prezentujące modele w

postaci ikon oraz połączeń pomiędzy elementami diagramu

reprezentującymi relacje

Ograniczenia

• Systemy powiązane

– Opisuje wszystkie systemy (zarówno softwerowe jak i

sprzętowe), z którymi projektowany system ma współpracować

• Przykład

– System ma dostarczać danych do systemu CrystalReport w celu

elastycznego projektowania raportów

– Baza danych ma być umieszczona na serwerach firmy IBM

Ograniczenia

• Przewidziane środowisko pracy

– Opis środowiska pracy, w którym będą działy wszystkie elementy

systemu. Informacje te mogą obejmować lokalizacje, warunki

pogodowe, głośność i oświetlenie itp..

• Przykład

– System będzie zainstalowany w bibliotece gdzie wymaga się

zachowania całkowitej ciszy

– Aplikacja mobilna będzie używana na placu budowy, również w

trudnych warunkach atmosferycznych

Ograniczenia

• Ograniczenia związane z terminami realizacji

– Dotyczy wszystkich znanych ograniczeń czasowych (deadlines)

związanych z realizacją projektu jako całości jak również

poszczególnych jego etapów

• Przykład

– Pierwsza testowa wersja systemu powinna być gotowa do

akceptacji w styczniu 2013

– Ostateczna wersja powinna zostać oddana najpóźniej w maju

2013

Ograniczenia

• Ograniczenia związane z budżetem

– Planowany budżet związany z realizacją projektu

– Można sprecyzować przeznaczenie środków np.:

• modernizacja sprzętu,

• koszty outsourcingu,

• koszty wynagrodzeń

Konwencje nazewnicze i definicje

• Definicje wszystkich terminów, haseł, akronimów stosowanych w

projekcie.

• Hasła powinny być jednoznaczne tak by minimalizować ryzyko

niejednoznaczności z ich definicje zwięzłe i zrozumiałe dla
wszystkich czytelników dokumentacji.

Konwencje nazewnicze i definicje

• Bezpieczna Transmisja

Przesłanie danych pozwalające zachować integralność i poufność

transmitowanych danych.

• Błąd Krytyczny

Nieprawidłowość wykonania, która w ocenie Zamawiającego uniemożliwia

przejście do kolejnego etapu projektu.

• Błąd Niekrytyczny

Nieprawidłowość wykonania, która w ocenie Zamawiającego nie uniemożliwia

przejścia do kolejnego etapu projektu.

• Protokół Odbioru

Sporządzony w formie pisemnej dokument potwierdzający odebranie

wszystkich prac podlegających odbiorowi oraz pozytywny efekt wynikających z

PTF procedur akceptacyjnych. W przypadku stwierdzenia istnienia Błędów

Niekrytycznych Strony mogą na zasadach przewidzianych Umową podpisać

Warunkowy Protokół Odbioru.

Fakty i założenia powiązane z

projektem

• Czynniki, które mają wpływ na produkt, lecz nie są ograniczeniami

wynikającymi z natury i okoliczności projektu.

• Mogą to być zwyczaje panujące w biznesie, sposoby organizacji lub

jakiekolwiek inne rzeczy które mają wpływ na produkt.

• Przykłady

– Średni czas życia urządzenia mobilnego szacuje się na 3 lata

– Aktualnie pracująca wersja systemu jest napisana w języku C++

w środowisku Microsoft Visual Studio i bibliotek MFC

Zakres produktu

• Opis sytuacji bieżącej

– Jest to analiza istniejących procesów biznesowych, w tym

obsługiwanych ręcznie lub przez aktualnie wykorzystywane sytemy

informatyczne, które mają zostać zastąpione.

– Opis będzie obejmował te procesy, których obsługa będzie

zoptymalizowana w wyniku wdrożenia systemu.

– Przedstawione w tym rozdziale modele powinny prezentować: role,

osoby, departamenty, procedury-procesy.

– Zadaniem ich jest ilustracja przepływu informacji i zależności między

składnikami tego procesu.

• Przykład

– Do ich ilustracji można wykorzystać: activity diagrams, business process

diagrams, swimlane diagrams, dataflow diagrams.

Opis sytuacji bieżącej - przykład

Opis sytuacji bieżącej - przykład

–

Faza

: Kontrola limitu kredytowego

•

Uwagi:

•

Wejścia:

–

Limity kredytowe – arkusz excel

–

Statystyki sprzedaży – arkusz excel

–

Kontrola procesu – P1

–

Statystyka należności – arkusz excel

–

Zamówienie – P1

•

Dokumenty towarzyszące:

•

Wyjścia:

–

Saldo sprzedaży– limit – Limity kredytowe – arkusz excel

•

Czas obsługi:

5-15 minut

•

Moduły i arkusze:

–

Limity kredytowe

–

Statystyki należności

–

Statystyki sprzedaży

–

P1 – System obsługi sprzedaży

•

Działy:

–

Księgowość

–

Dział sprzedaży

•

Opis:

–

Aktualizacja salda sprzedaży, w tabeli Limity kredytowe, o sumę danych statystycznych i sumę procesów z dnia

bieżącego

–

Aktualizacja salda należności w oparciu o statystykę należności

–

Odczyt salda sprzedaż/należności/limity

•

Problemy:

–

Ręczne sumowanie zapisów statystyk sprzedaży i procesów P1 z dnia bieżącego – link

–

Niezgodność kodów klienta w systemach – czasochłonne wyszukiwanie - link

Zakres produktu

• Kontekst pracy

– Diagramy kontekstu pracy pozwalają na identyfikację zakresu pracy,

związanej z realizowanym projektem w otoczeniu innych systemów lub

realizowanych zadań.

– Należy zwrócić uwagę na fakt, że diagramy przedstawiają więcej

elementów, niże te które będą realizowane w ramach projektu.

– Podstawowym celem prezentacji jest dokładne zrozumienie relacji

pomiędzy systemem a środowiskiem w którym ma pracować.

– Diagramy pozwalają zidentyfikować nie tylko systemu ale również osoby

i organizacje.

• Przykład

– Do ich ilustracji można wykorzystać: activity diagrams, business process

diagrams, swimlane diagrams, dataflow diagrams.

Zakres produktu – przykład diagramu

Model danych

• Model danych

– Obejmuje opis podstawowych struktur danych, obiektów biznesowych,

encji, klas związanych z systemem

– Może być zaprezentowany w postaci zgrubnych diagramów klas,

diagramów E/R itp..

Model danych

• Słownik danych obejmujący tabelaryczny opis:

– Klas/encji

– Atrybutów

– Relacji pomiędzy klasami/encjami

– Wejść i wyjść

• Słowniki te mogą ulec zmianie i aktualizacji w dalszym procesie

projektowania systemu

Słownik danych - przykład

Class

Depot Identifier

Depot

Class

Truck Identifier

Truck

Class

Reading Time + Temperature Measurement

Temperature Reading

Class

Road Section Identifier + Road Section

Coordinates

Road Section

Class

Road Name + Road Number

Road

Class

Forecast Temperature + Forecast Time

Forecast

Class

District Name + District Size

District

Type

Content

Name

Zakres produktu

• Diagramy przypadków użycia – graficzne przedstawienie:

– interakcji użytkowników systemu (aktorów) z systemem jako

całością lub poszczególnymi jego modułami

– interakcji pomiędzy poszczególnymi modułami systemu

– interakcjami pomiędzy systemem a zewnętrznymi systemami

Zakres produktu

Wymagania funkcjonalne

• Stwierdzenia opisujące:

– jakie usługi ma oferować system

– jak ma reagować na określone zdarzenia

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

– jak ma reagować w określonych sytuacjach

Kryteria spełnienia

• Umożliwiają testowanie i sprawdzanie zrealizowania wymagań,

• Kryterium spełnienia jest dla wymagania miarą, która umożliwia

określenie, czy oferowane rozwiązanie spełnia dane wymaganie.

• Jeśli nie da się znaleźć kryterium spełnienia dla wymagania, znaczy

to że wymaganie jest albo niejednoznaczne, albo źle zrozumiane.

• Wszystkie wymagania mogą być zmierzone i wszystkie powinny mieć

sprecyzowane kryterium spełnienia.

Szablon wymagań

Stopie

ń

(w wybranej skali) niezadowolenia w przypadku braku implementacji wymagania

Stopie

ń

(w wybranej skali) satysfakcji w przypadku spełnienia wymagania

Zał

ą

czniki (opisy, kopie dokumentów)

Lista wymagań, które nie będą zaimplementowane w przypadku implementacji danego
wymagania

Lista wszystkich powiązanych wymagań

Miara pozwalająca na potwierdzenie realizacji wymagania

Osoba zgłaszająca wymaganie

Lista wszystkich przesłanek i powodów, dla których realizacja wymagania jest istotna

Krótki opis znaczenia wymagania

Odnośnik do przypadku użycia (dotyczy wymagań funkcjonalnych)

Np.: funkcjonalne, estetyczne, …

Unikatowy identyfikator

Rozczarowanie

Satysfakcja

Materiały dodatkowe

Konflikty

Zale

ż

no

ś

ci

Kryterium spełnienia

Ź

ródło

Uzasadnienie

Opis

Id przypadku użycia

Typ wymagania

ID wymagania

Zakres produktu

Id wymagania

1

Nazwa

Logowanie z kartą

Typ wymagania

Funkcjonalne

Opis

System powinien pozwolić na identyfikację
użytkowników specjalnych SWKM

Przesłanka

Dostęp do funkcji SWKM jest chroniony systemem
identyfikacji i autoryzacji

Ograniczenia i warunki

Dotyczy wyłącznie użytkowników specjalnych
obsługujących SWKM i posiadających karty specjalne

Dane wejściowe

Dane niezbędne do identyfikacji i weryfikacji
użytkownika w systemie

Źródło danych wejściowych

Specjalna KM

Wynik

Potwierdzona tożsamość użytkownika SWKM

Przeznaczenie

SWKM

Kryterium spełnienia

Funkcja zaimplementowana zgodnie z opisem oraz
dalszymi ustaleniami

Priorytet

Wymagane

Materiały pomocnicze

Nazwa przypadku użycia

Logowanie z kartą

Wymagania estetyczne

• Wymagania dotyczące wyglądu

• Wymagania dotyczące stylu

Wymagania estetyczne

Wymagane

Priorytet:

Dokumentacja (karty katalogowe)
producenta oferowanych rozwiązań oraz
deklaracja wykonawcy zapewniająca, że
złożona oferta spełnia wymaganie.

Kryterium spełnienia:

Ma istnieć możliwość wykorzystania Karty w
celach reklamowych i innych zgodnie z
planami Zamawiającego.

Przesłanka:

Standardowa karta

musi mieć możliwość

uzupełnienia na niej trwałego nadruku
(zdjęcie i odpowiedni tekst) na drukarce do
drukowania kart plastikowych (np.
termosublimacyjnej) w procesie
personalizacji karty.

Opis:

Estetyczne

Typ wymagania:

Id wymagania

Wymagania dotyczące ergonomii i
wygody

• Wymagania dotyczące łatwości użytkowania

• Wymagania dotyczące personalizacji i

lokalizacji

• Wymagania dotyczące nauki produktu

Wymagania dotyczące ergonomii i
wygody

Wymagane

Priorytet:

Deklaracja wykonawcy zapewniaj

ą

ca,

ż

e zło

ż

ona

oferta spełnia wymaganie.

Kryterium spe

ł

nienia:

Wygoda u

ż

ytkowników systemu oraz maksymalizacja

przepustowo

ś

ci systemu.

Przes

ł

anka:

Kasowniki musz

ą

by

ć

umieszczone przy ka

ż

dym

wej

ś

ciu do pojazdu według nast

ę

puj

ą

cego schematu:

przy wej

ś

ciach z przodu i z tyłu pojazdu po jednym

kasowniku od strony

ś

rodka pojazdu; przy wej

ś

ciach

ś

rodkowych po jednym kasowniku z obu stron drzwi;

przy wej

ś

ciach

ś

rodkowych, w których zastosowano

podwójne drzwi (dwa wej

ś

cia blisko siebie) po jednym

kasowniku z lewej strony lewych drzwi oraz z prawej
strony prawych drzwi.

Opis:

Ergonomiczne

Typ wymagania:

Id wymagania

Wymagania wydajnościowe

• Wymagania dotyczące prędkości i czasów dostępu

• Wymagania dotyczące bezpieczeństwa korzystania z systemu

• Wymagania dotyczące precyzyjności i dokładności

• Wymagania dotyczące niezawodności i dostępności

• Wymagania dotyczące odporności i tolerancji na błędy

• Wymagania dotyczące potencjalnej wydajności

• Wymagania dotyczące skalowalności lub rozszerzalności

• Wymagania dotyczące czasu życia produktu

Wymagania wydajnościowe

Wymagane

Priorytet:

Dokumentacja (karty katalogowe) producenta

Dokumentacja (karty katalogowe) producenta

oferowanych rozwi

oferowanych rozwi

ą

ą

za

za

ń

ń

oraz deklaracja wykonawcy

oraz deklaracja wykonawcy

zapewniaj

zapewniaj

ą

ą

ca,

ca,

ż

ż

e z

e z

ł

ł

o

o

ż

ż

ona oferta spe

ona oferta spe

ł

ł

nia wymaganie.

nia wymaganie.

Kryterium spe

ł

nienia:

Jest to ogólnie przyj

ę

te rozwi

ą

zanie dla kart

bezstykowych. .

Przes

ł

anka:

Pr

ę

dko

ś

ci transferu danych (pisanie i odczyt) pomi

ę

dzy

kart

ą

elektroniczn

ą

a czytnikiem karty ma wynosi

ć

co

najmniej: 242 kbit/s

Opis:

Wydajno

ś

ciowe

Typ wymagania:

Id wymagania

Wymagania dotyczące warunków oraz

środowiska pracy

• Oczekiwane fizyczne środowisko pracy produktu

• Wymagania dotyczące kontaktu z innymi systemami

• Wymagania marketingowo-sprzedażowe

• Wymagania dotyczące wydawania kolejnych wersji produktu

Wymagania dotyczące warunków oraz
środowiska pracy

Wymagane

Priorytet:

Dokumentacja (karty katalogowe) producenta
oferowanych rozwi

ą

za

ń

oraz deklaracja wykonawcy

zapewniaj

ą

ca,

ż

e z

ł

o

ż

ona oferta spe

ł

nia wymaganie

Kryterium spe

ł

nienia:

Wymóg dla warunków klimatycznych
charakterystycznych dla terenu obj

ę

tego wdro

ż

eniem.

Przes

ł

anka:

Standardowa karta musi zapewnia

ć

mo

ż

liwo

ść

pracy w

temperaturach od 0°C do +50°C

Opis:

Warunki

Typ wymagania:

Id wymagania

Wymagania dotyczące utrzymania i
wsparcia

• Określenie przy pomocy liczb czasu, potrzebnego na dokonanie

wyspecyfikowanych zmian w produkcie

• Zakres wsparcia, którego wymaga produkt

Wymagania bezpieczeństwa

• Wymagania dotyczące dostępu

• Wymagania dotyczące rzetelności danych

• Wymagania dotyczące ochrony prywatności

• Wymagania dotyczące audytu

Wymagania bezpieczeństwa

wymagane

Priorytet:

Dokumentacja (karty katalogowe) producenta
oferowanych rozwi

ą

za

ń

oraz deklaracja wykonawcy

zapewniaj

ą

ca,

ż

e zło

ż

ona oferta spełnia wymaganie.

Kryterium spe

ł

nienia:

Karta ma by

ć

łatwa w u

ż

yciu i nie powodowa

ć

niepotrzebnych utrudnie

ń

dla u

ż

ytkownika.

Przes

ł

anka:

W przypadku gdy transakcja dla Standardowej karty nie
została zako

ń

czona sukcesem (z powodu złego

podpisu, bł

ę

du kary, nieprzewidzianego zamkni

ę

cia

systemu, awarii, itp.) wówczas wszystkie operacje
wykonane w pami

ę

ci karty w czasie trwania aktualnej

sesji (transakcji) musz

ą

zosta

ć

anulowane.

Opis:

Bezpiecze

ń

stwo

Typ wymagania:

Id wymagania

Wymagania kulturowe i polityczne

• Wymagania kulturowe i polityczne

• Wymagania prawne

Wymagania kulturowe i polityczne

wymagane

Priorytet:

Deklaracja wykonawcy zapewniaj

ą

ca,

ż

e zło

ż

ona

oferta spełnia wymaganie.

Kryterium spe

ł

nienia:

Ogólne przyj

ę

te normy dla produktów powszechnego

u

ż

ycia.

Przes

ł

anka:

Karta ma nie obra

ż

a

ć

uczu

ć

religijnych i narodowych.

Opis:

Kulturowe

Typ wymagania:

Id wymagania

Jakość opisu wymagań

Każde wymaganie powinno być:

• Kompletne (Completeness)

• Możliwe do śledzenia (Traceability)

• Spójne (Consistency)

• Zgodne z zakresem (Relevancy)

• Poprawne (Correctness)

• Jednoznaczne (Ambiguity)

• Wykonalne (Viability)

• Określa co, a nie jak (Deal only with the problem)

• Gold Plating

Kompletność (Completeness)

• Czy dokumentacja jest kompletna i zawiera wszystkie

istotne wymagania funkcjonalne, wydajnościowe, bądź w
odniesieniu do systemów zewnętrznych.

• Brak sekcji “to be determined” (TBD).

Możliwość śledzenia (Traceability)

• Każde wymaganie powinno być wyspecyfikowane w

pojedynczym, ponumerowanym punkcie, a odwołanie do
niego powinny być jednoznaczne:

– Backward traceability – oznacza, że wiemy dlaczego

każde wymaganie zostało wyspecyfikowane oraz
każde wymaganie odwołuje się do swojego źródła.

– Forward traceability – każdy dokument umożliwia

dokładne określenie każdego wymagania.

Spójność (Consistency)

• Istnieją 3 typy konfliktów:

– Różne określenia na to samo (synonimy).

– W dokumentacji istnieją różne definicje tego samego

elementu lub niespójne definicje.

– Błędy logiczne lub związane z następstwem czasu, np.

“Zdarzenie A poprzedza zdarzenie B” w jednej części,
a w drugiej “Zdarzenia A i B występują jednocześnie”.

Zgodność z zakresem (Relevancy)

• Czy wymaganie jest zgodne z celem oraz

zakresem produktu.

Poprawność (Correctness)

• Każde wymaganie przedstawia poprawnie

wymaganą funkcjonalność.

Jednoznaczność (Disambiguity)

• Problem z wieloznacznością jest związany z używaniem

języka naturalnego.

• Należy zatem sprawdzić, czy nie ma możliwości różnych

interpretacji każdego wymagania.

• Specyfikacja powinna być krótka, precyzyjna i klarowna.

• Należy stworzyć słowni pojęć, gdy niektóre pojęcia

mogłyby być różnie interpretowane.

• Kryteria spełnienia są miarą spełnienia wymagania i

może być używane w trakcie testowania produktu.

Jednoznaczność (Disambiguity)

• Przykład niejednoznaczności:

– Dane powinny zostać przesłane do centralnej bazy

danych i zapisane w możliwie krótkim czasie po
naciśnięciu przycisku „zapis” przez użytkownika.

• Przykład jednoznaczności:

– Dane powinny zostać przesłane do centralnej bazy

danych i zapisane w czasie nie dłuższym niż 5 sekund
po naciśnięciu przycisku „zapis” przez użytkownika.

Wykonalność (Viability)

• Wymagania wykonalne to te, które spełniają ograniczenia projektu.

• Należy przy tym zastanowić się nad odpowiedziami na następujące

pytania:

– Czy posiadamy wiedzę i umiejętności aby je spełnić?

– Czy posiadamy wystarczające zasoby (czas, pieniądze) aby je

spełnić?

– Czy są one akceptowalne przez interesariuszy?

Wymagania/Rozwiązania

• Wymagani powinny określać co ma być wykonane, a nie

jak

.

– W niektórych wypadkach mogą sugerować rozwiązania,

jeżeli jest to związane z ograniczeniami projektu.

• Wymagania muszą być zrozumiałe przez klienta, jak i

wykonawcę.

Wymagania/Rozwiązania

• Rozwiązanie:

– Produkt powinien mieć zegar na pasku menu.

• Wymaganie:

– Wymagane jest udostępnienie użytkownikowi informacji o

bieżącym czasie.

• Rozwiązanie:

– Użytkownik powinien używać hasła aby logować się do

systemu.

• Wymaganie:

– System powinien udostępniać informacje tylko autoryzowanym

użytkownikom.

Problemy otwarte

• Problemy, które rozstały rozpoznane w trakcie

dotychczasowych prac nad projektem i jeszcze nie ma dla
nich rozwiązania.

Problemy otwarte

• Problemy, które rozstały rozpoznane w trakcie

dotychczasowych prac nad projektem i jeszcze nie ma dla
nich rozwiązania.

• Przykład

– Nie ma pewności odnośnie tego, czy nowa wersja

systemu Android będzie kompatybilna z tworzoną
wersją modułu mobilnego

Gotowe rozwiązania alternatywne

• Lista istniejących produktów – systemów,

które mogą być rozważane jako
potencjalne rozwiązania lub źródła
pomysłów dla projektowanych rozwiązań

Nowe problemy

• Opis tego, jak produkt będzie oddziaływał na otoczenie po jego

wdrożeniu

– Wpływ na bieżące otoczenie

– Wpływ na zainstalowane systemy

– Potencjalne problemy użytkowników

– Ograniczenia w przewidywanym środowisku implementacyjnym,

które mogą zahamować rozwój nowego produktu

– Potencjalne problemy nie do przezwyciężenia

Nowe problemy

• Opis tego, jak produkt będzie oddziaływał na otoczenie po jego

wdrożeniu

– Wpływ na bieżące otoczenie

– Wpływ na zainstalowane systemy

– Potencjalne problemy użytkowników

– Ograniczenia w przewidywanym środowisku implementacyjnym,

które mogą zahamować rozwój nowego produktu

– Potencjalne problemy nie do przezwyciężenia

• Przykład

– Zwiększenie ilości przetwarzanych danych po wdrożeniu systemu

może spowodować, że obecnie wykorzystywana baza serwerów

nie będzie wystarczająca do obsługi transakcji realizowanych w

systemie

Dokumentacja dla użytkownika i szkolenia

• Wymagania dotyczące dokumentacji

użytkownika

• Wymagania dotyczące szkoleń

Poczekalnia

• Wymagania, które nie dotyczą zamawianego

produktu, ale planuje się ich realizację w
przyszłości.