Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
Y. Elrakaiby Date
CaRE A Refinement Calculus for Requirements Engineering
based on Argumentation Theory
Y. Elrakaiby*, A. Borgida, A. Ferrari, J. Mylopoulos
Lifecycle of Software Projects…! Unfortunately…
What the customer neededWhat the customer neededWhat the customer needed How they explained itHow they explained itHow they explained it How the analyst designs it How the developer developed it
How the developer developed it
How the developer developed it
How the project was documented
How the project was documented
How the project was documented
How the project manager understood it
How the project manager understood it
How the project manager understood it
SolutionRequirements Engineer!
What the customer needed How the developer developed it
How the project was documented
How the project was documented
How the project was documented
Requirements Engineer
“Requirements engineering (RE)[1] is the process of defining, documenting, and maintaining requirements[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.
Customer
Project Manager
… Requirements Engineer
Stakeholders Developers
Developer 1
Developer 2
…
Requirements Engineering
Our FocusThe Refinement Process
Transforming Initial requirements elicited from stakeholders
•conflicting •unattainable •incomplete •ambiguous
Stakeholders
Abstract
into a specification •consistent •complete •valid •unambiguous
Developers
SRS
“A software requirements specification (SRS) is a document that captures complete description about how the system is expected to perform.”
Concrete
Other Challenges
• Negotiation and agreement between stakeholders
• Documentation
• Keep track of rationale of design choices, defects identified in requirements and refinements proposed to address identified defects
• Change Management
Support of…
Requirements Engineering in the Literature
• Generally revolves around refinement, which have taken many forms:
• activity decomposition (Ross),
• abductive inference (Jackson),
• goal refinement (vanLamsweerde),
• social delegation (Yu).
Requirements Specification Methodologies
• Requirements Specification Languages
• Out of scope
Goal Decomposition in GOREExample: KAOS Goal Decomposition (Simplified)
• And/Or Goal Decomposition
• Leaves are
• Tasks (implementation activities)
• Domain Assumptions/Properties
• Formal Semantics
• First-order Temporal Logic
(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/fileadmin/download/documents/generalleaflet.pdf.
[1]
Goal Decomposition in GOREExample: KAOS Goal Decomposition (Simplified)
• And/Or Goal Decomposition
• Leaves are
• Tasks (implementation activities)
• Domain Assumptions/Properties
• Formal Semantics
• First-order Temporal Logic
(1) https://www.cse.msu.edu/~cse870/Materials/GoalModeling/KaosTutorial-2007.pdf. (2) http://www.objectiver.com/fileadmin/download/documents/generalleaflet.pdf.
Why?
How?
CaRE
• Defects are first-class entities
• Keep track of identified defects, hence document the rational behind refinements and evolution of the refinement process
• Refinements to address each defect type
• Formalised using Argumentation Theory
• Support convergence and agreement between stakeholders
• Reasoning support
• Tool support
A Calculus for Requirements Engineering
CaRE
Refinement Graph
Defect
Refinement
nonAtomic
ambiguous
unattainable
unjustified
incomplete
tooStrong
tooWeak
rejected
Single Target Defect
Multi Target Defect
mConflict
mMissing
mRedundant
strenghten
reduce
add
clarify
justify
resolve
drop
weaken
addresses addressesaddresses addresses addresses addresses addresses addresses
[1] Boolean: isInitial [1] Boolean: /isFinal
Requirement11..*
1..*
2..*
faults
faults
introduces
1..*
11110..110..10..11 0..1
1..*
The Metamodel
CaREThe Graphical Notation
REQ-id: REQ-text
Single TargetDefect
Requirement
Single Refinement
Multi-targetDefect
{REQ-1, ..., REQ-m} Requirement Set
Multiple Refinement
DType(DEF-id:[<"claim">])
RType(REF-id)
DType(DEF-id:[<"claim">])
Alternative Refinement
RType-1(REF-id-1)
RType(REF-id)
RType-2(REF-id-2)
g00: the app shall run on Android
g01: the app shall be delivered within
6 months
0 0
mConflict(d01: "cannot deliver Android app in 6 months")
g23: the app shall run on Android
g24: the app shall be delivered within
12 months
resolve(r20)
2 2
g20: the app shall run on iOS
g21: the app shall be delivered within 6 months
resolve(r21)
g22: all tablets of the factory shall be replaced
with iPads
unjustified(d00)
g10: the app shall run on all tablets of the factory,
which are Android tablets
1
justify(r10)
CaREThe Semantics
• Formal semantics in terms of ASPIC+ Argumentation Theory
• Reasoning about arguments and conflicts between them
• Computation of extensions
•A set of arguments •Conflict relations
•Sets of arguments which may be collectively accepted
CaRETool Support: Example
g00: the system shall ensure safety distance
between trainsg01: the distance between
trains shall be minimalg02: the train location
shall be identified through satellite navigation
unjustified(d00) unjustified(d01) unjustified(d02)
g10: avoid train collisions g11: maximise line capacity
g12: reduce deployment costs
g13: Reduce maintenance costs
justify(r10) justify(r11) justify(r12)
g20: the system shall be composed of a wayside system and an onboard
systemg21: the wayside system shall
indicate to the onboard system the distance that the
train can safely travel (Movement Authority, MA)
g22: the onboard system shall ensure that the train is
stopped at the end of the MA
nonAtomic(d03)
reduce(r20)
g30: the wayside system shall identify the location of
each train on the track
g31: the wayside system shall compute the MA for
each train on the track
nonAtomic(d20)
g32: the onboard system shall identify its location
g33: the onboard system shall compute the breaking curve to
ensure that the train is stopped at the end of the MA
nonAtomic(d21)
reduce(r30) reduce(r31)
nonAtomic(d30)
reduce(r40)
g40: the onboard system shall send the location of the train
to the wayside system
g41: the wayside system shall receive the location of
each train on the track
ambiguous(d04: "the term 'minimal' shall be better defined")
g50: the distance between trains is the distance between the front of a train and the rear
of the preceding train
g51: the braking distance is the distance that the train
needs to travel to come to a stop from its current speed
g52: the distance between trains is minimal if it is equal
to the braking distance
clarify(r50)
unattainable(d05: "in case of galleries,satellite navigation cannot be used")
g60: in case of a gallery the location of the train is
assumed to be the last location identified by the
satellite system
weaken(r60)
tooWeak(d60: "more than one train shall be allowedin a gallery")
g70: the onboard system shall use fixed balises to
identify its location in case of galleries
incomplete(d31: "the agent who stops the train is not specified")
g82: if the train speed exceeds the maximum speed allowed by the braking curve,
the onboard system shall brake the train
g80: the onboard system shall notify to the driver the
maximum speed allowed by the braking curve
clarify(r80)
g81: the driver shall drive the train without exceeding the maximum speed allowed by
the breaking curve
{g00,...,g82}
mMissing(d80: "requirements about the DMI are missing")
g90: the onboard system shall include a Driver Machine Interface (DMI) to notify information to the driver
g91: the DMI background shall be light blue
g92: the DMI text shall be white
add(r90)
mConflict(d90: "the contrast is too low")
g100: the DMI background shall be black
g101: the DMI text shall be white
resolve(r100)
11 1 1
0 0 0
2
22
3 3 3 3
4 4
5 5 5
6
7
8
8
8
99 9
10 10
strengthen(r70)
8
g102: the DMI background shall be blue
g103: the DMI text shall be yellow
resolve(r101)
10 10
g71: the onboard system shall use visual tags to identify its location in case of galleries
strengthen(r71)7
rejected(d70: "visual tags may not be reliable")
CaRETool Support
• Implemented in Java
• Runs through the command line using a textual description of refinement graphs
• Reasoning tasks
• Determine acceptability of the initial requirements and refinements
• Compute minimal specifications
• Minimal set of leaf requirements that make the initial requirements acceptable
ConclusionFinal Thoughts…
GORE CaRE
Documentation Mainly AND/OR decomposition (Nonatomic defect) More defects and refinements
Change Management Complex Simple (monotonic)
Formal Semantics Yes Yes
Reasoning support Yes Yes
Tool Support UI Basic
Support of finding agreement between Stakeholders No Yes
Future Work
• Structured requirement specification language
• Formalisation of valid refinements
• Relationships between requirements
• Equivalence
• Implication
• Incompatibility
• UI for the tool
Perspectives