io-3-wyk copy

69
1 Inżynieria oprogramowania Specyfikacja wymagań Autor: Łukasz Olek Szanowni Państwo! Witam serdecznie na kolejnym wykładzie z serii „Inżynieria oprogramowania”.

Transcript of io-3-wyk copy

Page 1: io-3-wyk copy

1

Inżynieria oprogramowania

Specyfikacja wymagań

Autor: Łukasz Olek

Szanowni Państwo!Witam serdecznie na kolejnym wykładzie z serii „Inżynieria oprogramowania”.

Page 2: io-3-wyk copy

2

Inżynieria oprogramowania

Specyfikacja wymagań (2)

Plan wykładów

Zasady skutecznego działaniaSpecyfikacja wymagańKontrola jakości artefaktówJęzyk UML, cz. IJęzyk UML, cz. IIMetody formalneWzorce projektoweZarządzanie konfiguracjąWprowadzenie do testowaniaAutomatyzacja wykonywania testówProgramowanie EkstremalneEwolucja oprogramowania i refaktoryzacja

Plan wykładów

Jest to już drugi wykład z tej serii.Dotyczy on bardzo ważnego aspektu w tej dziedzinie - mianowicie komunikacji pomiędzy klientem, ainformatykami dotyczącej wymagań systemów informatycznych.

Page 3: io-3-wyk copy

3

Inżynieria oprogramowania

Specyfikacja wymagań (3)

Wprowadzenie

W celu lepszego zrozumienia, czym są wymagania w projektach informatycznych przedstawię pewnąhistoryjkę.Na slajdzie tytułowym widzieliśmy restaurację.Załóżmy, że właściciel takiej restauracji dostrzega potrzebę wdrożenia systemu informatycznego, wcelu usprawnienia obsługi kelnerskiej klientów.Właściciel ten zgłasza się do firmy informatycznej i pragnie zamówić taki system.

Page 4: io-3-wyk copy

4

Inżynieria oprogramowania

Specyfikacja wymagań (4)

Wprowadzenie

Dochodzi do transakcji pomiędzy klientem, posiadającym pieniądze, oraz firmą informatyczną, będącąw stanie spełnić oczekiwania klienta.

Page 5: io-3-wyk copy

5

Inżynieria oprogramowania

Specyfikacja wymagań (5)

Wprowadzenie

Page 6: io-3-wyk copy

6

Inżynieria oprogramowania

Specyfikacja wymagań (6)

Wprowadzenie

Page 7: io-3-wyk copy

7

Inżynieria oprogramowania

Specyfikacja wymagań (7)

Wprowadzenie

Page 8: io-3-wyk copy

8

Inżynieria oprogramowania

Specyfikacja wymagań (8)

Wprowadzenie

Page 9: io-3-wyk copy

9

Inżynieria oprogramowania

Specyfikacja wymagań (9)

Wprowadzenie

= ?Z punktu widzenia takiej transakcji ważne jest, aby była równoważność pomiędzy tym ile klientzapłaci, tym co otrzyma w zamian.

Page 10: io-3-wyk copy

10

Inżynieria oprogramowania

Specyfikacja wymagań (10)

Kontrakt

Wprowadzenie

=

Dlatego, na początku przed przystąpieniem do realizacji projektu informatycznego musi zostać zawartykontrakt pomiędzy klientem, a dostawcą. Kontrakt taki jest zabezpieczeniem dla obu stron. Z jednejstrony zabezpiecza klienta, który ma obiecane, że w zamian za pieniądze dostanie pewien określonysystem informatyczny. Z drugiej strony zabezpiecza on dostawcę oprogramowania - daje mu pewność,że otrzyma zapłatę za swoją pracę.

Page 11: io-3-wyk copy

11

Inżynieria oprogramowania

Specyfikacja wymagań (11)

Kontrakt

Wprowadzenie

Specyfikacja wymagań =

Główną częścią kontraktu jest dokument zwany specyfikacją wymagań. Co oznacza ten termin?

Page 12: io-3-wyk copy

12

Inżynieria oprogramowania

Specyfikacja wymagań (12)

Wprowadzenie

• Wymaganie = opis co system powinienrobić

źródło: www.wikipedia.org

• Specyfikacja = zbiór wymagań

• W momencie kiedy spiszemywymagania, klient dostanie dokładnieto, czego potrzebuje

Rozbijmy go na poszczególne wyrazy…Jedno wymaganie, to opis pojedynczej funkcji, którą system powinien udostępniać swoimużytkownikom.Specyfikacja natomiast jest zbiorem wymagań, czyli zakresem funkcjonalności zamawianego systemu.

Mogłoby się więc wydawać, że jeżeli spiszemy wymagania na początku projektu informatycznego (conie jest powszechną praktyką), mamy zapewnienie, że klient dostanie dokładnie to, czego potrzebuje (iże nie będzie chciał od nas więcej!).

Page 13: io-3-wyk copy

13

Inżynieria oprogramowania

Specyfikacja wymagań (13)

Wprowadzenie

• W momencie kiedy spiszemy wymagania, klientdostanie dokładnie to, czego potrzebuje

• 1. Słowa nie mają znaczenia!

Niestety nie jest to takie proste, przynajmniej z kilku powodów.Po pierwsze, słowa nie mają znaczenia!Lingwistyka filozoficzna mówi, że to ludzie umówili się, iż krowa to krowa, dziecko to dziecko, awiatrak to wiatrak. Równie dobrze można by się umówić, że krowę będziemy nazywać wiatrakiem, awiatrak krową.

Page 14: io-3-wyk copy

14

Inżynieria oprogramowania

Specyfikacja wymagań (14)

Wprowadzenie

• W momencie kiedy spiszemy wymagania, klientdostanie dokładnie to, czego potrzebuje

• 1. Słowa nie mają znaczenia!– Załadunek kompletny?– Raport miesięczny?– SAD?

Może to rodzić problemy związane z nazewnictwem, terminologią. W momencie kiedy przystępujemydo informatyzacji pewnego przedsiębiorstwa, z pewnością spotkamy się z szeregiem terminów, którychnie zrozumiemy. Np. w firmach spedycyjnych powszechne są określenia: załadunek kompletny, raportmiesięczny, SAD.Co one znaczą?Czy załadunek kompletny, to samochód, który zapakowano do określonej wagi? Czy też możesamochód, którego ładunek zajmuje pewną określoną objętość minimalną? A może też samochódzaładowany wszystkimi towarami uwzględnionymi w zleceniu?Co oznacza termin raport miesięczny? Czy to podsumowanie faktur z całego miesiąca? A może liczbatransportów wraz z informacją o sumarycznym załadunku? A może jeszcze coś innego?SAD to kawałek ziemi obsadzony drzewami owocowymi, czy też może dokument celny?

