Supporting Agile Requirements Evolution via Paraconsistent Reasoning
•
1 gostou•1,493 visualizações
Innovative companies need an agile approach for the engineering of their product requirements, to rapidly respond to and exploit changing conditions. The agile approach to requirements must nonetheless be systematic, especially with respect to accommodating legal and nonfunctional requirements. This paper examines how to support a combination of lightweight, agile requirements which can still be systematically modeled, analyzed and changed. We propose a framework, RE- KOMBINE, which is based on a propositional language for requirements modeling called Techne. We define operations on Techne models which tolerate the presence of inconsistencies in the requirements. This para- consistent reasoning is vital for supporting delayed commitment to par- ticular design solutions. We evaluate these operations with an industry case study using two well-known formal analysis tools. Our evaluations show that the proposed framework scales to industry-sized requirements models, while still retaining (via propositional logic) the informality that is so useful during early requirements analysis.
Recomendados
Recomendados
Mais conteúdo relacionado
Último
Último (20)
Destaque
Destaque (20)
Supporting Agile Requirements Evolution via Paraconsistent Reasoning
- 1. Agile Requirements Evolution via Paraconsistent Reasoning Neil A. Ernst University of British Columbia @neilernst • neil@neilernst.net • neilernst.net with: Alexander Borgida, John Mylopoulos and Ivan Jureta borgida@cs.rutgers.edu, jm@disi.unitn.it, Thursday, 28 June, 12 ijureta@fundp.ac.be
- 2. page 382 of proceedings Agile Requirements Evolution via Paraconsistent Reasoning Neil A. Ernst University of British Columbia @neilernst • neil@neilernst.net • neilernst.net with: Alexander Borgida, John Mylopoulos and Ivan Jureta borgida@cs.rutgers.edu, jm@disi.unitn.it, Thursday, 28 June, 12 ijureta@fundp.ac.be
- 3. Takeaway We need agile requirements models — that can still be systematically analysed. Thursday, 28 June, 12
- 4. Takeaway We need agile requirements models — that can still be systematically analysed. • Motivation Thursday, 28 June, 12
- 5. Takeaway We need agile requirements models — that can still be systematically analysed. • Motivation • Formal representation of a requirements problem as a knowledge base. Thursday, 28 June, 12
- 6. Takeaway We need agile requirements models — that can still be systematically analysed. • Motivation • Formal representation of a requirements problem as a knowledge base. • How paraconsistent reasoning helps us support dynamism. Thursday, 28 June, 12
- 7. Takeaway We need agile requirements models — that can still be systematically analysed. • Motivation • Formal representation of a requirements problem as a knowledge base. • How paraconsistent reasoning helps us support dynamism. • Evaluation, how this works in practice. Thursday, 28 June, 12
- 8. Agility ... Test Devel. Ops Req time Thursday, 28 June, 12
- 9. Agility ... Test Devel. Ops Req time Thursday, 28 June, 12
- 10. Agility ... Test Devel. Ops Req time Thursday, 28 June, 12
- 11. Agility ... Test Devel. Ops Req time Thursday, 28 June, 12
- 12. Agility ... Test Devel. Ops Req time Thursday, 28 June, 12
- 13. Requirements agility is constrained Thursday, 28 June, 12
- 14. Requirements agility is constrained Let’s add remote login Thursday, 28 June, 12
- 15. Requirements agility is constrained Let’s add remote login Security hole Thursday, 28 June, 12
- 16. Requirements agility is constrained Let’s add remote login Security hole How about removing RSA? Thursday, 28 June, 12
- 17. Requirements agility is constrained Let’s add remote login Security hole How about removing Not back-compatible RSA? Thursday, 28 June, 12
- 18. Requirements agility is constrained Let’s add remote login Security hole How about removing Not back-compatible RSA? Simplify account mgmt? Thursday, 28 June, 12
- 19. Requirements agility is constrained Let’s add remote login Security hole How about removing Not back-compatible RSA? Simplify account mgmt? Violates Sarbanes-Oxley Thursday, 28 June, 12
- 20. Requirements agility is constrained Let’s add remote login Security hole How about removing Not back-compatible RSA? Simplify account mgmt? Violates Sarbanes-Oxley Add COO’s pet feature? Thursday, 28 June, 12
- 21. Requirements agility is constrained Let’s add remote login Security hole How about removing Not back-compatible RSA? Simplify account mgmt? Violates Sarbanes-Oxley Add COO’s pet feature? CEO hates COO Thursday, 28 June, 12
- 22. Requirements agility means success Thursday, 28 June, 12
- 23. Requirements agility means success Thursday, 28 June, 12
- 24. “[the code] remained operational in Ariane 5 without satisfying any (traceable) requirement.” Thursday, 28 June, 12
- 25. Thursday, 28 June, 12
- 26. Command Executions edit.Delete 5.4 M file.Save 4.3 M edit.Paste 3.8 M edit.Copy 2.4 M ContentAssist.proposals 1.4 M Thursday, 28 June, 12
- 27. Command Executions edit.Delete 5.4 M file.Save 4.3 M edit.Paste 3.8 M edit.Copy 2.4 M ContentAssist.proposals 1.4 M Command Executions window.previousView 9 navigate.Back 69 window.showViewMenu 89 window.previousPerspective 155 window.previousEditor 166 Data: Eclipse UPP, 200908, eclipse.ui, 3.5.0 Thursday, 28 June, 12
- 28. Requirements problems Thursday, 28 June, 12
- 29. Requirements problems R R R Thursday, 28 June, 12
- 30. Requirements problems R R R r r Thursday, 28 June, 12
- 31. Requirements problems R R R r r T T T T T Thursday, 28 June, 12
- 32. Requirements problems R R R r r T T T T T Thursday, 28 June, 12
- 33. Requirements problems R R R r r T T T T T D D Thursday, 28 June, 12
- 34. Requirements problems R R R r r T T T T T D D Thursday, 28 June, 12
- 35. Requirements problems R R R r r T T T T T D D Thursday, 28 June, 12
- 36. Requirements problems R R R r r T T T T T D D Thursday, 28 June, 12
- 37. Requirements problems R R R r r T T T T T D D Thursday, 28 June, 12
- 38. Requirements problems R R R r r T T T T T D D Thursday, 28 June, 12
- 39. Requirements problems R R R Requirements r r Knowledge Base T T T T T D D Thursday, 28 June, 12
- 40. Paraconsistency Payment Card regs. Thursday, 28 June, 12
- 41. Formalizing paraconsistency • For the statement ‘requirement A conflicts with requirement B’ write A∧B→⊥ • Inconsistent when bottom (⊥) can be derived • Often more ‘complete’ requirements are less consistent. Thursday, 28 June, 12
- 42. Why paraconsistency? taken from Nuseibeh et al. 2001 Thursday, 28 June, 12
- 43. Why paraconsistency? • to facilitate distributed collaborative working (viewpoints), taken from Nuseibeh et al. 2001 Thursday, 28 June, 12
- 44. Why paraconsistency? • to facilitate distributed collaborative working (viewpoints), • to ensure all stakeholder views are taken into account, taken from Nuseibeh et al. 2001 Thursday, 28 June, 12
- 45. Why paraconsistency? • to facilitate distributed collaborative working (viewpoints), • to ensure all stakeholder views are taken into account, • to focus attention on problem areas [of the specification], taken from Nuseibeh et al. 2001 Thursday, 28 June, 12
- 46. Why paraconsistency? • to facilitate distributed collaborative working (viewpoints), • to ensure all stakeholder views are taken into account, • to focus attention on problem areas [of the specification], • to prevent premature commitment to design decisions. taken from Nuseibeh et al. 2001 Thursday, 28 June, 12
- 47. Why paraconsistency? • to facilitate distributed collaborative working (viewpoints), • to ensure all stakeholder views are taken into account, • to focus attention on problem areas [of the specification], • to prevent premature commitment to design decisions. taken from Nuseibeh et al. 2001 Thursday, 28 June, 12
- 48. Criteria for paraconsistent satisfaction • Domain assumptions and refinements are consistent. • Desired goals are internally consistent. • Selected tasks are internally consistent. Thursday, 28 June, 12
- 49. R R R r r T T T T T D D Thursday, 28 June, 12
- 50. R R R r r T T T T T D D Thursday, 28 June, 12
- 51. R R R r r T T T T T D D Thursday, 28 June, 12
- 52. R R R r r T T T T T D D Thursday, 28 June, 12
- 53. R R R r r T T T T T D D Thursday, 28 June, 12
- 54. What to do? Thursday, 28 June, 12
- 55. What to do? 1. Given goals, what minimal sets of tasks satisfy them? (minimal goal achievement) Thursday, 28 June, 12
- 56. What to do? 1. Given goals, what minimal sets of tasks satisfy them? (minimal goal achievement) 2. Given goals, and minimal task sets, what can we add to expand our consistent solution? (get candidate solutions) Thursday, 28 June, 12
- 57. What to do? 1. Given goals, what minimal sets of tasks satisfy them? (minimal goal achievement) 2. Given goals, and minimal task sets, what can we add to expand our consistent solution? (get candidate solutions) 3. Other operations: bottom-up reasoning, costs, etc. Thursday, 28 June, 12
- 58. Minimal Goal Achievement Assign unique ID Use existing h/w Compensating 8.1 prevent control multiple logins Use AS/400 Use SUDO Use Log servers centralized Access ID Thursday, 28 June, 12
- 59. Minimal Goal Achievement Assign unique ID Use existing h/w Compensating 8.1 prevent control multiple logins Use AS/400 Use SUDO Use Log servers centralized Access ID Thursday, 28 June, 12
- 60. Minimal Goal Achievement Assign unique ID Use existing h/w Compensating 8.1 prevent control multiple logins Use AS/400 Use SUDO Use Log servers centralized Access ID Thursday, 28 June, 12
- 61. Assign unique ID Use existing h/w Compensating 8.1 prevent control multiple logins Use AS/400 Use SUDO Use Log servers centralized Access ID Thursday, 28 June, 12
- 62. Get Candidate Solutions Assign unique ID Use existing h/w Compensating 8.1 prevent control multiple logins Use AS/400 Use SUDO Use Log servers centralized Access ID Thursday, 28 June, 12
- 63. Get Candidate Solutions Assign unique ID Use existing h/w Compensating 8.1 prevent control multiple logins Use AS/400 Use SUDO Use Log servers centralized Access ID Thursday, 28 June, 12
- 64. Evaluation and implementation • Implemented reasoner using graphical modeling tool and assumption-based truth maintenance. • Tested tool on 340 requirement Payment Card case study. • Find all solutions in ~600s. • Outperforms (outdated) MinWeightSat reasoner. Thursday, 28 June, 12
- 65. RE-KOMBINE Visual editor Reasoner Domain specific lang. Thursday, 28 June, 12
- 66. Req. Mgmt. Visual editor Tool Reasoner DSL editor Thursday, 28 June, 12
- 67. Summary Problem: support agile requirements while still enabling systematically modelling and analysis. Solution: paraconsistent models with reasoning backend. Code and data available at http://github.com/ neilernst/Techne-TMS Neil Ernst: @neilernst • neilernst.net Thursday, 28 June, 12