Średniozaawansowane dobre praktyki inżynierii wymagań

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.

A. 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ń.

B. 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ń.

C. 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.

D. Modelowanie 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ń.

E. 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.

F. 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.

G. 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ń.

Technorati Tagi: zarządzanie wymaganiami
Podobne wpisy
Zintegrowane środowisko wytwarzania aplikacji web’owych na platformie .NET

W artykule przedstawiono opis pakietu narzędziowego VS.NET (Microsoft) z Rational XDE (IBM) do wytwarzania aplikacji webowych pracujących w środowisku urządzeń więcej

Rational Software Architect Pierwszy Krok

Technorati Tagi: Rational Software Architect,inżynieria oprogramowania W artykule zaprezentowano jak rozpocząć pracę z i opis elementów tego narzędzia CASE. Środowisko więcej

Wstęp do projektowania aplikacji w Rational Software Architect

Rational Software Architect jest kolejną po Rational Rose i Rational XDE generacją narzędzi wspierających twórców oprogramowania w czasie projektowania. RSA więcej

Rational Unified Process – Wstęp

Rational Unified Process jest zunifikowanym procesem wytwórczym oprogramowania dostarczającym praktycznych wskazówek, wzorców dokumentów i narzędzi, szablonów dokumentów oraz przykładów postępowania więcej

Reklama
MODESTO - licencje Enterprise Architect
Reklama
MODESTO - licencje Enterprise Architect
Przewijanie do góry