Page 15: io-3-wyk copy

15

Inżynieria oprogramowania

Specyfikacja wymagań (15)

Wprowadzenie

• W momencie kiedy spiszemy wymagania, klientdostanie dokładnie to, czego potrzebuje

• 2. Wiedza:– świadoma– nieświadoma

Stwierdzenie nasze nie jest poprawne również z drugiego powodu: wiedza każdej osoby (a więcrównież klienta) składa się z części świadomej oraz nieświadomej.Może się więc zdarzyć (i jest tak dosyć często), że klient nie jest w pełni świadomy każdegowymagania, więc nie jest w stanie wszystkiego przekazać analitykowi.System zbudowany na podstawie takich niekompletnych wymagań na pewno nie spełni do końca jegopotrzeb.

Page 16: io-3-wyk copy

16

Inżynieria oprogramowania

Specyfikacja wymagań (16)

Wprowadzenie

• Wymagania telefonu Nokia N80:– duży wyświetlacz– duże, wygodne klawisze– aparat o wysokiej

rozdzielczości

Problemy te najlepiej pokazać na przykładzie. Spójrzmy jak mogłyby wyglądać wymagania telefonukomórkowego.

Page 17: io-3-wyk copy

17

Inżynieria oprogramowania

Specyfikacja wymagań (17)

Wprowadzenie

• Wymagania telefonu Nokia N80:– duży wyświetlacz– duże, wygodne klawisze– aparat o wysokiej

rozdzielczości– WiFi

Co oznaczaokreślenie„duże”?

Co oznaczaokreślenie„wysoka”?

Czy klawiaturanie może sięznaleźć po

drugiej stronie?

Co oznacza określenie: duży wyświetlacz? Czy wyświetlacz wystarczający do odczytywaniawiadomości tekstowych, a może przeglądania zdjęć w dużej rozdzielczości?Podobnie z pozostałymi określeniami: duże klawisze, wysoka rozdzielczość aparatu.

Ciekawe spostrzeżenie możemy wysnuć w związku z wiedzą nieświadomą. Możemy być pewni, żenigdzie w wymaganiach żadnego telefonu komórkowego nie znajdziemy określenia, że klawiaturapowinna być po tej samej stronie telefonu co wyświetlacz. Dlaczego więc nikt nie zrobi na odwrót:przecież gdybyśmy ułożyli klawiaturę po jednej stronie, a wyświetlacz po drugiej - bylibyśmy w staniejeszcze bardziej zmniejszyć rozmiary telefonu.Jest to wiedza nieświadoma - każdy z nas korzystał z telefonu i wie że podczas naciskania klawiszymusi widzieć, co się dzieje na ekranie.Gdyby jednak te produkty były projektowane przez osoby, które nigdy nie miały do czynienia zczymkolwiek podobnym (tak jest w dużej części projektów informatycznych), wtedy z pewnościąznalazłoby się wiele rzeczy zrobionych wbrew intuicji przyszłych użytkowników.

Page 18: io-3-wyk copy

18

Inżynieria oprogramowania

Specyfikacja wymagań (18)

Jak sobie z tym poradzić?

• Spisywanie wymagań to sztuka- nie ma uniwersalnego sposobu

• Korzystaj z porad innych:– dobre praktyki– metody, które się sprawdziły

No dobrze. Widzimy, że na inżynierów wymagań czyha wiele niebezpieczeństw. Czy jest jakiśuniwersalny sposób poradzenia sobie z nimi?Niestety nie. Pozyskiwanie wymagań jest pewnego rodzaju sztuką.Można jednak patrzeć, jak to robią inni oraz spróbować pewnych „dobrych praktyk” zaproponowanychprzez ekspertów w tej dziedzinie.

Page 19: io-3-wyk copy

19

Inżynieria oprogramowania

Specyfikacja wymagań (19)

Plan wykładu

• Wprowadzenie• Wymagania

pozafunkcjonalne• Wymagania funkcjonalne:

– Przypadki użycia– Jak pisać przypadki

użycia?• Dobre praktyki

Sommerville i Sawyer’a

Po tym dłuższym wprowadzeniu, które właśnie miało miejsce, omówimy następujące zagadnienia:•podział wymagań na pozafunkcjonalne i funkcjonalne.•sposoby opisywania wymagań funkcjonalnych ze szczególnym naciskiem na przypadki użycia•dobre praktyki Sommerville i Sawyer’a

Page 20: io-3-wyk copy

20

Inżynieria oprogramowania

Specyfikacja wymagań (20)

Podział wymagań

• Funkcjonalne:– Wprowadzanie nowej faktury– Generowanie raportu miesięcznego

• Pozafunkcjonalne– minimum 20 faktur na godzinę– 200000h MTBF– maksimum 2 godziny potrzebne na

przeszkolenie 1 pracownika

W celu lepszego ogarnięcia wymagań systemów informatycznych, specjaliści podzielili je na 2kategorie: na wymagania funkcjonalne i pozafunkcjonalne.

Wymagania funkcjonalne to funkcje systemu widziane od strony użytkownika, np wprowadzenie nowejfaktury, lub wygenerowanie raportu miesięcznego. Natomiast wymagania pozafunkcjonalne towszystkie inne wymagania, zwłaszcza takie związane z bezpieczeństwem, wydajnością, awaryjnością,np: system ma umożliwiać wprowadzenie co najmniej 20 faktur w ciągu godziny, lub średni czaspomiędzy awariami (ang. MTBF) powinien wynosić 200000h.

Page 21: io-3-wyk copy

21

Inżynieria oprogramowania

Specyfikacja wymagań (21)

Wymagania pozafunkcjonalne

• Functionality - funkcjonalność

• Usability - użyteczność

• Reliability - niezawodność

• Performance - wydajność

• Security - bezpieczeństwo

