How to organize requirements as a Business Analyst

One of the major roles of a business analyst is to collate all the needed project requirements from the business stakeholders and relate the information to the project developers or IT team. To successfully achieve this assignment, there’s a need to first organize these requirements systematically so as to ensure a win-win condition for both the business stakeholders and the IT team.

In this tutorial, we would be learning how to organize requirements as a business analyst.

Let’s begin by looking at what a business requirement is.

A business requirement is an official document that spells out all the features and conditions on which a business project will exist.

This document is written and compiled by a business analyst after consulting with the business stakeholders. This document is then conveyed to the Project developers.

Figure 1.0: Triangular connection of a business analyst 

The business analyst obtains and gathers the requirements of the business from the stakeholders and then after gathering it, they translate it in such a way that the IT developers are going to be able to code it. This is illustrated in the figure above. Because the two upper members in the triangle (including the business stakeholders and the IT developers) cannot relate directly with each other, that is where the third member (the business analyst) comes into play. The business analyst serves as an intermediary between the business stakeholders and the IT developers.

He helps to communicate all the stakeholders’ needs about the software or product to be developed including the company’s obligations, policies, timeframes, budgets, product features as well as how the product is expected to function.

Major requirements gathering processes

The entire requirement gathering process can be broken down into 3 major phases.

1. Understanding the project for yourself:

As a business analyst, you are going to be assigned a project, an example of a project could be to upgrade the software payment page with more payment options,  or to develop accounting software for the company, and so on. The first thing you want to do is to understand the project for yourself. As a business analyst, you must know that you are expected to solve a particular problem.  

The project is surely going to have a problem. It could be something that the company or business is trying to create or trying to achieve or trying to correct, so whatever the problem is, you need to try as much as possible to figure out and understand exactly what it entails. It is only when you fully understand the project that you can now communicate it effectively to the IT developers.

2. Set up meetings with the business stakeholders: 

After you’ve understood the problem, the next thing you want to do is set up meetings with the stakeholders to find out in detail what the project is all about. For instance, if the project is to upgrade the software payment page with more payment options, you want to find out, what payment options does the company want to adopt? Is it bitcoin or ethereum, or credit card or Paypal option? Here you ask questions about the project. You need to make sure that no stone is left unturned and ask every necessary question that will give you full information of what the client wants about the project. 

Also, the kind of questions you are going to ask will be largely dependent on the SDLC model you are using. For instance, if you are using the waterfall approach where every phase is dependent on the previous one, there’s a need for thorough questioning on the project requirements, meanwhile, for the agile model which involves series of iterations, the kind of questions asked might not be as serious as that of the waterfall approach. 

You also need to ask the “why” questions. For instance, if your client says, ” we want to have 3 payment options on the software”, you want to ask them why they want it like that. It doesn’t mean that you are challenging their authority, you are simply trying to get a full understanding of what they want.

3. Begin writing the requirements:

After setting up meetings with your stakeholders to discover the full details of the project, the next step is to start writing the requirements. Note that you might not get all the full information you need in just one meeting. 

You could have questions that come up along the line. That’s why you might need to meet with your stakeholders several times. But you can start writing the requirements after the first meeting, then as you meet with them subsequently, you can update the requirements document. The method of approach you choose to adopt will also determine how you write the requirements. For instance, if you are using the waterfall approach, you’ll need to write a business requirements document, whereas, for the agile model, you’ll be writing user stories.

Steps in organizing requirements as a business analyst

1. categorizing the requirements: There’s a need for you to go through all the requirements and rearrange them according to types. Functional requirements should be placed together, Non-functional requirements should be arranged together, likewise technical and non-technical requirements and so on. Every requirement must fall under its relevant category.
2. The requirements should be collected and listed accordingly in a logical sequence. You want your stakeholders to easily read through and understand the content of the requirements document. This will also help the IT developers to easily comprehend the documented requirements.
3. Prepare the requirements in such a way that allows for easy review by respective departments. For instance, a stakeholder in the administrative department will only like to review administrative requirements and might be pissed off with technical requirements. Likewise, a stakeholder in the technical department will be very comfortable with reviewing technical requirements but pissed off with security or administrative requirements.
4. Adopt the use of separate identifiers for specific requirements to aid easy traceability. You can make use of Roman numerals or a combination of Arabic numerals and alphabets. The use of reference numbers to identify requirements makes it easy to trace errors, and apply corrections to affected modules and enhance future developments. You also want to ensure that you use a consistent reference number throughout the requirement document. For example,  if a requirement is identified as AR2 then it should remain as AR2 all through the document.
5. Provide various formats of the document: Because the business stakeholders constitute various individuals with different personalities and choices, it is advisable to prepare the requirements document in various formats such as word document, spreadsheet, Graphs, slide presentation, and so on.
6. Provide a table of content which will show all the major information in the document and the respective page number where each information could be found. This makes it easy to browse through the entire document at a glance and also saves time of having to flip through pages.
7. Ensure the use of appropriate tools in preparing your requirement document. Tools such as Microsoft Word, Excel, 
   
   SQL, Powerpoint, and so on, are very handy for top-notch document preparation.
8. After compiling your requirement document, check through for redundancies. Remove all unnecessary words or phrases that can sound confusing to the reader which includes your clients as well as the IT developers. 
9. Prepare and list out every aspect of the document in a professional manner. Make use of bullet points when listing key points, present complex data in tables. 

In conclusion, the major goal of a business analyst is to meet clients’ expectations on every project, and properly organizing project requirements is a major factor to be taken into consideration to achieve this goal.