Temat: Wymagania biznesowe a funkcjonalne
Często spotykam się z myleniem (przeplataniem) wymagań biznesowych i systemowych (rozumianych jako wymagania na system= oprogramowanie).
Preferuje rozłączne traktowanie wymagań jako fazy lub etapy:
- wymagana biznesowe (nieinformatyczne)
- wymagania na oprogramowanie
a Wy?
My też :-)
Oczywiście, że fazy. Oczywiście, że etapy. Oczywiście, że w tej właśnie kolejności. Z tym, że te drugie muszą być śladowalne* wstecz do tych pierwszych i jasno wynikać z tychże. Te pierwsze zaś wywiedzione zostać powinny z procesów, z założeń, z ograniczeń tudzież z reguł biznesowych. Tako rzecze Captain Obvious.
Co poniektórzy (kategoryzacja według Global Association for Software Quality) rozdzielają wymagania na trzy kategorie:
- customer requirements
- solution/system requirements
- product/component requirements
Te trzy poziomy dają się trochę lepiej zmapować do wierszy w siatce Zachmana, niż kategoryzacja dwustopniowa. Przedmiotem zainteresowania analityka w Siatce jest aż 21 z 36 obszarów (wg K. Hass, D. Wesselsa i K. Brennana), więc każdy przy odrobinie dobrej woli znajdzie w niej miejsce, gdzie to upchnąć :-)
Ale sam osobiście preferuję pracę na dwustopniowej, bo nikt nie da budżetu, żeby robić trzy "przebiegi". Kto się zajmuje analizą to wie, że ten zawód dopiero buduje swoje znaczenie, a w większości przypadków "analityk to strata pieniędzy, programiści wszystko zrobią" (w tym właśnie sęk, że "wszystko"). W większości moich projektów byłby to zresztą przerost formy nad treścią (nie współbuduję Airbusa).
Idąc za moją mentorką Suzanne Robertson — całkowicie się zgadzam, że wymagania mają być rozłączne od implementacji. Nawet już na poziomie wymagań na oprogramowanie. Na tym bazuję w pracy i ilekroć uległem pokusie "sprofilowania" wymagania pod konkretną implementację — z reguły tego żałowałem. Test case'y są wtedy dużo mniej elastyczne, itepe.
Nie zawsze się tak da zrobić, bo wymaganie może dotyczyć właśnie szczegółu implementacyjnego (jest to wtedy element projektu), ale wtedy zawsze powinno ono wynikać z CZEGOŚ NADRZĘDNEGO (najlepiej dokumentu). U mnie w firmie stosuje się wymagania dot. reguł stosowania kolorów i kontrolek (kiedy lista, kiedy radiobutton) i jest do tego specjalna księga napisana przez speców od Corporate Identity i usability. No, ale wtedy jest do czego śladować* wstecz takie wymagania.
UML i przypadki użycia bardziej służą do modelowania ROZWIĄZANIA, a nie PROBLEMU — a wiec wymagań na oprogramowanie, a nie biznesowych. PROBLEM jest na tle biznesowym i może przecież nie mieć z żadnym software'm nic wspólnego. PROBLEM może być opisany scenariuszem biznesowym, zamodelowany w BPMN itp. ale wciąż musimy zamodelować i _zrozumieć_ PROBLEM, aby przejść do głowienia się nad ROZWIĄZANIEM. Robertsonowie dzielą to na BUC (Business Use Case) i PUC (Product Use Case). PUC jest wynikiem rozkminienia BUC-a.
Osobiście unikam tych nazw. U mnie "przypadek użycia" zawsze dotyczy ROZWIĄZANIA (czyli de facto systemu informatycznego). Zamiast BUC-a wolę "scenariusz biznesowy" albo cokolwiek innego, ale wpychanie do biznesu terminu rodem z IT (a za taki uważam "przypadek użycia") jest IMO pozbawione sensu.
Tu zgadzam sie ze wspomnianym przez Henryka Oliverem Sachsem, że nie należy pchać slangu lekarskiego do uszu pacjenta.
My, analitycy, powinniśmy znać i rozumieć slang biznesu/klienta, bo mu służymy i on nam płaci. Ale biznes/klient naszego nie musi. Choć nie powiem, miło mi było, kiedy główna księgowa rozrysowała mi kiedyś diagram klas wraz z kardynalnościami. Ale to już zupełnie inna historia.
* Nienawidzę tego słowa
Rozpisałem się jak nigdy, popisałem same oczywiste rzeczy, ale jak życie pokazuje oczywiste one są tylko na papierze. Kto z Was nie spotkał się z klientem biznesowym, który od samego początku ma w głowie gotowy projekt systemu i przy próbie analizy o co chodzi broni go jak Częstochowy? Że to tak właśnie ma być w tym sofcie, bo on to tak wymyślił, bo on jest dyrektorem, a ci ludzie z produkcji to się guzik znają i nie ma co z nimi gadać o problemach, bo on wszystko wie i już zaprojektował, jak to powinno wyglądać?
Czy tylko ja mam "szczęście" do takich ludzi?
Pozdrawiam.
пропозиції роботи
