🚀 go-pugleaf

Witam,

Mi na temat "proces analizy" otwiera się w myślach takie drzewko

1. Proces analizy
1.1. Analiza wymagań
1.1.1. Wymagania funkcjonalne
1.1.2. Wymagania niefunkcjonalne
1.2. Analiza dziedziny problemu

No to po kolei:

1.1. Analiza wymagań jest opisem jakie wymagania są stawiane przed
systemem z punktu widzenia użytkownika (szeroko pojętego
użytkownika, bo administrator systemu też jest jego użytkownikiem)

1.1.1. Wymagania funkcjonalne to te które da się przedstawić w
postaci przypadków użycia. Istnieje w UML'u diagram przypadków
użycia ale jego użyteczność sprowadza się do wygodnego spisu
treści. Prawdziwe przypadki użycia muszą mieć formę tekstową i
obejmować wiele elementów. Tutaj:
http://www.agilemodeling.com/shared/UseCaseTemplateFormal.doc jest
dobry szablon przypadku użycia. Dobre szablony można też znaleźć w
książce Alstaire'a Cockburne'a "Writing Efective Use Cases"
(przetłumaczona na polski przez WNT)

1.1.2. Niefunkcjonalne wymagania - to te które nie dają się
przestawić jako scenariusze przypadków użycia. Należą do nich:
reguły businessowe, przypadki zmian, prototypy interfejsów, reguły
dotyczące jakości, licencjonowania, użyteczności, skalowalności,
reguł używania, wykorzystania obcego software'u i bibliotek.
Niestety, tutaj UML nas opuszcza i nie daje nic do przedstawienia -
pozostaje zwykły procesor tekstu i jakaś tabelka zbiorcza. Wiem że
niektóre narzędzia do modelowania w UML'u (np. Enterprise Architect)
dostarczają rozszerzenia UML'a do modelowania niefunkcjonalnych
wymagań.

1.2. Analiza dziedziny problemu. Tutaj w UML sprawdza się znakomicie.
Najczęściej używa się diagramów klas i diagramów obrazujących
zachowanie (praktycznie wszystkich)

-- 
Pozdrawiam
  Piotr Jachowicz