Bardzo powszechny jest również podział FURPS. Pierwsza litera oznacza wymagania funkcjonalne,natomiast pozostałe - wymagania pozafunkcjonalne.U - użyteczność, oznacza łatwość użytkowania systemu. Takie wymagania można precyzować np.poprzez maksymalny czas szkolenia pracownika, liczba kontaktów ze wsparciem klienta, liczbąsytuacji, w których konieczne jest skorzystanie z systemu pomocy.R - niezawodność, może być mierzona poprzez: średnią liczbę godzin pracy bez awarii (ang. MTBF -Mean Time Between Failure), maksymalną liczbą godzin w miesiącu w ciągu których system może byćwyłączony w celach pielęgnacyjnych (ang. maintainance) - ma to znaczenie szczególnie w przypadkusystemów, które muszą pracować na okrągło - np. systemy bankowości elektronicznejP - wydajność - mierzona np. liczbą transakcji, którą system jest w stanie obsłużyć w ciągu godziny,liczbą użytkowników, którzy mogą być zalogowani jednocześnie do portaluS - bezpieczeństwo, to wymagania związane z szyfrowaniem, polityką praw, itp.

Page 22: io-3-wyk copy

22

Inżynieria oprogramowania

Specyfikacja wymagań (22)

Plan wykładu

• Wprowadzenie• Wymagania

pozafunkcjonalne• Wymagania

funkcjonalne:– Przypadki użycia– Jak pisać przypadki

użycia?• Dobre praktyki

Sommerville i Sawyer’a

Z punktu widzenia klienta dużo ciekawsze wydają się wymagania funkcjonalne. Ta część wykładubędzie poświęcona właśnie takim wymaganiom.

Page 23: io-3-wyk copy

23

Inżynieria oprogramowania

Specyfikacja wymagań (23)

Wymagania funkcjonalne

• „System powinien…”• Funkcje systemu• Przypadki użycia

Wymagania funkcjonalne opisują funkcje poszczególnych użytkowników.Przedstawimy trzy podejścia. Pierwsze dwa są podejściami historycznymi, natomiast ostatni -przypadki użycia staje się obecnie coraz bardziej popularny.

Page 24: io-3-wyk copy

24

Inżynieria oprogramowania

Specyfikacja wymagań (24)

„System powinien…”

• Zalety:– łatwość

spisywania• Wady:

– słaba czytelność– trudne

sprawdzaniekompletności,spójności

– System powinien umożliwićwystawianie faktur

– System powinien generowaćzestawienie miesięczne faktur

– Faktura powinna zawierać conajmniej jedną pozycję

(tak przez kolejnych 200 stron)

Wymagania w stylu „System powinien…” były intensywnie wykorzystywane w latach 80-tych, 90-tych. W roku 1998 nawet zostały zaproponowane jako standard (IEEE 830-1998). Ich dużą zaletą jestłatwość spisywania.Niestety obecne systemy stają się coraz bardziej złożone, a wymagania średniej wielkości systemu w tejpostaci zajęłyby kilkaset stron. Tak wielka liczba luźnych zdań, niepowiązanych ze sobą sprawiatrudności podczas sprawdzania jakości takiej specyfikacji.

Page 25: io-3-wyk copy

25

Inżynieria oprogramowania

Specyfikacja wymagań (25)

Funkcje systemu

Funkcja (operacja)

Wejście Wyjście

Efekty uboczne

• Wady:– słaba

czytelność– trudne do

zrozumienia

Innym podejściem jest opisywanie poszczególnych funkcji systemu. Analogicznie do funkcjimatematycznych, każda funkcja systemu informatycznego ma swoje wejście, wyjście, efekty uboczne.Przykładowo, rozpatrując funkcję wystawiania faktury, wejściem mogą być pozycje faktury, wyjściemwydruk faktury (lub wysłanie jej faksem), natomiast efektem ubocznym zapisanie tej faktury wrejestrze faktur.

Podobnie jak w przypadku wymagań typu „System powinien”, taka specyfikacja wymagań zawierabardzo dużą liczbę małych funkcji, więc nadal są problemy ze zrozumieniem idei systemu iczytelnością.

Page 26: io-3-wyk copy

26

Inżynieria oprogramowania

Specyfikacja wymagań (26)

Przypadki użycia

•Zalety:–łatwośćspisywania–czytelność–łatwośćzrozumieniai wyobrażeniasobie przyszłegosystemu

UC1: Wystawianie fakturyGłówny scenariusz:1. Sprzedawca pragnie wystawić

fakturę.2. Sprzedawca wpisuje pozycje

faktury.3. System podlicza fakturę, nadaje jej

nowy numer i zapisuje w rejestrze4. Sprzedawca drukuje fakturę.

Trzecie podejście to przypadki użycia.Poprzednie podejścia opisywały wymagania z perspektywy systemu - jak system powinien sięzachować w określonej sytuacji. Przypadki użycia natomiast skupiają się na interakcji pomiędzyużytkownikiem, a systemem.Dzięki takiemu podejściu zyskujemy na czytelności - przypadki użycia nie pokazują zbędnychszczegółów. Dużo łatwiej też jest klientowi wyobrazić sobie jak system będzie funkcjonował. Nie czytaopisu matematycznego, lecz pewną opowieść, która mówi o tym, w jaki sposób np. wystawić fakturę.

Page 27: io-3-wyk copy

27

Inżynieria oprogramowania

Specyfikacja wymagań (27)

Plan wykładu

• Wprowadzenie• Wymagania

pozafunkcjonalne• Wymagania funkcjonalne:

– Przypadki użycia– Jak pisać przypadki

użycia?• Dobre praktyki

Sommerville i Sawyer’a

W dalszej części wykładu skupimy się na tym trzecim podejściu - przypadkach użycia.Najpierw dowiemy się czym jest przypadek użycia i jak jest zbudowany.

Page 28: io-3-wyk copy

28

Inżynieria oprogramowania

Specyfikacja wymagań (28)

Przypadek użycia

• Formaustrukturalizowana– Nazwa

Wystawianie faktury

Jak już było powiedziane wcześniej - przypadek użycia jest opisem interakcji pomiędzyużytkownikiem, a systemem informatycznym.Mogą one występować w różnych formach. Najprostsza to akapit tekstu pisany językiem naturalnym.Bardziej powszechna jest jednak postać strukturalna.Każdy przypadek użycia w tej formie składa się z następujących elementów:Nazwa - wyraża cel przypadku użycia (np. wystawianie faktury, zamówienie książki, dodanie wpisu naforum)

Page 29: io-3-wyk copy

29

Inżynieria oprogramowania

Specyfikacja wymagań (29)

Przypadek użycia

