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