Czy istnieje dokładna, ale prosta i zrozumiała definicja rozróżnienia między „przypadkiem użycia”, „historią użytkownika” i „scenariuszem użytkowania”?

jest sporo wyjaśnień, ale w tej chwili nie widzę nikogo, kto wyjaśniłby różnice w jednym zdaniu lub dwóch ...

(np. http://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparison bardzo długie i trudne do zdobycia, pełne dyskusji)

Story Użytkownik jest bardziej nieformalny, przyjazny i mniejsza wersja Korzystanie sprawie minus diagram UML; jest zwykle używany w scenariuszach iteracyjnych.

Scenariusz użycia to przypadku użycia wyciągnięta do procedury krok po kroku, czasami towarzyszy schemacie.

Dla mnie największe różnice między historią użytkownika a przypadkiem użycia to:

• Historia użytkownik jest lekki dokument, który może być zapisany na karcie (w celu, jak chcę). Historia użytkownika nie przechwytuje wszystkich szczegółów, jest to nieformalne wsparcie dyskusji.
• Przypadek użycia jest heavyweight dokument, który wymaga dokumentu programu Word. Opisuje „normalny przepływ” kroków i / lub działań oraz „alternatywne przepływy”, które są szczegółowo opisane. Przypadek użycia przechwytuje wszystkie szczegóły, jest to formalna specyfikacja.

Według Scotta W. Amblera w scenariuszach użycia te artefakty wyglądają jak przepływ przypadku użycia:

Scenariusz użycie lub scenariusz w skrócie opisuje przykład w świecie rzeczywistym, jak jedna lub więcej osób lub organizacji interakcji z systemem. Opisują kroki, zdarzenia i / lub działania, które występują podczas interakcji. Scenariusze użycia mogą być bardzo szczegółowe, wskazując dokładnie, jak ktoś pracuje z interfejsem użytkownika, lub dość wysoki poziom opisujący krytyczne działania biznesowe, ale nie wskazując, w jaki sposób są one wykonywane.

Szczerze mówiąc, różnice w przepływie przypadku użycia nie są krystalicznie wyraźne, nawet po przeczytaniu tego akapitu (ostatnie zdanie może być najważniejsze):

Jak możesz sobie wyobrazić, istnieje kilka różnic między przypadkami użycia i scenariuszami. Po pierwsze, przypadek użycia zazwyczaj odnosi się do aktorów ogólnych, takich jak Klient, podczas gdy scenariusze zwykle odnoszą się do przykładów aktorów, takich jak John Smith i Sally Jones. Nic nie stoi na przeszkodzie, aby napisać ogólny scenariusz, ale zazwyczaj lepiej jest spersonalizować scenariusze, aby zwiększyć ich zrozumiałość. Po drugie, scenariusze użycia opisują jedną ścieżkę logiki, podczas gdy przypadki użycia zwykle opisują kilka ścieżek (kurs podstawowy plus wszelkie odpowiednie ścieżki alternatywne). Po trzecie, w procesach opartych na UP przypadki użycia są często przechowywane jako oficjalna dokumentacja, podczas gdy scenariusze są często odrzucane, gdy nie są już potrzebne.

Mogę się mylić, ale Scenariusz użytkowania naprawdę brzmi jak przepływ przypadków użycia, ale został przemianowany za pomocą zwinnego dotyku.

Nie ma dokładnej definicji tych rzeczy. Wszystko różni się nieco (lub bardzo) w zależności od firmy i systemu.

Najlepiej jest znaleźć przykładowy przykład dla bieżącego projektu i postępować zgodnie z nim.

Jeśli tworzysz nowy system, możesz znaleźć definicje różnych rodzajów przypadków użycia dla dowolnego preferowanego systemu - po prostu wybierz wzór, który wydaje się najlepiej komunikować twoje zamiary.

Nie rozłączaj się z imionami.

Historia użytkownika jest zawsze nieformalna i opisuje potrzebę użytkownika. Przypadek użycia może być formalny lub nieformalny i opisuje zachowanie systemu.

Możliwe są historie użytkowników „technicznych”, to samo nie dotyczy przypadków użycia.

Po zakończeniu historia użytkownika jest zwykle odrzucana. Przypadki użycia mogą być utrzymywane podczas cyklu życia produktu.

Zakres jest również inny. Historie użytkowników mają zazwyczaj mniejszy zakres, a zatem przypadek użycia obejmuje kilka historii użytkownika. Zmienione wymagania dotyczące istniejącego systemu opisano w nowej historii użytkownika lub w zaktualizowanej wersji przypadku użycia.

Podobieństwa między historiami użytkowników i przypadkami użycia są takie, że oba są wykorzystywane do planowania i harmonogramowania.

Historia użytkownika po rozkładzie na zadania przypisane indywidualnie programistom może być bardziej szczegółowa i ograniczona w zakresie niż scenariusz przypadku użycia. Historia użytkownika dotyczy potrzeby użytkownika - celu lub wyniku korzystania z systemu.

Przykłady historii użytkowników:

1. Jestem klientem i chcę spłacać saldo konta online - widok dość wysoki
2. Jestem klientem i chcę zaktualizować rok wygaśnięcia przechowywanych informacji kredytowych - dość szczegółowy widok.

Na najwyższym poziomie abstrakcji Przypadek użycia brzmi bardzo podobnie - Rok ważności karty aktualizacji klienta - ale tutaj jest to określenie funkcji, a nie celu.

Po zdefiniowaniu szczegółowości scenariuszy przypadków użycia stają się one bardziej związane z funkcją i procedurą.

Stan po scenariuszu głównym przypadku użycia powinien być taki sam, jak ten podany w Historii użytkownika - Zaktualizowano rok wygaśnięcia karty kredytowej klienta.

Scenariusze przypadków użycia opisują krok po kroku w tekście lub schemacie procesu (niekoniecznie UML lub BPM - używam standardowego schematu przepływu międzyfunkcyjnego dla jasności i łatwości użytkowania przez nieprzeszkolonych konsumentów przypadku użycia.

Najważniejsze jest to, że Historie użytkowników opisują potrzeby i wyniki (to, co system musi zrealizować), natomiast przypadki użycia opisują interakcje między aktorami wymagane do osiągnięcia celu - ORAZ co może pójść nie tak (scenariusze rozszerzenia, alternatywy lub błędu) (sposób interakcji użytkownika z System osiąga ten wynik)

W celu szczegółowej dyskusji na ten temat sugeruję przeczytanie http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison na stronie internetowej Alistair Cockburn. Ponieważ jest sygnatariuszem Agile Manifesto, osoba, która stworzyła User Stories i przez ostatnie kilkadziesiąt lat była uważana za specjalistę od przypadków użycia, myślę, że jest doskonałym źródłem dodatkowych informacji.

_{Szybka notatka tymczasowa : ten post wymaga ulepszeń, aby lepiej odpowiedzieć na pytanie, takich jak 1) dodatkowe szczegóły powinny być zawarte w referencjach 2) niektóre cytaty może 3) ogólna poprawność języka angielskiego 4) ogólna jakość narracji 5) itd. Będę wróć do tego. Możesz to poprawić samodzielnie.}

