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)
agile
object-oriented
Henning
źródło
źródło
Odpowiedzi:
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.
źródło
Dla mnie największe różnice między historią użytkownika a przypadkiem użycia to:
Według Scotta W. Amblera w scenariuszach użycia te artefakty wyglądają jak przepływ przypadku użycia:
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):
Mogę się mylić, ale Scenariusz użytkowania naprawdę brzmi jak przepływ przypadków użycia, ale został przemianowany za pomocą zwinnego dotyku.
źródło
A use case is an heavyweight document that needs a word document.
. Martin Fowler uważa, żeUse case are at their best when they are short and readable. You should not be spending weeks, let alone months, generating use case documents before you begin development.
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.
źródło
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.
źródło
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:
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.
źródło
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:
Rozszerzenia - przepływ aplikacji, gdy odbiega ona od przepływu scenariusza sukcesu:
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:
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 :
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ęść:
Scenariusze użycia można wykorzystać do napisania testu dla aplikacji. Cytując ostatni akapit postu Martina:
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
źródło
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.
źródło
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.
źródło
„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.
źródło
Ze strony poświęconej sztuce produktu .
źródło