Analiza nie powinna być tylko pasmem wywiadów, którego owocem będę setki stron zapisów z ankiet i przeprowadzonych rozmów. Analiza wymagań, to duża praca, jakiej celem powinno być zrozumienie, a nie tylko opowiedzenie. Jaka jest różnica? Pokłosiem analizy, a więc poznania zjawiska (pracy przedsiębiorstwa itd.) jest wzornik jej logiki działania (logika biznesowa), tenże model – poprawny – pozwala przypuszczać co nas czeka (testowany jest na prawidłowość losowo wybranymi zdarzeniami w przedsiębiorstwie).

szkolenie

Autor: Juhan Sonin
Źródło: http://www.flickr.com

Tenże wzornik to wzornik dyscypliny systemu (model logiki biznesowej: dokumentacja reguł biznesowych). Rezultatem wywiadów jest niestety jedynie opis konsekwencji w reakcji na bodźce jednak w dalszym ciągu niezrozumiałe jest to „dlaczego akurat takie” efekty.

Wszystko to co nas oplata, samo w sobie jest naturalnie prostym. Złożone są, nie pojedyncze rzeczy, a to, że jest ich sporo i mają na siebie wzajemny wpływ. Zamierzeniem analizy jest rozpoznanie w naszym sąsiedztwie tych prostych elementarnych rzeczy jak też zrozumienie ich obustronnego na siebie wpływu. Zrozumienie to objawia się w postaci zdolności przygotowania modelu tych koegzystujących nieskomplikowanych rzeczy – analiza wymagań na

analiza biznesu

Autor: Brian Harrington Spier
Źródło: http://www.flickr.com

odgadnięcia i przedstawienia ich cech jak też zasad wzajemnego wpływania. Jeżeli tym badanym środowiskiem jest organizacja, powstanie jej model, informacja o tym jak funkcjonuje. A gdzie tutaj jest miejsce na oprogramowanie? Aby powstało, trzeba stworzyć też i jego wzornik, by zrozumieć oraz opisać to czego wymagamy. Pamiętajmy, iż jedna z trudnych gier na świecie – szachy – to jedynie paręnaście figur i proste reguły ich przesuwania. Nawet najogromniejsza organizacja to jedynie skończona ilość funkcji i zasad ich postępowania. Trzeba je tylko poznać.

Nie krytykuję idei stosowania przypadków użycia. One jednak są konkretnymi, zamierzanymi przypadkami użycia oprogramowania, to minimalny zestaw opcji. To nie ma jednak nic wspólnego z wewnętrzną konstrukcją oprogramowania, ta musi modelować zastaną faktyczność. Jest coś takiego jak reguła SOLID projektowania aplikacji. Program, jeżeli w wyniku analizy wymagań opracowano nie tylko raport z wywiadów, ale także model logiki działania, również spełni te zasadę.