Five Tips To Write A Great Requirements Analysis Document

A Requirements Analysis Document is an essential part of any IT project. It’s the key deliverable in the requirements analysis phase, and is among the first to define just what the IT project is in fact about. Let’s have a look at tips on how to write an exceptional Requirements Analysis Document for your project.

What Is A Requirements Analysis Document Used For?

The Requirements Analysis Document, often known as a RAD, is not just another document you'll want to write to get the project done. It really serves a major purpose. It’s used to specify what the project is for and what needs to be done for it to be successful. Depending on the organisation you’re at, the RAD can be referred to as a Requirements Definition Document (RDD), Business Requirements Document (BRD), or something different.

It’s used to record the requirements of a system. This can be a software system, hardware system, or any other business system. It's commonly used on software systems. It consists of sections on:

Project overview
Responsibilities
Functional requirements
Non-functional requirements

So, if you need to write one for your project, you could follow these tips to make sure your document is effective and is of high quality.

Tip 1 - Use A Template

The document you’ve been asked to write is almost definitely not the first of its kind that has been written. Your organisation has probably developed these previously. Other teams, or even your own team, could have written them. A great way of getting a top quality document and to be more efficient is to use some of the work which has been done already, by using a template.

A template is basically an outline of the document which needs to be written. It ought to have the cover page, headings for each section, and even perhaps an explanation of what goes in each section. This could have been developed by another project team, or another area of the organisation, and would form part of the company’s overall standards process.

This is great news for you - it helps you write the document and make sure it is effective. It will make your document look more professional, as there is a standard format to go by. It will also provide you with an indication on the parts to add. This has been of importance to me over the years - as a consultant I’ve visited various companies, all with different templates, and the templates have really assisted in finding out what has to be included.

Tip 2 - Write With A Business User In Mind

This might seem like an obvious tip, but when you produce the Requirements Analysis Document, try and write it with the business users in mind. It could be tempting, specifically from a technical background, to go into a lot of technical detail and include a great deal of IT lingo in the document. Try to refrain from doing this.

The purpose of the document is to present an summary of the project and to specify the requirements that were included and excluded in the project. If you write with the users in mind, it will frame it in a manner they can understand and that they are comfortable with. This comes with experience with being a business analyst, or technical writer, or whichever role it is that produces the document in your team.

Tip 3 - Use The Word “Shall”

Among the most important words you can know when composing a Requirements Analysis Document is the word “shall”. It’s a very appropriate word for specifying the particular requirements - whether functional or non-functional. The reason behind this is that it is more certain than other words such as “will”, “would”, “should”, or “can”. Unless your organisation has a format of writing requirements, I would recommend using the word “shall” when defining them.

For example, “The system shall allow a user to save their current session in the system” is an effective functional requirement - it’s definite, as it has the word shall in it, and it's specific in what needs to be done. It’s also a word that the readers can understand.

Tip 4 - Proof Read The Document

Something you should be doing before handing the document over to the users to look at is proof reading it. Give it a final review before finishing it - you could even find something you didn’t notice when creating the document. Some areas to check are:

Spelling and grammar check - This is build into a lot of word processors already, but it’s not 100% effective - especially if you make a typo and the word displayed is spelt correctly. It’s something you need to also check manually, and this can be done by giving it a proof read.
Diagrams - If any diagrams are involved (see the below section), then they need to be reviewed for accuracy. Diagrams can alter during the development of the document, so you must make sure you have the latest version in the document.
Document formatting - the formatting of the document is an often overlooked area. It sticks out when the document has bad or inconsistent formatting. The document ought to be neat, formatted well and consistent. It can add a perception of confidence to the document and to your team. It also looks professional.
Names of people and systems - Generally, for Requirements Analysis Documents, you should include peoples’ names in an Author or even a Project Responsibilities section. You need to check these names to make sure they are correct. The spell checker will likely not pick them up, but as long as they are correct, then the document will be OK.

Tip 5 - Include Diagrams

An effective way of outlining a concept or process is to utilize a diagram. They are great for detailing current systems, proposed systems, organisation structures, screen layouts, data and process flows, and many other things. They should be made use of in a Requirements Analysis Document to explain your concepts and in the sections that will reap the benefits of them. It also breaks up the document and makes it easier to read.

Many people are visual people - they can take in things easier if it’s in a diagram form, as opposed to explained in text. So, be sure to have included diagrams in any areas that are difficult to explain using text.