Requirement Data Object

Id: unique identifier of a given Requirement

Name: short description/title of a given Requirement

Description: represents the more detailed description and statements of a given Requirement

Purpose: purpose of the Requirement

Type: identifies the category of a Requirement, such as functional, security, compliance, data privacy, service level, performance, and availability

Status: status of the Requirement

Reference: reference to the related authoritative sources such as Policies, regulatory requirements, security standards, etc.

Priority: the priority of a Requirement

Owner: person or team that owns the Requirement statement

Version: version of the Requirement specification

Product Backlog Item to Requirement (n:m): a Product Backlog Item is mapped to one or more Requirements (e.g., feature or user story) to track how the Requirement is fulfilled/realized

Requirement to Product Design (n:m): one or more Requirements will be used to define the required behavior from the Product Design

Requirement to Requirement (n:m): Requirements can be mapped to other Requirements (recursive and/or hierarchical)

Requirement to Test Case (1:n): a Requirement is traced to one or more Test Cases to ensure stated needs or conditions have been successfully delivered or met

Policy to Requirement (n:m): Requirements may be sourced from Policies or may reference Policies in order to remain in compliance with previously agreed Policies for an organization

Requirement to Portfolio Backlog Item (n:m): Requirements can be associated with one or more Portfolio Backlog Items

Requirement to Defect (n:m): a Defect can be associated with one or more Requirements