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 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.