Supporting Agile Requirements Evolution via Paraconsistent Reasoning
Upcoming SlideShare
Loading in...5
×
 

Supporting Agile Requirements Evolution via Paraconsistent Reasoning

on

  • 1,234 views

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

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.

Statistics

Views

Total Views
1,234
Views on SlideShare
1,234
Embed Views
0

Actions

Likes
1
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Supporting Agile Requirements Evolution via Paraconsistent Reasoning Supporting Agile Requirements Evolution via Paraconsistent Reasoning Presentation Transcript

  • 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
  • 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
  • Takeaway We need agile requirements models — that can still be systematically analysed.Thursday, 28 June, 12
  • Takeaway We need agile requirements models — that can still be systematically analysed. • MotivationThursday, 28 June, 12
  • 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
  • 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
  • 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
  • Agility ... Test Devel. Ops Req timeThursday, 28 June, 12
  • Agility ... Test Devel. Ops Req timeThursday, 28 June, 12
  • Agility ... Test Devel. Ops Req timeThursday, 28 June, 12
  • Agility ... Test Devel. Ops Req timeThursday, 28 June, 12
  • Agility ... Test Devel. Ops Req timeThursday, 28 June, 12
  • Requirements agility is constrainedThursday, 28 June, 12
  • Requirements agility is constrained Let’s add remote loginThursday, 28 June, 12
  • Requirements agility is constrained Let’s add remote login Security holeThursday, 28 June, 12
  • Requirements agility is constrained Let’s add remote login Security hole How about removing RSA?Thursday, 28 June, 12
  • Requirements agility is constrained Let’s add remote login Security hole How about removing Not back-compatible RSA?Thursday, 28 June, 12
  • 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
  • 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
  • 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
  • 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
  • Requirements agility means successThursday, 28 June, 12
  • Requirements agility means successThursday, 28 June, 12
  • “[the code] remained operational in Ariane 5 without satisfying any (traceable) requirement.”Thursday, 28 June, 12
  • Thursday, 28 June, 12
  • 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
  • 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
  • Requirements problemsThursday, 28 June, 12
  • Requirements problems R R RThursday, 28 June, 12
  • Requirements problems R R R r rThursday, 28 June, 12
  • Requirements problems R R R r r T T T T TThursday, 28 June, 12
  • Requirements problems R R R r r T T T T TThursday, 28 June, 12
  • Requirements problems R R R r r T T T T T D DThursday, 28 June, 12
  • Requirements problems R R R r r T T T T T D DThursday, 28 June, 12
  • Requirements problems R R R r r T T T T T D DThursday, 28 June, 12
  • Requirements problems R R R r r T T T T T D DThursday, 28 June, 12
  • Requirements problems R R R r r T T T T T D DThursday, 28 June, 12
  • Requirements problems R R R r r T T T T T D DThursday, 28 June, 12
  • Requirements problems R R R Requirements r r Knowledge Base T T T T T D DThursday, 28 June, 12
  • Paraconsistency Payment Card regs.Thursday, 28 June, 12
  • 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
  • Why paraconsistency? taken from Nuseibeh et al. 2001Thursday, 28 June, 12
  • Why paraconsistency? • to facilitate distributed collaborative working (viewpoints), taken from Nuseibeh et al. 2001Thursday, 28 June, 12
  • 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
  • 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
  • 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
  • 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
  • Criteria for paraconsistent satisfaction • Domain assumptions and refinements are consistent. • Desired goals are internally consistent. • Selected tasks are internally consistent.Thursday, 28 June, 12
  • R R R r r T T T T T D DThursday, 28 June, 12
  • R R R r r T T T T T D DThursday, 28 June, 12
  • R R R r r T T T T T D DThursday, 28 June, 12
  • R R R r r T T T T T D DThursday, 28 June, 12
  • R R R r r T T T T T D DThursday, 28 June, 12
  • What to do?Thursday, 28 June, 12
  • What to do? 1. Given goals, what minimal sets of tasks satisfy them? (minimal goal achievement)Thursday, 28 June, 12
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • RE-KOMBINE Visual editor Reasoner Domain specific lang.Thursday, 28 June, 12
  • Req. Mgmt. Visual editor Tool Reasoner DSL editorThursday, 28 June, 12
  • 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