|
A Requirements Analysis Document is an integral part of any IT project. It’s the main deliverable in the requirements analysis phase, and is among the first to define what the IT project is actually about. Let’s check out tips on how to write an awesome Requirements Analysis Document for your project. What Is A Requirements Analysis Document Used For? The Requirements Analysis Document, also called a RAD, isn't just another document you need to write to get the project done. It actually serves an important purpose. It’s used to explain what the project is for and what must be done for it to be successful. Depending on the organisation you’re at, the RAD may be known as Requirements Definition Document (RDD), Business Requirements Document (BRD), or something different. It’s used to record the requirements of a system. This may be a software system, hardware system, or any other business system. It is commonly put to use on software systems. It has sections on: Project introduction Responsibilities Functional requirements Non-functional requirements So, when you have to write one for your project, you can follow these suggestions to be sure your document is successful and is of top quality. Tip 1 - Use A Template The document you’ve been required to write is almost certainly not the first of its kind that's been written. Your company has most likely 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 a little more efficient is to make use of some of the work which has been done already, simply by using a template. A template is basically a plan of the document that needs to be written. It needs to have the cover page, headings for each section, and even perhaps a description of what goes in each section. This might have been produced by another project team, or some other area of the company, and would form a part of the company’s overall standards approach. This is great news for you - it can help you write the document and make sure it is effective. It will help make your document look more professional, as there is a conventional format to go by. It will also supply you with an indication on what parts to include. This has been important for 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 needs to be included. Tip 2 - Write With A Business User In Mind This can seem like an obvious tip, but when you write the Requirements Analysis Document, try and write it with the business users in mind. It might be tempting, specifically from a technical background, to go into a lot of technical detail and include a whole lot of IT terms in the document. Try to keep from doing this. The intention of the document is to present an overview 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 ways they can understand and that they are comfortable with. This comes along with experience of being a business analyst, or technical writer, or whichever role it is that writes the document in your team. Tip 3 - Use The Word “Shall” One of the most important words you can know when writing a Requirements Analysis Document is the word “shall”. It’s quite a appropriate word for specifying the exact requirements - whether functional or non-functional. The reason for this is that it is more definite than other words such as “will”, “would”, “should”, or “can”. Unless your company has a format of writing requirements, I would suggest using the word “shall” when identifying them. For instance, “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 also 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 really should be doing before handing the document over to the users to look at is proof reading it. Have a final review before finishing it - you may even find something that you didn’t notice when producing the document. Some areas to check are: Spelling and grammar check - This is build into most word processors already, but it’s not 100% reliable - specifically if you make a typo and the word displayed is spelt correctly. It’s something you need to also check by hand, and this can be done by giving it a proof read. Diagrams - If any diagrams are included (see the below section), then they need to be reviewed for accuracy. Diagrams can change throughout the creation of the document, which means you need to make sure you have the latest version in the document. Document formatting - the formatting of the document is a regularly overlooked area. It sticks out when the document has bad or inconsistent formatting. The document needs to be neat, formatted well and consistent. It will add a feeling of confidence to the document and to your team. It also looks professional. Names of people and systems - Usually, for Requirements Analysis Documents, you need to include peoples’ names in an Author or even a Project Responsibilities section. You need to double 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 A good way of describing a concept or process is to utilize a diagram. They are useful for describing current systems, proposed systems, organisation structures, screen layouts, data and process flows, and plenty of other things. They should be made use of in a Requirements Analysis Document to explain your concepts and in the sections that will take advantage of them. It also breaks up the document and makes it much easier to read. Lots of people are visual people - they can digest things easier if it’s in a diagram form, rather than explained in text. So, make sure you have included diagrams in any areas that are difficult to explain using text.
Related Articles -
requirements, analysis, document,
| 
