Writing a requirement analysis document is something you might need to do as part of your job. Depending on your role in the project, you have different parts to play in preparing this document. Learn a few tips on how to write a requirement analysis document in this post.
What Is A Requirement Analysis Document?
A Requirement Analysis Document, or RAD as it is sometimes known, is a document that is prepared to explain what the requirements of a project are. This document is prepared by the project team, usually by the business analyst, with some input from other team members.
The purpose is to explain what the project is and list the different requirements that it needs to deliver on. Depending on your workplace and the size of the project, this document might be called a few different things:
- Business Requirements Document (BRD)
- Requirements Definition Document (RDD)
- Requirements Analysis Document (RAD)
You might even have more than one of these documents to prepare, especially if it’s a large company. One client I worked with asked me to prepare a BRD and an RDD, so this information is not limited to one document.
Set Up The Template
The first thing you should do when thinking about how to write a requirement analysis document is to prepare some kind of template.
This template would just be an outline of what you need to add in to the document. You might find it easier to complete the document if you have an outline to indicate what you need.
Create a new document, and set it up so it has sections such as:
- Document Purpose – what is this document for? Why should someone read this Requirement Analysis Document?
- Project Description – what is the project called? What will it product? What will the product accomplish?
- Business Drivers – why is it being done? What benefits are being targeted?
- Key Contacts – who is involved in the project and what roles do they have?
- Business Requirements – what does the project need to accomplish?
- Document Signoff – who needs to agree to this document?
- Document History – what is the history of changes to this document, and version numbers?
Each of these sections can be filled out at different stages, so you don’t need to do them all at once. However, if you have an outline or template with each of these sections (or sections similar to it), then it should make writing the rest of the requirement analysis document easier.
Start With The Description
A good way to start with this document is to begin writing the document purpose and project description.
For the project description, you probably know what the project is about. There has been some other documentation written for this, or perhaps emails have been sent or your manager has mentioned it do. Write down a few paragraphs about the project:
- What is the name of the project?
- What is it trying to achieve?
- What is the product or result?
- Who is the audience or user base of the product?
- What are some of the key dates or milestones of the project?
You can also write the document purpose. This is an overview of what the Requirements Analysis Document hopes to achieve. I usually write something along the lines of:
“This Requirements Analysis Document outlines the business requirements for [Project Name] that need to be met for the project to be successful. The intended audience of this document is anyone who is involved in the project team. This document includes project information, business drivers and business requirements, but does not detail the technical requirements for use by the developers.”
The [Project Name] is replaced with the name of the project. There may be a standard available in your company for this kind of description, so if there is, you can use that.
Include The Business Drivers
Once you’ve put in the Project Description and Document Purpose, you can fill out the Business Drivers section.
This section answers “why”. Why is the project being done? It’s usually done for several reasons:
- Increase revenue
- Decrease costs
- Improve user or customer experience
- Prevent future issues
The information for this section will likely have already been prepared for you. For the project to get to this point, the company needs to be OK with the project starting, and to do this, they need to be able to justify the money they are spending.
Ask your project manager about the information for this section, and they should be able to provide it. You might need to reformat it to fit your document, but the information should already be there.
Enter the Requirements
Once you’ve got your template and filled out the previous section, it’s time to enter the requirements.
This section contains all of the requirements for the project – all of the things that the project must complete or satisfy for it to be successful.
Generally, they are listed in a table so that they can be easily numbered and prioritised. I won’t go into too much detail on how to write business requirements in this post, but you can read my other posts on tips for writing a requirements analysis document and tips for writing great business requirements.
This section is probably the biggest of the document and may take some time to write, so don’t expect it all to be done at once.
Complete The Remaining Sections
Now that the template has been laid out and you have some information in each of the sections mentioned, it’s time to fill out the remaining sections.
These sections include:
- Key Contacts – List the names of people involved in the project, as well as their role and business unit.
- Document Signoff – List the names and roles of people who need to sign off the document, as well as space for them to sign off.
- Document History – Create a table that lists the version number, summary of changes, and author of changes. This allows you to see how the document has changed over time.
These sections may not be completed early on, but should be available before you send it out for people to review.