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
- 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.
- 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.
- 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.
- 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.
Reklama
