Skocz do linków, Skocz do treści

Przypadki użycia, a scenariusze użytkownika

11 maja 2009 22:00. Autor: Robert Drózd. Komentarze (1) »

Zdarza się, że przedstawiając klientowi swój projekt (czy też jego pierwszą część) zaczynam od profili użytkowników i powiązanych z nimi scenariuszy. I tu zdarza się opozycja – przecież nasi projektanci i architekci systemowi już zrobili use casy! I to znacznie więcej! Po co powtarzać robotę wykonaną przez kogo innego?!

Czym się różnią use case i user scenario? Ano, literką „r” na końcu.

Przypadek użycia to generyczny opis, przy pomocy którego przedstawiamy interakcję: użytkownik – system. Użytkownik naciska przycisk, system robi to i tamto.

Use casy powinny być zwięzłe, kompletne, napisane w sposób wykluczający sprzeczne interpretacje. Charakterystyczne dla przypadków użycia jest też to, że mówią więcej o działaniu systemu niż tym, co do działania systemu doprowadziło. Bez uwzględnienia przypadków użycia może się zdarzyć, że na ostatnią chwilę programiści będą dopisywali jakąś funkcję, bo „się o niej zapomniało”.

Scenariusz to przypadek użycia ubrany w profil konkretnej osoby, która realizuje go w swoim własnym kontekście. Dawno, dawno temu był sobie człowiek, który wskutek różnych wydarzeń potrzebował nacisnąć przycisk. A to dopiero początek historii.

Scenariusz nie musi uwzględniać wszystkich możliwych przypadków, tylko te, które są rzeczywiście dla danego użytkownika istotne. Działanie systemu interesuje nas tylko w takim stopniu, w jakim jest ono widoczne dla użytkownika: najczęściej jako rezultat. Bez uwzględnienia właściwych scenariuszy wyjdzie nam system, w którym Niezwykle Ważna Funkcja wymaga wcześniej pięciu kliknięć, a gdy już ją uruchomimy, nie jesteśmy pewni czy to już, czy jeszcze trzeba coś kliknąć.

O różnicach między przypadkami użycia i scenariuszami (z przykładami) napisano między innymi tutaj:

Jeszcze jedno: dlaczego uważam to rozróżnienie za istotne? Bo pokazuje, że języki informatyków i ludzi zajmujących się użytecznością mogą się różnić. Te same słowa: projekt, scenariusz, użytkownik – oznaczają coś zupełnie innego. Dlatego jak najczęściej trzeba upewniać się, że wszyscy się rozumieją i nie uznają pewnych określeń za oczywiste.

Podobne artykuły:

Być może zainteresują Cię następujące artykuły:

Zapisz się na kanał RSS bloga i dołącz do ponad 1500 czytelników RSS.

Zostań fanem WebAudit na Facebooku.

Komentarz - jeden samotny

Śledź komentarze do tego artykułu: format RSS
  1. Marcin Nowak

    Witam,

    zgadzam sie co do tego, ze jezyk informatykow jest czesto rozny od specow od uzytecznosci o koncowych userach nie wspominajac. Czesto zdarza sie, ze informatycy/programisci zakladaja z gory ze uzytkownik nie bedzie na tyle bezmyslny zeby cos zrobic/nie-zrobic (dla nich wiele spraw jest oczywistych – stad zakladaja, ze dla innych pewne rzeczy sa rownie oczywiste).

    Druga sprawa, ktora nasunela mi sie po lekturze tego postu to zagadnienie skutecznej komunikacji – jak widac nawet specjalisci z jednej branzy roznie postrzegaja te same terminy.

    Pozdrawiam

Zostaw komentarz

W komentarzu można (choć nie trzeba) używać podstawowych znaczników XHTML. Komentarze zawierające w podpisie słowa kluczowe mogą zostać potraktowane jako spam i usunięte.