• Formaustrukturalizowana– Nazwa– Identyfikator

UC1: Wystawianie faktury

Identyfikator - unikalny w obrębie danej specyfikacji wymagań, przydaje się podczas dyskusji na tematwymagań - do odwoływania się do poszczególnych elementów. Dzięki nim można prosto powiedzieć,że np. w przypadku użycia UC1, w kroku 2 jest błąd.

Page 30: io-3-wyk copy

30

Inżynieria oprogramowania

Specyfikacja wymagań (30)

Przypadek użycia

• Formaustrukturalizowana– Nazwa– Identyfikator– Główny

scenariusz

UC1: Wystawianie fakturyGłówny scenariusz:1. Sprzedawca pragnie wystawić fakturę.2. Sprzedawca wpisuje pozycje faktury.3. System podlicza fakturę, nadaje jej

nowy numer i zapisuje w rejestrze4. Sprzedawca drukuje fakturę.

Główny scenariusz - sekwencja kroków, która musi zostać wykonana do osiągnięcia celu przypadkuużycia (wyrażonego w nazwie). Opisuje najczęstszy przebieg interakcji pomiędzygłównym aktorem, a systemem.

Page 31: io-3-wyk copy

31

Inżynieria oprogramowania

Specyfikacja wymagań (31)

Przypadek użycia

• Formaustrukturalizowana– Nazwa– Identyfikator– Główny

scenariusz– Rozszerzenia

UC1: Wystawianie fakturyGłówny scenariusz:1. Sprzedawca pragnie wystawić fakturę.2. Sprzedawca wpisuje pozycje faktury.3. System podlicza fakturę, nadaje jej nowy

numer i zapisuje w rejestrze.4. Sprzedawca drukuje fakturę.Rozszerzenia:3.A. Sprzedawca nie dodał żadnej pozycji

3.A.1. System prosi o ponownewprowadzenie pozycji (powrót do 2.)

Nie zawsze jest możliwość wykonania głównego scenariusza. Czasem użytkownik popełni jakiś błąd,innym razem nie są spełnione pewne warunki, co uniemożliwia przejście dalej. Reakcje na takiewydarzenia możemy umieścić w rozszerzeniach.Przykładowo w kroku 3. może się okazać, że sprzedawca nie dodał żadnej pozycji. Dziękirozszerzeniom możemy podać sekwencję kroków, która będzie wykonana w takiej sytuacji.

Page 32: io-3-wyk copy

32

Inżynieria oprogramowania

Specyfikacja wymagań (32)

Przypadek użycia

• Formaustrukturalizowana– Nazwa– Identyfikator– Główny

scenariusz– Rozszerzenia– Atrybuty

UC1: Wystawianie fakturyAtrybuty:

Główny aktor: UżytkownikPriorytet: WysokiŹródło: Łukasz Olek

Główny scenariusz:1. Sprzedawca pragnie wystawić fakturę.2. Sprzedawca wpisuje pozycje faktury.3. System podlicza fakturę, nadaje jej nowy numer i

zapisuje w rejestrze.4. Sprzedawca drukuje fakturę.Rozszerzenia:…

Dodatkowo, do każdego wymagania możemy dołączyć listę atrybutów, np.-nazwę głównego aktora - użytkownika, który gra główną rolę w danym przypadku użycia-priorytet tego wymagania z punktu widzenia klienta-źródło wymagania - osoba, od której pochodzi konkretne wymaganie - taka informacja przydaje siępóźniej, kiedy programiści będą mieli jakieś wątpliwości i dodatkowe pytania - będą w stanie trafićbezpośrednio do osoby najlepiej poinformowanej.

Page 33: io-3-wyk copy

33

Inżynieria oprogramowania

Specyfikacja wymagań (33)

Przypadki użycia, a UML

• Diagram przypadkówużycia:– Nazwy przypadków

użycia– Powiązania z

aktorami– Dobre jako „mapa”

Przypadki użycia są często mylone z diagramami przypadków użycia z UML’a.Postaram już na początku zaznaczyć te różnice, żebyście Państwo nie mieli takich problemów wprzyszłości.

Diagram przypadków użycia prezentuje tylko połączenie aktorów z przypadkami użycia. Każdyprzypadek użycia jest tutaj reprezentowany jako nazwa. Jest to dobre w początkowej fazie analizywymagań, kiedy odkrywamy funkcje systemu, lecz wymaga późniejszego doprecyzowania, czylinapisania specyfikacji wymagań, która będzie zawierać kompletne przypadki użycia.W takiej specyfikacji wymagań dobrze jest umieścić na początku diagram przypadków użycia, którybędzie służył jako „spis treści” dokumentu.

Page 34: io-3-wyk copy

34

Inżynieria oprogramowania

Specyfikacja wymagań (34)

Plan wykładu

• Wprowadzenie• Wymagania

pozafunkcjonalne• Wymagania funkcjonalne:

– Przypadki użycia– Jak pisać

przypadki użycia?• Dobre praktyki

Sommerville i Sawyer’a

Na kolejnych slajdach przedstawię podstawowe zasady pisania przypadków użycia.

Page 35: io-3-wyk copy

35

Inżynieria oprogramowania

Specyfikacja wymagań (35)

Jak pisać przypadki użycia?

• Steve Adolph, PaulBramble:„Patterns forEffective Use Cases”

Jedną z lepszych książek mówiących o tym są: „Wzorce Efektywnych Przypadków Użycia”, napisanaprzez ludzi stosujących to podejście od lat w projektach informatycznych i mających dużedoświadczenie w tym zakresie.

Page 36: io-3-wyk copy

36

Inżynieria oprogramowania

Specyfikacja wymagań (36)

Jak pisać przypadki użycia?

• Przypadek użycia• Zbiór przypadków użycia• Proces• Zespół

Stworzyli oni listę „wzorców”, czyli „dobrych praktyk” dotyczących pisania i podzielili ją na 4 grupy:-pierwsza dotyczy pojedynczego przypadku użycia,-druga - całego ich zbioru, czyli sposobu komponowania specyfikacji z pojedynczych wymagań-trzecia - dotyczy procesu ich tworzenia, oraz-czwarta - zespołu osób, które przygotowują specyfikację wymagań

Page 37: io-3-wyk copy

37

Inżynieria oprogramowania

Specyfikacja wymagań (37)

Jak pisać przypadki użycia?

• Przypadek użycia• Zbiór przypadków użycia• Proces• Zespół

