Przypadek użycia - Use case

Bardzo prosty przypadek użycia schemat z Wiki systemu.

W inżynierii oprogramowania i systemów wyrażenie przypadek użycia jest polisemem o dwóch znaczeniach :

Scenariusz użycia oprogramowania; często używane w liczbie mnogiej, aby zasugerować sytuacje, w których dany fragment oprogramowania może być przydatny.
Potencjalny scenariusz, w którym system otrzymuje żądanie zewnętrzne (takie jak dane wejściowe użytkownika) i odpowiada na nie.

W tym artykule omówiono ten drugi sens.

Przypadek użycia jest lista działań lub etapów zdarzeń typowo określających interakcje pomiędzy rolą (znany w Unified Modeling Language (UML) jako aktor ) oraz system do osiągnięcia celu. Aktorem może być człowiek lub inny system zewnętrzny. W inżynierii systemów przypadki użycia są wykorzystywane na wyższym poziomie niż w inżynierii oprogramowania , często reprezentując misje lub cele interesariuszy . Szczegółowe wymagania mogą być następnie ujęte w języku modelowania systemów (SysML) lub jako oświadczenia umowne.

Historia

W 1987 roku Ivar Jacobson przedstawił pierwszy artykuł na temat przypadków użycia na konferencji OOPSLA '87. Opisał, w jaki sposób technika ta została wykorzystana w firmie Ericsson do przechwytywania i określania wymagań systemu przy użyciu technik modelowania tekstowego, strukturalnego i wizualnego w celu prowadzenia analizy i projektowania obiektowego. Początkowo używał terminów scenariusze użycia i przypadek użycia – ten ostatni był bezpośrednim tłumaczeniem jego szwedzkiego terminu användningsfall – ale stwierdził, że żaden z tych terminów nie brzmiał naturalnie w języku angielskim i ostatecznie zdecydował się na przypadek użycia .

W 1992 roku był współautorem książki Object-Oriented Software Engineering – A Use Case Driven Approach , która położyła podwaliny pod metodę inżynierii systemów OOSE i pomogła w popularyzacji przypadków użycia do przechwytywania wymagań funkcjonalnych , zwłaszcza w tworzeniu oprogramowania . W 1994 roku opublikował książkę o przypadkach użycia i technikach obiektowych stosowanych w modelach biznesowych i reengineeringu procesów biznesowych .

W tym samym czasie Grady Booch i James Rumbaugh pracowali nad ujednoliceniem swoich metod analizy obiektowej i projektowania , odpowiednio metody Boocha i techniki modelowania obiektowego (OMT) . W 1995 dołączył do nich Ivar Jacobson i razem stworzyli Unified Modeling Language (UML) , który obejmuje modelowanie przypadków użycia. UML został ustandaryzowany przez Object Management Group (OMG) w 1997 roku. Jacobson, Booch i Rumbaugh pracowali również nad udoskonaleniem procesu tworzenia oprogramowania Objectory . Powstały zunifikowany proces został opublikowany w 1999 roku i promował podejście oparte na przypadku użycia.

Od tego czasu wielu autorów przyczyniło się do rozwoju tej techniki, w szczególności: Larry Constantine opracowany w 1995 r. w kontekście projektowania zorientowanego na użycie , tak zwanych „istotnych przypadków użycia”, które mają na celu opisanie intencji użytkownika, a nie sekwencji działań lub scenariusze, które mogą ograniczać lub zniekształcać projekt interfejsu użytkownika; Alistair Cockburn opublikował w 2000 roku zorientowaną na cel praktykę przypadków użycia opartą na narracjach tekstowych i specyfikacjach tabelarycznych; Kurt Bittner i Ian Spence opracowali w 2002 roku zaawansowane praktyki analizy wymagań funkcjonalnych z wykorzystaniem przypadków użycia; Dean Leffingwell i Don Widrig zaproponowali zastosowanie przypadków użycia do zarządzania zmianą i działań komunikacyjnych z interesariuszami; Gunnar Overgaard zaproponował w 2004 roku rozszerzenie zasad wzorców projektowych na przypadki użycia.

W 2011 r. Jacobson opublikował wraz z Ianem Spence i Kurtem Bittnerem ebook Use Case 2.0, aby dostosować technikę do kontekstu zwinnego, wzbogacając ją o „plasterki” przyrostowych przypadków użycia i promując jej użycie w całym cyklu rozwoju po przedstawieniu nowego podejścia na dorocznej konferencji IIBA .

Zasada ogólna

Przypadki użycia to technika przechwytywania, modelowania i określania wymagań systemu. Przypadek użycia odpowiada zestawowi zachowań, które system może wykonywać w interakcji ze swoimi aktorami, i które dają obserwowalny wynik, który przyczynia się do jego celów. Aktorzy reprezentują rolę, jaką w interakcji odgrywają użytkownicy lub inne systemy.

