Requirement Functional Component

id EAID 168DEA01 781C 45e8 847A F23B668B0EED
Figure 1. Requirement Functional Component Model

Purpose

The Requirement functional component manages the Requirements of a product throughout its lifecycle. Requirements are associated with the Product Backlog Items managed in the Product Backlog. The Product Backlog manages all epics, features, and stories, which are short-lived, and closed once completed, while the Requirements are long-lived and provide the definitive specifications of the product. This definitive list of Requirements is also used for regression testing.

The Requirement functional component also tracks non-functional requirements, such as those related to security, risk, privacy, and compliance. These non-functional requirements are derived from the Policy functional component and are selected based upon the outcome of risk assessments such as a Security Impact Assessment (SIA) and Data Privacy Impact Assessment (DPIA). The relevant security and compliance Requirements should be added to the Requirement functional component. These Requirements are then linked to the Product Design, Product Backlog Items, and associated Test Cases. This ensures the product is designed according to the agreed Policies and enables full traceability on the compliance of the product against defined Policies and controls.

The Requirement functional component manages all the Requirements (both functional and non-functional requirements) for the different stakeholders such as those related to:

  • Business requirements

  • Security requirements (derived from Policies)

  • Requirements derived from SLOs such as those related to availability, performance, and capacity (to define the expected performance of the product)

  • Legal, regulatory, and compliance requirements (such as those related to data privacy)

  • Data management requirements

  • Business continuity/disaster recovery requirements (related to business and service continuity)

  • Architectural requirements

  • User experience requirements (such as those related to Experience-Level Agreements(XLAs)

  • Operations requirements (such as those related to monitoring and logging)

All Requirements need to be collected, refined, scoped, and have their progress tracked across the full development lifecycle.

The Requirement functional component supports the value streams:

Functional Criteria

The Requirement functional component:

  • Shall be the system of record (authoritative source) for all Requirements

  • Shall manage the lifecycle of the Requirements

  • Shall manage the state of a Requirement

  • Shall track all changes to Requirements

  • Shall manage Requirements through the lifecycle of a product

  • Shall capture service level Requirements such as those related to availability, reliability, and performance

  • Shall capture Requirements related to user experience (such as those related to user experience design, usability, etc.)

  • Shall capture Requirements related to security, risk, privacy, and compliance (for example, those derived from risk assessments and policies), and shall ensure that these Requirements can be traced back to originated Policies and associated legal and regulatory frameworks

  • Shall capture Requirements related to data management, such as those related to data integrity

  • Shall capture Requirements related to monitoring and logging (ensuring the deployed product can be monitored)

  • Shall collect, refine, scope, and track the progress of Requirements linked to the Product Backlog Items

  • Shall maintain traceability of each Requirement to the original Source (Product Backlog Item, a Policy, and/or requestor) and to the appropriate Source and/or Test Cases throughout the product lifecycle

  • Can manage the data flow to provide Requirement information to the Product Design functional component if a Product Design functional component exists

  • Shall allow a Requirement to be traced to one or more Test Cases designed to test the Requirement if a Test functional component exists

  • Shall allow one or more Requirements to be associated to one or more Policies that these Requirements originate from if a Policy functional component exists

  • May relate Requirements to specific stakeholders and personas

  • Shall rank Requirements to define the importance of each of the Requirements (e.g., must have, should have, could have, etc.)

  • May link Requirements to Portfolio Backlog Items (e.g., defining the high level requirements related to portfolio epics)