Jak pisać skuteczne przypadki użycia

Opublikowany: 2015-08-21

Jak pisać skuteczne przypadki użycia

Przypadki użycia są szeroko stosowane do dokumentowania logiki biznesowej i procesów systemowych. Ale jest wiele opinii na temat tego, czy są przydatne i jak powinny być skonstruowane. W niektórych projektach programiści nigdy nie patrzą na przypadki użycia, mówiąc, że są one szczegółowe lub naprawdę niewiele z nich rozumieją. Co może zrobić analityk biznesowy, aby przypadki użycia były naprawdę skuteczne?

Większość z nas zdaje sobie sprawę, że przypadki użycia opisują proces biznesowy i są specyfikacją interakcji między systemem a aktorami dla określonych celów. Dokument przypadku użycia różni się od dokumentu wymagań i nie jest tym samym, co dokument projektowy.

Przyjrzyjmy się dwóm przykładom przypadków użycia dla wymagania. Jak myślisz, który z nich jest lepszy.

Przykład 1

Użyj szczegółów przypadku Uwagi

Przypadek użycia Nazwa – Zamów bilety

Nazwa jest dobra. Wyraźnie wskazuje, jaki przypadek użycia

Cel – Klient z powodzeniem rezerwuje bilety na mecz piłki nożnej na stronie internetowej

Opis- Aktor odwiedza witrynę internetową, przegląda
harmonogram, wybiera mecz
i fotele, książki
bilet i dokonuje płatności za mecz piłki nożnej

Cel i opis są jasno określone.
Pomoże to projektantom
a programiści rozumieją, co to jest
cel ich dokumentacji projektowej i kodu

Aktorzy – Klient, Przedstawiciel Biura Obsługi Klienta
Warunki wstępne — system jest gotowy do pracy.
Wyzwalacz – aktor uzyskał dostęp do systemu w celu rezerwacji biletów.
Warunek końcowy – aktor jest w stanie zarezerwować bilety. System aktualizuje informacje.

Wszystkie inne szczegóły przypadku użycia, takie jak aktorzy,
warunki wstępne, warunki pocztowe i
wymienione są wyzwalacze, które pomogą
łatwiejsze projektowanie i tworzenie aplikacji.

Główny przepływ – kroki

  1. Aktor wchodzi na stronę internetową i wybiera rezerwację biletów
  2. System wyświetla informacje o rezerwacji
  3. Aktor potwierdza szczegóły meczu (więcej szczegółów w specyfikacji UI)
  4. Aktor potwierdza szczegóły miejsca (więcej szczegółów w specyfikacji UI)
  5. System potwierdza dostępność
  6. System przedstawia formularz, aby uzyskać informacje o użytkowniku
  7. Aktor podaje informacje o użytkowniku (Szczegóły w innym przypadku użycia)
  8. System prezentuje formularz do informacji o płatności
  9. Aktor podaje informacje o płatności (Szczegóły w innym przypadku użycia)
  10. System potwierdza szczegóły i nadaje numer rezerwacji
  11. Aktor oszczędza bilet
  12. Aktor wychodzi z systemu.

Dołączone przypadki użycia

- Dokonać płatności

– Wygeneruj identyfikator rezerwacji

Rozszerzone przypadki użycia

– Wygeneruj notatkę o niepowodzeniu płatności

– Wydrukuj bilet

Kroki w głównym przepływie są jasne, ale
Szczegóły interfejsu użytkownika zostały pominięte. Szczegóły interfejsu użytkownika w przypadku użycia
dotyczące wyboru miejsca i dopasowania
wybór może sprawić, że przypadek użycia będzie nieporęczny.
Przypadek użycia jasno pokazuje, co aktor ma zrobić i co zrobi system
Proces płatności jest szczegółowo opisany w
inny przypadek użycia, aby zadania mogły być
łatwo podzielić na różne elementy konstrukcyjne.
Uwzględnione i rozszerzone przypadki użycia są nazwane
aby można było
zapoznaj się z nimi w celu uzyskania dalszych szczegółów.

Przepływ alternatywny

-anuluj bilety

  1. Aktor anuluje transakcję
  2. System anuluje transakcję

Przepływ wyjątków

- Bilety niedostępne na wybrany mecz/wybrane miejsca

1. System wyświetla komunikat o błędzie

Przepływy alternatywne i wyjątków są szczegółowo opisane.

* Przypadek użycia może być bardziej szczegółowy pod względem odwołań oraz przepływów alternatywnych i wyjątków. Ten przykład ma na celu podkreślenie, co powinno być zawarte w dobrze napisanym przypadku użycia.

Przykład – 2

Użyj szczegółów przypadku Uwagi

Przypadek użycia Nazwa – Zamawianie biletów

Nazwa nie jest z perspektywy użytkownika i wydaje się być definicją procesu biznesowego.

Opis – Aktor odwiedza stronę internetową, przegląda harmonogram, wybiera mecz i miejsca, rezerwuje bilet i dokonuje płatności za mecz piłki nożnej

Brak celu przypadku użycia. Projektanci, analitycy testów i programiści nie zrozumieją, dlaczego ta funkcjonalność musi być rozwijana.

