Atrybuty a wymagania

Dokumentowanie informacji o wymaganiach w sposób strukturalny pozwala na zapewnienie, że żadne potrzebne dane nie zostaną pominięte oraz zapewnia możliwość łatwego dotarcia przez analizującego wymagania do informacji mu potrzebnych.

Jednym ze sposobów strukturalnego dokumentowania wymagań jest przypisanie wymaganiom atrybutów mających określone znaczenie oraz ustalone możliwe wartości. Aby umożliwić jednolity strukturalny opis wymagań należy w projekcie stosować jeden schemat dla danego typu wymagań (funkcjonalnych, jakościowych, ograniczeń) zawierający definicję atrybutu, jego opis oraz możliwe wartości dla tego atrybutu. Zawartość atrybutów w schemacie powinna być dostosowana do aktualnie realizowanego projektu.

W zależności od wykorzystywanych narzędzi atrybuty wymagań mogą być określane w postaci tabeli lub formatek udostępnianych przez narzędzie wspierające inżynierię wymagań.

Podstawowe typy atrybutów dla wymagań to:

  • Identyfikator: Krótki, unikalny identyfikator dla wymagania.
  • Nazwa: Krótka unikalna nazwa wymagania określająca jego znaczenie.
  • Opis: Opis wymagania zawierający jego treść.
  • Autor: Oznaczenie autora wymagania.
  • Źródło: Oznaczenie źródła wymagania.
  • Stabilność: Oznaczenie przybliżonej stabilności wymagania. Stabilność określa wymaganie w zależności od możliwości zmian tego wymagania.
  • Krytyczność: Oszacowanie możliwości wpływu na działanie systemu w przypadku nieprawidłowego zaimplementowania wymagania.
  • Priorytet: Określa rangę wymagania, które może zostać wykorzystana do ustalenia kolejności implementacji, czy wpływu na akceptację tworzonego systemu.

Dodatkowe typy atrybutów dla wymagań to:

  • Osoba odpowiedzialna: Określa osoby, grupy interesariuszy, czy też jednostki organizacyjne odpowiedzialne za zawartość wymagania.
  • Typ wymagania: Określa typ wymagania, który jest definiowany w zależności od przyjętego schematu (np. funkcjonalne, rodzaj wymagania jakościowego).
  • Status w odniesieniu do zawartości: Może określać status zawartości wymagania (np. idea, koncepcja, pełna zawartość).
  • Status w odniesieniu do walidacji: Określa aktualny status walidacji (np. niezaakceptowane, zaakceptowane, poprawiane).
  • Status w odniesieniu do negocjacji: Określa aktualny status negocjacji wymagania (np. propozycja, uzgodnione, konflikt).
  • Trudność: Określa wysiłek potrzebny do zaimplementowania wymagania (np. niska, średnia, wysoka).
  • Uwarunkowania prawne: Określa poziom uwarunkowań prawnych dla tego wymagania.
  • Powiązania: Określa powiązania do innych wymagań.
  • Dodatkowe informacje: Atrybut ten może określać dodatkowe informacje o wymaganiu potrzebne podczas inżynierii wymagań, np. informację na temat przebiegu negocjacji dotyczącej wymagania.

Nadawanie priorytetów wymaganiom wiąże się z określeniem celu w jakim te priorytety są nadawane. W zależności od celu dla określania priorytetów dla wymagań stosuje się różne kryteria do oceny priorytetu.

Typowe kryteria brane pod uwagę podczas nadawania priorytetów:

  • Koszt implementacji
  • Ryzyko
  • Straty spowodowane nieprawidłowym zaimplementowaniem
  • Zmienność
  • Ważność dla interesariuszy
  • Czas potrzebny na implementację

Podczas nadawania priorytetów wymaganiom trzeba mieć na uwadze zaangażowanie odpowiednich interesariuszy oraz ocenę wymagań na tym samym poziomie szczegółowości.

Tekst zainspirowany książką: Klaus Pohl, Chris Rupp „Requirements engineering fundamentals : a study guide for the Certified Professional for Requirements Engineering exam : foundation level”, IREB compliant Wydawnictwo: Rocky Nook Inc, 2011

Podobne wpisy
Przypadki użycia są łatwiejsze do zrozumienia niż diagramy BPMN

Jakiś czas temu napotkałem ciekawe wyniki badań, które zostały opracowane w Polsce. Instytut Informatyki Politechniki Poznańskiej wykonał badania, w których  więcej

Jesienny The Rational Edge ezine

Właśnie ukazał się jesienny The Rational Edge ezine (http://ibm.com/developerworks/ecma/campaign/er.jsp?id=376126&imid=68950291&end). Dla fanów RSA jest bardzo ciekawy artykuł, w którym Steve Arnold więcej

Podstawowe dobre praktyki inżynierii 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ć więcej

Ś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ć więcej

Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Scroll to Top