Niech się coś drukuje…
Zasłyszane w jednej z firm:
Programiści dostali specyfikację, w której jedno z wymagań było opisane szkicem ekranu z przyciskiem "Drukuj". Dociekliwy programista zaczął się zastanawiać, co ma przez to rozumieć? Drukowanie na drukarce? Drukowanie do pliku tekstowego? Może do PDF'a? Jakiś wzorzec ma być wybrany? I najważniejsze: co w zasadzie ma być wydrukowane? Na szczęście programista okazał się proaktywny, sięgnął po słuchawkę i zadzwonił do analityka odpowiedzialnego za to wymagania. Mniej więcej tak wyglądała ta rozmowa:
- Ja w sprawie wymagania ABC123.
- Słucham, w czym problem?
- Zastanawiam się, co, w jaki sposób i na czym ma być wydrukowane. Niestety z zapisanego wymagania to nie wynika.
- Hmmm...no niech się coś po prostu tam drukuje.
Czy tylko mi ręce opadają?
A najczęściej używana notacja to…
Patrząc przez ramię
Ile razy zastanawialiście się, w jaki sposób modelować Wasze wymagania? Która notacja będzie najlepsza? Który sposób modelowania powinienem\am wybrać? Ile razy zaglądaliście przez ramię koleżanki lub kolegi, żeby zobaczyć jak oni to robią? Czy nie fajnie by było spojrzeć przez ramię prawie 200 innych analityków i zobaczyć, z czego oni korzystają w swojej pracy z wymaganiami?
Ale jak to zrobić?
Na szczęście panowie Colin J. Neill oraz Phillip A. Laplante z Penn State University postanowili dowiedzieć się czegoś więcej na temat najczęściej stosowanych praktyk inżynierii wymagań. Stworzyli internetową ankietę, która składała się z 22 pytań i zaprosili do jej wypełnienia prawie 2000 osób (głównie absolwentów PennState University). Odpowiedzi udzieliły 194 osoby (m.in. z takich firm jak SAP, Boeing, Dupont, Simens Medical Systems) i odpowiedzi te były podstawą artykułu "Requirements Engineering: The State of the Practice", który ukazał się w 2003 roku.
A zwycięzcą jest...
Jako, że cały dokument jest dostępny tutaj, to nie będę rozwodził się nad poszczególnymi wnioskami, tylko przedstawię najciekawsze (moim zdaniem) wyniki, i tak:
- 60% osób biorących udział w ankiecie stosowało w jakimś stopniu prototypowanie.
- 35% respondentów powiedziało, że wykorzystują podejście kaskadowe.
- W projektach, które trwały dłużej niż dwa lata najpopularniejsze było podejście iteracyjne.
- 33% osób stwierdziło, że nie korzystają z żadnej metodologii
- 51% respondentów powiedziało, że stosują nieformalne sposoby zapisu wymagań, 27% sposoby półformalne, a 7% stosują notacje formalne.
- W 59% przypadków stosuje się inspekcje, jako sposób na podniesienie jakości wymagań.
- 52% osób stwierdziło, że w ich firmach za mało uwagi poświęca się na inżynierię wymagań.
- Ponad 50% osób wykorzystuje przypadki użycia i/lub scenariusze do zapisu wymagań.
Tak wyglądają wyniki badań po drugiej stronie oceanu, ciekaw jestem jak to wyglądałoby u nas? Bylibyście zainteresowani wzięciem udziału w takim badaniu? Dajcie znać w komentarzach lub mailowo.
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ć.
15 pytań
Na blogu firmy IAG można znaleźć ciekawy post z piętnastoma pytaniami, które warto zadań podczas sesji zbierania wymagań. Oto one:
- Czy mógłbyś podać więcej szczegółów, tak abym mógł lepiej Cię zrozumieć? Dzięki temu uzyskami więcej danych oraz lepiej zrozumiemy punkt widzenia rozmówcy.
- Czy mógłbyś podzielić się ze mną swoim rozumieniem tego, o czym przed chwilą mówiliśmy? Unikniemy dzięki temu nieporozumień wynikających z błędnego rozumienia drugiej osoby.
- Czy mógłbyś pomóc mi i zaklasyfikować te punkty? Pomoże nam to zorganizować fakty dotyczące wybranego tematu.
- Czy moglibyśmy porównać to stwierdzenie do tego, o czym mówiliśmy wcześniej? Pozwoli nam to lepiej zrozumieć rozmówcę, a także odkryć podobieństwa oraz różnice w wymaganiach.
- Czy mógłbyś zdefiniować ten termin, abym mógł go lepiej zrozumieć? Pomoże nam to utworzyć słownik pojęć i ustanowić wspólny język.
- Czy mógłbyś opisać przykładową sytuację, w której miałoby to zastosowanie? Dzięki odpowiedzi na to pytane możemy odkryć procesy, scenariusze kierujące naszym oprogramowaniem oraz warunki, jakie musi ono spełniać.
- Czy możemy porozmawiać o ograniczeniach oraz konsekwencjach tego rozwiązania? Pozwoli nam to lepiej zrozumieć omawiane wymagania.
- Możesz mi wyjaśnić, jak doszedłeś do takiego wniosku? Wyjaśnimy dzięki temu stopień wspólnego zrozumienia tematu.
- Czy możesz mi podać przykład, w jaki miałoby to działać? Dzięki przykładom lepiej zrozumiemy wymagania.
- Co jeszcze? Żeby o niczym nie zapomnieć.
- Jak rozumiesz (...)? Aby sprawdzić, czy myślimy w taki sam sposób.
- Dobra uwaga! Czy możemy ją dodać do listy spraw otwartych? Pozwoli nam to wrócić do głównego wątku rozmowy.
- Innymi słowy chodzi o to (...), tak? W taki sposób sprawdzisz, czy wszystko dobrze zrozumiałeś.
- Czy moglibyśmy przejrzeć punkty, które do tej pory przerobiliśmy? Pozwoli nam podsumować dotychczasową rozmowę.
- W jaki sposób możemy zweryfikować, czy na pewno o to chodzi? Uzyskamy dzięki temu informację, o źródle wymagania i dowiemy się, czy na pewno ma ono sens.
Spróbujcie wykorzystać te i podobne pytania podczas swoich kolejnych spotkań z klientami. Jestem ciekawe efektów, które uzyskacie.
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.
Nie podmieniaj!
Co ze spójnością?
Co z tym zrobić?
Nie podmieniaj!
Podpowiedzi
Grając zgodnie z zasadami
"Grając zgodnie z zasadami" - tak nazywa się jeden z rozdziałów w książce Karla Wiegers "Software Requirements"
Każda organizacja działa zgodnie z pewnym zestawem ustalonym wewnętrznie lub narzuconych z zewnątrz zasad, przepisów i standardów, np. organizacje bankowe muszą działać w ramach obowiązujących przepisów prawa bankowego. Gdy tworzymy oprogramowanie dla naszego klienta, to warto zastanowić się jakimi regułami kieruje się biznes klienta, tak aby nasze oprogramowanie było z nimi zgodne.
Typy reguł biznesowych
- fakty - proste stwierdzenia, które są zawsze prawdziwe dla biznesu. Często opisują one relacje między istotnymi obiektami biznesowymi. Inne reguły mogą odwoływać się w swoich definicjach do faktów. Same fakty rzadko przekładają się bezpośrednio na wymagania funkcjonalne, są natomiast często częścią modelu danych.
Przykłady:
Każdy kontener z materiałami chemicznymi ma indywidualny identyfikator.
Każde zamówienie musi mieć określoną cenę. - ograniczenia - jak sama nazwa wskazuje ograniczają akcje , które system lub użytkownik może wykonywać.
Przykłady:
Pożyczkobiorca, który ma mniej niż 18 lat musi mieć pisemną zgodę rodzica lub opiekuna prawnego.
Stały czytelnik może mieć maksymalnie 10 książek wypożyczonych.
Użytkownik ma dostęp do dokumentów pounych jedynie jeśli uzyskał certyfikat poufności w ciągu ostatnich 12 miesięcy.
Pracownicy załóg linii lotniczych muszą mieć zagwarantowany 14-godziny odpoczynek po każdym locie. - wyzwalacze - reguły, które pod wpływem określonych zdarzeń lub w określonych warunkach wywołują specyficzne akcje.
Przykłady:
Jeśli produkt straci ważność w ciągu najbliższych 30 dni powiadom osobę przypisaną do tego produktu.
Jeśli klient zamawia książki autora, który napisał kilka książek to zaproponuj pozostałe książki tego autora przez zakończeniem składania zamówienia przez klienta. - obliczenia - określają sposób w jaki wykonywane są określone operacje matematyczne lub algorytmy.
Przykłady:
Cena produktów jest obniżana o 10% jeśli zamówienie zawiera od 6 do 10 sztuk, o 20% gdy zamówienie zawiera od 11 do 20 sztuk, o 35% dla zamówienia z ponad 20-ma sztukami.
Droga między dwoma punktami ma być wyznaczana zgodnie z algorytmem Bellmana-Forda. - wnioski - określają nową wiedzę lub zmianę stanu obiektów biznesowych ma podstawie określonych warunków.
Przykłady:
Jeśli opłata nie zostanie wniesiona w ciągu 30 dni od określonej daty zapłaty to konto klienta staje się unieważnione.
Jeśli sprzedano więcej niż sto tysięcy płyt to ma ona status platynowej.
Jak zapisywać reguły biznesowe?
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".