W sieci pojawił się nowy blog o wymaganiach (http://owymaganiach.pl/). Cieszy mnie ta inicjatywa, Pana Jakuba Jurkiewicza – doktoranta na Politechnice Poznańskiej, gdyż w sieci jest mało zasobów na temat inżynierii oprogramowania a te zapowiadają się sensownie. Z pierwszych wpisów polecam teksty o przypadkach użycia. Powodzenia 
W Enterprise Architect jest dedykowany do gromadzenia wymagań element zwany “Requirement”
Jest to bardzo komfortowa sytuacja, ale co zrobić gdy nie ma takiego elementu w danym narzędziu CASE?
Kilka porad odnośnie przypadków użycia i aktorów.
Przypadek użycia nie dostarcza funkcjonalności aktorowi
Problem: Często oznacza to, że każdy przypadek użycia sam w sobie nie dostarcza wartości aktorowi.
Rada: Proszę połączyć fragmentaryczne przypadki użycia w kompletną sekwencję takich fragmentów, które łącznie zapewnią wartość aktorom.
Stanowiska pracy jako aktorzy
Problem: Powszechnym błędem jest tworzenie aktorów, którzy odzwierciedlają stanowiska pracy organizacji. Tworząc aktorów, którzy odzwierciedlają stanowiska pracy przypadki użycia będą kształtowane, aby wspomagać stanowiska pracy a nie pracę, którą mają wykonać jednostki.
Rada: Jeżeli aktorzy odzwierciedlają stanowiska pracy, proszę zmodyfikować aktorów, aby dostosować ich do czynności, które mają wykonać w pracy.
Urządzenia jako aktorzy
Problem: Proste urządzenia, takie jak skanery i drukarki nie pomagają zbytnio w identyfikacji przynoszących wartość przypadków użycia. Aktorzy, których należy szukać, są to ludzie oraz inne systemy, które współdziałają z systemem.
Rada: Jeżeli aktorów określono dla urządzeń, trzeba odszukać osobę, która "stoi za" urządzeniem i zasugerować ją jako aktora.
W trakcie szkicowania procesów biznesowych należy zdefiniować wspólne słownictwo, przy użyciu najpopularniejszych terminów i wyrażeń w zakresie problemu. Następnie należy konsekwentnie wykorzystywać wspólne słownictwo we wszystkich tekstowych opisach biznesu. W ten sposób, utrzymują Państwo spójne opisy tekstowe i unika się nieporozumień wśród członków projektu dot. stosowania i znaczenia terminów. Słownictwo powinno mieć formę słownika.
Aby znaleźć wspólne terminy w zakresie problemu, należy uwzględnić terminy stosowane w trakcie rozmowy, o co chodzi w biznesie. Warto skupić się na terminach opisujących następujące koncepcje:
Każdym termin jest na ogół opisywany jako rzeczownik wraz z definicją. Terminy powinny być podane w liczbie pojedynczej, "zamówienie" oraz "zadanie", a nie "zamówienia" czy "zadania".
I na koniec oczywiste i najważniejsze: wszystkie zainteresowane strony powinny porozumieć się co do zdefiniowania terminów.
Każdemu zalecam stosowanie przypadków użycia – także a może przede wszystkim w projektach Agile.
Poniżej zamieszczam trzy podstawowe zalety, które myślę, że przekonają do używania przypadków użycia w projektach Agile
1. Dzięki przypadkom użycia zyskuje się kontekst
Nawet w projektach Agile przypadki użycia są mechanizmem umożliwiającym firmom osiąganie celów. Podejście, które wykorzystuje ustrukturyzowane wymagania dostarcza ten kontekst. Innymi słowy przypadki użycia pozwalają określić z jakimi systemami lub innymi zasobami będzie współpracował nasz system.
2. Dzięki przypadkom użycia zyskuje się informacje dot. zakresu projektu
Z politycznego punktu widzenia największym problemem z uruchomieniem projektu Agile w organizacjach typu waterfall jest niewłaściwe ustalenie oczekiwań wobec projektu w zakresie jego trwania i kosztów. Ustalenie oczekiwań i w ten sposób zabezpieczenie zarówno finansowania jak i wsparcia dla projektu może być ważniejsze niż samo wykonanie.
Ustalanie zakresu polega przede wszystkim na ustalaniu priorytetów celów osób zamawiających produkt oraz ustaleniu ram czasowych i harmonogramów dostarczania.
Kluczem jest tutaj dokonanie wpierw przeglądu zakresu projektu, a potem jego dokładne zrozumienie poprzez przeprowadzanie iteracji.
3. Dzięki przypadkom użycia zyskuje się naturalną dekompozycję
Właściwym podejściem do definiowania przypadków użycia dla tworzenia oprogramowania przy użyciu metody Agile to zacząć od definicji zakresu. Kiedy już zakres zostanie zdefiniowany należy zdefiniować nazwy przypadków użycia a następnie stopniowo nadawać priorytety i definiować bardziej szczegółowo przypadki użycia podczas gdy są one włączane do harmonogramu projektu. Dokonujesz także refaktoryzacji przypadków użycia, w miarę potrzeb konsolidując i definiując podrzędne przypadki użycia, oraz definiując, jeśli zachodzi taka potrzeba, rozszerzeń przypadków użycia.
Obecnie znajdujemy się w dziwnej sytuacji – są user stores (zwane w języku polskim historyjkami użytkownika) i scenariusze przypadków użycia z czego te ostatnie można podzielić na przypadki użycia formalne i nieformalne a także streszczenia przypadków użycia. Czym one się różnią, a w czym są takie same?
Przypadki użycia, scenariusze przypadków użycia i user stories dokumentują opis tego jak produkt ma być używany. Różnią się one, w kontinuum, pod względem ilości dodatkowych danych wymaganych dla stworzenia każdego z nich.
Scenariusze przypadków użycia to nieco inny przypadek. Podobnie jak user story, scenariusz przypadku użycia opisuje jedną ścieżkę przez wielościeżkowy przypadek użycia. Warto więc połączyć słabość przypadku użycia (wysoka ilość danych dodatkowych) ze słabością user story (ograniczony kontekst) co w konsekwencji da dość spójny i zwinny oraz pomocny artefakt.
Jakiś czas temu na stronie Pana Kowalczykiewicza http://www.cs.put.poznan.pl/kkowalczykiewicz/ był ciekawy tekst na temat dobrych praktyk w inżynierii wymagań. Obecnie ta strona jest wyłączona. Z tego też powodu pozwalam sobie na publikację tego tekstu, który (co mnie zadziwia) miałem w swoim archiwum. Tekst ten został odrobinę przeformatowany.
Ian Sommerville i Pete Sawyer zaproponowali ciekawą metodę oceny i doskonalenia procesów inżynierii wymagań. Opiera się ona na wyodrębnieniu dobrych praktyk, czyli czynności będących pożądanymi elementami wzorcowego procesu inżynierii wymagań. Autorzy starali się przy tym objąć całość problematyki inżynierii wymagań. Dobre praktyki reprezentują więc następujące obszary działalności:
Biorąc pod uwagę te kryteria wyodrębniony został podział praktyk na trzy grupy wg zaawansowania powiązanego z tymi kosztami i poziomem skomplikowania:
Dobre praktyki stanowią podstawę do oceny poziomu dojrzałości procesów inżynierii wymagań w organizacji. Zakres wspomnianych dobrych praktyk opisałem w poniższych punktach:
Każdy inżynier oprogramowania dobrze wie jak ważnym dokumentem jest Słownik w trakcie procesu wytwórczego oprogramowania a szczególnie w jego pierwszych fazach. Bez zrozumienia pojęć czy skrótów, którymi posługuje się klient z na pewno nie rozwiążemy jego problemu.
Enterprise Architect (EA) udostępnia nam funkcjonalność związaną z budową Słownika (menu Project > Documentation > Glossary…). W okienku możesz definiować listę terminów używanych w projekcie i kojarzyć z nimi opisy ich znaczenia jak również generować prosty raport zwany Słownikiem.
Jednak użytkownik tworzący model w EA z reguły korzysta z podręcznego elementu Notes do opisu znaczenia definiowanych elementów modelu. Jest on zwykle widoczny w trakcie pracy w EA i kojarzony z każdym elementem modelu a więc poręczniejszy niż okienko Słownika.
Jak więc wygenerować raport odpowiadający Słownikowi z notatek modelu? Jak się okazuje nie jest to trudne w EA. Rozważmy przypadek, że chcemy wygenerować Słownik z notatek wszystkich Aktorów w postaci: nazwa aktora i jego opis. W tym celu:
Enterprise Architect, moim zdaniem, nie jest najszczęśliwszym narzędziem do zarządzania wymaganiami. Nie jest też beznadziejny.
W projektach dla mnie ważne jest to jak wymagania są mapowane na konkretne przypadki użycia (PU). Pozwala to stwierdzić, które PU są bardziej złożone, wymagają większej uwagi i są ważniejsze dla klienta. Aby to stwierdzić trzeba zmapować PU z konkretnymi wymaganiami. W tym celu dodaję wymagania na diagram i łączę asocjacja z PU a jeśli diagram jest nieczytelny to związki dodaje w macierzy. Wygenerowanie macierzy…
Na jednym ze spotkań z klientem otrzymałem pytanie: Czy przypadki użycia są jedyną formą specyfikacji systemu? Moja odpowiedź była jasna: NIE. Przypadki użycia są niewątpliwie pożyteczne dla specyfikowania systemów, ale nie pozwalają w pełni opisać wymagań. Przypadki użycia stanowią swoiste agregaty dla wymagań, pozwalają dokonać pewnej dekompozycji wymagań na poszczególne funkcje systemu. Niestety ich rola jest ograniczona wskazania roli jakie podejmą aktorzy w systemie a przecież bardzo często wymagania pochodzą od ludzi, którzy nie zbliżą się do granic systemu. Co więcej wymagania poza funkcjonalnością obejmują aspekty techniczne (np.: interfejsy). Z moich doświadczeń wynika, że często aby w pełni wyspecyfikować funkcjonalność systemu trzeba poznać proces biznesowy czyli zbudować model biznesowych przypadków użycia za pomocą techniki odmiennej, ale zgodnej z modelem przypadków użycia. Oznacza to, że poza modelem przypadków użycia powstają inne artefakty (dokumenty) przede wszystkim takie jak wspomniany model lub inna dokumentacja procesów biznesowych oraz obligatoryjnie specyfikacja wymagań funkcjonalnych i niefunkcjonalnych.
Poniżej opisane wskazówki to zaawansowane dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać tutaj.
Używaj te same wymagania wielokrotnie
Zaleca się, w miarę możliwości, używanie lub modyfikacje pozyskanych w czasie budowy innych, podobnych lub obejmujących tę samą dziedzinę zastosowań projektów. Oszczędza to koszty i czas ponownego odkrywania wymagań oraz pozwala na uniknięcie wcześniejszych błędów. Ponowne użycie wymagań może prowadzić do wykorzystania np. istniejącego kodu.
Przypisz ryzyko wymaganiom
Zaleca się przeprowadzenie analizy ryzyka dla każdego wymagania lub ich grup. Analiza ta określa prawdopodobieństwo i rodzaj problemów, skutki i środki zaradcze. Ujawnia to wymagania potrzebujące zmian w celu ograniczenia tego ryzyka lub bardziej szczegółowego wyspecyfikowania.
Opracuj słowną parafrazę systemu
W przypadku używania notacji formalnych lub graficznych do prezentacji modelu systemu, przekształć ją także w opis w języku naturalnym. Oszczędza to czas udziałowców systemu weryfikujących ten model i nie narzuca im znajomości notacji.
Zidentyfikuj wymagania ulotne
Powinno się wyróżnić wymagania ulotne, czyli najbardziej podatne na zmiany. W razie możliwości należy przewidzieć jakiego rodzaju to mogą być zmiany. Ich wyodrębnienie wpływa na planowanie i projektowanie systemu, by zredukować te zagrożenia.
Przechowuj odrzucone wymagania
Przechowuj listę wymagań, które zostały odrzucone w fazie analizy i negocjacji oraz dlaczego. Często zdarza się, że proponuje się je bowiem ponownie w czasie późniejszym. Ich przechowywanie może ograniczyć koszty ponownej analizy.
Wyspecyfikuj system przy użyciu metod formalnych
Metody formalne posługują się zapisem matematycznym oraz ustaloną składnią i regułami. Krytyczne części systemu powinny zostać wyspecyfikowane w taki sposób, aby uniknąć niejasności oraz skorzystać z możliwości dowiedzenia poprawności implementacji.
Zbieraj opisy wypadków
Informacje i szczegóły na temat wypadków, które zaszły we wcześniej dostarczonych systemach powinny być zbierane. Unaocznia to pomyłki, które zaszły wcześniej i pomaga w ich uniknięciu w przyszłości.
Wyciągaj wnioski z doświadczeń wypadków
Przy pomocy zebranych informacji o wypadkach należy sprawdzić wymagania funkcjonalne i wyszukać potencjalne zagrożenia bazując na przeszłych doświadczeniach, aby uniknąć podobnych sytuacji.
Dbaj o kulturę bezpieczeństwa w organizacji
Kultura bezpieczeństwa oznacza, że wszyscy w organizacji są świadomi roli jaką pełni bezpieczeństwo i czuje się odpowiedzialny jej zapewnienia. Łatwiej jest wtedy o ulepszanie dotychczas stosowanych procesów.
Poniżej opisane wskazówki to średniozaawansowane dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać tutaj.
Poszukaj ograniczeń narzucanych przez dziedzinę problemu
Domena budowanego systemu narzuca często dodatkowe wymagania, wynikają one z obowiązujących wymogów, przepisów oraz ograniczeń dziedziny. System musi je brać pod uwagę i spełniać. Gromadzenie tych ograniczeń może być przydatne przy budowie innego systemu z tej samej dziedziny.
Przechowuj uzasadnienia wymagań
Uzasadnienie wymagania podsumowuje przyczyny wyspecyfikowania wymagania oraz wyjaśnia adresowany problem i sposób jego rozwiązania. Uzasadnienie przyspiesza zrozumienie wymagania oraz pomaga w ocenie wpływu zmian ma wymaganie.
Zbieraj wymagania z wielu punktów widzenia
Ważnym elementem dla pozyskiwania wymagań jest identyfikacja punktów widzenia (ang. viewpoint) na system. Takie osobne punkty widzenia mogą mieć użytkownicy końcowi, managerowie czy też ograniczenia dziedziny systemu. Identyfikacja ich pomaga w kategoryzacji wymagań oraz wyszukiwaniu ważnych.
Prototypuj trudno zrozumiałe wymagania
Prototyp jest demonstracją działania systemu zbudowaną w celu ukonkretnienia wymagań udziałowców systemu. Jest to szczególnie istotne w przypadku niejasnych i trudnych do określenia wymagań dotyczących np. interfejsu użytkownika.
Stosuj scenariusze użycia
Scenariusz to zapis przykładowej interakcji użytkownika z systemem. Wskazywane są w nim oczekiwania użytkowników co do systemu. Pozwala to na łatwiejsze pozyskiwanie wymagań i żądanej funkcjonalności od użytkowników.
Zdefiniuj procesy operacyjne
Systemy komputerowe zazwyczaj mają na celu wspomaganie pewnych procesów zachodzących w organizacjach. Należy więc zdefiniować te procesy, aby lepiej zrozumieć budowany system. Prowadzi to do łatwiejszej identyfikacji udziałowców i samych wymagań.
Klasyfikuj wymagania używając podejścia wielowymiarowego
Zaleca się klasyfikowanie wymagań, aby znaleźć związane powiązania pomiędzy nimi. Najlepiej używać wiele sposobów kategoryzacji równolegle. Taki sposób nazywa się wielowymiarowym. Pozwala to znaleźć podobieństwa i konflikty pomiędzy wymaganiami oraz pomaga w śledzeniu propagacji zmian i znajdowaniu brakujących wymagań.
Użyj macierzy interakcji, by wykryć nakładające się wymagania i konflikty
Macierz interakcji posiada w wierszach i kolumnach wymagania, zaś na przecięciach relacje pomiędzy danymi dwoma wymaganiami. Może to być konflikt, zazębienie lub brak związku. Macierz taka wymusza analizę związków pomiędzy wszystkimi wymaganiami i stanowi dobry obiekt do negocjacji wymagań.
Specyfikuj wymagania ilościowo
W miarę możliwości wymagania (zazwyczaj niefunkcjonalne) powinny zawierać konkretne, mierzalne wartości opisywanych atrybutów. Przekazuje to precyzyjne informacje dla wykonawców oraz stanowi podstawę do testów akceptacyjnych systemu.
Użyj metod strukturalnych do modelowania systemu
Metody strukturalne to zbiór notacji, wskazówek oraz reguł definiowania modelu systemu. Tak zdefiniowane modele mogą być uzupełnieniem specyfikacji wymagań, ustandaryzowują dokumentację modeli oraz ułatwiają przejście to projektu systemu.
Użyj słownika danych
Wszystkie nazwy używane w modelach systemu powinny zostać umieszczone w słowniku wraz z opisem i innymi informacjami. Pozwala to ustalić wspólne nazewnictwo, szczególnie w wieloosobowych zespołach oraz wspomaga śledzenie propagacji zmian.
Udokumentuj powiązania pomiędzy wymaganiami udziałowców systemem
Zawsze powinno się udokumentować powiązania pomiędzy opisem słownym wymagań uzyskanym od udziałowców a szczegółowymi modelami specyfikującymi system. Ułatwia to śledzenie propagacji zmian oraz sprawdzanie modeli i powiązanych z nimi wymagań.
Skonstruuj prototyp do animacji wymagań
Stwórz prototyp systemu, aby zademonstrować pozyskane wymagania i uzyskać ich akceptację przez udziałowców systemu lub wskazówki dotyczące zmian. Prototyp pomaga udziałowcom w wizualizowaniu wymagań oraz zapobiega niejasnościom w wymaganiach.
Napisz szkic podręcznika użytkownika
Na podstawie specyfikacji systemu napisz szkicowy podręcznik użytkownika zawierający opis wszystkich aspektów funkcjonalności z uwzględnieniem założeń dotyczących interfejsu użytkownika. Pomaga to ujawnić możliwe problemu z użytkowaniem systemu.
Zaproponuj testy dla wymagań
Dla każdego wymagania zaproponuj jeden lub wiele testów sprawdzających, czy system spełnia dane wymaganie. Często ujawnia to brakujące informacje w wymaganiach a także pomaga w zaprojektowaniu i zaplanowaniu właściwych testów systemu.
Użyj bazy danych do zarządzania wymaganiami
Zaleca się zastosowanie bazy danych do przechowywania wymagań w miejsce formy papierowej. Baza taka jest łatwiejsza do utrzymywania, aktualizacji i przeszukiwania oraz utrzymywania informacji o powiązaniach. Dostęp i aktualizację może dokonywać wiele osób jednocześnie.
Zdefiniuj reguły zarządzania zmianami
Powinny zostać zdefiniowane jasne reguły proponowania, analizowania i akceptowania zmian w wymaganiach. Po uwzględnieniu zmiany tworzona jest nowa wersja danego wymagania. Zdefiniowanie tych reguł daje udziałowcom mechanizm wnoszenia poprawek, przy jednoczesnym uwzględnieniu i zaplanowaniu kosztów z tym związanych.
Zidentyfikuj globalne wymagania systemowe
Globalne wymagania systemowe określają istotne i pożądane cechy systemu jako całości. Nie są one związane z modułem czy podsystemem. Są też one dlatego najbardziej kosztowne do zmiany i wymagają konsultacji z wszystkimi udziałowcami. Ich znajomość pozwala na przewidzenie i zaplanowanie kroków wymaganych w przypadku zmian.
Zidentyfikuj i zanalizuj zagrożenia
Zagrożenie to stan systemu mogący doprowadzić do wypadku. W przypadku systemów krytycznych wymagane jest zebranie zagrożeń, ich możliwych przyczyn i konsekwencji. Stanowi to pierwszy krok w zapewnianiu bezpieczeństwa dla takich systemów.
Wywiedź wymagania bezpieczeństwa z analizy zagrożeń
Na podstawie analizy zagrożeń powinno się zawsze wprowadzić wymagania funkcjonalne unikania lub ograniczania skutków wypadków. Postępowanie zgodnie z tymi regułami podnosi znacznie bezpieczeństwo systemu.
Sprawdź wymagania funkcjonalne wobec wymagań bezpieczeństwa
Ciągle sprawdzaj wymagania funkcjonalne, czy nie wpływają na powstawanie nowych zagrożeń i czy nie rodzą się konflikty z wymaganiami zabezpieczającymi. Ma to na celu podniesienie bezpieczeństwa systemu i wyszukanie konfliktów wymagań.
Wszystkie prawa zastrzeżone 
modesto group All rights reserved
