Requirements

Requirements are the base of a good systems engineering foundation. Managing those requirements is the basis of a strong traceability and reporting structure to help ensure product delivery.

What is a requirement?

A requirement is a living document that details a condition or set of parameters that must be executed for the product to be considered completed. These come in many different forms, and from different stakeholders inside (and outside) the organization.

Types of Requirements

Stakeholder Requirements

  • Definition: High-level requirements that capture the needs, wants, and expectations of stakeholders

  • Purpose: To define what the stakeholders expect from the system

  • Examples:

    • "The system shall allow users to generate monthly reports"
    • "The product must be usable by non-technical personnel"
  • Format: Often expressed in natural language, focusing on business objectives

Stakeholder Validation Requirements

  • Definition: Criteria used to verify that stakeholder requirements have been met

  • Purpose: To provide clear measures for determining if stakeholder needs are satisfied

  • Examples:

    • "90% of users should be able to complete basic tasks without training"
    • "Stakeholder acceptance testing must confirm all user stories are implemented"
  • Format: Often includes acceptance criteria, test procedures, and demonstration plans

System Functional Requirements

  • Definition: Specifications of what the system must do

  • Purpose: To define the system's behavior and functionality

  • Examples:

    • "The system shall authenticate users via username and password"
    • "The system shall generate PDF reports from database queries"
  • Format: Typically structured as "The system shall [action]" statements

System Non-Functional Requirements

  • Definition: Quality attributes that constrain how the system delivers its functionality

  • Purpose: To define the system's performance, reliability, security, and other quality aspects

  • Examples:

    • "The system shall respond to user queries in under 2 seconds"
    • "The system shall maintain 99.9% uptime during business hours"
  • Format: Often quantifiable constraints on system performance and qualities

System Validation Requirements

  • Definition: Criteria used to verify that the system meets all specified functional and non-functional requirements

  • Purpose: To ensure the system satisfies its intended purpose as a whole

  • Examples:

    • "End-to-end testing shall demonstrate successful processing of 1000 concurrent transactions"
    • "User acceptance testing shall verify all critical workflows function correctly"
  • Format: Typically includes test cases, procedures, and acceptance criteria

Technical Requirements

  • Definition: Detailed specifications that guide implementation of the system

  • Purpose: To define how the system will be built

  • Examples:

    • "The backend shall be implemented using Node.js version 18 or higher"
    • "The database shall use PostgreSQL with encryption at rest"
  • Format: Specific technical specifications and implementation details

Technical Validation Requirements

  • Definition: Criteria used to verify that technical implementation meets the specifications

  • Purpose: To ensure the technical implementation satisfies requirements and follows best practices

  • Examples:

    • "Code quality must pass automated testing with greater than 85% coverage"
    • "API response times must be validated under simulated load of 500 requests per second"
  • Format: Includes technical test specifications, performance benchmarks, and acceptance thresholds