← Back to home

Requirement

You're asking me to dissect the very essence of what makes something acceptable in the cold, hard world of engineering. Fine. Let's get this over with. You want to know about requirements? They're the teeth in the mouth of a project, the things that bite you if you're not careful.

The Unyielding Mandate: What Makes an Engineered Work Acceptable

This whole discussion, this elaborate dissection of "requirements," is fundamentally about what separates the merely attempted from the achieved. It's about the conditions, the non-negotiable stipulations, that must be met for the culmination of your product and process development efforts to be deemed anything other than a spectacular failure. For those of you who prefer your definitions less… metaphorical, a requirement is, in essence, a precise, quantifiable declaration of a condition that a material, a design, a product, or a service must satisfy. It’s the blueprint’s promise, the client’s ultimate decree.

Now, the specification, or "spec" as the jargon-slingers call it, is merely the collection of these demands. It’s the manifest of what you’re up against. Developers use it like a roadmap through a minefield during the design phase, and testers wield it like a weapon during verification. It’s the holy writ, the final word.

The methodologies you employ dictate how this dance unfolds. With iterative and incremental development – think agile software development – requirements are a moving target, evolving alongside design and implementation. They’re sketched in the sand, refined with each tide. The waterfall model, on the other hand, demands that all requirements be etched in stone before any design or implementation even begins. A quaint, perhaps even naive, approach in my estimation.

These requirements aren't confined to a single discipline. They permeate engineering design, system engineering, software engineering, enterprise engineering, product development, and the relentless pursuit of process optimization. It's a pervasive concept, this idea of necessity.

At its core, a requirement is a broad concept, encompassing any function, attribute, capability, characteristic, or quality that a system absolutely needs to possess to offer any modicum of value or utility to its intended audience – be they customers, organizations, users, or any other stakeholder unfortunate enough to be involved.

The Genesis of the Demand: Origins of the Term

The term "requirement" itself has been rattling around the software engineering community since at least the 1960s. It’s not exactly a fresh bloom.

According to the esteemed, if somewhat verbose, Guide to the Business Analysis Body of Knowledge® version 2 from the IIBA (BABOK), a requirement is defined with a certain… bureaucratic precision:

  • A condition or capability that a stakeholder absolutely requires to solve a problem or achieve a specific objective.
  • A condition or capability that must be met or possessed by a solution, or a component thereof, to satisfy a contract, a standard, a specification, or any other document that carries the weight of formal imposition.
  • And, of course, the documented representation of either of the above.

This particular flavour of definition owes its lineage to IEEE 610.12-1990, the IEEE Standard Glossary of Software Engineering Terminology. A weighty tome, I'm sure.

The Dichotomy of Demands: Product Versus Process Requirements

Requirements, in their infinite variety, can be broadly categorized into two distinct fields:

  • Product requirements: These dictate the intrinsic properties of the system or product itself. What it is.
  • Process requirements: These prescribe the actions, the very activities, that the developing organization must undertake. How it gets done. Think of them as the rules of engagement for the creators.

The two are inextricably linked, like a particularly dysfunctional pair of Siamese twins. A product requirement might necessitate specific automation to support a process requirement, while a process requirement might outline the activities needed to bring a product requirement to fruition. For instance, a stringent requirement on the maximum development cost (a process requirement, naturally) might be imposed to ensure a palatable maximum sales price (a product requirement). Similarly, a product requirement for maintainability might lead to process requirements mandating the adoption of specific development styles, like object-oriented programming, adherence to style guides, or the implementation of rigorous review and inspection processes. It’s a constant, often tedious, feedback loop.

A Taxonomy of Tyranny: Types of Requirements

The classification of requirements often reflects the developmental stage at which they emerge, the specific model in use dictating the nomenclature. The International Institute of Business Analysis, in their rather comprehensive Business Analysis Body of Knowledge, offers a scheme that, while detailed, is not entirely without merit (though one might argue about the necessity of such granularity). Other frameworks, like FURPS and the general concept of Types of requirements, offer alternative perspectives.

  • Architectural requirements: These are the foundational dictates, outlining the necessary integration of a system's structure and its behavior. They define the very system architecture. In the hallowed halls of software engineering, these are termed architecturally significant requirements, defined as those that exert a measurable influence on a software system’s architecture. They are the bones and sinew of the beast.

  • Business requirements: These are the high-level pronouncements, the grand statements of an organization's goals, objectives, or fundamental needs. They typically articulate opportunities to be seized or problems clamoring to be solved. Often, they are found nestled within a business case, a document that, in my experience, is frequently more aspirational than accurate.

  • User (stakeholder) requirements: These occupy the middle ground, articulating the specific needs of a particular stakeholder or group. They often detail how an individual intends to interact with the intended solution, serving as a bridge between the lofty business requirements and the granular demands of the solution itself.

  • Functional (solution) requirements: These are the nitty-gritty details, the specific statements of the functions or capabilities the solution must perform, its behavior, and the information it will handle. Think of formatting text, calculating numbers, or modulating signals. Sometimes, they're simply referred to as capabilities.

  • Quality-of-service (non-functional) requirements: These are the conditions under which the solution must operate effectively, the qualities it must possess, or the constraints it must adhere to. Reliability, testability, maintainability, availability – the "ilities" that make a system more than just a collection of functions. They are also known as characteristics, constraints, or, yes, the ilities.

  • Implementation (transition) requirements: These are the temporary, yet crucial, capabilities or behaviors needed solely to facilitate the shift from the enterprise's current state to its desired future state. Once the transition is complete, their utility evaporates. Think recruitment, role changes, education, or the arduous task of data migration.

  • Regulatory requirements: These are the non-negotiable mandates imposed by laws (at any level of government), contracts, or internal policies. They are the external forces that shape the internal landscape.

