ORIGINAL ARTICLE

On the systematic transformation of requirementsto specifications

Zhi Li • Jon G. Hall • Lucia Rapanotti

Received: 26 April 2012 / Accepted: 8 May 2013

� Springer-Verlag London 2013

Abstract Formal approaches to development are widely

acknowledged to have difficulty in the validation of real-

world requirements; in contrast, non-formal approaches

find it difficult to identify the formal structures in

requirements that are useful in a solution. That the prob-

lems that computing treats are embedded in the real world

with solutions being an essentially formal machine means

this dichotomy will always exist, with some new approach

to the development needed which can draw a boundary

between what is formalised and what can be left informal.

In this paper, we show how the natural cause-and-effect

structures that can be found in non-formal requirements

descriptions can be used systematically to arrive at a

software specification. The theoretical contribution of the

work is the formalisation of Jackson’s idea of problem

progression in his Problem Frames framework through the

use of a graph grammar to capture problem models as

graphs and their manipulation as transformations. The

approach is illustrated through a substantial benchmark

example—Swartout’s and Balzer’s package router. We

also report on the results of an initial empirical evaluation

of the approach based on a prototype problem progression

tool we have constructed.

Keywords Requirements � Specifications � Problem

Frames � Problem progression � Graph transformation

1 Introduction

It is widely acknowledged (see, e.g., [1–3]) that poorly

defined system and user requirements and specifications

remain one of the outstanding problems in software

development and a key factor in the failure of many soft-

ware projects. Even when stakeholder needs are well

captured, understood or analysed, elucidating clear

requirements and building traceable paths from needs to

code is difficult, leading to a mismatch between what

stakeholders need and what the software developer

understands they need and that subsequently influences the

solution. The problem is particularly acute in complex

developments and large development teams typically found

in industry [4].

As far back as the 80s, Turski, [5], diagnosed the

problem as that of software engineering activities being

concerned with spanning non-formal and formal domains;

that is, software engineering takes, typically, a natural

language description of a stakeholder’s need and must map

it to a formal description in code. This difficulty of span-

ning non-formal and formal—termed the Turski Discon-

nect in [6]—has sometimes led to a dichotomy in

approaches to software development: some approaches

address only the formal concerns, usually in a single formal

language; others address only the non-formal concerns,

Z. Li (&)

College of Computer Science and Information Technology,

Guangxi Normal University, No. 15 Yu Cai Road, Guilin

541004, Guangxi, People’s Republic of China

e-mail: zhili@gxnu.edu.cn

Z. Li

Key Laboratory of High Confidence Software

Technologies (Peking University), Ministry of Education,

Beijing 100871, China

J. G. Hall � L. Rapanotti

Centre of Research in Computing, The Open University,

Walton Hall, Milton Keynes, Buckinghamshire MK7 6AA, UK

e-mail: J.G.Hall@open.ac.uk

L. Rapanotti

e-mail: L.Rapanotti@open.ac.uk

123

Requirements Eng

DOI 10.1007/s00766-013-0173-8

using several languages, which often cannot be reconciled.

Yet, an effective approach to development should deal

adequately with the non-formal, the formal, and the rela-

tionships between them. This work is concerned with

addressing this issue.

The Problem Frames approach to requirements and

specifications proposed by Jackson [7] shows some prom-

ise in dealing with this problem. In Problem Frames, a

requirement is regarded as a description of some desired

behaviour in the environment that a computing machine

must eventually bring about, while the software specifica-

tion is regarded as a behavioural description of the com-

puting machine in terms of its interface shared with the

environment.

The Problem Frames approach encourages a proper

understanding of the problem (the requirement in its con-

text) as a first essential step in providing an appropriate

solution (starting with a specification at the machine

boundary). Secondly, it underlines the distinction between

the problem and solution space allowing the clearer for-

mulation of the argument of the satisfaction of the

requirements by a machine that satisfies the specification.

Thirdly, it provides a notation (the problem diagram) to

represent precisely details of the problem space in relation

to the solution space, hence the means to reason about

requirements, contexts, specifications and their relation-

ships, while still allowing descriptions to be informal and

real-world grounded.

The work is an extension and generalisation of the PhD

work of [8] and other preliminary work published in [9].

1.1 Contribution of the research

The theoretical contribution of the work is the provision of

an operational semantics for Jackson’s idea of problem

progression as sketched in his Problem Frames framework

[7]. This is based on the definition of a graph grammar that

permits the expression and transformation of a software

requirement into its solution specification form in the

context of problem diagrams, a key technique in Problem

Frames.

The basis of the graph grammar is the identification of

causal relationships within (natural language/non-formal)

requirements as the vehicle for transformation of those

requirements to be ‘closer to the machine’. The formali-

sation of the transformations without needing a formali-

sation of the requirements is a step towards addressing the

Turski Disconnect, and our work can be seen as drawing a

boundary between what is formalised and what can be left

informal in Problem Frames approach.1

To illustrate our approach, we use a benchmark software

engineering example, the package router, proposed by

Hommel [10], which has been used extensively to illustrate

the Problem Frames approach [7]. This problem is suffi-

ciently complex and representative of real-world situations

to test our approach.

The techniques presented in this paper lay the founda-

tions of a practical approach that could, at one level,

improve traceability between requirements and specifica-

tions and, at a higher level, improve communication

between developer and non-developmental stakeholders. In

other work, we are actively developing a semi-automatic

tool based on our techniques that should allow real-world

problems to be tested. An early prototype was used as part

of the empirical evaluation reported in this paper.

1.2 Paper structure

The remainder of this paper is structured as follows: in

Sect. 2, we introduce some relevant aspects of Problem

Frames, problem progression, causal reasoning and graph

transformation used in this paper; in Sect. 3, we describe

and demonstrate a rule-based technique for implementing

problem progression; in Sect. 4, we illustrate our tech-

niques by applying them to the benchmark package router

problem; in Sect. 5, we report an empirical evaluation of

the techniques; in Sect. 6, we recall and compare our

approach with related work; with discussions and future

work in Sect. 7, we conclude the paper.

2 Background

In this section, we describe the aspects of Problem

Frames,2 of causality and of graph grammars on which our

technique is based.

2.1 Problems Frames

A systematic account of Problem Frames is beyond the

scope of this paper but can be found in [7].

In Problem Frames, a software development problem is

a requirement in a real-world context for which a software

solution is sought. Problem descriptions are captured and

expressed by problem diagrams—labelled graphs that

model the computing machine, the problem world in terms

of the domains that exist therein, the requirement and the

phenomena that relate them. Like many other approaches,

a software specification is regarded as a behavioural

1 We are indebted to Pamela Zave, who through her comments on an

earlier manuscript, helped us to clarify the nature of our contribution.

2 We use capitalisation, as here, to distinguish Problem Frames as a

framework from the tools provided by that framework, such as

problem diagrams and context diagrams.

Requirements Eng

123

description of the computing machine in terms of its

interface shared with the environment.

The core of Problem Frames is the problem diagram, a

graph of the scope and structure of a software problem.

Figure 1 shows a problem diagram for a simple Heating

Controller.

The problem diagram shows the domains involved—the

Heating Controller machine and the Heating devices—the

phenomena that exist to relate their behaviours—the con-

trols HC! both on and off phenomena which are observed

by, and serve to control the, Heating devices. The

remaining element is the dashed oval which holds the

requirement, Heating regime, which is the desired rela-

tionship between is_on and is_off.

The heating control problem might be expressed thus as:

A modern office building needs an automatic heating

control system during the cold winter months in a

year. The building has a fixed pattern of usage—the

building needs heating on every working day from

9:00 am till 5:00 pm, which are the regular working

hours in the offices. The problem is to build a simple

controller machine that will switch on the heating

devices (we assume the heating devices have a

mechanism to maintain the temperature) at 8:45 am

and switch them off at 4:45 pm every day.

Some basic elements of the problem diagram are

explained below:

– The problem domain Heating devices representing

those physical devices that are used to generate heat

which can be in either the is_on state or the is_off state;

– The computer machine domain named Heating con-

troller (its machine status indicated by the box

decoration) representing the solution to be specified;

– The shared phenomena annotating the link between

them: the annotation indicates that the HC controls (!)

the phenomena {on, off} that it shares with the Heating

devices;

– The domain description describes how the events on

and off will cause state changes in the Heating devices;

– The requirement Heating regime (the dashed oval)

constrains the Heating devices’ states is_on and is_off

to be on between 8:45 a.m. and 4:45 p.m. every day.

More generally, phenomena are ‘element[s] of what we

can observe in the world’ [7]. and consist of distinguish-

able, named individuals such as events, entities or values

and relations such as states, truths and roles, which are sets

of associations among individuals. There are two catego-

ries of phenomena:

– Causal phenomena which are directly caused or

controlled by some domain and can cause other

phenomena in turn;

– Symbolic phenomena are used to symbolise other

phenomena and relationships among them.

Domains are ‘set[s] of related phenomena that are use-

fully treated as a unit in problem analysis’ [7], often

mapping to a domain experts’ partitioning of the problem

world. Domains control certain phenomena which they

share with other observing domains. Domain properties

describe ‘the expected and assumed relationships among

the phenomena of a domain’ [7].

Domains can be classified based upon their phenomena:

a causal domain is one whose properties include predict-

able causal relationships among its phenomena, whereas a

biddable domain typically consists of people and lacks

positive predictable internal causality. Jackson notes the

important role of chains of causality between domains: this

motivates much of the analysis in the problem domain.

The requirement3 is ‘a condition on one or more

domains of the problem context that the machine must

bring about’ [7]. Requirements are optative in expressing

‘wishes’ for relationships between contextual phenomena.

Satisfaction of the requirement is determined by observing

whether changes wrought by the solution within the real

