1

RE Process

Lawrence ChungDepartment of Computer Science/Software Engineering

The University of Texas at Dallas

2

RE Process:What is a Process?

Given input, transforms it into output

Consist of a set of activities

Process descriptions are also “process specifications”!

Often produced by Requirements Engineers Should be as complete, consistent, clear, agile, …

RE Process:Why?

Quality of product Quality of Process

Product

Process

Garbage in garbage out, so get the right requirements

*** Recall: Error Propagation Cycle

4

RE Process:Why?

It is more important to understand the problem than the solution. [Albert Einstein]

If software is simply for automation,what would a washing machine be like?

5

RE Process:The Basic RE Evolutionary Process

Old Reality

Old Model

Old Implementation

New Reality

New Model

New Implementation

ReverseEngineering

ChangeIncorporation

Legacy Integration

Change Definition

Change in Reality

RE Process:The Basic RE Evolutionary Process

Evolution is inevitable – traceability is more than a virtue

- Forward traceability- Backward traceability

7

RE Process:A Basic Framework [Loucopoulos]

Many variations and extensions

3 fundamental activities: understand, (formally) describe, attain an agreement on, the problem

User

ProblemDomain

Elicitation Specification Validation

Elicitation: determine what’s really needed (F/NF), why needed (???), whom to talk to (For, Of, By)

Specification: produce a (formal) RS model: translate "vague" into "concrete", etc. make various decisions on what & how

Validation: assure that the RS model satisfies the users’ needs

Domain knowledge Domain knowledge

User reqsUser feedback

Req. models

Val. result

knowledge

For more knowledge

(domain experts, laws, standards, policies, documents, etc.)

8

RE Process:Spiral Model [KotonyaSummerville98]

How many cycles? When to analyze and negotiate? Risk analysis?

Requirements elicitation Requirements analysis andnegotiation

Requirements documentationRequirements validation

Informal statement ofrequirements

Agreedrequirements

Draft requirementsdocument

Requirementsdocument and

validationreport

Decision point:Accept documentor re-enter spiral

START

Requirements elicitation: Requirements discovered through consultation with stakeholders Requirements analysis and negotiation: Requirements are analysed and conflicts resolved through negotiation Requirements documentation: A requirements document is produced Requirements validation: The requirements document is checked for consistency and completeness

R

e

q

u

i

r

e

m

e

n

t

s

e

l

i

c

i

t

a

t

i

o

n

R

e

q

u

i

r

e

m

e

n

t

s

a

n

a

l

y

s

i

s

a

n

d

n

e

g

o

t

i

a

t

i

o

n

R

e

q

u

i

r

e

m

e

n

t

s

d

o

c

u

m

e

n

t

a

t

i

o

n

R

e

q

u

i

r

e

m

e

n

t

s

v

a

l

i

d

a

t

i

o

n

I

n

f

o

r

m

a

l

s

t

a

t

e

m

e

n

t

o

f

r

e

q

u

i

r

e

m

e

n

t

s

A

g

r

e

e

d

r

e

q

u

i

r

e

m

e

n

t

s

D

r

a

f

t

r

e

q

u

i

r

e

m

e

n

t

s

d

o

c

u

m

e

n

t

R

e

q

u

i

r

e

m

e

n

t

s

d

o

c

u

m

e

n

t

a

n

d

v

a

l

i

d

a

t

i

o

n

r

e

p

o

r

t

D

e

c

i

s

i

o

n

p

o

i

n

t

:

A

c

c

e

p

t

d

o

c

u

m

e

n

t

o

r

r

e

-

e

n

t

e

r

s

p

i

r

a

l

S

T

A

R

T

9

RE Processes:RAD (Role Actor Diagram)

An RE Process is dominated by human, social and organisational factors

ROLES

Understandproblem

Establishoutline

requirements

Selectprototyping

system

Developprototype

Evaluateprototype

ACTIONS

Req. engineerDomain expert

End-userReq. engineer

End-user

Softwareengineer

Project manager

Req. engineerSoftwareengineer

End-userDomain expertReq. engineer

Software engineer

for prototyping [Kotonya&Sommerville98]

Stakeholders/Actors/Agents

Would you use this process for your project?

10

RE Process:A RE Process Maturity Model

Based on CMM

Level 1 - InitialAd-hoc requirements

engineering; requirementsproblems are common

Level 2 - RepeatableStandardised requirements

engineering; fewerrequirements problems

