Post on 03-Apr-2018
transcript
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
1/41
1
Requirements ErrorsII
Lecture # 15
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
2/41
2
Todays Topic and Recap
We discussed requirements errors inthe last lecture
Introduced different types of errors
Discussed defect prevention
Today well talk about defect removaland in particular inspections using,perspective-based reading
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
3/41
3
Defect Removal
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
4/41
4
Inspections - 1
Inspections, by all accounts, do a better
job of error removal than any
competing technology, and they do it
at a lower cost
Robert Glass
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
5/41
5
Inspections - 2
Inspections are conducted by a group of
people working on the project, with the
objective to remove defects or errors
Every member of the inspection team has to
read and evaluate requirements documents
before coming to the meeting and a formalmeeting is conducted to discuss
requirements errors
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
6/41
6
Inspections - 3
Requirements errors detected during
this inspections save lot of money and
time as requirements errors do not flow
into the design and development
phases of software development
process
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
7/41
7
Inspections - 4
A complete description of inspections
must address five dimensions:
Technical
Managerial
OrganizationalAssessment
Tool support
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
8/41
8
Defect Detection Without
Inspections
Requirements Design Coding Documentation Testing Maintenance
Requirements Design Coding Documentation Testing Maintenance
Defect Origins
Defect Discovery Chaos Zone
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
9/41
9
Defect Detection With Inspections
Requirements Design Coding Documentation Testing Maintenance
Requirements Design Coding Documentation Testing Maintenance
Defect Origins
Defect Discovery
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
10/41
10
Observations
Requirements engineers are trained to write
requirements documents, but have no
training on reading/reviewing requirementsdocuments
Reviewers typically rely on ad hoc reading
techniques, with no well-defined procedure,learning largely by doing
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
11/41
11
Techniques for Reading
Requirements Documents Ad hoc review
Checklist review
Defect-based reading
Perspective-based reading
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
12/41
12
Ad hoc Review
A review with no formal, systematic
procedure, based only individual
experience
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
13/41
13
Checklist Review
A list of items is provided to reviewers,
which makes this inspection process
more focused
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
14/41
14
Defect-based Reading
Provides a set of systematic procedures
that reviewers can follow, which are
tailored to the formal software cost
reduction notation
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
15/41
15
Perspective-Based Reading (PBR)
Researchers at Experimental SoftwareEngineering Group at the University of
Maryland, College Park, have createdPerspective-Based Reading (PBR) to
provide a set of software reading
techniques for finding defects inEnglish-language requirementsdocuments
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
16/41
16
Different Perspectives - 1
PBR operates under the premise that
different information in the requirements is
more or less important for the different usesof the document
Each user of the requirements document
finds different aspects of the requirementsimportant for accomplishing a particular
task
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
17/41
17
Different Perspectives - 2
PBR provides a set of individual reviews,
each from a particular requirements users
point of view, that collectively cover thedocuments relevant aspects
This process is similar to constructing
system use cases, which requires identifyingwho will use the system and in what way
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
18/41
18
Steps in PBR
Selecting a set of perspectives for reviewingthe requirements document
Creating or tailoring procedures for eachperspective usable for building a model ofthe relevant requirements information
Augmenting each procedure with questionsfor finding defects while creating the model
Applying procedures to review thedocument
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
19/41
19
Two Questions
What information in these documents
should they check?
How do they identify defects in that
information?
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
20/41
20
Benefits of Different Perspectives - 1
Systematic
Explicitly identifying the different uses for the
requirements gives reviewers a definiteprocedure for verifying whether those uses areachievable
Focused
PBR helps reviewers concentrate moreeffectively on certain types of defects, ratherthan having to look for all types
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
21/41
21
Benefits of Different Perspectives - 2
Goal-oriented and customizable
Reviewers can tailor perspectives based on the
current goals of the organization
Transferable via training
PBR works from a definite procedure, and not
the reviewers own experience with recognizingdefects, new reviewers can receive training in
the procedures steps
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
22/41
22
Identifying Defects
A series of questions are used to identify
different types of requirements defects
Requirements that do not provide enoughinformation to answer the questions usually
do not provide enough information to
support the user. Thus, reviewers canidentify and fix defects beforehand
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
23/41
23
Requirements Defects that PBR
Helps Detect Missing information
Ambiguous information
Inconsistent information
Incorrect fact
Extraneous information
Miscellaneous defects
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
24/41
24
Missing Information - 1
Any significant requirement related to
functionality, performance, design
constraints, attributes, or external
interface not included
Undefined software responses to allrealizable classes of input data in all
realizable classes of situations
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
25/41
25
Missing Information - 2
Sections of the requirements document
Figure labels and references, tables,
and diagrams
Definitions of terms and units of
measures
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
26/41
26
Ambiguous Information
Multiple interpretations caused by
using multiple terms for the same
characteristic or multiple meanings of
a term in a particular context
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
27/41
27
Inconsistent Information
Two or more requirements that conflict
with one another
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
28/41
28
Incorrect Facts
A requirement-asserted fact that cannot
be true under the conditions specified
for the system
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
29/41
29
Extraneous Information
Unnecessary or unused information (at
best, it is irrelevant; at worst, it may
confuse requirements users)
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
30/41
30
Miscellaneous Defects
Other errors, such as including a
requirement in the wrong section
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
31/41
31
Benefits of PBRs Detailed
Questions Allow controlled improvement
Reviewers can reword, add, or delete
specific questions Allow training
Reviewers can train to better understand
the parts of a representation or workproduct that correspond to particularquestions
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
32/41
32
PBR General Questions - 1
Does the requirement make sense fromwhat you know about the application or
from what is specified in the generaldescription?
Do you have all the information necessaryto identify the inputs to the requirement?
Based on the general requirements and yourdomain knowledge, are these inputs correctfor this requirement?
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
33/41
33
PBR General Questions - 2
Have any of the necessary inputs been
omitted?
Are any inputs specified that are not
needed for this requirement?
Is this requirement in the appropriatesection of the document?
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
34/41
34
Results of PBR Experiments - 1
PBR provides a framework that represents
an improved approach for conducting
requirements reviews This approach will only be effective when
an organization tailors the framework to its
own needs and uses feedback from itsreviewers to continually improve and refine
the techniques
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
35/41
35
Results of PBR Experiments - 2
PBR seems best suited for reviewers
with a certain range of experience (not
too little; not too much)
Development teams that use PBR to
inspect requirements documents tend
to detect more defects than they do
using other less- structured approaches
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
36/41
36
Results of PBR Experiments - 3
Relatively novice reviewers can use PBR
techniques to apply their expertise in other
development tasks to defect detection Using PBR improves team meeting by
helping team members build up expertise in
different aspects of a requirementsdocument
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
37/41
37
Results of PBR Experiments - 4
It creates high-level representations of
the software system, usable as a basis
of work products in later stages of thedevelopment
Each development organization can
customize PBRs set of perspectives,
level of detail, and types of questions
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
38/41
38
Results of PBR Experiments - 5
PBR facilitates controlled
improvements, providing a definite
procedure, alterable according toprojects metrics and reviewers
feedback
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
39/41
39
Summary
Discussed defect removal and in
particular inspections using,
perspective-based reading
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
40/41
40
References - 1 Software Engineering: A Practitioners
Approach by Roger S. Pressman
A Handbook of Software Quality Assurance
edited by G. Gordon Schulmeyer and JamesL. McManus
Customer-Oriented Software Quality
Assurance by Frank P. Ginac Software Quality: Analysis and Guidelinesfor Success by Capers Jones
7/29/2019 Requirement Enginering Software Requirement Tutorial 15
41/41
41
References - 2
How Perspective-Based Reading Can
Improve Requirements Inspections by
Forrest Shull, Ioana Rus, & VictorBasili, IEEE Computer, July 2000, pp.
73-79