04-29-11 | 1

› Matthias Galster, University of Groningen, NL

› Armin Eberlein, American University of Sharjah, UAE

Facilitating Software Architecting by Ranking Requirements based on their Impact on the Architecture Process

04-29-11 | 2

Research problem

› What is the impact of requirements on the software architecture process?

› Goal• Investigate how to rank requirements that

makes them more suitable for architecting

04-29-11 | 3

Background and related work

› Many ranking techniques exist in literature• 1. Select prioritization criteria• 2. Order requirements based on these criteria• 3. Compose individual ordering into final

ordering

› Criteria• Generic requirements categories (e.g.,

mandatory)• Value, etc.

04-29-11 | 4

Proposed method – overview

PreparationPreparation

ExecutionExecution

PresentationPresentation

Create list of atomic requirements

Perform ranking

Present ranking to stakeholders

R = {r1, …, rN}R = {r1, …, rN}

Target rankingTarget ranking

04-29-11 | 5

Stage 1 - preparation

› Specify atomic requirements• To ensure proper requirements attribute

assessment• No differentiation between functional and

non-functional requirements

› Global concerns are not atomized• Key drivers act as criteria when making

design decisions

04-29-11 | 6

Stage 2 – execution

› Assessment of requirements attribute values

› 10 requirements attributes• Characteristics of individual requirements

that affect the architecture process

04-29-11 | 7

Stage 2 – requirements attributesAttribute Description Possible values

effortEstimated cost of implementing rn

1 = low2 = low-medium3 = medium4 = medium-high5 = high

risk

Expected risk of failing to implement rn and potential

to introduce errors into the software

1 = low2 = low-medium3 = medium4 = medium-high5 = high

complexityEstimated difficulty of implementing rn

1 = low2 = low-medium3 = medium4 = medium-high5 = high

early designExistence of design information implied by rn

yesno

dependenciesDependencies of rn with

other requirements

Any combination of requirements in requirements set R

Attribute Description Possible values

volatilityLikelyhood of rn to

change

1 = low2 = low-medium3 = medium4 = medium-high5 = high

hardware constraints

Existence of hardware constraints imposed by rn

yesno

aspects addressed

System aspects addressed by rn

internal communicationexternal communicationuser interfacebusiness logic

importanceImportance of rn as

perceived by stakeholders

1 = low2 = low-medium3 = medium4 = medium-high5 = high

familiarityDevelopers’ knowledge and experience related to rn

1 = low2 = low-medium3 = medium4 = medium-high5 = high

04-29-11 | 8

Stage 3 – presentation

› Four sub-steps

• 1. Definition of impeding forces In for each rn

• 2. Definition of enabling factors En for each rn

• 3. Calculation of the impact of In and En on n

• 4. Calculation of for n each rn

04-29-11 | 9

Stage 3 – impeding forces In

› Attributes which make it difficult to implement rn

› Potential impeding forcesAttribute Criterion

effort

Impeding force if attribute value has the highest value among (effort, risk, complexity, volatility, importance). If more than one attribute share the highest value, more than one impeding force exists.

risk

complexity

volatility

importance

familiarity Impeding force if value of familiarity is “low”.

04-29-11 | 10

Stage 3 – enabling factors En

› Attributes which support the implementation of rn

› Potential enabling factorsAttribute Criterion

effort

Enabling factor if attribute value has a value of “low”. If more than one attribute has a value of “low”, more than one enabling factor exists.

risk

complexity

volatility

importance

familiarity Impeding force if value of familiarity is “high”.

04-29-11 | 11

Stage 3 – impact of In and En on n

IIn = isIF(risk) x (-1) x valueOf(risk) +isIF(volatility) x (-1) x valueOf(volatility) +isIF(importance) x valueOf(importance) + (1)isIF(familiarity) x (-1) x valueOf(familiarity)

EIn = 5 x | En | (2)

04-29-11 | 12

Stage 3 – ranking index n

importancen x (IIn + EIn) iff IIn + EIn > 0

importancen iff IIn + EIn = 0(3)

(1 / importancen) x (IIn + EIn) iff IIn + EIn < 0

n

=

04-29-11 | 13

Post-processing

› Early design (design constraints imposed by reqs)

› Dependencies (“linked” requirements, independent of priority)

› Hardware constraints (descriptions of HW components and interactions)

› Addressed aspects (architecture views affected)

04-29-11 | 14

Case study

› Single-project case study• Experimental setup for VR simulation

› Question• How does the ranking from an architectural

perspective compare to the target ranking?

04-29-11 | 15

Case study: step 1 – preparation

› 26 architecture relevant requirements, e.g.,

• r1: The VR system shall provide real-time interaction.

• r4: The application must display virtual objects of different stiffness.