W analizie wymagań , przy ich identyfikacji, przypadek użycia jest nazwany zgodnie z konkretnym celem użytkownika, który reprezentuje dla swojego głównego aktora. Przypadek jest dodatkowo uszczegółowiony opisem tekstowym lub dodatkowymi modelami graficznymi, które wyjaśniają ogólną sekwencję działań i zdarzeń, a także warianty, takie jak warunki specjalne, wyjątki lub sytuacje błędów.

Według Software Engineering Body of Knowledge (SWEBOK) przypadki użycia należą do technik pozyskiwania wymagań opartych na scenariuszach , a także technik analizy opartej na modelu . Jednak przypadki użycia obsługują również zbieranie wymagań w oparciu o narrację, przyrostowe pozyskiwanie wymagań, dokumentację systemową i testy akceptacyjne.

Wariacje

Istnieją różne rodzaje przypadków użycia i odmiany tej techniki:

Przypadki użycia systemu określają wymagania tworzonego systemu. W szczegółowym opisie identyfikują nie tylko interakcje z aktorami, ale także podmioty, które są zaangażowane w przetwarzanie. Stanowią punkt wyjścia do dalszych analiz modeli i działań projektowych.
Biznesowe przypadki użycia koncentrują się na organizacji biznesowej, a nie na systemie oprogramowania. Służą do określania modeli biznesowych i wymagań dotyczących procesów biznesowych w kontekście inicjatyw przebudowy procesów biznesowych.
Niezbędne przypadki użycia, zwane również abstrakcyjnymi przypadkami użycia, opisują potencjalne intencje aktorów i sposób, w jaki system je rozwiązuje, bez definiowania jakiejkolwiek sekwencji lub opisu scenariusza. Ta praktyka została opracowana w celu wspierania projektowania zorientowanego na użytkownika i uniknięcia wywoływania uprzedzeń dotyczących interfejsu użytkownika na wczesnym etapie specyfikacji systemu.
Use Case 2.0 dostosowuje technikę do kontekstu metod programowania zwinnego. Ta technika wzbogaca praktykę zbierania wymagań o obsługę narracji użytkownika. Zapewnia również „wycinki” przypadków użycia, aby ułatwić przyrostowe pozyskiwanie wymagań i umożliwić przyrostową implementację.

Zakres

Zakres przypadku użycia można zdefiniować według tematu i celów:

Przedmiot identyfikuje system, podsystem lub komponent, który zapewni interakcje.
Cele mogą być ustrukturyzowane hierarchicznie, biorąc pod uwagę szczebel organizacyjny zainteresowany celem (np. firma, dział, użytkownik) oraz dekompozycję celu użytkownika na podcele. Dekompozycja celu odbywa się z punktu widzenia użytkowników i niezależnie od systemu, który różni się od tradycyjnej dekompozycji funkcjonalnej.

Stosowanie

Wiadomo, że przypadki użycia mają zastosowanie w następujących kontekstach:

Inżynieria Oprogramowania Obiektowego (OOSE) jako element napędowy;
Unified Modeling Language (UML), jako instrument modelowania behawioralnego;
Unified Software Development Process (UP) i jego poprzednik, IBM Rational Unified Process (RUP) ;
wstępna dokumentacja specyfikacji wymagań oprogramowania (SRS), jako alternatywna struktura wymagań funkcjonalnych;
wyprowadzenie projektu z wymagań przy użyciu podejścia jednostka-kontrola-granica ;
i zwinny rozwój .

Szablony

Istnieje wiele sposobów na napisanie przypadku użycia w tekście, od krótkiego przypadku użycia , swobodnego , zarysu , po pełne ubranie itp., korzystając z różnych szablonów. Pisanie przypadków użycia w szablonach opracowanych przez różnych dostawców lub ekspertów jest powszechną praktyką branżową w celu uzyskania wysokiej jakości funkcjonalnych wymagań systemowych.

Styl Cockburn

Szablon zdefiniowany przez Alistaira Cockburna w jego książce Writing Effective Use Cases jest jednym z najczęściej używanych stylów pisania przypadków użycia.

Zakresy projektowe

Cockburn sugeruje adnotację każdego przypadku użycia za pomocą symbolu, aby pokazać „Zakres projektu”, który może być czarną ramką (szczegóły wewnętrzne są ukryte) lub białą ramką (szczegóły wewnętrzne są pokazane). Dostępnych jest pięć symboli:

Zakres	Ikona
Organizacja (czarna skrzynka)	Wypełniony dom
Organizacja (biała skrzynka)	Niewypełniony dom
System (czarna skrzynka)	Wypełnione pudełko
System (biała skrzynka)	Niewypełnione pudełko
Składnik	Śruba lub śruba

