Jak opisywać przypadki użycia?

Opisując przypadki użycia stosuję kilka poziomów ich opisu. Najpierw identyfikuję aktorów i przypadki użycia potem dla każdego przypadku użycia opisuje punkty końcowe i początkowe by pomiędzy tymi punktami umieścić scenariusze.  Jakiś czas temu wynotowałem z jakiejś publikacji taki oto zakres działania

  1. Aktorzy i cele. Wypisz aktorów i ich cele, których realizację system będzie wspomagał. Sprawdź tę listę pod względem dokładności i kompletności. Określ priorytety i przydziel cele do zespołów i wersji. Masz teraz wymagania funkcjonalne na pierwszym poziomie precyzji.
  2. Skróty przypadków użycia albo główne scenariusze powodzenia. Naszkicuj główne scenariusze powodzenia przypadków użycia, które postanowiłeś zbadać. Sprawdź je w tej szkicowej postaci, aby upewnić się, że system naprawdę odpowiada interesom użytkowników, którzy są dla ciebie ważni. To jest drugi poziom precyzji wymagań funkcjonalnych. Jest go dość łatwo napisać na brudno w odróżnieniu od pozostałych dwóch poziomów.
  3. Sytuacje awaryjne. Ukończ główny scenariusz powodzenia i przeprowadź burzę mózgów na temat wszystkich awarii, które mogą się zdarzyć. Napisz na brudno całą tę listę, zanim zajmiesz się tym, jak system ma te awarie obsługiwać. Ustalenie obsługi awarii wymaga znacznie więcej energii niż pisanie wykazu awarii. Ludzie, którzy zaczynają od pisania obsługi awarii, często natychmiast tracą siły jeszcze przed określeniem wszystkich sytuacji wyjątkowych.
  4. Obsługa awarii. Napisz, jak system powinien reagować na każdą awarię. Często jest to praca zawiła, męcząca i zaskakująca. Jest zaskakująca, ponieważ często w czasie pisania wyłaniają się pytania o jakąś niejasną regułę gospodarczą. Rozważanie obsługi awarii może też niespodziewanie doprowadzić do odkrycia nowego aktora lub nowego celu, który powinien być wspierany.

Na koniec dodam iż każdy z tych punktów warto jest zaczynać opisywać, gdy wcześniejsze prace są zatwierdzone.

Podobne wpisy
Podsumowanie 2016 i plany na 2017

Kończy się rok 2016. Dla mnie dość intensywny i jednocześnie pełen refleksji. Refleksja dotyka kilku tematów. Zastanawiam się dokąd zmierza więcej

Dokumentacja przypadków użycia w administracji publicznej

Myślę, że czasem warto się pochwalić drobnymi osiągnięciami. W 2013 roku miałem okazję współpracować z Ministerstwem Sprawiedliwości. Brałem udział w więcej

TORMIGO – oficjalnie na stronach Sparx Systems

Tormigo został oficjalnie zarejestrowany na stronach Sparx Systems jako program wspierający Enterprise Architect’a http://sparxsystems.com.au/products/3rdparty.html#tormigo Tormigo jest konkurencją dla RaQuest w więcej

KILKA PORAD DLA MODELOWANIA WYMAGAŃ METODĄ AGILE

Chciałbym podzielić się kilkoma istotnymi zasadami, które, mam nadzieję, że pomogą ustanowić efektywne podstawy dla modelowania wymogów metodą agile (i więcej

Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Przewiń do góry