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:statement, in a natural language plus

diagrams, of what services the system isexpected to provide and the constraints

under which it must opreate. It is generateusing customes-supplied information.

General Managerial LevelEnd-users

System architectsClient engineers

Requirements Specification:a structured document which sets out the

system services in detail. This documentshould be precise. It may serve as acontract between the system buyer and

software developer

Intermediate End-usersSystem architects

Client engineersSW developers

Software Specification:abstract description of the software whichis a basis for design and implementation.

Highly detailed System architectsSW developers

Techniques for Producing SRS

Approach to Requirements

Specifications

Description

Natural Language -

Structured NaturalLanguage

restricted natural language where the terminology islimited and templates can be used. Control

constructs derived from programming languagescan be included.

Semi-formal Languages they are usually special-purpose graphical notationswith a precise syntax and a non-rigorous semantic.

Formal Languages mathematics based languages with vocabulary,

syntax 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 EvaluationRDQ 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

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, .....

Unexplana- tion

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

UN

DE

RS

TA

ND

AB

ILIT

Y

The Quality Model (II)PROPERTY INDICATOR DECRIPTION NOTES

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.

Under-reference

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

Under- specification

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

TE

ST

AB

ILIT

YC

ON

SIS

TE

NC

Y

CO

MP

LE

TE

NE

SS

EXAMPLESINDICATOR 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

--------- --------- ---------

- -- - -- -- -- -- - - --- --

- -- - -- -- -- -- - - --- --

- -- - -- -- -- -- - - --- --

GRAMMAR

SYNTACTICAL RECOGNISER

TREE BUILDER

QUALITY EVALUATOR TYPE A

QUALITY EVALUATOR TYPE B

SRS Phrases

SYNTACTICAL ANALYSER

WARNING MESSAGES

SPECIAL DICTIONARIES

QuARS:

Quality Analyser of Requirements Specifications

NL SRS Evaluation Process

Requirements

Specification Process

Requirements

Document

Review

Process

Quality

Model

Expert Reviewer

TOOL

produces

supports

performs

determines

changes

QuARS

Validation Results

0,0% 20,0% 40,0% 60,0% 80,0% 100,0%

S1

S2

S3

S4

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

S1

S2

S3

S4

multiple vague optional

underspec implicit subjective

Rate of defects occurrences on the total requirements

Percentage distribution of defects types detected

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

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