Transcript QUALITY EVALUATION OF SOFTWARE REQUIREMENTS …

ANALYSIS OF SOFTWARE
REQUIREMENTS
S.Gnesi
IEI-CNR Pisa
Joint work with
F.Fabbrini, M.Fusani, G.Lami
REQUIREMENTS
ENGINEERING
Requirements Engineering phase
Level of Detail
People involved
Requirements Definition:
General
st atement, in a natural language plus
diagrams, of what services t he system is
expected to provide and the const raints
under which it must opreate. It is generat e
using customes-supplied information.
Requirements Specificat ion:
Intermediate
a st ructured document which sets out the
system services in det ail. This document
should be precise. It may serve as a
contract between the system buyer and
software developer
Software Specification:
Highly det ailed
abst ract description of the software which
is a basis for design and implementation.
Managerial Level
End-users
System architects
Client engineers
End-users
System architects
Client engineers
SW developers
System architects
SW developers
Techniques for Producing SRS
Approach to Requirements
Specifications
Natural Language
St ruct ured Natural
Language
Semi-formal Languages
Formal Languages
Description
rest ricted natural language where the t erminology is
limited and templates can be used. Cont rol
const ructs derived from programming languages
can be included.
they are usually special-purpose graphical notations
with a precise syntax and a non-rigorous semant ic.
mathematics based languages wit h vocabulary,
synt ax and semantics formally defined.
SRS Quality Model
Set of rules against which to
evaluate a SRD
• Syntactic and semantic rules
• Document structure and sentence
structure characteristics
SRS Quality Evaluation
RSQ related Properties
• Non-Ambiguity: the capability of a Requirement to have a
unique interpretation.
• Completeness: the capability of each Requirement to
make reference to precisely identified entities.
• Understandability: the capability of each Requirement to
be fully understood when used for developing software.
SRS Quality Evaluation
RDQ related Properties
• Completeness: the capability of the Requirements
Specification Document to avoid potential or actual
discrepancies.
• Understandability: the capability of the Requirements
Specification Document to be fully understood when read
by the user.
The Quality Model (I)
PROPERTY
INDICATOR
DESCRIPTION
NOTES
UNDERSTANDABILITY
Implicity
An Implicity Indicator is pointed out in a sentence when the
subject is generic rather than specific
Subject expressed by means of:
· Demonstrative adjective or
Pronouns;
Subject specified by means of:
Adjective or Preposition.
Multiplicity
A Multiplicity Indicator is pointed out in a sentence if the
sentence has more than one main verb or more than one direct
or indirect complement that specifies its subject
Multiplicity-revealing words:
and, or, and/or, …
Comment
Frequency
It is the value of the CFI (Comment Frequency Index). [CFI=
NC / NR where NC is the total number of Requirements
having one or more comments, NR is the number of
Requirements of the RSD]
Readability
Index
It is the value of ARI (Automated Readability Index)
[ARI=WS + 9*SW where WS is the average words per
sentence, SW is the average letters per word]
Directives
Frequency
It is the rate between the number of SRS and the pointers to
figures, tables, notes, .....
Unexplanation
An Unexplaination Indicator is pointed out in a RSD
(Requirement Specifications Document) when a sentence
contain acronyms not explicitly and completely explained
within the RSD itself
The Quality Model (II)
PROPERTY
INDICATOR
DECRIPTION
NOTES
TESTABILITY
CONSISTENCY
COMPLE
TENESS
Optionality
An Optionality Indicator reveels a requirement
sentence containing an optional part (i.e. a part that
can or cannot considered)
Optionality-revealing words: possibly,
eventually, if case, if possible, if
appropriate, if needed, …
Subjectivity
A Subjectivity Indicator is pointed out if sentence
refers to personal opinions or feeling
Subjectivitt-revealing wordings: similar,
better, worse, having in mind, take into
account, as [adjective] as possible
Vagueness
A Vagueness Indicator is pointed out if the sentence
includes words holding inherent vagueness, i.e. words
having a non uniquely quantifiable meaning
Vagueness-revealing words: clear, easy,
strong, good,, efficient, useful, adequate,
fast, recent, near, far, close, in front, ...
Weakness
A Weakness Indicator is pointed out in a sentence
when it contains a weak main verb
Weak verbs: can, could, may.
Underreference
An Under-reference Indicator is pointed out in a RSD
(Requirement Specifications Document) when a
sentence contains explicit references to:
- not numbered sentences of the RSD itself
- documents not referenced into the RSD itself
- entities not defined nor described into the RSD itself
Underspecification
An Under-specification Indicator is pointed out in a
sentence when the subject of the sentence contains a
word identifying a class of objects without a modifier
specifying an instance of this class
This indicator deals with the syntactic
and semantics of the sentence under
evaluation
EXAMPLES
INDICATOR
NEGATIVE EXAMPLE
Implicity
the above requirements shall be verified by test
Optionality
the system shall be such that the mission can be pursued, possibly without
performance degradation
Subjectivity
in the largest extent as possible, the system shall be constituted by
commercially available software products
Vagueness
the C code shall be clearly commented
Weakness
the results of the initialization checks may be reported in a special file
Underspecification
the system shall be able to run also in case of attack
Multiplicity
the mean time needed to remove a faulty board and restore service shall be
less than 30 minutes
Undereference
the software shall be designed according to the rules of the Object
Oriented Design
Unexplaination
the handling of any received valid TC packet shall be started in less than 1
CUT
QuARS Tool
QuARS:
Quality Analyser of
Requirements
Specifications
NL SRS Evaluation Process
Requirements
Specification
Process
produces
TOOL
QuARS
determines
supports
Requiremen ts
Documen t
Review
Process
Quality
Model
changes
performs
Expert Reviewer
Validation Results
S1: Business Application: Functional Requirements of a Transaction and Customer Service (TACS) Check Cashing module;
S2: Space Software Application: Functional Requirements of a sub-system of a space vehicle;
S3:Telecommunication Application: Requirements Specification of a project aiming for a new generation STM switches;
S4: Security Application: Functional Security Requirements for an Application Level Firewall Protection Profile
Rate of defects occurrences on the
total requirements
S4
S3
S2
multiple
underspec
S1
0,0%
vague
implicit
optional
subjective
60,0%
20,0%
40,0%
60,0%
80,0%
100,0%
50,0%
40,0%
30,0%
Percentage distribution of
defects types detected
20,0%
10,0%
0,0%
S4
S3
S2
S1
Conclusions
• A Model for the syntactic quality of SRS
– uncomplete
– including indicators (metrics) numerically and
automatically computable
• An automatic Tool providing support for the
Quality Evaluation of SRS by means of
calculation of the Quality Model metrics