Czym jest przypadek użycia? Jak go napisać, przykłady i szablon

Projektowanie produktu to więcej niż tylko wymienienie funkcji i celów. Zanim pojawił się pierwszy smartfon, jak można opisać sposoby, w jakie użytkownicy wchodzili z nim w interakcję? Nazwanie smartfona telefonem komórkowym, na którym można przeglądać internet, to dobry początek, ale to nie oddaje złożoności wszystkich systemów. Aby zmapować sposoby, w jakie użytkownicy wchodzą w interakcję z systemem, narzędziem lub produktem, trzeba przypadku użycia.

Przypadki użycia to opisy sposobów, w jakie użytkownicy wchodzą w interakcje z systemami, aby wykonać zadania lub osiągnąć cele. Mapowanie tych interakcji może poprawić wczesne planowanie oraz zapewnić płynny przebieg cyklu rozwoju. Aby pomóc Ci włączyć je do planowania projektu, zdefiniujemy przypadek użycia, wyjaśnimy, jak go napisać i udostępnimy przykłady.

Czym jest przypadek użycia

Przypadek użycia opisuje, jak użytkownicy wchodzą w interakcję z produktem lub systemem. Obejmuje to przepływ danych wprowadzanych przez użytkownika, określając pomyślne i nieudane ścieżki do osiągnięcia celów. To pozwala zespołom produktowym lepiej zrozumieć, co robi system, jak działa oraz dlaczego pojawiają się błędy. Możesz napisać własny lub stworzyć diagram modelu przypadku użycia dla osób myślących wizualnie.

Przypadki użycia różnią się złożonością w zależności od odbiorców lub systemu. Ale ogólnie rzecz biorąc, przypadek użycia powinien wskazać kilka kluczowych komponentów. Do najważniejszych z nich należą:

• Aktor: coś, co wykazuje zachowanie wchodzące w interakcję z systemem, jak pojedynczy użytkownik, zespół lub inny element oprogramowania
• System: produkt lub usługa o określonej funkcjonalności
• Cel: cel, który użytkownicy osiągają korzystając z funkcji systemu.

Aktorzy, systemy i cele stanowią podstawę przypadku użycia. Gdy zaczynasz śledzić interakcje z systemem, pojawia się kilka nowych elementów:

• Interesariusz(e): osoby mające udział lub interes w działaniu systemu.
• Główny aktor: osoba, która rozpoczyna działanie systemu, aby osiągnąć cel.
• Warunki wstępne: czynniki podstawowe wymagane do przypadku użycia
• Wyzwalacze: zdarzenia, które rozpoczynają przypadek użycia
• Podstawowe przepływy: przypadki użycia, w których systemy działają zgodnie z przeznaczeniem, aby osiągnąć cel.
• Alternatywne przepływy: różne wyniki w zależności od tego, kiedy i jak system zboczy z kursu

Rodzaje przypadków użycia

Przypadki użycia występują w dwóch formach: biznesowej oraz systemowej. Przypadek użycia to szczegółowe spojrzenie na to, jak użytkownicy wchodzą w interakcję z każdą częścią systemu. Podkreśla, jak unikalne dane wejściowe i kontekst powoduje, że system osiąga różne wyniki. Ten poziom szczegółowości pokazuje, jak poszczególne funkcje systemu działają w dowolnym scenariuszu.

Przypadki użycia biznesowego przedstawiają bardziej ogólny obraz tego, jak użytkownik może wchodzić w interakcje z Twoją firmą, aby osiągnąć swoje cele. Zamiast skupiać się na szczegółach technicznych, jest to opis przyczynowo-skutkowy różnych danych wejściowych. Na przykład, jeśli prowadzisz platformę do debugowania kodu, przypadek użycia biznesowego wyjaśnia, jak użytkownicy wprowadzają swój kod i otrzymują powiadomienia o błędach.

Niektóre zespoły wolą tworzyć biznesowy przypadek użycia, aby przedstawić procesy systemu przed jego opracowaniem. Gdy programiści rozpoczną pracę, menedżer obrysuje bardziej techniczne przypadki użycia.

Scenariusz użycia a przypadek użycia

Przypadki użycia pokazują wszystkie sposoby, w jakie działa system, aby osiągnąć cele, ale scenariusz przedstawia tylko jeden przykład. W scenariuszu system może odnieść sukces lub ponieść porażkę w osiąganiu celów użytkownika. Mówiąc prościej, wiele scenariuszy użycia tworzy jeden przypadek użycia.

Przypadek użycia a historia użytkownika

Przypadki użycia pokazują, jak użytkownicy wchodzą pracują z systemem, a historie użytkowników opisują funkcje z ich perspektywy. W rezultacie historie użytkowników są znacznie krótsze niż przypadki użycia. Zazwyczaj składają się z krótkich opisów, które zespoły wykorzystują jako punkt wyjścia w rozwoju. Co więcej, przypadki użycia mogą wspierać różne zespoły w organizacji, a historie użytkowników pomagają zespołom produktowym w budowaniu narzędzia.

