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

  • 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 nie tylko). 1. "Niezwykle […]
  • Przypadki użycia ułatwiają określenie celu i zakresu projektu Wiele mówi się o tym co dają przypadki użycia dla wymagań na system. Warto jest tez wiedzieć iż przypadki użycia pozwalają, zwłaszcza w projektach agile, na określenie celu  i zakresu […]
  • Agile a tworzenie przypadków użycia Właściwym podejściem do definiowania przypadków użycia dla tworzenia oprogramowania przy użyciu metody agile to zacząć od definicji zakresu. Definicje zakresu można opisać za pomocą […]
  • Prototyp a przypadek użycia Specyfikacja wymagań na system to trudny moment przede wszystkim dla osób, które muszą je wyspecyfikować. Nie zawsze wiadomo w jaki sposób narzędzia informatyki będą mogły pomóc. Często […]
  • Trzy korzyści z przypadków użycia Każdemu zalecam stosowanie przypadków użycia ? także a może przede wszystkim w projektach Agile. Poniżej zamieszczam trzy podstawowe zalety, które myślę, że przekonają do używania […]

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *