This example requirements document is part of a news post, please read more about how this was generated there.

Requirements Example Project

Introduction

** normally we would summarize the project here, discuss the scope, and introduce the requirement document**
We will use the following 4 levels of requirements:

• Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise. They describe things such as the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure success.
• Stakeholder Requirements are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how the stakeholder will interact with the solution. Stakeholder Requirements serve as a bridge between Business Requirements and the various classes of Solution Requirements.
• Solution Requirements define the characteristics of a solution that meets the Business Requirements and Stakeholder Requirements. They are frequently divided, particularly when the requirements describe a software solution, into:
• Functional Requirements describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations – a specific system action or response.
• Non-Functional Requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the system must have. They are also known as quality or supplementary requirements.
• Implementation Requirements describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desire future state, but that will not be needed once the transition is complete

We will assign to each requirement one of the following priorities:

• Must: mandatory for the team, without it the system/business will be hard to move forward
• Should: not vital but still very important
• Nice: nice to have, but will make only a small impact if left out
• Will not: initiatives that are not a priority at this moment

Business requirements

The example project has the following four main business objectives:

B1 TimeToMarket: Faster time to market

To beat our competitors, we have to decrease the time it takes to adapt to changing market needs

• S1 MortgageProduct

B2 HighQuality: Maintain high quality

Our customers expect high quality software, we want to avoid regulatory issues caused unexpected bugs/regressions

• S1 MortgageProduct
• S2 AutomatedTesting
• S3 MigrateExisting
• I1 KeepExistingInfra
• I2 TestAllTheThings

Stakeholder requirements

The following stakeholders are involved:

• Sales: people that look at the market and design new morgage products
• Developers: people responsible for developing new mortgage products
• MorgageExperts: people that understand morgages
• Architects: people responsible for the technical architecture over multiple systems
• Devops: people that have to deploy and maintain the servers

S1 MortgageProduct: Fast ,ortgage products

• SL1 MortgageDSL
• SL2 TestDSL
• SL3 VSCodeIDE

S2 AutomatedTesting: Automate mortgage testing

• SL1 MortgageDSL
• SL2 TestDSL
• SL3 VSCodeIDE

S3 MigrateExisting: Migrate existing Mortgage products

• SL4 Cobol2DSL

Solution requirements : Functional

SL1 MortgageDSL: DSL for mortgages

SL2 TestDSL: A test DSL for mortgage products

SL3 VSCodeIDE: A VS Code extension for the DSL

Solution requirements : Non-Functional

SL4 Cobol2DSL: Rewrite old COBOL code to the new DSL

Implementation requirements

I1 KeepExistingInfra: Target existing infrastructure

I2 TestAllTheThings: Test all interfaces

Relationship between requirements

This final graph shows the relationship between requirements, it helps figuring our connections, and will support the creation of a roadmap