Zacznijmy od wzorców związanych z pojedynczym przypadkiem użycia

Page 38: io-3-wyk copy

38

Inżynieria oprogramowania

Specyfikacja wymagań (38)

Przypadek użycia

• „Fraza czasownikowa w nazwie”:– Wystawianie faktury– Generowanie raportu miesięcznego– Główny przypadek użycia– Przypadek użycia 2– Zarządzanie

Nazwa przypadku użycia jest bardzo ważna - występuje w wielu miejscach dokumentu (spisie treści,diagramach przypadków użycia, itp), tak więc w sformułowanie prawidłowej nazwy powinna byćwłożona odrobina wysiłku, tak aby dobrze odzwierciedlała ona zawartość przypadku użycia.Mówi o tym pierwszy wzorzec, jaki wybrałem z książki: „Fraza czasownikowa w nazwie”.Frazy czasownikowe dobrze opisują cele przypadków użycia, np jak spotkamy nazwę: wystawianiefaktury, albo generowanie raportu miesięcznego, to od razu wiemy o jakie wymaganie chodzi.

Kilka przykładów złych nazw:-Nazwy nic nie znaczące: Główny przypadek użycia, Przypadek użycia 2-Zbyt ogólna, przez co nie stanowi żadnej wartości dla czytelnika: Zarządzanie

Page 39: io-3-wyk copy

39

Inżynieria oprogramowania

Specyfikacja wymagań (39)

Przypadek użycia

• „Scenariusz i rozszerzenia”:– Nadrzędny cel: czytelność!– Scenariusz główny - najbardziej

prawdopodobna ścieżka• 3-9 kroków

– Rozszerzenia - alternatywnescenariusze

• kiedy coś pójdzie nie tak• numer rozszerzenia: numer kroku

+ kolejna litera

UC1: Dodawanie nowej fakturyGłówny scenariusz:1. Użytkownik pragnie dodać nową fakturę.2. Użytkownik wpisuje pozycje faktury.3. System podlicza fakturę, nadaje jej nowy

numer i zapisuje w rejestrze.4. Użytkownik drukuje fakturę.Rozszerzenia:3.A. Użytkownik nie dodał żadnej pozycji

3.A.1. System prosi o ponownewprowadzenie pozycji (powrót do 2.)

Drugi omawiany wzorzec to „Scenariusz i rozszerzenia”Przypadek użycia powinien być podzielony na takie 2 części - dzięki temu czytelnik może się zapoznaćnajpierw z głównym scenariuszem i zrozumieć na czym polega wymaganie, a następnie przejść doniuansów zawartych w rozszerzeniach.

Generalną zasadą jest zwięzłość i przejrzystość, aby czytelnik nie pogubił się.Dlatego, każdy scenariusz powinien zawierać od 3-9 kroków (gdy jest ich mniej, specyfikacja wymagańjest zbyt fragmentaryczna, natomiast gdy jest ich więcej - czytelnik nie jest w stanie ogarnąć pamięciącałości).Ze względu na czytelność, również poszczególne kroki scenariusza nie powinny być zbytskomplikowane. Najlepiej gdy są wyrażone prostym zdaniem zawierającym podmiot (czyli aktora).

Rozszerzenia natomiast, to sekwencje kroków wykonywane podczas sytuacji wyjątkowych. Numerrozszerzenia składa się zawsze z numeru kroku, którego rozszerzenie dotyczy, oraz litery - stanowiącejnumer rozszerzenia (w ramach tego kroku).Czyli przykładowo możemy się spotkać z takimi rozszerzeniami:1.A.2.A.3.A.1.B.

Rozszerzenia mogą być wielokrotnie zagnieżdżane, czyli przykładowo, jeżeli mamy krok 1.A.2 ichcemy do niego dodać rozszerzenie, to będzie ono miało numer 1.A.2.A.

Page 40: io-3-wyk copy

40

Inżynieria oprogramowania

Specyfikacja wymagań (40)

Przypadek użycia

• „Obojętność technologiczna”:– technologia jest zmienna– niepotrzebne ograniczenia– szczegóły GUI zaciemniają obraz– klient nie rozumie terminy technicznych

• Przykłady:– Pracownik klika na link kalendarium– System zapisuje dane użytkownika w bazie danych– System za pomocą protokołu SOAP pobiera aktualną

temperaturę

Wzorzec kolejny: „ Obojętność technologiczna”Błędem jest, gdy przypadki użycia zawierają szczegóły technologiczne:-technologia jest zmienna - może sie okazać, że następny podobny projekt będzie realizowany w nowejtechnologii, mimo że część wymagań będzie identyczna. Jeżeli przypadki użycia będą zawieraćszczegóły technologiczne, to ponowne zastosowanie raz napisanych wymagań będzie dużo trudniejsze-szczegóły Graficznego Interfejsu Użytkownika (ang. GUI - Graphical User Interface) zaciemniająjedynie obraz czytelnika - gubi się on w gąszczu szczegółów. Czasem jednak jest potrzebazobrazowania klientowi takich szczegółów - wtedy warto naszkicować poszczególne ekrany aplikacji idodać je jako załącznik do specyfikacji wymagań-klient nie rozumie terminów technicznych w stylu SOAP, baza danych, HTTP, itp.

Page 41: io-3-wyk copy

41

Inżynieria oprogramowania

Specyfikacja wymagań (41)

Jak pisać przypadki użycia?

• Przypadek użycia• Zbiór przypadków użycia• Proces• Zespół

Kiedy potrafimy napisać pojedynczy przypadek użycia, czas dowiedzieć się, w jaki sposób składać teelementy w całą specyfikację wymagań.

Page 42: io-3-wyk copy

42

Inżynieria oprogramowania

Specyfikacja wymagań (42)

Zbiór przypadków użycia

• „Rozwijalna historia”:–Hierarchiczne scenariusze–Można rozwijać lub zwijać w celu

pokazania lub ukrycia szczegółów

Pierwszy wzorzec z tej grupy to „Rozwijalna historia”Zbiór przypadków użycia powinien stanowić rozwijalną historię, czyli być zorganizowany whierarchiczne drzewo scenariuszy. Im głębiej, tym przypadki użycia są bardziej szczegółowe.Dzięki temu będzie można przeczytać tylko przypadki użycia najwyższego poziomu, aby miećogólną wiedzę o systemie, lub zagłębiać się coraz bardziej jeżeli potrzebujemy większychszczegółów.

