For the past two decades or so, a number of organizations around the world have been applying a series of comprehensive quality management standards known as ISO 9000 to improve operating efficiency and productivity and to reduce costs. In December 2000, these documents were revised to conform more closely to the lessons learned in the previous five years , and the resulting update to the standards became known as ISO 9000:2000. As opposed to the CMM, which addresses software development exclusively, the ISO standards are a much broader set of standards intended to cover virtually all business process activities in all businesses that engage in domestic and international trade of any sort . As such, ISO standards apply equally well to a small import company that simply resells products manufactured by others and to the largest global manufacturers of goods and services. In so doing, ISO has tremendous breadth and must be "all things to all people," but it cannot possibly contain the depth of coverage for any specific area as does a standard, such as the CMM, which is designed for a specific business process.
The standards apply to all facets of operations, from sales order activity to customer support, as well as product development activity and the role of software suppliers (developers) in the process of producing goods and services that depend on software. In this respect, the ISO 9000:2000 revisions are particularly significant to this book because the changes had the effect of shifting ISO 9000 into much more of a process orientation and away from its audit orientation. Figure F-2 illustrates how the focus has shifted to the implementation of a process that has continual feedback loops and therefore provides a built-in mechanism for continual quality improvement. And when the process being analyzed is product development, the input is based on requirements derived from the "interested parties," that is, stakeholders, to help ensure that the resultant solution meets their needs. So yes, an effective requirements management process stands at the very front of this business process, and in that way the philosophy of ISO is consistent with the philosophy of this book.
Figure F-2. ISO model of the process approach ( adapted from ISO 9000:2000)
Today, ISO 9000 has been adopted by the European Community as EN29000 and has become an important factor for international trade; organizations wishing to do business in Europe, for example, often have to demonstrate ISO 9000 certification. Thus, in today's global economy, many American businesses have adopted ISO 9000 to ensure their credibility in the world marketplace . Certification to ISO standards requires an on-site assessment by an independent, ISO-approved assessor, so adopting such a set of standards represents a significant commitment. Companies are reassessed periodically to maintain their certification. ISO 9000 consists of four primary quality standards:
Within these documents, ISO 9001 contains a number of specifications that focus on using an effective requirements management process to control and improve the quality of a product or service. In addition, the document now makes a distinction between product-oriented requirements and process-oriented requirements. Again, this philosophy is consistent with the definitions we provided for quality in Chapter 29, wherein we described software project quality as the characteristic of having demonstrated the achievement of producing a product that meets or exceeds agreed-on requirements (as measured by agreed-on measures and criteria) and that is produced by an agreed-on process.
The same document also stipulates that the information thus provided to the supplier (which we've described as the "developer" throughout this book) should include all performance, safety, reliability, security, and privacy requirements (a subset of the nonfunctional requirements described in this book) that collectively determine whether the delivered system is acceptable.
Like the CMM, ISO 9000 standards have been the subject of considerable debate, particularly in U.S. organizations that worry about the possibility of the standards degenerating into a bureaucratic demand for excessive documentation. Our purpose here is not to endorse or attack ISO 9000; like all such commonsense concepts, it can be used or misused. But to the extent that many organizations are adopting ISO 9000 because they think it's a good idea or because it's a necessary prerequisite for doing business in Europe and other parts of the world, it's interesting to note the emphasis that the standard puts on requirements management. For example, ISO 9000 emphasizes the need for mutual cooperation between the customer and the developer for software systems. Specifically , it calls for:
Although it's easy to dismiss all of this as obvious and commonsense, remember what happens during the assessment required to achieve certification. An assessor will visit the organization and ask, "Where are your methods and procedures for approving changes to the requirements? Show them to me in writing. Let me visit some project teams and make some spot-checks to ensure that the procedures are actually being followed."
ISO 9000 also stipulates that the input to the development phase of a project ”the lifecycle activity in which technical design and programming usually take place ”should be defined and documented. These "inputs" are, of course, requirements , and ISO 9000 also states that the requirements should be defined so that their achievement can be verified . The use-case-to-test-case approach we have described could be of real value here. ISO 9000 also calls for processes to ensure that incomplete, ambiguous, or conflicting requirements will be resolved in an orderly fashion. Your team may wish to apply an iterative and incremental process for successive refinement of requirements as we have described.
In summary, the ISO 9000 emphasis on requirements at the beginning of a development effort is intended to help ensure that, if the technical design and development efforts are carried out in a disciplined fashion, the organization is more likely to produce a system that meets specifications, or requirements, rather than relying on frantic testing and validation activities at the end of the lifecycle to assure quality. With respect to software development at least, that also nicely summarizes the purpose of this book!
Like the SEI-CMM, ISO 9000 doesn't tell you specifically how to actually do requirements management. Rather, your team members will be obligated to define, implement, and adhere to an effective requirements management process that they themselves declare to be sufficient for the intended purpose. But armed with the procedures and techniques described in this book, and with Chapters 30 and 31 as a comprehensive summary and process guide, your team will be able to create a comprehensive requirements management approach that should satisfy the most demanding ISO 9000 or CMM assessors.