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
Zarządzanie relacjami pomiędzy wymaganiami

Zarządzanie wymaganiami to ważny element procesu wytwórczego oprogramowania. Jednym z jego elementów budowanie i zarządzanie relacjami pomiędzy wymaganiami. Najczęściej spotykanym więcej

Architektura procesów biznesowych a modelowanie procesów biznesowych – poziomy modelowania

W poprzednim wpisie Modelowanie procesów biznesowych w procesie wytwórczym oprogramowania opisałem znaczenie modelowania procesów biznesowych. W moim odczuciu, modelowanie procesów biznesowych więcej

Wymagania są najważniejsze

Podczas mojej pracy zauważyłem, że spory problem stanowią wymagania. Trudnością nie jest ich spisanie. Trudnością jest ich wyartykułowanie. Pomijam turbulencje związane więcej

Plan zarządzania wymaganiami

Plan zarządzania wymaganiami to dokument, który opisuje zasady postępowania z wymaganiami. W moim odczuciu to jeden z najważniejszych dokumentów, gdyż więcej

Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *

Przewiń do góry