Article by Tom Gilb
The problems with software requirements.
One of our most common problems is that we seem unable to specify what we really want! We have many problems there:
• we specify the ‘means’ not our true ‘ends’
• we specify unclearly (not testable, not measurably)
• we totally fail to identify key stakeholders and their needs
• we ignore specification of constraints, assumptions
• we fail to specify key quality goals at all (serviceability, recoverability,…)
• we fail to specify key economic constraints (future maintenance cost …)
Our currently published requirements specification and analysis discipline is suited only for a program coder (‘functional requirements’), but not for a software engineer or systems engineer.
To discover the problem we have only to ask of a specification: “Why?”, and the answer will be a higher level of specification, nearer the real ends. There are too many designs in our requirements! You might say, why bother? Isn’t the whole point of software to get the code written? Who needs high level abstractions; cut the code! But somehow that code is late and of unsatisfactory quality. And the reason is, partly, lack of attention to the real needs of the stakeholders and the project. We need these high-level abstractions of what our stakeholders need so that we can focus on giving what they are paying us for! So that we can design to find the best technology to satisfy their needs at a competitive cost.
One day software engineers will realize that the primary task is to satisfy their stakeholders. They will learn to design towards stakeholder requirements, which are multiple simultaneous requirements. One day we will become real systems engineers and realize that there is far more to software engineering
than writing code!
