Software Requirements Engineering Lecture #1, Slides of Software Engineering

Download Software Requirements Engineering Lecture #1 and more Slides Software Engineering in PDF only on Docsity!

SOFTWARE REQUIREMENTS

ENGINEERING

LECTURE # 1

INTRODUCTI

ON

Reference

Books

4

 Managi ng Sof tware R equi rements:

A

Use Case A pproach, Second Edi ti on

By

D ean Leff ingwel l, Don Wi dri g, A

ddi son-

Wesl ey

 Sof tware R equi rements,

by

Second

Edi ti on K arl

E. Wi egers I SB N: 0735618798, Mi crosof

t

Press



Kotonya and Sommerville, Requirements

Engineering: Processes and Techniques,

John Wiley Sons.

Requirem

ent

8

 Something required, something wanted

or needed

 Webster’s

dictionary

 There is a huge difference between wanted and needed and it

should be kept

in mind all the

time

 Need - something you have

to have

 Want -something you would like

to have

Software

Requirements

9

 A complete description of what the software system will do without

describing how it

will do it is represented by the software

requirements

 Software requirements are complete specification of the desired

external behavior

of the software system to

be built

Response of

software

 Software requirements

may be:

 Abstract statements of

services

 Detailed mathematical

functions

 Par t of the bid of contract

against the

input

 The contract

itself

 Par t of the technical document, which

describes a product

Sources of

Requirement

11

Stakeholder

s

 People affected in

some

way by the

system

Document

s

Sources of

Requirement

12

 Existing

system

 Application

Domain

Context: Stakeholder's

Environment [6]

14

Importance of Software

Requirements[9]

15

The hardest single part of

building a

software system is deciding

what to

build….. No other part of

the work

so cripples the resulting

system if

done wrong. No other part

is difficult

to rectify later. (Fred

Brooks)

The Root Causes of Project Success

and Failure[1]

17

 Thereafter, the data diverges rapidly. Of course, your

project could fail

 because of an unrealistic schedule or time frame (4 percent of the

projects cited

this)

 inadequate staffing and resources (

percent),

 inadequate technology skills (7 percent), or various

other reasons.

 The survey shows that at least a third of development projects

run into trouble

for reasons that are directly related to requirements

gathering, requirements

documentation, and requirements management.

The Root Causes of Project Success

and Failure[1]

18

 Although the majority of projects do seem to

experience

schedule/budget overruns, the Standish Group found

that 9 percent

of the projects in large companies were delivered on

time and on

budget; 16 percent of the projects in small companies

enjoyed a

similar success. That leads to an obvious question:

What were the

primary "success factors" for those projects?

 According to the Standish study, the three most

important factors were

 User involvement: 16 percent of all

successful projects

Frequency of Requirement

Errors [1]

20

 Table 1. summarizes a 1994 study by Capers Jones

that provides

data regarding the likely number of "potential"

defects in a

development project and the typical "efficiency"

with which a

development organization removes those defects

through various

combinations of testing, inspections, and

other strategies.

Table 1. Defect

Summary

Def ectOrigins Def ect Potentials Removal Ef f iciency Del i vered Def ects

R equi rements

Design

77%

85%

95%

80%

70%

Coding

Documentation

Bad fixes

Total 5. 00 85% 0. 75

Requirements errors top the delivered defects and contribute

approximately one third

of the total delivered defects to the defect pile

High Cost of Requirement

Errors [1]

21

 If a unit cost of one is assigned to the effort

required to

detect and repair an error during the coding

stage ….

High Cost of Requirement

Errors [1]

23

 It's the latter category of errors

that turn

out to be particularly expensive,

for two

reasons.

 By the time the requirements-oriented

error is

discovered, the development

group will

have

invested time and effort in building a

design

from those erroneous requirements. As a

result, the

design will probably have to be thrown

away or

reworked.

 The true nature of the error may be

disguised;

everyone assumes that they're looking

for design

errors during the testing or inspection

activities that

take place during this phase, and

considerable time

and effort may be wasted until someone

says, "Wait

a minute! This isn't a design mistake after

all; we've

Dr. Sohail

High Cost of Requirement

Errors- Defect

Leakage [1]

24

 One organization that has done the research on

defect leakage is

Hughes Aircraft. A study by Snyder and Shumate

[1992] follows the

leakage phenomenon for a large collection of projects

Hughes has

conducted over the past 15 years.

 The study indicates

that

 Defects discovered at Requirements Analysis phase-- 74

percent of

the

requirements-oriented

defects

 Defects discovered at preliminary, or high-level, design-- 4

percent of the requirements defects "leak" and that 7 percent leak further into

detailed design.

 The leakage continues throughout the lifecycle, and a total of 4

percent of the

requirements errors aren't found until maintenance, when

the system has

been released to the customers and is likely in full-scale operation.