• r14: The VR system shall provide real-time interaction.

• r17: Rendering must allow for more than 2% of geometric difference between frames.

04-29-11 | 16

Case study: step 2 – execution

› Example attribute valuesrn Attribute values

r1

effort = “high”risk = “high”complexity = “high”early design = “no”dependencies = {r16, r25}

volatility = “low”hardware constraints = “yes”aspects addressed = “business logic”importance = “high”familiarity = “low-medium”

r4

effort = “medium”risk = “medium-high”complexity = “medium-high”early design = “no”dependencies = {r17, r19}

volatility = “low”hardware constraints = “no”aspects addressed = “user interface”importance = “medium”familiarity = “low-medium”

rn Attribute values

r14

effort = “high”risk = “high”complexity = “high”early design = “no”dependencies = {r16, r24}

volatility = “low-medium”hardware constraints = “no”aspects addressed = “user interface”importance = “low-medium”familiarity = “low-medium”

r17

effort = “medium-high”risk = “medium”complexity = “medium-high”early design = “no”dependencies = {r20, r25, r26}

volatility = “low-medium”hardware constraints = “no”aspects addressed = “user interface”importance = “low-medium”familiarity = “low-medium”

04-29-11 | 17

Case study: step 3 – presentation (I)

› Calculation of ranking indices

› Example

• I1 = {effort, risk, complexity, importance}

• E1 = {volatility}

• II1 = [(-1) x 5] + 5 = 0

• EI1 = 5 x 1 = 5

• 1 = 5 x (0 + 5) = 25

04-29-11 | 18

Case study : step 3 – presentation (II)

› Results

Rank RequirementRanking index n

1 r26 1252 r23 563 r22 304 r1 255 r2 256 r12 257 r5 248 r24 249 r9 1810 r3 1611 r18 1612 r20 1413 r21 14

RankRequiremen

tRanking index n

14 r19 1015 r6 416 r7 417 r8 418 r25 419 r4 320 r16 321 r15 222 r17 223 r11 -1.2524 r10 -1.525 r13 -1.6726 r14 -2.5

04-29-11 | 19

Case study: post-processing

› Effect on requirements with similar / identical ranking index

› Dependencies between requirements made some requirements being ranked higher

04-29-11 | 20

Case study: discussion of results (I)

versus priority• 7 / 26 requirements ranked the same

versus actual implementation order• 4 / 26 requirements ranked the same

04-29-11 | 21

Case study – discussion of results (II)

› Diff(rn, n) = rank(rn, n) – rank(rn, actual)(4)

› Diff(rn, prio) = rank(rn, prio) – rank(rn, actual)(5)

0

5

10

15

20

25

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Rank

Difference to actual implementation

order [a.u.]

Difference based on (4) Difference based on (5)

Trend line based on (4) Trend line based on (5)

04-29-11 | 22

Case study: discussion of results (III)

› Different ranking than priority-based ranking

› Ranking closer to actual implementation order

› Acceptable ranking (stakeholders)

› Technically feasible ranking

04-29-11 | 23

Case study: threats to validity

› External validity

› Internal validity

› Cost-benefit analysis

Limitations

› Subjective assessment of attributes• Scalability• Requirements attributes

› Reprioritization / evolving systems

› Integration with other constraints

› Effort / cost

04-29-11 | 24

Summary and conclusions

› Rank requirements from an architecture perspective• No focus on NFR, depends on expert assessment• Can be used “as-is” or with other methods

› Case study• Distance to final implementation order is smaller

› Future:• Experiments, integration with other methods

04-29-11 | 25

04-29-11 | 26

Thank you for your attention

04-29-11 | 27

Case study

› Data collection• List of architecture-relevant requirements• Attribute value assessment• Priority of requirements (used for

comparison)• Final implementation order (used for

comparison)

Backup

04-29-11 | 28

Case study: discussion of results

› Priority and actual implementation order

RankRequirement

(priority-based ranking)Requirement(actual order)

1 r26 (5) r26

2 r12 (5) r3

3 r2 (5) r4

4 r1 (5) r5

5 r3 (4) r6

6 r11 (4) r7

7 r18 (4) r8

8 r23 (4) r2

9 r25 (4) r9

10 r4 (3) r20

11 r13 (3) r21

12 r16 (3) r22

13 r24 (3) r18

RankRequirement

(priority-based ranking)Requirement(actual order)

14 r19 (2) r1

15 r6 (2) r25

16 r7 (2) r23

17 r8 (2) r10

18 r10 (2) r14

19 r5 (2) r15

20 r14 (2) r12

21 r20 (2) r16

22 r17 (2) r17

23 r22 (2) r19

24 r21 (2) r24

25 r9 (1) r13

26 r15 (1) r11

Backup