Temat: Jednoznaczność wymagań biznesowych
Monika Korbecka:
Z Twojej wypowiedzi wynika, że odbiorcami dokumentacji analitycznej jest projektant/architekt, brakuje mi tu klienta biznesowego, dla którego tworzone jest rozwiązanie. Czy taka rola nie występuje, jako odbiorca dokumentacji analitycznej i wymagań?
Owszem, ale niejako z drugiej strony. Biznes jest dla mnie uzupełniającym źródłem wymagań, oni mogą odbierać dokumentację analityczną w sensie testowania modeli biznesowych i odpowiedzi na pytanie - czy te modele to Wasz biznes. Także dla mnie jest to element tworzenia tej dokumentacji.
Zgadzam się, że metody wizualne pomagają w definiowaniu wymagań, ale BPMN jest notacją do opisywania procesów, a UML jest często niezrozumiały dla użytkownika biznesowego.
Ja mam do czynienia z analizą biznesową jako elementem analizy wymagań na systemy informatyczne. Dlatego dla mnie istotnym elementem jest model dziedziny jaka jest podmiotem w działaniach biznesu. Innymi słowy chcę jednoznacznej obiektowej definicji tego czym jest z punktu widzenia biznesu mojego klienta faktura kosztowa (bo poza księgowością wygląda to różnie), czym jest zlecenie produkcyjne, czym jest konfiguracja maszyny pakującej, czym jest wystawienie listu przewozowego (co to jest list przewozowy i jakie stany może posiadać - np. stworzony, zlecony, dostarczony).
Wymagania dokumentuje się zwykle w formie tekstu. Jak, więc je zapisywać, aby zapewnić prostotę, zrozumienie, opisać je zwięźle i prosto?
Wymagania w formie tekstu, czy, jak czasem żartobliwie mówię, opisie słowno-muzycznym są nic nie warte. Dostałem właśnie jakieś 30 stron obrazków interfejsów i tabelek z numerkami i strzałkami co z czym się wiąże a także jakieś 10 stron tekstu o tym jak użytkownicy będą korzystali z systemu i co to tam w tym systemie ma się dziać.
Kompletnie nic z tego nie wynika - ten dokument nie nadaje się nawet na dane wejściowe do analizy wymagań.
Najważniejszymi cechami dobrej dokumentacji wymagań jest:
- jednoznaczność (pewność, że po pierwsze model odzwierciedla biznes, po drugie ktokolwiek rozumie model, rozumie biznes z przyjętą dokłądnością)
- kompletność (oczywiście z dokładnością do istotności)
- weryfikowalność (możliwość wskazania źródła danego wymagania)
tych cech nie da się utrzymać inaczej niż korzystając z formalnych notacji.
W obiektowym wytwarzaniu oprogramowania konieczne jest zrozumienie biznesu (model procesowy - najlepiej w BPMN) oraz jego transpozycja na model obiektowy (UML). Oczywiście całkowicie pozbyć się części słowno-muzycznej się nie da(choćby scenariusze przypadków użycia, opisy klas), ale jeśli jest ona zorganizowana właśnie w modele procesowy i obiektowy to da się tymi wymaganiami zarządzać i je realizować.
Mateusz Kurleto edytował(a) ten post dnia 05.12.11 o godzinie 10:40
пропозиції роботи
