As an example of some of the difficulties that we
run into when trying to write software requirements.
Let's say that we're making a system that's set
up to create meetings within an organization.
In order to figure out what you need to do,
you need to talk to a large amount of people.
This might include the meeting organizer,
a subset of the potential meeting attendees,
meeting participants and likely many others.
These others might include management,
people who will maintain and monitor the system, and maybe others.
Gathering requirements requires talking with
all of these stakeholder groups in an organized fashion.
And this helps us to create a good product overall.
This is all very easy to mess up.
When we mess up in any of these areas,
the cost can be high.
For example, in 1994,
a study was done by a group that found that the US spent
more than 250 billion dollars on IT app development.
The average cost of development projects for large companies, was around $2,322,000.
For medium sized companies they were spending about $1,331,000.
For small companies, about $334 thousand.
31% of those projects within the study were canceled before they were completed.
52% of the projects ended up costing 189% more than their original estimates.
This means that within the US back in 1994,
$81 billion was being spent on canceled projects.
59 billion, was being spent on projects that
would be completed but would exceed the original time estimates.
In the study they also tried to identify some of the main problem areas.
Many of them came back to user requirements,
and the requirements documents.
First, 13% of all the projects suffered from lack of user input.
Second, they had incomplete requirements and incomplete specifications.
12% of the issues came from changing requirements and specifications.
Many of the errors that come about from a lack of requirements,
cause a massive need for rework later on.
Much of the rework is so expensive because we don't find the errors early.
We have to go back and go back and go back.
That links us from, requirements, to design,
to code, to testing,
to maintenance and repeating all of that.
If the error persists into the maintenance phase of development,
the cost to detect it and repair it is on
average about 20 times more than if you find it during coding.
In several studies it's shown that requirements errors are
likely to be the most common class of error in software development.
And requirements errors are likely to be the most expensive errors to fix,
particularly because once they're found,
so much work has already been done before you find the error.
The true nature of the bug is often hidden.
Thus we have to ask the question of,
how do we write good requirements early on?
How do we actually fix?