Quality begins with requirements. Many subscribe to Philip Crosby’s classic definition of quality as “conformance to requirements.” Crosby is one of the top quality gurus and has contributed greatly to the field, but his starting-point definition of quality is only part of the story.

Yes, conformance is important but not sufficient. The quality of the requirements is if anything even more critical. Conforming to wrong requirements, or simply lacking suitable requirements to conform to, will not produce quality. Too often, though, requirements issues impede ability to produce quality; and too often such issues are not recognized, which increases their negative impact.

An effective quality management system (QMS) not only tracks the presence and status of requirements documents but also is concerned that their contents and uses are adequate to create quality.

REAL Requirements

The rest of the story is that conformance must be to what I refer to as REAL requirements. REAL is not an acronym. Rather, all capitals is the one highlighting method that various tools don’t mess up. Capital letters survive even when italics, underlining, and bold face get stripped out.

REAL means several things. First, the requirements are right. They accurately and meaningfully relate to what is needed to provide value. As such, they are relevant and reasonably complete. Note, adequacy is critical, total perfection is not.

Second, REAL requirements are business requirements—business deliverable, the whats, that provide value when satisfied by some product or process, the hows, to satisfy them. This is a concept that few are familiar with and consequently is frequently missed or misunderstood. Most projects focus only on product requirements, which often turn out wrong. We’ll discuss the distinctions further below.

Third, REAL requirements are what you end up with, which often differs from what you start with. That is, most projects are familiar with defining requirements and then seeing them change as more information is gained. In fact, while REAL requirements can change, they tend not to. Rather, what actually changes is awareness of the REAL requirements that have been there all along but just haven’t been recognized.

Contrary to some popular opinions, the fact that somebody of influence has declared something to be a requirement does not by itself make it a REAL requirement. Such persons’ declarations need to be acknowledged but are just as likely as, and perhaps more likely than, requirements from other sources not to survive changes. When the changes cease, what’s left are the REAL requirements.

Form vs. Content

Several additional factors frequently confuse accurately defining REAL requirements. A widely-held belief is that form determines whether or not something is a requirement. To some this means that the requirement must be written in some prescribed format. For example, various published standards identify sets of topics that a requirements specification should include. While addressing each topic for each requirement can aid understandability, it does not necessarily assure the requirement is right. Moreover, including so many topics can produce a document whose very volume in fact can impede understandability.

A related common belief typically articulated in standards—and also held by many who are not referencing standards -is that a requirement has to include the word “shall” or “must.” Going along with that is the belief that the presence of “shall” or “must” makes something a requirement. Thus, rather than a full-blown requirements specification, many statements of requirements consist only of sentence after sentence starting with, “The system shall ….”

Such standardized language can facilitate communication, especially conveying intent that something indeed is important. However, merely stating that something shall or must does not assure that it actually is a REAL requirement.  

I refer to these as “magic words.” The conventional wisdom is that some, notably “shall” or “must,” have to be present, whereas others should not be in a requirement. Typically, forbidden magic words lack specificity and pertain to what many call nonfunctional requirements, for example, “easy” and “quick.”

Some automated tools evaluate the adequacy of requirements by checking for presence and absence of magic words and/or conformance to various checklists of supposed criteria for “good” requirements.

I find that those defining requirements tend to overemphasize such form elements, too often at the expense of content. A requirement is first and foremost a matter of content. Form is secondary and by itself does not make something a requirement. Form cannot fix content.

Humans can judge form issues, such as lack of clarity; but they often lack skills and knowledge needed to identify and correct wrong and missing content. Form can aid communication to others and creating shared understanding of the content, but form does not make it correct.    

Level of Detail

Another common source of confusion is the belief that a requirement must represent a particular level of detail. Such concerns fail to recognize that requirements tend to be hierarchical and can be dealt with at varying levels of detail.

High-level requirements cover big topics and thus are somewhat general and vague. We decompose them to successively lower and lower levels of detail to increase meaning and understandability. Thus, many supposedly-forbidden magic words are not only acceptable but desirable in high-level requirements; but they must be driven down to lower levels of detail to make them sufficiently specific.

“Levels Model”

Some additional common beliefs about level of detail arise in what I call the “Levels Model of Requirements.” According to this widely-held model, the difference between business requirements and product requirements is only a level of detail (or abstraction).

That is, the Levels Model says business requirements are high-level and vague, typically objectives or statements of desired/expected benefits, and decompose into product requirements which are detailed. Thus, to the Levels Model a detailed requirement is a product requirement; whereas a high-level vague requirement is a business requirement. Perhaps you can see why such a distinction is untenable.

REAL Business vs. Product Requirements

I use the terms “business requirements” and “product requirements” quite differently from the Levels Model, in ways that I think you’ll find more useful. Rather than differing based on level of detail, they are qualitatively different. As such, REAL Business Requirements are business deliverable, the “whats,” that provide value when satisfied by some product or process, the “hows,” to satisfy them. Product requirements are actually high-level design of how said product will work—in other words, its implementable features.

“Whats” do not decompose into “hows.” Consequently, all the detail in the world will not turn a REAL Business Requirement, the “what,” into product requirements, the “hows.” Instead, product hows respond to REAL Business Requirements whats. Each can exist at varying levels of detail, from high-level down to extremely detailed.

First driving REAL business requirements “whats” down to lower levels of detail makes it much easier and more reliable then to map product “hows” to the “whats.” That’s the key to designing and creating quality products that satisfy the REAL Business Requirements and thereby provide value. An effective QMS guides and supports the processes that make it all happen.