Cost of Bad Requirements

Loading...

En provenance du cours de University of Colorado System

Requirements Gathering for Secure Software Development

126 notes

University of Colorado System

Requirements Gathering for Secure Software Development

126 notes

Cours 1 sur 5 dans Specialization Requirements Engineering: Secure Software Specifications

In Software Requirements Elicitation for Secure Software Development, we're going to discuss the overall software requirements process as it applies in waterfall, spiral, and agile models. You'll learn about each of these processes and your goals as a software requirements analyst. This is not an easy task! Who do you talk to, when, and what kind of knowledge are you trying to obtain, in any software life cycle? How do you handle obstacles as you go? These are the questions we will focus on answering in this specialization.

À partir de la leçon

The Software Requirement Specification Process and Cost

Software Requirements are a vital part of the Software Development Lifecycle. While there are many ways to go about collecting and recording requirements, the cost of bad requirements is high. Here we discuss what Software Requirements Specifications are and some challenges in writing them well.

The Software Requirement Specification Process7:21

Cost of Bad Requirements3:52

Rencontrer les enseignants

Kristen Walcott-Justice
Assistant Professor
Department of Computer Science

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?

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2019 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play