Inni autorzy czasami nazywają przypadki użycia na poziomie organizacji „Biznesowymi przypadkami użycia”.

Poziomy celów

Hierarchia poziomów celów

Cockburn sugeruje opisanie każdego przypadku użycia symbolem, aby pokazać „Poziom celu”; preferowany poziom to „Cel użytkownika” (lub potocznie „poziom morza”).

Poziom celu	Ikona	Symbol
Bardzo wysokie podsumowanie	Chmura	++
Streszczenie	Latający latawiec	+
Cel użytkownika	Fale na morzu	!
Funkcja wewnętrzna	Ryba	-
Za nisko	Muszla z dna morskiego	--

Czasami w pisaniu tekstu nazwa przypadku użycia, po której następuje alternatywny symbol tekstowy (!, +, - itp.) jest bardziej zwięzłym i wygodnym sposobem oznaczania poziomów, np. złóż zamówienie! , logowanie- .

W pełni ubrany

Cockburn opisuje bardziej szczegółową strukturę przypadku użycia, ale pozwala na uproszczenie, gdy potrzeba mniej szczegółów. Jego w pełni ubrany szablon przypadku użycia zawiera następujące pola:

Tytuł: „wyrażenie celu z aktywnym czasownikiem, które określa cel głównego aktora”
Główny aktor
Cel w kontekście
Zakres
Poziom
Interesariusze i interesy
Warunek wstępny
Minimalne gwarancje
Gwarancje sukcesu
Cyngiel
Główny scenariusz sukcesu
Rozszerzenia
Lista odmian technologii i danych

Ponadto Cockburn sugeruje użycie dwóch urządzeń do wskazania charakteru każdego przypadku użycia: ikon zakresu projektu i poziomu celu.

Podejście Cockburna wpłynęło na innych autorów; na przykład Alexander i Beus-Dukic uogólniają szablon „W pełni ubranych przypadków użycia” Cockburna z oprogramowania na wszelkiego rodzaju systemy, z następującymi polami różniącymi się od Cockburn:

Scenariusze zmienności „(może odgałęzienie i może powrót do scenariusza głównego)”
Wyjątki „tj. zdarzenia wyjątków i ich scenariusze obsługi wyjątków”

Codzienny

Cockburn zdaje sobie sprawę, że projekty nie zawsze wymagają szczegółowych „w pełni ubranych” przypadków użycia. Opisuje przypadkowy przypadek użycia z polami:

Tytuł (cel)
Główny aktor
Zakres
Poziom
(Historia): treść przypadku użycia to po prostu akapit lub dwa tekstu, opisujące nieformalnie, co się dzieje.

Styl ptactwa

Martin Fowler stwierdza: „Nie ma standardowego sposobu napisania zawartości przypadku użycia, a różne formaty działają dobrze w różnych przypadkach”. Opisuje „powszechny styl do użycia” w następujący sposób:

Tytuł: „cel, który przypadek użycia stara się spełnić”
Główny scenariusz sukcesu: numerowana lista kroków
- Krok: „proste stwierdzenie interakcji między aktorem a systemem”
Rozszerzenia: oddzielnie numerowane listy, po jednej na rozszerzenie
- Rozszerzenie: „stan, który skutkuje różnymi interakcjami z… głównego scenariusza sukcesu”. Rozszerzenie z głównego kroku 3 ma numer 3a itd.

Styl Fowlera można również postrzegać jako uproszczoną wersję szablonu Cockburn.

Aktorzy

Przypadek użycia definiuje interakcje między aktorami zewnętrznymi a rozważanym systemem w celu osiągnięcia celu. Aktorzy muszą być w stanie podejmować decyzje, ale nie muszą być ludźmi: „Aktorem może być osoba, firma lub organizacja, program komputerowy lub system komputerowy — sprzęt, oprogramowanie lub jedno i drugie”. Aktorzy są zawsze interesariuszami , ale nie wszyscy interesariusze są aktorami, ponieważ „nigdy nie wchodzą w bezpośrednią interakcję z systemem, nawet jeśli mają prawo dbać o to, jak system się zachowuje”. Na przykład „właściciele systemu, rada dyrektorów firmy i organy regulacyjne, takie jak Internal Revenue Service i Department of Insurance” mogą być wszyscy udziałowcami, ale jest mało prawdopodobne, aby byli aktorami.

Podobnie osoba korzystająca z systemu może być reprezentowana jako różni aktorzy ze względu na odgrywanie różnych ról. Na przykład użytkownik „Joe” może odgrywać rolę klienta, gdy korzysta z bankomatu w celu wypłaty gotówki z własnego konta, lub odgrywać rolę kasjera bankowego, gdy korzysta z systemu w celu uzupełnienia szuflady na gotówkę w imieniu Bank.