Page 43: io-3-wyk copy

43

Inżynieria oprogramowania

Specyfikacja wymagań (43)

Rozwijalna historia

• Poziom celu użytkownika:– główny aktor osiąga zamierzony cel w ciągu

jednej sesji przy komputerze

W celu łatwiejszego zorientowania się w tej hierarchii scenariuszy, wprowadzono podział przypadkówużycia na trzy poziomy.Środkowy poziom - to poziom celu użytkownika. Przypadki użycia na tym poziomie opisująposzczególne funkcje systemu, z punktu widzenia użytkowników, np. Rejestracja na szkolenie,Wypełnienie ankiety, Redagowanie ankiety…

Page 44: io-3-wyk copy

44

Inżynieria oprogramowania

Specyfikacja wymagań (44)

Rozwijalna historia

• Poziom podfunkcji:– przecyzuje wykonanie funkcji

Niekiedy do opisania pewnych funkcji potrzebujemy większych szczegółów. Wtedy korzystamy zprzypadków użycia poziomu podfunkcji. Jeżeli np. uważamy, że „Dodawanie komponentu do ankiety”,lub „Wysyłanie wiadomości email” wymaga doprecyzowania, możemy stworzyć taki przypadek użyciai wywołać go z przypadku użycia wyższego poziomu. Przykładowo, mamy dane 2 przypadki użycia:UC1. Rozsyłanie ankiety, orazSUB1. Wysyłanie wiadomości email.

Wtedy z UC1, możemy wywołać drugi przypadek użycia, poprzez wymienienie tego przypadku użyciaw treści jednego z kroków:

UC1. Rozsyłanie ankiety….3. System wysyła prośbę o wypełnienie ankiety do wszystkich firm zarejestrowanych w systemie(SUB1).…

To jest znak dla czytelnika, że jeżeli interesują go szczegóły danego kroku, może zajrzeć do przypadkuużycia SUB1.

Page 45: io-3-wyk copy

45

Inżynieria oprogramowania

Specyfikacja wymagań (45)

Rozwijalna historia

• Poziom streszczenia (biznesowy):– kontekst dla wymagań użytkownika

Trzeci poziom, to poziom biznesowy. Służy on do naszkicowania kontekstu dla tworzonego systemu.W momencie kiedy analityk pozna specyfikę konkretnej firmy, jej procesy biznesowe, dużo prościejzrozumieć wymagania użytkownika.W celu opisania tych procesów można skorzystać z przypadków użycia poziomu streszczenia(biznesowego).

Page 46: io-3-wyk copy

46

Inżynieria oprogramowania

Specyfikacja wymagań (46)

Rozwijalna historia

Na kolejnych slajdach widać, w jakiej kolejności czytać przypadki użycia, aby maksymalnie szybkozrozumieć wymagania systemu. W dowolnym momencie można przerwać czytanie, jeżeli niepotrzebujemy większej liczby szczegółów.

Page 47: io-3-wyk copy

47

Inżynieria oprogramowania

Specyfikacja wymagań (47)

Rozwijalna historia

Page 48: io-3-wyk copy

48

Inżynieria oprogramowania

Specyfikacja wymagań (48)

Rozwijalna historia

Page 49: io-3-wyk copy

49

Inżynieria oprogramowania

Specyfikacja wymagań (49)

Rozwijalna historia

Page 50: io-3-wyk copy

50

Inżynieria oprogramowania

Specyfikacja wymagań (50)

Jak pisać przypadki użycia?

• Przypadek użycia• Zbiór przypadków użycia• Proces• Zespół

Trzecia grupa - wzorce dotyczące procesu powstawania przypadków użycia. Mówią one, w jaki sposóbspisywać przypadki użycia, aby zrobić to najefektywniej.

Page 51: io-3-wyk copy

51

Inżynieria oprogramowania

Specyfikacja wymagań (51)

Proces

• „Szerokość przed głębokością”:pozyskiwanie wymagań - odkrywczy proces– zmiany na tym etapie - bardzo prawdopodobne– pisanie kompletnych przypadków użycia -

strata energii– rozwijaj w kolejności:

• 1. lista aktorów• 2. nazwy przypadków użycia• 3. główny scenariusz• 4. rozszerzenia

Pozyskiwanie wymagań jest procesem odkrywczym. Nie ma osób, które są w stanie od razuzaproponować w pełni poprawne wymagania. Często pytamy klienta, jak wyobraża sobie poszczególnefunkcje systemu, następnie zapisujemy to w formie przypadków użycia, po czym okazuje się, żechodziło o coś zupełnie innego.Dlatego warto robić to stopniowo, na początku bardzo zgrubnie, a w momencie kiedy upewnimy się, żenasz tor myślenia jest prawidłowy, można dodawać szczegóły.Takie podejście właśnie oznacza określenie „Szerokość przed głębokością”

Dla przypadków użycia proponowane są następujące etapy:-1. odkrycie wszystkich aktorów-2. zaprezentowanie funkcji - nazwy przypadków użycia-3. dopisanie głównego scenariusza do każdej nazwy przypadku użycia-4. uzupełnienie rozszerzeń

Page 52: io-3-wyk copy

52

Inżynieria oprogramowania

Specyfikacja wymagań (52)

Szerokość przed głębokością

Przeprowadza ankiety

Zarządza artykułami w portalu

Akceptuje zgłoszenia nowych firmKonsultant

Zgłoszenie do udziału w projekcie

Pobieranie artykułu

Rejestracja na szkolenieFirma

Lista Aktor-Cel:

Pierwsze dwa kroki (aktorzy i nazwy przypadków użycia) można przedstawić na diagramieprzypadków użycia, lub prościej - w formie tabeli Aktor-Cel, której przykład jest zaprezentowany naslajdzie.

Page 53: io-3-wyk copy

53

Inżynieria oprogramowania

Specyfikacja wymagań (53)

Jak pisać przypadki użycia?

• Przypadek użycia• Zbiór przypadków użycia• Proces• Zespół

Ostatnia grupa wzorców, to wzorce dotyczące zespołu autorów przypadków użycia.

Page 54: io-3-wyk copy

54

Inżynieria oprogramowania

Specyfikacja wymagań (54)

Zespół

• „Mały zespół autorów”– wielkość zespołu to najważniejszy

czynnik wpływający na jakość– 2-3 osoby w zupełności wystarczają– zaangażuj więcej osób w proces

recenzji– duże systemy – kilka małych zespołów