Spojrzenie na ich szablony może dać cenny wgląd w różnice między tymi terminami.

Przypadek użycia

Istnieje wiele szablonów przypadków użycia. Znalazłem 3 po szybkim wyszukiwaniu: 1 , 2 , 3 . Niektóre punkty, które mają (czasem niejasno) wspólne:

1. Nazwa przypadku użycia / tytułu
2. Opis - krótki tekst opisujący zakres.
3. Aktor (y) / Główny aktor - osoba (osoby), które wchodzą w interakcje z tym konkretnym przypadkiem użycia.
4. Warunek wstępny - wszystko, co ten przypadek użycia może uznać za prawdziwy przed rozpoczęciem jego cyklu życia.
5. Scenariusz sukcesu - sekwencja kroków opisująca prawidłowy przebieg zachodzących zdarzeń.

6. Rozszerzenia - przepływ aplikacji, gdy odbiega ona od przepływu scenariusza sukcesu:

   1. Przepływy alternatywne - inne opcje poprawnego przepływu
   2. Przepływy wyjątków - przepływ zdarzeń na wypadek, gdy coś pójdzie nie tak

7. Gwarancja sukcesu (aka. Stan postu) - stan zgłoszenia po wykonaniu wszystkich czynności

Niektóre dodatkowe punkty, które można uwzględnić, to Poziom , Minimalne Gwarancje , Wyzwalacz itp.