Aktorzy często pracują w imieniu kogoś innego. Cockburn pisze, że „W dzisiejszych czasach piszę »przedstawiciel handlowy dla klienta« lub »urzędnik w dziale marketingu«, aby uchwycić, że użytkownik systemu działa w imieniu kogoś innego”. To mówi projektowi, że „interfejs użytkownika i poświadczenia bezpieczeństwa” powinny być zaprojektowane dla przedstawiciela handlowego i urzędnika, ale że klient i dział marketingu są rolami zainteresowanymi wynikami.

Interesariusz może odgrywać zarówno aktywną, jak i nieaktywną rolę: na przykład Konsument jest zarówno „nabywcą masowym” (niewchodzącym w interakcję z systemem), jak i Użytkownikiem (aktorem aktywnie wchodzącym w interakcję z zakupionym produktem). Z kolei Użytkownik jest zarówno „zwykłym operatorem” (aktorem korzystającym z systemu zgodnie z jego przeznaczeniem), jak i „beneficjentem funkcjonalnym” (interesariuszem korzystającym z korzystania z systemu). Na przykład, gdy użytkownik „Joe” wypłaca gotówkę ze swojego konta, obsługuje on bankomat i uzyskuje wynik we własnym imieniu.

Cockburn radzi szukać aktorów wśród interesariuszy systemu, głównych i wspierających (wtórnych) aktorów przypadku użycia, samego projektowanego systemu (SuD) i wreszcie wśród „aktorów wewnętrznych”, czyli komponentów systemu w trakcie projektowania.

Biznesowy przypadek użycia

W taki sam sposób, w jaki przypadek użycia opisuje serię zdarzeń i interakcji między użytkownikiem (lub innym typem aktora) a systemem, w celu uzyskania wyniku wartości (celu), biznesowy przypadek użycia opisuje bardziej ogólną interakcję między systemem biznesowym a użytkownikami/aktorami tego systemu w celu uzyskania wartościowych wyników biznesowych. Podstawowa różnica polega na tym, że system rozpatrywany w biznesowym modelu przypadków użycia może zawierać osoby oprócz systemów technologicznych. Ci „ludzie w systemie” nazywani są pracownikami biznesowymi. Na przykładzie restauracji trzeba podjąć decyzję, czy każdą osobę traktować jako aktora (czyli poza systemem) czy pracownika biznesowego (wewnątrz systemu). Jeśli kelner jest uważany za aktora, jak pokazano w poniższym przykładzie, system restauracji nie obejmuje kelnera, a model uwidacznia interakcję między kelnerem a restauracją. Alternatywą byłoby traktowanie kelnera jako części systemu restauracyjnego (pracownika biznesowego), podczas gdy klient był poza systemem (aktor).

Biznesowy diagram przypadków użycia przedstawia model kilku biznesowych przypadków użycia (cele), które reprezentują interakcje między restauracją (systemem biznesowym) a jej głównymi interesariuszami ( aktorami biznesowymi i pracownikami biznesowymi ).

Modelowanie wizualne

Przypadki użycia to nie tylko teksty, ale w razie potrzeby także diagramy. W Unified Modeling Language , relacje pomiędzy przypadkami użycia i aktorami są reprezentowane w diagram przypadków użycia pierwotnie w oparciu Ivar Jacobson „s Objectory notacji. SysML używa tej samej notacji na poziomie bloku systemowego.

Ponadto, inne schematy UML behawioralnych, takich jak diagramów aktywności , schematów sekwencji , schematach komunikacyjnych i schematów maszyna stanów może również być wykorzystywane do wizualizacji przypadków użycia odpowiednio. W szczególności diagram sekwencji systemu (SSD) to diagram sekwencji często używany do pokazania interakcji między aktorami zewnętrznymi a projektowanym systemem (SuD), zwykle w celu wizualizacji konkretnego scenariusza przypadku użycia.

Analiza przypadków użycia zwykle rozpoczyna się od narysowania diagramów przypadków użycia. W przypadku programowania zwinnego, model wymagań wielu diagramów UML przedstawiających przypadki użycia oraz kilka opisów tekstowych, notatek lub krótkich opisów przypadków użycia byłby bardzo lekki i wystarczyłby do małych lub łatwych projektów. Jako dobre uzupełnienie tekstów przypadków użycia, wizualne diagramy przedstawiające przypadki użycia są również skutecznymi narzędziami ułatwiającymi lepsze zrozumienie, komunikację i projektowanie złożonych wymagań behawioralnych systemu.

Przykłady

