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?
Z nowym rokiem uzupełniłem kilka wpisów, które były niedokończone a które miały się ukazać w grudniu. Pierwsze dwa tygodnie były dość pracowite dla mnie. Jedno z zadań z jakiego myślę, że wywiązałem należycie się to autorskie szkolenie zakresu gromadzenia i zarządzania wymaganiami w Enterprise Architect. Dlaczego myślę, że wywiązałem się należycie. W testach z wiedzy przed i po szkoleniu widać progres u każdego z uczestników szkolenia. Ponadto w ankietach oceniających szkolenie otrzymałem dobre i bardzo dobre noty. Innym ciekawym przedsięwzięciem w jakim mogłem uczestniczyć to współpraca z polskim instytutem badawczym. Pomagałem im, i mam nadzieję, że w nowym roku także będę to robił, w zakresie budowy architektury złożonego systemu (sprzęt + oprogramowanie) oraz zarządzaniem wymaganiami na ten system. Zadanie to jest tym bardziej ciekawe, że jest to jeden z ostatnich polskich instytutów z polską myślą inżynierską. To rzadkość na polskim rynku, a dla mnie satysfakcja z pracy z rewelacyjnymi polskimi inżynierami, specjalistami w swojej dziedzinie, praktykami w każdym calu. W tym instytucie tworzą się na prawdę innowacyjne polskie produkty.
Przymiotnik polski powtórzyłem celowo kilka razy.
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.
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…
W zeszłym tygodniu na jednym ze spotkań dotyczącego projektu o dość sporej wartości dostałem pytanie: Dlaczego do większych projektów do zarządzania wymaganiami rekomenduję IBM Rational RequisitePro? Oponent argumentował, że to drogi produkt a wejście w niego “spycha” w dość kosztowną platformę Rational. Pozornie miał rację. Otóż w przypadku małych firm i niewielkich projektów wystarczą narzędzia konkrecyjne takiej jak choćby plug-in do jednego z najbardziej popularnych narzędzi CASE Enterprise Architecta o nazwie RaQuest. Niestety wydajność i możliwości wspomnianego tandemu (EA i RaQuest) są dość ograniczone (co wiem z praktyki).
Osobiście lubię stosować RequistePro zwłaszcza przy większych projektach gdyż pozwala on na :
Oczywiście narzędzie może nie jest tanie, ale daje tyle wartości dodanej i pomaga uniknąć tylu trudności, że wydane pieniądze zwracają się wielokrotnie. Zdaje się, że wyszła mi przesłodzona laurka. Na szczęście dla mnie to prawdziwe cechy aplikacji (sprawdzone osobiście w projektach). Jeśli ktoś chciałby się przekonać w praktyce “na własne oczy” proszę o kontakt – mogę zrobić prezentację możliwości narzędzia lub szkolenie.
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ń.
Poniżej opisane wskazówki to podstawowe dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać tutaj.
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.
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ń.
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.
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.
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.
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.
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.
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.
Wszystkie prawa zastrzeżone 
modesto group All rights reserved
