Dzisiaj krótki artykuł o wymaganiach dziedzinowych. W jednym z poprzednich artykułów pisałem o wymaganiach, że problem tkwi w ich zrozumieniu i o tym, że przyszły użytkownik nie powinien pisać “jaki ma być ten program”, bo popycha projekt w stronę chaotycznych oczekiwań.
I tu jest sedno: analiza nie powinna być tylko pasmem wywiadów, którego produktem będę setki stron zapisów z ankiet i przeprowadzonych rozmów. Analiza, to duża praca, której celem powinno być zrozumienie a nie tylko opisanie. (Analiza wymagań na oprogramowanie czyli opisanie czy zrozumienie).
Wymagania najczęściej dzielimy na funkcjonalne i poza-funkcjonalne. Warto jednak uporządkować projekt i ukierunkować analizę najpierw na wymagania biznesowe a potem do już wymienionych dodać wymagania dziedzinowe. Te ostatnie są tak na prawdę wydzieleniem z chaosu oczekiwań czegoś co nazwę “jak to jest robione” ale nie w kontekście oprogramowania (programiści wiedzą jak programować), a w kontekście reguł biznesowych i decyzyjnych (wiedzy o tym jak się rzeczy dzieją).
Oprogramowania bezpośrednio dotyczą tylko wymagania funkcjonalne, poza-funkcjonalne i dziedzinowe. Wymagania biznesowe to cele jakie ma przed sobą organizacja, dla której ma powstać (ma zostać jej dostarczone) oprogramowanie. Zresztą, nie należy o tym zapominać, że może istnieć inne rozwiązanie problemu organizacji, niż oprogramowanie.
Oprogramowanie projektowane metodami obiektowymi wg. najlepszych praktyk i wzorców ma następująca strukturę:
Aktor to oczywiście jego użytkownik. Oprogramowanie, jako narzędzie pracy, świadczy usługi jego użytkownikom – aktorom, jest ich narzędziem pracy. Oprogramowanie zawiera:
- klasy (struktury oprogramowania) odpowiadające za jakość świadczonych usług, to klasy realizujące przypadki użycia tego oprogramowania,
- klasy (struktury oprogramowania) odpowiadające za logikę biznesową,
- klasy (struktury oprogramowania) odpowiadające za utrwalanie informacji (obiekty biznesowe).
Wymagania to warunki jakie ma spełniać oprogramowanie by było przydatne. Tak więc Analityk biznesowy powinien zrozumieć jak działa organizacja, zdefiniować narzędzie jakie jej pomoże, opisać wymagania na to narzędzie. Jak? Powiem inaczej, nie jest rolą programistów “odkrywanie” logiki biznesowej, programista odpowiada za jej implementację. Dlatego warto pamiętać o wymaganiach dziedzinowych… nie jest to niestety miejsce na szczegółowy ich opis, tu zapraszam na szkolenie o wymaganiach, które prowadzę.
Praktyka niestety pokazuje, że zapis oczekiwań użytkownika i przekazanie ich programistom to droga na manowce… Oczekiwania w rodzaju rozwijane listy, “myszkologia”, “łatwe w użyciu ekrany” i cała masa innych szczegółów nijak się ma do tego jak to oprogramowanie ma działać. To tylko cechy użytkowe interfejsu użytkownika, te jednak bez wewnętrznej logiki po pierwsze o niczym nie mówią, a po drugie i tak są efektem gotowych elementów z jakich buduje się interfejs użytkownika. Warto o ich wspomnieć by zamawiający miał ich świadomość ale nie oszukujmy się, opisujemy tak tylko to co znamy już z innych aplikacji a to w pewnym sensie standard (np. dotykowy ekran smartfona czy tabletu).
Zapisanie zaś, że system ma pozwalać na dobór promocji dla klientów o różnych poziomach zakupów, po pierwsze nic nie mówi, po drugie wymaga analizy “o co chodzi” i są to właśnie wymagania dziedzinowego. Wymaganiem funkcjonalnym będzie tu to: System pozwala na zarządzanie listą upustów. W języku polskim i nie tylko funkcja to zadanie, które spełnia lub ma spełnić jakaś osoba lub rzecz. Innymi słowy wymaganie funkcjonalne to to do czego ma służyć oprogramowanie a nie to jak ma to robić.
Przypomnę na zakończenie: powyższe to tylko pewne dobre praktyki 🙂 bazujące na metodach obiektowych (a w zasadzie takie głównie są teraz a w użyciu) i wzorcach projektowych.
