Implementing the Quality Gateway

We have described the Quality Gateway as a process for testing requirements. Now you have to decide how you will implement it in the context of your own organization.

The first decision focuses on who is involved in the Quality Gateway. Is it one person? If so, who? Should it be a small group? If so, will it be made up of testers or requirements analysts? Does the group include the project leader? Is the client represented? The answers to these questions are as varied as the organizations that have implemented Quality Gateways.

We suggest you start your Quality Gateway with two peopleperhaps the lead requirements analyst and a tester. Keep in mind this gateway is meant to be a fast, easy test of requirements, not a laborious process involving half of the development team. We have clients who implement their Quality Gateway electronically. The requirements analysts e-mail all requirements to the gatekeepers, who then add the accepted ones to the specification. They report this strategy is both convenient and effective.

Clients who use requirements tools typically assign an attribute to the requirement that indicates whether it has been tested and approved by the gatekeepers. The gatekeepers are, naturally enough, the only people to have write permission for this attribute.

Culture is an ingrained part of organizational life. You must respect it when you implement a Quality Gateway.

An important facet of any organization is its culture. This culture is every bit as strong as the culture you find when visiting different countries, when talking to people from different ethnic backgrounds, or when observing groups of people who are outside your normal way of life. Culture is an ingrained part of organizational life, and you must respect it when you implement new procedures.

The degree of formality also brings up many questions: How formal does the Quality Gateway need to be? Should you issue inspection reports? Should you hold prearranged Quality Gateway inspection meetings? And so on.

Most of the time we advise clients to keep their Quality Gateway procedures as informal as will allow for the satisfactory checking of their requirements. Some organizations deal with complex, technical subject matter; their Quality Gateways are of necessity formal and rigorous. Some clients deal with more accessible subject matter, where all the participants in the requirements-gathering process are well versed in the business; their Quality Gateways are so informal that they happen almost without anybody noticing.

The use of automated tools can help to reduce the amount of human intervention in the Quality Gateway process.

The use of automated tools can help to reduce the amount of human intervention in the Quality Gateway process. Some requirements-gathering tools can do the preliminary mechanical checkingensuring that all the components are present, use the correct terminology, are correctly identified, and so on.

Existing procedures may also play a part in your Quality Gateway. If people already have the job of inspecting work, then they are likely to be involved in your Gateway. If inspection procedures exist, then they should be adapted for requirements rather than trying to implement a whole new process.

Alternative Quality Gateways

We have discussed the Quality Gateway as a process whereby appointed gatekeepers test all requirements before the requirements become part of the requirements specification. We have said that this endeavor should be a permanent, but informal process. Of course, there are other ways of testing the quality of your requirements.

In "buddy pairing," requirements analysts test each other's requirements.

Requirements analysts can test each other's requirements, for example. This informal "buddy pairing" approach works well when the analysts are able to approach their work in an ego-free manner. The partners check each other's output and trap errors early in the process. This strategy works best when a pair of analysts has learned to be objective about each other's work.

Sometimes the process is far more formal and rigorous. One elephant project we worked on implemented the Quality Gateway as a four-stage process. First, each individual developer has a checklist and uses it to informally review and improve requirements throughout the development process.

The second stage is a peer review, in which another member of the team formally reviews each written requirement. We found it very effective for the peer reviewer to be someone from the test team. Rather than review the entire specification, these reviews concentrate on all the requirements related to a particular use case. The results of the review are recorded for the requirement as part of its history.

The third stage is a team review that includes customers and users. Problem requirements that have not passed the Quality Gateway tests are presented by one person, and are discussed and possibly resolved by the team members.

The fourth, and final, stage is a management review that is mostly concerned with looking at a summary of the Quality Gateway successes and failures. The results of this review are used to manage and fine-tune the requirements project.

See Chapter 2, The Requirements Process, and Chapter 15, Whither Requirements?, for more on tailoring your process.

Whatever your situation, you should think of the Quality Gateway both as a way of testing the requirements before they become part of the specification, and as a way of improving the quality of your requirements process.