9.2 Uses of requirements

Beyond their function as an aid to communication requirements have other functions.

9.2.1 Requirements as contract elements

Requirements often form a part of a contract for delivery. This leads to people insisting on the need for a ‘complete’ set of requirements (and the resulting interminable, and often flawed, requirements phase). After all, if the requirements are not established in excruciating detail beforehand, how can we price up and control the project?

Quite simply you cannot, but then again, even with these painfully acquired detailed upfront requirements, most projects[citation needed] fail to deliver. Why? Because requirements change, especially in light of experience. Also, people are better at telling you what is wrong with the delivered system than they are imagining what they need up front5.

Which is more productive? Do something quick and realise it’s wrong, correct course, repeat. Or, spend months trying to write perfect requirements, develop something based on the wrong requirement, deliver something that does not meet the user’s needs but meets the documented requirements. This was realised long before computers were created; models, galley proofs, and prototypes are all attempts to provide customers with something concrete to evaluate and critique before committing to expensive production runs. While these prototypes etc. were intended to be disposed of6, current IT development encourages continual refinement; taking each product and refining it through a deliberate process (in Agile approaches this is the often misunderstood7 ‘refactoring’ process).

9.2.2 Decouple Architecture

We will discuss coupling throughout this course, requirements afford an opportunity to identify boundaries to each component in our system and treat these as stakeholders. This approach has two main benefits: once the stakeholder’s needs are identified (the other component’s API, for example) no additional interaction should be required during requirement capture, secondly it encourages decoupling in our architecture. Clearly defining system component boundaries is one step in decoupling components.

5The old joke springs to mind, “To get the answer to a question online, don’t post the question, post the wrong answer. You’ll quickly get many people eager to point out that you’re wrong and what the correct answer should be.”

6The maxim ‘build one to throw away (you will anyway)’ is often quoted from the original edition of The Mythical Man Month and Other Essays on Software Engineering [Fre74], Brooks meant we should build prototypes so that we can get early feedback. Twenty years later [Fre95, Chapter 19] Brooks revised this advice saying it was ‘too simplistic’ and ‘implicitly assumes the classical waterfall model of software construction’.

7I say ‘misunderstood’ because too many fail to treat refactoring as a definite step, instead muddling it it with development of new features.