.png)
Zapraszam do lektury kolejnej części cyklu publikacji mających na celu omówienie głównych punktów w programie certyfikacji IREB oraz wspierających przygotowanie do egzaminu certyfikacyjnego IREB CPRE. W tej części publikacji kontynuujemy temat artefaktów i praktyk dokumentowania wymagań.
Artefakty oparte na języku naturalnym
Podstawowym środkiem komunikacji i dokumentacji wymagań jest język naturalny. Jego zastosowanie jest szerokie, ponieważ nie wymaga specyficznych szkoleń ani umiejętności - komunikujemy się w ten sposób na co dzień. Niestety, język naturalny ma swoje ograniczenia i wady, takie jak niejednoznaczność komunikatu. W inżynierii wymagań potrzebna jest precyzja, dlatego język naturalny często zawodzi.
Rozważmy przykład wymagania: "System ma generować potwierdzenie". Na pierwszy rzut oka zdanie wydaje się zrozumiałe. Jednak z punktu widzenia precyzyjnej inżynierii wymagań, pojawiają się wiele niewiadomych. Jakie potwierdzenie system ma generować? Potwierdzenie czego? W jakiej formie? Co dokładnie oznacza "generować"?
W powyższym przykładzie deklaracji wymagania występuje kilka usterek:
Niejasne sformułowania, takie jak "generować".
Niekompletny opis, brak precyzji co do potwierdzenia.
Podczas dokumentowania wymagań za pomocą języka naturalnego warto zwrócić uwagę na kilka wskazówek:
Piszemy krótkie, zwięzłe, poprawne gramatycznie zdania.
Stosujemy jednolitą i zrozumiałą terminologię.
Unikamy pojęć, które mogą być niejednoznaczne w danym kontekście.
Należy również unikać:
Niekompletnych opisów, takich jak "system umożliwia wyszukiwanie" - wyszukiwanie czego?
Nieokreślonych rzeczowników, np. "system umożliwia zapisanie danych" - jakich konkretnie danych?
Niekompletnych warunków, np. "w przypadku przelewu do kwoty 10 000 system nie nalicza prowizji" - co jeśli przelew przekroczy 10 000?
Niekompletnych porównań, np. "system ma być szybszy" - szybszy niż co?
Użycia uniwersalnych kwantyfikatorów, np. "system umożliwia zapisanie wszystkich danych" - czy chodzi o wszystkie bez wyjątku?
Nominalizacji, np. "system umożliwia zarządzanie użytkownikami" - pod słowem "zarządzanie" kryje się wiele operacji na użytkownikach, takich jak tworzenie, edycja, aktywacja.
Artefakty oparte na szablonach
Aby zredukować ryzyko związane z opisem wymagań w języku naturalnym stosujemy szablony. IREB wskazuje trzy podstawowe rodzaje szablonów:
Szablony wyrażeń
Szablony formularzy
Szablony dokumentów
Szablony wyrażeń
Szablony wyrażeń (ang. phrase template) zapewniają predefiniowaną strukturę składniową dla wyrażeń, które opisują konkretne wymaganie, takie jak pojedyncze wymaganie lub historia użytkownika (user story). Dzięki temu podejściu możemy specyfikować wymagania w sposób jednolity i zgodny z ustalonymi standardami, czy to zewnętrznymi, pochodzącymi z uznanych źródeł, czy też standardami danej organizacji. Przykładem takiego szablonu jest popularne "user story".
Standardowa forma "user story" wygląda następująco:
Jako <rola> chcę <wymaganie>, aby <korzyść>.
Przykładem wymagania opisanego za pomocą "user story" może być:
Jako użytkownik chcę mieć możliwość dodania produktu do koszyka, aby móc go później kupić.
Innym przykładem jest szablon wyrażenia pochodzący ze standardu ISO/IEC/IEEE 29148 [ISO29148].
[<Warunek>] <Podmiot> <Akcja> <Obiekty> [<Ograniczenie>]
Przykładem wymagania opisanego za pomocą tego szablonu może być:
Kiedy płatność się udała, system wyświetla komunikat potwierdzenia zakupu oraz zmienia status zamówienia na "opłacone".
Szablony formularzy
Szablony formularzy (ang. form template) zawierają zestaw predefiniowanych pól, które należy wypełnić. Przykładowe formularze mogą być używane do pisania przypadków użycia lub mierzalnych wymagań jakościowych.
I tak, szablon specyfikacji przypadku użycia może zawierać następujące dane:
Nazwa <Krótki czasownikowy zwrot czynny>
Warunek wstępny <Warunki, które muszą zachodzić przy uruchomieniu przypadku użycia>
Warunek zakończenia dla sukcesu <Stan po pomyślnym zakończeniu przypadku użycia>
Warunek zakończenia dla niepowodzenia <Stan po nieudanym wykonaniu przypadku użycia>
Główny aktor <Nazwa aktora>
Pozostali aktorzy <Lista innych zaangażowanych aktorów, jeśli istnieją>
Wyzwalacz <Zdarzenie, które inicjuje wykonanie przypadku użycia>
Przebieg normalny <Opis głównego scenariusza sukcesu w sekwencji kroków:
<krok 1> <akcja 1>
<krok 2> <akcja 2>
...
<krok n> <akcja n> ... >
Alternatywne przebiegi <Opis alternatywnych lub wyjątkowych kroków, z odniesieniem do odpowiednich kroków w przebiegu normalnym>
Rozszerzenia <Rozszerzenia do przebiegu normalnego (jeśli istnieją), z odniesieniem do rozszerzanych kroków w przebiegu normalnym>
Powiązane informacje <Opcjonalne pole dla dodatkowych informacji, takich jak wydajność, częstotliwość lub dodatkowe uwagi dotyczące przypadku użycia>
Poniżej prezentuję wypełniony przykład:
Bardzo interesującą formą szablonu formularza jest specyfikacja w notacji Planguage autorstwa Toma Gilba. Dzięki tej notacji jesteśmy w stanie precyzyjnie określić wymagania, korzystając z predefiniowanych tagów.
Rozważmy wymaganie:
"System powinien w co najmniej 95 procentach przypadków wyświetlić każdy zdefiniowany raport księgowy w czasie nie dłuższym niż 8 sekund."
To samo wymaganie wyspecyfikowane przy użyciu Planguage będzie wyglądać następująco:
TAG: Performance.Report.ResponseTime (Wydajność.Raport.CzasOdpowiedzi)
AMBITION: Szybki czas odpowiedzi w generowaniu raportów księgowych na platformie użytkownika.
SKALA: Czas trwania w sekundach pomiędzy naciśnięciem klawisza Enter lub kliknięciem OK w celu żądania raportu, a rozpoczęciem wyświetlania raportu.
POMIAR: Test stopera przeprowadzony na 30 raportach testowych, które reprezentują zdefiniowany profil operacyjny użytkowania dla księgowego w biurze terenowym.
CEL: Nie więcej niż 8 sekund dla 95 procent raportów. Kierownik biura terenowego.
ROZCIĄGNIĘCIE: Nie więcej niż 2 sekundy dla raportów predefiniowanych, 5 sekund dla wszystkich raportów.
ŻYCZENIE: Nie więcej niż 1,5 sekundy dla wszystkich raportów.
DEFINICJA: Platforma użytkownika bazowa obejmuje procesor czterordzeniowy, 8GB RAM, system Windows 8, działanie Query Gen 3.3, pojedynczego użytkownika, co najmniej 50 procent pamięci RAM i 70 procent mocy procesora systemu wolnych, prędkość połączenia sieciowego co najmniej 30 Mbps.
Szablony dokumentów
Szablony dokumentów zapewniają predefiniowaną strukturę dla różnych rodzajów dokumentów wymagań, czyli produktów pracy zawierających wiele wymagań. Istnieje wiele typów dokumentacji wymagań, w zależności od specyfikowanych wymagań. Na przykład, istnieją specyfikacje wymagań biznesowych, systemowych, funkcjonalnych oraz zabezpieczeń.
Przykładem szablonów dokumentów są oferowane przez ISO29148 oraz starszą wersję standardu IEEE 830. Innym popularnym przykładem jest szablon Volere opracowany przez Suzanne i Jamesa Robertsonów. Poniżej przedstawiam listę zagadnień objętych szablonem Volere, zgodnie z informacją na stronie produktu:
Cel projektu
Interesariusze
Narzucone ograniczenia
Konwencje nazewnictwa i terminologia
Istotne fakty i założenia
Zakres prac
Model danych biznesowych i słownik danych
Zakres produktu
Wymagania funkcjonalne
Wymagania dotyczące wyglądu i interfejsu użytkownika
Wymagania dotyczące użyteczności i ergonomii
Wymagania dotyczące wydajności
Wymagania operacyjne i środowiskowe
Wymagania dotyczące utrzymania i wsparcia
Wymagania dotyczące bezpieczeństwa
Wymagania kulturowe
Wymagania zgodności
Otwarte kwestie
Gotowe rozwiązania
Nowe problemy
Zadania
Migracja do nowego produktu
Ryzyka
Koszty
Dokumentacja użytkownika i szkolenie
Oczekujące
Pomysły na rozwiązania
Szablon Volere Zwykle dostosowuje się do własnych potrzeb. Poniżej przedstawiam skróconą wersję szablonu dostosowaną do potrzeb konkretnego projektu.
Informacje o projekcie: Informacje wprowadzające o projekcie, jego celu i kontekście. Identyfikacja i analiza interesariuszy. Cele i zadania projektu.
Ograniczenia projektu: Ograniczenia budżetowe, czasowe i zasobowe. Wymagania prawne, regulacyjne i zgodności. Ograniczenia techniczne i ograniczenia.
Charakterystyka użytkowników: Profile użytkowników, role i persona, aby uzyskać wgląd w różne typy użytkowników. Cele, oczekiwania i preferencje użytkowników.
Zasady biznesowe: Zasady biznesowe definiujące określone polityki, przepisy lub wytyczne do wdrożenia. Ograniczenia lub warunki, które określają, jak system powinien się zachowywać.
Założenia i zależności: Założenia dokonane podczas gromadzenia wymagań. Zależności zewnętrzne, takie jak systemy zewnętrzne lub integracje.
Hierarchia funkcji: Hierarchiczny podział wymagań funkcjonalnych, zorganizowany na moduły lub podsystemy.
Wymagania funkcjonalne: Szczegółowe wymagania funkcjonalne opisujące, co system powinien robić. Przypadki użycia, scenariusze lub historie użytkowników do uwiecznienia interakcji użytkownika i zachowania systemu.
Wymagania niefunkcjonalne: Cechy jakościowe lub ograniczenia niefunkcjonalne, takie jak wydajność, skalowalność, bezpieczeństwo i dostępność.
Słownik: Definicje kluczowych terminów i terminologii specyficznej dla dziedziny stosowanej w specyfikacji wymagań.
Podsumowując, korzystanie z szablonów ułatwia proces tworzenia dokumentacji wymagań, zapewniając spójność i uporządkowanie informacji. Dzięki nim można uniknąć pominięcia ważnych elementów i zwiększyć czytelność dokumentów wymagań. Warto jednak pamiętać, że szablon to tylko narzędzie, a jakość dokumentacji zależy od treści wypełnianych w nim. Szablon to tylko szablon, pomaga zapewnić jakość, ale jej nie gwarantuje. Można mieć znakomity szablon, ale jeśli treść dokumentu jest słaba, to nie gwarantuje wysokiej jakości dokumentacji.
W kolejnej części cyklu omówimy tematy modelowania wymagań.
Comments