Budujemy poprawnego UseCase’a.

Czas czytania: 15 min.

Podczas pracy nad tworzeniem nowego programu spotkałeś się z takim bytem jak UseCase. Bardzo dobrze, ponieważ jak pewnie wiesz UseCase powinien opisywać jak dana funkcjonalność ma działać. Problem w tym, że w zależności od osoby projektującej funkcjonalność, czy firmy dostarczającej funkcjonalność wyglądały one zupełnie inaczej. Miały różne poziomy szczegółowości. Przez brak standaryzacji nigdy nie wiedziałeś, czego się spodziewać i nie wiedziałeś jaką wartość taki UseCase przyniesie.

W tym artykule przedstawię jak powinien wyglądać UseCase, aby posiadał w sobie merytorykę zgodną z tym do czego został stworzony.

< Zaczynamy />

UseCase musi przekazywać odbiorcy taką aby spełniała poniższe warunki:

  1. Musi być jednoznacznie identyfikowany
  2. Musi wskazywać do jakiej dziedziny funkcjonalnej przynależy
  3. Wynik działania UseCase musi być mierzalny

Wykaz elementów jakie powinien posiadać dobrze skonstruowany UseCase

Indywidualny nr

Numer musi być zwięzły, aby dało się go wymówić bez łamańców językowych. Musi przekazywać trzy informacje:

  • Indywidualny nr
  • Informację, że jest to UseCase
  • Do jakiej dziedziny funkcjonalnej przynależy

Przykład:
Dziedzina funkcjonalna: Zarządzanie fakturami (skrót: ZF)
Nr UseCase: UZF_01
U – UseCase
ZF – Zarządzenie Fakturami
_01 – kolejny numer UseCase w ramach Dziedziny funkcjonalnej.

Nazwa UseCase:

Dobra nazwa Zła nazwa
Tworzenie nowej FV Możliwość stworzenia nowej FV
Wysłanie powiadomienia o zatwierdzeniu FV Użytkownik wysyła powiadomienie o zatwierdzeniu FV do firmy ABC

Opis

W tym miejscu opisujemy co właściwie ma robić dana funkcjonalność. Pamiętaj, że nikt nie chce czytać w pracy epopei więc pisz konkretnie i na temat. Nie owijaj w bawełnę. Nie zaczynaj zdań od takich stwierdzeń jak:

  • Użytkownik ma możliwość
  • Użytkownik może wykonać.
    Tylko
  • Możliwość generowania ….

Od tego kto może wykonać daną funkcjonalność służy Aktor z nim połączony.

Warunek początkowy, warunek końcowy

Wielu analityków omija ta kwestię, ale uważam, że warunki graniczne są niezastąpione. Warunki początkowe jak i końcowe ponieważ może być ich wiele muszą być mierzalne w taki sposób, aby użytkownik realizujący dana funkcjonalność potrafił określić, że ją zrealizował, albo nie.

Scenariusz (opcjonalnie)

W tym momencie należy sobie zadać pytanie do czego ma nam posłużyć taki scenariusz. Co on właściwie ma zawierać? Jak kto stworzyć, aby odbiorca miał realną wartość z niego.

Scenariusz powinien przedstawiać komunikacje użytkownika z systemem. Nie chodzi o to, aby w scenariuszu wpisać nazwy przycisków, czy dokładne dane z otrzymanych komunikatów. Scenariusz przedstawia kolejność akcji wykonywanych przez Aktora i system.

Rozróżniamy trzy rodzaje scenariuszy:

  • optymistyczny – podstawowy przebieg umożliwiający przeprowadzić użytkownika od posiadania spełnianych warunków początkowych do osiągnięcia warunków końcowych.
  • alternatywny – Przebieg, którego ścieżka jest inna niż podstawowa, ale jest możliwość osiągnięcia warunków końcowych. Ważne, aby ścieżka alternatywna nie negowała warunków końcowych.
  • wyjątek – ścieżka obrazuje scenariusz kończący się pesymistycznie. Po co taką ścieżkę w ogóle opisywać jak z założenia wiemy, że nie osiągnie ona zamierzonego celu jaki jest warunek końcowy? Przedstawiamy scenariusze wyjątkowe po to, aby obsłużyć wyjątkowe sytuacje. Dzięki temu, że analityk zdiagnozuje nieprzewidziane sytuacje, developer będzie mógł je zaimplementować, a sam system stanie się idiotoodporny.

WAŻNE: Jak UseCase jest bardzo atomowy, albo dość prosty do zrozumienia. To nie ma potrzeby tworzyć scenariusze do niego. Pamiętaj, aby nie dodawać elementów, tylko po to, aby były.

Masz już poprawna konstrukcje UseCase. Teraz od Ciebie zależy jak bardzo będzie on wartościowy dla odbiorcy.

UseCase to nie wolny elektron.

Ten temat pozostawimy na odrębny wpis. Jednak już teraz musisz pamiętać, że przekazanie odbiorcy samotnego UseCase, albo grupy UseCase może nie być wystarczające. UseCase to nie wolny elektron. Funkcjonalność jest częścią większej całości. Każdy UseCase należy do dziedziny funkcjonalnej.

Przeważnie UseCase należy obudować wiedzą bardziej szczegółową jak np:

  • mockup obrazujący makietę jak może wyglądać interfejs za pomocą którego będzie realizowana ta funkcjonalność
  • diagram aktywności obrazujący logikę działania
  • itp

Jeszcze raz w skrucie

  1. Do projektowania pojedynczej funkcjonalności podejdź tak samo jak do tworzenia całego projektu. Od ogółu to szczegółu.
  2. Wpisz indywidualny nr i nazwę UseCase. Nazwa musi być krótka, zwięzła i na temat.
  3. Warunek końcowy. Musisz wiedzieć jaki chcesz otrzymać efekt. Sprawdź, czy to co napisałeś jako warunek końcowy jest mierzalne.
  4. Opis funkcjonalności. Tworząc opis funkcjonalności musisz być precyzyjnie dobitny. Nie ma tutaj miejsca na takie stwierdzenia jak “Dobrze by była”, “Jeśli jest taka możliwość”, “Powinna być możliwość”, itp. Powiem więcej. Takich stwierdzeń nie może być w żadnej części projektowanego systemu.
  5. Warunki początkowe. Po opisie funkcjonalności zastanów co jest wymagane od użytkownika, aby mógł zrealizować daną funkcjonalność.
  6. Indywidualny numer. Jak dotarłeś do tego miejsca z projektowaniem funkcjonalności to znaczy, ze jednak jej potrzebujesz i potrafisz ja sparametryzować. W tym momencie możesz nadać jej numer, czyli wprowadzić ją w szereg innych funkcjonalności w obrębie danej dziedziny funkcjonalnej.
  7. Dziedzina funkcjonalna. Pamiętaj, aby nie wkładać wszystkich funkcjonalności do jednego worka. Dekomponuj je właśnie na dziedziny funkcjonalne.
  8. Status. Pamiętaj, aby statusować funkcjonalności. Jak tworzę UseCase to zawsze pierwszym statusem jest “Propozycja”.

Opcjonalnie

  1. Scenariusz. Opcjonalnie ponieważ czym bardziej atomowe funkcjonalności tym  scenariusze stają się krótsze. Nie ma sensu tworzyć scenariuszy na siłę jak sam projektant czuje, że dużej wartości nie wniosą.
  2. Mocqup lo-fi. Dobrą praktyką jest naszkicowanie interfejsu uzytkownika. Nie oczekujmy, że analityk zaprojektuje nam szczegółowy i  w pełni usability mocqup hi-fi. Od tego mamy UX’ów.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *