źr. http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
Kolejny artykuł z gatunku "przemyślenia i rady na koniec roku" :) Często spotykam się traktowaniem reguł biznesowych jak jakiegoś piątego koła u wozu (o ile w ogóle się ktoś nimi zajmuje w projekcie). Pół roku temu pisałem, że reguły biznesowe to, jeżeli stają się wymaganiem, stanowią kluczowy element realizowanej logiki biznesowej: Sprawdzoną metodą skutecznego (spójność, kompletność, niesprzeczność) zapisywania wymagań dziedzinowych (w tym ?walidacje?) jest wydzielenie w dokumentacji: słownika pojęć słownika reguł biznesowych specyfikacji tablic decyzyjnych jako uzupełnienia reguł biznesowych. (Gdzie są te cholerne szczegóły). Jest jednak drugi, nie mniej ważny, element każdego…
Tak więc przypadkami użycia opisujemy abstrakcję jaką jest [[Model Dziedziny Systemu]]. Są one wtedy proste, zawierają scenariusz, który w skrócie ma postać: aktor inicjuje usługę, system prezentuje formularz do wypełnienia, aktor wypełnia go i potwierdza, system potwierdza odebranie danych i pokazuje wynik swojej pracy (lub komunikaty o błędach). Tu skupiamy się na opisie tego jakie usługi są wymagane od systemu. Kolejny etap to "komplikowanie" każdego scenariusza w postaci projektowania, dla każdego przypadku użycia, różnego rodzaju wizardów lub wprowadzamy ograniczenia związane z uprawnieniami użytkowników. Ten etap to praca projektantów UX i grafików, specjalistów od ergonomii itp.