Ch. 6 Lecture NotesIN4MTX 113

February 2010

Requirements Evolution

Chapter 6 Topics

Sources of change Versions (Revisions) and Variants Configuration Management Change propagation Trace links Verifiability Organization of a requirements document for

change

2

Versions and Variants Versions: new in time sequence Variants: members of a product family having

some features in common

3

A Simple Product Family

4

Configuration Management Version control systems (VCSs) capture “the

items to be versioned, the common propertiesshared by all version of an item, and the deltas[and also] determines the way version sets areorganized” [Clemm 2002] An Extensional approaches retrieve reversions of

artifacts that have been previously checked in [Conradi 1998]

Intensional approaches construct artifact versionsbased on rules describing consistent combinations[Conradi 1998]

Example: Subversion Version Control with Subversion

5

Change Propagation What work do you have to do if:

An error is found in a requirments document? A requirement is found to be infeasible

(as a result of trying to design or program a solution)

How does this change when managing a productfamily?

Example: suppose the accelerator pedal “sticks”in a car -- what models do you recall/fix?

6

Trace links

7

Motivating Scenario

Test Suites

ReqSpec

Javapackage

X

Statecharts

X

Structural Design

FuncSpec

Use Cases

Motivating Scenario

Bugreports

Test Suites

ReqSpec

Javapackage

X

Statecharts

Module X

Module XTest Results

Module X

X

Structural Design

FuncSpec

Notes

MgmtReports

Sequence Charts

Use Cases

Gantt Chart

Why Software Traceability?

Questions Why is this component used? Can it be

replaced? Who owns the related artifacts? Is the component tested? Does it meet

requirements (if it exists)?

Traceability aids in System comprehension & impact analysis

[Lindvall 1996, Ramesh 2001, Jarke 1998]

Communication between stakeholders [Pohl 1994]

System debugging [Jarke 1998, Richardson 2004]

It minimizes access time to relevantsoftware artifacts

Multi-faceted Traceability Problem High cost [Jarke 1998, Ramesh 2001]

Explosion of artifact/relationshipspace [Domges 1998, Ramesh 2001]

Link deterioration [Hayes 2007, Ramesh 2001]

Heterogeneity of artifacts[Anderson 2002, Lindvall Practical]

Heterogeneity of tools[Domges 1998, Gotel 1994, Ramesh 1995]

Different groups[Gotel 1994, Ramesh 1995, Ramesh 2001]

Different expectations[Gotel 1994, Ramesh 2001]

Low motivation[Appleton 2005, Almeida 2006, Jarke 1998, Alexander 2002, Hayes 2005]

Others…privacy, politics, low priority, lack of time…[Domges 1998, Gotel 1994, Jarke 1998, Ramesh 1995, Lindval 1996]

Current approaches Information Retrieval Techniques

Automatically generated links have limited link semantics [Spanoudakis2005]

Usually require pre- & post-processing [Cleland-Huang 2007] Software Repository Mining

Specialized searches & retrospective capture of links [Zimmerman2004, Cubranic 2005]

Design Rationale Difficult to retrieve & use [Horner 2005]

Compendium [Shum 2006] – capturing rationale requires significant effort ARM [Tang 2005] caters mainly to architects and assumes the

existence of requirements prior to design Current Link Technology

XML Topic Maps enable manual capture of links

Insights Experience in building an industrial software

traceability tool Software Architecture Open Hypermedia e-Science

Developerperspective

QAperspective

Architect perspective

Field engineerperspective

Bugreports

Internet

Test Suites

ReqSpec

Javapackage

X

Statecharts

X

Localnet

XX

X Internet

X

Module X

Module XTest Results

Module X

ACTS

Chapter6

Figure 6.2 – Ordering features by levels of stability or commonality

Determine meeting date

date more stable than

Notify invited participants

Notify participants by SMS

Determine meeting location

date

Use date preferences Use participant status

Rule-based conflict resolution

more stable than

Figure 6.3 – Traceability links: forward, backward, horizontal, and vertical traceability

Objectives, domain concepts,

requirements, assumptions

Architectural components & connectors

Source code Test data User manual

horizontal

vertical

forward

backward

Figure 6.4 – A taxonomy of traceability link types

Dependency link

Inter-version link Intra-version link

Revision Variant Derivation Use

Subtype

Figure 6.5 – Dependency link type

A dependsOn

Dependency B

affects

Figure 6.6 – Variant link type

A variantOf

Variant

B master

Figure 6.7 – Revision link type

A next

Revision

B previous

Figure 6.8 – Use link type

A uses

Use

B usedBy

Figure 6.9 – Derivation link type

A derivedFrom

Derivation

B metBy

Figure 6.10 – Derivational traceability links implied by satisfaction arguments

SysReq: system requirement ASM: environment assumptions

DOM: domain properties

SOFREQ: software requirements

G: system objective ASM: environment

assumptions

DOM: domain properties

REQ: requirements

G: system objective OP: system operations

Derivation

Derivation

Derivation

0..*

MasterVersion

VariantOf

0..1

0..1

PreviousFrom

NextTo

0..1

Figure 6.11 – Item traceability: an entity-relationship model

1..*

Derivation

DerivedFrom

MetBy

0..*

Use Uses

UsedBy

RD item

RefName Spec

SW lifecycle

item

RefName Spec

DerivedFrom

0..*

1..*

0..*

MasterVersion

VariantOf

0..1

0..1 PreviousFrom

NextTo

0..1

Revision

CM attributes

Variant

CM attributes

Revision

CM attributes

Variant

CM attributes

Inter-version dependencies Intra-version dependencies

Figure 6.12 – Item traceability: model instantiation to meeting scheduling

Derivation

DerivedFrom

Revision

Uses

Participant notification

requirements

Notifier Module

Specs

RefName: NMS

Spec: ….

DerivedFrom

NextTo

Notification Test

Data

RefName: NTD

Spec: …

Notification requirements + SMS notification

MS interface

requirements

MS interface reqs + GSM interface reqs

Revision

Objective: Anywhere anytime notification

Derivation Use

User Manual

Sect.: Notification

RefName: UMN Spec: …

Use

…

RefName: AA-Notif

Spec: ….

RefName: Notif+SMS

Spec: ….

RefName: MSI/GSM

Spec: ….

Inter-version dependencies Intra-version dependencies

Figure 6.13 – Traceability management

Establish

traceability l inks

Exploit

traceability links

Maintain

traceability links

Define

traceability policy

Figure 6.14 – Single-relation traceability graph represented by the matrix in Table 6.2

T1 T2

T3

T4

T5

Figure 6.15 – Feature diagram for variants of the meeting scheduling system

MeetingSchedul ing

MeetingInitiation

ConstraintsAcquisition Planning RuleBased

ConflictResolution

MeetingNoti fication

byEmail byE-agenda Dates Dates&Locations byEmail bySMS

WithPreferences WithoutPreferences

Figure 6.16 – Change control

Change initiation Change evaluation and prioritization

Change consolidation