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