CaRE A Re f inement Ca lculus for R equirements E ngineering based - PowerPoint PPT Presentation

CaRE A Re f inement Ca lculus for R equirements E ngineering based on Argumentation Theory Y. Elr a k a iby*, A. Borgid a , A. Ferr a ri, J. Mylopoulos Y. Elr a k a iby D a te

Lifecycle of Software Projects…! Unfortunately … How the project manager How the project manager How the project manager How the developer How the developer How the developer How the project was How the project was How the project was What the customer needed What the customer needed What the customer needed How they explained it How they explained it How they explained it How the analyst designs it understood it understood it understood it developed it developed it developed it documented documented documented

Solution Requirements Engineer! Requirements Engineer How the developer How the project was How the project was How the project was What the customer needed developed it documented documented documented

Requirements Engineering “Requirements engineering (RE) [1] is the process of de fi ning, documenting, and maintaining requirements [2].” Developers Stakeholders … Requirements Engineer Customer … Developer 1 Project Manager Developer 2 (1) Nuseibeh, B.; Easterbrook, S. (2000). Requirements engineering: a roadmap (PDF). ICSE'00. Proceedings of the conference on the future of Software engineering. pp. 35–46. (2) Kotonya, Gerald; Sommerville, Ian (September 1998). Requirements Engineering: Processes and Techniques. John Wiley & Sons. ISBN 978-0-471-97208-2.

Our Focus The Re f inement Process Stakeholders into a specification •consistent Abstract •complete •valid Transforming Initial requirements elicited from •unambiguous stakeholders •conflicting •unattainable SRS Concrete •incomplete •ambiguous Developers “A so fu ware requirements speci fi cation (SRS) is a document that captures complete description about how the system is expected to perform.”

Other Challenges Support of… • Negotiation and agreement between stakeholders • Documentation • Keep track of rationale of design choices, defects identi fi ed in requirements and re fi nements proposed to address identi fi ed defects • Change Management

Requirements Engineering in the Literature Requirements Speci f ic a tion Methodologies • Generally revolves around re fi nement, which have taken many forms: • activity decomposition (Ross), • abductive inference (Jackson), • goal re fi nement (vanLamsweerde) , • social delegation (Yu). • Requirements Speci fi cation Languages • Out of scope

Goal Decomposition in GORE Ex a mple: KAOS Go a l Decomposition (Simpli f ied) • And/Or Goal Decomposition • Leaves are • Tasks (implementation activities) • Domain Assumptions/Properties • Formal Semantics • First-order Temporal Logic [1] (1) https://opnfv-availability.readthedocs.io/en/latest/development/overview/HA_Analysis-Gambia.html (2) https://www.cse.msu.edu/~cse870/Materials/GoalModeling/KaosTutorial-2007.pdf. (3) http://www.objectiver.com/ fi leadmin/download/documents/generallea fl et.pdf.

Goal Decomposition in GORE Ex a mple: KAOS Go a l Decomposition (Simpli f ied) • And/Or Goal Decomposition • Leaves are Why? • Tasks (implementation activities) • Domain Assumptions/Properties How? • Formal Semantics • First-order Temporal Logic (1) https://www.cse.msu.edu/~cse870/Materials/GoalModeling/KaosTutorial-2007.pdf. (2) http://www.objectiver.com/ fi leadmin/download/documents/generallea fl et.pdf.

CaRE A C a lculus for Requirements Engineering • Defects are fi rst-class entities • Keep track of identi fi ed defects, hence document the rational behind re fi nements and evolution of the re fi nement process • Re fi nements to address each defect type • Formalised using Argumentation Theory • Support convergence and agreement between stakeholders • Reasoning support • Tool support

CaRE The Met a model Refinement Graph 1..* 1..* 1 Requirement 1..* Defect [1] Boolean: isInitial [1] Boolean: /isFinal 2..* faults Single Target Defect Multi Target Defect faults mConflict mMissing mRedundant rejected nonAtomic ambiguous unattainable unjustified incomplete tooStrong tooWeak 1 1 1 0..1 0..1 1 1 0..1 1 0..1 addresses addresses addresses addresses addresses addresses addresses addresses reduce weaken justify clarify strenghten resolve add drop Refinement 1..* introduces