Level 3 - DefinedDefined process basedon best practice; processimprovement in place

5 levels

11

IEEE Standard for SRS[ IEEE-STD-830-1993] [Blum 1992, p160]

1 IntroductionPurposeScope

Definitions, acronyms, abbreviationsReference documentsOverview

2 Overall DescriptionProduct perspective

Product functions

User characteristics

Constraints

Assumptions and Dependencies

3 Specific Requirements

AppendicesIndex

Identifies the product, &application domain

Describes contents and structureof the remainder of the SRS

Describes all external interfaces:system, user, hardware, software;

also operations and site adaptation,and hardware constraints

Summary of major functions

Anything that will limit thedeveloper’s options (e.g. regulations,

reliability, criticality, hardwarelimitations, parallelism, etc)

All the requirements go in here (i.e.this is the body of the document).

IEEE STD provides 8 differenttemplates for this section

[IEEE-STD-830-1998https://iansommerville.com/software-engineering-book/web/requirements-standard/

https://iansommerville.com/software-engineering-book/web/requirements-standard/

12

IEEE Standard Section 3[IEEE-STD-830-1993.] [Blum 1992, p160]

3.1 External Interface Requirements3.1.1 User Interfaces3.1.2 Hardware Interfaces3.1.3 Software Interfaces3.1.4 Communication Interfaces

3.2 Functional Requirementsthis section organized by mode, userclass, feature, etc. For example:

3.2.1 Mode 13.2.1.1 Functional Requirement 1.1

…3.2.2 Mode 2

3.2.1.1 Functional Requirement 1.1

…...3.2.n Mode n

...

3.3 Performance RequirementsRemember to state this in measurable terms!

3.4 Design Constraints3.4.1 Standards compliance3.4.2 Hardware limitationsetc.

3.5 Software System Attributes3.5.1 Reliability3.5.2 Availability3.5.3 Security3.5.4 Maintainability3.5.5 Portability

3.6 Other Requirements

13

RE in Agile Methods

Basic PhilosophyReduce communication barriers

Programmer interacts with customerReduce document-heavy approach

Documentation is expensive and oflimited use

Have faith in the peopleDon’t need fancy process models to tellthem what to do!

Respond to the customerRather than focussing on the contract

WeaknessesRelies on programmer’s memory

Code can be hard to maintainRelies on oral communication

Mis-interpretation possibleAssumes single customer representative

Multiple viewpoints not possibleOnly short term planning

No longer term vision

E.g. Extreme ProgrammingInstead of a requirements spec,

use:User story cardsOn-site customer representative

Pair ProgrammingSmall releases

E.g. every three weeksPlanning game

Select and estimate user story cardsat the beginning of each release

Write test cases before codeThe program code is the design doc

Can also use CRC cards (Class-Responsibility-Collaboration)

Continuous IntegrationIntegrate and test several times a day

Would you always use an agile process?

Appendix

14

15

RE Processes:Volere Requirements Process

How many cycles? When to analyze and negotiate?

16

RE in V Model

systemrequirements

systemintegration

softwarerequirements

preliminarydesign

detaileddesign

code &debug

acceptancetest

softwareintegration

componenttest

unittest

Time

Leve

l of

abst

ract

ion

17

RE Processes:RE Process Variability

Many Variety …and Evolution is inevitable

RE processes vary radically from one organisation to another

Factors contributing to this variability include Technical maturity Disciplinary involvement Organisational culture Application domain …

There is therefore no ‘ideal’ requirements engineering process [KotonyaSummerville98]

18

NFRs & RE Process:A Requirements Management System

Many variations and extensions

Requirementsdatabase

NLrequirements

documentReq. convertor

WP linker

Traceabilitysupport system

Report generator

Traceabilityreport

Requirementsreport

Req. browser Req. querysystem

Change controlsystem

RE ProcessRE Process:�What is a Process?RE Process:�Why?RE Process:�Why?RE Process:�The Basic RE Evolutionary ProcessRE Process:�The Basic RE Evolutionary ProcessRE Process:�A Basic Framework [Loucopoulos]RE Process:�Spiral Model [KotonyaSummerville98]RE Processes:�RAD (Role Actor Diagram)RE Process:�A RE Process Maturity ModelIEEE Standard for SRSIEEE Standard Section 3RE in Agile MethodsSlide Number 14RE Processes:�Volere Requirements ProcessRE in V ModelRE Processes:�RE Process VariabilityNFRs & RE Process:�A Requirements Management System