Przypadek użycia a przypadek testowy

Podczas gdy przypadek użycia opisuje, jak użytkownicy oraz funkcje systemu współpracują, aby osiągnąć cele, przypadki testowe weryfikują, czy pojedyncza funkcja działa poprawnie. W przeciwieństwie do przypadków użycia, przypadki testowe analizują funkcje w izolacji.

Na przykład, przypadek testowy może obejmować weryfikację funkcji logowania na platformie e-mail, zapewniając użytkownikom możliwość logowania się w dowolnej przeglądarce o dowolnej porze po założeniu konta.

Jak napisać przypadek użycia

Napisanie przypadku użycia wydaje się skomplikowane, ale wymaga jedynie zrozumienia Twojego systemu i jego użytkowników. Możesz napisać przypadek użycia, postępując zgodnie z tymi sześcioma krokami:

1. Opisz swój system

Zacznij od opisania swojego systemu, produktu lub usługi, którą Ty i Twój zespół zbudujecie. Skoncentruj swój opis na tym, co Twój system robi dla użytkowników. W przypadku zastosowania biznesowego możesz zachować ogólne tło i wyjaśnić, co ono osiąga. Dla przypadku użycia systemu, podaj szczegółowy opis działania produktu.

Zdefiniuj swój system, zadając pytania:

• Jaką formę to przybiera: produkt, usługa czy oprogramowanie?
• Jakie funkcje oferuje?
• Jakie cele możesz zrealizować dzięki niemu?
• Jak to spełnia te cele?
• Czego możesz się dowiedzieć o systemie z innych dokumentów, takich jak dokumenty projektowe?

2. Zidentyfikuj uczestników

Aktorzy zazwyczaj odnoszą się do użytkowników i klientów, ale mogą dotyczyć każdej zewnętrznej siły, która wchodzi w interakcję z systemem. Twój aktor potrzebuje dobrze zdefiniowanych zachowań, które wyjaśniają, jak i dlaczego aktorzy korzystają z systemu.

Zidentyfikuj użytkowników, pytając:

• Czy to są osoby, zespoły, sprzęt czy też inny system?
• Czy główni i drugorzędni aktorzy zachowują się w ten sam sposób?
• Czy interesariusze przejmą rolę aktorów w Twoim przypadku użycia?

3. Określ cele swoich aktorów

Przypadki użycia podkreślają rezultaty, których oczekują użytkownicy. Pamiętaj, aby skupić się na potrzebach użytkowników, a nie na możliwościach systemu, aby zrozumieć, dlaczego użytkownicy przychodzą do Twojego systemu. W niektórych przypadkach klienci chcą używać systemów do więcej niż jednego celu. Wymienienie każdego z tych celów utworzy bardziej solidny przypadek użycia.

4. Utwórz scenariusz

W przypadku użycia, scenariusze to sekwencja działań, które klienci podejmują podczas korzystania z systemu, oraz przepływ efektów wynikających z tej interakcji. Twoje podstawowe przepływy obejmują scenariusze, w których system działa zgodnie z zamierzeniami. Użytkownik podchodzi do systemu, wprowadza właściwe dane, a system pomaga mu osiągnąć żądane cele.

Zacznij od udanych, podstawowych przepływów, aby stworzyć punkt odniesienia. Możesz użyć technik mapowania procesów, aby zidentyfikować potencjalne problemy w kolejnych przepływach.

5. Rozważ alternatywne przepływy

Po napisaniu scenariusza, stwórz alternatywne przepływy, które prowadzą do różnych rezultatów. Zazwyczaj alternatywne przepływy wiążą się z niewłaściwym użyciem systemu, który uniemożliwia użytkownikom osiągnięcie celów. Można jednak również zauważyć wewnętrzne błędy, które powodują awarię systemu lub niezamierzone sposoby, w jakie systemy mogą osiągać cele.

Alternatywne przepływy pokazują, jak różni aktorzy używają systemu, odnoszą sukces lub ponoszą porażkę. Zapewniają bardziej zniuansowany widok wszystkiego, co Twój system może zrobić, aby pomóc Ci w rozwiązywaniu problemów.

6. Powtórz kroki 2–5, aby skompilować przypadek użycia

Przy wystarczającej różnorodności aktorów, celów i scenariuszy możesz pokazać, jak działa Twój system. Kompilacja tych przepływów daje Ci przypadek użycia, który może usprawnić rozwój i informować inne dokumenty, takie jak raporty o stanie projektu.

W prostych systemach można zmienić kilka elementów, aby zobaczyć wszystkie możliwe wyniki. Jednak w złożonych systemach może być zbyt wiele elementów, aby dostrzec każdy rezultat. W takich przypadkach możesz skupić się na testowaniu najczęstszych interakcji. Możesz także zaprojektować systemy, które uniemożliwią używanie nieprzetestowanych komponentów.

Wypróbuj szablon przypadku użycia Figma