Powyżej jest tak zwany w pełni ubrany przypadek użycia . Możesz uprościć tworzenie przypadków użycia, używając przypadkowego przypadku użycia , używając tylko najważniejszych punktów, na przykład:

1. Tytuł
2. Aktorzy
3. Sekwencja wydarzeń

Przypadki użycia zostały stworzone i spopularyzowane przez Ivara Jacobsona na przełomie lat 80. i 90. Później także inni ludzie przyczynili się do jego pracy (jedną z takich osób jest Alistair Cockburn, autorka artykułów o efektywnym użytkowaniu ). Aby sparafrazować Martin Fowler przypadków użycia mogą skorzystać z tekstu i diagramów UML, ale ich największych kłamstw wartości w tekście niego. Są najlepsze, gdy nie są duże i łatwe do odczytania.

Historia użytkownika _{(znana również jako funkcja)}

Historia użytkownika - mała historia opisująca określoną funkcję. Istnieje wspólny wzorzec pisania historii użytkownika, który brzmi:

Jako szczególny typ użytkownika
chcę coś zrobić
, aby z jakiegoś powodu .

Ponadto historia użytkownika może mieć kryteria akceptacji .

Jak widać, ten szablon jest znacznie mniejszy niż przypadek użycia. Historie użytkowników są zwykle kojarzone z regionem rozwoju oprogramowania scrum / agile / xp. Są przeznaczone do pisania na małych obszarach powierzchni, takich jak karteczki samoprzylepne i / lub na tablicach Scrum. Tam są (zwykle) podane wartości punktowe, które przybliżają, ile wysiłku należy zainwestować w tę historię użytkownika ^ref .

Bill Wake opracował mnemonik INVEST, aby opisać, jakie cechy powinna mieć dobra historia użytkownika, i pożyczę krótkie podsumowanie tego Martina Fowlera z jego strony internetowej :

Niezależne : historie mogą być dostarczane w dowolnej kolejności
Negocjowalne : szczegóły tego, co jest w historii, są współtworzone przez programistów i klientów podczas opracowywania.
Cenne : funkcjonalność jest postrzegana przez klientów lub użytkowników oprogramowania jako cenna.
Szacunkowy : programiści mogą opracować rozsądny kosztorys budowania opowieści.
Małe : historie powinny być budowane w krótkim czasie, zwykle w ciągu osobodni. Z pewnością powinieneś być w stanie zbudować kilka historii w ramach jednej iteracji.
Testowalny : powinieneś być w stanie napisać testy, aby sprawdzić, czy oprogramowanie dla tej historii działa poprawnie.

Scenariusz użycia

Scenariusz użycia jest zgodny ze wzorem GWT, który oznacza Given-When-Then, w następujący sposób:

Scenariusz : tytuł
Biorąc pod uwagę : konkretny fakt
I : inny szczególny fakt (może być opcjonalny)
Kiedy : pewne zdarzenie się dzieje
Następnie : inne zdarzenie się dzieje

Scenariusze użycia są powiązane z rozwojem opartym na zachowaniu. Brzmi bardzo podobnie do testu. Martin Fowler w swoim wpisie na blogu podaje historię i uzasadnienie scenariuszy użytkowania. Oto ważna część:

Dana część opisuje stan świata przed rozpoczęciem zachowanie jesteś określając w tym scenariuszu. Możesz myśleć o tym jako o warunkach wstępnych testu.
Sekcja kiedy to zachowanie, które określasz.
Wreszcie następnie sekcja opisuje zmiany można oczekiwać w związku z określonym zachowaniem.

