Dokumentacja wymagań w oparciu o przypadki użycia

Przypadki użycia służą do dokumentacji funkcjonalności systemu i bazują na dwóch wspólnie wykorzystywanych koncepcjach:

  • Diagramach przypadków użycia
  • Specyfikacjach przypadków użycia

Obiekty:

Przypadek użycia (PU): Przypadek użycia reprezentuję funkcję systemu, która reprezentuję osiągnięcie jakiegoś celu w systemie. Nazwa przypadku użycia powinna odzwierciedlać cel osiągnięty przez realizację PU.

Aktor: Aktorzy znajdują się poza granicami systemu i reprezentują ludzi i inne systemy, które wchodzą w interakcję z modelowanym systemem.

Granica systemu: Granica systemu służy do oddzielenia PU, które są częścią modelowanego systemu, od jego otoczenia (aktorów, innych systemów). Opcjonalnie nazwa granicy może zawierać nazwę modelowanego systemu.

Relacje:

Relacja pomiędzy aktorem a PU (użycia): Relacja modeluje wystąpienie interakcji pomiędzy PU a aktorami, którzy komunikują się z systemem w celu realizacji PU.

Relacja rozszerzenia (extend): Relacja rozszerzenie modeluje sytuację, w której scenariusz realizacji źródłowego przypadku użycia (PU A) może rozszerzyć scenariusz realizacji docelowego przypadku użycia (PU B). Rozszerzenie to jest wywoływane po spełnieniu warunków zawartych w scenariuszu realizacji docelowego przypadku użycia.

Relacja włączenia (include): Relacja włączenia modeluje sytuację, w której scenariusz docelowego przypadku użycia (PU B) jest włączany do scenariusza realizacji źródłowego przypadku użycia (PU A).

Przykład diagramu przypadków użycia

image

Diagramy przypadków prezentują funkcjonalność systemu z perspektywy jego otoczenia – aktorów, oraz powiązania pomiędzy tymi funkcjonalnościami. Diagramy te, poza nazwą określającą cel PU, nie dokumentują natomiast żadnych innych informacji na temat poszczególnych PU, jak na przykład przebiegu interakcji pomiędzy aktorami a przypadkami użycia, czy też warunków wymaganych do realizacji danego przypadku użycia.

Zadaniem specyfikacji przypadku użycia jest kompleksowe udokumentowanie poszczególnych przypadków użycia. Do specyfikacji przypadku użycia należy skorzystać z przyjętego w projekcie szablonu, który zapewni, że żadne wymagane informacje nie zostaną pominięte.

Najczęściej szablony specyfikacji przypadków użycia wykorzystują tabele, w których poszczególne wiersze reprezentują sekcję dotyczącą określonego typu informacji na temat opisywanego PU.

Specyfikacja przypadku użycia powinna zawierać następujące sekcje:

  • Oznaczenie: Unikalny identyfikator przypadku użycia
  • Nazwa: Unikalna nazwa PU określająca jego cel
  • Autorzy: Nazwy autorów zaangażowanych w opis PU
  • Priorytet: Nadana ranga dla PU
  • Krytyczność: Określa jak wiele szkody może wyrządzić niepowodzenia realizacji PU
  • Źródło: Oznaczenie źródła, z którego powodzi PU (np. interesariusz, dokument, system)
  • Osoba odpowiedzialna: Interesariusz, który jest odpowiedzialny za dany PU
  • Opis: Krótki opis PU
  • Wyzwalacze: Nazwa zdarzenia, która powoduje uruchomienie PU
  • Aktorzy: Lista aktorów, którzy wchodzą w interakcję z danym PU
  • Warunki wstępne: Lista warunków, które muszą być spełnione aby PU mógł być uruchomiony
  • Warunki końcowe: Lista stanów systemu jakie muszą być osiągnięte po poprawnym wykonaniu scenariusza głównego PU
  • Rezultat: Opis rezultatów jakie są osiągane podczas realizacji PU
  • Główny scenariusz: Opis scenariusza głównego określającego ścieżkę wykonania PU
  • Scenariusze alternatywne: Opis scenariuszy alternatywnych określających oraz zdarzeń powodujących przejście do realizacji scenariusza alternatywnego
  • Scenariusze wyjątków: Opis scenariuszy dla wyjątków oraz zdarzeń powodujących przejście do realizacji scenariusza wyjątku
  • Wymagania jakościowe: Odsyłacze do wymagań jakościowych, które dotyczą opisywanego PU

 

Przykład opisu przypadku użycia zamieszczam poniżej:

image

image

image

 

Do specyfikacji przypadków użycia używam oczywiście Enterprise Architect’a.

Tekst zainspirowany książką: Klaus Pohl, Chris Rupp „Requirements engineering fundamentals : a study guide for the Certified Professional for Requirements Engineering exam : foundation level”, IREB compliant Wydawnictwo: Rocky Nook Inc, 2011

Podobne wpisy
Jesienny The Rational Edge ezine

Właśnie ukazał się jesienny The Rational Edge ezine (http://ibm.com/developerworks/ecma/campaign/er.jsp?id=376126&imid=68950291&end). Dla fanów RSA jest bardzo ciekawy artykuł, w którym Steve Arnold więcej

Podstawowe dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to podstawowe dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Średniozaawansowane dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to średniozaawansowane dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Zaawansowane dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to zaawansowane dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Reklama
MODESTO - licencje Enterprise Architect

2 komentarze dla “Dokumentacja wymagań w oparciu o przypadki użycia”

  1. „Scenariusze alternatywne: Opis scenariuszy alternatywnych określających oraz zdarzeń powodujących przejście do realizacji scenariusza alternatywnego”
    Brakuje mi w tej definicji informacji, co jest scenariuszem alternatywnym. W podanym przykładzie scenariusz alternatywny wygląda jak scenariusz główny. Podane czynności dzieją się w momencie uruchomienia głównej ścieżki- są jej częścią. Spodziewałabym się, że scenariusz alternatywny będzie wykorzystany, jeśli coś pójdzie nie tak w scenariuszu głównym.

    1. Scenariusza alternatywny to działanie, które doprowadza nas do celu, ale inną drogą, z dodatkowymi opcjami. Jeśli coś „idzie nie tak” to mamy wyjątek.

Dodawanie komentarzy zostało zablokowane.

Scroll to Top