How to Write 

Functional Requirements
How you write your functional requirements will depend on your product development methodology.
Agile software teams generally call their functional requirements user stories and might write them on
Post-Its or cards in an online system.
Teams developing products for a regulated industry might still be using Agile best practices, but
because of the size and complexity of their products, will use a more structured approach to
documenting requirements. Requirements are usually outlined as written descriptions in a document —
like an SRS or PRD.
No matter the methodology you use, when writing a functional requirement, you want to include:
•Identifier — unique name and number
•Summary
•Reasoning
The identifier is used to help track the requirement through the system, and the other information helps
clarify why the requirement is needed and what functionality must be provided.

Other Guidelines for Writing Functional Requirements

There are differences between well-written and poorly-written requirements. You want to encompass
all the relevant information as thoroughly, clearly, and concisely as possible. Here are some general
best practices to writing useful requirements:
•Use an active voice.
•Avoid vagueness — make them as complete and accurate as possible.
•At the same time, avoid extraneous information that can be confusing.
•Be consistent in terminology and format.
•Use “must” instead of “should.” Separate meta-data fields are a better way to indicate priority and
whether the requirement is in or out of scope.
•Quantify requirements — if a stakeholder wants a website to load “quickly,” ask what that means (3
seconds or less? 2 seconds or less?)
•If you intend to reuse the requirement, write it as such — use “accept payment” rather than “accept
payment through iTunes,” for example.
•Include requirements that detail what the system should not do to cover every scenario.
•Focus on features the users truly need.
•Each requirement needs to be testable.
•Each requirement needs to track back to one of the objectives.
•Document assumptions.
•Use visuals to reinforce information when possible.
•As best you can, make them understandable to non-technical stakeholders.