Ian Sommerville i Pete Sawyer w „Requirements Engineering: A Good Practice Guide” opisali, ponad 15 lat temu, 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ń. W moim mniemaniu te dobre praktyki nie tracą na aktualności. Dotyczą one następujących obszarów:
- dokument specyfikacji wymagań,
- pozyskiwanie wymagań,
- analiza i negocjacja wymagań,
- opisywanie wymagań,
- modelowanie systemu,
- weryfikacja wymagań,
- zarządzanie wymaganiami,
- systemy krytyczne.
Natomiast biorąc po uwagę kryteria złożoności i kosztów wprowadzenia dobrych praktyk, wyodrębniony został podział praktyk na trzy grupy wg zaawansowania:
- praktyki podstawowe
- praktyki średnio zaawansowane
- praktyki zaawansowane
Dobre praktyki stanowią podstawę do oceny poziomu dojrzałości procesów inżynierii wymagań w organizacji. Zakres wspomnianych dobrych praktyk opisałem w ramach wyżej zdefiniowanych obszarów.
Zarządzanie wymaganiami – podstawowe dobre
Dokument specyfikacji wymagań
Zdefiniuj standardową strukturę dokumentu. Dokument wymagań powinien mieć ustandaryzowaną w danej organizacji strukturę. Ma to ułatwić i przyspieszyć czytelnikom zaznajamianie się z dokumentem ze względu na znajomość struktury i rozkładu treści.
Wyjaśnij jak korzystać z dokumentu. Dokument specyfikacji wymagań powinien zawierać sekcję wyjaśniającą sposób korzystania z dokumentu przez różne grupy adresatów. Powinny zostać wymienione sekcje przeznaczone dla poszczególnych grup, co ułatwi im i przyspieszy zapoznanie się z treścią dokumentu.
Załącz podsumowanie wymagań. Dokument specyfikacji powinien zawierać rozdział podsumowujący założenia systemu i prezentujący podstawowe jego wymagania. Pozwala to czytelnikom uzyskać szerszy obraz systemu i umożliwia odwoływanie się do później szczegółowo zdefiniowanych wymagań oraz przyspiesza ich wyszukiwanie.
Odnieś się do analizy biznesowej. Dokument specyfikacji powinien zawierać rozdział uzasadniający potrzebę budowy systemu i odwołujący się do celów organizacji dla której jest on przeznaczony. Pomaga to w uzasadnianiu wystąpienia pewnych wymagań oraz pozwala na ocenę zmian wprowadzanych w wymaganiach w odniesieniu do celów organizacji.
Zdefiniuj specjalizowane terminy. Dokument powinien zawierać słownik terminów specjalistycznych i specyficznych dla domeny systemu. Pomaga to w uniknięciu nieporozumień terminologicznych zarówno wśród autorów jak i czytelników. Poszerza także krąg potencjalnych czytelników.
Zadbaj o czytelną strukturę dokumentu. Dokument powinien mieć czytelną i jasną strukturę pozwalającą ograniczyć czas potrzebny na przegląd dokumentu i znajdowanie w nim informacji. Podnosi to ogólną efektywność osób korzystających z dokumentu. Zaleca się m.in. używanie szerokich marginesów, spójnych nagłówków, list i wypunktowań oraz diagramów w miejsce opisów słownych.
Pomóż czytelnikowi znaleźć informacje. Aby przyspieszyć korzystanie z dokumentu przez cały przebieg projektu powinien on zawierać indeks oraz spis treści, tabel, rysunków itp. Pomaga to znacznie w znajdowaniu potrzebnych informacji i zwiększa produktywność jego użytkowników.
Spraw, by dokument był łatwy do zmian. Dokument powinien być łatwy do zmian dla jego użytkowników i nie wymagać przebudowy i ponownego rozpowszechnienia w całości. Zapewnić to powinien zarówno sposób napisania jak i publikacji. Ogranicza to koszty wynikające z rozpowszechniania oraz opóźnień.
Oceń wykonalność systemu. Ocena wykonalności systemu powinna zostać przeprowadzona przed pozyskiwaniem wymagań, aby ocenić możliwość i wykonalność implementacji systemu oraz określić jej opłacalność. Może się okazać bowiem, że system nie spełnia tych warunków i jego realizacja niesie duże ryzyko niepowodzenia.
Pozyskiwanie wymagań
Bądź wyczulony na czynniki organizacyjne i polityczne. Czynniki specyficzne dla organizacji i strategiczne mogą mieć wpływ na przebieg pozyskiwania wymagań. Ich identyfikacja może pomóc w wyróżnieniu ważnych źródeł wymagań i samych wymagań systemowych.
Zidentyfikuj udziałowców systemu i skonsultuj się z nimi. Udziałowcami nazywamy wszelkie osoby zaangażowane w tworzenie systemu i te w przyszłości czerpiące z niego korzyści. Identyfikacja tych osób może pomóc w pozyskiwaniu wymagań ujawniając potencjalne ich źródła.
Przechowuj źródła wymagań. Źródła wymagań określają powiązanie z informacją, na podstawie której uzyskano wymaganie. Źródłem mogą być udziałowcy systemu, korespondencja, standardy jakości, dokumentacja techniczna i inne. Przechowywanie źródeł przyspiesza ponowne konsultacje przy zmianach wymagań.
Zdefiniuj środowisko działania. Zdefiniowanie środowiska operacyjnego, czyli docelowej platformy sprzętowej i programowej, ale również innych systemów komunikujących się i wykorzystujących budowany system pozwala na ograniczenie odtworzenie tych warunków w testach a poza tym umożliwia ujawnienie wymagań narzucanych przez systemy zewnętrzne.
Użyj celów biznesowych przy pozyskiwaniu wymagań. Cele biznesowe to abstrakcyjne i ogólne cele stawiane budowanemu systemowi, wymagane aby zadowolić zleceniodawcę. Spełnienie ich jest podstawowym warunkiem użyteczności systemu i stanowi bazę do specyfikowania wymagań.
Analiza i negocjacja wymagań
Zdefiniuj granice systemu. Granice systemu są definiowane przez ograniczony zbiór wymagań systemowych. Należy oddzielić od nich wymagania procesów związanych z systemem i inne będące poza zakresem systemu. Eliminuje się w ten sposób niejasności w późniejszym procesie analizy wymagań.
Użyj list kontrolnych do analizy wymagań. Lista kontrolna powinna zawierać pytania sprawdzające problemy napotkane w dotychczasowym doświadczeniu analizy wymagań. Zweryfikowanie każdego wymagania przy pomocy takiej listy zapobiega omyłkom i przyspiesza proces analizy wymagań.
Udostępnij oprogramowanie do wspomagania negocjacji. Proces analizy i negocjacji wymagań powinien być wspomagany przy użyciu np. poczty elektronicznej i elektronicznych tablic ogłoszeń lub nawet systemów konferencyjnych i wspomagających pracę grupową. Celem jest zapewnienie ciągłego dialogu udziałowców i analityków, aby uniknąć nieporozumień, przy jednoczesnym ograniczeniu kosztów spotkań.
Zaplanuj postępowanie w przypadku konfliktów i ich rozwiązywanie. W każdym projekcie należy oczekiwać konfliktów pomiędzy wymaganiami i należy się na to z góry przygotować planując spotkania negocjacyjne z udziałowcami systemu w celu ustalania kompromisów. Takie spotkania skracają czas fazy analizy wymagań.
Nadaj priorytety wymaganiom. W czasie analizy i negocjacji należy nadać wymaganiom priorytety zgodnie z ich ważnością dla udziałowców i dla powodzenia systemu jako całości. Wyróżnić można w ten sposób najważniejsze wymagania i na nich skoncentrować negocjacje.
Opisywanie wymagań
Zdefiniuj szablony do opisywania wymagań. Szczegółowy opis wymagań powinien być budowany z wykorzystaniem standardowego szablonu zawierającego miejsce na wszystkie istotne informacje. Wymagania są łatwiejsze do czytania i do pozyskiwania. Unika się możliwości ominięcia ważnych informacji.
Użyj prostego i ścisłego języka. Jeżeli używany jest opis słowny wymagania powinien on być wyrażony przy pomocy prostego i ścisłego języka z wykluczeniem skomplikowanych zdań i niejasnego słownictwa. Ułatwia to szybkie czytanie i zrozumienie wymagań a przez to ogranicza koszty.
Użyj diagramów w odpowiedni sposób. Diagramy powinny być włączone w opis wymagania, aby wyrazić informacje strukturalne, powiązania pomiędzy elementami opisu lub opisać sekwencje zdarzeń. Są one łatwiej i szybciej zrozumiałe niż opis słowny. Mogą być także powtórnie używane w przyszłości.
Uzupełnij opis słowny wymagań innymi opisami. Niektóre wymagania najlepiej jest opisywać przy pomocy równań matematycznych, notacji projektowych lub nawet języków programowania. Opis taki nie powinien jednak zastępować, a jedynie uzupełniać opis słowny, czyniąc go bardziej ścisłym.
Modelowanie systemu
Opracuj komplementarne modele systemu. Aby nie komplikować modelu systemu, lepiej jest go podzielić na mniejsze modele prezentujące różne jego aspekty. Wymusza to analizę z uwzględnieniem tych różnych aspektów, ujawnia przeoczenia oraz ułatwia komunikację z udziałowcami reprezentującymi określony punkt widzenia na system.
Zamodeluj otoczenie systemu. Aby lepiej zrozumieć wymagania, dobrze jest zamodelować otoczenie systemu, czyli inne systemy komunikujące się z budowanym. Wymusza to wyspecyfikowanie sposobu tej komunikacji oraz wskazuje możliwości wykorzystania systemów zewnętrznych. Pomaga także czytelnikom w zrozumieniu związku z wspomaganymi procesami biznesowymi.
Zamodeluj architekturę systemu. Zawsze powinno się zamodelować architekturę systemy ukazującą w jaki sposób system jest podzielony na podsystemy i w jaki sposób przebiega komunikacja pomiędzy podsystemami. Pomaga to w podziale wymagań oraz identyfikacji często stwarzających problemy wymagań dotyczących kilku podsystemów.
Weryfikacja wymagań
Sprawdź, czy dokument jest zgodny z twoim standardem. Zanim dokument wymagań zostanie rozpowszechniony powinien zostać sprawdzony pod względem zgodności z przyjętym standardem dokumentów. Oszczędza to czas osób później przeglądających, gdyż mogą się one skoncentrować na stronie merytorycznej dokumentu.
Zorganizuj formalne przeglądy wymagań.Wymagania systemowe powinny być regularnie przeglądane przez wyznaczoną grupę osób. Spotykają się oni, aby dyskutować problemy związane z wymaganiami i ustalać sposoby radzenia sobie z nimi. Spotkanie takie powinno się koncentrować na samych problemach a nie na odpowiedzialności za nie.
Użyj wielodyscyplinarnych zespołów do przeglądu wymagań.Do przeglądu wymagań najlepsze są zespoły złożone z przedstawicieli różnych grup udziałowców i ekspertów. Zapewnia to różnorodność punktów widzenia oraz dokładność i wszechstronność przeglądu wymagań. Udziałowcy czują się w ten sposób zaangażowani w proces specyfikacji wymagań oraz bardziej otwarci na zmiany.
Zdefiniuj listy kontrolne dla wymagań. Listy kontrolne pozwalają na uporządkowanie weryfikacji wymagań oraz koncentrację uwagi osób sprawdzających na najbardziej krytycznych atrybutach wymagań. Pozwalają także wdrożyć niedoświadczone osoby, np. użytkowników końcowych w proces weryfikacji.
Przypisz wymaganiom identyfikatory. Nadaj wymaganiom identyfikatory lub numery, aby łatwiej się było do nich odwoływać z innych części specyfikacji wymagań lub innych dokumentów. Wspomaga to proces śledzenia propagacji zmian i ułatwia stosowanie narzędzi automatyzujących zarządzanie wymaganiami.
Zarządzanie wymaganiami
Zdefiniuj reguły zarządzania wymaganiami. Reguły zarządzania wymaganiami powinny definiować cele i procedury tego procesu oraz standardy do podążania. Wskazują one osobom zaangażowanym w projekt co i w jaki sposób powinno być wykonywane. Uniezależnia się w ten sposób od indywidualnej wiedzy.
Zdefiniuj reguły śledzenia propagacji zmian. Część reguł zarządzania wymaganiami stanowić powinny informacje dotyczące zakresu i sposobu śledzenia propagacji zmian. Powinny one zawierać informacje jak znaleźć powiązania pomiędzy wymaganiami oraz pomiędzy wymaganiami a projektem, dokumentacją itp. Wpływają one na kontrolę jakości i kosztów i ułatwiają zmiany w systemie.
Utrzymuj podręcznik śledzenia propagacji zmian. Dodatkiem do dokumentu specyfikacji wymagań powinien być podręcznik śledzenia propagacji zmian. Zawiera on informacje o zastosowanych regułach śledzenia oraz same informacje o powiązaniach wymagań i innych elementów. Zebranie tych informacji w jednym miejscu ułatwia zmiany i aktualizację oraz przyspiesza dostęp do nich.
Systemy krytyczne
Utwórz listę kontrolną dla wymagań bezpieczeństwa. Powinna zostać sporządzona lista kontrolna specyficzna dla dziedziny zastosowań systemu, aby sprawdzić kompletność specyfikacji wymagań. Jeżeli istotne jest bezpieczeństwo i niezawodność, ta lista też powinna się koncentrować na tych atrybutach. Uniknąć w ten sposób można ominięcia istotnych dla tych cech systemu wymagań.
Zaangażuj osoby zewnętrzne w proces zatwierdzania wymagań. Należy zawsze włączyć zewnętrznych ekspertów, nie biorących udziału w pozyskiwaniu i negocjacji wymagań, w proces zatwierdzania wymagań dla systemów krytycznych. Wnoszą oni świeży punkt widzenia i nie mają uprzedzeń wyniesionych z poprzednich faz.
Zarządzanie wymaganiami – średnio zaawansowane dobre praktyki
Pozyskiwanie wymagań
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ń.
Analiza i negocjacja 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ń.
Opisywanie 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.
Modelowanie systemu
Użyj metod obiektowych do modelowania systemu. Metody obiektowych to zbiór notacji, wskazówek oraz reguł definiowania modelu systemu. Tak zdefiniowane modele mogą być uzupełnieniem specyfikacji wymagań, standaryzują 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 interesariuszy a systemem. Zawsze powinno się udokumentować powiązania pomiędzy opisem słownym wymagań uzyskanym od interesariuszy a szczegółowymi modelami specyfikującymi system. Ułatwia to śledzenie propagacji zmian oraz sprawdzanie modeli i powiązanych z nimi wymagań.
Weryfikacja 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.
Zarządzanie wymaganiami
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.
Systemy krytyczne
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ń.
Zarządzanie wymaganiami – zaawansowane dobre praktyki
Wykorzystaj 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 błędów. Informacje i szczegóły na temat błędó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ń błędów. Przy pomocy zebranych informacji o błędach 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.
