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

  • Wymagania – Zarządzanie wersjami Zmiany w wymaganiach wymaga ich wersjonowania.Wersje wymagań pomagają uzyskać dostęp do określonego stanu wymagania w trakcie życia oprogramowania. Najczęściej wersje wymagań określane są […]
  • Dokumentacja wymagań oparta na modelu Poza opisem słownym warto jest dokumentować wymagania w oparciu o model. Definicja: Model Model to abstrakcyjna reprezentacja istniejącej rzeczywistości lub rzeczywistości, która będzie […]
  • 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 […]
  • Cykl tworzenia oprogramowania w Rational Unified Process Technorati Tagi: Rational Unified Process,inżynieria oprogramowania,RUP Procesy, jakie są realizowane w czasie budowy oprogramowania, są zazwyczaj cykliczne. Systemy, w zależności od […]
  • Wprowadzenie do zarządzania wymaganiami–podstawowe definicje Wpisy na temat inżynierii wymagań zacznę od podstawowych definicji. Definicja: Wymaganie 1.Ograniczenie lub zdolność potrzebna użytkownikowi do rozwiązania problemu lub osiągnięcia […]
Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry