Join Haydn Thomas for an in-depth discussion in this video Verifying your requirements, part of Business Analysis Foundations.
- So let's say I just took your order for your favorite drink at your local coffee shop and I say, "Let me repeat that back to you. "You ordered the decaf vanilla low-fat latte "with a twist of hazelnut in a large cup." Ordering a beverage is never easy, and if the person capturing the order has not verified your requirements, you may end up with a light mocha with a French vanilla twist three hours after you expected it. Enjoying the benefits of your favorite beverage can be challenging if verification is not undertaken appropriately.
There are a number of verification pitfalls that I want you to be aware of. First is limiting the validation to quality assurance personnel or testers only. Next is analysis paralysis, frustrating personnel who contribute to the requirements. Another pitfall is not taking a holistic point of view. And finally, considering verification as a one-time event. The verification of requirements gathered from your stakeholders is imperative in successfully ensuring the expected results meet the needs.
The validation and verification process is to be performed at varying stages throughout the project life cycle. Deciding ahead of time who and how you should be confirming requirements should always be in the business analyst's mindset. Business analysts capturing the requirements with the stakeholders are close enough to understanding the context of the business and understanding the organization's drivers and needs. The verification process may include multiple people and require meetings where requirements are reviewed and discussed to ultimately obtain sign off of the requirements from the customer and the sponsor.
You can commence the verification process at the early stages where you replay or repeat the requirement back to the stakeholder to seek clarification that you captured the requirement correctly. This can be undertaken in several ways. The first is through paraphrasing, where you replay what you hear back to the stakeholder, who then verifies what was said. Next is capturing the requirements in a written format and sending it back to the stakeholder to verify or update. The final way is through capturing the agreement from the stakeholder and possibly their manager.
Requirements are captured and then classified into business, stakeholder, functional, and nonfunctional, and finally, transitional requirements. This is known as the requirements breakdown structure and captures how the low-level requirements align to meet the high-level business and stakeholder requirements. This also ensures the requirements complexities have been identified and clarified within the context of the entire scope of the project. The next stage of the project life cycle is to ensure that each and every requirement will deliver against a scope item to create a deliverable.
And that deliverable will achieve one or many measurable project objectives. The next stage is to establish the priority of the requirements and how it best aligns to the achievement of the project objectives, expected outcomes, resolving the stated issues and problems, or delivering against the new opportunities. These requirements can then be captured in three categories: mandatory, important, or nice to have. Categorizing your requirements into these three categories will help you figure out which ones are most important. Making sure that your requirements are necessary for the organization is the essence of this stage of the verification process.
The final stage of the verification process is to ensure the requirements pass the SMART Test. Are they specific, measurable, achievable, realistic, and traceable, and written in a language that ensures understanding by many. Ensure the requirements gathered align with the initial objectives of the project by analyzing each item and considering where the priority of your project lies in the project portfolio, focusing on the synergies and conflicts between business and user needs, and finally, analyzing any off-task requests for their true motivation.
Failure to capture the essence and specifics of any requirements in isolation may not cause any major impact. Though when these requirements are collated, validated, verified, aligned, and agreed to, they represent the true needs of the project. It is only then that the requirements package is ready for final sign off by the sponsor and customer. You can then relax in the knowledge that you have done your utmost to deliver the decaf vanilla low-fat latte with the twist of hazelnut in a large cup, and your stakeholder appreciates your efforts to make it happen.
Discover where business analysis lives in the project life cycle, how to initiate a project, the best way to gather requirements, and smart strategies to monitor results and test outcomes.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- Understanding what business analysts do
- Defining business opportunities and objectives
- Identifying stakeholders
- Gathering requirements through observation and brainstorming
- Validating requirements
- Developing project acceptance criteria
- Implementing, testing, and closing your project<br><br>
- The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.