Requirements quality

A theoretical introduction

Contents

2

Current situation in sw development

Why requirements are so important

What is the quality target

ARM project

Requirements Quality Analyzer: RQA

Requirements quality (A theoretical introduction) - (C) The REUSE Company

Current situation in sw. development

Requirements quality (A theoretical introduction) - (C) The REUSE Company 3

32%

44%

24%

The Chaos report 2009

Successful Challenged Failed

Why requirements are so important

Requirements quality (A theoretical introduction) - (C) The REUSE Company 4

Success key factors % of answers 1. User Involvement 15.9%

2. Executive Management Support 13.9%

3. Clear Statement of Requirements 13.0%

4. Proper Planning 9.6%

5. Realistic Expectations 8.2%

6. Smaller Project Milestones 7.7%

7. Competent Staff 7.2%

8. Ownership 5.3%

9. Clear Vision & Objectives 2.9%

10. Hard-Working, Focused Staff 2.4%

Other 13.9%

+40% directly related to

requirements

15.9%

13.0%

8.2 %

2.9 %

Based on requirements

Why requirements are so important

Requirements quality (A theoretical introduction) - (C) The REUSE Company 5

Requirements:

Should be signed as a contract between developer and customer

Are the basis for software design

Man role also during the testing phase

Why requirements are so important

Requirements quality (A theoretical introduction) - (C) The REUSE Company 6

Software projects are more and more complex over the time

The sooner a problem is tackled the less the solution costs

0

50

100

150

200

1 3 10 15 30

50

200

Cost

What is the quality target

Requirements quality (A theoretical introduction) - (C) The REUSE Company 7

According to IEEE Std. 830 – 1998:

Correct

Unambiguos

Complete

Consistent

Ranked (importance and stability)

Verifiable

Modifiable

Traceable

What is the quality target

Requirements quality (A theoretical introduction) - (C) The REUSE Company 8

According to ESA PSS-05-03:

SR04 Each software requirement shall include an identifier.

SR05 Essential software requirements shall be marked as such.

SR06 For incremental delivery, each software requirement shall include a measure of priority so that

the developer can decide the production schedule.

SR07 References that trace software requirements back to the URD shall accompany each software

requirement.

SR08 Each software requirement shall be verifiable.

SR11 The SRD shall be complete.

SR12 The SRD shall cover all the requirements stated in the URD.

SR13 A table showing how user requirements correspond to software requirements shall be placed in

the SRD.

SR14 The SRD shall be consistent.

SR15 The SRD shall not include implementation details or terminology, unless it has to be present as a

constraint.

SR16 Descriptions of functions ... shall say what the software is to do, and must avoid saying how it is to

be done.

SR17 The SRD shall avoid specifying the hardware or equipment, unless it is a constraint placed by the

user.

What is the quality target

Requirements quality (A theoretical introduction) - (C) The REUSE Company 9

"I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him safely to Earth"

Letter Term Description

S Specific Clear and simple: a single need

M Measurable Can you measure whether the goal has been achieved or not

A Aligned Is the goal aligned with the strategy of the

company/development

R Relevant Can be achieved with a realistic number of resources

T Time-framed Clear time limits

What is the quality target

Requirements quality (A theoretical introduction) - (C) The REUSE Company 10

All these targets seem to be clear

RM tools (e.g. DOORS or IRQA) help us in some cases:

Modifiable, traceable…

But, let us double check these targets

Are all these quality goals really unambiguous

Spanish proverb: «In the blacksmith’s home wooden knife»

ARM project

Requirements quality (A theoretical introduction) - (C) The REUSE Company 11

ARM:

Automated Requirement Measurement by NASA

«The objective of the ARM tool is to provide measures that can be used

by project managers to assess the quality of a requirements specification

document»

The ARM tool scans a requirements specification document for key

words and phrases and generates a report file summarizing the specific

quality indicators

The tool is not intended to evaluate the correctness of the specified

requirements; it’s an aid to “writing the requirements right”, not “writing

the right requirements”

ARM analyzes a whole specification, req by req, and is able to show

which aspects of a requirement should be avoided

ARM project

Requirements quality (A theoretical introduction) - (C) The REUSE Company 12

Objectively measured indicators vs. quality attributes

Requirements Quality Analyzer

Requirements quality (A theoretical introduction) - (C) The REUSE Company 13

RQA (Requirements Quality Analyzer) is a tool by The REUSE

Company

In the same way as ARM, RQA try to obtain objective quality

measurements

RQA works, nowadays, in English and Spanish

The main differences between RQA and ARM:

RQA includes much more metrics that ARM

RQA is fully connected to DOORS and IRQA

RQA is fully customizable

RQA uses linguistic capabilities and not keyword spotting

RQA uses semantic capabilities to provide global metrics

RQA allows you cicles of change text and assess quality as many

times as needed

Requirements Quality Analyzer

Requirements quality (A theoretical introduction) - (C) The REUSE Company 14

More information about Requirements Quality Analyzer:

http://www.reusecompany.com