Pierwszym krokiem w definiowaniu nowego produktu, usługi, procesu lub systemu jest określenie wymagań, tj. konkretnych wymagań funkcjonalnych lub niefunkcjonalnych.
- Wymagania funkcjonalne opisują, jak produkt lub usługa spełniają potrzeby klientów. Obejmuje to cechy i funkcjonalność w przypadkach użycia, które dokumentują, jak użytkownicy będą wchodzić w interakcje z produktem lub usługą.
- Wymagania niefunkcjonalne są atrybutami operacyjnymi i produktowymi, które czasami nie są oczywiste dla użytkownika, w tym wydajność, użyteczność, trwałość, bezpieczeństwo oraz aspekty finansowe (cena i koszt).
Edytuj tę ilustrację – wymagania funkcjonalne vs wymagania niefunkcjonalne
Wymagania funkcjonalne można postrzegać jako to, co produkt musi zrobić dla klienta, podczas gdy wymagania niefunkcjonalne można postrzegać jako ograniczenia, które produkt lub usługa muszą spełniać.
Wymagania funkcjonalne uchwycają zamierzony sposób działania systemu. To zachowanie może być wyrażone jako usługi, zadania lub funkcje, które system musi wykonać. W branży rozwoju oprogramowania podejście oparte na przypadkach użycia szybko stało się powszechną praktyką zbierania wymagań funkcjonalnych. Jest to szczególnie prawdziwe w społeczności obiektowo zorientowanej i UML, gdzie się narodziło, ale ich zastosowanie nie jest ograniczone do systemów obiektowo zorientowanych.
Jakie techniki zbierania wymagań funkcjonalnych?
Wymagania funkcjonalne są zazwyczaj zbierane w formie przypadków użycia lub scenariuszy użytkowników. Terminy te są czasami używane zamiennie, ale w rzeczywistości oznaczają nieco różne rzeczy.
- Przypadki użycia koncentrują się bardziej na systemie i tym, co musi zrobić, aby zaspokoić potrzeby użytkowników.
- Historie użytkowników, z drugiej strony, pokazują funkcjonalność produktu z punktu widzenia użytkownika, określając role użytkowników i konkretne cele, które chcą osiągnąć.
Zbieranie wymagań funkcjonalnych za pomocą historii użytkowników
Historie użytkowników to lekka metoda szybkiego zbierania „kto”, „co” i „dlaczego” wymagań produktu. Mówiąc prosto, historie użytkowników to pomysły, które wyrażają potrzeby, które mają użytkownicy. Historie użytkowników są krótkie, a każdy element zazwyczaj zawiera mniej niż 10 lub 15 słów. Historie użytkowników to listy „do zrobienia”, które pomagają zidentyfikować kroki na ścieżce projektu. Pomagają zapewnić, że twój proces i powstały produkt spełniają twoje wymagania.
Szablon historii użytkownika
Historie użytkowników uchwycają tylko istotne elementy wymagania:
- Dla kogo jest przeznaczone?
- Czego oczekuje od systemu?
- Dlaczego to jest ważne (opcjonalnie?)?
Oto prosty format historii użytkownika używany przez 70% praktyków:
Rola – Użytkownik powinien być rzeczywistym człowiekiem, który wchodzi w interakcję z systemem.
- Bądź tak konkretny, jak to możliwe
- Zespół deweloperski NIE jest użytkownikiem
Akcja – Zachowanie systemu powinno być zapisane jako akcja.
- Zazwyczaj unikalne dla każdej historii użytkownika
- „System” jest domyślny i nie jest zapisany w historii
- Głos czynny, nie bierny („Mogę być powiadomiony”)
Korzyści – Korzyść powinna być wynikiem rzeczywistym, który jest niefunkcjonalny lub zewnętrzny dla systemu.
- Wiele historii może mieć to samo stwierdzenie korzyści.
- Korzyść może dotyczyć innych użytkowników lub klientów, a nie tylko użytkownika w historii.
Jak zidentyfikować wymagania funkcjonalne za pomocą przypadku użycia?
Aby w pełni zrozumieć wymagania funkcjonalne systemu, musisz wiedzieć, dla kogo jest przeznaczony system, tj. Kto będzie korzystał z systemu?
Odpowiedzią na to pytanie jest: aktor w analizie przypadków użycia
Przypadki użycia lub historie użytkowników uchwycają wymagania funkcjonalne, których zachowanie może być wyrażone jako usługi, zadania lub funkcje, które system musi wykonać. Przypadki użycia definiują interakcję między użytkownikiem a usługą systemową, co może pomóc w określeniu wymagań funkcjonalnych rozwijanego systemu. Innymi słowy, co produkt lub usługa musi zrobić, aby zaspokoić potrzeby i pragnienia klienta.
Przypadek użycia zaczyna się od „aktora” lub „kto”, konkretnego użytkownika produktu lub usługi.
A aktor jest osobą lub zewnętrznym systemem, który odgrywa rolę w interakcji z systemem. Przykłady aktorów mogą być osobami fizycznymi lub systemami zewnętrznymi; jednak każdy aktor dostarcza unikalnej i ważnej perspektywy systemu, perspektywy, która jest wspólna dla każdego przypadku (rzeczywista osoba / użytkownik) aktora.
Rzeczywisty użytkownik vs aktor przypadku użycia
Aby w pełni zrozumieć cel systemu, musisz wiedzieć, dla kogo jest przeznaczony system, tj. kto będzie z niego korzystał. Różne typy użytkowników są reprezentowane jako aktorzy (role).
Różnica między rolą a indywidualnym użytkownikiem polega na tym, że rola reprezentuje konkretną klasę użytkowników, a nie rzeczywistego użytkownika. Różni użytkownicy mogą odgrywać tę samą rolę, w takim przypadku każdy użytkownik stanowi instancję aktora.
Ta różnica między aktorami a instancjami aktorów jest ilustrowana w następujący sposób:
Rysunek poniżej pokazuje przypadek, w którym Mary i John są klientami automatu sprzedającego. Kiedy korzystają z automatu, każdy z nich jest reprezentowany przez instancję aktora zwanego klientem, który oczekuje dostępu do określonych funkcji systemu (w tym przypadku drukowania zakupu jedzenia).
Edytuj tę ilustrację automatu sprzedającego
Przeciwnie, ten sam użytkownik może odgrywać wiele ról (tj. ta sama osoba może odgrywać różne role).
Na przykład, Dr Gates, który jest członkiem komitetu Towarzystwa Komputerowego. Odpowiada za zarządzanie systemem zarządzania członkostwem, takim jak dodawanie i usuwanie kont użytkowników. Kiedy to robi, odgrywa rolę zwaną Administratorem (Aktor). Jednak ten sam Dr Gates może być również członkiem Towarzystwa Komputerowego. W takim przypadku odgrywałby również rolę zwaną „Członkiem” (Aktor).
Jak uzyskać wymagania funkcjonalne, identyfikując przypadki użycia systemu
Przypadek użycia można zidentyfikować, zadając interesariuszom następujące pytania (na które muszą odpowiedzieć z punktu widzenia aktorów):
- Co użytkownicy w tej roli próbują osiągnąć?
- Aby wypełnić tę rolę, co użytkownicy muszą być w stanie zrobić?
- Jakie są główne zadania użytkowników w tej roli?
- Jakie informacje użytkownicy w tej roli muszą zbadać, stworzyć lub zmienić?
- Czego użytkownicy w tej roli muszą być informowani przez system?
- O czym użytkownicy w tej roli muszą informować system?
Zauważ, że:
Przypadki użycia są często używane jako środek do odkrywania i reprezentowania wymagań funkcjonalnych i systemowych, ponieważ przypadek użycia definiuje interakcje i zadania potrzebne do realizacji konkretnego celu biznesowego. Jednak zazwyczaj nie są dobrym sposobem na definiowanie wymagań niefunkcjonalnych, takich jak wydajność i jakość systemu.
Bibliografia
- Historia użytkownika vs przypadek użycia w zwinnej metodzie rozwoju oprogramowania
- Czym jest historia użytkownika?
- Czym jest mapowanie historii użytkownika?
- Identyfikacja wymagań użytkowników za pomocą diagramów przypadków użycia
- Jak używać szkieletów z historiami użytkowników?
- Podejście oparte na przypadkach użycia w zwinnej metodzie rozwoju
- Czym jest specyfikacja przypadku użycia?
Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文