Establish and Document the Application's Functional and Non-Functional Requirements

This chapter explains how to establish and document the requirements an Application must satisfy, both what it must do and how well it must do it.

Functional and Non-Functional Requirements

Functional requirements describe what the Application must do: the behaviors, functions, business rules, and outputs it must provide.

Non-functional requirements describe the qualities the Application must have: for example, its availability, performance, scalability, security, privacy, usability, accessibility, maintainability, recoverability, and data retention characteristics.

Both kinds are essential. An Application that does the right things but is unavailable, slow, insecure, or impossible to recover does not meet the needs of the enterprise.

Establish the Requirements

Capture requirements during the Requirements Capture phase of each Release, with the Business Application Owner, users, and other relevant stakeholders. For each requirement, establish its source, its priority, and how its satisfaction will be verified. Pay particular attention to non-functional requirements, which are frequently assumed rather than stated, and derive them in part from the Application’s business criticality, service levels, and regulatory classification.

Enhancement Requests often describe future requirements; when an Enhancement Request is accepted into a Release, it becomes a requirement for that Release.

Document and Share the Requirements

Record the Application’s requirements in the Requirements section of its documentation, organized so that a reader can see which requirements are currently satisfied by the Application and which belong to future Releases. Link requirements to the design elements that address them and to the tests that verify them, so that each can be traced. Update the requirements with every Release.

Best Practice: Establish and Document the Application’s Functional and Non-Functional Requirements

It is a best practice to both establish and document the solution for what an Application must do and how well: capture its functional and non-functional requirements with their sources, priorities, and verification methods, and trace each one to the design that addresses it and the tests that verify it.

Benefits: Documented, traceable requirements let anyone confirm what an Application is supposed to do and whether it does it, which is invaluable when changing, testing, auditing, or replacing it. Making non-functional requirements explicit prevents the common failure of an Application that works correctly in testing but cannot meet real-world demands for availability, performance, or recovery.

Connections to Related IF4IT Practices and Inventories

The Non-Functional Requirements (NFRs) Framework for Software Systems describes a comprehensive set of non-functional requirements to consider. The Systems Development Lifecycle (SDLC) Best Practices describes the Requirements Capture phase.