Requirements Validation
Requirements validation should be done by comparing the actual features and functions against the planned features and functions. All of this would have been documented in an acceptance test procedure developed and approved by the customer and the project manager during the Planning Phase. As long as that document is kept current, the validation involves nothing more than demonstrating that all items on the acceptance test procedure list have been checked off. If the document has not been kept current, validation becomes a shooting contest, and the customer usually wins. Because the Linear SDPM strategy is based on the assumption of clearly defined and documented requirements, validation should be straightforward. But that doesn’t mean it should not be a formal process from initial definition through to final acceptance.
There must be some assurance throughout the project life cycle that the current requirements are in fact what the customer expects. It sounds like it should be simple and straightforward, but that is far from reality. It all depends on what you—the project manager and project team—have done to ensure alignment between what the customer expects and what you are delivering. The first step to this assurance is to have the customer meaningfully involved throughout the project life cycle. That means frequent touch-points with the customer. At those touch-points, both of you should be verifying that the previously agreed requirements are still ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access