Poniżej znajduje się przykładowy przypadek użycia napisany za pomocą nieco zmodyfikowanej wersji szablonu w stylu Cockburn. Zwróć uwagę, że w podstawowym opisie przypadku użycia nie ma przycisków, kontrolek, formularzy ani żadnych innych elementów interfejsu użytkownika i operacji, w których na każdym etapie podstawowego przepływu lub rozszerzeń wyrażane są tylko cele użytkownika, cele podrzędne lub intencje. Ta praktyka sprawia, że specyfikacja wymagań jest jaśniejsza i maksymalizuje elastyczność projektu i implementacji.

Przypadek użycia : Edytuj artykuł

Główny aktor : członek (zarejestrowany użytkownik)

Zakres : system Wiki

Poziom : ! (Cel użytkownika lub poziom morza)

Krótki : (odpowiednik historii użytkownika lub epopei)

Członek edytuje dowolną część (cały artykuł lub tylko sekcję) czytanego artykułu. Podczas edycji możliwy jest podgląd i porównanie zmian.

Interesariusze

...

Warunki końcowe

Minimalne Gwarancje :

Gwarancje sukcesu :

Artykuł zostanie zapisany i wyświetlony zostanie zaktualizowany widok.
Rekord edycji artykułu jest tworzony przez system, dzięki czemu obserwatorzy artykułu mogą być później poinformowani o aktualizacji.

Warunki wstępne :

Artykuł z włączoną edycją jest prezentowany członkowi.

Wyzwalacze :

Członek wywołuje żądanie edycji (całego artykułu lub tylko jednej sekcji) artykułu.

Podstawowy przepływ :

System zapewnia nowy obszar/pole edytora wypełnione całą istotną treścią artykułu z informacyjnym podsumowaniem edycji, które członek może edytować. Jeśli członek chce tylko edytować sekcję artykułu, wyświetlana jest tylko oryginalna treść sekcji, a tytuł sekcji jest automatycznie wypełniany w podsumowaniu edycji.
Członek modyfikuje treść artykułu, dopóki nie zostanie usatysfakcjonowany.
Członek wypełnia podsumowanie edycji, informuje system, czy chce obejrzeć ten artykuł, i przesyła edycję.
System zapisuje artykuł, rejestruje zdarzenie edycji i kończy wszelkie niezbędne przetwarzanie końcowe.
System prezentuje zaktualizowany widok artykułu członkowi.

Rozszerzenia :

2-3.

a. Pokaż zapowiedzi:

Członek wybiera Pokaż podgląd, który przesyła zmodyfikowaną zawartość.
System ponownie uruchamia krok 1 z dodaniem renderowanej zaktualizowanej zawartości do podglądu i informuje członka, że jego/jej zmiany nie zostały jeszcze zapisane, po czym kontynuuje.

b. Pokaż zmiany:

Członek wybiera Pokaż zmiany, który przesyła zmodyfikowaną treść.
System ponownie uruchamia krok 1 z dodaniem wyników porównania różnic między bieżącymi zmianami wprowadzonymi przez członka a najnowszą zapisaną wersją artykułu, a następnie kontynuuje.

C. Anuluj edycję:

Członek wybiera Anuluj .
System odrzuca wszelkie zmiany wprowadzone przez członka, a następnie przechodzi do kroku 5.

4a. Koniec czasu:

...

Zalety

Od momentu powstania ruchu zwinnego, technika user story z Extreme Programming jest tak popularna, że wielu uważa, że jest to jedyne i najlepsze rozwiązanie dla zwinnych wymagań wszystkich projektów. Alistair Cockburn wymienia pięć powodów, dla których wciąż pisze przypadki użycia w programowaniu zwinnym .

Lista nazw celów zapewnia najkrótsze podsumowanie tego, co zaoferuje system (nawet niż historyjki użytkownika ). Zapewnia również szkielet planowania projektu, który można wykorzystać do budowania wstępnych priorytetów, szacunków, przydziału zespołu i harmonogramu.
Główny scenariusz sukcesu każdego przypadku użycia zapewnia wszystkim zaangażowanym porozumienie co do tego, co system będzie zasadniczo robił, a czego nie. Zapewnia kontekst dla każdego konkretnego wymagania dotyczącego elementu zamówienia (np. szczegółowe historyjki użytkownika), kontekst, który jest bardzo trudny do uzyskania nigdzie indziej.
Warunki rozszerzenia każdego przypadku użycia zapewniają ramy do badania wszystkich drobnych, drobiazgowych rzeczy, które w jakiś sposób zajmują 80% czasu i budżetu na rozwój. Zapewnia mechanizm wybiegania w przyszłość, dzięki czemu interesariusze mogą dostrzec problemy, na które uzyskanie odpowiedzi prawdopodobnie zajmie dużo czasu. Te problemy można i należy następnie przesunąć przed harmonogramem, aby odpowiedzi były gotowe, gdy zespół programistów zacznie nad nimi pracować.
Fragmenty scenariuszy rozszerzenia przypadków użycia dostarczają odpowiedzi na wiele szczegółowych, często podchwytliwych i ignorowanych pytań biznesowych: „Co mamy zrobić w tym przypadku?” Jest to struktura myślenia/dokumentacji, która pasuje do instrukcji if...then...else, która pomaga programistom przemyśleć problemy. Z wyjątkiem tego, że odbywa się to w czasie dochodzenia, a nie w czasie programowania.
Pełny zestaw przypadków użycia pokazuje, że badacze przemyśleli potrzeby każdego użytkownika, każdy cel, jaki mają w odniesieniu do systemu, i każdy zaangażowany wariant biznesowy.

