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).
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.
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.