Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
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
1 / 46
4
Managi ng Sof tware R equi rements:
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
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
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
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
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
11
12
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
14
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)
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
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.
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
19
Executive management support: 14 percent of all
successful projects
Clear statement of requirements: 12 percent of all
successful projects
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
21
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.
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
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.
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
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
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.
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.
Information
Systems
Commercial Software
Apps
Embedded Systems