Cel analizy

Celem analizy funkcjonalnej jest ustalenie wymagań wobec projektowanego systemu oraz przełożenie tych wymagań na jego funkcje.

Pracę tą wykonujemy, korzystając z wcześniejszych ustaleń, wykonanych w trakcie analizy merytorycznej i zawartych we wstępnym projekcie.

Odnosząc się do metod zarządzania projektami, należy uznać, że analiza funkcjonalna rozpoczyna się od ustalenia zakresu projektu, następnie dokonujemy analizy interesariuszy i przechodzimy do ustalenia szczegółowych celów projektu.

Wśród interesariuszy należy wyróżnić aktorów, którzy będą użytkownikami tworzonego systemu. Pojęcie „aktor” ma tu jednak szersze znaczenie, gdyż obejmuje także poza-osobowe elementy systemu (moduły, programy).

Posiadając informacje o aktorach i celach, jakie im przyświecają, możemy dokonać analizy oczekiwanych funkcji.

Analiza

Zakres

Zgodnie z propozycją Cockburna [1], zakres projektu możemy ustalić poprzez stworzenie wykazu tematów (funkcji), jakie zidentyfikowaliśmy w trakcie analizy i podjęcie decyzji, które z nich zostaną ujęte w analizowanym systemie.

Tworzy się w ten sposób tabelkę opisującą zakres funkcjonalny systemu jako zestawienie w/poza:

Lp	Temat	W	POZA
Zagadnienie 1
1-1	Temat 1	X
1-2	Temat 2	X
1-3	Temat 3		X
Zagadnienie 2
2-1	...

Tabela 1. Lista W/POZA

Interesariusze

Aktorzy

Do celów analizy funkcjonalnej musimy ustalić interesariuszy, którzy będą aktywnie uczestniczyć w działaniu systemu. Nazywa się ich aktorami. Aktorów możemy zestawić w tabeli, opisującej także kluczowe potrzeby, jakie system powinien uwzględnić.

Aktor	Kluczowe potrzeby
Aktor1	Opis potrzeb ….
...	...

Tabela 2. Główni aktorzy

Pozostali interesariusze

Analiza pozostałych interesariuszy nie ma znaczenia dla samego docelowego projektu, ale jest ważnym elementem zarządzania projektami, który może decydować o jego sukcesie. Analiza taka obejmuje informacje, jakie będzie oddziaływanie projektu na interesariuszy, jaki oni mają wpływ na projekt i jaką wobec nich podjąć strategię. Na przykład zarząd firmy może nie korzystać bezpośrednio z projektowanego systemu, ale ma nań decydujący wpływ (finansowanie) i będą go dotyczyć uzyskiwane efekty. Dlatego należy przyjąć strategię polegającą na informowaniu o oczekiwanych efektach i postępach prac.

Interesariusz	Oddziaływanie projektu	Wpływ na projekt	Strategia

Tabela 3. Analiza interesariuszy

Cele szczegółowe

Główny cel postawiony przed systemem musimy poprzez analizę rozbić na cele szczegółowe, które dotyczą poszczególnych aktorów. Znów można zaproponować tabelę zawierającą listę aktor – cel:

Lp	Główny aktor	Cel	Priorytet
1	Aktor 1	Cel 1	wysoki
2	...	….

Tabela 4. Lista cel – aktor (do uzupełnienia)

Przypadki użycia (use cases)

Przypadki użycia to opisy w jaki sposób system powinien być używany przez aktora w celu osiągnięcia konkretnego celu. Opis ten nie zawiera szczegółów dotyczących implementacji oraz interfejsu użytkownika.

Pomimo tego, że przypadki użycia są stosunkowo prostym narzędziem analizy systemów, istnieje wokół nich wiele kontrowersji. W niniejszym opracowaniu wykorzystano podejście Alistaira Cockburna opisane w pracy „Writing Effective Use Cases” (polskie tłumaczenie „Jak pisać efektywne przypadki użycia” wydało PWN [1]).

Jednak słuszną wydaje się krytyka Jarosława Żelińskiego, który zarzuca Cokburnowi zbytnie komplikowanie prostego zagadnienia. Podejście jakie tutaj zastosujemy jest czysto pragmatyczne. Wybrane zostaną z propozycji Cokburna te elementy, które ułatwiają osiągnięcie zapisanego na początku celu. Jako nieporozumienie można traktować w związku z tym opisywanie przypadków użycia jako alternatywy dla procesów biznesowych (zob. Łukasz Olek, „Wykorzystanie przypadków użycia do opisywania procesów biznesowych”).

Cockburn proponuje określenie dla każdego przypadku użycia, jaki jest jego zakres i poziom:

zakres	ang.
gospodarczy - opis zewnętrzny	enterprise
gospodarczy - szczegóły	system
systemowy - opis zewnętrzny	subsystem
systemowy - szczegóły	subsystem
komponentowy	component

Tabela 5. Oznaczenia zakresu projektowego

opis ogólny	very high summary
poziom streszczenia	summary
poziom użytkownika (niebieski)	user-goal
podfunkcje	subfunction
poziom najniższy	too low

Tabela 6. Oznaczenie nazwanych poziomów

Cele wyższego poziomu skupiają się na pytaniu: dlaczego; poziom niższy – jak.

Pomimo kontrowersji wokół potrzeby takiego szczegółowego rozróżnienia, nie sądzę, aby jego stosowanie prowadziło do zaciemnienia projektu, a niekiedy może być przydatne. Dlatego można to traktować jako opcjonalny element analizy (dodatkowe objaśnienie).

Szkice przypadków użycia

Tworzenie przypadków użycia rozpoczynamy od ich zestawienia zawierającego aktora głównego oraz szkic (będący po prostu prostym opisem w języku potocznym celu i sposobu, w jaki ten cel będzie osiągany). Możemy takie zestawienie ująć w tabeli:

ID	zakres	poziom	Aktor główny	Szkic
...	...

Tabela 7. Szkice przypadków użycia (do uzupełnienia)

Przypadki użycia

Przypadki użycia należy opisywać w postaci tekstowej, traktując schematy (UML) jako poglądową ilustrację. Zgodnie z propozycją Cockburna, przypadek użycia powinien mieć następującą strukturę:

Cel w kontekście:

Minimalna gwarancja: (co zostaje zrealizowane na pewno)

Główny scenariusz powodzenia: (jak to zostanie zrealizowane)

Rozszerzenia: (dodatkowe/alternatywne działania, wyjątki)

	Warunki rozszerzeń	Obsługa rozszerzeń
1

Ponieważ niniejszy tekst zostanie zilustrowany praktycznym przypadkiem analizy, poprzestańmy tutaj na takim pobieżnym opisie.

Literatura:

[1] Alistair Cockburn „Jak pisać efektywne przypadki użycia”, WNT 2004 ( Alistair Cockburn: WRITING EFFECTIVE USE CASES Adres URL)

[2] "Identifying and Analyzing Stakeholders and Their Interests"