Aktorzy – Klient, Przedstawiciel Biura Obsługi Klienta
Wyzwalacz – aktor uzyskał dostęp do systemu w celu rezerwacji biletów.
Warunek końcowy – aktor jest w stanie zarezerwować bilety. System aktualizuje informacje.

Brak warunków wstępnych.

Główne kroki przepływu

  1. Klient wchodzi na stronę i wybiera opcję „Zarezerwuj bilety” w celu rezerwacji biletów
  2. System wyświetla listę dopasowań w rozwijanej liście.
  3. Przedstawiciel obsługi klienta wybiera z listy rozwijanej
  4. System wyświetla szczegóły miejsc na mapie miejsc
  5. Aktor wybiera miejsca. Jeśli miejsca nie są dostępne i wyświetlany jest komunikat o błędzie.
  6. Aktor podaje szczegóły płatności
  7. Aktor rezerwuje bilet, w przeciwnym razie bilet anuluje.
  8. System generuje identyfikator rezerwacji na podstawie imienia klienta i losowo wygenerowanego 4-cyfrowego numeru

Dołączone przypadki użycia
- Dokonać płatności

W krokach dotyczących przypadków użycia znajdują się odniesienia do rzeczywistych elementów interfejsu użytkownika, które mogą zmylić czytelnika. Przepływy alternatywne są zapisywane w przepływie głównym, co utrudnia zrozumienie całego procesu.
Aktor określany jest wieloma nazwami – „Klient, Aktor i Przedstawiciel Obsługi Klienta, co jest mylące.
Tutaj wyjaśniono generowanie identyfikatora rezerwacji, ale nie dotyczy to aktorów związanych z zamawianiem biletów.
Nie ma alternatywnych przepływów, przepływów wyjątków ani wzmianki o wszystkich powiązanych przypadkach użycia.

Ten przypadek użycia jest mało przejrzysty i szczegółowy i nie pomoże zespołowi w prawidłowym rozwijaniu funkcjonalności.

Co powinno być w przypadku użycia Czego nie powinno być w przypadku użycia
  1. Imię
  2. Opis/cel
  3. Warunki wstępne
  4. Spust
  5. Przepływ podstawowy i przepływy alternatywne
  6. Scenariusze wyjątków
  7. Warunki postu
  8. Specjalne wymagania, jeśli istnieją
  9. Link do szczegółów interfejsu użytkownika i innych powiązanych modeli/diagramów
  1. Szczegóły dotyczące wdrożenia
  2. Przetwarzanie wewnętrzne
  3. Wymagania niefunkcjonalne
  4. Szczegóły interfejsu użytkownika powinny być wykonywane jednocześnie z przypadkami użycia, ale w osobnym dokumencie

.

Kilka wskazówek do napisania przydatnych przypadków użycia:

  1. Napisz kroki przypadku użycia z perspektywy aktora.
  2. Przypadki użycia nie powinny zawierać szczegółów projektowych i architektonicznych. Powinna koncentrować się na procesie biznesowym.
  3. Lepiej, jeśli kroki w przypadku użycia są napisane w sposób uporządkowany w czasie
  4. W zależności od wymagań i złożoności, zdecyduj, czy operacje CRUD (Tworzenie, Odczytywanie, Aktualizowanie i Usuwanie) mają być przechowywane w oddzielnych przypadkach użycia, czy mogą być połączone w jednym.
  5. Ważne jest podanie odwołań do przepływów alternatywnych, przepływów wyjątków, uwzględnionych przypadków użycia i rozszerzonych przypadków użycia, aby projekt biznesowy był kompletny.
  6. Wybierz szablon (zdefiniowany przez projekt, zdefiniowany przez firmę lub dowolny szczegółowy) i postępuj zgodnie ze strukturą dla wszystkich przypadków użycia.
  7. Ważne jest posiadanie diagramów przypadków użycia.
  8. W Agile mamy historyjki użytkowników do przechwytywania wymagań. Historyjki użytkownika można szczegółowo opisywać za pomocą przypadków użycia szczupłego w sposób iteracyjny.
  9. Walidacje powinny być szczegółowo opisane.

Po napisaniu przypadku użycia zadaj te pytania i jest to skuteczny przypadek użycia, jeśli odpowiedź na wszystkie pytania brzmi „Tak” –

  1. Czy użytkownik będzie wiedział, kiedy przepływ biznesowy obecny w przypadku użycia zostanie wykonany?
  2. Czy jest jasne, kto wykona dany etap przypadku użycia?
  3. Czy opis logiki biznesowej zapewnia wystarczającą ilość informacji do analizy, projektowania, rozwoju i testowania?
  4. Czy istnieją odpowiednie odwołania od przepływu głównego do przepływów alternatywnych i wyjątków?
  5. Czy istnieje diagram przypadków użycia?

Przypadki użycia to skuteczny sposób na uchwycenie wymagań i formalne udokumentowanie procesów biznesowych, jeśli są dobrze napisane. Cały zespół powinien zostać przeszkolony w zakresie wykorzystywania przypadków użycia do wykonywania swoich zadań. Przypadki użycia i diagramy przypadków użycia to świetny sposób na omówienie procesów biznesowych z klientami. Lepiej mieć standardowy szablon przypadków użycia z wytycznymi dotyczącymi pisania przypadków użycia. Przypadki użycia napisane w ten sposób będą cenione przez wszystkich członków zespołu projektowego i interesariuszy.