1. 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

2. 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

3. 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.

4. 04-29-11 | 4 Proposed method – overview Preparation Execution Presentation Create list of atomic requirements Perform ranking Present ranking to stakeholders R = {r 1, …, r N } Target ranking

5. 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

6. 04-29-11 | 6 Stage 2 – execution ›Assessment of requirements attribute values ›10 requirements attributes Characteristics of individual requirements that affect the architecture process

7. 04-29-11 | 7 Stage 2 – requirements attributes AttributeDescriptionPossible values effort Estimated cost of implementing r n 1 = low 2 = low-medium 3 = medium 4 = medium-high 5 = high risk Expected risk of failing to implement r n and potential to introduce errors into the software 1 = low 2 = low-medium 3 = medium 4 = medium-high 5 = high complexity Estimated difficulty of implementing r n 1 = low 2 = low-medium 3 = medium 4 = medium-high 5 = high early design Existence of design information implied by r n yes no dependencies Dependencies of r n with other requirements Any combination of requirements in requirements set R AttributeDescriptionPossible values volatility Likelyhood of r n to change 1 = low 2 = low-medium 3 = medium 4 = medium-high 5 = high hardware constraints Existence of hardware constraints imposed by r n yes no aspects addressed System aspects addressed by r n internal communication external communication user interface business logic importance Importance of r n as perceived by stakeholders 1 = low 2 = low-medium 3 = medium 4 = medium-high 5 = high familiarity Developers’ knowledge and experience related to r n 1 = low 2 = low-medium 3 = medium 4 = medium-high 5 = high

8. 04-29-11 | 8 Stage 3 – presentation ›Four sub-steps 1. Definition of impeding forces I n for each r n 2. Definition of enabling factors E n for each r n 3. Calculation of the impact of I n and E n on  n 4. Calculation of for  n each r n

9. 04-29-11 | 9 Stage 3 – impeding forces I n ›Attributes which make it difficult to implement r n ›Potential impeding forces AttributeCriterion 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 familiarityImpeding force if value of familiarity is “low”.

10. 04-29-11 | 10 Stage 3 – enabling factors E n ›Attributes which support the implementation of r n ›Potential enabling factors AttributeCriterion 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 familiarityImpeding force if value of familiarity is “high”.

11. 04-29-11 | 11 Stage 3 – impact of I n and E n on  n II n = 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) EI n = 5 x | E n |(2)

12. 04-29-11 | 12 Stage 3 – ranking index  n importance n x (II n + EI n ) iff II n + EI n > 0 importance n iff II n + EI n = 0(3) (1 / importance n ) x (II n + EI n ) iff II n + EI n < 0  n =

13. 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)

14. 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?

15. 04-29-11 | 15 Case study: step 1 – preparation ›26 architecture relevant requirements, e.g., r 1 : The VR system shall provide real-time interaction. r 4 : The application must display virtual objects of different stiffness. r 14 : The VR system shall provide real-time interaction. r 17 : Rendering must allow for more than 2% of geometric difference between frames.

16. 04-29-11 | 16 Case study: step 2 – execution ›Example attribute values rnrn Attribute values r1r1 effort = “high” risk = “high” complexity = “high” early design = “no” dependencies = {r 16, r 25 } volatility = “low” hardware constraints = “yes” aspects addressed = “business logic” importance = “high” familiarity = “low-medium” r4r4 effort = “medium” risk = “medium-high” complexity = “medium-high” early design = “no” dependencies = {r 17, r 19 } volatility = “low” hardware constraints = “no” aspects addressed = “user interface” importance = “medium” familiarity = “low-medium” rnrn Attribute values r 14 effort = “high” risk = “high” complexity = “high” early design = “no” dependencies = {r 16, r 24 } volatility = “low-medium” hardware constraints = “no” aspects addressed = “user interface” importance = “low-medium” familiarity = “low-medium” r 17 effort = “medium-high” risk = “medium” complexity = “medium-high” early design = “no” dependencies = {r 20, r 25, r 26 } volatility = “low-medium” hardware constraints = “no” aspects addressed = “user interface” importance = “low-medium” familiarity = “low-medium”

17. 04-29-11 | 17 Case study: step 3 – presentation (I) ›Calculation of ranking indices ›Example I 1 = {effort, risk, complexity, importance} E 1 = {volatility} II 1 = [(-1) x 5] + 5 = 0 EI 1 = 5 x 1 = 5  1 = 5 x (0 + 5) = 25

18. 04-29-11 | 18 Case study : step 3 – presentation (II) ›Results RankRequirement Ranking index  n 1r 26 125 2r 23 56 3r 22 30 4r1r1 25 5r2r2 6r 12 25 7r5r5 24 8r 24 24 9r9r9 18 10r3r3 16 11r 18 16 12r 20 14 13r 21 14 RankRequirement Ranking index  n 14r 19 10 15r6r6 4 16r7r7 4 17r8r8 4 18r 25 4 19r4r4 3 20r 16 3 21r 15 2 22r 17 2 23r 11 -1.25 24r 10 -1.5 25r 13 -1.67 26r 14 -2.5

19. 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

20. 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

21. 04-29-11 | 21 Case study – discussion of results (II) ›Diff(r n,  n ) = rank(r n,  n ) – rank(r n, actual)(4) ›Diff(r n, prio) = rank(r n, prio) – rank(r n, actual)(5)

22. 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

23. 04-29-11 | 23 Case study: threats to validity ›External validity ›Internal validity ›Cost-benefit analysis

24. Limitations ›Subjective assessment of attributes Scalability Requirements attributes ›Reprioritization / evolving systems ›Integration with other constraints ›Effort / cost 04-29-11 | 24

25. 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

26. 04-29-11 | 26 Thank you for your attention

27. 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

28. 04-29-11 | 28 Case study: discussion of results ›Priority and actual implementation order Rank Requirement (priority-based ranking) Requirement (actual order) 1r 26 (5)r 26 2r 12 (5)r3r3 3r 2 (5)r4r4 4r 1 (5)r5r5 5r 3 (4)r6r6 6r 11 (4)r7r7 7r 18 (4)r8r8 8r 23 (4)r2r2 9r 25 (4)r9r9 10r 4 (3)r 20 11r 13 (3)r 21 12r 16 (3)r 22 13r 24 (3)r 18 Rank Requirement (priority-based ranking) Requirement (actual order) 14r 19 (2)r1r1 15r 6 (2)r 25 16r 7 (2)r 23 17r 8 (2)r 10 18r 10 (2)r 14 19r 5 (2)r 15 20r 14 (2)r 12 21r 20 (2)r 16 22r 17 (2)r 17 23r 22 (2)r 19 24r 21 (2)r 24 25r 9 (1)r 13 26r 15 (1)r 11 Backup