z jednym architektem odpowiedzialnymza spójną wizję systemu

Kluczowym czynnikiem stanowiącym o jakości specyfikacji wymagań jest wielkość zespołuanalityków.Z praktyki wynika, iż 2-3 osoby są w zupełności wystarczające - o tym mówi ten wzorzec. Jeżeli będziewięcej piszących, to narzut związany z komunikacją między nimi będzie zbyt duży, a kompromisytrudne do osiągnięcia.Więcej osób można zaangażować na etapie recenzji - wtedy inne osoby (testerzy, użytkownicy) będą wstanie wyrazić swoje zdanie.W trakcie pracy nad ogromnymi systemami może się okazać, że 2-3 osoby nie są w stanie ogarnąćcałości. Wtedy warto taki system podzielić na moduły i powołać po jednym małym zespole doanalizowania wymagań tylko w ramach modułu.

Page 55: io-3-wyk copy

55

Inżynieria oprogramowania

Specyfikacja wymagań (55)

Zespół

• „Zrównoważony zespół”– grupa podobnych specjalistów skupi się

jedynie na ograniczonych problemach– synergia: kompensuj słabe strony

jednych, dobrymi stronami innych– połącz ludzi różnej specjalności– analitycy i użytkownicy

Drugim kluczowym czynnikiem, jeżeli chodzi o zespół analityków, jest różnorodność specjalistów.W dzisiejszych czasach żadko kto ma tak obszerne doświadczenie, że zna się jednocześnie na tworzeniuoprogramowania i dziedzinie, którą informatyzujemy. W związku z tym warto na etapie powstawaniawymagań połączyć siły specjalistów z różnych dziedzin. Autorzy wzorców nazwali to„Zrównoważonym zespołem”.Tak skomponowany zespół będzie w stanie dostrzec dużo wcześniej wiele problemów i szybciejstworzyć poprawne wymagania.

Page 56: io-3-wyk copy

56

Inżynieria oprogramowania

Specyfikacja wymagań (56)

Często popełniane błędy

UC1: FakturaGłówny scenariusz:1. Sprzedawca wpisuje kod dostępu.2. System weryfikuje użytkownika.3. Kliknięcie na przycisk wystawiania faktury.4. System prezentuje formularz.5. Wpisanie pozycji w dolnym okienku.6. Wpisanie wartości pozycji , stawki VAT, liczby pozycji i nr. porządkowego.7. System podlicza fakturę i prezentuje sumę.8. System nadaje nowy numer i zapisuje w rejestrze faktur.9. Wydruk faktury.10. Jeżeli wystawianie faktur zakończyło się, to użytkownik się wylogowuje.Rozszerzenia:3.A. Sprzedawca nie dodał żadnej pozycji

3.A.1. System prosi o ponowne wprowadzenie pozycji (powrót do 2.)

To tyle, jeżeli chodzi o podstawowe informacje dotyczące tworzenia przypadków użycia. W celu ichlepszego utrwalenia wykonajmy proste ćwiczenie…Spróbujmy znaleźć naruszenia podanych wcześniej zasad na bieżącym slajdzie.

Page 57: io-3-wyk copy

57

Inżynieria oprogramowania

Specyfikacja wymagań (57)

Często popełniane błędy

UC1: FakturaGłówny scenariusz:1. Sprzedawca wpisuje kod dostępu.2. System weryfikuje użytkownika.3. Kliknięcie na przycisk wystawiania faktury.4. System prezentuje formularz.5. Wpisanie pozycji w dolnym okienku.6. Wpisanie wartości pozycji, stawki VAT, liczby pozycji i nr. porządkowego.7. System podlicza fakturę i prezentuje sumę.8. System nadaje nowy numer i zapisuje w rejestrze faktur.9. Wydruk faktury.10. Jeżeli wystawianie faktur zakończyło się, to użytkownik się wylogowuje.Rozszerzenia:3.A. Sprzedawca nie dodał żadnej pozycji

3.A.1. System prosi o ponowne wprowadzenie pozycji (powrót do 2.)

Najważniejsze błędy to:-tytuł przypadku użycia nie mówi, czym przypadek użycia będzie się zajmował (nie wiemy czy to jestwystawienie faktury, wysłanie, przefaksowanie, odbiór, czy cokolwiek innego)-W krokach 3, 5, 6, 7 znajdują się zbędne szczegóły (część to szczegóły techniczne, np. informacje oGUI, wyliczenia pól na ekranie, itp.)-W krokach 3, 5, 6, 9 - nie ma sprecyzowanego podmiotu, czyli aktora, który wykonuje krok.-Krok 10 zawiera konstrukcję warunkową - warunki powinny się znaleźć w sekcji rozszerzeń, a nie wgłównym scenariuszu.-Scenariusz posiada 10 kroków, czyli jest za długi dla przeciętnego czytelnika. Liczba kroków powinnaoscylować pomiędzy 3-9.

Page 58: io-3-wyk copy

58

Inżynieria oprogramowania

Specyfikacja wymagań (58)

Plan wykładu

• Wprowadzenie• Wymagania

pozafunkcjonalne• Wymagania funkcjonalne:

– Przypadki użycia– Jak pisać przypadki

użycia?• Dobre praktyki

Sommerville i Sawyer’a

To, co zostało przedstawione do tej pory podczas tego wykładu, to jedynie kilka podstawowychpomysłów (dobrych praktyk) związanych z dokumentowaniem wymagań. Inżynieria wymagań todziedzina dużo bardziej skomplikowana.Skąd więc czerpać nowe pomysły?

W momencie kiedy będziemy już pracować jako analitycy w firmach informatycznych przydałby sięsposób na ocenienie, na ile dobrze wykonujemy fazę analizy wymagań. Skąd mogę wiedzieć, czy to corobię do tej pory, wystarcza już do efektywnego pozyskiwania wymagań, czy też może mogę robić toznacznie lepiej?

Page 59: io-3-wyk copy

59

Inżynieria oprogramowania

Specyfikacja wymagań (59)

Dobre praktyki inżynierii wymagań

• Yan Sommerville &Pete Sawyer ‘97

• Zbiór dobrych praktyk• Model dojrzałości

procesów inżynieriiwymagań

Z odpowiedzią na te dylematy przychodzi książka opublikowana w 1997 roku przez panów YanaSommerville i Pete Sawyera poświęcona dobrym praktykom inżynierii wymagań.

