Struktura dokumentów wymagań cz. 1

Dokumenty wymagań zawierają dużą ilość różnych informacji. Aby umożliwić sprawne posługiwanie się tym dokumentem powinien on spełniać pewne standardy dotyczące jego układu oraz treści. W trakcie tworzenia dokumentu wymagań inżynierowie powinni określić i stosować określoną strukturę dokumentu. Struktura ta powinna być dopasowana do właściwości danego projektu i przestrzegać ograniczeń na niego nałożonych. Inżynierowie wymagań podczas tworzenia specyfikacji wymagań mogą skorzystać ze standaryzowanych struktur dokumentów lub zdefiniować własną strukturę, która będzie dopasowana do specyficznych wymagań projektu i interesariuszy.

Zalety wykorzystania standaryzowanych struktur dokumentów są ogólnie znane. Robiąc małe zestawienie to zastosowanie standardowej struktury pozwala na:

  • szybsze włączenie nowych członków zespołu do projektu
  • odnalezienie w dokumentacji pożądanej informacji
  • selektywne czytanie oraz selektywną walidację dokumentu wymagań
  • automatyczną weryfikację dokumentu wymagań (np. w odniesieniu do kompletności)
  • proste ponowne użycie zawartości dokumentu wymagań

Struktury dokumentów są znane metodyk i standardów. Nie mniej jednak poniżej krótkie zestawienie.

Rational Unified Process

W metodyce Rational Unified Process, która jest często stosowana podczas tworzenia systemów wykorzystując metody zorientowane obiektowo, klient przygotowuje model biznesowy organizacji. Model biznesowy zawiera artefakty środowiska biznesowego, w którym funkcjonuje organizacja. Artefaktami mogą być np. zasady biznesowe, biznesowe przypadki użycia, czy też cele biznesowe. Na podstawie tego modelu inżynierowie wymagań przygotowują specyfikację wymagań na system (SRS), która dokumentuje wszystkie wymagania dla tworzonego oprogramowania. Struktura specyfikacji wymagań na system jest bardzo zbliżona do struktury proponowanej przez standard IEEE 830.

Standard IEEE 830-1998

Standard IEEE 830-1998 dotyczy zalecanych praktyk dla specyfikacji wymagań na system. Standard ten sugeruje podział dokumentu wymagań na trzy główne rozdziały:

  • Rozdział zawierający informacje wprowadzające (np. cele systemu, granicę systemu)
  • Rozdział zawierający ogólny opis tworzonego systemu (np. perspektywa systemu, opis przyszłych użytkowników, ograniczenia dla procesu produkcyjnego)
  • Rozdział zawierający specyfikację wymagań (np. wymagania funkcjonalne, wymagania dotyczące wydajności, interfejsy)

V-Model

V-Model opisuje proces tworzenia oprogramowania zaproponowany przez niemieckie Federalne Ministerstwo Spraw Wewnętrznych, które definiuje różne struktury dla dokumentu wymagań w zależności od tego, kto je tworzy.

Specyfikacja Wymagań Klienta jest tworzona przez klienta i zawiera opis pożądanych przez klienta cech dotyczących tworzonego oprogramowania. Może także zawierać wymagania użytkowników oraz ograniczenia systemu i procesu produkcyjnego. Odpowiada na pytanie: Co jest robione i po co?

Specyfikacja Wymagań na System bazuje na Specyfikacji Wymagań Klienta i zawiera propozycję implementacji zaproponowanych przez klienta potrzeb. Specyfikacja Wymagań na System jest uściśleniem wymagań i ograniczeń zawartych w Specyfikacji Wymagań Klienta.

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

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

Projektowanie hurtowni danych w oparciu o język UML

Nowoczesne zarządzanie organizacjami XXI wieku to sprawne i dynamiczne decyzje oparte na zebranych i dobrze przeanalizowanych danych. Coraz to większe więcej

Eclipse Process Framework

Jestem zwolennikiem wolnego oprogramowania i wszystkich narzędzi, które pozwalają na pracę przy podobnych standardach co narzędzia płatne. Dlaczego? W każdym więcej

Reklama
MODESTO - licencje Enterprise Architect
Scroll to Top