Jeden z moich ulubionych autorów, [[Ronald G. Ross]], w artykule Business Vocabulary: The Most Basic Requirement of All napisał:
Ask managers and workers in the business what they mean by requirements for developing software systems, and typically you get answers centered on features and functions, or on the look-and-feel of user interfaces. The answer “business vocabulary” (or “shared business vocabulary”) is almost never among the responses. Nonetheless, a shared, well-structured business vocabulary is indeed a kind of requirement. (Business Vocabulary: The Most Basic Requirement of All).
“Zapytaj menedżerów i ich podwładnych co rozumieją pod pojęciem wymagań na oprogramowanie, z reguły dostaniesz odpowiedź skupiająca się na jego cechach i funkcjonalnościach lub na tym jak ma wyglądać interfejs użytkownika. Odpowiedź “słownik pojęć biznesowych” w zasadzie nigdy nie pada. Pomimo tego, dobrze ustrukturyzowany słownik pojęć biznesowych jest także wymaganiem.”
Ale o co chodzi z tym słownikiem? Słownik to lista pojęć i ich znaczenia, a co mówi słownik (j.polskiego) o słowniku:
słownik ?indywidualny zasób wyrazów?
znaczenie ?treść, której znakiem jest wyraz lub wyrażenie?
Dlaczego słownik miałby być wymaganiem? Przypomnę, że wymaganie to “warunek jaki coś musi spełniać, by było przydatnym do określonego celu”. Jeżeli np. oprogramowanie ma być przydatne do “czegoś”, to pojęcia (słowo i jego znaczenie) “zastosowane” w tym oprogramowaniu muszą spełniać wymaganie zgodności z tymi “używanymi” w dziedzinie w jakiej oprogramowanie będzie stosowane. Ta zgodność to nie tylko używane słowa, to stanowczo za mało. Znaczenie to “treść”. Tak więc, np. faktura to nie tylko papier z danymi, powinna być “czymś co zaświadcza o dokonaniu transakcji kupna-sprzedaży” a np. “towar” to coś co jest przedmiotem tej transakcji.
Pierwszym etapem analizy (prowadzonej opisywaną metodą), bardzo trudnym, jest opracowanie modelu pojęciowego. Celem budowy tego modelu jest zrozumienie na poziomie komunikacji (tak zwany biznes z developerem -> zagwarantowanie jednoznaczności) oraz zrozumienie tego, co jest przedmiotem projektu (modelując magazyn raczej planujemy oprogramowanie symulujące kartoteki magazynowe a nie produkty w magazynie). Ważne jest by na oprogramowanie patrzeć jak na narzędzie, bo ono nim jest. Oprogramowanie wspomagające zarządzanie magazynem, nie zastępuje tego magazynu i towarów w nim…
Tak więc oprogramowanie, nazwy w nim używane, muszą spełnić warunek zgodności ze “słownikiem biznesowym”: biznesowy słownik pojęć (zgodność z nim) to jest wymaganie.
Pierwszy etap analizy biznesowej to między innymi opracowanie biznesowego słownika pojęć (model pojęciowy), kolejny etap to opracowanie modelu dziedziny i listy usług “systemu” (wymagania funkcjonalne – przypadki użycia). Potem scenariusze przypadków użycia, operacje klas… o tym nie raz było ale pewnie nie raz będzie… z różnych perspektyw.
Potwierdzam, że opracowanie dobrze ustrukturyzowanego słownika pojęć binzesowych jest zadaniem bardzo trudno. Główne trudności jakie aktualnie dostrzegam to:
– liczba pojęć biznesowych – zaleca się, aby słownik zawiera listę kluczonyw dla organizacji pojęć. Często jako analitycy jesteśmy zalewami dziesiątkami pojęć (z istniejących dokumentów, od interesariuszy). Próbując je uporządkować np. w postaci diagramu faktów, robi sie z tego skomplikowany model;
– uzgodnienie słownika odpowiadajęcego różnym interesariuszom. Często mamy do czynienia z sytuacją, kiedy jakieś pojęcie bizneowe posiada inne znaczenie dla różnych iteresariuszy. Zniwelowanie tego problemy wymaga niekiedy wprowadzenie nowych, dość “szczutnych” (dla danego interesariusza) pojęć, co nie zawsze spotyka się ze zrozumieniem i akceptacją;
– poziom ogólności pojęcia. Opracowując słownik prawie zawsze można się odwołać do słownika języka polskiego i wykorzystać zapisane tam definicje. Zauwazyłem jednak, że definicje słownikowe często budzą u interestaiuszy niechęć a wręcz sprzeciw. Z drugiej storny definicja pojęcia nie może abstrahować od rdzenia jakim są definicje słonikowe. Większość definicja pojęć biznesowych, które widziałem była albo zbyt słownika albo za bardzo od tego słownika (rdzienia) oddalona;
– akceptacja słownika. Tu mam pytanie do autora – kto powinien akceptować/uzgadniać słownik pojęć biznesowych?
– co do liczby pojęć to bywa to liczba duża ale raczej kilkadziesiąt niż kilka set, metodą zalecaną w książce Rossa jest uznanie, że to “fakt” (istnienie takowego) decyduje o tym czy dane pojęcie ma się znaleźć w słowniku czy nie,
– różni interesariusze: potrafią to skomplikować, dlatego bywa, ze robię słowniki osobne dla każdego interesariusz, “tłumaczem” jest system aliasów
– osobiście jestem za tym by definicje biznesowe mieściły się a nie kolidowały ze sł. j.polskiego, opory bywają, trzeba negocjować 🙂
– osobiście stosuje zasadę, że sponsor (interesariusz) stawiający wymagania biznesowe akceptuje biznesowy słownik pojęć (jego rola jest usuwanie niejednoznaczności) , IT nie ma tu nic do gadania (mimo, że nie raz próbuje)
Rozumiem, że napisanie ogólnego słownika, do wykorzystania w projektach jest niemożliwe, ale czy nie jest w naszym zasięgu napisanie pewnego rodzaju podstawy słownikowej zawierającej pojęcia występujące zawsze oraz zasady budowy i dodawania nowych pojęć?
Myślę, że słownika powielalnego napisać się nie da, ale pewna podstawa jest możliwa: ja używam – jako szkieletu – słownika zawierającego kluczowe pojęcia z zakresu zarządzania, typu Proces biznesowy, Wymaganie, Przypadek użycia, właściciel procesu, rola, itp. Zasady budowy są w pewnym sensie opisane w SBVR, lepiej w książce Business Rules Concept. Generalnie narzędziem jest budowanie słownika w ten sposób, że dodajemy (tylko) te pojęcia, które są powiązane z zakresem projektu jakimś faktem (zdarzeniem).