1. Dobre praktyki inżynierii wymagań
1.1. Koncepcja dobrych praktyk
Ian Sommerville i Pete Sawyer zaproponowali ciekawą metodę oceny i doskonalenia procesów inżynierii wymagań [1]. 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:
§ dokument specyfikacji wymagań,
§ pozyskiwanie wymagań,
§ analiza i negocjacja wymagań,
§ opisywanie wymagań,
§ modelowanie systemu,
§ weryfikacja wymagań,
§ zarządzanie wymaganiami,
§ systemy krytyczne.
Każdej dobrej praktyce przypisano ponadto oszacowania kosztów wprowadzenia do organizacji oraz jej stosowania. Biorąc pod uwagę te kryteria wyodrębniony został podział praktyk na trzy grupy wg zaawansowania powiązanego z tymi kosztami i poziomem skomplikowania:
§ praktyki podstawowe,
§ praktyki średniozaawansowane,
§ praktyki zaawansowane.
Dobre praktyki stanowią podstawę do oceny poziomu dojrzałości procesów inżynierii wymagań w organizacji. Oszacowania takiego można dokonać przy pomocy kryteriów opisanych w punkcie 2.3. Stanowi ono ponadto podstawę do procesu ciągłego ulepszania procesów inżynierii wymagań i pozwala wznieść całą organizację na wyższy poziom dojrzałości np. w odniesieniu do modelu CMM [2], którego inżynieria wymagań stanowi ważny element.
1.2. Opis dobrych praktyk Sommerville’a i Sawyera
W sekcji tej przedstawiony zostanie krótki opis wszystkich dobrych praktyk wraz z oszacowaniami, brzmieniem oryginalnym oraz identyfikatorem nadanym w pracy [1].
1.2.1 Praktyki podstawowe
|
3.1 |
Dokument specyfikacji wymagań |
||
|
Zdefiniuj standardową strukturę dokumentu |
Koszt wprowadzenia: |
Średni-wysoki |
|
|
Define standard document structure |
Koszt stosowania: |
Niski |
|
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.
|
3.2 |
Dokument specyfikacji wymagań |
||
|
Wyjaśnij jak korzystać z dokumentu |
Koszt wprowadzenia: |
Bardzo niski |
|
|
Explain how to use document |
Koszt stosowania: |
Bardzo niski |
|
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.
|
3.3 |
Dokument specyfikacji wymagań |
||
|
Załącz podsumowanie wymagań |
Koszt wprowadzenia: |
Bardzo niski |
|
|
Include a summary of the requirements |
Koszt stosowania: |
Niski |
|
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.
|
3.4 |
Dokument specyfikacji wymagań |
||
|
Odnieś się do analizy biznesowej |
Koszt wprowadzenia: |
Średni-wysoki |
|
|
Make a business case for the system |
Koszt stosowania: |
Niski |
|
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.
|
3.5 |
Dokument specyfikacji wymagań |
||
|
Zdefiniuj specjalizowane terminy |
Koszt wprowadzenia: |
NISKI |
|
|
Define specialised terms |
Koszt stosowania |
Niski-ŚREDNI |
|
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.
|
3.6 |
Dokument specyfikacji wymagań |
||
|
Zadbaj o czytelną strukturę dokumentu |
Koszt wprowadzenia: |
NISKI |
|
|
Lay out the document for readibility |
Koszt stosowania: |
Niski |
|
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.
|
3.7 |
Dokument specyfikacji wymagań |
||
|
Pomóż czytelnikowi znaleźć informacje |
Koszt wprowadzenia: |
BARDZO NISKI |
|
|
Help readers find information |
Koszt stosowania: |
NISKI-ŚREDNI |
|
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.
|
3.8 |
Dokument specyfikacji wymagań |
||
|
Spraw, by dokument był łatwy do zmian |
Koszt wprowadzenia: |
NISKI |
|
|
Make the document easy to change |
Koszt stosowania: |
BARDZO NISKI |
|
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ń.
|
4.1 |
Pozyskiwanie wymagań |
||
|
Oceń wykonalność systemu |
Koszt wprowadzenia: |
NISKI |
|
|
Assess system feasibility |
Koszt stosowania: |
NISKI-ŚREDNI |
|
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.
|
4.2 |
Pozyskiwanie wymagań |
||
|
Bądź wyczulony na czynniki organizacyjne i polityczne |
Koszt wprowadzenia: |
NISKI |
|
|
Be sensitive to organisational & political considerations |
Koszt stosowania: |
Bardzo niski |
|
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.
|
4.3 |
Pozyskiwanie wymagań |
||
|
Zidentyfikuj udziałowców systemu i skonsultuj się z nimi |
Koszt wprowadzenia: |
bardzo NISKI |
|
|
Identify and consult stakeholders |
Koszt stosowania: |
niski |
|
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.
|
4.4 |
Pozyskiwanie wymagań |
||
|
Przechowuj źródła wymagań |
Koszt wprowadzenia: |
NISKI |
|
|
Record requirement sources |
Koszt stosowania: |
niski |
|
Ź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ń.
|
4.5 |
Pozyskiwanie wymagań |
||
|
Zdefiniuj środowisko działania |
Koszt wprowadzenia: |
NISKI |
|
|
Define operating environment |
Koszt stosowania: |
niski |
|
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.
|
4.6 |
Pozyskiwanie wymagań |
||
|
Użyj celów biznesowych przy pozyskiwaniu wymagań |
Koszt wprowadzenia: |
NISKI |
|
|
Use business concerns to drive requirements elicitation |
Koszt stosowania: |
niski |
|
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ń.
|
5.1 |
Analiza i negocjacja wymagań |
||
|
Zdefiniuj granice systemu |
Koszt wprowadzenia: |
NISKI |
|
|
Define system boundaries |
Koszt stosowania: |
niski |
|
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ń.
|
5.2 |
Analiza i negocjacja wymagań |
||
|
Użyj list kontrolnych do analizy wymagań |
Koszt wprowadzenia: |
NISKI-średni |
|
|
Use checklists for requirements analysis |
Koszt stosowania: |
niski |
|
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ń.
|
5.3 |
Analiza i negocjacja wymagań |
||
|
Udostępnij oprogramowanie do wspomagania negocjacji |
Koszt wprowadzenia: |
NISKI-średni |
|
|
Provide software to support negotiations |
Koszt stosowania: |
NISKI-średni |
|
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ń.
|
5.4 |
Analiza i negocjacja wymagań |
||
|
Zaplanuj postępowanie w przypadku konfliktów i ich rozwiązywanie |
Koszt wprowadzenia: |
NISKi |
|
|
Plan for conflicts and conflict resolution |
Koszt stosowania: |
NISKi |
|
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ń.
|
5.5 |
Analiza i negocjacja wymagań |
||
|
Nadaj priorytety wymaganiom |
Koszt wprowadzenia: |
NISKi |
|
|
Prioritise requirements |
Koszt stosowania: |
NISKi |
|
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.
|
6.1 |
Opisywanie wymagań |
||
|
Zdefiniuj szablony do opisywania wymagań |
Koszt wprowadzenia: |
średni |
|
|
Define standard templates for describing requirements |
Koszt stosowania: |
NISKi |
|
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.
|
6.2 |
Opisywanie wymagań |
||
|
Użyj prostego i ścisłego języka |
Koszt wprowadzenia: |
dosyć niski |
|
|
Use language simply & concisely |
Koszt stosowania: |
NISKi-średni |
|
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.
|
6.3 |
Opisywanie wymagań |
||
|
Użyj diagramów w odpowiedni sposób |
Koszt wprowadzenia: |
niski |
|
|
Use diagrams appropriately |
Koszt stosowania: |
NISKi |
|
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.
|
6.4 |
Opisywanie wymagań |
||
|
Uzupełnij opis słowny wymagań innymi opisami |
Koszt wprowadzenia: |
bardzo niski |
|
|
Supplement natural language with other descriptions of requirements |
Koszt stosowania: |
NISKi |
|
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.
|
7.1 |
Modelowanie systemu |
||
|
Opracuj komplementarne modele systemu |
Koszt wprowadzenia: |
niski-średni |
|
|
Develop complementary system models |
Koszt stosowania: |
średni |
|
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.
|
7.2 |
Modelowanie systemu |
||
|
Zamodeluj otoczenie systemu |
Koszt wprowadzenia: |
niski |
|
|
Model the system’s environment |
Koszt stosowania: |
niski |
|
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.
|
7.3 |
Modelowanie systemu |
||
|
Zamodeluj architekturę systemu |
Koszt wprowadzenia: |
niski-średni |
|
|
Model the system architecture |
Koszt stosowania: |
niski |
|
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.
|
8.1 |
Weryfikacja wymagań |
||
|
Sprawdź, czy dokument jest zgodny z twoim standardem |
Koszt wprowadzenia: |
niski |
|
|
Check that the requirements document meets your standard |
Koszt stosowania: |
niski |
|
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.
|
8.2 |
Weryfikacja wymagań |
||
|
Zorganizuj formalne przeglądy wymagań |
Koszt wprowadzenia: |
średni |
|
|
Organise formal requirements inspections |
Koszt stosowania: |
średni |
|
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.
|
8.3 |
Weryfikacja wymagań |
||
|
Użyj wielodyscyplinarnych zespołów do przeglądu wymagań |
Koszt wprowadzenia: |
niski |
|
|
Use multidisciplinary teams to review requirements |
Koszt stosowania: |
niski |
|
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.
|
8.4 |
Weryfikacja wymagań |
||
|
Zdefiniuj listy kontrolne dla wymagań |
Koszt wprowadzenia: |
niski-Średni |
|
|
Define validation checklists |
Koszt stosowania: |
niski |
|
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.
|
9.1 |
Zarządzanie wymaganiami |
||
|
Przypisz wymaganiom identyfikatory |
Koszt wprowadzenia: |
bardzo niski |
|
|
Uniquely identify each requirement |
Koszt stosowania: |
bardzo niski |
|
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.
|
9.2 |
Zarządzanie wymaganiami |
||
|
Zdefiniuj reguły zarządzania wymaganiami |
Koszt wprowadzenia: |
średni |
|
|
Define policies for requirements management |
Koszt stosowania: |
niski |
|
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.
|
9.3 |
Zarządzanie wymaganiami |
||
|
Zdefiniuj reguły śledzenia propagacji zmian |
Koszt wprowadzenia: |
średni |
|
|
Define traceability policies |
Koszt stosowania: |
średni-wysoki |
|
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.
|
9.4 |
Zarządzanie wymaganiami |
||
|
Utrzymuj podręcznik śledzenia propagacji zmian |
Koszt wprowadzenia: |
niski |
|
|
Maintain a traceability manual |
Koszt stosowania: |
średni-wysoki |
|
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.
|
10.1 |
Systemy krytyczne |
||
|
Utwórz listę kontrolną dla wymagań bezpieczeństwa |
Koszt wprowadzenia: |
niski-średni |
|
|
Create safety requirements checklists |
Koszt stosowania: |
niski |
|
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 wyamagań.
|
10.2 |
Systemy krytyczne |
||
|
Zaangażuj osoby zewnętrzne w proces zatwierdzania wymagań |
Koszt wprowadzenia: |
niski |
|
|
Involve external reviewers in the validation process |
Koszt stosowania: |
niski-średni |
|
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.
1.2.2 Praktyki średniozaawansowane
|
4.7 |
Pozyskiwanie wymagań |
||
|
Poszukaj ograniczeń narzucanych przez dziedzinę problemu |
Koszt wprowadzenia: |
niski |
|
|
Look for domain constraints |
Koszt stosowania: |
średni |
|
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.
|
4.8 |
Pozyskiwanie wymagań |
||
|
Przechowuj uzasadnienia wymagań |
Koszt wprowadzenia: |
niski |
|
|
Record requirements rationale |
Koszt stosowania: |
niski-średni |
|
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.
|
4.9 |
Pozyskiwanie wymagań |
||
|
Zbieraj wymagania z wielu punktów widzenia |
Koszt wprowadzenia: |
średni-wysoki |
|
|
Collect requirements from multiple viewpoints |
Koszt stosowania: |
średni |
|
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
|
4.10 |
Pozyskiwanie wymagań |
||
|
Prototypuj trudno zrozumiałe wymagania |
Koszt wprowadzenia: |
średni |
|
|
Prototype poorly understood requirements |
Koszt stosowania: |
niski-wysoki |
|
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.
|
4.11 |
Pozyskiwanie wymagań |
||
|
Stosuj scenariusze użycia |
Koszt wprowadzenia: |
dosyć wysoki |
|
|
Use scenarios |
Koszt stosowania: |
niski |
|
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.
|
4.12 |
Pozyskiwanie wymagań |
||
|
Zdefiniuj procesy operacyjne |
Koszt wprowadzenia: |
dosyć wysoki |
|
|
Define operational processes |
Koszt stosowania: |
średni |
|
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ń.
|
5.6 |
Analiza i negocjacja wymagań |
||
|
Klasyfikuj wymagania używając podejścia wielowymiarowego |
Koszt wprowadzenia: |
niski-średni |
|
|
Classify requirements using using a multidimensional approach |
Koszt stosowania: |
średni |
|
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ń.
|
5.7 |
Analiza i negocjacja wymagań |
||
|
Użyj macierzy interakcji, by wykryć nakładające się wymagania i konflikty |
Koszt wprowadzenia: |
niski |
|
|
Use interaction matrices to find conflicts and overlaps |
Koszt stosowania: |
średni-wysoki |
|
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ń.
|
6.5 |
Opisywanie wymagań |
||
|
Specyfikuj wymagania ilościowo |
Koszt wprowadzenia: |
niski-średni |
|
|
Specify requirements quantitatively |
Koszt stosowania: |
niski-średni |
|
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.
|
7.4 |
Modelowanie systemu |
||
|
Użyj metod strukturalnych do modelowania systemu |
Koszt wprowadzenia: |
średni-wysoki |
|
|
Use structured methods for system modelling |
Koszt stosowania: |
średni |
|
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.
|
7.5 |
Modelowanie systemu |
||
|
Użyj słownika danych |
Koszt wprowadzenia: |
średni |
|
|
Use a data dictionary |
Koszt stosowania: |
niski |
|
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.
|
7.6 |
Modelowanie systemu |
||
|
Udokumentuj powiązania pomiędzy wymaganiami udziałowców a systemem |
Koszt wprowadzenia: |
niski |
|
|
Document the links between stakeholder requirements and system |
Koszt stosowania: |
średni |
|
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ń.
|
8.5 |
Weryfikacja wymagań |
||
|
Skonstruuj prototyp do animacji wymagań |
Koszt wprowadzenia: |
średni-wysoki |
|
|
Use prototyping to animate requirements |
Koszt stosowania: |
średni-wysoki |
|
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.
|
8.6 |
Weryfikacja wymagań |
||
|
Napisz szkic podręcznika użytkownika |
Koszt wprowadzenia: |
niski |
|
|
Write a draft user manual |
Koszt stosowania: |
średni |
|
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.
|
8.7 |
Weryfikacja wymagań |
||
|
Zaproponuj testy dla wymagań |
Koszt wprowadzenia: |
niski |
|
|
Propose requirements test cases |
Koszt stosowania: |
średni |
|
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.
|
9.5 |
Zarządzanie wymaganiami |
||
|
Użyj bazy danych do zarządzania wymaganiami |
Koszt wprowadzenia: |
średni-wysoki |
|
|
Use a database to manage requirements |
Koszt stosowania: |
średni |
|
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.
|
9.6 |
Zarządzanie wymaganiami |
||
|
Zdefiniuj reguły zarządzania zmianami |
Koszt wprowadzenia: |
średni-wysoki |
|
|
Define change management policies |
Koszt stosowania: |
niski-średni |
|
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.
|
9.7 |
Zarządzanie wymaganiami |
||
|
Zidentyfikuj globalne wymagania systemowe |
Koszt wprowadzenia: |
niski |
|
|
Identify global system requirements |
Koszt stosowania: |
niski |
|
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.
|
10.3 |
Systemy krytyczne |
||
|
Zidentyfikuj i zanalizuj zagrożenia |
Koszt wprowadzenia: |
średni-wysoki |
|
|
Identify and analyse hazards |
Koszt stosowania: |
średni-wysoki |
|
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.
|
10.4 |
Systemy krytyczne |
||
|
Wywiedź wymagania bezpieczeństwa z analizy zagrożeń |
Koszt wprowadzenia: |
niski |
|
|
Derive safety requirements from hazard analysis |
Koszt stosowania: |
średni |
|
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.
|
10.5 |
Systemy krytyczne |
||
|
Sprawdź wymagania funkcjonalne wobec wymagań bezpieczeństwa |
Koszt wprowadzenia: |
niski |
|
|
Cross-check operational and functional requirements against safety requirements |
Koszt stosowania: |
średni |
|
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ń.
1.2.3 Praktyki zaawansowane
|
4.13 |
Pozyskiwanie wymagań |
||
|
Używaj te same wymagania wielokrotnie |
Koszt wprowadzenia: |
średni-wysoki |
|
|
Reuse requirements |
Koszt stosowania: |
średni |
|
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.
|
5.8 |
Analiza i negocjacja wymagań |
||
|
Przypisz ryzyko wymaganiom |
Koszt wprowadzenia: |
średni |
|
|
Assess requirements risks |
Koszt stosowania: |
średni |
|
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.
|
8.8 |
Weryfikacja wymagań |
||
|
Opracuj słowną parafrazę systemu |
Koszt wprowadzenia: |
średni-wysoki |
|
|
Paraphrase system models |
Koszt stosowania: |
średni |
|
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.
|
9.8 |
Zarządzanie wymaganiami |
||
|
Zidentyfikuj wymagania ulotne |
Koszt wprowadzenia: |
niski |
|
|
Identify volatile requirements |
Koszt stosowania: |
niski |
|
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.
|
9.9 |
Zarządzanie wymaganiami |
||
|
Przechowuj odrzucone wymagania |
Koszt wprowadzenia: |
niski |
|
|
Record rejected requirements |
Koszt stosowania: |
niski |
|
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.
|
10.6 |
Systemy krytyczne |
||
|
Wyspecyfikuj system przy użyciu metod formalnych |
Koszt wprowadzenia: |
wysoki |
|
|
Specify systems using formal specification |
Koszt stosowania: |
wysoki |
|
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.
|
10.7 |
Systemy krytyczne |
||
|
Zbieraj opisy wypadków |
Koszt wprowadzenia: |
wysoki |
|
|
Collect incident experience |
Koszt stosowania: |
wysoki |
|
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.
|
10.8 |
Systemy krytyczne |
||
|
Wyciągaj wnioski z doświadczeń wypadków |
Koszt wprowadzenia: |
wysoki |
|
|
Learn from incident experience |
Koszt stosowania: |
wysoki |
|
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.
|
10.9 |
Systemy krytyczne |
||
|
Dbaj o kulturę bezpieczeństwa w organizacji |
Koszt wprowadzenia: |
wysoki |
|
|
Establish an organisational safety culture |
Koszt stosowania: |
Żadny |
|
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.
1.3. Ewaluacja dojrzałości procesów inżynierii wymagań
Ocena dojrzałości procesów inżynierii wymagań ma na celu poznanie własnych procesów oraz wskazanie słabych punktów wymagających poprawy. Poprawa inżynierii oprogramowania jest procesem ciągłym, wykonywanym iteracyjnie aż do osiągnięcia pożądanego poziomu dojrzałości. Proces ten został przedstawiony na rysunku 2.1.
Rysunek 2.1: Proces poprawy procesów inżynierii wymagań
Szacowanie zaproponowane przez Sommerville’a i Sawyera opiera się na ocenach punktowych stosowania poszczególnych dobrych praktyk w organizacji i analizie sum tych punktów w określonych kategoriach.
Każdej dobrej praktyce zostaje przypisana jedna z ocen, a co za tym idzie wartość punktowa jej realizacji wg zestawienia w tabeli 2.1.
Tabela 2.1: Kryteria oceny powszechności stosowania praktyk
|
Stosowanie praktyki |
Wartość punktowa |
|
|
Czynności związane z praktyką stanowią udokumentowany standard w organizacji i ich stosowanie jest sprawdzane w procesie zapewniania jakości |
3 |
|
|
Praktyka w częstym użyciu |
Czynności związane z praktyką są bardzo często wykonywane, nie są jednak obowiązkowe |
2 |
|
Praktyka stosowana wedle woli |
Wybór czynności związanych z praktyką jest pozostawiony w gestii managerów projektów |
1 |
|
Praktyka nigdy nie stosowana |
Czynności związane z praktyką nie są nigdy wykonywane lub jedynie bardzo rzadko |
0 |
Kolejnym krokiem oceny dojrzałości procesów inżynierii wymagań jest zsumowanie punktów z praktyk podstawowych oraz średniozaawanasowanych i zaawansowanych. Uzyskane w ten sposób liczby należy porównać z kryteriami oceny dojrzałości zaproponowanymi przez Sommerville’a i Sawyera i przedstawionymi na rysunku 2.2.
Rysunek 2.2: Poziomy dojrzałości procesów inżynierii wymagań wg Sommerville’a i Sawyera [1]
Koncepcja poziomów dojrzałości procesów nawiązuje do modelu CMM [2] obejmującego wszystkie obszary inżynierii oprogramowania lecz nie oferującego tak ścisłych kryteriów ewaluacji w odniesieniu do inżynierii wymagań. Poziomy dojrzałości w obu modelach, mimo podobnych nazw, obejmują inny zakres działalności organizacji.
Zaprezentowane podejście nie jest doskonałe. Jedną z jego wad jest kompensacyjność – może się zdarzyć, że dwie organizacje sklasyfikowane na tym samym poziomie będą stosowały bardzo różne praktyki inżynierii wymagań. Model ten jednak dobrze się nadaje do poprawy procesów poprzez dostatecznie precyzyjne zdefiniowanie zbioru dobrych praktyk.