Skip to main content

System Requirement Review Guideline

A system requirement review intends to improve the quality of the requirements. It applies both to system requirements and technology requirements.

The purpose of the checklist is to support PCP R&D members, typically product owners and release owners, when invited to review system requirements.

System Requirement Review Goals​

  • Eliminate problems and rework at an early stage
  • Improve product quality
  • Ensure common understanding between PPM and R&D on what should be developed
  • Secure the development flow by ensuring that R&D receives well-defined and prioritized requirements to implement and test

System Requirement Review Checklist​

  • Traceability to Market Opportunity
  • Consistent with Market Opportunity
  • Wanted functionality and not a technical solution
  • Clear/Crisp description – not a broad statement
  • Consistent with other SRs (conflict, overlap)
  • Performance aspects covered (if relevant)
  • Reasonable size or possible to split
  • Possible to understand impact on the different products
  • Need for exceptions/limitations
  • Testable or need for verification criteria
  • Priority
  • Intellectual Property impact (opportunity, risk)
  • Security
    1. required capability security level (SL-C) of the system/product,
    2. security context including scope and boundaries in a physical and a logical way, and
    3. required security capabilities related to installation, operation, maintenance, and decommissioning.

PPMs directive for writing System Requirements​

To understand PPMs way of working, see their directive for writing the system requirement bellow.

  • Title: Title of the SR, should briefly describe the functionality without pointing to a specific product or product line or version.
  • Description: More detailed description
  • Motivation: State the reason for doing this requirement. If there is no associated MO, the business motivation should be put here.
  • Exceptions: Document any exceptions or limitations to the requirement.
  • Verification criteria: Describe suggestions/requirements in how the requirement shall be validated, either on system or product level
  • Market Opportunity: Reference to related Market Opportunity. Life cycle related System Requirements and Technology Requirements might not have MOs if the need for development is not associated with any change in market functionality.
  • Priority: Priority relative within one MO, 1 – 5, Used if more than one SR is connected to the same market requirement.
  • Target release: Do not use if not a specific target release is known, leave empty
  • Product Line: E.g.: 800xA Extensions; Advanced Services; Compact Product Suite; Digital, etc.
  • Compatibility: Indicate to which category Evolution --- Enhancement --- New Feature
  • Requirement type: e.g. Life Cycle Maintenance; Productization & Logistics; Product Function; Performance & Capacity; Security; Safety; Topology and Deployment; System Management

Underlined are mandatory fields, for more details see PPM's process description: Managing Market Requirements and System Requirements

References​

Owner: Requirements Team