http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
źr. http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471

Reguły – jakie nie powinny być…

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…

Czytaj dalejReguły – jakie nie powinny być…

Panowanie nad złożonością czyli gdzie są Przypadki Użycia czyli MVVM-MVC

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.

Czytaj dalejPanowanie nad złożonością czyli gdzie są Przypadki Użycia czyli MVVM-MVC

Koniec treści

Nie ma więcej stron do załadowania