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.

Figure 2.6.

The Quality Gateway ensures a rigorous specification by testing each requirement for completeness, correctness, measurability, absence of ambiguity, and several other attributes before allowing the requirement to be added to the specification.

The Quality Gateway is detailed in Diagram 4 of the Volere Requirements Process model in appendix A.

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."

We discuss measurements for requirements in Chapter 9, Fit Criteria.

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."

Chapter 11 describes how the Quality Gateway tests the requirements for these qualities.

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.