Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Software Requirements Engineering Lecture #1, Slides of Software Engineering

The importance of software requirements engineering and the different types of requirements, including functional, non-functional, domain, and inverse requirements. It also covers the sources of requirements, the root causes of project success and failure, and the high cost of requirement errors. reference books and tables summarizing studies on requirement errors and defect leakage. It emphasizes the need for complete and consistent requirements to avoid project challenges and dissatisfaction.

Typology: Slides

2021/2022

Available from 08/18/2022

SamenKhan
SamenKhan 🇵🇰

231 documents

Partial preview of the text

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.

Presentation

Outline

7              

What is

Requirement?

Software

Requirements

Sources of

Requirements

The Goal of Software

Development

Stakeholder’s Environment

Customer’s Types

Root Causes of Project Success

and Failures

The Frequency of Requirement

Errors

The High Cost of Requirement

Errors

Requirements Management

Types of Software Applications

Types of Software Requirements

The Problem Domain

The Solution

Domain

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

Requirement

[7]

10

Can be

constrai

nt

functional

ity

 A condition or capability that must be met or possessed

by a system...to

satisfy a contract, standard, specification, or other

formally imposed

document

 IEEE Std

729

Sources of

Requirement

11

Stakeholder

s

 People affected in

some

way by the

system

Document

s

Sources of

Requirement

12

 Existing

system

 Application

Domain

The Goal of Software

Development [1]

13

 The goal of software development

is to

develop quality software—on time

and on

budget—that meets customers' real

needs.

 A software is good if it

STAKEHOLDERS MEETS

EXPECTATIONS:

 it is (at least) correct, reliable,

maintainable, user-

friendly …

 the total cost it incurs over all phases of its

life cycle is minimal and within the

budget

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]

16

 The first step in resolving any problem is to understand

the root causes.

 The 1994 Standish Group sur vey study noted the

three most

commonly cited factors that caused projects to be

"challenged":

Lack of user input: 13 percent of all projects

Incomplete requirements and specifications: 12

percent of all projects

Changing requirements and specifications: 12

percent of all projects

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

The Root Causes of Project Success

and Failure[1]

19

Executive management support: 14 percent of all

successful projects

Clear statement of requirements: 12 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]

22

 The errors discovered during the design of a development

project could

fall into one of two

categories:

 errors that occurred when the development staff created a

technical design from a correct set of

requirements or

 errors that should have been detected as requirements errors

somewhat earlier

in the process but that somehow "leaked" into the design

phase of the project.

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.

High Cost of Requirement

Errors- Defect

Leakage [1]

25

 whenever a defect is discovered in a software

application, we're

likely to experience the effect of 50 – 100

times cost.

 Re-

specification.

Redesign.

Recoding.

Retesting.

 Change orders

 Corrective

action

High Cost of Requirement

Errors- Defect

Leakage [1]

26

 Scrap

 Recall of defective versions of software and

associated manuals from

users.

 Warranty

costs.

 Product

liability

 Service costs for a company representative

to visit a customer's field location to reinstall the

new software.

Documentation

Requirements Engineering

Process

27

Elicitation: work with the customer

on gathering

requireme

nts

Analysis: process this

information to

understand it, classify in various

categories,

and relate the customer

needs to

possible software requirements

Specification: Structure the

customer input

and derived requirements as

written

documents and diagrams

Validation: you’ll ask your customer

to confirm

that what you’ve written is

accurate and

complete and to correct errors.

Requirements

Management [10]

28

Requirement

s

managem

ent

is the proces

s

of

documenting, analyzing, tracing, prioritizing and agreeing on

requirements and then

controlling change and communicating to relevant stakeholders.

Types of Software

Apps

 Information

Systems

 Commercial Software

Apps

 Embedded Systems