Podsumowując, określanie wymagań systemowych w przypadkach użycia ma te oczywiste korzyści w porównaniu z tradycyjnymi lub innymi podejściami:

Skupiony na użytkowniku

Przypadki użycia stanowią potężne, zorientowane na użytkownika narzędzie w procesie specyfikacji wymagań oprogramowania. Modelowanie przypadków użycia zazwyczaj rozpoczyna się od identyfikacji kluczowych ról interesariuszy ( aktorów ) wchodzących w interakcję z systemem oraz ich celów lub zadań, które system musi spełnić (perspektywa zewnętrzna). Te cele użytkownika stają się następnie idealnymi kandydatami na nazwy lub tytuły przypadków użycia, które reprezentują pożądane funkcje funkcjonalne lub usługi dostarczane przez system. Takie podejście skoncentrowane na użytkowniku zapewnia, że rozwijane jest to, co ma rzeczywistą wartość biznesową i czego naprawdę chce użytkownik, a nie te trywialne funkcje spekulowane z perspektywy programisty lub systemu (wewnątrz).

Tworzenie przypadków użycia od lat jest ważnym i cennym narzędziem analitycznym w dziedzinie projektowania zorientowanego na użytkownika (UCD) .

Lepsza komunikacja

Przypadki użycia są często pisane w językach naturalnych za pomocą szablonów strukturalnych. Ta narracyjna forma tekstowa (czytelne historie wymagań), zrozumiała dla prawie wszystkich, uzupełniona wizualnymi diagramami UML, sprzyja lepszej i głębszej komunikacji między wszystkimi interesariuszami, w tym klientami, użytkownikami końcowymi, programistami, testerami i menedżerami. Lepsza komunikacja skutkuje wymaganiami jakościowymi, a tym samym dostarczaniem systemów jakości.

Wymagania jakościowe poprzez ustrukturyzowaną eksplorację

Jedną z najpotężniejszych cech przypadków użycia są formaty szablonów przypadków użycia , zwłaszcza głównego scenariusza sukcesu (podstawowy przepływ) i fragmentów scenariusza rozszerzenia (rozszerzenia, wyjątkowe i/lub alternatywne przepływy). Analizowanie przypadku użycia krok po kroku od warunków wstępnych do warunków końcowych, badanie i badanie każdego kroku działania przepływów przypadków użycia, od podstawowych do rozszerzeń, w celu zidentyfikowania tych trudnych, zwykle ukrytych i ignorowanych, pozornie trywialnych, ale realistycznie często kosztownych wymagań (jak wspomniał Cockburn powyżej) jest uporządkowanym i korzystnym sposobem systematycznego uzyskiwania jasnych, stabilnych i jakościowych wymagań.

Minimalizacja i optymalizacja kroków działania przypadku użycia w celu osiągnięcia celu użytkownika również przyczynia się do lepszego projektowania interakcji i doświadczenia użytkownika w systemie.

Ułatwienie testowania i dokumentacji użytkownika

Dzięki zawartości opartej na strukturze przepływu akcji lub zdarzeń, model dobrze napisanych przypadków użycia służy również jako doskonała podstawa i cenne wytyczne do projektowania przypadków testowych i instrukcji obsługi systemu lub produktu, co jest inwestycją wartą wysiłku z góry. Istnieją oczywiste powiązania między ścieżkami przepływu przypadku użycia i jego przypadków testowych. Wyprowadzanie funkcjonalnych przypadków testowych z przypadku użycia poprzez jego scenariusze (uruchamianie instancji przypadku użycia) jest proste.

Ograniczenia

Ograniczenia przypadków użycia obejmują:

