In the last episode—Is software engineering a thing?—I (apparently controversially) suggested that software is the reification of thought, and that software engineering is thus the art of reifying thought, and that thus there can’t be any single one-size-fits-all software engineering approach. Let’s dig in.
One of the big questions in a software project, hence one of the big topics in software engineering, is requirements: who wants the software to do something, do we need to pay attention to them, and what do they want it to do? We’re already well into the realm of individuals and interactions—whether the people building the thing and the people telling them what to build can agree on what one of the two groups thinks they mean—and haven’t got as far as building software yet. There’s plenty of software engineering ink spilled in this domain, but it can be hard to even decide whether to agree at a metaphysical level with some of it.
Taking a convenience sample (i.e. what’s the nearest book on my shelf that I think might mention software requirements), Shari Pfleeger’s “Software Engineering: the Production of Quality Software” asks “What is a requirement?” and supplies its own answer:
A requirement is a feature of the system or a description of something the system is capable of doing in order to fulfill the system’s purpose.
Enquiring minds have many questions, but let’s focus on questions pertaining to reality. Does the system have an objective, positive purpose that can be said to exist? Does the requirement support that purpose, or does someone just think or hope that it does? Does the requirement-as-description accurately capture the expectation of the person who thought it?
With this level of reflection, we can still expect a field of software engineering to say something about requirements, and for understanding that to help with constructing software, but not for it to supply a single solution to “how to requirements”. And without that, much of the rest of software engineering naturally bifurcates or multifurcates. For example, verification and validation is about whether the software does what it ought—or whether someone thinks the software does what they think it ought—but we’re back to asking our question of whether we have (or can) accurately capture that.
