Przypadki użycia, a scenariusze użytkownika
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:
- Nowy komputronik.pl i wyszukiwarka która zawodzi
- Wątek usability w katastrofie smoleńskiej?
- Użyteczność, a dostępność
- Interfejs użytkownika jako nośnik reklamy i inne pomysły WP
- „Więcej” to nie lepiej – o efektach ubocznych zmian w interfejsie
Zapisz się na kanał RSS bloga i dołącz do ponad 1500 czytelników RSS.
18 maja 2009 15:23
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