Scenariusze użycia można wykorzystać do napisania testu dla aplikacji. Cytując ostatni akapit postu Martina:

Chociaż styl Given-When-Then jest symptomatyczny dla BDD, podstawowa idea jest dość powszechna podczas pisania testów lub specyfikacji na przykładach. Meszaros opisuje wzór jako test czterofazowy. Jego cztery fazy to Przygotowanie (dane), Ćwiczenie (Kiedy), Weryfikacja (Wtedy) i Porzucenie. Bill Wake wymyślił formułę jako Arrange, Act, Assert.

Referencje do dalszych badań:

Strony Wikipedii dotyczące przypadku użycia , historii użytkownika , scenariusza użytkowania
Blogi Martina Fowlera na temat przypadku użycia , historii użytkownika , scenariusza użytkowania

Nie jestem zaznajomiony z User Story, ale kiedy przyjrzałem się temu kilka lat temu:

Przypadek użycia jest ważnym zadaniem.
Scenariusze użytkownika to różne sposoby odgrywania zadania. Zatem każdy przypadek użycia ma jeden lub więcej scenariuszy. Przypadek użycia jest streszczeniem, scenariusze użytkownika są katalogiem wszystkich możliwych instancji tego abstrakcyjnego zadania.

Zatem:
Użyj przypadku A: Użytkownik uwierzytelnia się za pomocą identyfikatora i hasła.

Scenariusze:
1. Identyfikator jest rozpoznawany, hasło jest prawidłowe. (scenariusz „słoneczny dzień”)
2. Rozpoznano identyfikator, hasło jest niepoprawne.
3. Identyfikator jest rozpoznawany, hasło jest niepoprawne po raz trzeci.
4. Identyfikator nie jest rozpoznawany.

Zawsze uważałem przypadki użycia za sposób definiowania wymagań w sposób narracyjny dla klienta na ich warunkach. w / r / t powyżej, jeśli klient powie „Ale co, jeśli spróbuje zalogować się między północą a pierwszą, gdy system jest wyłączony?”, odkryliśmy inny scenariusz dla zadania uwierzytelnienia i pewne dodatkowe wymagania.

Historia użytkownika jest z punktu widzenia klienta, czasem jest niepoprawna lub niekompletna. Może nie mieć wpływu na wydajność, obsługę błędów lub na backend.

Przypadek użycia jest z punktu widzenia dewelopera. Jest dokładny i kompletny. Powinien odpowiadać na wszystkie wymagania klientów.

„Przypadek użycia” i „historia użytkownika” są takie same w tym sensie, że reprezentują „wymagania” klienta.

Przypadek użycia to sposób, w jaki system jest używany w każdym przypadku, zwykle reprezentowany jako interakcja między aktorem a systemem lub między systemami.

Historia użytkownika jest punktem początkowym podróży do stworzenia narzędzia wspomaganego komputerowo, które umożliwi użytkownikowi końcowemu wykonanie zadania, i zwykle zaczyna się od prostego zdania, z którego kto, co, dlaczego („Chcę zamknąć aplikację monit o zapisanie wszystkiego, co zmieniło się od czasu ostatniego zapisu, abym mógł zachować użyteczną pracę i odrzucić błędną pracę. ”). Tę historię użytkownika należy następnie przekształcić w przypadek użycia, którego programiści używają do tworzenia aplikacji, a testerzy do przeprowadzania testów.

Z perspektywy QA Testera nie testują „historii użytkowników”, lecz „przypadków użycia”, co oznacza, że ​​testują funkcje oprogramowania.

Celem scenariusza użytkowania jest uchwycenie istoty interakcji użytkownika z systemem w celu osiągnięcia celu, bez zagłębiania się w szczegóły działań systemu lub rzeczywistego projektu. Nacisk kładziony jest na użytkownika, a nie na system.

... Przypadek użycia zawiera również stwierdzenia o tym, co zrobi system, natomiast scenariusz użycia pozwoli uniknąć tej dyskusji.

Nie określiłeś jeszcze, jak zamierzasz to wdrożyć.

Ze strony poświęconej sztuce produktu .