Join Terri Wagner for an in-depth discussion in this video Validating the requirements task list, part of Project Management Foundations: Requirements.
- Once you've verified the requirements, you'll now validate the requirements. The reason you validate requirements is to make certain every requirement meets a stated stakeholder need as well as provides value to the business, while fulfilling goals and objectives set out for your project. During validation you can also resolve any issues that are identified such as incomplete requirements, missing information, ambiguous content, unrealistic or conflicting requirements while also allowing an opportunity to add clarification before moving forward.
There are many different types of reviews that can be done. Let's check one of them out. For example, you can conduct a static confirmation technique. Static confirmation requirements documents can be done in meetings or with individuals assigned to conduct the reviews. This technique begins early in the life cycle before physical work begins. Typically, you'll have two types of static confirmation. Pre-reviews of requirements and technical reviews where people analyze and discuss specific documents.
Requirements pre-reviews provide a cost effective process where a subject matter expert checks the document and looks for straightforward problems such as missing requirements and typographical errors and such. When that person is done, the documents return for correction or distribution to other reviewers. In a technical requirements review, you generally have groups of people read and analyze the documented requirements looking for problems, meeting and discussing the problems, then agreeing on actions to address the problems.
When you conduct a technical review you'll want to involve a number of stakeholders drawn from different backgrounds. People from different backgrounds bring different skills and knowledge to the review. Stakeholders feel involved in the process and develop an understanding and appreciation of the needs of other stakeholders. Your review team should always involve at least a domain expert and an end user. This team is checking for how understandable the document is, how complete, consistent and unambiguous the content appears, and whether the content conforms to any known organizational procedures.
The team can also confirm the traceability of content in this requirements document to other documents that complete the requirements package. Your team may want to work from a validation checklist. For example, you may want to make certain your team answers all the following questions and documents the results. Is each requirements uniquely identified? Are specialized terms defined in the glossary? Does a requirement stand on its own or do you have to examine other requirements to understand what it means? Do individual requirements use the terms consistently? Is the same service requested in different requirements? Are there any contradictions in these requests? Are requirement references described elsewhere? Are related requirements grouped together.
You want to validate all your project requirements to confirm each requirement adds value and aligns with your project's stated business goals and objectives. If a requirement fails the business value test there will be no benefit to the organization, so it's best to trim that requirement from your final documentation.
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.
- Classifying requirements
- Developing requirements
- Investigating requirements
- Documenting requirements
- Validating requirements
- Managing changing requirements