Levels Of Requirements, Robustness, Unicorns, And Other Semi-Mythical Creatures In The Requirements Engineering Bestiary: Why "Types" Of Software Requirements Are Often Misleading

Taxonomies are useful for organizing complex bodies of knowledge, and taxonomies of software requirements abound. Most software engineering textbooks include one. However, there is little, if any, agreement on the names or definitions for the types of requirements that constitute the taxonomies. "Types" of requirements that appear in the literature include functional, performance, high level, low level, lower level, derived, interface, design, operational, system, system operational, safety-related, security, initial, user, and detailed requirements.And that list is hardly exhaustive. Yet ambiguous and even contradictory definitions for many of these terms in the literature can make it hard to identify conceptually distinct items. The problem is not academic. In the avionics community, disputations about the meaning and nature of high level, low level, and derived requirements have persisted for decades; the nature of robustness requirements is similarly unclear, as is the distinction between functional and performance requirements. It is not that no one knows what these terms might mean; it is that there are too many obvious but incompatible interpretations, too little rigor in the conceptual underpinnings of the definitions, and, as a result, too little agreement as too which ones apply and when, if ever. Chapter 7 of The Mythical Man-Month, "Why Did the Tower of Babel Fail?", identifies the issue: Poor communication leads to engineering fiascos. Ambiguities and confusion in fundamental concepts and vocabulary hinder communications about requirements engineering. In the avionics world of DO-17C/ED-12C, such confusions are particularly worrisome. This paper will seek to clarify requirements engineering vocabulary that remains murkier than it needs to be.