Chcesz rozpocząć burzę mózgów nad przypadkami użycia? Wypróbuj szablon przypadku użycia Figmy, aby rozłożyć systemy na części i znaleźć nowe rozwiązania.

Przykład zastosowania

Załóżmy, że jesteś menedżerem produktu, który rozwija aplikację bankowości mobilnej dla swojej firmy. Platforma musi usprawnić rejestrację użytkowników i konfigurację konta. Oto przykładowy format przypadku użycia oparty na tej aplikacji:

Informacje w tle:

• System: aplikacja mobilna do bankowości
• Główny aktor: klient, który chce otworzyć konto
• Aktor drugorzędny: underwriter i zautomatyzowane narzędzia obliczające stopy procentowe oraz maksymalne salda kapitałowe
• Cele: oszczędzaj czas przy rejestracji konta i wdrażaniu
• Interesariusze: dyrektor generalny i wiceprezes ds. produktów
• Warunki wstępne: użytkownicy pobierają aplikację i spełniają wymagania dotyczące konta.
• Wyzwalacze: użytkownik wybiera utworzenie nowego konta w aplikacji

Scenariusze:

• Podstawowy przepływ: użytkownicy pobierają Twoją aplikację i wybierają utworzenie nowego konta. Aplikacja gromadzi informacje o innych kontach użytkownika i punktach kredytowych. Stamtąd automatycznie udostępnia konta, do których się kwalifikujesz oraz ich oprocentowanie. Użytkownik znajduje konto, które odpowiada jego potrzebom i rejestruje się.
• Alternatywny przepływ 1: użytkownicy wprowadzają swoje dane finansowe, a aplikacja szybko generuje opcje kont. Jednak każde konto domyślnie ustawia się na najwyższe oprocentowanie, na jakie pozwala sytuacja finansowa klienta. Użytkownicy porzucają aplikację, aby znaleźć niższą cenę.
• Alternatywny przepływ 2: proces wdrażania działa zgodnie z założeniami, ale aplikacja napotyka problemy zgodności, takie jak wymagania KYC (Know Your Customer). Chociaż aplikacja może oferować opcje konta, dodatkowe kroki zgodności spowalniają proces.
• Alternatywny przepływ 3: ponieważ aplikacja uwzględnia jedynie inne konta i oceny kredytowe, nie jest w stanie zaoferować pełnego zakresu opcji kont. Na przykład, może oferować jedynie karty i linie kredytowe. Klienci szukający kredytów hipotecznych muszą udać się gdzie indziej.

Zalety przypadków użycia

Na etapie planowania przypadki użycia definiują zakres projektu, wymagania i strategię rozwoju. Zespoły mogą również omawiać najlepsze rezultaty dla użytkowników oraz projektować ścieżkę do ich osiągnięcia. Dzięki alternatywnym przepływom można także przewidywać zagrożenia, zanim wpłyną one negatywnie na doświadczenie użytkownika. Jeśli to nie jest wystarczający powód, aby to napisać, oto kilka innych korzyści wynikających z przypadków użycia:

• Wyjaśnia wartość: przypadki użycia wyjaśniają funkcje systemu w prostych słowach. Kiedy więc przedstawiasz swoje plany interesariuszom, przypadek użycia sprawia, że Twój system jest łatwiejszy do zrozumienia.
• Przewidywanie kosztów: przypadek użycia przedstawia złożoność systemu. Większa złożoność może pojawić się wraz z dodatkowymi funkcjami albo zabezpieczeniami. Dowiadując się, jak złożony jest Twój system, możesz oszacować koszty rozwoju.
• Usprawnia planowanie: bez przypadku użycia projektanci i programiści skupiają się na tym, co system robi, a nie jak to robi. Jednak przypadki użycia pomagają zespołom rozważyć wszystkie sposoby wdrażania funkcji i zabezpieczeń.
• Udostępnia alternatywne zastosowania: nie wszystkie alternatywne przepływy w systemie prowadzą do niepowodzeń. Mapowanie różnych scenariuszy pozwala odkryć nowe rozwiązania dla starych problemów lub poszerzyć zrozumienie tego, co system może osiągnąć.

Udoskonalaj przypadki użycia z FigJam

Przypadki użycia wykraczają poza opis tego, co potrafi Twój produkt. Zapewniają interesariuszom i zespołom jasny obraz interakcji użytkowników oraz pomyślnych rezultatów. Niezależnie od tego, czy dodajesz nową funkcję, tworzysz szybki prototyp, czy zmieniasz projekt systemu, planowanie powinno rozpocząć się od napisania przypadku użycia.

Im więcej wniosków na temat aktorów, interakcji i wyników, tym lepiej — dlatego ważne jest, aby współpracować nad przypadkami użycia z całym zespołem i interesariuszami. Współdzielona tablica online, taka jak FigJam, usprawnia współpracę między zdalnymi zespołami, pomagając Ci tworzyć kompleksowe przypadki użycia. Nasza galeria zawierająca ponad 300 szablonów może zjednoczyć zespoły na każdym etapie rozwoju.