Przypadki użycia nie są dobrze dostosowane do uchwycenia wymagań systemu, które nie są oparte na interakcji (takich jak algorytm lub wymagania matematyczne) lub wymagań niefunkcjonalnych (takich jak platforma, wydajność, czas lub aspekty krytyczne dla bezpieczeństwa). Są one lepiej określone deklaratywnie gdzie indziej.
Ponieważ nie ma w pełni standardowych definicji przypadków użycia, każdy projekt musi tworzyć własną interpretację.
Niektóre relacje przypadków użycia, takie jak extends , są niejednoznaczne w interpretacji i mogą być trudne do zrozumienia dla interesariuszy, jak wskazuje Cockburn (Problem #6)
Deweloperzy przypadków użycia często mają trudności z określeniem poziomu zależności interfejsu użytkownika (UI), który należy uwzględnić w przypadku użycia. Chociaż teoria przypadków użycia sugeruje, że interfejs użytkownika nie znajduje odzwierciedlenia w przypadkach użycia, wyabstrahowanie tego aspektu projektu może być niewygodne, ponieważ utrudnia to wizualizację przypadków użycia. W inżynierii oprogramowania ta trudność jest rozwiązywana przez zastosowanie identyfikowalności wymagań , na przykład za pomocą macierzy śledzenia . Innym podejściem do kojarzenia elementów interfejsu użytkownika z przypadkami użycia jest dołączenie projektu interfejsu użytkownika do każdego kroku w przypadku użycia. Nazywa się to scenorysem przypadków użycia.
Przypadki użycia mogą być nadmiernie podkreślane. Bertrand Meyer omawia takie kwestie, jak kierowanie projektowaniem systemu zbyt dosłownie na podstawie przypadków użycia oraz wykorzystanie przypadków użycia z wyłączeniem innych potencjalnie wartościowych technik analizy wymagań.
Przypadki użycia są punktem wyjścia do projektowania testów, ale ponieważ każdy test wymaga własnych kryteriów sukcesu, przypadki użycia mogą wymagać modyfikacji, aby zapewnić oddzielne warunki końcowe dla każdej ścieżki.
Chociaż przypadki użycia obejmują cele i konteksty, niezależnie od tego, czy te cele i motywacje stojące za celami (obawy interesariuszy i ich oceny, w tym brak interakcji) są w konflikcie, czy też negatywnie/pozytywnie wpływają na inne cele systemu, są przedmiotem technik modelowania wymagań zorientowanych na cel (takich jak BMM , I * , KAOS i ArchiMate ARMOUR).

Nieporozumienia

Typowe nieporozumienia dotyczące przypadków użycia to:

Historyjki użytkownika są zwinne; przypadki użycia nie są.

Agile i Scrum są neutralne w zakresie technik wymagań. Jak stwierdza Scrum Primer,

Pozycje Backlogu Produktu są wyrażane w sposób jasny i zrównoważony. Wbrew powszechnemu nieporozumieniu Backlog Produktu nie zawiera „historii użytkowników”; zawiera po prostu przedmioty. Pozycje te mogą być wyrażone jako historyjki użytkownika, przypadki użycia lub dowolne inne podejście do wymagań, które grupa uzna za przydatne. Jednak niezależnie od podejścia, większość produktów powinna koncentrować się na dostarczaniu klientom wartości.

Techniki przypadków użycia ewoluowały, aby uwzględnić podejścia Agile poprzez wykorzystanie wycinków przypadków użycia do przyrostowego wzbogacania przypadku użycia.

Przypadki użycia to głównie diagramy.

Craig Larman podkreśla, że „przypadki użycia to nie diagramy, to tekst”.

Przypadki użycia zawierają zbyt dużo treści związanych z interfejsem użytkownika.

Jak niektórzy to ujęli,

Przypadki użycia często zawierają pewien poziom szczegółowości (tj. nazewnictwa etykiet i przycisków), co sprawia, że nie nadaje się on dobrze do uchwycenia wymagań nowego systemu od zera.

Nowicjusze nieporozumienia. Każdy krok dobrze napisanego przypadku użycia powinien przedstawiać cele lub intencje aktora (istotę wymagań funkcjonalnych) i normalnie nie powinien zawierać żadnych szczegółów interfejsu użytkownika, np. Nazewnictwa etykiet i przycisków, operacji UI itp., co jest złym ćwiczyć i niepotrzebnie komplikować pisanie przypadków użycia i ograniczać jego implementację.

Jeśli chodzi o rejestrowanie wymagań dla nowego systemu od podstaw, diagramy przypadków użycia oraz opisy przypadków użycia są często używane jako przydatne i cenne narzędzia, co najmniej tak lekkie jak historyjki użytkowników .

Pisanie przypadków użycia dla dużych systemów jest żmudne i strata czasu.

Jak niektórzy to ujęli,

Format przypadku użycia utrudnia opisanie dużego systemu (np. systemu CRM) na mniej niż kilkaset stron. Jest to czasochłonne i będziesz spędzać czas na niepotrzebnej przeróbce.

Poświęcanie dużej ilości czasu na pisanie żmudnych przypadków użycia, które nie dodają żadnej wartości lub mają niewielką wartość i powodują wiele przeróbek, jest nieprzyjemnym zapachem wskazującym, że autorzy nie są dobrze wykwalifikowani i mają niewielką wiedzę na temat pisania wysokiej jakości przypadków użycia, zarówno skutecznie, jak i skutecznie. Przypadki użycia powinny być tworzone w sposób iteracyjny, przyrostowy i ewolucyjny ( zwinny ). Stosowanie szablonów przypadków użycia nie oznacza, że wszystkie pola szablonu przypadków użycia powinny być wykorzystane i wypełnione kompleksowo z góry lub na specjalnym dedykowanym etapie, tj. fazie wymagań w tradycyjnym modelu rozwoju kaskadowego .

W rzeczywistości, formaty przypadków użycia sformułowane przez te popularne style szablonów , np. RUP i Cockburn's (przyjęte również metodą OUM ) itp., okazały się w praktyce cennymi i pomocnymi narzędziami do przechwytywania, analizowania i dokumentowania złożonych wymagań duże systemy. Jakość dobrej dokumentacji przypadków użycia ( model ) nie powinna być oceniana w dużej mierze lub tylko na podstawie jej rozmiaru. Możliwe jest również, że jakościowy i kompleksowy model przypadków użycia dużego systemu może w końcu ewoluować do setek stron, głównie z powodu nieodłącznej złożoności problemu , a nie z powodu słabych umiejętności pisarskich jego autorów.

Narzędzia

Edytory tekstu i/lub edytory tekstu z obsługą szablonów są często używane do pisania przypadków użycia. W przypadku dużych i złożonych wymagań systemowych pomocne są dedykowane narzędzia do przypadków użycia.

Niektóre z dobrze znanych narzędzi do przypadków użycia obejmują:

Sprawa zakończona
Architekt korporacyjny
MagicDraw
RequisitePro firmy Rational Software — jedno z wczesnych, dobrze znanych narzędzi do zarządzania przypadkami użycia i wymaganiami w latach 90. XX wieku.
Modelarz pomysłów na oprogramowanie
Oprogramowanie Wiki — dobre narzędzia dla zespołów do wspólnego tworzenia i zarządzania przypadkami użycia.

Większość narzędzi UML obsługuje zarówno pisanie tekstu, jak i wizualne modelowanie przypadków użycia.

Zobacz też

Bibliografia

Dalsza lektura

Alexander, Ian i Beus-Dukic, Ljerka. Wykrywanie wymagań: jak określać produkty i usługi . Wiley, 2009.
Alexander Ian i Maiden Neil. Scenariusze, historie, przypadki użycia . Wiley 2004.
Zbroja, Frank i Granville Miller. Zaawansowane modelowanie przypadków użycia: systemy oprogramowania . Addison-Wesley, 2000.
Kurt Bittner, Ian Spence, Use Case Modeling , Addison-Wesley Professional, 20 sierpnia 2002.
Cockburn, Alistair. Pisanie skutecznych przypadków użycia. Addison-Wesley, 2001.
Larry Constantine, Lucy Lockwood, Software for Use: A Practical Guide to the Essential Models and Methods of Usage-Centered Design , Addison-Wesley, 1999.
Denney, Richard. Odniesienie sukcesu dzięki przypadkom użycia: inteligentna praca w celu zapewnienia jakości . Addison-Wesley, 2005.
Fowler, Martin. Destylowany UML (wydanie trzecie) . Addison-Wesley, 2004.
Jacobson Ivar, Christerson M., Jonsson P., Övergaard G., Obiektowa inżynieria oprogramowania – podejście oparte na przypadku użycia , Addison-Wesley, 1992.
Jacobson Ivar, Spence I., Bittner K. Przypadek użycia 2.0: Przewodnik po sukcesach z przypadkami użycia , IJI SA, 2011.
Dean Leffingwell, Don Widrig, Zarządzanie wymaganiami dotyczącymi oprogramowania: podejście do przypadków użycia , Addison-Wesley Professional. 7 grudnia 2012 r.
Kulak, Daryl i Eamonn Guiney. Przypadki użycia: wymagania w kontekście. Addison-Wesley, 2012.
Meyera, Bertranda. Budowa oprogramowania zorientowanego obiektowo. (wydanie drugie). Sala Prezydencka, 2000.
Schneider, Geri i Winters, Jason P. Stosowanie przypadków użycia Wydanie drugie: praktyczny przewodnik . Addison-Wesley, 2001.
Wazlawick, Raul S. Analiza i projektowanie obiektowe dla systemów informatycznych: modelowanie za pomocą UML, OCL i IFML . Morgana Kaufmanna, 2014.

Linki zewnętrzne

Kolumna przypadków użycia i szablon podstawowego przypadku użycia autorstwa Alistaira Cockburn
Przypadki użycia na stronie Usability.gov GSA
Zastosowanie przypadków użycia do analizy interesariuszy „Projekt Icarus” w Academia.edu
Wyszukaj „przypadek użycia” w IBM Developer

Languages

In other projects