Jak dokumentować reguły biznesowe

Zastanawiam się, jaka byłaby formalna i najczęściej stosowana metoda dokumentowania reguł biznesowych? Również w jaki sposób dokumentujesz specyfikacje interfejsu użytkownika artefaktów programistycznych (np. Dokumentowanie pól formularza i zachowanie przycisków w formularzu, tekście informacyjnym itp.)

Jeśli chodzi o reguły biznesowe, myślę, że @Joppe wskazał na UML, o którym wszyscy myśleliśmy.

Diagramy przypadków użycia zapewniają doskonały przegląd interakcji aktorów / ról z systemem i jego działania. Dla complexe Korzystanie przypadku dodatkowe informacje pomogą wyjaśnić tekstowo dużo ( warunki wstępne , postconditions , uzależnienia od poprzednich wykonań UC , etc )

Istnieją diagramy, które świetnie sprawdzają działalność firmy na różnych poziomach:

• Schemat automatu stanów, jeśli istnieją stany do udokumentowania.
• Diagram aktywności . W przypadku złożonego przypadku użycia może być konieczne szczegółowe omówienie. Poziom szczegółów zależy od Ciebie i zależy od tego, kto będzie czytał dokumentację. Dokument ten może nie wydawać się dokumentacją biznesową, ale przy odpowiednim poziomie szczegółowości może się tak stać.

Tylko rada, przypisz kod do każdego przypadku użycia (np .: UC-1 , UC-n ). Przydadzą się one później, podczas dokumentacji interfejsu użytkownika.

W przypadku dokumentacji interfejsu użytkownika powszechną praktyką (obecnie) jest tworzenie szkieletów . Całkiem lepiej niż zrzuty ekranu, ponieważ wygląda na czystsze i prostsze. Na przykład spójrz na WireframeSketcher

Modele szkieletowe mogą nie być wystarczającą dokumentacją, dlatego na każdym ekranie wykonaj krótkie wprowadzenie i opisz każdy przycisk. Dodatkowo wykonaj odniesienia do UC zaangażowanego w ekran ( zobacz teraz, dlaczego kody UC są przydatne ). Dzięki temu twoja dokumentacja będzie spójna.

Istotą narzędzi takich jak Wireframesketcher jest to, że wykonują interaktywne makiety. Idealne, aby dać klientowi coś interaktywnego podczas projektowania lub rozwoju.

Nie zapomnij udokumentować planu nawigacji . Nav. Plan nie ma diagramu UML, ale zamiast niego można użyć diagramu automatu stanów . Nie chodzi o to, co zostało zrobione, ale nadal.

Wreszcie pamiętaj, do kogo się zwracasz.

• Technik : możesz zagłębić się w szczegóły i użyć szczegółów technicznych.

• Nie technik : unikaj szczegółów technicznych (niezwiązanych z językiem ani kodem). Staraj się być jasne i proste i używaj tych samych terminów / słów, których używa klient. Pomyśl, jakbyś nie miał pojęcia o programowaniu.

Dokumentacja jest często wykonywana w przypadkach użycia i innych formach prozy. Ponadto niezwykle przydatne mogą być diagramy UML i inne formy graficzne, które zapewniają przegląd na wyższym poziomie i są łatwe do zrozumienia w krótszym czasie niż czytanie stron i stron.

Wreszcie najlepszą dokumentacją imho są przypadki testowe, które wykonują reguły biznesowe. W ten sposób możesz zmienić kod i dowiedzieć się, że naruszasz regułę biznesową. W przeciwnym razie dokumentacja zawsze będzie zagrożona starzeniem się i przedawnieniem.

Prawdopodobnie najczęstszą formą są przypadki użycia . Możesz je uzupełnić makietami i opisami ekranów.

Książka, którą poleciłabym to „Pisanie spraw efektywnego użycia” Alistaira Cockburna. Opisuje, jak pisać przypadki użycia na różnych poziomach szczegółowości, jak uniknąć popadania w podejście oparte na „szablonach” i po prostu trzymać się dokumentowania niezbędnych i odpowiednich bitów.

Niezależnie od wybranej metody upewnij się, że można ją aktywnie utrzymywać. Powinny być żywymi dokumentami. Umieszczanie dokumentów w systemie kontroli wersji lub innym systemie zarządzania dokumentami, takim jak Sharepoint, może znacznie przyczynić się do ich utrzymania. Śledzenie reguł biznesowych za pomocą dokumentów tekstowych dołączanych do wiadomości e-mail jest okropnym sposobem radzenia sobie z tym problemem, ponieważ prowadzi do wielu wersji.

Zdecydowanie zalecam ścisłe oddzielenie reguł biznesowych od specyfikacji systemu, odwołując się tylko do reguł biznesowych od przypadku użycia i projektu interfejsu użytkownika. Moją ulubioną techniką jest: - Mieć listę zidentyfikowanych reguł biznesowych w arkuszu kalkulacyjnym. - W projekcie systemu, specyfikacji przypadku użycia, historii użytkownika lub cokolwiek innego, po prostu określ „Użytkownik wprowadza informacje określone w regule biznesowej BR012”, „System oblicza całkowitą kwotę zgodnie z regułą biznesową BR510”. Polecam ten artykuł http://www.allaboutrequirements.com/business-rules/

Spróbuj wygenerować diagram UML przy użyciu kodu Visual Studio i wtyczki Plant UML