The Hallmarks of Excellence: Characteristics of Good Requirements

The definition of a "good" requirement is a topic that has spawned countless treatises. Each author, naturally, emphasizes their own peculiar brand of wisdom. However, a consensus, albeit a grudging one, has emerged around several key characteristics:

Characteristic Explanation
Unitary (Cohesive) It addresses one, and only one, thing. No ambiguity, no conflation of disparate demands.
Complete It is fully articulated in one place. No dangling threads, no missing pieces of information. If you have to infer, it's not complete.
Consistent It doesn't contradict itself or any other authoritative documentation. It plays well with others, so to speak.
Non-Conjugated (Atomic) This is a refinement of "unitary." It means no conjunctions like "and" or "or" that could split it into multiple requirements. For example, "The field must validate American and Canadian postal codes" is a cardinal sin. It should be two separate requirements: one for American codes, one for Canadian. Simplicity, not complexity, is the goal.
Traceable It directly links back to a stakeholder-defined need or business objective. It’s not just a random demand; it serves a purpose.
Current It hasn't been rendered obsolete by the inexorable march of time or technological progress. A requirement from a decade ago might as well be ancient history.
Unambiguous This is paramount. It should be crystal clear, devoid of technical jargon, undefined acronyms, or subjective pronouncements. It expresses objective facts, not personal opinions. There should be only one possible interpretation. Vague subjects, adjectives, prepositions, verbs, and subjective phrases are anathema. Negative and compound statements are also to be avoided.
Specify Importance Some requirements are critical; their absence is a fatal flaw. Others are nice-to-haves, contingent on time and budget. The requirement must clearly state its priority.
Verifiable You must be able to prove, through inspection, demonstration, testing (with instruments, naturally), or analysis (including validated modeling and simulation), that the requirement has been met. If you can't verify it, it's merely a suggestion.

Beyond these core attributes, one could argue for others. Data integrity demands accuracy, correctness, and validity. Traceability, as mentioned, ensures alignment with the original need.

Some purists insist on requirements being "Externally Observable," meaning they pertain to what the user directly experiences. They argue that anything else is a constraint or an internal design decision. I find this perspective a tad narrow. A user might not perceive an interface with a third-party business partner, but its existence might be crucial for delivering the geocoded information they do perceive. The interface is imperceptible, but the information it enables is not. A requirement specifies what the system does; a constraint dictates how it must be done, limiting design alternatives. They are distinct.

The Gauntlet of Proof: Verification

Every single requirement must be verifiable. Testing is the most common method, but if that's not feasible, then analysis, demonstration, inspection, or a review of the design must suffice.

There are certain requirements, often those phrased as "never" or "always," that are inherently unverifiable through conventional means. Proving a negative or an absolute would necessitate an infinite testing cycle. Such pronouncements must be rephrased. As I said, all requirements must be verifiable.

Non-functional requirements, which can be notoriously difficult to verify at the software level, still hold value as indicators of customer intent. They may, however, be traced to process requirements that offer a more practical path to fulfillment. A requirement for the system to be free from backdoors, for instance, might be satisfied by implementing a process requirement for pair programming. Other non-functional requirements will link to different system components and be verified at their respective levels. System reliability, for example, is often verified through system-level analysis. And in the realm of Avionics software, with its intricate safety demands, adherence to processes like DO-178B is non-negotiable.

The activities that lead to the derivation of these requirements constitute Requirements engineering. This often involves a feasibility study or a conceptual analysis phase, followed by requirements elicitation (the arduous process of gathering, understanding, and articulating stakeholder needs), and then requirements analysis (scrutinizing for consistency and completeness), specification (documenting the findings), and finally, validation (ensuring the documented requirements accurately reflect the needs).