world match those ‘wishes’. A requirement reference is a

connection between a requirement and a domain, which

consists of references to phenomena of the domain.

A requirement constraint is a requirement reference that

constrains the domain to which it refers, then the machine

must ensure that the state or behaviour of the domain sat-

isfies the requirement. Phenomena can be either referred to

or constrained by a requirement: if constrained, a satisfying

solution will ensure that that constraint is satisfied.

It is with chains of causality between domains with

predictable causality and their relationships that this work

concerns itself. We discuss the other possibilities later in

the paper.

2.2 Problem progression

In [11], Jackson considers the various possibilities for

problem decomposition by which one software develop-

ment problem can be related to others. In passing, Jackson

suggests the possibility of a systematic reduction in a

software development problem to a ‘pure programming

problem’, i.e., a software development problem which

Fig. 1 Automatic heating control problem diagram

3 There is but a single requirement in a problem diagram; this can, of

course, be a conjunction of many subsidiary ‘requirements.’

Requirements Eng

123

must only relate machine ‘inputs’ to ‘outputs’—a so called

specification phenomena. This tantalising possibility is a

result of the careful structuring of a problem’s domain and

of the strict observance of the meaning of a requirement

therein. Jackson says:

You can think of any problem as being somewhere on

a progression towards the machine, like this: The top

problem is deepest into the world. Its requirement RA

refers to domain DA. By analysis of the requirement

RA and the domain DA, a requirement RB can be

found that refers only to domain DB and guarantees

satisfaction of RA. This is the requirement of the next

problem down. Eventually, at the bottom is a pure

programming problem whose requirement refers just

to the machine and completely ignores all problem

domains.4

In Fig. 2, the solution to each of the problems is the

machine M, i.e., each problem transformation is solution-

preserving. Once RM, the machine specification, is known,

it is a simple matter to find M. The problem, then, is to find

RM. To do this, note that RM is the re-expression of

requirement RD so that it mentions only those events that

are shared with M, which are causally related to those

mentioned by RD.

Jackson does not provide any detail on the nature of the

relationship between the various descriptions, nor the sit-

uations in which progression applies. In this paper, we:

– Characterise those problems for which Jackson’s idea

holds in general;

– Identify characteristics of domains that allow progres-

sion to be applied; and

– Provide an implementation of progression as sketched

by Jackson.

2.3 Causality and causal reasoning

Causality is shared among various branches of the social

and natural sciences, including philosophy, logic, physics,

and psychology [12]. In the systems engineering setting, it

has been observed [13] that causation is often a natural

concept for the customer of a system to express his

requirements of it.

Causal chains—in which one phenomenon causes

another and so on—relate effects distant from causes. In a

problem diagram, a requirement will typically refer to one

or more phenomena at the end of a causal chain that ends

with machine phenomena and constrain other phenomena

in a causal chain emanating from the machine. To satisfy

the requirement, then, the machine must concatenate those

causal chains through its behaviour so that the phenomena

constraint is realised from the phenomena reference.

We follow Moffett et al’s treatment of causality. In

particular:

Cause and effect We regard cause as a relation

between events, which induces

a relationship between their

occurrences. Notationally, we use

to indicate direct cause: for

events e and f ; e f indicates that

an occurrence of e is the immediate5

cause of an occurrence of f.

State changes Given a state st of a domain D, the

event corresponding to D’s

entering the state st is denoted

" st6

Simple causality An event is the (simple) cause of

another if an occurrence of the

former is followed by an

occurrence of the latter. The time

period between the former

occurrence and the latter

occurrence may be indeterminate;

moreover, the effect of an earlier

occurrence may occur before the

effect of a later one. If the time

period is not unbounded, then the

cause is said to be sufficient;

otherwise, it is necessary cause.

Throughout this paper, ‘cause’

will mean sufficient cause.

Fig. 2 Problem progression, as sketched by Jackson [7]

4 The figure was named ‘a progression of problems’ by Jackson, on

page 103 in [7].

5 As usual, we indicate the transitive closure of a relation through the? decoration.6 What Problem Frames refers to as state, [13] refers to as conditions.

Requirements Eng

123

Timed causality Given an interval I, an occurrence

of one event e is the timed cause

of another event f on the interval

I if an occurrence of f necessarily

occurs within that time interval

after e’s occurrence, written e I

f :

Timed causality is sufficient

causality with an explicit bound.

The notation for intervals is not

prescribed.

Conditional causality An occurrence of one event e is

the g-guarded cause of another

event f, written g : e f ; whenever

the occurrence of e at a time when

g does not hold does not lead to

an occurrence of f. There are

sufficient and necessary forms of

timed causes.

Within Problem Frames, a domain controls a causal

phenomenon if it has the ability to initiate an occurrence of

that phenomena. In this paper, we interpret this to mean

that there are other phenomena, also under the control of

the domain that is its cause, in one of the senses explained

above. Domains that share phenomena participate in its

occurrence; this allows a causal phenomena of one domain

to be considered as the cause of another in another domain

without compromise.

By exploiting the notions of control and causality

together, we may reason about causal chains of behaviour

in a problem diagram. Following and manipulating these

causal chains is the basis of our implementation of problem

progression.

3 Problem progression

Problem diagrams are graphs. Because of this, the problem

progression can be implemented in the language of graph

grammars [14] which we briefly recall.

A graph, G, is a four-tuple, (V, E, s, t), where V is a

(finite) set of vertices and E is a (finite) set of edges with

V \ E = [ [14]. Functions s; t : E! V define source and

target, respectively. A subgraph of a graph G is a graph

whose vertex and edge sets are subsets of those of

G (including the mapping functions s; t : E! V).

Given graphs G1, G2 with Gi = (Vi, Ei, si, ti) for

i = 1, 2, an injective graph morphism f : G1 ! G2;

f = (fV, fE) consists of two injections fV:V1 ? V2 and fE:E1

? E2 which preserve the source and target functions, that

is, fV � s1 = s2 � fE and fV � t1 = t2 � fE [14].7

3.1 Graph transformation

A (graph) production rule p ¼ ðL l K!r RÞ consists of

graphs L, K and R, called the left-hand side, the interface

and the right-hand side, respectively, and two injective

graph morphisms l:K ? L and r: K ? R [14].

The injective morphisms (the shaded solid arrows

labelled l and r in Fig. 3) identify interface K as the sub-

graph common to both L and R under the production rule.

The injective remainders are those structures which are

transformed.

Production rules are the basis for the definition of graph

transformation; as they may be less familiar than the other

machinery we use, we take a little space to explain their

operation. Suppose that we have a graph G and a produc-

tion rule p ¼ ðL l K!r RÞ. Transforming G under p means

doing the following:

– Identifying a subgraph of G which matches the

structure of L; in the figure, this is the injective graph

morphism m:L ? G, called the ‘match’; then

– Replacing the subgraph m(L) in G with a subgraph

whose structure is defined by m(R) through p, which

leads to a new graph H.

Such a transformation is represented by G¼)p;m

H.

Figure 3 illustrates a graph transformation between

G and H for the production rule p defined above. The

shaded straight arrows labelled l, r and m represent

injective graph morphisms,8 while the shaded bent arrow

Fig. 3 The graph transformation G¼)p;m

H based on production rule

p and injective match m

7 Here, � is functional composition.

8 For brevity, and as m is an injection, vertex names are left

unchanged.

Requirements Eng

123

indicates the complete graph transformation. We note

that the ‘site’ of a rule application is not determined by

the rule, but by the source graph; a rule may therefore

apply many times to any graph. We must, therefore, be

careful in stipulating where within the graph a rule

applies.

3.2 Problem diagrams as graphs

Given a problem diagram D, we define:

1. Three sets, Types = {Domain, Requirement}, the ver-

tex types, Names, the set of domain names, and

Descriptions, the set of descriptions in the problem

diagram:

2. There is one vertex for each domain (including the

machine domain) and one for the requirement: for

n C 1 domains, we have vertices

