10 wskazówek jak skutecznie pisać przypadki użycia 2


Skuteczne przypadki użyciaZ przypadkami użycia jest trochę jak piłką nożną w naszym kraju – niby wszyscy wiemy “czym to się je”, ale kiedy zaczynamy rozmawiać o szczegółach, to okazuje się że nie wszystko jest takie proste i oczywiste.

Zaczynamy od odpowiedzi na pytanie – czym jest przypadek użycia (ang. Use Case, często używane w skrócie UC)? Przypadek użycia jest pisaną prozą historią, najczęściej w formie listy kroków realizowanych przez poszczególnych aktorów, prowadzących do realizacji określonego celu. Pod pojęciem aktor można rozumieć rolę w systemie (np. administrator), zewnętrzne oprogramowanie (np. system księgowy) lub urządzenie (np. drukarka).

System realizujący przypadek użycia, gwarantuje aktorom osiągnięcie ich celów, tylko pod warunkiem spełnienia pewnych wstępnych wymagań (np. posiadanie określonej roli w systemie).

Wartym podkreślenia jest, że przypadek użycia nie jest odpowiedzią na wszelkie potrzeby inżynierii wymagań. Forma ta nadaje się świetnie do opisu funkcjonalności systemu na różnych poziomach szczegółowości, ale nie może zastąpić diagramów aktywności, przepływu, czy modeli domenowych.

