Supporting Agile Requirements Evolution via Paraconsistent Reasoning

1,449 views

Published on

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.

Published in: Technology, Lifestyle
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,449
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Supporting Agile Requirements Evolution via Paraconsistent Reasoning

  1. 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. 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. 3. Takeaway We need agile requirements models — that can still be systematically analysed.Thursday, 28 June, 12
  4. 4. Takeaway We need agile requirements models — that can still be systematically analysed. • MotivationThursday, 28 June, 12
  5. 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. 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. 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. 8. Agility ... Test Devel. Ops Req timeThursday, 28 June, 12
  9. 9. Agility ... Test Devel. Ops Req timeThursday, 28 June, 12
  10. 10. Agility ... Test Devel. Ops Req timeThursday, 28 June, 12
  11. 11. Agility ... Test Devel. Ops Req timeThursday, 28 June, 12
  12. 12. Agility ... Test Devel. Ops Req timeThursday, 28 June, 12
  13. 13. Requirements agility is constrainedThursday, 28 June, 12
  14. 14. Requirements agility is constrained Let’s add remote loginThursday, 28 June, 12
  15. 15. Requirements agility is constrained Let’s add remote login Security holeThursday, 28 June, 12
  16. 16. Requirements agility is constrained Let’s add remote login Security hole How about removing RSA?Thursday, 28 June, 12
  17. 17. Requirements agility is constrained Let’s add remote login Security hole How about removing Not back-compatible RSA?Thursday, 28 June, 12
  18. 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. 19. Requirements agility is constrained Let’s add remote login Security hole How about removing Not back-compatible RSA? Simplify account mgmt? Violates Sarbanes-OxleyThursday, 28 June, 12
  20. 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. 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 COOThursday, 28 June, 12
  22. 22. Requirements agility means successThursday, 28 June, 12
  23. 23. Requirements agility means successThursday, 28 June, 12
  24. 24. “[the code] remained operational in Ariane 5 without satisfying any (traceable) requirement.”Thursday, 28 June, 12
  25. 25. Thursday, 28 June, 12
  26. 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 MThursday, 28 June, 12
  27. 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.0Thursday, 28 June, 12
  28. 28. Requirements problemsThursday, 28 June, 12
  29. 29. Requirements problems R R RThursday, 28 June, 12
  30. 30. Requirements problems R R R r rThursday, 28 June, 12
  31. 31. Requirements problems R R R r r T T T T TThursday, 28 June, 12
  32. 32. Requirements problems R R R r r T T T T TThursday, 28 June, 12
  33. 33. Requirements problems R R R r r T T T T T D DThursday, 28 June, 12
  34. 34. Requirements problems R R R r r T T T T T D DThursday, 28 June, 12
  35. 35. Requirements problems R R R r r T T T T T D DThursday, 28 June, 12
  36. 36. Requirements problems R R R r r T T T T T D DThursday, 28 June, 12
  37. 37. Requirements problems R R R r r T T T T T D DThursday, 28 June, 12
  38. 38. Requirements problems R R R r r T T T T T D DThursday, 28 June, 12
  39. 39. Requirements problems R R R Requirements r r Knowledge Base T T T T T D DThursday, 28 June, 12
  40. 40. Paraconsistency Payment Card regs.Thursday, 28 June, 12
  41. 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. 42. Why paraconsistency? taken from Nuseibeh et al. 2001Thursday, 28 June, 12
  43. 43. Why paraconsistency? • to facilitate distributed collaborative working (viewpoints), taken from Nuseibeh et al. 2001Thursday, 28 June, 12
  44. 44. Why paraconsistency? • to facilitate distributed collaborative working (viewpoints), • to ensure all stakeholder views are taken into account, taken from Nuseibeh et al. 2001Thursday, 28 June, 12
  45. 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. 2001Thursday, 28 June, 12
  46. 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. 2001Thursday, 28 June, 12
  47. 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. 2001Thursday, 28 June, 12
  48. 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. 49. R R R r r T T T T T D DThursday, 28 June, 12
  50. 50. R R R r r T T T T T D DThursday, 28 June, 12
  51. 51. R R R r r T T T T T D DThursday, 28 June, 12
  52. 52. R R R r r T T T T T D DThursday, 28 June, 12
  53. 53. R R R r r T T T T T D DThursday, 28 June, 12
  54. 54. What to do?Thursday, 28 June, 12
  55. 55. What to do? 1. Given goals, what minimal sets of tasks satisfy them? (minimal goal achievement)Thursday, 28 June, 12
  56. 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. 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. 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 IDThursday, 28 June, 12
  59. 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 IDThursday, 28 June, 12
  60. 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 IDThursday, 28 June, 12
  61. 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 IDThursday, 28 June, 12
  62. 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 IDThursday, 28 June, 12
  63. 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 IDThursday, 28 June, 12
  64. 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. 65. RE-KOMBINE Visual editor Reasoner Domain specific lang.Thursday, 28 June, 12
  66. 66. Req. Mgmt. Visual editor Tool Reasoner DSL editorThursday, 28 June, 12
  67. 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.netThursday, 28 June, 12

×