Have you noticed a trend these days where projects are being developed and launched with no requirements having been created at all? Other projects may come with a few requirements, but when problems arise, they find their limited planning is of little help in guiding them through the issues. To better emphasize why good requirements are more than useful, let’s explore further through two everyday situations.
If an issue remains unidentified during the QA and testing phase, but is then caught in a live environment, an analysis of the root cause will be initiated. At that point, it’s realised that the issue was skipped not because of the testers but due to a miss in the requirements. If the defect has been found in the later stages of development or post-deployment, it can have a detrimental impact as well incur a lot of extra expenditure for the fix.
Due to budgetary constraints of startups, development usually happens through oral communication or email threads, rather than writing requirements. This situation can pose an issue in later stages when enhancements are being planned, and the development is handed over to a different team. It then requires reverse engineering for traversing through the code to find the functionalities, and so on.
These examples indicate the importance of having well-defined requirements. Now for some pointers on how to write clear, functional requirements that can be understood by all stakeholders and be a vital knowledge resource for everyone involved in the project.
What is a Functional Requirements Document?
A Functional Requirement document specifies every functionality, along with the details on how the desired system is expected to work.
How do we write clear, functional requirements?
A Template
The very first step before you begin writing any functional requirement is to select the template to be used. Some businesses require highly detailed formal documents, and some need their documentation to follow a precise format. The template you eventually use will come from one of the following three sources:
- If the business already has a defined template, the same can be leveraged to create new functional requirements.
- Customize an existing template. If you have been involved with writing requirements, the same template can be utilized with slight customization as needed.
- If you are writing requirements for the first time, some readily available templates can be downloaded online from sites like Klariti.com.
Once the template has been defined, you will have a better idea of which inputs will need to be documented.
Questionnaire for Requirements Gathering
You need information from the business before you can start, but in what form will it be delivered? You might be given wireframes or designs and asked to create functional requirements from them. But a functional spec needs to include an lot more detail than can be inferred just from designs. To help you to extract all the information you need from the business, it is always handy to have a standard set of questions ready. The questionnaire include the following questions:
- Confirm the status of the project, whether it’s a new project, a migration, maintenance or enhancement.
- What is the project’s objective?
- Is any third party integration required?
- What platform will be used?
- Ask for all available reference docs.
Approach for documenting
Next to decide is the approach to be taken when writing the requirement. Despite having the template and all available information, it is still quite a challenge to present everything in a format that’s easy to understand. Functional requirements form the basis for any project development. The development team relies on the details provided in the document to code, hence it’s very important to include every detail, business process and rule so nothing is missed during development.
- Include workflows that define all alternative paths, eg. have been shown below in a login scenario.
- Include mockups with definitions and annotations.
- List all business rules applicable for a functionality.
- Mention the complete flow/business process, including the integration and the data flow. Best example of this is the order management flow for any e-commerce website. It will require documenting the overall order creation through to the order shipment process.
Sample Requirement template for a Website
To explain this section better, let’s take a look at a simple example with a very basic requirement template:
An Overview of the Client
This section should contain details and background about the business or the client
Objective/Purpose of the Project
This section should give details about the project’s objectives, what the business wants to achieve and how the end users are going to benefit from the new website. It is advisable to include an overall system flow depicting all the layers and interaction points. If a sitemap is available, include that as well.
If the requirement is for a migration project, this section can also include information about the existing system, the problems with the current system and how the new system can overcome those problems.
Intended Audience
List all who will be the target audience for this document, such as the stakeholders, project managers, developers, BAs and Testers.
Scope
List all points that lie in the scope of this project. This section should give a detailed idea of the overall development and QA scope. There are instances where if third party systems are involved, it’s common for the integration to remain out of scope, handled by a separate team. So within this section, mention should be made of all in-scope and out of scope items.
Assumptions, Constraints and Dependencies
This section should list any assumptions, constraints and dependencies, if any. For example, there can be technical constraints such as access to the environment or a limited number access, so such items should be very well defined in this section. Another instance can be inbound data dependency on a different system, for example if system x is dependent on system y to send data in xyz format.
Functional Requirements Summary
This section lists all feature details, including design annotation and all user flows.
