Historie użytkowników można formułować jako wymagania klientów. Klienta tak naprawdę nie interesuje, jak oprogramowanie będzie działać w środku. Klient w prostych zdaniach definiuje poszczególne interakcje, jakie będzie wykonywał system. Można więc powiedzieć, że Historie użytkowników mówią o tym, cosystem powinien zrobić, a nie o jak powinien to zrobić.
Historie użytkowników są podobne do przypadków użycia znanych z metodologii oprogramowania. Pomimo znacznego podobieństwa do siebie, różnica polega na tym, że Historie użytkowników są mniej złożone niż Przypadki użycia. Historie użytkowników opisują mniejszy zakres zadań. Często zapisywane są one jedynie na małych kartkach w formie analogowej lub cyfrowej. Przypadek użycia jest bardziej złożony, sformalizowany i z niego tworzone są scenariusze, które następnie są wdrażane.
Prostota Historii użytkowników ma wiele zalet. gdy do systemu wpłynie nowe żądanie, definiujemy to zadanie jako nową historię użytkownika, którą następnie wdrażamy. Przyczynia się to do podziału systemu na małe części. Dzięki temu system jest łatwo otwarty na nowe zmiany.
Historia użytkownika składa się z dwóch obowiązkowych części:
Rola: rola określa, kto będzie korzystał z danej historii użytkownika. Jest to bardzo podobne do przypadku aktora w przypadkach użycia.
Cel: tutaj krótko opisano czynność wykonywaną przez użytkownika systemu.
Historia użytkownika ma także trzecią – opcjonalną część, którą jest korzyść. Korzyść mówi, dlaczego chcemy wdrożyć historię użytkownika. Chociaż definicja użyteczności jest opcjonalna, ma dwa ważne uzasadnienia:
Oto przykładowa historia użytkownika: Aby osiągnąć [korzyści] jako [rola], chcę [cel]
Jak widać na przykładzie, historie użytkowników są bardzo proste. Nie mówi o tym, jak historia będzie testowana. Czasami historie użytkowników kojarzone są z tzw kryteria akceptacji, które określają, w jaki sposób będziemy testować daną historię.
Marián Knězek