How often should I be reviewing my requirements with members of my project team? By requirements I mean everything from high-level business needs (e.g. stakeholder requests, business requirements, vision and problem statements) to the most granular requirements (aka shall statements, functional and supplementary requirements and the like).
My answer (with only the slightest bit of hyperbole) is “all the time.”
When it is first articulated and then documented, a requirement just sits there on the page. Words. Words with multiple meanings and interpretations and implications. Ask a developer and you get an interpretation, ask a tester and they will have a different interpretation. Business resource, different interpretation. If these different (and usually conflicting) interpretations are allowed to stand through the project, there is high potential that someone will be disappointed when the project is completed.
So the team has to commit the time to discuss the meaning and implication of each requirement that is presented as a candidate for the system.
Does a tester have to review a stakeholder request like “Business wants to provide upsell and cross-sell opportunities based on items browsed/purchased on the website.” Probably not, but the business does. They need to validate the functional features that will execute this requirement.
One of those features might be “Should provide a ‘Check Me Out’ list on the website.”
Does the business agree that this feature (along with others, potentially) effectively satisfies the stated stakeholder request? Do the architect and development resources believe that this feature is implementable and supportable given the current technology framework? Implied in the second question is the fact that I have chosen to get the development team involved at this point of feature identification. If I have identified a feature that I think is going to meet a stakeholder request and it is not technically feasible, I want to get that feedback to the business as soon as possible so they have the chance to provide an alternate feature to meet their stakeholder request.
Let’s say that my identified feature is technically feasible. I am going to have to provide more granular requirements for that feature that will specify additional detail and rules for the feature. One of those functional requirements might be ‘System shall display products we recommend based on previous purchases or previously browsed or items.’. This then becomes a requirement that the development team and test team will want to review to consider how they will implement it and how it will be tested. I will also need to further bounce this requirement off the business to verify that this specific requirement fits with their vision of the final solution.
At all stages in the process, there should be time devoted to validating the requirement with the relevant team members. When a review and approval step is skipped, the requirement and the dependencies for that requirement are placed at risk. The greater the risk that a requirement carries, the more potential it has for being inaccurate from the business perspective and misunderstood from the development and testing perspectives. And a requirement that is either inaccurate or misunderstood or both runs a very high risk for negatively impacting the project and its success.
