We've come a long way in this book. From early lifecycle methods designed to support early and effective interactions with potential users and stakeholders to later, more rigorous lifecycle methods designed to help assure that we've built what we said we would, we've provided a comprehensive process to help the software team produce a quality system .
In so doing, we've implied quality, inferred quality, and hopefully even produced quality, but we've never specifically discussed quality. While there is never a shortage of debates regarding the relative merits of methods, practices, and specific techniques for requirements, analysis, design, and coding activities, when taken together these debates imply a grander debate: the ongoing debate about exactly how one goes about achieving quality in a software project . After all, when the very nature of the thing we produce ”this accumulation of source text, models and artifacts, and resultant millions of bits and bytes that we call software ”is itself intangible, how can we possibly get a handle on that most intangible of all concepts, quality?
Well, get a handle on it we must, else we risk working in an empty intellectual forum where, in the end, all our labors are for naught because we did not produce the requisite quality in the product. So, in this chapter, we provide some background and context on the topic of software quality and show how this book, by its very nature, serves really only one purpose: to help assure that the results you produce have the requisite quality to meet the needs of your users and extended stakeholders . In so doing, we also provide some more specific guidelines to help the team assure that the requirements process employed is a quality process so that, in turn , a higher-quality result will be achieved.