CaRE The Gr a phic a l Not a tion 1 Requirement REQ-id: REQ-text g10: the app shall run on all tablets of the factory, which are Android tablets Requirement Set justify(r10) {REQ-1, ..., REQ-m} unjustified(d00) 0 0 g01: the app shall be Single Target g00: the app shall run on delivered within DType(DEF-id:[<"claim">]) Android Defect 6 months mConflict(d01: "cannot deliver Android app in 6 months") Multi-target DType(DEF-id:[<"claim">]) Defect resolve(r20) RType(REF-id) 2 2 Single Refinement g24: the app shall be g23: the app shall delivered within run on Android resolve(r21) 12 months RType(REF-id) Multiple Refinement g22: all tablets of the g20: the app shall run on factory shall be replaced iOS RType-1(REF-id-1) with iPads Alternative Refinement g21: the app shall be delivered within 6 months RType-2(REF-id-2)

CaRE The Sem a ntics • Formal semantics in terms of ASPIC + Argumentation Theory • Reasoning about arguments and con fl icts between them • Computation of extensions •A set of arguments •Conflict relations •Sets of arguments which may be collectively accepted

CaRE Tool Support: Ex a mple 1 1 1 1 g11: maximise line g12: reduce deployment g13: Reduce maintenance g10: avoid train collisions capacity costs costs justify(r10) justify(r11) justify(r12) unjustified(d00) unjustified(d01) unjustified(d02) 0 0 0 g00: the system shall g02: the train location g01: the distance between ensure safety distance shall be identified through trains shall be minimal between trains satellite navigation nonAtomic(d03) ambiguous(d04: "the term 'minimal' shall be better defined") unattainable(d05: "in case of galleries, satellite navigation cannot be used") weaken(r60) 6 g60: in case of a gallery the location of the train is clarify(r50) assumed to be the last reduce(r20) location identified by the satellite system 2 2 g20: the system shall be g22: the onboard system shall tooWeak(d60: "more than 2 composed of a wayside ensure that the train is 5 one train shall be allowed 5 5 g21: the wayside system shall system and an onboard g50: the distance between g51: the braking distance is stopped at the end of the MA in a gallery") indicate to the onboard g52: the distance between system trains is the distance between the distance that the train system the distance that the trains is minimal if it is equal the front of a train and the rear needs to travel to come to a train can safely travel to the braking distance of the preceding train stop from its current speed (Movement Authority, MA) strengthen(r70) strengthen(r71) nonAtomic(d21) nonAtomic(d20) 7 7 g70: the onboard system g71: the onboard system reduce(r30) reduce(r31) shall use fixed balises to shall use visual tags to identify identify its location in case of its location in case of galleries 3 3 3 galleries 3 g30: the wayside system g31: the wayside system g33: the onboard system shall rejected(d70: "visual tags g32: the onboard system shall identify the location of shall compute the MA for compute the breaking curve to may not be reliable") shall identify its location ensure that the train is each train on the track each train on the track stopped at the end of the MA nonAtomic(d30) incomplete(d31: "the agent who stops the train is not specified") 8 clarify(r80) reduce(r40) {g00,...,g82} 8 8 4 g82: if the train speed 4 8 g40: the onboard system shall g41: the wayside system exceeds the maximum speed g80: the onboard system shall mMissing(d80: "requirements send the location of the train shall receive the location of allowed by the braking curve, notify to the driver the g81: the driver shall drive the about the DMI are missing") to the wayside system the onboard system shall each train on the track maximum speed allowed by train without exceeding the brake the train the braking curve maximum speed allowed by the breaking curve add(r90) 9 9 9 g90: the onboard system shall include a Driver Machine g91: the DMI background g92: the DMI text shall be Interface (DMI) to notify shall be light blue white information to the driver mConflict(d90: "the contrast is too low") resolve(r101) resolve(r100) 10 10 10 10 g102: the DMI background g103: the DMI text shall be g100: the DMI background g101: the DMI text shall be shall be blue yellow shall be black white

CaRE Tool Support • Implemented in Java • Runs through the command line using a textual description of re fi nement graphs • Reasoning tasks • Determine acceptability of the initial requirements and re fi nements • Compute minimal speci fi cations • Minimal set of leaf requirements that make the initial requirements acceptable

Conclusion Fin a l Thoughts… GORE CaRE Mainly AND/OR decomposition (Nonatomic Documentation More defects and re f inements defect) Change Management Complex Simple (monotonic) Yes Yes Formal Semantics Yes Yes Reasoning support Tool Support UI Basic Support of f inding agreement No Yes between Stakeholders