Requirement Draft

[Feature Name ]	[Brief description of the feature As is]

[Feature Name ]

[Brief description of the feature As is]

Problem Statement

[Outline the problem with the existing service/product and improvements needed]

High level requirement (Objectives and Key results)

Epics (As a Customer [who] I want to receive an Order Confirmation that includes details such as the items purchased, amount charged and expected delivery date [what] sent to my email address [where] following the completion of each order [when] so that I have an off-line record of my purchase [why] or The system shall provide a Customer with)

Key performance indicators

Return on Investment (ROIs)

[What value the feature or improvement is providing, which can span a number of metrics] e.g

Reduction in cost
Increase in customer happiness
Increase in user engagement
Reduction in engineering complexity (I.e. team can move faster later, or unencumbered)

External Stakeholders

[Customers who are currently impacted or will benefit directly from the feature ]

External Dependencies

Internal Dependencies

Risks and Assumptions

Functional Requirements (Use Case)

Use Case Title:	[short title with active verb phrase]

Use Case Title:	[short title with active verb phrase]
Description	[One to two sentences that briefly describe the use case, including the primary actor’s goal]
Trigger	[Describe the event that initiates the use case].
Primary Actors (Personas)	[Designate the actor whose goal is satisfied in this use case, and has the most significant interest in the outcome]
Secondary Actors	[List other actors that play a supporting role in the use case and impact the outcome]
Stakeholders	[List the various entities who may not directly interact with the system but they may have an interest in the outcome of the use case. Stakeholder identification can aid in uncovering additional which are not readily apparent or mentioned directly by the users]
Preconditions	[List the system state/conditions which must be true before this Use Case can be executed]
Flow (Main success Scenario)	[Document the steps that illustrate the straightest or simplest path (the “happy path”) to accomplishing the goal. The main success scenario should describe the actors’ actions/stimuli and system response to the action or stimulus. This scenario should always end with a success end condition]
Alternative flows	[Document alternate flows and exceptions to the main success scenario. Extensions are branches from the main scenario, and numbering should align with the step of the success scenario where the branch occurs]
Exception flows	[Document conditional set of steps that are a response to the failure of a step]
Post-conditions	[Describe the end condition of the Use Case where the Primary Actor’s goal is satisfied] Success End condition: [Describe the end condition of the Use Case where the Primary Actor’s goal is satisfied] Failure End condition: [Describe the end condition that results if the Primary Actor fails to accomplish his goal.]
Frequency	[Indicate how often the use case is expected to occur. This information aids designers and developers in understanding capacity requirements]
Priority	[Prioritise requirements using MOSCOW]; Must have, Should have, Could have and Wont have.

Non functional requirements

Area	Requirement	MoSCoW	Additional comments
Hardware Requirements	[Describe Hardware requirements and related processes]
Software Requirements and Licencing	[Describe software requirements and related processes].
Supportability Requirements	[Describe all of the technical requirements that affect supportability and maintainability such as coding standards, naming conventions, maintenance access, required utilities, etc]
Security Requirements	[Describe all of the technical requirements that affect security such as security audits, cryptography, user data, system identification/authentication, resource utilisation,]
Interface Requirements	[Describe all of the technical requirements that affect interfaces such as protocol management, scheduling, directory services, broadcasts, message types, error and buffer management, security]
Usability/Accessibility	[Describe all of the requirements that affect Usability and Accessibility such as requirements that are technical and relate to the underlying code and user interaction and visual design.]
Compliance Requirement	[Describe the existing compliance environment as it affects project requirements. Include an overview of the compliance requirements necessary to achieve the project’s objectives.
Training	[Describe the specific training/installation/configuration documentation that is associated with this feature that need to be created/updated]
Resilience	[Describe ability to handle failure of an individual component within the system]
Legal and Regulatory	[Describe specific legal and regulatory requirements associated with the feature]
Scalability	[Describe all requirements to support increasing numbers of users/concurrency without incurring significant cost]
Error-handling	[Ease with which the system can degrade gracefully if errors occur - eg does the entire system go down and lose data if the internet goes down]
Localizability	[Describe need to include localised features eg currency; date formats]
Performance	[Ability to meet specific performance standards/requirements]
Concurrency	[Describe specific concurrency requirements]
Storage	[Describe specific storage requirements/considerations]
Test requirements	[Describe ease with which the functionality could/should be supported by automated testing]