Skąd się wzięły przypadki użycia?
Na swoim blogu Ivar Jacobson pisze o tym skąd się wziął pomysł na zapisywanie wymagań za pomocą przypadków użycia. Jacobson pisze:
"In 1986, Use Case was the solution to the problem that traditional functional specifications were immense and not testable. To start from the users and find their different use cases made the specifications understandable, while we also at the same time found the test cases. The result was a good way to do test-driven development, now being popular in agile teams."
Polecam zresztą cały najnowszy post Jacobsona, w którym pisze o tym, że problem jest ważniejszy niż samo rozwiązanie (o czym wspominałem wcześniej tutaj).
Darmowy webinar o tworzeniu modeli przypadków użycia
Na blogu Bridging the Gap możecie się zarejestrować na darmowy webinar dotyczący tworzenia modeli przypadków użycia. Webinar jest zaplanowany na wtorek 04. maja na godzinę 18:00 EST, co oznacza 01:00 naszego czasu (będzie to już środa), (więc jeśli ktoś cierpi na bezsenność to) może warto skorzystać?
Echa konferencji Requirements Engineering 2009
W zeszłym roku miałem szansę brać udział w jednej z najbardziej prestiżowych konferencji poświęconych inżīnierii wymagań Requirements Engineering. To właśnie podczas tej konferencji zdecydowałem się założyć tego bloga, którego jednym z celów miało być omówienie najciekawszych zagadnień omawianych tamtego wydarzenia. Minęło pół roku od powstania bloga, a ja jeszcze nie napisałem ani słowa na temat konferencj - czas to zmienić.
Zacznę może od pierwszej prezentacji zaproszonej, którą poprowadził pan Dave West z Forester Research. Prezentacja dotykała problemów zwinności oraz wymagań, a pan West dzielił się wynikami różnorodnych ankiet i badań jakie prowadzone są przez Forester Research. Oto kilka fragmentów z notatek, które udało mi się zrobić:
- 1298 profesjonalistów z dziedziny IT odpowiadało na pytanie która z istniejących metodologii jest najbliższa temu, co robicie w waszej firmie? 31% podejście zwinne (zbliżone do RUP); 21# model kaskadowy; 12% podejście zwinne.
- Na pytanie, jakie są doświadczenia firm z wykorzystaniem podejść zwinnych odpowiedzi były następujące: 38% określiło, że mają wykoształcone dojrzałe podejście do zwinności; 30,8% stwierdziło, że są w połowie wdrażania podejść zwinnych; 25% dopiero zaczęło wprowadzać metodyki zwinne; a 5% dopiero zaczyna oceniać zalety takich podejść.
- Dlaczego ludzie wybierają zwinne metodyki? 63% - bo dają możliwość wprowadzenia zmian podczas tworzenia projektów; 60% - pozwalają zwiększyć jakość projektów; 60% - dają możliwość częstszych wydań; 55% - pozwalają na większość przewidywalność wydań; 45% - zwiększają motywację członków zespołów.
- Główne problemy związane z wymaganiami to: wymagania szybko stają się nieaktualne; wymagania to zwykle długie dokumenty, których nikt nie chce czytać; wymagania opisują zwykle rozwiązanie, a nie problem; zbieranie i analiza wymagań zabierają zbyt dużo czasu. Dodatkowe utrudnienia sprawiają: brak czasu po stronie klienta; wiele osób zainteresowanych tworzonym system, które często reprezentują sprzeczne interesy; słabe umiejętności komunikacyjne po stronie zespołu wytwórczego.
- Analityk powinien: mieć możliwość samodzielnego podejmowania decyzji; znać dziedzinę biznesową; dobrze współpracować z zespołem programistów.
- 81 profesjonalistów powiedziało, jakie mechanizmy z inżynierii wymagań wykorzystują najczęściej: 82% specyfikuje wymagania funkcjonalne; 62% wykorzystuje przypadki użycia; 57% tworzy prototypy; 46% specyfikuje wymagania pozafunkcjonalne; 37 % wykorzystuje warsztaty; 17% wykorzystuje wiki.
- Głównym narzędziem ankietowanych 230 analityków jest MS Office.
- Zalecenia: specyfikuj tylko to co będzie zaimplementowane; dobrze dobieraj poziom szczegółowości, staraj się estymować pracochłonność na etapie zbierania wymagań; pozwól wymaganiom ewoluować razem z powstającą implementacją; ciągle dostosowuj wykorzystywane techniki do zmieniającej się sytuacji.
- Pamiętajcie o wykorzystywaniu narzędzi i modeli graficznych.
W przygotowaniu dalsze relacje z Requirements Engineering 2009.
Kompletny SRS na wyciągnięcie ręki…i to za darmo!
W zeszłym roku zostaliśmy zaproszeni (jako zespół Inżynierii Oprogramowania na Politechnice Poznańskiej) do współpracy przez Wydział Informatyki Urzędu Miasta Poznania nad dokumentem zawierającym wskazówki dotyczące zbierania wymagań dla projektów informatycznych. Jednostki samorządowe objęte są przepisami dotyczącymi zamówień publicznych, dlatego też najczęściej muszą one same muszą zadbać o zebranie wymagań dla systemów informatycznych, wymagania te później są podstawą ogłoszonego przetargu na realizację systemu.
Efektem naszej współpracy są 3 dokumenty:
- wskazówki dotyczące dokumentowania wymagań dla systemów informatycznych
- przykładowa pełna specyfikacja wymagań dla systemu archiwizacji elektronicznej
- wzorzec dla dokumentu specyfikacji wymagań (na bazie standardu IEEE 830:1998)
Dzięki uprzejmości Wydziału Informatyki Urzędu Miasta Poznania wszystkie 3 dokumenty są publicznie dostępne. Zapraszam tutaj (znajdziecie tam archiwum zip ze wspomnianymi wcześniej dokumentami oraz dodatkowy dokument zawierający szczegóły dotyczące zasad rozpowszechniania naszego opracowania).
Mam nadzieję, że zarówno zebrane przez nas wskazówki jak i przykład pozwolą Wam jeszcze efektywniej zbierać wymagania w Waszych projektach. Jeśli będziecie korzystali z tych dokumentów to dajcie znać co o nich sądzicie i czy się Wam przydały. Jesteśmy bardzo ciekawi Waszych opinii!
Oczywiście jeśli jesteście zainteresowani współpracą nad podobnym projektem, lub macie jakikolwiek problem z wymaganiami w Waszych projektach to również dajcie koniecznie znać.
Jak klient może się stać partnerem dzięki zwinności?
Znalazłem dzisiaj dość ciekawy wywiad a Alistairem Cockburnem (autorem wielu publikacji na temat przypadków użycia, m.in. "Writing Effective Use Cases") dotyczący jego poglądów na temat metodyk zwinnych. W wywiadzie pojawia się tez pytanie w jaki sposób zwinne podejście może pomóc w naszych relacjach z klientem, oto odpowiedź:
Explain how customers become partners?
In the best cases, the business asks the clients what they want in such a way that the clients come to help steer the project. After each (frequent) delivery, the clients converse with the business in such a way that they start to become discussion partners and co-steer the product’s development. Obviously, this works better with small client bases, and is harder to accomplish (and maybe less meaningful) with large consumer bases, as is the case with shrink-wrapped products and consumer devices.
Cały wywiad znajdziedzie tutaj.
Benchmark dla przypadków użycia
Które przypadki użycia wybrać do badań?
W naszym zespole zajmującym się Inżynierią Oprogramowania na Politechnice Poznańskiej skupiamy naszą uwagę w dużej mierze na analizie przypadków użycia. W ramach naszych prac tworzymy metody oraz narzędzia pozwalające analizować wymagania z różnych punktów widzenia. W pewnym momencie pojawił się problem: na jakich danych powinniśmy testować nasze metody i narzędzia? Wiadomo, że jeśli będziemy testować na danych spreparowanych przez nas to wyniki będą niemiarodajne. Moglibyśmy wziąć też pod uwagę specyfikacje stworzone w rzeczywistych projektach.Powstaje wówczas jednak pytanie: które specyfikacje powinniśmy wybrać? Doszliśmy więc do wniosku, dlaczego by nie przeanalizować dostępnych nam przypadków użycia i nie stworzyć pewnego rodzaju specyfikacji referencyjnej, która jak najwierniej odzwierciedlałaby rzeczywisty świat wymagań zapisanych w postaci przypadków użycia?
Benchmark 1.0
Aby stworzyć taki swoisty benchmark dla narzędzi badających przypadki użycia przeanalizowaliśmy 432 przypadki użycia z 11 dostępnych nam specyfikacji wymagań. Cześć naszej analizy możecie znaleźć tutaj (resztą wyników mogę udostępnić zainteresowanym osobom, w takiej sytuacji proszę o kontakt). Samą specyfikację, która powstała w wyniku tych prac znajdziecie tutaj. Jak powstał nasz benchmark? Każdy z przypadków użycia był przez nas badany m.in. pod kątem liczby kroków, liczby warunków początkowych, liczby kroków wykonywanych przez budowany system, itp. Następnie po takiej analizie zebraliśmy wyniki ze wszystkich projektów, co pozwoliło nam stworzyć obraz "przeciętnej" specyfikacji wymagań. Na tej podstawie stworzyliśmy przykładową specyfikację zachowującą właściwości specyfikacji "przeciętnej".
Benchmark 2.0
Po kilku miesiącach postanowiliśmy rozszerzyć naszą analizę o 5 kolejnych projektów (524 przypadki użycia łącznie), dodaliśmy również drugi wymiar do naszych badań. Za pierwszym razem wzięliśmy pod uwagę jedynie charakterstki ilościowe (liczba kroków, liczba rozszerzeń, etc.), tym razem dodatkowo analizowaliśmy różnież charakterystyki jakościowe (czy w każdym kroku jest wskazany aktor? czy używana jest czynna forma czasownika? etc.) i w ten sposób powstały dwie wersje referencyjnej specyfikacji: jedna zawierająca wyłącznie wyniki analizy ilościowej oraz druga zawierająca zarówno wyniki analizy ilościowej jak i jakościowej. Częściowe wyniki analiz możecie znaleźć tutaj, po resztę trzeba niestety poczekać dopóki nasz artykuł nie zostanie opublikowany. Benchmark w wersji ilościowej znajdziecie tutaj, a ten z dodatkową analizą jakościową tutaj.
Chcesz nam pomóc?
A może miałbyś ochotę podzielić się z nami swoimi przypadkami użycia? Jakość naszej pracy badawczej w dużej mierze zależy od tego na jakich danych operujemy. Czym więcej mamy danych rzeczywistych tym bardziej dopasowane metody i narzędzia możemy tworzyć. Zatem jeśli masz możliwość podzielenia się z nami wymaganiami ze swoich projektów to śmiało napisz do mnie maila! Oczywiście gwarantujemy pełną poufność danych, a jeśli trzeba to możemy również podpisać odpowiednie umowy.
10 potencjalnych problemów z przypadkami użycia
Mimo iż przypadki użycia są najpopularniejszą notacją do zapisu wymagań funkcjonalnych, to nie oznacza to, że nie niosą one za sobą różnych pułapek. Pani Susan Lilly w swoim artykule "Use Case Pitfalls: Top 10 Problems from Real Projects Using Use Cases" opisuje 10 potencjalnych problemów, które mogą pojawić się, gdy korzystamy z przypadków użycia, oto one:
- Zakres systemu jest niezdefiniowany lub niespójny. Często wykorzystujemy przypadki użycia do zapisu wymagań na różnych poziomach (biznesowym, użytkownika, systemowym), pozwala to na opis z różnym poziomem szczegółowości. Problem pojawia się jednak, gdy na diagramach przypadków użycia zaczynamy mieszać ze sobą przypadki użycia z różnych poziomów - prowadzi to do niejasności i może spowodować kłopoty ze zrozumieniem wymagań przez osoby zaangażowane w projekt.
- Przypadki użycia zapisane są z punktu widzenia systemu, a nie z punktu widzenia użytkownika. Jako informatyce często zdarza nam się opisywać wymagania w kontekście tego, co system powinien robić, przypadki użycia jednak służą innym celom, ich zadaniem jest opisać intencje użytkowników. Dlatego też zawsze pisząc przypadki użycia staraj się skupić na tym, co chce osiągnąć użytkownik, a nie na tym, co system będzie robił, aby umożliwić realizację celu użytkownika.
- Nazwy aktorów są niespójne. Często wykorzystujemy różne nazwy dla aktorów pełniących te same role, lub też wykorzystujemy te same albo podobne nazwy dla opisu różnych ról. Aby unikąć tego problemu należy na samym początku prac zastanowić się jakich aktorów możemy wyróżnić w naszym systemie, nadać im unikalne identyfikatory, nazwy oraz opis.
- Zbyt dużo przypadków użycia. Duża liczba przypadków użycia może spowodować trudności w czytaniu SRSa, trudności w zrozumieniu i kłopoty w komunikacji. Staraj się zapewniać odpowiednią granularność przypadków użycia. Zastanów się, czy jakichś przypadków użycia nie możesz połączyć ze sobą? Usuń przypadki użycia, które nie wnoszą dodatkowej wartości do opisu wymagań.
- Relacje aktor-przypadek użycia przypominają pajęczą sieć. Jeśli na diagramach połączeń między aktorami i przypadkami użycia jest bardzo dużo, to powinno dać nam to do myślenia. Może aktorzy zdefiniowani są zbyt szeroko? Czy można wyodrębnić bardziej szczegółowych aktorów? A może masz zbyt wielu aktorów i wyodrębnienie nadrzędnego aktora uprościło by diagram?
- Specyfikacja jest za długa. Sprawa wygląda podobnie jak w punkcie 4-tym. Zastanów się, czy niektórych wymagań nie możesz połączyć ze sobą? Pamiętaj oczywiście, że czytelność i jednoznaczność jest naszym nadrzędnym celem, więc jeśli skrócenie specyfikacji miałoby wpłynąć na któryś z tych elementów to lepiej nie wprowadzaj takich zmian.
- Specyfikacja jest myląca i niejasna. Możliwe, że Twoim przypadkom użycia brakuje kontekstu? Zastanów się, czy określiłeś zakres wymagań i cel projektu? Może warto jest dodać sekcję wyzwalaczy i krótki opis do każdego przypadku użycia? Może Twoje przypadki użycia przypominają program komputerowy? Pamiętaj o stosowaniu dobrych praktyk, które pozwolą Ci uniknąć niektórych pułapek.
- Przypadki użycia niewłaściwie określają możliwości użytkowników. Czasem może się zdarzyć, że połączenia między aktorami a przypadkami użycia będą niepoprawnie wskazywać, jaką akcję może wykonywać poszczególny aktor. Zastanów się zawsze, czy dany aktor jest w pełni uprawniony do wykonania danego przypadku użycia? Jeśli móże wykonać go tylko w części, to może należałoby odpowiednio podzielić taki przypadek użycia na mniejsze bardziej szczegółowe części?
- Klient nie rozumie przypadków użycia. Zdarza Ci się zapomnieć, że klient może nie znać przypadków użycia? Zastanów się, co taki klient może zrozumieć ze specyfikacji, jeśli dostanie w niej zestaw przypadków użycia właśnie? Pamiętaj, aby zawsze przed rozpoczęciem pracy z klientem zapoznać go z notacją przypadków użycia, wytłumacz dlaczego przypadki użycia będą dobre dla wymagań jego systemu i w jaki sposób powinien je czytać. Może napisz razem z klientem kilka pierwszych przypadków użycia i spokojnie wytłumacz mu wszystkie niejasności?
- Przypadki użycia nie są nigdy skończone. Jeśli Twoje przypadki użycia są pisane na podstawie (lub chociaż z zamysłem) interfejsu użytkownika, to za każdym razem, gdy będziesz zmieniał interfejs prawdopodobnie będziesz też musiał zmienić przypadki użycia. Staraj się unikać szczegółów interfejsu użytkownika w swoich przypadkach użycia. Pamiętaj też o odpowiedniej analizie przypadków użycia - najpier zidentyfikuj procesy biznesowe, a później wszystkie przypadki użycia poziomu użytkownika. Zastanów się i zapisz scenariusze główne, a na końcu dodać rozszerzenia, scenariusze alternatywne i wyjątki - pozwoli Ci to lepiej zapanować nad całą specyfikacją i nie będziesz musiał tak często wprowadzać zmian.
Jak pisać przypadki użycia?
Pisałem ostatnio o przypadkach użycia jako formie zapisu wymagań. Na końcu obiecałem, że napiszę również o kwestii jakości przypadków użycia. Zatem proszę bardzo.
Źródła wiedzy
Jeśli chcemy dowiedzieć się jak najwięcej o tym w jaki sposób zapisywać wymagania to najlepiej przyjrzeć się bliżej dwóm pozycjom książkowym: "Patterns for effective use cases" oraz "Writing effective use cases". Obie te książki w przyjazny sposób prezentują najlepsze praktyki zapisu wymagań zwracając uwagę zarówno na sam proces tworzenia specyfikacji wymagań jak i sposób zapisu poszczególnych elementów.
Podstawowe wskazówki
Na co powinniśmy zwrócić uwagę zapisując nasze wymagania w postaci przypadków użycia? Otóż:
- scenariusz główny powinien posiadać nie mniej niż 3 kroki i nie więcej niż 9 kroków. Same liczby są wartościami arbitralnymi, pozwalają jednak pamiętać z jednej strony o tym, żeby przypadek użycia nie był zbyt krótki, gdyż prawdopodobnie nie niesie on za sobą żadnej wartościowej informacji i należy się zastanowić, czy ten jeden lub dwa kroki nie można włączyć do innego przypadku użycia; z drugiej strony długi przypadek użycia może być trudny do ogarnięcia - czytelnikowi może być trudno skupić się na kilkunastu krokach scenariusza (pod koniec może już nie pamiętać co było na początku), a dodatkowo wyjątki i rozszerzenia do tak długiego scenariusza mogą być przytłaczające - kto z Was chciałby czytać przypadek użycia zajmujący kilka stron? Dodatkowym czynnikiem jest trudność z utrzymaniem tak długiego przypadku użycia - w momencie potrzeby zmiany jakiegoś wymagania to my będziemy musieli się przebić przez te długie linijki i zmienić odpowiedni fragment. Co można zrobić z za długim przypadkiem użycia? Należy zastanowić się, czy nie możemy podzielić go na kilka osobnych przypadków użycia lub wydzielić przypadek użycia wyższego poziomu.
- należy unikać opisu interfejsu użytkownika. Dlaczego? Ponieważ przypadek użycia w swoim założeniu powinien opisywać intencje aktora, a nie sposób w jaki wykonywane są akcje. Innymi słowy przypadek użycia powinien opisywać wymagania, a nie gotową implementację. Na opis interfejsu użytkownika powinno być wydzielone osobne miejsce w specyfikacji wymagań, bo czy istotne jest, że użytkownik w danym miejscu klika na link? albo na przycisk? Nie! a opis tych szczegółów powoduje, że przypadek użycia staje się dłuższy i trudniejszy do zmiany (szczególnie gdy okazuje się, że później ten "link" trzeba wszędzie zmienić na "przycisk").
- istotne jest, aby w każdym kroku jasno określony był aktor wykonujący akcję. Często autorowi przypadku użycia może wydawać się oczywiste, w jaki sposób jakaś interakcja się wykonuje, jednak dla czytelnika nie musi być już to takie oczywiste. Dla przykładu krok "Wiadomość jest wysyłana" może oznaczać, że Użytkownik (który?) wysyła wiadomość, albo, że to System wysyła wiadomość do użytkownika, albo może to dwa systemy się ze sobą komunikują i wysyłają między sobą wiadomości - tylko który z nich wysyła wiadomość w tym momencie? Jak widzicie jasne określenie aktora może być kluczowe dla zrozumienia wymagania, a przecież na tym zrozumieniu przez klienta, programistów, testerów (i pozostałe osoby związane z tworzeniem naszego oprogramowania) najbardziej nam zależy!
- warto jest zwrócić uwagę na prostotę używanego języka oraz na długość pojedynczych kroków. Pamiętajcie, że zależy nam na jednoznaczności zapisu, a każdy dodatkowy wyraz powoduje, że zdanie staje się bardziej skomplikowane i pozwala na dodatkowe możliwości interpretacji. Jeśli to możliwe starajcie się więc trzymań konstrukcji :
Podmiot + orzeczenie + dopełnienie
czyli np. "Administrator wysyła wiadomość do użytkowników premium", gdzie "Administrator" jest podmiotem, "wysyła" jest orzeczeniem", a "wiadomość do użytkowników premium" jest dopełnieniem. - spróbuj przechodzić od ogółu do szczegółu, czyli najpierw wypisz sobie wszystkie nazwy przypadków użycia, później zastanów się nad wszystkimi scenariuszami głównymi, żeby na końcu dopisać wszędzie sekcje wyjątków i rozszerzeń. Dlaczego warto stosować takie podejście? Pozwala nam ono lepiej ogarnąć całość specyfikacji i zaoszczędzić sporo energii, którą w przeciwnym przypadku wykorzystalibyśmy na początkowe szczegółowe opisywanie wymagań, które później będzie trzeba zmienić, bo ogólna koncepcja będzie inna, niż na początku nam się wydawało.
- w każdym przypadku należy skupiać się na pojedynczym celu aktora. Jeden przypadek użycia = jeden cel aktora. Jeśli zauważymy, że w danym przypadku użycia aktor osiąga kilka celi, to należy zastanowić się, czy nie lepiej byłoby podzielić dany przypadek użycia na kilka mniejszych. Dlaczego? Po pierwsze pojedynczy cel ułatwia ustalenie granicy między przypadkami użycia, co wpływa później na lepsze zrozumienie wymagań. Po drugie późniejsza weryfikacja takiego przypadku użycia jest łatwiejsza, gdyż sprawdzamy tylko jeden cel, a nie kilka.
- nazwa przypadku użycia powinna w jasny sposób określać, jaki konkretny cel osiąga aktor w danym przypadku użycia. Nazwy są tym elementem, który decyduje o tym w jaki sposób interpretujemy cały przypadek użycia, dlatego też istotne jest aby nazwy były jednoznaczne i trafnie określały, co przypadek użycia opisuje.
- poświęć dużo uwagi sekcji wyjątków i rozszerzeń. Zwykle jeśli dobrze określimy nazwę przypadku użycia czytelnik intuicyjnie będzie wiedział, jak powinien wyglądać scenariusz główny. Sprawa jest jednak trudniejsza w przypadku sytuacji wyjątkowych - jeśli nie opiszemy ich wyczerpująco, to okaże się, że programista nie zaimplementuje ich obsługi, co w konsekwencji może prowadzić do stworzenia systemu, z którego nie będzie można korzystać w sensowny sposób.
- przy zapisie wyjątków i rozszerzeń zapisuje warunki, które system może zweryfikować. Dlaczego? Wyobraź sobie przypadek użycia opisujący wypłatę pieniędzy z bankomatu. Czy jest sens zapisywać wyjątek "Klient odszedł od bankomatu"? Nie, gdyż system prawdopodobnie nie jest w stanie tego wykryć. Natomiast wyjątek "Klient nie odebrał gotówki w czasie 1 minuty" jest już łatwiejszy dla systemu do zweryfikowania, a co za tym idzie programiści mogą go zaimplementować, a testerzy odpowiednio przetestować.
- unikaj szczegółów technicznych. Jako informatyk, lub przynajmniej osoba dość mocno związana z branżą oprogramowania masz prawdopodobnie dużo szerszą wiedzę na temat technologii niż Twój klient, czemu by więc się tą wiedzą nie pochwalić? Niech klient wie, jaki jestem mądry! a co?! Ano to, że jeśli w przypadku użycia będziesz używał(a) języka technicznego, to klient większości tego nie zrozumie i dodatkowo czytanie takiej specyfikacji będzie dla niego bardzo uciążliwe. Pamiętaj, że przypadek użycia ma opisywać intencje aktora, a nie implementację systemu.
Przypadki użycia
Historia powstania przypadków użycia
Ostatnio zastanawialiśmy się, w jaki sposób można zapisać wymagania. Jednym z nieformalnych sposobów są przypadki użycia. Zostały one zaproponowane przez Ivara Jacobsona w latach 80-tych jako opis wymagań dla systemów stosowanych w branży telekomunikacyjnej. W latach 90-tych, gdy powstawały fundamenty notacji UML postanowiono włączyć pana Jacobsona do grona twórców UMLa i w ten sposób przypadki użycia znalazły swoje miejsce jako element tej właśnie notacji. Z jednej strony pozwoliło to przypadkom użycia zyskać na popularności i stać się jednym z popularniejszych sposobów zapisu wymagań (badania pokazują, że przypadki użycia i zapis scenariuszy jest wykorzystywany w ponad 50% projektów). Z drugiej strony jednak UML spowodował, że przypadki użycia zaczęły być kojarzone wyłącznie z diagramami, na których specyfikuje się aktorów oraz funkcje do jakich mają oni dostęp. Oczywiście diagramy są ważne, pozwalają one ogarnąć ogólną wizję funkcjonalności oraz zależności między przypadkami użycia. Przypadki użycia to jednak dużo więcej niż same diagramy - ich istotą są scenariusze interakcji między aktorami systemu.
Podstawowe elementy przypadków użycia
Tak jak wspomniałem powyżej głównym elementem przypadków użycia są scenariusze interakcji (zwane równieżscenariuszami głównymi), gdyż to one niosą za sobą największą wartość jeśli chodzi o wymagania. Co jeszcze w takim razie składa się na przypadek użycia? W podstawowej wersji poza scenariuszem podajemy:
- identyfikator pozwalający w jednoznaczny sposób odwoływać się do przypadku użycia,
- nazwę określającą czego dotyczy dany przypadek użycia,
- aktorów biorących udział w interakcji
- opis wyjątków oraz rozszerzeń dla scenariusza interakcji.
Z czego wynika ten ostatni element? Otóż w głównym scenariuszy podajemy pozytywny przebieg interakcji, czyli np. jeśli opisujemy zakup książki w sklepie internetowym to scenariusz główny kończy się zakupem książki (jest to tzw. "happy day scenario"). Co z przypadkami, gdy np. książki nie ma w naszym sklepie? Właśnie do takich sytuacji wykorzystywana jest sekcje wyjątków i rozszerzeń, w których możemy opisać sytuacje wyjątkowe (np. błędnie podane hasło przez użytkownika, błąd przy nawiązaniu połączenia zdalnego, itp.) oraz rozszerzenia naszego scenariusza głównego (np. gdy książki akurat nie ma w naszym sklepie, lub gdy nasz klient chce kupić więcej niż jedną książkę?).
Poniżej znajdziecie przykład przypadku użycia z wymienionymi wcześniej elementami:
Rozszerzony przypadek użycia
Poza podstawowymi elementami w przypadku użycia można zawszeń:
- wyzwalacze (ang. trigger) opisujące jakie zdarzenie może wywołać dany przypadek użycia
- warunki początkowe (ang. preconditions) określające jakie warunki muszą być spełnione, aby przypadek użycia mógł zostać wykonany
- warunki końcowe (ang. postconditions) mówiące o tym jakie warunki muszą być spełnione na końcu poprawnego wykonania przypadku użycia
- opis prezentujący skróconą wersję przypadku użycia
- wymagania dodatkowe określające wymagania, które nie zostały zawarte w scenariuszach, a są w jakiś sposób powiązane z przypadkiem użycia
- szkice ekranów prezentujące przykładowy wygląd systemu w danym kroku
- poza tym nazwisko autora przypadku użycia, datę utworzenia, datę ostatniej zmiany, wersję.
Poniżej znajdziecie nasz wcześniejszy przykład poszerzony o elementy dodatkowe:
Dlaczego przypadki użycia są fajne?
Jak widzimy przypadki użycia pisane są w języku naturalnym, co powoduje, że czytelnik nie potrzebuje specjalistycznej wiedzy, aby taki przypadek użycia zrozumieć. Dodatkowo z góry określona struktura ułatwia czytanie, gdyż każde wymagania zapisane jest w taki sam sposób. Pisanie takich przypadków również jest proste - każdy element wymagania ma swoje określone miejsce, więc dość prosto jest skupić się na każdym elemencie i opisać go osobno.
Czy to naprawdę jest takie proste?
Patrząc na powyższe przykłady może się wydawać, że w pisaniu przypadków użycia nie ma nic trudnego, gdyż korzystamy tutaj z języka naturalnego, który z łatwością pozwala nam wyrażań nasze myśli. Okazuje się, że z przypadkami użycia związana są pewne pułapki, o których należy pamiętać zapisując wymagania właśnie w taki sposób. Różne "zasadzki" oraz dobre praktyki opisane są m.in. w książkach pt. "Patterns for effective use cases" oraz "Writing effective use cases".