Zdefiniowali oni również pewien model, wg którego można oszacować poziom dojrzałości procesówinżynierii wymagań w firmie.

Page 60: io-3-wyk copy

60

Inżynieria oprogramowania

Specyfikacja wymagań (60)

Dobre praktyki: Sommerville & Sawyer

432IW dla systemów krytycznych234Zarządzanie wymaganiami134Walidacja wymagań-33Modelowanie systemu-14Opisywanie wymagań125Analiza i negocjacja wym.166Zbieranie wymagań--8Dokument wymagań

Zaaw.9

Pośred.21

Podst.36Obszar

Dobre praktyki zaprezentowane przez nich są podzielone na 8 obszarów, natomiast każda praktyka jestprzydzielona do jednej z kategorii: podstawowa, pośrednia, zaawansowana - w zależności od stopniatrudności jej stosowania.

Page 61: io-3-wyk copy

61

Inżynieria oprogramowania

Specyfikacja wymagań (61)

Punktacja

3 - standard w organizacji2 - powszechnie używane1 - używane sporadycznie0 - nigdy

W celu sprawdzenia stopnia dojrzałości inżynierii wymagań w firmie, należy wziąć listę wszystkichpraktyk zaproponowanych przez autorów, a następnie każdej z nich przydzielić od 0-3 punktów, wzależności od tego, w jaki sposób praktyka jest wykorzystywana w organizacji:-3 punkty jeżeli praktyka jest standardem w organizacji-2 punkty jeżeli nie jest standardem, lecz jednak jest powszechnie wykorzystywana-1 punkt jeżeli jest wykorzystywana jedynie sporadycznie przez nieliczne jednostki-0 jeżeli nigdy nie jest używana

Page 62: io-3-wyk copy

62

Inżynieria oprogramowania

Specyfikacja wymagań (62)

Poziomy dojrzałości

Zdefiniowany > 85 Podst. & > 40 Pośr. & Zaaw.

Powtarzalny > 55 Podst. & < 40 Pośr. & Zaaw.

Początkowy < 55 Podst.

Autorzy zdefiniowali 3 poziomy dojrzałości procesów inżynierii wymagań w przedsiębiorstwach(kryteria są lekko rozmyte):-na pierwszym poziomie - początkowym znajduje się firma, która ma mniej niż 55 punktów z praktykpodstawowych-na drugim poziomie - powtarzalnym - są te firmy, które mają powyżej 55 punktów za praktykipodstawowe oraz poniżej 40 z praktyk pośrednich i zaawansowanych-na najwyższym poziomie - zdefiniowanym - znajdują się takie firmy, które mają powyżej 85 punktówza praktyki podstawowe, oraz powyżej 40 punktów za pośrednie i zaawansowane.

Poziomy te można krótko scharakteryzować:-Poziom początkowy - to podejście ad-hoc do zbierania wymagań, pojawiają się częste problemy zwymaganiami-Poziom powtarzalny - na tym poziomie są zdefiniowane standardy dla dokumentu wymagań orazczynności pozyskiwania wymagań - problemów w fazie analizy wymagań jest dużo mniej-Poziom zdefiniowany - posiada z góry zdefiniowany proces inżynierii wymagań, bazujący nanajlepszych praktykach. Jest obecny program poprawy tego procesu.

Page 63: io-3-wyk copy

63

Inżynieria oprogramowania

Specyfikacja wymagań (63)

Dobre praktyki: Dokument wymagań

• Określ standardową strukturędokumentu

• Wytłumacz, jak korzystać z dokumentu• Dołącz podsumowanie wymagań• Zdefiniuj specjalizowane terminy

(słownik)• Pomóż czytelnikom znaleźć informację

Kolejne slajdy przedstawiają wybrane praktyki. Tutaj jedynie wymienimy je z nazwy. Bardziejszczegółowo będziemy się nimi zajmować przy okazji poszczególnych wykładów z cyklu inżynieriioprogramowania i zaawansowanej inżynierii oprogramowania. Osoby, które już teraz są ciekaweszczegółów zachęcam do przeczytania książki Sommerville i Sawyera.

Page 64: io-3-wyk copy

64

Inżynieria oprogramowania

Specyfikacja wymagań (64)

Zbieranie wymagań

• Oceń możliwość zbudowania systemu• Zapisuj źródła wymagań• Zdefiniuj środowisko operacyjne

Page 65: io-3-wyk copy

65

Inżynieria oprogramowania

Specyfikacja wymagań (65)

Analiza i negocjacja wymagań

• Określ granice systemu• Korzystaj z list kontrolnych podczas

analizy wymagań• Określ priorytety wymagań

Page 66: io-3-wyk copy

66

Inżynieria oprogramowania

Specyfikacja wymagań (66)

Opisywanie wymagań

• Zdefiniuj standardowy szablon do opisuwymagań

• Korzystaj z prostego i spójnego języka• Dobrze wykorzystuj diagramy

Page 67: io-3-wyk copy

67

Inżynieria oprogramowania

Specyfikacja wymagań (67)

Walidacja wymagań

• Sprawdź, czy wymagania spełniająstandardy

• Zorganizuj formalne inspekcje wymagań• Zdefiniuj listy kontrolne walidacji• Wykorzystaj zespoły wielodyscyplinarne

do przeglądów wymagań

Page 68: io-3-wyk copy

68

Inżynieria oprogramowania

Specyfikacja wymagań (68)

Podsumowanie

• Wymagania funkcjonalne:– Przypadki użycia– Jak pisać przypadki

użycia?• Wymagania

pozafunkcjonalne• Dobre praktyki

Sommerville i Sawyer’a

Podsumujmy krótko co udało się przedstawić podczas tego wykładu:-główna część to sposób pisania wymagań funkcjonalnych w postaci przypadków użycia-krótko powiedzieliśmy sobie czym są wymagania pozafunkcjonalne-omówiliśmy model dojrzałości procesu inżynierii wymagań wg dobrych praktyk Sommerville iSawyera

Page 69: io-3-wyk copy

69

Inżynieria oprogramowania

Specyfikacja wymagań (69)

Literatura

• Y. Sommerville and P. Sawyer. RequirementsEngineering. A Good Practice Guide. Wiley &Sons, 1997.

• S. Adolph, P. Bramble, A. Cockburn, and A.Pols. Patterns for Effective Use Cases. Addison-Wesley, 2002.

• A. Cockburn. Writing Effective Use Cases.Addison-Wesley, 2003.