V ¼ fv1; . . .; vng [ fvnþ1g

Then, lV : V ! Types� Names � Descriptions; which

maps a vertex to its expected value;

3. There is one edge for each relationship between

phenomena, i.e., one edge for each set of shared

phenomena, one for each set of referenced or con-

strained phenomena and one edge for each causal

relationship that is part of a domain description. Let

this set be E. Edge direction is derived as s, t:E ?V such that:

(a) For controlling domain (or constraining require-

ment) v of an edge e, its source is s(e) = v;

(b) For observing domain (or referencing require-

ment) v of an edge e, its target is t(e) = v;

(c) A causal relationship within domain v that gives

rise to an edge e has both source and target that

domain t(e) = s(e) = v;

The edge labelling mapping lE : E! PPhenomena

maps an edge to the set of phenomena from which it

derives.

3.2.1 Example: the heating control problem

As a running example to illustrate problem progression as a

graph grammar, we look again at the heating control

example of Fig. 1. With two domains, a requirement, one

set of shared phenomena, one constrained set and one

internal causal relation, we have:9

With the labelled graph representation of a problem dia-

gram, we are in a position to define graph production rules

for their manipulation. Problem progression can then be

regarded as graph transformations.

3.3 Progression rule classes

In this section, we decompose problem progression into

three classes of ‘atomic’ transformation classes. Briefly:

Reducing through

Cause and Effect

by which the effects and causes are

swapped in the requirements as

appropriate to the causal relations

identified in domain descriptions.

This rule class allows us to reason

through the behaviours of a domain,

thus allowing the requirement

constraint or reference to be

restated based on causal chains

within domain descriptions.

Fig. 4 Heat control problem diagram in Fig. 1 represented as a

directed graph (graph labels are omitted for clarity)

9 For brevity we will, as in Fig. 4, write lV(v) as lv, lE(e) as le.

Requirements Eng

123

Changing Viewpoint by which differing ‘perspectives’ of

domains sharing an event are used,

i.e., switching from the perspective

of a domain controlling an event to

that of a domain observing that

event, or vice versa. This rule class

allows us to reason through the

shared phenomena among domains.

Removed Domain by which we remove domains that

have become disconnected from all

other domains through applications

of the other rules.

We formally describe these rule classes in the sequel.

3.4 Reducing through cause-and-effect

There are two subclasses of transformation in this class,

corresponding to whether we wish to replace an effect with

a cause, or a cause with an effect.

3.4.1 The effect-to-cause rule class

The basis for this rule class is that a causal relationship

exists within D, i.e., there are phenomena c and e such that

c e (more generally, ðgÞ : c e with g the guarding

Boolean condition). The reader will note that:

– As we work within the Problem Frame framework, that

c causes e means we may exclude the control of e by a

domain other than D; the resulting six of nine possible

combinations (c, e: controlled, internal, observed) are

illustrated in Table 1;

– Under this condition, the causal relationship between

c and e permits a requirement to be rewritten so that

statements to the effect that ‘… e occurs …’ are replaced

by their (guarded) cause ‘… c occurs (and g holds) …’

without altering satisfaction of the requirement. This

property, in consort with other properties of the other

rules we define, is the basis of problem progression in

that the same solution (M in Fig. 2) will satisfy both

original and rewritten requirements.

We also note that the rewriting of the requirement in this

way decreases by one the number of constraints on the

phenomena controlled by D.

We adopt the following rule naming convention: a rule

name has three parts: (i) a sub-rule acronym in capital

letters—here ETC; (ii) the case number of problem topol-

ogy to which the rule applies; and (iii) either the letter ‘c’

when the requirement phenomenon is constrained or the

letter ‘r’ when the requirement phenomenon is referenced.

Formally, to apply a rule to a problem diagram consid-

ered as a graph, we encode each rule within our graph

grammar; for instance, rule ETC(3)c is the graph production

rule shown in Fig. 5, where the application conditions are:

1. Types(v1) = Types(v2) = Domain, that is, the type of

v1 (i.e. D0) and v2 (i.e. D) is Domain;

2. Types(v3) = Types(v4) = Requirement, that is, the

type of v3 (i.e. R) and v4 (i.e. R0) is Requirement;

3. s(e1) = v1, t(e1) = v2, that is, domain v1 (i.e. D0)controls its shared phenomena e1 (i.e. {c}) with

domain v2 (i.e. D);

4. s(e2) = v3, t(e2) = v2, that is, requirement v3 (i.e.

R) constrains the phenomena e2 (i.e. {e}) of domain

v2 (i.e. D);

5. e2 � v2 ^ e2 � v3 ^ e2 6� v1; that is, the description of

v3 (i.e. R) includes occurrence(s) of event e, i.e., ‘…

Table 1 The ETC rule class:

all causal possibilitiesCase Description/explanation

(1) Both effect e and cause c are internal to D

(2) Effect e is internal to D; cause c is controlled by D (and observed elsewhere)

(3) Effect e is internal to D; cause c is observed by D (and controlled elsewhere)

(4) Effect e is controlled by D (and observed elsewhere); cause c is internal to D

(5) Both effect e and cause c are controlled by D (and shared elsewhere)

(6) Effect e is controlled by D (and observed elsewhere); cause c is observed by D (but

controlled elsewhere)

Requirements Eng

123

e occurs …’, which is an internal phenomenon of v2

(i.e. ‘e internal to D’);

6. s(e3) = v2, t(e3) = v2, and ðgÞ : c DT

e; that is, the

description of e3 (i.e. the dog-eared box in the upper-

left part of Fig. 5) must contain statements of causal-

ity, e.g., there should be a statement like ‘c causes

e when g’ as part of domain D’s properties;

7. DT � Limit ^ Limit 2 R; that is, the time elapsed

between the occurrence of the cause c and that of the

effect e is short enough to be ignored (there is one

complication: for some real-time systems, if problem

progression involves n successive applications of

effect-to-cause sub-rules, in which casePn

i¼1 DTi of

time is needed for the causal events to occur, thenPn

i¼1 DTi � Limit must hold).

After the rule application, the description of v4 is

derived from that of v3 by replacing ‘. . .e occurs. . .’ with

‘. . .c occurs when g holds:. . . ’.

– Statements in R on phenomena other than event e are

untouched by this rule and remain the same in the

derived requirement R0; thus, all the constraints on such

phenomena are the same in both R and R0 and are

satisfied under the same conditions;

– Because ðgÞ : c e; a statement of sufficient causality,

is part of the behaviour of D, occurrences of ‘…e occurs …’ are always the effect of ‘… c occurs when

g holds …’; thus, behaviours that satisfy R will also

satisfy R0, and vice versa;

– That the timing of the system is not compromised by

focusing on event c instead of e means that care has

already been taken in considering the time elapsed

between the occurrence of c and that of its effect e, so

that replacing R with R0 does not affect the order of

event occurrence in behaviours.

Example (cont’d) The Heating Control Problem Consider

again the heating control problem. From its description

(Sect. 3.2.1), we have that on " is on: Hence, ETC(3)c

can be used to replace the requirement reference on

is_on with a constraint on the machine controlled on.

In detail, if

mðD0Þ ¼ Heating controller mðcÞ ¼ on

mðDÞ ¼ Heating devices mðeÞ ¼ is on

mðRÞ ¼ Heating regime0;

then m matches the dog-eared box containing ‘e internal to

D, c causes e when g’ in the rule to the dog-eared box

containing ‘on " is on’ in the problem diagram. The

changes wrought by the graph transformation are as

follows:

– Heating regime becomes10 Heating regime’, with

description ‘the heating devices should receive an on

pulse command at 8:45 a.m. and be switched off at 4:45

p.m. every day’, as indicated by the pattern ‘… on

pulse command [c occurs when g holds]’.

We note that ‘receive an on pulse command at 8:45

a.m.’ is a constraint on machine phenomena: in effect, we

have ‘moved’ the requirement closer to the machine. The

transformed problem diagram is shown in the bottom right

corner of Fig. 6.

There is a second application of the rule possible, this

time with match n applied to the off phenomenon, shown as

the end point of Fig. 7 (in which Heating regime’ has been

renamed to Command Regime).

When applied in this way, i.e., to phenomena

observed by the environment and controlled by the

machine, the number of phenomena referred to by the

requirement decreases by one for each application of

this rule as the number of constrained phenomena

increases by one. In this way, causal chains may be

followed from those machine-controlled phenomena to

the environment.

Fig. 5 Rule ETC(3)c, derived from case (3) of Table 1, written in a

problem diagram-like notation (above) and as a graph transformation

(below)

Fig. 6 Applying effect-to-cause rule ETC(3)c to on " is on in the

heating control problem diagram …

10 With changes italicised.

Requirements Eng

123

3.4.2 The cause-to-effect (CTE) rule class

The cause-to-effect rule class is based on the same analysis

as the effect-to-cause rule class; indeed, Table 1 again

serves to enumerate the cases. For cause-to-effect, how-

ever, the requirement is rewritten so that any occurrence of

a cause, say event ‘… c occurs … ’, is replaced by an

occurrence of its guarded effect, say ‘e occurs and g held’.

In contrast to the effect-to-cause rule, the number of

phenomena referred to by the requirement increases by one

for each application of this rule as the number of con-

strained phenomena decreases by one. In this way, causal

chains may be followed from environment-controlled

domains to machine-observed phenomena.

3.4.3 The observe-to-control (OTC) rule class

This rule class focuses on two domains D and D0 and a

phenomenon that they share ev. It is based on the following

observation: a requirement R may be rewritten so that a

description of a shared event, say ev, is switched from the

viewpoint of its ‘observer’ domain, say D0, to that of its

‘controller’ domain, say D. In this way, we replace ‘… D0

observes ev …’ appearing in R with ‘… D observes ev …’

to make the new requirement R0.The are only two cases, corresponding to whether the

phenomenon ev is constrained or referred to, and both of

which give rise to the rule ‘shape’ that is shown in Fig. 8.

That the above rules preserve solution-hood of the

machine follow from the following observations:

– Statements in R on phenomena other than event ev are

untouched by this rule and remain the same in the

derived requirement; thus, all constraints on such

phenomena remain the same in both R and R0 and are

satisfied under the same conditions;

– Because ev is shared between D and D0, the occurrence

of ev that D0 observes is exactly the same as that

D controls; thus, behaviours satisfying R also satisfy

R0, and vice versa.

Like ETC, this rule can be used to ‘move’ the require-

ment towards the cause in a causal chain.

3.4.4 The control-to-observe (CTO) rule class

This rule class bears the same relationship to the OTC class

as CTE does to ETC. We omit its description for brevity,

other than to remark that, like CTE, this rule can be used to

’move’ the requirement towards the effect in a causal

chain.

3.4.5 The domain removal rule class

The goal of the transformations we have defined so far is to

move the focus of a requirement from a domain further

from the solution machine, such as the DA in Fig. 2, to a

domain, DB, closer to the machine. If our goal is reached,

then we should hope to find a domain that has become

‘isolated’ from the requirement in that its phenomena are

not referenced or constrained by it. If this is that case, we

should remove it from the problem diagram, thus effecting

the topology changing part of problem progression.

The remaining rule class we define, Domain Removal—

RD— implements this problem transformation. The RD

rule class focuses on two domains D and D0. Domain D is

attached to the requirement R, while D0 is the domain to be

removed (see Fig. 9). Again on whether the requirement

constrains or refers to the event they share or other events

that do not belong to D0, there are six possible cases, as

shown in Fig. 10:

– Event ev is constrained by the requirement R and

controlled by D; thus, this rule is called RD(1)c;

– Event ev is referenced to by the requirement R and

controlled by D; thus, this rule is called RD(1)r;

– Event ev is constrained by the requirement R and

controlled by D0; thus, this rule is called RD(2)c;

– Event ev is referenced to by the requirement R and

controlled by D0; thus, this rule is called RD(2)r.

– Event ev is constrained by the requirement R and does

not belong D0; thus, this rule is called RD(3)c;

– Event ev is referenced to by the requirement R and does

not belong D0; thus, this rule is called RD(3)r.

Fig. 7 … and subsequently to off " is off in the heating control

problem diagram

Fig. 8 Observe-to-control rules OTCc and OTCr

Fig. 9 Left: D’ ready for domain removal; right: without further

influence, R’ compensates

Requirements Eng

123

All of the above cases are admissible, from which six

sub-rules are derived.

Note that we only apply this rule when R does not

constrain internal phenomena of D0 (except D0’s shared

event ev with D in RD(1)c&b, RD(2)c&b and RD(3)c&b,

ev is internal phenomenon of D), and in other words, no

more events that belong to D0 are constrained by

R; therefore, we have the following justification of the rule

(which is similar to all removing domain rules):

– Statements in R on phenomena other than event ev are

untouched by this rule and remain the same in the derived

requirement; since R’s only constraint on domain D0 is ev

(R may constrain or refer to some internal phenomena

that belong to D or D’s shared phenomena with other

domains), removing D0 does not touch any phenomena in

R, and since R’s constraint on ev is still kept within the

rewritten requirement, i.e., R0 repeats what is stated in

R; thus, all constraints or references on such phenomena

remain the same in both R and R0.

The effect of this rule is to reduce by one the number of

domains.

3.5 A terminating heuristic for rule application

The aim of this work is an operationalisation of problem

progression which identifies and exploits useful structures

and causal relationships in informal real-world domain

descriptions for the systematic and traceable transforma-

tion of requirements into software specifications. Note that

we do not claim that every application of rules will lead to

the same end point, only that any endpoint that is reached,

i.e., every specification derived from a problem, will pro-

vide a solution. Here, we argue that, given suitable causal

chains linking phenomena, there is a sequence of rule

applications which end with a machine specification.

It is not obvious that rule application will always ter-

minate. Indeed, it is not the case that an arbitrary appli-

cation will terminate: take the transformation in Fig. 6, for

example, and consider the effect of ETC(3)c followed by

CTE(3)c with the same causal relationship as subject, the

result of the CTE application is the inverse of the CTE

application. Some way must be found of preventing such

inverse pairs being applied.

Recall that our aim is to attach the requirement to the

machine under the assumption that causal chains link the

phenomena that appear in the software problem. Given a

machine-shared phenomena, we may determine whether it

is observed by the machine or controlled by it.

In the former case, we may assume that that phenome-

non is at the end of a causal chain that is incident on the

machine, but with original cause distant from the machine

and referenced by the requirement, in which case we

should apply the CTE and/or CTO rules applied to the

distant cause to ‘move’ the requirement ‘closer’ to the

effect, i.e., the machine.

In the latter case, we may assume that that phenomenon

is at the end of a causal chain incident on the machine, but

with effect distant from the machine and constrained by the

requirement, in which case we should apply the ETC and/

or OTC rules to the distant effect to ‘move’ the requirement

‘closer’ to the cause, i.e., the machine.

In each case, a distant cause or effect is moved closer to

the machine; applying an inverse would move the cause or

effect further from the machine and so would not be

allowed under this heuristic.

4 Example: the package router

The package router is used extensively in the Problem

Frames literature as a benchmark example for Problem

Frame techniques. Here, we present problem progression as

applied to this benchmark example.

4.1 The package router problem

A package router is a large machine used by delivery

companies to sort packages into bins according to

bar-coded destination labels affixed to the packages.

Fig. 10 Removed domain rule RD(1)c, RD(1)r, RD(2)c, RD(2)r,

RD(3)c and RD(3)r

Requirements Eng

123

Each bin corresponds to a regional area. Packages

slide by gravity through a tree of pipes and binary

switches. The bins are at the leaves of this tree. The

problem is to control the operation of the package

router so that packages are routed to their appropriate

bins, obeying the operator’s commands to start and

stop the conveyor, and reporting any misrouted

packages.

Figure 11 is a schematic of the package router, and

Fig. 12 shows details of the pipes and switches (both taken

from [15], unmodified).

4.1.1 Decomposing the problem into subproblems

The analysis in [7] shows that this problem can be

decomposed into the following subproblems:

P1 = ‘‘The problem is to control the operation of the

package router so that packages are routed to their

appropriate bins.’’

P2 = ‘‘The problem is to let the operation obey the

operator’s commands to start and stop the conveyor.’’

P3 = ‘‘The problem is to report any misrouted

packages.’’

Subproblem P2 concerns the situation where the con-

veyor should be in its running or stopped state in response

to the operator’s commands; subproblem P3 concerns the

situation where a package arrives at a bin, but its destina-

tion ID is not correctly associated with the bin because the

package may have been directed along the wrong path from

a switch, e.g., due to some mechanical errors of the

switches, etc.

4.1.2 Describing subproblem P1

Although each of the above subproblems could be

addressed through problem progression, for brevity, we

will focus only on P1. We follow the standard PF approach

to problem analysis, i.e., identifying relevant domains as

shown in Table 2, drawing the problem diagram as shown

in Fig. 13, with the shared phenomena designated in

Table 3.

4.1.3 Identifying causal relationships

The Package domain is a causal domain with complex

behaviours which can be partially expressed by a state

machine diagram [16] (assuming it does not break—actu-

ally breakage can be monitored by subproblem P3 and

stopped by subproblem P2—problem composition is out-

side the scope of problem progression) in Fig. 14 (adapted

from [15], modified). The timed transitions capture the

time duration a package needs to slide from one part of the

routing device to the next.

The following causal relations can be derived from

Fig. 14:

1. " inRS þ\xþy

" inSW means that the package entering

the Reading station will cause it to enter the Switch

within x ? y seconds.

2. ðswStateðleftÞÞ :" inSW þ\zþw

" inBin1 means that if

the Switch is set to the left, then the package entering

the Switch will cause it to enter Bin1 within

z ? w seconds.

3. ðswStateðrightÞÞ :" inSW þ\zþw

" inBin2 means that if

the Switch is set to the right, then the package entering

the Switch will cause it to enter Bin2 within

z ? w seconds.

However, the following phenomena (including

shared and internal ones) are not explicitly described in

Fig. 14:

1. The internal phenomena that every package has a

unique id (may be useful for other subproblems, e.g.,

tracking/displaying/reporting misrouted package) and

destination pkgDst, which, for this simplified problem,

Fig. 11 Schematic of the package router problem (adapted from [7])

Fig. 12 Pipes and switches (adapted from [7])

Requirements Eng

123

is a state with two values: either pkgDst = left or

pkgDst = right (for problems with more than two bins,

pkgDst should be the target bin number);

2. The package shares phenomenon shared(pkgDst) with

the Reading station, where pkgDst represents package

destination: either pkgDst = left or pkgDst = right. It

Table 2 Domains and their

descriptionsName Description

Package The physical object (e.g. a mail or parcel) to be sorted to the correct bins for delivery. All

packages carry bar-coded labels, which contain its id and destination pkgDst. In this

simplified problem, pkgDst is either left or right; in a problem with more than two bins,

pkgDst is the destination bin number. They go through the reading station, after which

they slide down through pipes and switches by gravity and finally stop and arrive at their

destination bins

Bin1, Bin 2 The container that the package is finally released. Each bin is dedicated to a group of

adjacent areas (addresses) for delivery

Reading

station

The place through which the package is fed from the conveyor and its id and destination are

read

Switch A two-position device that joins 3 pipes - one incoming pipe, one left pipe and one right

pipe. It can be flipped to the left or to the right so that a package can only slide down one

of the connected pipes (either left pipe or right pipe). The flipping is controlled by the

controller to be built

Controller The solution machine to be designed. Its wired connection with the reading station allows it

to indirectly access package ids and destinations; its wired connection with the switch

allows it to control the flipping of switches

Table 3 Phenomena and their designations

Name Type Designation

{send(pkgDst)} Shared event The reading station sends the package destination pkgDst to the controller. The destination

pkgDst can be left or right

{set{(pkgDst)} Shared event The controller machine sets the switch to left or right according to the package destination

pkgDst

fshareðpkgDstÞ " inRSg Shared event Once the package arrives at the reading station, i.e., " inRS event occurs, the package’s barcode

label is shared with the reading station, i.e., share(pkgDst) event occurs

f" inSWg Shared event Once the package is inside the switch, event " inSW occurs, which is shared with the Switch

domain, e.g., via optical sensors

f" swStateðpkgDstÞg Shared event Depending on the package’s destination (pkgDst= left or right), the switch is set accordingly, so

event " swStateðpkgDstÞ is shared with the Package domain, which decides whether the

package goes to Bin1 or Bin2

f" inBin1g Shared event When the package enters Bin1, event " inBin1 occurs

f" inBin2g Shared event When the package enters Bin2, event " inBin2 occurs

fpkgDst; " inRSg Internal state/

shared event

The package’s destination pkgDst. namely left or right. in this simplified problem diagram is

encoded in the package’s label (barcode). Event " inRS occurs when the package enters the

reading station

f" inBin1; " inBin2g Shared event Once the package enters Bin1 or Bin2, the event " inBin1 or " inBin2 occurs

Fig. 13 Problem diagram

Requirements Eng

123

is controlled by the Package domain. There are the

following causal relations:

ðpkgDst ¼ leftÞ :" inRS shareðleftÞ; andðpkgDst

¼ rightÞ :" inRS shareðrightÞ;

3. The Switch’s state swState(left) or swState(right) is

shared between the Switch domain and the Package

domain, and it is controlled by the former. These

shared phenomena determine whether the package

goes to the left bin Bin1 or the right bin Bin2 (as

captured by the causal relations in the package

description earlier on).

Bin1 and Bin2 are simple causal domains with sensors at

their entrances. Their shared phenomena with the Package

domain, namely " inBin1 and " inBin2; will allow the

package into them.

The Reading station domain is causal, with the follow-

ing causal relation: sharedðpkgDstÞ sendðpkgDstÞ; where

pkgDst 2 fleft; rightg; which means that the bar-code for

the package’s destination pkgDst, namely left or right, is

shared with (or scanned by) the reading station, which will

cause the reading station to send the package’s destination

information to the Controller domain.

The Switch domain is causal, with the following causal

relation:

setðpkgDstÞ " swStateðpkgDstÞ;

where pkgDst 2 fleft; rightg; which means that the Con-

troller issuing the set(left) command will cause the

switch’s state swState to become left, and the Controller

issuing the set(right) command will cause the switch’s state

swState to become right.

4.1.4 Interpreting the requirement for P1

In a realistic project, the project stakeholders may have

expressed the requirement in a fuzzy and somewhat

abstract statement, which may be a reasonable start in

early requirements elicitation phase. For example, the

requirement for P1 might have been some informal state-

ment like

R0 = ‘‘A package should eventually reach its correct

destination’’.

In PFs, a requirement statement should be concretised as

conditions (either references to or constraints) on certain

problem domain’s observable phenomena. This coincides

with the Robertsons’ criterion on good requirements—that

requirements must be measurable [17]. Therefore, stake-

holders should investigate problem domain’s phenomena

(see Sect. 4.1.2 for details) and concretise and interpret

statement R0 as something like the following:

R1 = ‘‘If the package’s destination ispkgDst, with

pkgDst = leftorpkgDst = right, and the package

enters the reading station (i.e., " inRS occurs), then

the package should enter the appropriate bin (i.e.

either " inBin1or " inBin2 occurs) within

x ? y ? z ? w seconds.’’.

Note:

– R1 relates two separate sets of phenomena, namely

those that R1 refers to, i.e., fpkgDst; " inRSg; and those

that R1 constrains, i.e., f" inBin1; " inBin2g: Although

they are drawn as a single dotted line with an arrow

head in Fig. 13, our application rules can differentiate

requirement references from requirement constraints.

– Since causality is timed in this problem, a time

constraint is expressed by R1 on the total travelling

time of the package through the router. This relation

should be achieved by the entire routing device

including the Reading station and the Switch domains,

which are directly connected to the Package domain,

and the Controller domain, which is indirectly con-

nected to Package.

4.2 Problem progression

In this section, we explain the steps needed to transform

problem P1 from its requirement statement R1 to the

specification R12. (The resulting progression of require-

ments is shown in Table 4.)

Fig. 14 Package behaviour described as a state machine

Requirements Eng

123

R2ð R1Þ Consider pkgDst, which is internal to

Package, and " inRS; which is shared

between Package and Reading station.

Recall that the following causal relations

exist:

ðpkgDst ¼ leftÞ :" inRS shareðleftÞ

and

ðpkgDst ¼ rightÞ :" inRS shareðrightÞ

Then, cause-to-effect rule CTE(6)r replaces

event " inRS with event share(pkgDst) (see

R2 in Table 4).

R3ð R2Þ Applying the control-to-observe rule CTOr.

Switching from Package (the controller) to

Reading station (the observer) results in

requirement statement R3.

R4ð R3Þ Recall that Reading station has the

following domain properties (causal

relations):

sharedðpkgDstÞ sendðpkgDstÞ;

where pkgDst 2 fleft; rightg so that cause-

to-effect rule CTE(7)r applies to replace

share(pkgDst) with send(pkgDst) resulting

in requirement statement R4.

Table 4 Traceable requirements transformations in the package router problem progression

Name Description

R1 If the package’s destination is pkgDst, with pkgDst=left or pkgDst=right, and the package enters the reading station

(i.e. " inRS occurs), then the package should enter the appropriate bin (i.e. either " inBin1 or " inBin2 occurs) after

x ? y ? z ? w seconds

R2 (by rule CET(6)r) If the package’s destination is pkgDst, with pkgDst=left or pkgDst=right, and the package shares pkgDst with the

reading station (i.e. share(pkgDst) occurs), then the package should enter the appropriate bin (i.e. " inBin1 or

" inBin2 occurs) after x ? y ? z ? w seconds

R3 (by rule ITOr) If the package’s destination is pkgDst, with pkgDst=left or pkgDst=right, and the reading station reads pkgDst (i.e.

shareðpkgDstÞ occurs), then the package should enter the appropriate bin (i.e. either " inBin1 or " inBin2 occurs)

after x ? y ? z ? w seconds

R4 (by rule CTE(7)r) If the package’s destination is pkgDst, with pkgDst=left or pkgDst=right, and the reading station sends pkgDst to the

controller (i.e. send(pkgDst) occurs), then the package should enter the appropriate bin (i.e. either " inBin1 or

" inBin2 occurs) after x ? y ? z ? w seconds

R5 (by rule ITOr) If the package’s destination is pkgDst, with pkgDst=left or pkgDst=right, and the controller receives pkgDst (i.e.

send(pkgDst) occurs), then the package should enter the appropriate bin (i.e. either " inBin1 or " inBin2 occurs) after

x ? y ? z ? w seconds

R6 (by rule ETC(7)c) If the package’s destination is pkgDst, with pkgDst=left or pkgDst=right, and the controller receives pkgDst (i.e.

send(pkgDst) occurs), then the package should enter the switch (i.e. " inSW occurs) with the switch state

appropriately set (i.e. either swState(left) or swState(right)), depending on the value of pkgDst after x ? y seconds

R7 (by rule RD(3)c) Assuming the behaviour of Bin1 and Bin2, if the package’s destination is pkgDst, with pkgDst=left or pkgDst=right,

and the controller receives pkgDst (i.e. send(pkgDst) occurs), then the package should enter the switch (i.e. " inSW

occurs) with the switch state appropriately set (i.e. either swState(left) or swState(right)) depending on the value of

pkgDst after x ? y seconds

R8 (by rule ITOc) Assuming the behaviour of Bin1 and Bin2, if the package’s destination is pkgDst, with pkgDst=left or pkgDst=right,

and the controller receives pkgDst (i.e. send(pkgDst) occurs), then the switch observes the package entering (i.e.

" inSW occurs), with the switch state appropriately set (i.e. either swState(left) or swState(right)), depending on the

value of pkgDst after x ? y seconds

R9 (by rule ETC(7)c) Assuming the behaviour of Bin1 and Bin2, if the package’s destination is pkgDst, with pkgDst=left or pkgDst=right,

and the controller receives pkgDst (i.e. send(pkgDst) occurs), then the switch should receive commands from the

controller to set its state appropriately set (i.e. either set(left) or set(right) occurs), depending on the value of pkgDst

after x ? y seconds

R10 = (by rules RD(3)c) Assuming the behaviour of Bin1, Bin2 and Package, if the controller receives pkgDst (i.e. send(pkgDst) occurs), with

pkgDst=left or pkgDst=right, then the switch should receive commands from the controller to set its state

appropriately set (i.e. either set(left) or set(right) occurs), depending on the value of pkgDst after x ? y seconds

R11 = (by rules OTIc) Assuming the behaviour of Bin1, Bin2 and Package, if the controller receives pkgDst (i.e. send(pkgDst) occurs), with

pkgDst=left or pkgDst=right, then the controller should issue commands to set the switch state appropriately set (i.e.

either set(left) or set(right) occurs), depending on the value of pkgDst after x ? y seconds

R2 = (by rules

RD(1)c&(2)r)

Assuming the behaviour of Bin1, Bin2, Package, Switch and Reading station, if the controller receives pkgDst (i.e.

send(pkgDst) occurs), with pkgDst=left or pkgDst=right, then the controller should issue appropriate commands (i.e.

either set(left) or set(right) occurs), depending on the value of pkgDst after x ? y seconds

Requirements Eng

123

R5ð R4Þ Control-to-observe rule CTOr then applies

to switch from the Reading station to the

Controller resulting in requirement

statement R5.

R6ð R5Þ That domain properties of Package include

the following:

ðswStateðleftÞÞ :" inSW þ\zþw

" inBin1

and

ðswStateðrightÞÞ :" inSW þ\zþw

" inBin2

allows us to apply effect-to-cause rule

ETC(7)c (twice) to replace " inBin1 and "inBin2 with " inSW and swState(pkgDst)

holds, respectively, resulting in requirement

statement R6. (Note that the time z ? w of

transit of the package from the switch to the

bin has been taken into account in the

rewritten R6.)

R7ð R6Þ We then apply the remove domain rule

RD(3)c (twice) to remove Bin1 and Bin2

resulting in requirement statement R7.

R8ð R7Þ Applying the control-to-observe rule CTOc

(twice) to switch from Package to Switch

events and " swStateðpkgDstÞ results in

requirement statement R8.

R9ð R8Þ Recalling that Switch has the following

domain properties (causal relations):

setðpkgDstÞ " swStateðpkgDstÞ; where

pkgDst 2 fleft; rightg so that effect-to-

cause rule ETC(7)c replaces swState

(pkgDst) with set(pkgDst) for requirement

statement R9.

R10ð R9Þ Remove domain rule RD(3)c applied to

Package gives requirement statement R10.

R11ð R10Þ We then apply the observe-to-control rule

OTCc to switch from domain Switch to

domain Controller, resulting in requirement

statement R11.

R12ð R11Þ And finally, we apply the remove domain

rule RD(1)c first to remove Switch and then

rule RD(2)r to remove Reading station

resulting in requirement statement R12.

That completes all the steps of problem progression as

the requirement statement R12 is expressed only in terms of

specification phenomena, i.e., all Controller’s phenomena.

Figure 15 shows the (much simplified) problem diagram

that results from the problem progression.

This concludes the problem progression for our

example.

4.3 Guiding problem transformation using causal

chains ending with machine phenomena

From this exemplar, we can observe that the proposed

transformation rules provide needed mechanisms to sys-

tematically manipulate requirements descriptions and

domain descriptions in various mini-steps. Since they are

applied in a stepwise manner, guidance is needed to help

with the transformations. For example, Fig. 16 shows the

two causal chains (we use bold-and-red dotted arcs to

distinguish them from requirements) which may be used

for guiding rule applications. Based on the terminating

heuristics given previously in Sect. 3.4, the two causal

chains terminate (represented by arrow heads) at the

machine interface. This may provide the intuition needed

in communicating among project stakeholders in terms of

eliciting domain knowledge and/or requirements and ra-

tionalising software design.

5 Empirical evaluation

The approach presented in this paper is design-science

based, the goal of which is

to create innovations that define the ideas, practices,

technical capabilities and products through which the

analysis, design, implementation, management and

use of information systems can be effectively and

efficiently accomplished [18]

As a first evaluation of our technique, we have con-

ducted a laboratory-based evaluation supported by a pro-

totype tool for computer-aided problem progression.

5.1 The subjects

We enrolled 50 first-year and 14 second-year postgraduate

computer science students studying at a southern urban

university in China. All were MSc (Master of Science)

students majoring in computer science and information

technology, a 3-year course. In the first year, students must

take several compulsory modules and some selective

modules, according to their planned research and out of

their personal interests; in the second year, the students are

required to work with their supervisors and focus on a

research topic in addition to taking some selective modules

Fig. 15 Final problem diagram after problem progression

Requirements Eng

123

to earn enough credit for the degree; in the third year, the

students wrap up their research and write their dissertations.

Before participating in the experiments, the students were

given several lectures on the basics of Problem Frames.

They were also given tutorials on problem progression.

We chose student subjects in this first evaluation

because we wanted to evaluate our techniques in their

purest form, i.e., we wanted to avoid the confounding

effects which may be caused by rich background experi-

ence or competencies in requirement analysis and design.

Since Problem Frames are relatively new in the software

engineering curriculum, the students had not been exposed

to any knowledge of our techniques or tools before.

Although the students might have gained a lot of knowl-

edge about software engineering in general through their

undergraduate courses, their knowledge about Problem

Frames, problem transformation and the tool was minimum

before the first author’s lectures.

5.2 The problem transformation tool

In order to evaluate empirically the techniques proposed in

this paper, we have developed a prototype tool using

Microsoft Visual Studio C#. The required running envi-

ronment is the .NET framework 4.0. Our aim was to

develop a tool to allow users to manipulate diagrammatic

elements and transform them in a stepwise manner

according to the three classes of rules defined previously in

this paper; hence, we decided to develop a customised

problem transformation tool, instead of using a generic

graph editor tool such as Microsoft Visio.

The tool allows the user to draw problem diagrams by

selecting, dropping, moving and linking various ready-

made diagrammatic elements representing the machine,

application domains, the requirement, shared phenomena,

requirement references and constraints, as well as domain

property descriptions, as shown in Fig. 17.

Fig. 16 Two causal chains

(in bold-and-red dotted arrows)

guiding rule applications

(color figure online)

Fig. 17 Problem progression tool as a graph editor

Requirements Eng

123

Moreover, as shown in Fig. 18, the tool allows the user

to apply problem progression rules to a domain (Package

in this case) that is directly constrained or referenced by the

requirement, by selecting a rule out of the three classes of

progression rules defined, i.e., cause-and-effect, switching-

viewpoint and domain removal rules.

Finally, the tool automatically modifies the requirement

statement based on the sequence of rules applied, as shown

in Fig. 19.

5.3 The evaluation

The purpose of the evaluation was to answer the following

questions:

– How easy is problem progression to understand

theoretically?

– How easy is problem progression to apply without tool

support?

– How does a dedicated tool help in applying problem

progression?

Based on the above evaluation questions, we designed

the following three experiments:

– The first experiment investigates how easy it was to

identify causal relationships between events. Participants

were provided with a fully described problem diagram

for the POS problem [8] and asked to identify causal

relationships between events as cause–effect pairs.

– The second experiment investigates how easy it is for

participants to progress a problem by hand. Participants

were asked to progress the POS problem by applying

transformations from the three classes of progression

rule from the initial to final problem.

– The third experiment investigates how a dedicated

tool can help in applying problem progression.

Participants were divided into groups containing at

least 1 second-year student and asked to draw the

problem diagram for the package router problem, then

identify correct causal relationships from textual

descriptions and discussions, and use the tool to

manipulate the diagram to reach the machine phe-

nomena from requirements phenomena. At the end,

the was given a short questionnaire to evaluate the use

of the tool.

All participants were given a brief introduction to

problem modelling, its notation and descriptions. An

example problem model, the heating control problem [8],

was given and explained to them.

5.4 The results

In the first experiment, 52 out of the 64 participants found

the 6 pairs of cause-and-effect relationships necessary for

progressing the POS problem, including 27 participants

who found exactly the 6 necessary and sufficient pairs, and

another 25 participants who found extra cause-and-effect

pairs in addition to the 6 necessary and sufficient pairs. The

extra pairs were either mistakenly identified events that

were not causally related but often happened in a fixed

temporal order, or causal relationships between machine’s

Fig. 18 Selecting a domain and an applicable transformation rule

Requirements Eng

123

externally shared events which were correct but not nec-

essary for problem progression.

The remaining 12 out of the 64 participants found fewer

than 6 pairs, including 8 of them who found 5 pairs, 1 of

them who found 4 pairs, 1 of them who found 3 pairs, and 2

of them who completely ignored the instructions and drew

data flow diagrams.

In the second experiment, 61 out of the 64 partici-

pants could identify the correct causal chains linking

requirements phenomena to specification phenomena, but

they had difficulty differentiating the 3 classes of pro-

gression rules, and formulating the correct sequences of

rule applications.

In the third experiment, due to constraints on the number

of available computers, the participants were divided into

12 groups containing at least 1 second-year student each:

all groups succeeded in the task. The results of the ques-

tionnaire are given in Table 5.

Fig. 19 Automatically generated requirement description after the application of a transformation rule

Table 5 Participants’ answers to the questionnaire

1. How helpful is problem progression to you in understanding and analysing the requirements for the system to be designed?

Extremely helpful Very helpful Somewhat helpful Not helpful

19 37 8 0

2. How helpful is the tool to you in understanding and mastering the 3 classes of transformation rules, after applying the tool in the POS and the

package router problems?

Extremely helpful Very helpful Somewhat helpful Not helpful

6 52 6 0

3. How helpful is problem progression to you in your communication and discussion about requirements and application domains among

members of your group?

Extremely helpful Very helpful Somewhat helpful Not helpful

18 34 12 0

Requirements Eng

123

5.5 Observations

Based on the above results, we can make the following

observations. The idea of problem progression appears

easy to grasp by participants representative of novice

requirements engineers, who find it relatively easy to

identify appropriate cause-and-effect pairs. The application

of progression rules by hand is more problematic, although

it can be eased by automatic tool support: the majority of

the participants found it difficult to apply the transforma-

tions accurately in the paper evaluation, but they were able

to trace from higher-level requirements through to lower-

level requirements quite easily with the provided tool in the

third experiment.

5.6 Threats to validity

Participants were the same across the three experiments,

and so there was the learning effect to be considered. This

was mitigated by the choice of a more complex problem for

the third experiment. The overall results may not generalise

to the experienced requirements engineer, but they should

be representative of those with less experience.

6 Related work

Software engineering activities are concerned with both

non-formal and formal domains of reasoning: on the one

hand, the physical and human world, requirements

expressed in natural language, the capabilities of human

users and operators, and the identification and resolution of

apparent and real conflicts between different needs; on the

other, formal hardware/software machine.

An effective end-to-end approach to system develop-

ment must, therefore, deal adequately with the non-formal

and the formal as well as with the relationships between

them, an area in which development has previously

struggled (see, for instance, [4]). Our work contributes to

such an aim of combining non-formal and formal and

record their relationship. In this section, we compare and

contrast our work with a number of approaches which are

known from the literature.

6.1 Formal methods

Recognising the need for end-to-end coverage, some for-

mal methods authors have advocated extending the scope

of formal techniques through a formally integrated

requirements engineering process covering elicitation,

modelling and analysis, communication and validation,

examples include [19–21]. However, their solution is often

to derive software specifications from high-level formal

notations including, for instance, real-time linear temporal

logic (cf. [22]). The problem of, for instance, agreeing a

formal requirements expression with the customer (or other

non-specialist stakeholder) is left untreated. Thus, although

such approaches may build the system right, they do not

necessarily build the right system.

An approach that is based on transformation, and which

thus considers the importance of relationships between

engineering stages, is model-driven engineering (MDE), an

umbrella term encompassing a range of software devel-

opment approaches which see models as key artefacts in

the development process and from which executable code

is derived. Notable among them is model-driven

architecture.11

However, as recognised by Mellor in his recent keynote

address [23], the promise of MDE in delivering a true end-

to-end process is yet to be realised. One particular area

which has only recently received some attention is that of

requirement models. In particular, [24] proposes the

introduction of restrictions and of a new template for the

specification of use cases—one of the main approaches to

requirements modelling within MDE—so as to avoid

ambiguities and facilitate subsequent automated analysis;

whilst sharing with our work the desire to deal with

informal descriptions, its main aim is internal consistency

of use case models rather than with the derivation of

solution specifications from requirements.

6.2 Problem-oriented approaches

Our work is located within a problem-oriented view of

requirements, where a number of techniques have devel-

oped from Jackson’s seminal work on Problem Frames [7].

In the last decade, Problem Frames have been applied and

extended in a number of directions. For example: [25] has

looked into the problem of deriving software architectures

from Jackson’s five basic frames; [26, 27] have looked at

capturing business problems with Problem Frames; [28]

has applied Problem Frames in the context of security

engineering, [29] in safety engineering and [30] in process-

control systems; while [31–33] have looked at meta-mod-

els and ontologies for Problem Frames with a view to tool

development. This is the rich context to which our work

adds.

Realising the importance of bridging end-to-end, as

early as the mid-90s, Jackson and Zave [34] demonstrated

on an example how a specification could be derived from a

requirement. The example was that of a coin-operated

turnstile, and they used a logical constraint language to

help with the reasoning and transformations. This lead, in

[35], to a detailed classification of phenomena as

11 OMG. Model Driven Architecture. http://www.omg.org/mda/.

Requirements Eng

123

environment/machine controlled and shared/unshared, and

of assertions as indicative/optative, which we retain and

which drive our transformations.

The authors of this paper have also attempted to provide

alternative and fully formal techniques to support the

transformation from requirements to specifications, build-

ing on the set-based denotational semantics underpinning

Problem Frames of [36] and having uncovered a deep

relationship (see [37]) between problem progression and

Lai’s weakest environment calculus [38]. However, this

fully formal approach again depends on requirements

expressed in formal language, this time CSP [39].

Work by Seater et al. [40] pursues problem progression

in another direction: a stepwise rewrite of the requirement

statement is applied until a specification is reached. How-

ever, their approach is fully formal, and as a by-product of

each rewrite, assumptions are generated (called ‘bread-

crumbs’, similar to the assumptions we embed into our

rewritten requirement) to preserve the notion of satisfaction

based on logical implication: this requires the formal

capture of the requirement (but can be embedded in Alloy

for automatic checking).

From the observation that Problem Frames notation

differs substantially from wide-spread software engineer-

ing practice based on UML [16], Lavazza et al. [41–43]

propose the integration of Problem Frames and UML to

ease the transition from requirements specifications to

UML-based design artefacts. Their work is complementary

to our work in this paper, where the focus is the systematic

transformation of real-world requirements into Problem

Frames-based specifications; hence, the two approaches

could coexist in an end-to-end software engineering life-

cycle.

Extending Problem Frames principles and embedding

them in an engineering framework are also the aim of

Problem-Oriented Engineering (POE) [44], developed by

the second and third author, which provides a framework

bridging (non-formal) problem and (formal) solution

spaces in a general engineering setting, as defined by

Rogers [45], and which has been extensively validated in

professional engineering practice (for instance, [6, 46–48]).

Problem progression features in POE as one of its many

problem transformation classes (see [15] for a compre-

hensive example of application of such transformations).

POE problem progression shares with the approach pre-

sented in this paper the need to rewrite the requirement to

take into consideration properties of real-world domains;

however, it does not put any restriction as to how such a

rewrite should occur or which domain properties should be

taken into consideration. As a consequence, it admits many

forms of rewriting, from the purely formal to the purely

subjective, which makes it a more abstract and general

transformation than what we have proposed in this paper.

However, causality is a possible driver for POE problem

progression as shown in the work of [49] in the context of

safety engineering. As a consequence, there would be an

opportunity to incorporate the techniques presented in this

paper within the more general POE framework, making

them available for a wider scope of application. Work

towards this aim is in progress with the development of a

tool for support.

7 Discussion and conclusion

We have argued that our transformational rules are sound

and provide adequate coverage of the topologies of interest.

We have proposed a basic heuristic to guide rule applica-

tion and have exemplified the approach through a bench-

mark problem.

7.1 Properties of the transformation

From the worked example throughout, we can observe that

among all the problem progression rules we have proposed,

the net effect of applying the Reducing through Cause and

Effect rule class is essentially substituting equivalent events

phenomena in the requirements descriptions; and similarly,

the net effect of applying the Changing Viewpoint rule

class is essentially substituting equivalent domain names

observing or controlling the same set of shared phenomena

in the requirement descriptions; for the Removed Domain

rule class, assumptions are made in the transformed

requirement statements, with the non-machine domains

being successively removed, while the machine domain is

the only one untouched. Since all the problem transfor-

mations we have proposed end at the machine domain

interface based on the proposed terminating heuristics, all

these rule classes have not touched the solution machine

domain; thus, transformations based on these two rule

classes are solution-preserving.

An issue that has not been addressed by this work is to

which extent two different progressions of the same

problem converge on the same specification. We note that

our heuristic for the order of rule application does not offer

much assistance in regard to this as it does offers no

guarantee of convergence, i.e., we do not claim that the

developer, given a free choice of transformation to apply,

will reach the same specification with any choice. Such a

property may be attractive when the requirements are

expressed formally, and so, there can be no interpretation

by the developer of which are the details of the relation-

ships between phenomena encoded in the non-formal

descriptions, and the final design does not depend on the

choices of the designer who uses the system. However,

convergence, as such, may be too strong for designed

Requirements Eng

123

systems: as our subject matter is design and engineering,

what we are aiming for is a traceable transformation to a

specification that will satisfy the requirement, without

necessarily expecting it to be the only one. We do not,

however, deny that there may be fruitful augments that can

be made in the exploration of, for instance, the notion of

adequacy through the detailed consideration of conver-

gence in the case of formally expressed requirements. This

too remains the subject of future research.

7.2 Evaluation of the example

The example problem in this paper was used primarily as a

means to demonstrate the viability of the approach. The

problem was captured in Problem Frames notation, aug-

mented by descriptions in natural language. Phenomena

were identified and designated, and causal relationships

among events established from those descriptions. These

were used to transform successfully the initial requirement

into a specification through rule application, adopting our

basic heuristic as guidance.

The example has both merits and limitations. It is a well-

known example from the literature [7, 15, 50], with known

problem models and decompositions, which has allowed us

to focus on a specific sub-problem on which to demonstrate

our techniques. It is a fairly typical control problem, hence

general enough to demonstrate our techniques, at least for

this class of problems. Domain descriptions could be pro-

vided which allowed us to establish essential causal rela-

tionship between events for the application of our rules.

The particular sub-problem we transformed was suffi-

ciently complex so that a number of causal chains had to be

considered in the rewrite of the requirement, including

timing constraints, and allowing us to exercise our tech-

nique to its full extent.

On the other hand, the causal relations between events

were relatively simple, with each effect having a single

cause and vice versa. Our choice of Moffett’s causal model

does not allow us to extend the approach to causal relations

with multiple causes and effects, sophisticated timing

concerns, etc. However, the techniques we propose are

notation independent, and so, the substitution of a more

complete causality—or indeed any other suitable relation,

singly or in combination—is not expected to cause

difficulty.

7.3 Potential benefits of applying the transformation

rules

The potential benefits of developing and proposing our

transformation rules in Problem Frames can be envisaged

in the following two perspectives:

– When using Problem Frames for developing software-

based systems, particularly critical systems, carefully

describing the step-by-step progression (which are

concretely supported and implemented by our trans-

formation rules) ensures adequate rigour in reasoning

about the requirements and domain properties based on

the phenomena, which are fundamental building blocks

of Problem Frames. Adoption of these rules in software

development will produce many traceable causal chains

linking requirements phenomena with machine phe-

nomena, meanwhile forcing the developer to document

(or at least describe) important guarding conditions of

causality (also known as domain assumptions), as

shown in Table 4. Without these basic transformations

steps, and associated guarding conditions, these causal

chains may collapse, posing serious problems to the

entire system;

– These transformation rules may provide a pattern to

follow in manipulating requirements and domain

descriptions, recording domain assumptions and poten-

tially arguing and rationalising design decisions in

practical software development.

7.4 Practicality, scalability and usability

Notwithstanding the limitations discussed above, our

approach to problem progression has a certain practical

appeal: it can guide practitioners to identify and exploit

particular structures in otherwise informal problem

descriptions, without a need for a formal language to be

adopted. It could also be argued that the fact that the many

rules are specialisations of only three general cases, their

application should be relatively easy to grasp conceptually:

this seems to be supported by our initial evaluation,

although more empirical evidence would be required to

support this claim fully.

As shown in the example, each rule addresses the

smallest possible progression step that can be taken at any

point in the process, such as exploiting the immediate

cause/effect relation between two events. As a conse-

quence, even for relatively short causal chains, a large

number of rule applications are required. For problem

diagrams of large complexity, this might become rather

cumbersome and impact negatively both on the practicality

and usability of the approach. This was also evidenced in

our paper-based evaluation.

As a consequence, for the approach to scale up to

complex real-world problems, while still remaining con-

ceptually clear and usable to the developer, appropriate

semi-automatic tools are required, both able to carry out

the bulk of the transformations based on the already

defined graph production rules, and by extension of our

Requirements Eng

123

theory so to introduce operators able to combine some of

the rules so that they apply more efficiently to entire causal

chains. The empirical evaluation results and the tool pro-

totype presented in Sect. 5 have given some encouraging

evidence that techniques presented in this paper will lead to

more substantial theories, tools and research results.

Acknowledgments Zhi Li’s research is sponsored by the National

Natural Science Foundation of China under Grant No.61262004, and the

authors’ joint research is sponsored by the National Science Foundation

of Guangxi Province under Grant No.2012GXNSFCA053010, and the

Guangxi Scientific Research and Technological Development Project

under Contract No.(Gui-Ke-He)1347004-22.

References

1. The challenges of complex IT projects (2004) Technical report,

working group (Chair: Basil R.R Butler) of The Royal Academy

of Engineering and The British Computer Society

2. Charettte R (2005) Why software fails. IEEE Spectrum, pp 42–49

3. Verner J, Sampson J, Cerpa N (2008) What factors lead to soft-

ware project failure? In: Proceedings of the 2nd international

conference on research challenges in information science (RCIS

2008). IEEE Press, New York, pp 71–80

4. Sikora E, Tenbergen B, Pohl K (2012) Industry needs and

research directions in requirements engineering for embedded

systems. Requir Eng 17:57–78

5. Turski WM (1986) And no philosophers’ stone, either. Infor-

mation processing 86, pp 1077–1080

6. Mannering D, Hall JG, Rapanotti L (September 2007) Safety

process improvement with pose and alloy. In: Saglietti F, Oster N

(eds) Proceedings of the 26th international conference on com-

puter safety, reliability and security (SAFECOMP’07), lecture

notes in computer science, vol 4680. Springer, Nuremberg,

Germany, pp 252–257

7. Jackson M (2001) Problem frames: analyzing and structuring

software development problems. Addison-Wesley Publishing

Company, Boston

8. Li Z (September 2007) Progressing problems from requirements

to specifications in problem frames. Ph.D. thesis, Department of

Computing, The Open University, Walton Hall, Milton Keynes,

UK

9. Li Z (May 2008) Progressing problems from requirements to

specifications in problem frames. In: Rapanotti L, Hall JG, Jin Z,

Cox K (eds) Proceedings of the 3rd international workshop on

advances and applications of problem frames (IWAAPF’08).

ACM Press, Leipzig, pp 53–59

10. Hommel G (1980) Vergleich verschiedener spezifikationsver-

fahren am beispiel einer paketverteilanlage. Kernforschungszen-

trum Karlsruhe, Karlsruhe

11. Jackson MA (April 2001) Problem structures and solution

structures: a position paper. In: Proceedings of the international

workshop on requirements engineering (IWRE’01). Imperial

College, London

12. Hopkins B (2004) Causality and development: past, present and

future, chap. 1. John Benjamins Publishing Company, Lancaster

University, pp 1–17

13. Moffett JD, Hall JG, Coombes A, McDermid JA (1996) A model

for a causal logic for requirements engineering. J Requir Eng

1(1):27–46

14. Ehrig H, Ehrig K, Prange U, Taentzer G (2006) Fundamentals of

algebraic graph transformation, 1st edn. Springer, New York

15. Hall JG, Rapanotti L, Jackson MA (2008) Problem Oriented

Software Engineering: solving the package router control prob-

lem. IEEE Trans Softw Eng 34(2). http://oro.open.ac.uk/5445/

16. OMG: Unified Modeling Language (UML), version 2.0.

http://www.uml.org/. http://www.uml.org/. Last accessed: 12th

Septermber 2012

17. Robertson S, Robertson J (1999) Mastering the requirements

process. Addison-Wesley, Boston

18. Hevner AR, March ST, Park J, Ram S (2004) Design science in

information systems research. MIS Q 28(1):75–105

19. van Lamsweerde A, Darimont R, Massonet P (1995) Goal-

directed elaboration of requirements for a meeting scheduler:

problems and lessons learned. In: Proceedings of the RE’95—2nd

international symposium on requirements engineering, York

20. Heisel M, Souquieres J (1999) A method for requirements elic-

itation and formal specification. In: Conceptual modeling—

ER’99, LNCS 1728. Springer, New York, pp 309–324

21. van Lamsweerde A (2000) Formal specification: a roadmap. In:

ICSE ’00: proceedings of the conference on the future of software

engineering, pp 147–159. ACM, New York

22. Letier E, van Lamsweerde A (November 2002) Deriving opera-

tional software specifications from system goals. In: SIGSOFT

2002/FSE-10. Charleston, SC

23. Mellor SJ (2009) Models. models. models. so what? In: Schurr A,

Selic B (eds) MODELS 2009, LNCS 5795. Springer, Berlin, p 1

24. Yue T, Briand LC, Labiche Y (2009) A use case modeling

approach to facilitate the transition towards analysis models:

concepts and empirical evaluation. In: Schurr A, Selic B (eds)

MODELS 2009, LNCS 5795. Springer, Berlin, pp 484–498

25. Choppy C, Hatebur D, Heisel M (2005) Architectural patterns for

problem frames. IEE Proc Softw 152(4):198–208

26. Bleistein S, Cox K, Verner J (2004) Requirements engineering

for e-Business systems: intergrating Jackson context diagrams

with goal modelling and BPM. In: Proceedings of the 11th

international Asia-Pacific software engineering conference (AP-

SEC 2004), pp 410–417. IEEE, Busan, Korea. 30th November–

3rd December 2004

27. Cox K, Hall JG, Rapanotti L (2005) Editorial: a roadmap of

problem frames research. Inf Softw Technol 47(14):891–902

28. Hatebur D, Heisel M, Schmidt H (2006) Security engineering

using problem frames. In: Emerging trends in information and

communication security, lecture notes in computer science, vol

3995/2006. Springer, New York, pp 238–253

29. Strunk EA, Knight JC (2006) The essential synthesis of problem

frames and assurance cases. In: Proceedings of the 2006 inter-

national workshop on advances and applications of problem

frames (IWAAPF ’06). ACM Press, New York, pp 81–86

30. Zhang X, Auriol G, Baron C. (2010) Deriving specification for

process-control systems: a problem frames approach. In: 5th

International conference on systems (ICONS). IEEE Press, New

York, pp 60–65

31. Hatebur D, Heisel M, Schmidt H (2008) A formal metamodel for

problem frames. In: Model driven engineering lanugages and

systems, lecture notes in computer science, vol 5301/2008.

Springer, New York, pp 68–82

32. Chen X, Jin Z, Yi L (2007) An ontology of problem frames for

guiding problem frame specification. In: Knowledge schience,

engineering and management, lecture notes in computer science,

vol 4798/2007, pp 384–395

33. Lavazza L, Coen-Porisini A, Del Bianco V (2009) Towards a

meta-model for problem frames: conceptual issues and tool

building support. In: 4th International conference on software

engineering advances (ICSEA ’09). IEEE Press, New York,

pp 339–345

34. Jackson M, Zave P (1995) Deriving specifications from require-

ments: an example. In: Proceedings of the 17th international

Requirements Eng

123

conference on software engineering (ICSE’95). ACM Press,

Seattle, pp 15–24

35. Zave P, Jackson M (1997) Four dark corners of requirements

engineering. ACM Trans Softw Eng Methodol 6(1):1–30

36. Hall JG, Rapanotti L, Jackson MA (2005) Problem frame

semantics for software development. Softw Syst Model

4(2):189–198

37. Li Z, Hall JG, Rapanotti L (May 2006) From requirements to

specifications: a formal approach. In: Hall JG, Rapanotti L, Cox

K (eds) Proceedings of the 2nd international workshop on

advances and applications of problem frames (IWAAPF’06).

ACM Press, Shanghai, pp 65–70

38. Lai L, Sanders JW (1995) A weakest-environment calculus for

communicating processes. Research report PRG-TR-12-95, Pro-

gramming Research Group, Oxford University Computing

Laboratory

39. Hoare CAR (1985) Communicating sequential processes. Pre-

ntice-Hall International, Englewood Cliffs

40. Seater R, Jackson D, Gheyi R. (2007) Requirement progression in

problem frames: deriving specifications from requirements.

Requir Eng J 12(2):77–102

41. Lavazza L, Bianco VD (2006) Combining problem frames

and UML in the description of software requirements. In:

Baresi L, Heckel R (eds) Proceedings of FASE 2006, lecture

notes in computer science, vol 3922. Springer, New York,

pp 199–213

42. Colombo P, Del Bianco V, Lavazza L, Coen-Porisini A (2007) A

methodological framework for SysML: a problem frames-based

approach. In: Proceedings of the 14th Asia-Pacific software

engineering conference (APSEC 2007), pp 25–32. IEEE Com-

puter Press, New York

43. Colombo P, Khendek F, Lavazza L (2010) Requirements analysis

and modeling with problem frames and SysML: a case study. In:

Modelling foundations and applications, lecture notes in com-

puter science, vol 6138/2010. Springer, New York, pp 74–89

44. Hall JG, Rapanotti L (2012) Software engineering as the design

theoretic transformation of software problems. Innov Syst Softw

Eng 8(3):175–193

45. Rogers GFC (1983) The nature of engineering: a philosophy of

technology. Palgrave Macmillan, Basingstoke

46. Hall JG, Mannering D, Rapanotti L (2007) Arguing safety with

problem oriented software engineering. In: Proceedings of the

10th IEEE international symposium on high assurance systems

engineering (HASE 2007). IEEE Computer Society, Dallas,

Texas. http://oro.open.ac.uk/9591/

47. Nkwocha A, Hall JG, Rapanotti L (2011) Design rationale cap-

ture for process improvement in the globalised enterprise: an

industrial study. Software and systems modeling (online FirstTM,

14th December 2011). http://www.springerlink.com/content/

d45x17g438833069/

48. O’Halloran M, Hall JG, Rapanotti L (2012) Safety-assurance-

driven development. In: The 7th international conference on

software engineering advances (ICSEA 2012). Lisbon, Portugal

(to appear 2012)

49. Mannering D (2010) Problem oriented engineering for software

safety. Ph.D. thesis, The Open University, UK

50. Swartout W, Balzer R (1982) On the inevitable intertwining of

specification and implementation. Commun ACM 25(7):438–440

Requirements Eng

123