Poniżej znajdziesz listę dziesięciu wskazówek, których stosowanie uczyni Twoje przypadki użycia bardziej efektywnymi. Lista  ta została zainspirowana najlepszą chyba pozycją jaka powstała z zakresu projektowania przypadków użycia – „Writing Effective Use Cases” (w polskim tłumaczeniu: „Jak pisać efektywne przypadki użycia”). Zaczynamy!

    1. Czytelność formatu – stosuj prosty, przejrzysty i ujednolicony format. Skup się na treści a nie na formie. Sprawdź np. https://en.wikipedia.org/wiki/Use_case#Examples Zaproponowany, standardowy szablon zawiera tytuł przypadku, aktorów, skrócony opis przypadku, warunki wstępne i początkowe (minimalną gwarancję oraz główny cel), wyzwalacz przypadku, podstawowy scenariusz oraz alternatywne ścieżki. Stosując ten sam format za każdym razem, przyzwyczaisz czytelników do określonej formy i ułatwisz im przyswajanie i wyszukiwanie informacji.Jeszcze bardziej uproszczony przykład znajdziesz np. tutaj: http://pmblog.accompa.com/2009/10/08/use-case-template-example-requirements-management-basics/
      Czy podoba Ci się taka forma opisu zachowania systemu? 
    2. Na przykładach przytoczonych powyżej widać, iż każdy przypadek musi mieć określony cel i warunki wstępne – są to bardzo ważne informacje! Cel dotyczy podstawowego scenariusza – jest to zobowiązanie systemu względem aktorów. Bardzo ważnym jest, aby cel był mierzalny i weryfikowalny. Im dokładniej określisz warunki pozytywnego zakończenia, tym łatwiej będzie Ci weryfikować poprawność implementacji systemu na etapie testów akceptacyjnych (końcowych testów).Warunki wstępne stanowią integralną część celu, gdyż tylko ich spełnienie daje gwarancję osiągnięcia pożądanego wyniku. Zastanów się więc za każdym razem, czy na przykład nie są potrzebne określone dane w bazie, lub posiadanie konkretnych uprawnień w systemie zanim scenariusz będzie mógł być przeprowadzony.
    3. Nie przesadzaj z rysunkami. Być może zabrzmi to dość dziwnie, ale przypadki użycia nie potrzebują jakiejkolwiek prezentacji graficznej. Jak wspomniałem, najważniejszy jest opis słowny. Sam rysunek (graf) może stanowić swego rodzaju spis treści przypadków użycia, ułatwiać odszukanie określonych elementów. Na rysunku łatwiej też pokazać zależności między przypadkami użycia (zawieranie, generalizacja). Diagram przypadków użyciaPamiętaj jednak, że jeżeli prezentujesz opis przypadków osobom nieznającym notacji UML, taki diagram może być wręcz mylący. Duża liczba połączeń, strzałek i etykiet może wprowadzać czytelnika w zakłopotanie. Dla przykładu, spójrz na załączony obok diagram 
      (żródło:
      An Automatic Subsystem Grouping Scheme using Use Case Dependency Graph for Large Complex Systems; Nanchaya Khrueahong and Wiwat Vatanawood) Czy myślisz, że osoba bez przygotowania analitycznego zechce w ogóle spojrzeć na taki diagram? Zamiast rysować – opisuj a jeżeli chcesz przedstawić diagram, to wydziel mniejsze części i przygotuj proste schematy.
    4. Stosuj prostą forma zdań Wyobraź sobie taki opis jednego z kroków przypadku użycia: “Użytkownik wprowadza 4-cyfrowy kod PIN, który umożliwia zalogowanie od systemu, po czym otwiera się okno do zarządzania transakcjami, które można dowolnie filtrować a także utworzyć nowy wpis wybierając odpowiednie opcje z menu”. Co sądzisz o takim opisie? Czy jest on czytelny? Opisując kroki przypadku użycia zawsze używaj krótkich zdań. Pamiętaj o zależności – jedna czynność, jedno zdanie. Jest to o tyle ważne, że dzięki temu będziesz mógł w łatwy sposób połączyć konkretny krok z alternatywnymi ścieżkami. Powiedzmy, że w przytoczonym przykładzie chciałbyś dodać scenariusz obsługujący błędny kod PIN. Przy tak rozbudowanej formie, za każdym razem potrzebujesz odwołać się do pełnej ścieżki logowania i zarządzania transakcjami, co jest zdecydowanie nadmiarowe i kłopotliwe dla czytelników.
    5. Wskazuj aktora odpowiedzialnego za każdą czynność. Tym razem przeanalizuj taki opis: “Kiedy wysłane zostanie błędne zapytanie, odpowiedź będzie zawierała dokładny kod błędu”. Jak podoba Ci się taki opis? Chociaż jest on krótki i dotyczy tylko jednego tematu, to posiada zasadnicze wady. Nie wiadomo kto wysyła zapytanie i kto odpowiada. Prawidłowo napisany przypadek powinien wyglądać na przykład tak: “System księgowy wysyła błędne zapytanie do modułu kadrowego. Moduł kadrowy wysyła dokładny kod błędu.” Pisząc przypadek użycia wczuj się w rolę komentatora sportowego – zaczynaj każde zdanie od informacji “kto jest przy piłce”. Dzięki temu zdecydowanie zwiększysz czytelność scenariuszy użycia.
    6. Nie staraj się opisać całego systemu. Jak już zostało wspomniane, nie jest zalecane opisywanie całego systemu za pomocą przypadków użycia. Z uwagi na to, że dokumentacja tego typu powstaje często na samym początku projektu, przed przygotowaniem specyfikacji interfejsu użytkownika, nie jest zalecane stosowanie niskopoziomowych szczegółów implementacyjnych. Przykładowo, opis: “Użytkownik naciska przycisk ‘Sprawdź szczegóły’ w wyniku czego system wyświetla tabelę zawierającą następujące kolumny…”. Jest to zdecydowanie zbyt niski poziom, który odciąga uwagę od istoty samego problemu, który dany przypadek rozwiązuje. W początkowym etapie realizacji projektu można też spodziewać się częstych zmian w interfejsie, które spowodują konieczność uciążliwych aktualizacji dokumentacji.
    7. Stosuj krótkie przypadki – zawieraj połączeniaWg Alistair Cockburn’a, specjalisty w kwestii przypadków użycia, każdy taki opis powinien zawierać maksymalnie 10 kroków. Taka struktura pozwala zachować przejrzystość, ułatwia czytanie i zarządzanie dokumentacją. Co zrobić w sytuacji, gdy scenariusz wygląda na bardziej złożony? Odpowiedzią są zależności, z których najpopularniejsza to zawieranie przypadków użycia (include) oraz rozszerzanie (extend). Wyobraź sobie, że chcesz opisać wszelkie czynności możliwe do wykonania na liście faktur. Pierwszym krokiem jest zwykle wyszukanie odpowiedniej faktury. Kolejnym może być usunięcie, kopiowanie, drukowanie itp. Jeżeli każdą z tych czynności chciałbyś opisać w osobnym przypadku, to zalecane jest przygotowanie wspólnego scenariusza – “wyszukaj fakturę” a następnie wykorzystanie zależności zawierania. Na schemacie zaprezentujesz to w sposób pokazany na załączonym diagramie Zawieranie przypadków użycia Natomiast w opisie tekstowym wystarczy że dodasz stwierdzenie typu: “Użytkownik wyszukuje fakturę zgodnie z opisem w ‘UC-Wyszukaj fakturę’” Takie rozwiązanie ma bardzo istotną zaletę. Powiedzmy, że zmienia się funkcjonalność wyszukiwania faktur. Jeżeli opis wyszukiwarki byłby skopiowany do wielu powiązanych przypadków, to teraz czekałoby Cię ciężkie zadanie przeszukania dokumentacji i aktualizowania wielu elementów. W przypadku gdy ta czynność jest “zawierana”, aktualizujesz tylko jedno miejsce! W analogiczny sposób korzystaj z rozszerzania przypadków użycia, co stanowi doskonałe wsparcie w trakcie rozwijania systemu, kiedy nie chcesz modyfikować głównego scenariusza a tylko dodać nową, opcjonalną funkcję. Szczegółowe informacje na temat zależności między przypadkami znajdziesz w opisie notacji UML. Najważniejsze abyś pamiętał o stosowaniu krótkich opisów, wspieranych zależnościami. Dzięki temu utrzymanie spójności i czytelności dokumentacji będzie dużo łatwiejsze.
    8. Pamiętaj o ścieżkach alternatywnych. 
      Kiedy już opisałeś podstawowe ścieżki obsługi systemu, warto zastanowić się nad alternatywnymi sposobami użycia. Powiedzmy, że przygotowałeś opis funkcjonalności dodawania nowej firmy do bazy systemu CRM, w którym użytkownik otwiera formularz i uzupełnia dane. Twój system pozwala jednak również importować znaczną część powszechnie dostępnych informacji, na podstawie wprowadzonego numeru NIP. Jest to niewątpliwie ważna funkcjonalność, która powinna mieć odzwierciedlenie w przypadku użycia. Do podstawowego scenariusza dodaj sekcję “scenariusze alternatywne” i wprowadź tam inne ścieżki, wskazując dokładnie miejsce rozpoczęcia i zakończenia takiego scenariusza.
      Przykładowo, jeżeli scenariusz główny byłby:

      1. Użytkownik loguje się do systemu.
      2. Użytkownik otwiera formularz dodawania nowej firmy.
      3. System prezentuje pusty formularz.
      4. Użytkownik wprowadza NIP oraz nazwę firmy.
      5. Użytkownik wybiera opcję zapisu danych w bazie.
      6. System potwierdza zgodność danych i zapisuje nowy rekord.

      To scenariusz alternatywny wyglądałby następująco:

      4.a. Użytkownik wybiera opcje importu dodatkowych danych na podstawie numeru NIP
      4.a.1 System pobiera ogólnodostępne dane firmy, takie jak adres, czy dane kontaktowe
      4.a.2 System wyświetla informację o statusie operacji (zakończona sukcesem czy nie).
      4.a.3 Użytkownik kontynuuje scenariusz zgodnie z opisem z kroku 5.

      Co sądzisz o takiej formie rozszerzania scenariusza głównego, czy jest ona czytelna?

    9. Obsłuż sytuacje problemowe. Znane jest powszechnie stwierdzenie, według którego jeżeli coś może pójść źle, to tak na pewno się stanie. I to zwykle w najmniej spodziewanym momencie. Przygotuj się na potencjalne problemy, wyszukując możliwe błędy już na etapie projektowania systemu. Wracając do przykładu z pkt 8. wyglądałoby to na przykład tak:Scenariusz obsługi błędu:
      6.a. System wykrywa niepoprawny format numeru NIP.
      6.a.1 System wyświetla komunikat wskazujący na konkretną przyczynę błedu.
      6.a.2 Użytkownik potwierdza komunikat (zamyka)
      6.a.3 Użytkownik koryguje dane i kontynuuje scenariusz zgodnie z opisem z kroku 5.

      Jeżeli nawet nie wiesz jak powinien zachować się system w sytuacji problemowej, to wypisz taki scenariusz i oznacz go jako “to-do”. Następnie przeanalizuj go z odpowiednimi osobami z zespołu technicznego czy biznesowego, które pomogą znaleźć odpowiednie rozwiązanie.

    10. Refaktoruj, zmieniaj, aktualizuj.W dzisiejszych czasach należałoby zaktualizować powiedzenie, iż pewna jest tylko śmierć i podatki. Pojawia się trzeci czynnik – zmiany.Jeżeli napisałeś idealne scenariusze użycia, to teraz mam dobrą wiadomość – prawdopodobnie za chwilę będziesz je zmieniał. Od zmian nie ma ucieczki i tylko od Ciebie zależy, jak dobrze przygotujesz swoją dokumentację na obsługę zmian.Wszystko co było wcześniej napisane ma ułatwić zarządzanie dokumentacją i jeżeli zastosujesz się do tych reguł, to na pewno przejdziesz przez proces modyfikacji dużo sprawniej.Powodzenia!

     


Dodaj komentarz

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

 

2 komentarzy do “10 wskazówek jak skutecznie pisać przypadki użycia