Explorez l'intégralité de Coursera

For Enterprise

Join for Free
Log In

Arts et humanités
Business
Informatique
Science des données
Technologies de l'information
santé
Mathématiques et logique
Développement personnel
Sciences physiques et ingénierie
Sciences sociales
Apprentissage des langues
Diplômes
Certificats

Explorez l'intégralité de Coursera

Parcourir
Rechercher
For Enterprise
Connexion
Inscrivez-vous gratuitement

Cost of Bad Requirements

Loading...

Requirements Gathering for Secure Software Development

University of Colorado System

4.5 (146 notes) | 2.6K étudiants inscrits

Cours 1 de 5 dans Requirements Engineering: Secure Software Specifications Spécialisation

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.

Visualiser le programme de cours

Compétences que vous apprendrez

Requirements Elicitation, Requirements Analysis, Software Requirements, Requirements Engineering

Avis

4.5 (146 notes)

5 stars
102 ratings
4 stars
22 ratings
3 stars
12 ratings
2 stars
9 ratings
1 star
1 ratings

RK

Feb 21, 2018

The instructor is too good. And her wit is wonderful.

NM

Mar 12, 2019

The best and advanced way of learning with COURSERA

À 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

Enseigné par

Kristen Walcott-Justice
Assistant Professor

Transcription

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

Coursera
À propos
Direction
Carrières
Catalogue
Certificats
Certificats MasterTrack™
Diplômes
For Enterprise
For Government

Communauté
Learners
Partners
Developers
Beta Testers
Translators

Se connecter
Blog
Facebook
LinkedIn
Twitter
Instagram
YouTube
Blog Tech

Plus
Conditions
Confidentialité
Aide
Accessibilité
Presse
Contact
Répertoire
Filiales