Deriving Operational Software
Specification from System Goals
Xin Bai
EEL 5881 Course
Fall, 2003
Reference Paper

“Deriving Operational Software
Specification from System Goals”

November 2002, Proceedings of the tenth ACM
SIGSOFT symposium on Foundations of software
engineering
Content





Introduction
Goal-Oriented Elaboration of
Requirements
Semantics of Operationalization
Operationalization Patterns
Analysis
Introduction

Lots of techniques and tools for specification
analysis


Algorithmic model checking, Deductive verification
etc.
Building formal specifications for complex
software is not easy


Translate natural language statements to some
formal language
To be elaborated, structured, interrelated and
negotiated
Introduction

Goal-oriented requirements engineering

The use of goals for requirements
elicitation, elaboration, organization,
specification, analysis, negotiation,
assignment, documentation and evolution.
Introduction

Goals

Objectives the system under consideration
must achieve


E.g. “safe transportation” and “reverse thrust
enabled when wheels pulse on”
Achieving goals require the cooperation of
multiple agents (humans, devices or
software)
Introduction

Goal refinement


To decompose a goal into subgoals so that
each subgoal requires the cooperation of
fewer agents
Stops when goals can be assigned as
responsibility of single agents
Goal-oriented elaboration of
requirements

An application model is composed of
four submodels:




Goal model
Object model
Agent model
Operation model
The goal model

The various objectives the system
should meet are defined in this model
The goal model

Temporal operators
The goal model
The goal model

A sample
The object model


Defines the domain entities,
relationships and attributes
A sample
The agent model


Defines the responsibilities and
interfaces of the various agents
A sample
The operation model


Defines the various services to be provided by
agents
Domain pre/post conditions


Capture the elementary state transitions defined
by operation applications in the domain
Required pre/post/trigger conditions

Capture additional strengthenings to ensure that
the goals are met
The operation model

A required preconditions


A required trigger condition


Captures a permission to perform the operation
when the condition is true
Captures an obligation to perform the operation
when the condition becomes true provided the
domain precondition is true
A required postcondition

Captures an additional condition that must hold
after any application of the operation
The operation model

Difference between domain and
required conditions

Domain conditions describe what an
application of the operation means in the
domain without any prescription as to
when the operation must be applied and
when it may not be applied.
The operation model

A sample for domain conditions
The operation model

A sample for required conditions
Semantics of
operationalization


Functional goals need to be
operationalized into specifications of
services the agents should provide to
meet them
Operationalization is a process that
maps declarative property specifications
to operational specifications satisfying
them
Semantics of
operationalization

It takes the form of a set of operations
specified by domain and required pre,
post- and trigger conditions.
Semantics of
operationalization

Correctness of goal operationalization



Completeness
Consistency
minimality
Operationalization patterns

A pattern-based technique for
operationalizing goals, specified in realtime linear temporal logic (RT-LTL), into
operations specified by pre-, post- and
trigger conditions
Operationalization patterns

An operationalization pattern is an
abstract AND-operationalization link
between a goal specification pattern in
RT-LTL and a set of required pre-,
trigger and postcondition specification
patterns that operationalize the root
correctly.
Operationalization patterns

The Immediate Achieve pattern
Operationalization patterns

The Bounded Achieve pattern
Operationalization patterns

The “InBetween” Invariance pattern
A taxonomy of goal patterns
Operationalization patterns


In every but very rare cases, the goals
match one of the general patterns in
the previous taxonomy diagram
Not complete, could be enriched with
additional goal patterns
Analysis

Benefits




Abstraction from formal details
Completeness assurance
Guidance in writing operational
specifications
Goal mining from operational specifications
Thank you!