Quality Management: Why it’s important to review requirements in detail

Hello project managers and project specialists, Happy Tuesday! I hope all of you are doing well! Wishing you a great week ahead!!

Today, we will be focusing on a very important area of the quality management pillar within project management, which is requirements management. When developing a solution or system, it is critical to make sure that you effectively manage the requirements process. I hope you enjoy the post!

Requirements are the essential component of anything that you create. From a building that you are planning to construct, to a software solution that you are planning to create for your department, requirements are the essential ingredients that are needed to define what you are focused on creating and implementing by the time a project will be finished. When creating requirements, you cannot keep them high level. They need to be as specific as possible, which means that requirements need to be descriptive enough for the rest of the team to be able to understand them.

Before diving into why it’s important to review requirements, we should also understand how requirements are documented. Depending on the industry that you are in, you may more than likely be using a table to capture the Level 1 and Level 2 area of the requirement and the discussing the specific requirement in detail. While this is a great approach to take, there are ways to further enhance the requirements gathering process by developing a Requirements Traceability Matrix, or RTM. An RTM is a great way to capture detailed requirements by level 1 and level 2 focuses and then diving into each requirement. From there, the RTM can be utilized for the other phases of a project, such as the development and testing phase. When you are utilizing an RTM, it means that you are making sure each business requirement that you are notating is traceable throughout all phases of the project. In a technology project, the development team should be able to read the business requirement as a system requirement. Likewise, when the solution reaches the testing cycle, each business requirement should be able to be tested at its individual requirement level. By taking this approach, the requirements are more holistic and can be utilized and are applicable across all phases of the project lifecycle. 

Now that you understand what requirements are, how they are documented, we can focus on why its essential to review requirements. There are several reasons as to why requirements should be reviewed in detail during the requirements phase of a project. In a waterfall project, where there is only one cycle of gathering, reviewing and finalizing requirements for the lifecycle of the project, its essential to make the requirements review process as organized and fruitful as possible. Within an agile project, requirements go through sprint cycles so its important to keep all project stakeholders aligned on which requirements will be focused on during specific sprints.  Below, we have listed out the reasons as to why reviewing requirements is critical to the success of any project:

1. Bring stakeholders on same page: when gathering requirements for a specific project, you may be meeting with multiple types of stakeholders across the spectrum of an organization, which can potentially include the finance team, operations team, legal team, manufacturing team, supply chain team, etc. By doing a holistic requirement review with the entire group of project stakeholders, you will be able to bring everyone together so that they can understand how each group’s requirements can have potential downstream/upstream impacts to other groups as well.
2. Make sure the requirements make sense: During the requirements gathering process, some requirements can become so intricate that they may not be a requirement at all and may just be focused on a specific detail tied to another requirement that was already captured. It’s important to confirm the validity of the requirement and make sure it ties into the overall solution and is not an offshoot of another process.
3. Make sure requirements are not in conflict: When reviewing all requirements, there are certain stakeholders who may be specific with a function being required in their solution, while another set of stakeholders may say that requirement is not tied to the correct process or overrides the requirement that another group captured. Here, it is crucial to make sure that any conflicts in requirements that come up are resolved with a proactive approach with the project stakeholders. In addition, its important to make sure to define the correct process up front. During the development or testing phases of the project (or even after go live of the solution), all stakeholders who will be utilizing the solution should be able to understand how the solution will work based on the requirements gathered and that there are no breaks or interruptions within the overall process. 
4. Gain clarity on overall solution/system across multiple sets of stakeholders and understand the impacts of the requirements to stakeholder groups: this is definitely key in developing the solution and deploying a holistic project. If you don’t involve all of the stakeholders in the requirements review discussions, then there will be potential areas that may be missed or overlooked. Additionally, it is vital to assess the impacts of requirements to other groups as well and be able to identify how the requirement may impact the users from other groups at the end of the day. 
5. Remove redundant requirements: during the review process, there may be one group that identifies the same requirement as another group but uses a totally different set of words/phrases to describe the requirement. This is where it’s important to make sure there are no redundant requirements that are showing the same type of information. 
6. Requirements are detailed and explicit: Requirements are useful when they are very detailed and explicit. If requirements are not detailed enough, then the downstream processes of developing and testing the solution will not be effective, which can impact the overall solution when it goes live. By being as specific as possible, the requirements can be helpful in bringing clarity to the project stakeholders during the requirements review process. 
7. Requirements are traceable: we discussed this at the beginning of this post. Requirements are traceable when the business requirements can be converted to system requirements, which can also be converted into testing scenarios to make sure that the business requirements are met. As this applies to the technology and IT industry, there can be a similar approach for other projects within construction and non-technology projects. At the end of the day, you have to make sure that the solution or product being developed meets the intention of why the project was started in the first place. At the same time, the end product needs to be durable and meet the requirements of what the project stakeholders set out for.
8. Requirements need to be achievable: this is a critical step during the requirements review process. Typically, its important to make sure that the development team is in the room when conducting requirement reviews to answer questions regarding the feasibility of requirements. There are definitely project stakeholders who have a “pie in the sky” style requirements, but these requirements also need to be technically feasible, and able to be completed within the time frame and budget allotted.
9. Confirm major requirements are not missed across stakeholder spectrum: while conducting and completing the requirements review with the stakeholders, its important to ask questions towards the end of the session to confirm that no other major requirements were missed among the stakeholder groups as they interact with each other. Typically, this can be a separate session as a requirements review session can be very exhausting and an all-day type of event. Even so, it’s critical to make sure that the stakeholders were not relying on other groups to provide requirements that they themselves should have brought up. The last thing you want is to develop and test a solution that doesn’t end up working long term for anyone.
   

As you can tell, the requirements review process is critical to any project that you are pursuing, whether it’s a home being remodeled, a software solution being developed, a new home being constructed, or a new office floor being set up. By reviewing requirements in detail, it gives the opportunity to all stakeholders in the project to voice their concerns, bring up potential requirements that may not have been thought of, and bring the project team together to align on a common vision of the end product or solution.

I hope you enjoyed this post! What are your thoughts on the requirements review process? Leave us a comment below!