- May 26, 2006
- Agility Guide
- Requirements Process in Context
- The Process
- A Case Study
- Trawling for Requirements
- Prototyping the Requirements
- Writing the Requirements
- The Quality Gateway
- Reusing Requirements
- Reviewing the Specification
- Iterative and Incremental Processes
- Requirements Retrospective
- Your Own Requirements Process
- In Conclusion
The Quality Gateway
Requirements are the foundation for all that is to follow in the product development cycle. It therefore stands to reason that the requirements must be correct before they are given to the designers/developers. The Quality Gateway (Figure 2.6) tests the requirements. It is a single point that every requirement must pass through before it can become a part of the specification. Quality Gateways are normally set up so that one or two people, probably the lead requirements analyst and a tester, are the only people authorized to pass requirements through the gateway. Working together, they check each requirement for completeness, relevance, testability, coherency, traceability, and several other qualities before they allow it to become part of the specification.
One of the tasks of the Quality Gateway is to ensure that each requirement has a fit criterion attached to it. The fit criterion is a measurement of the requirement that makes it both understandable and testable. The understandability is for the benefit of the client, who has on several occasions said, "I am not going to have any requirements that I do not understand, nor will I have any that are not useful or that don't contribute to my work. I want to understand the contributions that they make. That's why I want to measure each one."
The requirements analyst has a different, but complementary reason for measuring and testing requirements: "I need to ensure that each requirement is unambiguous; that is, it must have the same meaning to both the client and the developer. I also need to measure the requirement against the client's expectations. If I can't put a measurement to it, then I can never tell if we are building the product the client really needs."
Another reason the project has a Quality Gateway is to prevent requirements leakage. Just as water seeps into a leaky rowing boat and you cannot tell where it is coming from, requirements sometimes seem to leak into the specification without anyone really knowing where they came from or what value they add to the product. By ensuring that the only way for requirements to get into the specification is through the Quality Gateway, the project team is in control of the requirements, and not the other way around.