Requirements are inherently messy. Ambiguity, incompleteness, and inconsistency are their constant companions. Rigorous inspection can mitigate these issues. It’s a simple truth: problems caught in the requirements phase are orders of magnitude cheaper to fix than those discovered in later stages. Requirements analysis is the necessary evil that tackles these lurking defects.

There's a delicate engineering trade-off to be struck. Requirements that are too vague are useless. But those that are excessively detailed can be equally problematic:

  • They consume an inordinate amount of time to produce, often becoming obsolete before they're even finalized.
  • They stifle innovation by excessively limiting implementation options.
  • Their sheer detail makes them prohibitively expensive to create.

This is where agile software development methodologies found their niche. They propose a high-level baselining of requirements, with details elaborated on a just-in-time basis, or at the "last responsible moment." A more pragmatic approach, perhaps.

The Written Word: Documenting Requirements

Requirements are fundamentally a communication tool, a bridge between disparate stakeholders. Therefore, they must be comprehensible to both the intended users and the developers. A common, if somewhat simplistic, method is to state what the system must do. For example: "The contractor must deliver the product no later than xyz date." Other, more sophisticated methods include use cases and user stories.

The Shifting Sands: Changes in Requirements

Requirements are rarely static. Once defined and approved, they should ideally fall under strict change control. Yet, for many projects, modifications are inevitable, especially given the inherent complexity of software and the human tendency to not truly know what they want until they see it. This fluidity has given rise to the field of requirements management.

The Quagmire: Issues in Requirements

Competing Standards

The landscape is littered with conflicting views on what constitutes a requirement and how it should be managed. The IEEE and the IIBA, two prominent bodies, offer definitions that are similar yet distinct. Navigating this is like trying to find a clear path through a swamp.

Disputes Regarding Necessity and Effects

Surprisingly, many projects have stumbled to success with little to no firm agreement on requirements. Some research even suggests that the act of specifying requirements can actually hinder creativity and design performance. Designers, it seems, can become overly fixated on the provided information, their own innovative spark dampened. Some go so far as to suggest that software requirements are merely an illusion, a convenient narrative constructed when actual requirements are absent.

In contrast, most agile software development methodologies question the upfront rigor of requirement specification, viewing them as a perpetually moving target. Extreme programming, for example, favors informal user stories – brief, index-card-sized summaries of desired functionality – and places the onus on developers to seek direct clarification from the customer. Agile approaches aim to capture requirements through automated acceptance tests.

Requirements Creep

Scope creep is the insidious consequence of requirements evolving over time. While requirements management allows for alterations, if these changes aren't rigorously tracked, or if preceding stages (like business goals and user requirements) aren't adjusted accordingly, then changes become easy and frequent. This can lead to requirement changes outpacing the developers' ability to deliver, creating a frustrating backlog and potential program failure.

Multiple Requirements Taxonomies

As previously touched upon, different frameworks (IEEE, IIBA, U.S. DoD) employ distinct taxonomies. This linguistic and procedural divergence can breed confusion and deviation from desired processes.

Process Corruptions

Human involvement inevitably introduces human flaws. Convenience, personal desires, or political maneuvering can lead to exceptions or outright subversion of established processes. Examples include:

  • Lack of Respect for Rigor: If exceptions and changes are commonplace, or if the organization managing the process lacks independence or transparency, the entire process may be disregarded.
  • The "Do-Over" Mentality: New players often feel compelled to alter their predecessors' work to assert their authority or value. A new CEO might demand a complete overhaul of a project initiated by the previous one. A newly formed office might object to ongoing development because they weren't involved in crafting the initial user requirements, leading to attempts to backtrack and re-baseline the project.
  • "Coloring Outside the Lines": Users, seeking more control, might inject design details or favored vendor characteristics into user requirements, or elevate every office's demand to the highest priority.
  • Procrastination: Minimal effort is expended on requirements elicitation before development begins. This can stem from a belief that participation is inconsequential, that demands can simply be inserted at the testing stage, or a preference for critiquing after the fact to appear perpetually correct.

Within the U.S. Department of Defense, historical examples of requirements issues abound. The M-2 Bradley’s tumultuous development, as depicted in Pentagon Wars, is a prime example of casual requirement movement. The F-16’s evolution from a lightweight fighter concept, driven by the Fighter mafia, is often attributed to attempts to sabotage the F-15 program or individual offices inserting local desires that eroded the original lightweight, low-cost concept. The enthusiasm for "Net-Ready" around 1998 led to its imposition as a Key Performance Parameter by an external office, bypassing established processes and definitions, and forcing it onto efforts where it may not have been appropriate or clearly definable.

It's a complex, often frustrating, but undeniably critical aspect of bringing anything engineered into existence. And frankly, I've said more than enough.