What are functional requirements and how to capture them?

Functional requirement document (FRD) or Functional requirement specification (FRS) is a part of most project. What is covered in a FRD/FRS? FRD would capture all the functional requirements for the system or web application. So, then what is meant by "functional requirement"?

Functional requirement explains the behavior and information the system will manage.  It states on what the system shall do. An example, would be "'My Accounts' section would display the list of all active accounts held by the user."

Functional requirement can be about logical calculations, business rules, audit checking etc. The functional requirement document would also contain the overview and the context of the project.The list of items that can be part of functional requirements is as given

• Business rules
• Calculations or formulas
• Authentication
• Authorization
• Audit trails
• Certifications needs
• Report generation
• Archives/Historical data
• Legal/Compliance requirements
• External Interfaces

The functional requirement document should list the requirements in clear  and concise manner. For better understanding, the document should be structured, with clear headings and sub-headings. It should have the same style pattern and be numbered. Use diagrams, wire-frames and data flow where required. Explain the system and ensure that all the functionalities are captured.

Functional requirements are captured in different templates like FRD, Use Cases or User Stories. A FRD or FRS, would have all the functional requirements in one document in an ordered list. The project overview, system details, assumptions, project scope etc would be part of this document. Each of the details would be captured in sections and sub-sections and length of the document can be 20-40 pages. Use cases are mostly used for website requirement gathering, where each functional requirement is captured as a series of actions performed by user in the system, to achieve a goal. User stories, mainly used in Agile projects, have the syntax as "As the {user}, I can {do something}, so that I {get this result}.

No matter what is the template being used, functional requirement document, serves as the gateway between IT and business users. To avoid any gaps in requirements and to make sure no requirements are dropped half-way through the project, ensure that all stakeholders (IT, business, architects, etc) are part of the review process. This would avoid any delays or increase in cost due to rework. A well reviewed and signed off functional requirement document, ensures that the IT team develops the system as per the business needs.

In addition to the functional requirements, there are also non-functional requirements for a system/application. More about non-functional requirements in next post.

How to write a requirement document?

A good document should satisfy the three C's - Concise, Clear and Complete. It is very true for the requirement document also. When a business analyst writes the requirement document, they may write the document, in a condensed or restrictive language, assuming that the other person would understand. Each user works in their specific business domain or "circle", where there would be certain terms and understanding among the colleagues. When communicating with each other in the department, using this restrictive language would be fine, as both the teams are on the same level of understanding.

BAs are comfortable in their domain and while documenting the requirements, unconsciously the restrictive language might come in the writing. IT team is not from the same domain as the BA and it is not necessary that they understand the implied meaning. Many a time, the defects caught can be traced back to a requirement, that was not clear or complete.

Business Domains 

BA must take conscious effort to make sure that the document is written in the elaborative language. One way to make sure that the requirement is elaborate is to have a review done by a peer from another department. Some examples of restrictive and elaborate requirements are listed

Restrictive	Elaborate
The data has to be backed up once a week	The data has to be backed up on every Saturday at 9pm and two copies has to be saved – one online and one offline
The system must allow users to view account summary	The system must allow users to view their account summary for the past one year
The system must provide summary report on Friday	The system must provide a summary report to the accounts manager on Friday 3pm UCT and it can be viewed from --- section

As can be seen from the examples above, elaborate requirements, ensure that there is no ambiguity and therefore helps IT to design better solutions. 

What are User Stories and Epics?

User Stories are high-level functional requirements, mainly used in Agile projects.
A user story typically has 3 parts-

• AS A - this identifies the user - it could be a general user, for example, the customer browsing the website, or it could be a specific set of users (business class users) or it could even be a system. The user/actor defines WHO wants the requirement.
• WANT - this refers to the action. WHAT is required? For example, I want to cancel the order, I want to open a new account, etc
• SO THAT - this refers to the WHY section, i.e, the advantage or use of the requirement. 

Some examples of user stories are

• The customer can order gift cards online using their credit cards
• As a patient, I should be able to make a reservation for a doctor online, so that I can see the doctor without waiting

User stories are very high-level requirements, that can be used as the starting point to flush out more details of the requirement. User stories are easy to write than use cases and functional requirements and it is typically written by stakeholders or business analysts. 

Good user stories would have the following characteristics - Independent, Negotiable, Valuable, Estimable, Small and Testable.

Epics are larger user stories that can be further broken down into several user stories. Epics are usually lower priority user stories, which when later is taken for development, is examined more closely and divided into several user stories and may be completed in more than one iteration