Handling Obstaclesin Goal-Oriented Requirements Engineering

Axel van Lamsweerde and Emmanuel Letier

Département d’Ingénierie InformatiqueUniversité catholique de Louvain

B-1348 Louvain-la-Neuve (Belgium){avl, eletier}@info.ucl.ac.be

sen

ni-rt

ive7,

heif

eystsr itn-llyhets

le-

ting-nalhe-a-s is93,ort

tis-].

ofd

al-].on-bemend

ly,ly

isnd

ABSTRACTRequirements engineering is concerned with the elicitatioof high-level goals to be achieved by the envisioned systethe refinement of such goals and their operationalizatiointo specifications of services and constraints, and thassignment of responsibilities for the resulting requiremento agents such as humans, devices, and software.Requirements engineering processes often result in goarequirements and assumptions about agent behavior thattoo ideal; some of them are likely to be not satisfied fromtime to time in the running system due to unexpected agebehavior. The lack of anticipation of exceptional behaviorresults in unrealistic, unachievable and/or incomplerequirements. As a consequence, the software developfrom those requirements will not be robust enough and winevitably result in poor performance or failures, sometimewith critical consequences on the environment.The paper presents formal techniques for reasoning aboobstacles to the satisfaction of goals, requirements, aassumptions elaborated in the requirements engineerprocess. A first set of techniques allow obstacles to be geerated systematically from goal formulations and domaproperties. A second set of techniques allow resolutionsbe generated once the obstacles have been identifithereby.Our techniques are based on a temporal logic formalizatioof goals and domain properties; they are integrated intoexisting method for goal-oriented requirements elaboratiowith the aim of deriving more realistic, complete and robusrequirements specifications.A key principle in this paper is to handle exceptions arequirements engineering time and at the goal level, so thmore freedom is left for resolving them in a satisfactorway. The various techniques proposed are illustrated aassessed in the context of a real safety-critical system.

KEYWORDS

Goal-oriented requirements engineering, high-level excetion handling, obstacle-based requirements transformatiodefensive requirements specification, specification refinment, lightweight formal methods.

1. INTRODUCTION

Requirements engineering (RE) is the branch of softwaengineering concerned with the real-world goals for, funtions of, and constraints on software systems. It is also co

y tox-are

This paper is a revised, expanded version of a paper appearing the Proceedings of ICSE’98 - 20th International Conference onSoftware Engineering, Kyoto, ACM-IEEE, April 1998.

To appear in IEEE Transactions on Software Engineering,Special Issue on Exception Handling, 2000.

nm,nets

ls,are

ntsteed

ills

utndingn-

intoed

nannt

tat

ynd

p-n,e-

rec-n-

cerned with the relationship of these factors to precispecifications of software behavior, and to their evolutioover time and across software families. This general defition, borrowed from [Zav97a], stresses the leading paplayed by goals during requirements elaboration. Goals drthe elaboration of requirements to support them [Ros7Dar91, Rub92]; they provide a completeness criterion for trequirements specification --the specification is completeall stated goals are met by the specification [Yue87]; thprovide a rationale for requirements --a requirement exibecause of some underlying goal which provides a base fo[Dar91, Som97]; goals represent the roots for detecting coflicts among requirements and for resolving them eventua[Rob89, Lam98b]; goals are generally more stable than trequirements to achieve them [Ant94]. In short, requiremen"implement" goals much the same way as programs impment design specifications.

Goals are to be achieved by the various agents operatogether in thecompositesystem; such agents include software components that exist or are to be developed, exterdevices, and humans in the environment [Fea87, Fic92]. Telicitation of functional and non-functional goals, their organization into a coherent structure, and their operationaliztion into requirements to be assigned to the various agentthus a central aspect of requirements engineering [DarMyl99]. Various techniques have been proposed to suppthis process.Qualitative reasoningtechniques may be usedto determine the degree to which high-level goals are saficed/denied by lower-level goals and requirements [Myl92When goals can be formalized,formal reasoningtechniquesare expected to do more. For example, the correctnessgoal refinements/operationalizations may be verifie[Dar96]; more constructively, such refinements/operationizations may be derived formally [Dar93, Fea95, Dar96Formal goal models may be used to detect and resolve cflicts among goals [Lam98b]. Planning techniques mayused to generate admissible scenarios showing that sodesirable goal is not achieved by the system specified, apropose resolution actions [And89, Fic92]. Conversedeclarative goal specifications may be inferred inductivefrom operational specifications of scenarios [Lam98c].

One major problem requirements engineers are faced withthat first-sketch specifications of goals, requirements aassumptions tend to be too ideal; such assertions are likelbe occasionally violated in the running system due to unepected behavior of agents like humans, devices, or softw

in

-min

es,a-byeso

at

isg

oft-g,n-andrect4,icntsise,

iveals,inn-

tst ofb-ecase

orr-

imi-n

ve-ti-ndech-or

m-ealst,s.ntstionfor-rm-olved in

components [Lam95, Pot95, Fea98]. This general problem isnot really handled by current requirements elaboration meth-ods.

Consider an ambulance dispatching system, for example; afirst-sketch goal such asAchieve[MobilizedAmbulancePromptlyAt-Incident] is overideal and likely to be violated from time totime --because of, e.g., allocation of a vehicle not closeenough to the incident location; or too long allocation time;or imprecise or confused location; etc. In an electronicreviewing system for a scientific journal, a first-sketch goalsuch asAchieve[ReviewReturnedInFourWeeks] or an assumptionsuch asReviewerReliable are straightforward examples ofoverideal statements that are likely to be violated on occa-sion; the same might be true for a security goal such asMain-tain[ReviewerAnonymity]. In a resource management system, agoal such asAchieve[RequestedResourceUsed] or an assump-tion such asRequestPendingUntilUse are also overideal asrequesting agents may change their mind and no longer wishto use the requested resource even if the latter becomes avail-able. In a meeting scheduler system, a goal such asAchieve[ParticipantsTimeConstraintsProvided] is likely to be vio-lated, e.g., for participants that do not check their email regu-larly thereby missing invitations to meetings and requests forproviding their time constraints. In a control system, a goalsuch asMaintain[AlarmIssuedWhenAbnormalCondition] might beviolated sometimes due to unavailable data, device failure ordeactivation by malicious agents.

Overidealization of goals, requirements and assumptionsresults in run-time inconsistencies between the specificationof the system and its actual behavior. The lack of anticipa-tion of exceptional circumstances may thus lead to unrealis-tic, unachievable and/or incomplete requirements. As aconsequence, the software developed from those require-ments will inevitably result in failures, sometimes with criti-cal consequences on the environment.

The purpose of this paper is to introduce systematic tech-niques for deidealizing goals, assumptions and requirements,and to integrate such techniques in a goal-oriented require-ments elaboration method in order to derive more completeand realistic requirements, from which more robust systemscan be built.

Our approach is based on the concept ofobstaclefirst intro-duced in [Pot95]. Obstacles are a dual notion to goals; whilegoals capture desired conditions, obstacles capture undesir-able (but nevertheless possible) ones. An obstacle obstructssome goal, that is, when the obstacle gets true the goal maynot be achieved. The term “obstacle” is thus introduced hereto denote agoal-orientedabstraction, at the requirementsengineering level, of various notions that have been studiedextensively in specific areas - such ashazards that mayobstruct safety goals [Lev95] orthreats that may obstructsecurity goals [Amo94] -, or in later phases of the softwarelifecycle - such asfaults that may prevent a program fromachieving its specification [Cri95, Gar99].

The paper presents a formalization of this notion of obstacle;a set of techniques for systematic generation of obstaclesfrom goal specifications and domain properties; and a set ofalternative operators that transform goal specifications so asto resolve the obstacles generated.

Back to the example of the ideal goal namedAchieve[Revie-wReturnedInFourWeeks], our aim is to derive obstacle specifications from a precise specification of this goal and froproperties of the domain; one would thereby expect to obtaobstacles such as, e.g.,WrongBeliefAboutDeadline or ReviewRe-questLost (under responsibility ofReviewer agents);Unprocess-ablePostscriptFile (under responsibility ofAuthor agents); andso on. From there one would like to resolve those obstacle.g., by weakening the original goal formulation and propgating the weakened version in the goal refinement graph;introducing new goals and operationalizations to overcomor mitigate the obstacles; by changing agent assignmentsthat the obstacle may no longer occur; and so on.

A key principle here is to handle abnormal agent behaviorrequirements engineering time andat the goal level.Thisprinciple is consistent with recommendations from analysof software requirements errors [Lut93]. Exception handlintechniques are usually introduced at later stages of the sware lifecycle, such as architectural design or programminwhere the boundary between the software and its enviroment has been decided and cannot be reconsidered,where the requirements specifications are postulated corand complete [And81, Bor85, Per89, Cri91, Ros92, Jal9Cri95, Aro98, Gar99]. In contrast, we perform systematobstacle analysis at the much earlier stage of requiremeengineering, from goal formulations, so that more freedomleft on adequate ways of handling obstacles to goals --like.g., considering alternative requirements or alternatagent assignments that result in different system proposin which more or less functionality is automated andwhich the interaction between the software and its enviroment may be quite different.

The integration of obstacle analysis into the requiremenengineering process is detailed in the paper in the contexthe KAOS methodology for goal-oriented requirements elaoration [Dar93, Lam95, Dar96]. In [Lam98b], we havshown that obstacle analysis can be seen as a degenerateof conflict analysis; an obstacle amounts to a condition fconflict between N goals within the domain under consideation, where N=1. As a consequence, there are generic slarities between the respective identification/resolutiotechniques. However, handling exceptions to the achiement of a single goal and handling conflicts between mulple stakeholders’ goals correspond to different problems afoci of concern for the requirements engineer. As will bseen in the paper, the generic identification/resolution meanisms yield different instantiations and specializations fobstacle analysis and for conflict analysis.

The rest of the paper is organized as follows. Section 2 sumarizes some background material on KAOS that will bused in the sequel. Section 3 introduces obstacles to goand provides a formal characterization of this concepincluding the notion of completeness of a set of obstacleSection 4 discusses a modified goal-oriented requiremeelaboration process that integrates obstacle analysis. Sec5 presents techniques for generating obstacles from goalmulations. Section 6 then presents techniques for transfoing goals, requirements and/or assumptions so as to resthe obstacles generated. The various techniques presente

2

ta-

ed;nalby

nt.in

eirnda-oal

lize

sft-stalinsby

si-in-tate

di-toits

eloro

n-x),n)er-

3,

totole,e

the paper are illustrated and assessed in Section 7 by anobstacle analysis of a real safety-critical system for whichfailure stories have been published [LAS93, Fin96]. Somerelated work is discussed in Section 8 before concluding inSection 9.

2. GOAL -ORIENTED RE WITH KAOS

The KAOS methodology is aimed at supporting the wholeprocess of requirements elaboration - from the high-levelgoals to be achieved to the requirements, objects and opera-tions to be assigned to the various agents in the compositesystem. The methodology provides a specification language,an elaboration method, and tool support. To make the paperself-contained, we recall some of the features that will beused later in the paper; see [Dar93, Lam95, Dar96, Dar98]for details.

2.1 Concepts and terminology

An object is a thing of interest in the composite systemwhose instances may evolve from state to state. Objects arecharacterized by attributes and invariant assertions. Theymay be organized in inheritance hierarchies. Anentity is anautonomous object. Arelationship is an object dependent onother objects it links. Anevent is an instantaneous object.

An operation is an input-output relation over objects; opera-tion applications define state transitions. Operations arecharacterized by pre-, post-, and trigger conditions. A dis-tinction is made betweendomainpre/postconditions, whichcapture the elementary state transitions defined by operationapplications in the domain, andrequiredpre/postconditions,which capture additional strengthenings to ensure that therequirements are met.

An agent is an active object which acts as processor forsome operations. An agentperforms an operation if it is allo-cated to it; the agentmonitors/controls an object if the statesof the object are observable/controllable by it. Agents maybe humans, devices, programs, etc.

A goal is an objective the composite system should meet; itcaptures a set of desired behaviors of the composite system.AND-refinement links relate a goal to a set of subgoals(called refinement); this means that satisfying all subgoals inthe refinement is a sufficient condition for satisfying thegoal. OR-refinement links relate a goal to an alternative setof refinements; this means that satisfying one of the refine-ments is a sufficient condition for satisfying the goal. Thegoal refinement structure for a given system can be repre-sented by anAND/OR directed acyclic graph [Nil71]. Goalsconcern the objects they refer to. A goal may additionally becharacterized by apriority attribute whose values specify theextent to which the goal is mandatory or optional.

Goals are classified according to the category of require-ments they will drive about the agents concerned. Functionalgoals result in functional requirements. For example,Satis-factionGoals are functional goals concerned with satisfyingagent requests;InformationGoals are goals concerned withkeeping agents informed about object states. Likewise, non-functional goals result in non-functional requirements. Forexample,AccuracyGoals are non-functional goals concernedwith maintaining the consistency between the state of

objects in the environment and the state of their represention in the software; other sub-categories includeSafety-Goals, SecurityGoals, PerformanceGoals, and so on.

Goal refinement ends up when terminal goals are reachthese are goals assignable to individual agents. A termigoal can thus be formulated in terms of states controllablesome individual agent. Arequirement is a terminal goalassigned to an agent in the software-to-be. Anassumption isa terminal goal assigned to an agent in the environmeUnlike requirements, assumptions cannot be enforcedgeneral. Terminal goals are in turnAND/OR operationalizedby operations and objects through strengthenings of thdomain pre/postconditions and invariants, respectively, athrough obligations expressed by trigger conditions. Alterntive ways of assigning responsible agents to a terminal gare captured throughOR responsibility links. The actualassignment of an agent to the operations that operationathe terminal goal is captured in correspondingperformslinks.

A domain property is a property about objects or operationin the environment which holds independently of the soware-to-be. Domain properties include physical law[Par95], regulations, constraints imposed by environmenagents [Lev95] --in short, indicative statements of domaknowledge [Jac93, Zav97b]. In KAOS, domain propertieare captured by domain invariants attached to objects anddomain pre-/postconditions attached to operations.

A scenario is a domain-consistent sequence of state trantions controlled by corresponding agent instances; domaconsistency means that the operation associated with a stransition is applied in a state satisfying its domain precontion together with the various domain invariants attachedthe corresponding objects, with a resulting state satisfyingdomain postcondition.

2.2 The specification language

Each construct in the KAOS language has a two-levgeneric structure: an outer semantic net layer [Bra85] fdeclaring a concept, its attributes and its various links tother concepts; an inner formal assertion layer forformallydefiningthe concept. The declaration level is used for coceptual modeling (through a concrete graphical syntarequirements traceability (through semantic net navigatioand specification reuse (through queries) [Dar98]. The asstion level is optional and used for formal reasoning [Dar9Dar96, Mas97, Fea98, Lam98b, Lam98c].

The generic structure of a KAOS construct is instantiatedspecific types of links and assertion languages accordingthe specific type of the concept being specified. For exampconsider the following goal specification for an ambulancdispatching system:

Goal Achieve [AmbulanceMobilization]Concerns Call, Ambulance, IncidentRefines AmbulanceInterventionRefinedTo IncidentFiled, AmbulanceAllocated,

AllocatedAmbulanceMobilized

InformalDef For every responded call about an incident, anambulance able to arrive at the incident scene within 11 minutesshould be mobilized. The ambulance mobilization time shouldbe less than 3 minutes [ORCON standard, 3005].

3

into

,alth

al-ralby

g to

ed

t

n

FormalDef ∀ cl: Call, inc: IncidentResponded (cl) ∧ About (cl, inc)⇒ ◊≤3m ∃ a: Ambulance

Mobilized (a, inc)∧ •[Available (a) ∧ TimeDist (a.Loc, inc.Loc) 11]

The declaration part of this specification introduces a con-cept of type “goal”, namedAmbulanceMobilization, stating atarget property that should eventually hold (“Achieve” verb),refering to objects such asCall or Ambulance, refining the par-ent goalAmbulanceIntervention, refined into subgoalsIncident-Filed, AmbulanceAllocated andAllocatedAmbulanceMobilized, anddefined by some informal statement. (The semantic net layeris represented in textual form in this paper for reasons ofspace limitations; the reader may refer to [Dar98] to seewhat the alternative graphical concrete syntax looks like.)

The optional assertion part in the specification above definesthe goalAchieve[AmbulanceMobilization] in formal terms using areal-time temporal logic inspired from [Koy92]. In this paperwe will use the following classical operators for temporalreferencing [Man92]:

o (in the next state) • (in the previous state)

◊ (some time in the future) ♦ (some time in the past)

❏ (always in the future) ■ (always in the past)

W (always in the future unless) U (always in the future until)

Formal assertions are interpreted over historical sequencesof states. Each assertion is in general satisfied by somesequences and falsified by some other sequences. The nota-tion

(H, i) |= P

is used to express that assertionP is satisfied by historyH attime position i (i ∈ T), where T denotes a linear temporalstructure assumed to be discrete for sake of simplicity. Wewill also use the notationH |= P for (H, 0) |= P.

States are global; thestateof the composite system at sometime positioni is the aggregation of the local states of all itsobjects at that time position. The state of an individual objectinstanceob at some time position is defined as a mappingfrom ob to the set of values of allob’s attributes and links atthat time position. In the context of KAOS requirements, anhistorical sequence of states defines a behavior produced bya scenario.

The semantics of the above temporal operators is thendefined as usual [Man92], e.g.,

(H, i) |= o P iff (H, next(i)) |= P

(H, i) |= ◊ P iff (H, j) |= P for some j i

(H, i) |= ❑ P iff (H, j) |= P for all j i

(H, i) |= PUQ iff there exists a j i such that (H, j)|= Qand for every k, i k < j, (H, k)|= P

(H, i) |= PWQ iff (H, i) |= PUQ or (H, i) |= ❑ P

Note that❑ P amounts toPW false . We will also use thestandard logical connectives∧ (and), ∨ (or), ¬ (not), →(implies), ↔ (equivalent), ⇒ (strongly implies), ⇔ (stronglyequivalent),with

P ⇒ Q iff ❑ (P → Q)P ⇔ Q iff ❑ (P ↔ Q)

Note thus that there is an implicit outer❑-operator in every

strong implication.

Beside the agent-related classification of goals introducedSection 2.1, goals in KAOS are also classified accordingthe pattern of temporal behavior they capture:

Achieve: C ⇒ ◊ TCease: C ⇒ ◊ ¬ T

Maintain: C ⇒ TW N, C ⇒ TAvoid: C ⇒ ¬ TW N, C ⇒ ¬ T

In these patterns,C, T, and N denote some current, targetand new condition, respectively. (We avoid the classicsafety/liveness terminology here to avoid confusions wiSafetyGoals.)

In requirements engineering we often need to introduce retime restrictions. Bounded versions of the above tempooperators are therefore introduced, in the style advocated[Koy92], such as

ײd (some time in the future within deadline d)

❑≤d (always in the future up to deadline d)

To define such operators, the temporal structureT isenriched with a metric domainD and a temporal distancefunction dist: T×T → D which has all desired properties of ametrics [Koy92]. We will take

T: the set of naturalsD: { d | there exists a natural n such that d = n × u},

where u denotes some chosen time unitdist(i, j): | j - i | × u

Multiple units can be used --e.g.,s (second),m (minute, seethe AmbulanceMobilization goal above),d (day), etc; these areimplicitly converted into some smallest unit. Theo-operatorthen yields the nearest subsequent time position accordinthis smallest unit.

The semantics of the real-time operators is then definaccordingly, e.g.,

(H, i) |= ײd P iff (H, j) |= P for some j i with dist(i, j) d

(H, i) |= ❑<d P iff (H, j) |= P for all j i such that dist(i, j) < d

In the above goal declaration ofAmbulanceMobilization, theconjunction of the assertions formalizing the subgoalsInci-dentFiled, AmbulanceAllocated and AllocatedAmbulanceMobilizedmust entail the formal assertion of the parent goalAmbulance-Mobilization they refine together. Every formal goal refinementhus generates a corresponding proof obligation [Dar96].

In the formal assertion of the goalAmbulanceMobilization, thepredicateMobilized(a,inc) means that, in the current state, ainstance of theMobilized relationship links variablesa andincof sort Ambulance and Incident, respectively. TheMobilizedrelationship andAmbulance entity are defined in other sec-tions of the specification, e.g.,

Entity AmbulanceHas Loc: Location, Dest: Location, ...

Relationship MobilizedLinks Ambulance {card 0:1}, Incident {card 0:N}InformalDef An ambulance is mobilized for some incident iff a

crew is assigned to it and its destination is the incident’s loca-tion.

DomInvar ∀a: Ambulance, inc: IncidentMobilized (a, inc) ⇔ (∃ cr: Crew) Assigned (cr, a)

∧ a.Dest = inc.Loc

The Crew type might in turn be declared by

4

dnsi-s.ind,ra-

dri-ls

le

ga--c-toin

ys-ro-nts

mayry

toa

sta-al”t

tion

av-see

nsi-ro-oale

rs;

Agent CrewHas Free: Boolean, Paramedics: Boolean ...

In the declarations above,Loc is declared as an attribute ofthe entity Ambulance (this attribute was used in the formaldefinition of the goalAmbulanceMobilization); Free is declaredas an attribute of the agentCrew.

As mentioned earlier, operations are specified formally bypre- and postconditions in the state-based style [Pot91], e.g.,

Operation MobilizeInput Incident {arg inc}Outpu t Ambulance {res amb}, MobilizedDomPre ¬ (∃ a: Ambulance) Mobilized (a, inc)DomPost Mobilized (amb, inc)

Note that the invariant defining theMobilized relationship isnot a requirement, but a domain property; it specifies whatbeing mobilized does precisely mean in the domain. The pre-and postcondition of the operationMobilize above are domainproperties as well; they capture corresponding elementarystate transitions in the domain, namely, from a state whereno ambulance is mobilized to a state where some ambulanceis mobilized. The software requirements are found in the ter-minal goals assigned to agents in the software-to-be, and inthe additional pre-, post-, and trigger conditions that need tostrengthen the corresponding domain conditions in order toensure all such goals [Dar93, Dar95]. Assuming theAmbu-lanceMobilization goal is assigned to the dispatching softwareone would derive from the above formal assertion for thatgoal:

Operation Mobilize...RequiredPre for AmbulanceMobilization:

Available (amb) ∧ TimeDist (amb.Loc, inc.Loc) 11RequiredTrig for AmbulanceMobilization:

■≤3m (∃ cl: Call) Responded (cl) ∧ About (cl, inc)

The trigger condition captures an obligation to trigger theoperation as soon as the condition gets true and provided thedomain precondition is true. The specification will be consis-tent provided the trigger condition and required precondi-tions are together true in the operation’s initial state.

2.3 The elaboration method

Figure 1 outlines the major steps that may be followed toelaborate KAOS specifications from high-level goals. (Sec-tion 4 will discuss how obstacle analysis enter into this pro-cess model.)

• Goal elaboration:elaborate the goalAND/OR structure bydefining goals and their refinement links until assignablegoals are reached. The process of identifying goals, defin-ing them precisely, and relating them through refinementlinks is in general a combination of top-down and bottom-up subprocesses [Lam95]; offspring goals are identified byasking HOW questions about goals already identifiedwhereas parent goals are identified by askingWHY ques-tions about goals and operational requirements alreadyidentified.

• Object capture:identify the objects involved in goal for-mulations, define their conceptual links, and describe theirdomain properties by invariants.

• Operation capture:identify object state transitions that are

meaningful to the goals. Goal formulations refer to desireor forbidden states that are reachable through state trations; the latter correspond to applications of operationThe principle is to specify such state transitions as domapre- and postconditions of operations thereby identifieand to identify the agents that could perform these opetions.

• Operationalization: derive strengthened pre-, post, antrigger conditions on operations, and strengthened invaants on objects, in order to ensure that all terminal goaare met. A number of formal derivation rules are availabto support the operationalization process [Dar93].

• Responsibility assignment:(a) identify alternative respon-sibilities for terminal goals; (b) make decisions amonrefinement, operationalization, and responsibility alterntives, so as to reinforce non-functional goals [Myl92] -e.g., goals related to reliability, performance, cost redution, load reduction, and so on; (c) assign the operationsagents that can commit to guarantee the terminal goalsthe alternatives selected. The boundary between the stem and its environment is obtained as a result of this pcess, and the various terminal goals become requiremeor assumptions depending on the assignment made.

The steps above are ordered by data dependencies; theybe running concurrently, with possible backtracking at evestep.

3. GOAL OBSTRUCTION BY OBSTACLES

This section formally defines obstacles, their relationshipgoals, and their refinement links; a criterion is provided forset of obstacles to be complete; a general taxonomy of obcles is then suggested. In the sequel, the general term “gowill be used indifferently for a high-level goal, a requiremenassigned to an agent in the software-to-be, or an assumpassigned to an agent in the environment.

3.1 Obstacles to goals

Semantically speaking, a goal defines a set of desired behiors, where a behavior is a temporal sequence of states (Section 2.2). A positive scenario is a sequence of state trations, controlled by corresponding agent instances, that pduces such a desired behavior (see Section 2.1). Grefinement yields sufficient subgoals for the goal to bachieved.

Likewise, an obstacle defines a set of undesirable behavio

goal elaboration

object/operation capture

goal operationalization

responsibility assignment

data dependency

Figure 1 - Goal-oriented requirements elaboration

5

nt

-

ci-os-ble

:

s

el-ar,5]

rn

arenvi-

or

cles

eeris

alid

a negative scenario produces a behavior in this set. Goalobstruction yields sufficient obstacles for the goal to be vio-lated; the negation of such obstacles yields necessary pre-conditions for the goal to be achieved.

Let G be a goal andDom a set of domain properties. AnassertionO is said to be anobstacleto G in Dom iff the fol-lowing conditions hold:

1. {O, Dom} |= ¬ G (obstruction)

2. {O, Dom} | false (domain-consistency)

Condition(1) states that the negation of the goal is a logicalconsequence of the theory comprising the obstacle specifica-tion and the set of domain properties available; condition(2)states that the obstacle may not be logically inconsistent withthe domain theory. Clearly, it makes no sense to reason aboutobstacles that are inconsistent with the domain. In terms ofbehaviors, the consistency condition is semantically equiva-lent to

2’. There exists a scenarioS producing a behaviorHsuch that H|= O (feasibility)

This condition now states that the obstacle specification issatisfiable through one behavior at least, produced by a(domain-consistent) scenario of agent cooperation.

As a first simple example, consider a library system and thefollowing high-level goal stating that every book requestshould eventually be satisfied:

Goal Achieve [BookRequestSatisfied]RefinedTo SatisfiedWhenAvailable, CopyEventuallyAvailable,

RequestPending

FormalDef ∀ bor: Borrower, b: BookRequesting (bor, b)⇒ ◊ (∃ bc: BookCpy) [Copy (bc, b) ∧ Gets (bor, bc)]

An obstructing obstacle to that goal might be specified bythe following assertion:

∃ bor: Borrower, b: Book◊ { Requesting (bor, b)

∧ ❑ (∀ bc: BookCpy) [Copy (bc, b) ⇒ ¬ Gets (bor, bc)] }

Condition(1) trivially holds as the assertion amounts to thenegation of the goal (remember thatP ⇒ Q iff ❑ (P → Q), and¬ ❑ (P → Q) iff ◊ (P ∧ ¬ Q)). This obstructing assertion is satis-fiable, e.g., through the classical starvation scenario [Dij71]in which, each time a copy of a requested book becomesavailable, this copy gets borrowed in the next state by a bor-rower different from the requesting agent.

To further illustrate the need for condition(2), consider thefollowing goal for some device control system (expressed inpropositional terms for simplicity):

Running ∧ PressureTooLow ⇒ AlarmRaised

It is easy to see that condition(1) would be satisfied by thecandidate obstacle

PressureTooLow ∧ Startup ⇒ ¬ AlarmRaised∧ ◊ [ Running ∧ PressureTooLow ∧ Startup]

which logically entails the negation of the goal above; how-ever this candidate is inconsistent with the domain propertystating that the device cannot be both in startup and runningmodes:

Running ⇒ ¬ Startup

Note that the above definition of an obstructing obstacle

allows for the same obstacle to obstruct several differegoals; examples of this will be seen later on in the paper.

It is also worth noticing that, sinceAchieve/Cease andMain-tain/Avoid goals all have the general form❑ GC, an obstacleto such goals will always have the general form◊ OC; in thesequel,GC andOC will be called goal and obstacle condition, respectively.

3.2 Completeness of a set of obstacles

Given some goal formulation, defensive requirements spefication would require as many meaningful obstacles as psible to be identified for that goal; completeness is desira-at least for high-priority goals such as, e.g.,Safety goals.

A set of obstacles O1, ..., On to goal G in Dom isdomain-complete with respect to G iff the following condition holds

{¬ O1, ..., ¬ On, Dom} |= G (domain-completeness)

This condition intuitively means that if none of the obstaclein the set may occur then the goal is satisfied.

It is most important to note that completeness is a notion rative to what is known about the domain. To make this clelet us consider the following example introduced in [Jac9after a real plane incident. The goal

MovingOnRunway ⇒ ReverseThrustEnabled

can be AND-refined, using the milestone refinement patte[Dar96], into two subgoals:

MovingOnRunway ⇒ WheelsTurning (Ass)

WheelsTurning ⇒ ReverseThrustEnabled (Rq)

The second subgoal is a requirement assigned to a softwagent; the first subgoal is an assumption assigned to an eronment agent. AssumptionAss will be violated iff

◊ (MovingOnRunway ∧ ¬ WheelsTurning) (N-Ass)

Assume now that the following necessary conditions fwheels to be turning are known in the domain:

WheelsTurning ⇒ WheelsOut (D1)

WheelsTurning ⇒ ¬ WheelsBlocked (D2)

WheelsTurning ⇒ ¬ Aquaplaning (D3)

The following obstacles can then be seen to obstructAssinthat domain since each of them then entailsN-Ass:

◊ (MovingOnRunway ∧ ¬ WheelsOut) (O1)

◊ (MovingOnRunway ∧ WheelsBlocked) (O2)

◊ (MovingOnRunway ∧ Aquaplaning) (O3)

In order to check the domain completeness of these obstawe take their negation:

MovingOnRunway ⇒ WheelsOut (N-O1)MovingOnRunway ⇒ ¬ WheelsBlocked (N-O2)

MovingOnRunway ⇒ ¬ Aquaplaning (N-O3)

Back to the definition of domain-completeness one can sthat the set of obstacles {O1, O2, O3} will be complete onot dependent on whether or not the following propertyknown in the domain:

MovingOnRunway∧ WheelsOut ∧ ¬ WheelsBlocked ∧ ¬ Aquaplaning (D4)⇒ WheelsTurning

Obstacle completeness thus really depends on what vproperties are known in the domain.

6

ub-

e

-

chry.inro-

as

s,t

n-ve

tionheres-r,ndr-eof

foreu-l-oncoredto

enttion

nda-

edletond

deleer-

yns.

cir-or

3.3 Obstacle refinement

Like goals, obstacles may be refined.AND-refinement linksmay relate an obstacle to a set of subobstacles (called refine-ment); this means that satisfying the subobstacles in combi-nation is a sufficient condition in the domain for satisfyingthe obstacle.OR-refinement links may relate an obstacle toan alternative set of refinements; this means that satisfyingone of the refinements is a sufficient condition in the domainfor satisfying the obstacle. The obstacle refinement structurefor a given goal may thus be represented by anAND/ORdirected acyclic graph.

A set of obstacles O1, ..., On is an AND-refinementof anobstacle O iff the following conditions hold:

1. {O1 ∧ O2 ∧... ∧ On, Dom} |= O (entailment)

2. {O1 ∧ O2 ∧... ∧ On, Dom} | false (consistency)

In general one is interested in minimal AND-refinements, inwhich case the following condition has to be added:

3. for all i: {∧j iOj, Dom} | O (minimality)

A set of obstacles O1, ..., On is anOR-refinementof an obsta-cle O iff the following conditions hold:

1. for all i: {Oi , Dom} |= O (entailment)

2. for all i: {Oi , Dom} | false (consistency)

In general one is interested in complete OR-refinements inwhich case the domain-completeness condition has to beadded:

3. {¬ O1 ∧ .. ∧ ¬ On, Dom} |= ¬ O (completeness)

In the plane landing example above, the set{O1, O2, O3)is acomplete OR-refinement of the higher-level obstacleN-Asswith respect to a domain comprising all properties listed.

One may sometimes wish to consider all disjoint alternativesubobstacles of an obstacle; the following additional condi-tion has to be added in such cases:

4. for all i j: { Oi, Oj, Dom} |= false (disjointness)

Section 5.3 will present a rich set of complete and disjointobstacle refinement patterns.

Chaining the definitions in Sections 3.1 and 3.3 leads to thefollowing straightforward proposition:

If O’ is a subobstacle within an OR-refinement of an obstacleO that obstructs some goal G, then O’ obstructs G as well.

3.4 Classifying obstacles

As mentioned in Section 2.1, goals are classified by type ofrequirements they will drive about the agents concerned. Foreach goal category, corresponding obstacle categories maybe defined. For example,

• Non-satisfaction obstacles are obstacles that obstruct the sat-isfaction of agent requests (that is,Satisfaction goals);

• Non-information obstacles are obstacles that obstruct thegeneric goal of making agents informed about object states(that is,Information goals);

• Inaccuracy obstacles are obstacles that obstruct the consis-tency between the state of objects in the environment andthe state of their representation in the software (that is,Accuracy goals);

• Hazard obstacles are obstacles that obstructSafety goals;

• Threat obstacles are obstacles that obstructSecurity goals.

Such obstacle categories may be further specialized into scategories --e.g.,Indiscretion andCorruption obstacles are sub-categories ofThreat obstacles that obstruct goals in thConfidentiality and Integrity subcategories ofSecurity goals,respectively [Amo94];WrongBelief obstacles form a subcategory of Inaccuracy obstacles; and so on.

Knowing the (sub)category of a goal may prompt a searfor obstructing obstacles in the corresponding categoMore specific goal subcategories will of course resultmore focussed search for corresponding obstacles. This pvides the basis for heuristic identification of obstacles,discussed in Section 5.4.

3.5 Goal obstruction vs. goals divergence

In the context of handling conflicts between multiple goalwe have introduced in [Lam98b] the notion of divergengoals. Goals G1, G2, ..., Gn are said to bedivergentiff thereexists a boundary condition that makes them logically incosistent with each other in the domain considered. We hashown that an obstacle corresponds to a boundary condifor the degenerate case where n=1. As a consequence, tare generic principles common to obstacle identification/reolution and divergence identification/resolution. Howevehandling exceptions to the achievement of a single goal ahandling conflicts between multiple stakeholders’ goals corespond to different problems and foci of concern for threquirements engineer. For example, the above notionscompleteness and refinement are specifically introducedobstacle analysis. The classification of obstacles and the hristic rules for their identification is specific to obstacle anaysis (see Section 5.4). As will be seen below, the commgeneric principles for identification/resolution yield specifiinstantiations and specializations for obstacle analysis. Fexample, the goal regression procedure can be simplifi(see Section 5.1); the completion procedure is specificobstacle analysis (see Section 5.2); obstruction refinempatterns are different from divergence patterns (see Sec5.3).

4. INTEGRATING OBSTACLES IN THE RE PROCESS

First-sketch specifications of goals, requirements aassumptions tend to be too ideal; they are likely to be occsionally violated in the running system due to unexpectagent behavior [Lam95, Pot95]. The objective of obstacanalysis is to anticipate exceptional behaviors in orderderive more complete and realistic goals, requirements aassumptions.

A defensive extension of the goal-oriented process mooutlined in Section 2.3 is depicted in Figure 2. (As in Figur1, the arrows indicate data dependencies.) The main diffence is theobstacle analysis loopintroduced in the upperright part.

During elaboration of the goal graph by elicitation and brefinement, obstacles are generated from goal specificatioSuch obstacles may be recursively refined --see the rightcle arrow in Figure 2. (Section 5 will discuss techniques f

7

alc-as

seingmss-ft-n

ofi-ofede-ee-erde

eAne

s toe-r-on

sis

teept-toer

pe-e

nred

ay

on-

ng-,in

theu-rore

supporting the obstacle identification/refinement process.)

The generated obstacles are resolved which results in a goalstructure updated with new goals and/or transformed ver-sions of existing ones. The resolution of an obstacle may besubdivided into two steps [Eas94]: the generation of alterna-tive resolutions, and the selection of one among the alterna-tives considered. (Section 6 will discuss different operatorsfor resolution generation.)

The new goal specifications obtained by resolution may inturn trigger a new iteration of goal elaboration and obstacleanalysis. Goals obtained from obstacle resolution may alsorefer to new objects/operations and require specific opera-tionalizations.

A number of questions arise from this process model.

• Obstacle identification:From which goals in the goalgraph should obstacles be generated? For some given goal,how extensive should obstacle generation be?

– The more specific the goal is, the more specific itsobstructing obstacles will be. A high-level goal willproduce high-level obstacles which will need to berefined significantly into sub-obstacles in order to iden-tify precise circumstances whose feasibility might beassessed through negative scenarios of agent behavior.It is much easier and preferable to elicit/refine what iswanted than what isnot wanted. We therefore recom-mend that obstacles be identified fromterminal goalsassignable to individual agents.

– The extensiveness of obstacle identification willdepend on the category and priority of the goal beingobstructed. For example, obstacle identification shouldbe exhaustive forSafety or Security goals; higher-pri-ority goals deserve more extensive identification thanlower-priority ones. Domain-specific cost-benefit anal-ysis needs to be carried out to decide when the obstacleidentification process should terminate.

• Obstacle resolution:For some given obstacle, how exten-sive should the generation of alternative resolutions be?For some set of alternative resolutions, how and whenshould a specific resolution be selected?

As will be seen in Section 6, the generation of alternativeresolutions correspond to the application of different strat-egies for resolving obstacles. The strategies include obsta-cle elimination, with substrategies such as obstacle

prevention, goal substitution, agent substitution, godeidealization, or object transformation; obstacle redution; and obstacle tolerance, with substrategies suchobstacle mitigation or goal restoration. (Some of thestrategies have been studied in other contexts of handlproblematic situations --e.g., deadlocks in parallel syste[Cof71]; exceptions and faults in fault-tolerant system[And81, Cri91, Jal94, Gar99]; feature interaction in telecommunication systems [Kec98]; inconsistencies in soware development [Nus96]; or conflicts betweerequirements [Rob97, Lam98b]).– The range of strategies to consider and the selection

a specific strategy to apply will depend on the likelhood of occurrence of the obstacle, on the impactsuch occurrence (in number of goals being obstructby the obstacle), and on the severity of the consquences of such occurrence (in terms of priority of thgoals being obstructed). Risk analysis and domain-spcific cost-benefit analysis need to be deployed in ordto provide a definite answer. Such analysis is outsithe scope of this paper.

– The selection of a specific resolution should not bdone too early in the goal/obstacle analysis process.obstacle identified at some point may turn out to bmore severe later on (e.g., because it then appearalso obstruct new important goals being elicited). Prmature decisions may stifle the consideration of altenatives that may appear to be more appropriate laterin the process [Eas94].

• Goal-obstacle analysis iteration:When should the inter-twined processes of goal elaboration and obstacle analystop?

The goal-obstacle analysis loop in Figure 2 may terminaas soon as the obstacles that remain are considered accable without any resolution. Risk analysis needs againbe carried out together with cost-benefit analysis in ordto determine acceptability tresholds.

Some of the issues above will be addressed in a more scific way for the obstacle analysis of the London AmbulancSystem in Section 7.

5. GENERATING OBSTACLES

According to the definition in Section 3.1, the identificatioof obstacles obstructing some given goal in the considedomain proceeds by iteration of two steps:

(1) Given the goal specification, find some assertion that mobstruct it;

(2) Check that the candidate obstacle thereby obtained is csistent with the domain theory available.

Step (2) corresponds to a classical consistency checkiproblem in logic; it can be carried out using deductive verification techniques (e.g., [Man96], [Owr95]). Alternativelyone may check the satisfiability of the candidate obstaclethe domain by finding out some negative scenario (seefeasibility condition in Section 3.1). This can be done manally [Pot95], with some formal support as shown below, ousing automated techniques based on planning [Fic92]model checking [Hol97, McM93, Jac96]; in the latter cas

goal elaboration

object/operation capture

goal operationalization

responsibility assignment

obstacle identification

obstacle resolution

Fig. 2 - Obstacle analysis in goal-oriented requirements elaboration

8

meantntce.5.3ed

re

esre

a-

r

m

ce

a

en-p

herh (i)eis-

d.

nt

he

some operational model of the system needs to be available.

We therefore concentrate on step(1) and present techniquesfor deriving candidate obstacles whose domain consistency/feasibility needs to be subsequently checked. We succes-sively discuss:

• a formal calculus of preconditions for obstruction,

• the use of formal obstruction patterns to shortcut formalderivations,

• the use of identification heuristics based on obstacle clas-sifications as a cheap, informal alternative to formal tech-niques.

5.1 Regressing goal negations

The first technique is based on the obstruction conditiondefining an obstacle in Section 3.1. Given the goal assertionG, it consists of calculating preconditions for obtaining thenegation¬ G from the domain theory. Every preconditionobtained defines a candidate obstacle. This may be achievedusing a regression procedure which can be seen as a counter-part of Dijkstra’s precondition calculus [Gri81] for declara-tive representations. Variants of this procedure have beenused in AI planning [Wal77], in explanation-based learning[Lam91], and in requirements engineering to identify diver-gent goals [Lam98b]. We first explain the general procedurebefore showing how it can be specialized and simplified forobstacle generation.

Consider a meeting scheduler system and the goal statingthat intended people should participate to meetings they areaware of and which fit their constraints:

Goal Achieve [InformedParticipantsAttendance]

FormalDef ∀ m: Meeting, p: Participant

Intended (p, m) ∧ Informed (p, m) ∧ Convenient (p, m)

⇒ ◊ Participates(p, m)

The initialization step of the regression procedure consists oftaking the negation of that goal which yields

(NG) ◊ ∃ m: Meeting, p: ParticipantIntended (p, m) ∧ Informed (p, m) ∧ Convenient (p, m)∧ ❑ ¬ Participates(p, m)

(Such initialization may already produce precise, feasibleobstacles in some cases, see other examples below.)

Suppose now that the domain theory contains the followingproperty:

∀ m: Meeting, p: Participant

Participates(p, m) ⇒ Holds (m) ∧ Convenient (p, m)

This domain property states that a necessary condition for aperson to participate in a meeting is that the meeting is beingheld and its date/location is convenient to her. A logicallyequivalent formulation is obtained by contraposition:

(D) ∀ m: Meeting, p: Participant

¬ [ Holds (m) ∧ Convenient (p, m) ] ⇒ ¬ Participates(p, m)

The consequent in(D) unifies with a litteral in(NG); regress-ing (NG) through(D) then amounts to replacing in(NG) thematching consequent in(D) by the corresponding antecedent.We have thereby formally derived the following potentialobstacle:

(O1) ◊ ∃m: Meeting, p: ParticipantIntended (p, m) ∧ Informed (p, m) ∧ Convenient (p, m)∧ ❑ [ ¬ Holds (m) ∨ ¬ Convenient (p, m) ]

This obstacle covers two situations, namely, one where someeting never takes place and the other where a participinvited to a meeting whose date/location was first convenieto her is no longer convenient when the meeting takes plaUsing the OR-refinement techniques decribed in Sectionwe will thereby obtain two subobstacles that could be namMeetingPostponedIndefinitely andLastMinuteImpediment , respec-tively. Scenarios satisfying their respective assertion astraightforward in this case.

Assuming the domain theory takes the form of a set of rulA ⇒ C, a temporal logic variant of the regression procedufound in [Lam91] can be described as follows.

Initial step:take O := ¬ G

Inductive step:let A ⇒ C be the domain rule selected,

with C matching some somesubformula L in O whose occurrences in O are all positive;

then µ := mgu (L, C);O := O [L / A.µ]

This procedure relies on the following definitions and nottions:– for a formula schemeϕ(u) with one or more occurrences

of the sentence symbolu, an occurrence ofu is said to bepositive inϕ if it does not occur in a subformula of theform p ↔ q and it is embedded in an even (explicit oimplicit) number of negations;

– mgu (F1, F2) denotes the most general unifier of F1 and F2;– F.µ denotes the result of applying the substitutions fro

unifierµ to F;– F [F1 / F2] denotes the result of replacing every occurren

of F1 in formula F by F2.

The soundness of the regression procedure follows frommonotonicity property of temporal logic [Man92, p.203]:

If all occurrences ofu in ϕ(u) are positive, then(p ⇒ q) → (ϕ(p) ⇒ ϕ(q) )

is valid.

Every iteration in the regression procedure produces pottially finer obstacles to the goal under consideration; it is uto the specifier to decide when to stop, dependent on whetthe obstacles obtained are meaningful and precise enougto easily identify scenarios satisfying them, and (ii) to seappropriate ways of resolving them through strategies dcussed in Section 6.

In the example above only one iteration was performeRegressing obstacle(O1) above further through a domainproperty like

Convenient (p, m) ⇒ m.Date in p.Constraints∧ m.Location in p.Constraints

would have produced finer sub-obstacles to the goalAchieve[InformedParticipantsAttendance], namely, the date being nolonger convenient or the location being no longer conveniewhen the meeting takes place.

Exploring the space of potential obstacles derivable from t

9

n-

to

hature

thsion

sts

in-tore-e

of

if

in

domain theory is achieved bybacktrackingon each domainrule applied to select another applicable one. After havingselected rule(D) in the example above, one could select thefollowing other domain rule stating that another necessarycondition for participation is that the meeting date the partic-ipant has in mind corresponds to the actual date of the meet-ing:

(D’) ∀ m: Meeting, p: ParticipantParticipates(p, m) ⇒ ∃ M: Beliefp(m.Date = M) ∧ m.Date = M

The deonticBeliefag construct in this formalization is oftenused to captureAccuracy goals andInaccuracy obstacles; it islinked to theKnowsag construct by the following property:

Knowsag(P) ≡ Beliefag(P) ∧ P

whereag denotes an agent instance,P a fact, and the KAOSbuilt-in predicateKnowsag(P) means that the truth value ofP

in ag’s local memory coincides with the actual truth value ofP.

Regressing the goal negation(NG) above through property(D’) now yields the following new obstacle:

(O2) ◊ ∃m: Meeting, p: ParticipantIntended (p, m) ∧ Informed (p, m) ∧ Convenient (p, m)∧ ❑ ∀M: ¬ [ Beliefp(m.Date = M) ∧ m.Date = M ]

This obstacle, in theInaccuracy category, could be namedPar-ticipantBelievesWrongDate.

Further backtracking on other applicable rules would gener-ate other obstacles obstructing the goalAchieve[InformedPartic-ipantsAttendance] such as, e.g.,ParticipantNotInformedInTime,InvitationNotKnown, etc.

The examples above exhibit asimplified procedure for gen-erating obstacles toAchieve goals of the form C⇒ ◊ T:

1. Negate the goal, which yields a pattern ◊ ( C ∧ ❑ ¬ T);

2. Find necessary conditions for the target condition T in thedomain theory;

3. Replace the negated target condition in the pattern resultingfrom step 1 by the negated necessary conditions found; eachsuch replacement yields a potential obstacle. If needed, applysteps 2, 3 recursively.

A dual version of this simplified procedure can be used forgoals having theMaintain patterns C⇒ T, C ⇒ ❑ T, or C ⇒

TW N. For the plane landing example in Section 3.2, it geerates the obstacles O1, O2, and O3 to the assumptionAssina straightforward way.

In practice, the domain theory does not necessarily needbe very rich at the beginning. Given a target conditionT in agoal such as C⇒ ◊ T, the requirements engineer mayincre-mentally elicit necessary conditionsfor T by interaction withdomain experts and clients.

To give a more extensive idea of the space of obstacles tcan be generated systematically using this technique, Fig3 shows a goalAND-refinement tree, derived by instantiationof a frequent refinement pattern from [Dar96], together wicorresponding obstacles that were generated by regres(universal quantifiers have been left implicit).

5.2 Completing a set of obstacles

The domain-completeness condition in Section 3.2 suggea procedure for completing a set of obstacles O1, ..., Okalready identified for some goal G.

As noted in Section 3.1, G has the general form❑ GCwhereas Oi has the general form◊ OCi. The completion pro-cedure can be described as follows.

1. Form the complementary assertionO* = ◊ (¬ GC ∧ ¬ OC1 ∧ ... ∧ ¬ OCk);

2. Check the consistency of O* with Dom;

3. If O* is domain-consistent and too unspecific, regress it throughDom or generate subobstacles using refinement patterns, toyield finer obstacles SO* ;

4. If needed, apply steps 1-3 recursively to the SO*’s.

It is easy to check that the the set {O*, O1, ..., Ok} obtainedby Step 1 satisfies the domain-completeness conditionSection 3.2 in which the domain is temporarily not considered. Considering the domain in the next steps allows O*be checked for consistency and refined if necessary. A fquent simplification arises from Step 3 when O* has thform P ∧ P1 and a domain property is found having the formP ⇒ P1. A one-step regression then yieldsO = P.

Back to the plane landing example in Section 3.2, Step 1the completion procedure applied to the assumption

MovingOnRunway ⇒ WheelsTurning (Ass)

and the obstructing obstacles◊ (MovingOnRunway ∧ ¬ WheelsOut) (O1)◊ (MovingOnRunway ∧ WheelsBlocked) (O2)

◊ (MovingOnRunway ∧ Aquaplaning) (O3)

yieldsO∗ = ◊ (MovingOnRunway ∧ ¬ WheelsTurning

∧ WheelsOut ∧ ¬ WheelsBlocked ∧ ¬ Aquaplaning)

This candidate obstacle is inconsistent with the domainproperty(D4) is found inDom (see Section 3.2). If not, fur-ther regression/refinement throughDom should be under-taken to find out more specific causes/subobstacles of O*order to complete the set(O1)-(O3). Such refinement may bedriven by patterns as we discuss now.

5.3 Using obstruction refinement patterns

As introduced in Section 3.3, obstacles may beAND/OR-refined into subobstacles.AND-refinements yield more

Intended (p, m) ⇒ ◊ Participates(p, m)

Intended(p,m)

⇒ ◊ Participates(p,m)

∧ Informed(p,m)∧ Convenient(p,m)

Intended(p,m)⇒ ◊ [ Informed(p,m)

∧ Convenient(p,m)]

Intended(p,m)⇒ ❑ Intended(p,m)

LastMinuteImpedimentParticipantBelievesWrongDateParticipantNotInformedInTimeInvitationNotKnown

◊ ∃m, p:Intended(p,m)

∧ ❑ ¬ Informed(p,m)

◊ ∃m, p:Intended(p,m)

∧ ❑ ¬ Convenient(p,m)

◊ ∃m, p:Intended(p,m)

∧ ◊ ¬ Intended(p,m)

Fig. 3 - Goal refinement and obstacles derived by regression

MeetingPostponedIndefinitely

10

-an

her. In

-

th

eion

goal

d:

“primitive” obstacles, that is, obstacles for which (i) negativescenarios can be found more easily to show their feasibility,and (ii) effective ways of resolving them can be envisionedmore easily. On another hand, domain-completeOR-refine-ments are in general desirable for critical goals; they yield adomain-complete set of alternative subobstacles that can bemade disjoint if necessary.

Section 5.1 already contained examples of obstacle refine-ments. The obstacleLastMinuteImpediment was in fact OR-refined into two alternative subobstacles using the domaintheory, namely, the date being no longer convenientor thelocation being no longer convenient. Figure 3 also shows anexample ofOR-refinement of the obstacle obstructing thegoal in the middle of the goal tree; this obstacle, not explic-itly represented there, has been formallyOR-refined into thetwo subobstacles in the middle (which could be namedMeet-

ingNeverNotified and MeetingNeverConvenient, respectively).The latter subobstacles may be refined in turn. Similarly, theobstacleParticipantBelievesWrongDate that was derived in Sec-tion 5.1 could beOR-refined into alternative subobstacleslike WrongDateCommunicated, ParticipantConfusesDates, etc.

The AND/OR refinement of obstacles may be seen as a for-mal, goal-oriented form of fault-tree analysis [Lev95] orthreat-tree analysis [Amo94]. Such analysis is usually donein an informal way through interaction with domain expertsand clients; our aim here is to derive complete fault/threat-trees formally.

The regression procedure in Section 5.1 is a first technique toachieve this; alternatively, one may use obstacle refinementpatterns to shortcut the formal derivations involved in theregression procedure.

The general principle is similar to goal refinement patterns[Dar96] and divergence detection patterns [Lam98b]. Alibrary of generic refinement patterns is built; each pattern isa refinement tree where the root is a generic assertion to berefined and the leaves are generic refining assertions. Thecorrectness of each pattern is proved formallyonce and forall.

The patterns for goal obstruction are specific in that the rootsof refinement trees are negated goals. The generation of(sub)obstacles to some goal then proceeds by selecting pat-terns whose root matches the negation of that goal, and byinstantiating the leaves accordingly. The requirements engi-neer is thus relieved of the technical task of doing the formalderivations required in Section 5.1. The patterns can be seenas high-level inference rules for deriving finer obstacles.

All obstruction patterns in this paper were proved formallycorrect using the STeP verification tool [Man96]. As we willsee, the notion of correctness is different forAND- andOR-refinement patterns. We discuss them successively.

5.3.1AND-refinement patterns

Figures 4-6 show a sample of frequentAND-refinement pat-terns for obstacles that obstructAchieve andMaintain goals,

respectively.

Theroot assertion in eachAND-tree corresponds to the negation of the goal being obstructed. (Remember that there isimplicit outer ❑-operator in every strong implication; thiscauses the outer◊-operator to appear there.) Theleft childassertion may correspond to a domain property, to anotrequirement/assumption, or to a companion subobstaclethe1-step regression andstarvation patterns, it will typicallycorrespond to a domain rule T⇒ P. In themilestone pattern,it defines a necessary milstoneM for reaching the targetpredicateT. The left child assertion often guides the identification of the subobstacle captured by theright child asser-tion.

Obstacle refinement patterns may thus help identifying bosubobstaclesand domain properties. Also note that the1-step regression pattern in Figures 4 and 6 correspond to thregression procedure in Section 5.1 where only one iteratis performed.

As an example of using thestarvation pattern in Figure 4,consider a general resource management system and the

∀ u: User, r: ResourceRequesting (u, r) ⇒ ◊ Allocated (r, u)

The domain propertyAllocated (r, u) ⇒ ¬ ∃ u’ u: Allocated (r, u’)

suggests reusing thestarvation pattern with instantiations

C: Requesting (u, r)T: Allocated (r, u) , P: ¬ ∃ u’ u: Allocated (r, u’)

The following starvation obstacle has been thereby derive

Fig.4 - AND-refinement patterns for obstacles to the goal C ⇒ ◊ T

◊ (C ∧ ❑ ¬ T)

T ⇒ P ◊ (C ∧ ❑ ¬ P)

(1-step regression)

◊ (C ∧ ❑ [¬ T U ¬ P] )

◊ (C ∧ ❑ ¬ T)

◊ (C ∧ ❑ ¬ M)

(milestone)

C ∧ ◊ T ⇒ (¬ T W M)

◊ (C ∧ ❑ ¬ T)

T ⇒ P

(starvation)

Fig.5 - AND-refinement patterns for obstacles to the goal C ⇒ ❑ T

◊ (C ∧ ◊ ¬ T)

B ⇒ ◊ ¬ T ◊ (C ∧ ◊ B)

(backward chain)

B ⇒ o ¬ T

(1-state back)

◊ (C ∧ ◊ ¬ T)

◊ (C ∧ ◊ B)

Fig. 6 - AND-refinement pattern for obstacles to the goal C ⇒ T W N

(1-step regression)

◊ (C ∧ ( ¬ N U (¬ N ∧ ¬ T)))

B ⇒ ¬ T ◊ (C ∧ ( ¬ N U (¬ N ∧ B)))

11

ind

erer-mnm-the

ne

r-il-re

an-m-

nentlds.

ngnts’ed

◊ ∃ u: User, r: ResourceRequesting (u, r) ∧ ❑ [ ¬ Allocated (r, u)U ∃u’ u: Allocated (r, u’) ]

As an example of using the 1-step regression pattern in Fig-ure 6, consider the LAS ambulance dispatching system[LAS93] and the goal stating that an ambulance allocated toan incident should remain allocated to that incident until ithas arrived at the incident scene. This goal may be formal-ized by

∀ a: Ambulance, inc: IncidentAllocation (a, inc) ⇒ Allocation (a, inc) W Intervention (a, inc)

We know from the domain that an ambulance can be allo-cated to at most one incident at a time:

Allocation (a, inc) ⇒ ¬ ∃ inc’ inc: Allocation (a, inc’)

This property suggests using the 1-step regression patternwith the following instantiations

C: Allocation (a, inc) , T: Allocation (a, inc)

N: Intervention (a, inc) , B: ∃ inc’ inc: Allocation (a, inc’)

The following subobstacle is thereby derived:◊ ∃ a: Ambulance, inc: Incident

Allocation (a, inc)

∧ ¬ Intervention (a, inc) U¬ Intervention (a, inc) ∧ ∃ inc’ inc: Allocation (a, inc’)

This obstacle captures a situation in which an ambulanceallocated to an incident becomes allocated to another inci-dent before its intervention at the first one.

A more extensive set of obstacleAND-refinement patterns isgiven in Tables 1-4. Each table corresponds to a specific kof goal. Each row in a table represents anAND-refinement ofthe negation of the goal associated with the table. The lowa row is in a table, the more specific the corresponding asstion and subobstacle are. The assertions in the first columay represent a domain property, a requirement or a copanion subobstacle. Table 4 may be seen to correspond tobackward construction of a fault-tree from a state machi[Rat96];p andq are intended to be state predicates there.

All AND-refinement patterns in Tables 1-4 were proved corect using STeP [Man96] --by this we mean that the entament and consistency conditions in Section 3.3 weformally verified.

Section 7 will illustrate the use of various patterns fromTables 1-4.

5.3.2 CompleteOR-refinement patterns

Figures 7 shows a pattern for refining the obstruction ofAchieve goalR ⇒ ◊ S into a complete set of disjoint alternative subobstacles (see Section 3.3 for the definition of copleteness and disjointness). The goal negation◊ (R ∧ ❑ ¬ S) isAND-refined into two child nodes; the left child assertiomay be a domain property, an assumption or a requirem(in this case it defines what a milestone is); the right chinode is anOR-node refined into two alternative subobstacle

As an example of using this pattern, consider the meetischeduler system again and the goal stating that participatime/location constraints should be provided if request[Lam95]:

assertion subobstacle

1-step regress S ⇒ P ◊ [ R ∧ ❑ ¬ P ]

S ⇒ P ◊ [ R ∧ ( ¬ SU ❑ ¬ P ) ]

starvation S ⇒ P ◊ [ R ∧ ❑ ( ¬ SU ¬ P ) ]

missing source R ∧ ◊ S ⇒ P ◊ [ R ∧ ¬ P ]

non-persistence

R ∧ ◊ S ⇒ PW S ◊ [ R ∧¬ S U (¬ P∧ ¬ S ) ]

non-persistence

R ∧ ◊ S ⇒PW (P ∧ S)

◊ [ R ∧ ( ¬ SU ¬ P ) ]

milestone R ∧ ◊ S ⇒ ¬ SW M ◊ [ R ∧ ❑ ¬ M ]

blocking B ⇒ ❑ ¬S ◊ [ R ∧ ( ¬ SUl B) ]

substitution S’ ⇒ ❑ ¬ S ∧ ■ ¬ S ◊ [ R ∧ ◊ S’ ]

strengthening R ∧ ◊ S ⇒◊ [P ∧ (PW S)]

◊ [ R ∧ ❑ ¬ P ]

starvation R ∧ ◊ S ⇒◊ [P ∧ (PW S)]

◊ [ R ∧ ( ¬ SU ❑ ¬ P ] ) ]

R ∧ ◊ S ⇒◊ [P ∧ (PW S)]

◊ [ R ∧(¬ SU (¬ S ∧ ❑ ¬ P)) ]

TABLE 1. Patterns of obstacles to the goalR ⇒ ◊ S

assertion subobstacle

1-step regress Q ⇒ C ◊ [ P ∧ ◊ ¬ C ]

backward C ⇒ ◊ ¬ Q ◊ [ P ∧ ◊ C ]

1-state back C ⇒ o ¬ Q ◊ [ P ∧ ◊ C ]

TABLE 2. Patterns of obstacles to the goalP ⇒ ❑ Q

assertions subobstacle

Q ∧ C ⇒ o ¬ Q ,

P ∧ C ⇒ o P◊ [ P ∧ Q ∧ C ]

Q ∧ C ⇒ o ¬ Q ,

¬ P ∧ C ⇒ o P◊ [ ¬ P ∧ Q ∧ C ]

¬ P ∧ C ⇒ o P ,¬ Q ∧ C ⇒ o ¬ Q

◊ [ ¬ P ∧ ¬ Q ∧ C ]

TABLE 3. Patterns of obstacles to the goal❑ (P → Q)

assertion subobstacle

back state p ⇒ o ¬ q ◊ p

TABLE 4. Patterns of obstacles to the goal❑ q

Fig. 7 - OR-refinement pattern for obstacles to the goal C ⇒ ◊ T

◊ (C ∧ ❑ ¬ T)

◊ (C ∧ ❑ ¬ M)

(milestone)

C ∧ ◊ T ⇒ (¬ T W M)

◊ [C ∧ (¬ MUl(M ∧ ❑ ¬ T) ) ]

12

ce-

o ae-le;

for

ctnt,ndi-e,ric

esesillally

is-e

seeti-ralls;ific

m-

e

e

lerg

∀ m: Meeting, p: Participant

ConstraintsRequested (p, m) ⇒ ◊ ConstraintsProvided (p, m)

An obvious milestone condition for a participant to provideher constraints is that a request for constraints is reachingher. This suggests using themilestone pattern in Figure 7with the following instantiations:

C: ConstraintsRequested (p, m) T: ConstraintsProvided (p, m)

M: RequestReaches (p, m)

The milestone pattern then generates the formalized domainproperty

∀ m: Meeting, p: Participant

ConstraintsRequested (p, m) ∧ ◊ ConstraintsProvided (p, m)

⇒ [ ¬ ConstraintsProvided (p, m) W RequestReaches (p, m) ]

together with a complete set of alternative subobstacles tothe goal above:

◊ ∃ m: Meeting, p: Participant

ConstraintsRequested (p, m) ∧ ❑ ¬ RequestReaches (p, m)

or

◊ ∃ m: Meeting, p: Participant

ConstraintsRequested (p, m) ∧

¬ RequestReaches (p, m)Ul

RequestReaches (p, m) ∧ ❑ ¬ ConstraintsProvided (p, m)

The refinement may then proceed further to find out finersubobstacles in each alternative; this will yield causes for arequest not reaching an invited participant and causes for aparticipant not providing her constraints in spite of therequest having reached her, respectively.

These examples suggest thatthe more an obstacle is refinedthe closer one gets to an explicit scenario. Obstacle refine-ment patterns may thus be used for suggesting feasible snarios as well.

A more extensive set of complete and disjointOR-refinementpatterns is given in Tables 5-6. Each table corresponds tspecific kind of goal. Each row in a table represents a refinment of the negation of the goal associated with the tabthe thick vertical line separator represents anAND whereasthe double line separators represent anOR. Some of the pat-terns in these tables will be used in the obstacle analysisthe London Ambulance System in Section 7.

All OR-refinement patterns in Tables 5-6 were proved correusing STeP [Man96] --by this we mean that the entailmeconsistency, disjointness, and domain-completeness cotions in Section 3.3 were formally verified. In the latter casthe formulas in the assertion column were taken as genedomain property forming Dom.

5.4 Informal obstacle identification

Informal heuristics may be used to help identify obstaclwithout necessarily having to go through formal techniquevery time. Although they are easier to deploy, the result wbe much less accurate, and not guaranteed to be formcorrect and complete.

Such heuristics are rules of thumb taking the form: “if thespecification has such or such characteristicsthen considersuch or such type of obstacle to it”. The general principlesomewhat similar in spirit to the use of HAZOP-like guidewords for eliciting hazards [Lev95] or, more generally, to thuse of safety checklists [Jaf91, Som97].

Our heuristics are based on goal/obstacle classifications (Section 3.4), on formal obstruction patterns we have idenfied, and on past experience in identifying obstacles. Geneheuristics are independent of any particular class of goamore specific heuristics are associated with some specclass.

General heuristicsrefer to the KAOS meta-model only (seethe concepts defined in Section 2.1). Here are a few exaples to illustrate the approach.

• If an agent has tomonitor/control someobject in order toguarantee thegoal it is assigned to then consider the fol-lowing types of obstacles:– InfoUnavailable: the necessary information about th

object state is not available to theagent;– InfoNotInTime: the necessary information about th

object state is available too late;– WrongBelief: the necessary information about theobject

state as recorded in theagent’s memory is different fromthe actual state of this object. (In the meeting scheduexample, this heuristics might have helped identifyinobstacles likeParticipantBelievesWrongDate --see Section

assertion obstacle obstacle obstacle

S ⇔ P ∧ Q ◊ [ R ∧ ❑ ¬ P ] ◊ [ R ∧ ❑ ¬ Q] ◊ [ R∧ ◊ P ∧ ◊ Q∧ ❑ ¬ (P ∧ Q) ]

S ⇒ P ◊ [ R ∧ ❑ ¬ P ] ◊ [ R ∧ ◊ P∧ ❑ ¬ S ]

S ⇒ P ◊ [ R ∧¬ SU ❑ ¬ P ]

◊ [ R ∧ ◊ P∧ ❑ ¬ S ]

S ⇒ P ◊ [ R ∧❑ (¬ SU ¬ P)]

◊ [ R ∧◊ (PW(P ∧ S))∧ ❑ ¬ S ]

R ∧ ◊ S⇒ P

◊ [ R ∧ ¬ P ] ◊ [ R ∧ P∧ ❑ ¬ S ]

R ∧ ◊ S⇒ PW S

◊ [ R ∧ ¬ SU(¬ P ∧ ¬ S)]

◊ [ R ∧ PW S∧ ❑ ¬ S ]

R ∧ ◊ S ⇒PW (P∧S)

◊ [ R ∧ ¬ SU¬ P ]

◊ [ R ∧ ❑ ¬ S∧ PW (P∧S) ]

R ∧ ◊ S⇒ ¬ SWM

◊ [ R ∧ ❑ ¬ M ] ◊ [ R ∧ ¬ MU(M ∧ ❑ ¬ S) ]

B ⇒ ❑ ¬ S ◊ [R ∧ ¬ SUB] ◊ [ R ∧ ❑ ¬ S∧ ¬ BW S]

P ⇒ ❑ ¬ S∧ ■ ¬ S

◊ [ R ∧ ◊ P ] ◊ [ R ∧ ❑ ¬ S∧ ❑ ¬ P ]

TABLE 5. Obstacle OR-refinement for the goalR ⇒ ◊ S

assertion obstacle obstacle

Q ⇔ Q1 ∧ Q2 ◊ [ R ∧ ¬ Q1 ] ◊ [ R ∧ ¬ Q2 ]

TABLE 6. Obstacle OR-refinement for the goal❑ (P → Q)

13

n

in7].

y oress

.dofse-n-

sesionme

oflels-inft-e-zeinginal

ednd

nsb-uldher.

y

noay

5.1; for an electronic reviewing process an obstacle likeReviewerBelievesWrongDeadline could be identified in asimilar way.)

TheWrongBelief obstacle class can be further refined intosubclasses such as:– WrongInfoProvided: the necessary information pro-

vided by anotheragent about theobject state is incor-rect (possible refinements for this obstacle are, e.g., toohigh or too low values for anobject attribute);

– InfoCorrupted: the information from the provider hasbeen corrupted by anotheragent;

– InfoOutDated: the information provided to theagent isno longer correct at the time of use;

– InfoForgotten: the information provided to theagent isno longer available at the time of use;

– WrongInference: theagent has made a wrong inferencefrom the information available;

– InfoConfusion: the agent confuses the necessary infor-mation about theobject state with some other informa-tion.

InfoConfusion obstacles can be refined in turn, e.g.,– InstanceConfusion: the agent confuses the necessary

information about theobject state with informationaboutanotherinstance of object within the same class[Pot95];

– ValueConfusion: the agent confuses different valuesfor an attribute of the sameobject;

– UnitConfusion: the agent confuses different units interms of which values of anobject attribute areexpressed.

In the meeting scheduler example, these heuristics mighthave helped identify several obstacles among those derivedformally, e.g., participants confusing meetings or dates,meeting initiators confusing participants which results inwrong people being invited, confusion in constraints, etc. Inan ambulance dispatching system, an obstacle like an ambu-lance going to a wrong place could be identified thereby.

An important specialization ofInfoConfusion obstacles in theaviation domain is ModeConfusion where pilot agentsbecome confused about what the cockpit software agent isdoing; obstacles in this category receive increasing attentionas they have been recognized to be responsible for a signifi-cant number of critical incidents [But98].

• If an agent requires someresource in order to guaranteethegoal it is assigned to then consider obstacles in the fol-lowing categories:ResourceUnavailable, ResourceTooL-ate, ResourceOutOfOrder, WrongResource,ResourceConfusion, and so on.

• If a persistent condition is necessary to reach thetargetcondition from thesource condition in anAchieve goal,then consider an obstacle in which the persistent conditionbecomes false before reaching the target condition.

The latter heuristic rule corresponds to a natural languagerephrasing of themissing persistence pattern in Table 1; itsuggests how similar heuristics can be formulated from theother patterns.

Morespecific heuristicsrefer to goal classifications. Here area few examples.

• If a MessageDeliveredgoal in the Informationgoal categoryis considered,then consider obstacles likeMessageUndeliv-ered, MessageDeliveredAtWrongPlace, MessageDeliveredAt-WrongTime, MessageCorrupted, and so on.

• If agoal being considered is in theStimulusResponse cate-gory, then consider the following types of obstacles:– StimulusIgnored, TooLatePickUp, IncorrectValue, or

StimuliConfused obstacles to the abstract goalStimulus-PickedUp;

– NoResponse, ResponseTooLate, ResponseIgnored, orWrongResponse obstacles to the abstract companiogoalResponseProvided.

Obstacles can also be identified by analogy with obstaclessimilar systems, using analogical reuse techniques [Mas9

6. RESOLVING OBSTACLES

The generated obstacles need to be resolved in some waanother. As discussed in Section 4, the resolution proccovers two aspects: thegenerationof alternative resolutionsand theselectionof one resolution among those identifiedWhich resolution to apply and when to apply it will depenon risk/cost-benefit analysis based on the likelihoodoccurrence of the obstacle and on the severity of its conquences. We will not discuss selection tactics here; we cocentrate on the generation of alternative resolutions.

Such resolutions correspond to differentstrategiesthat maybe applied. They can be classified into three broad clasdependent on whether the obstacle is eliminated (Sect6.1), reduced (Section 6.2), or tolerated (Section 6.3). Soof these strategies have been studied in other contextshandling problematic situations --e.g., deadlocks in paralsystems [Cof71]; exceptions and faults in fault-tolerant sytems [And81, Cri91, Jal94, Gar99]; feature interactiontelecommunication systems [Kec98]; inconsistencies in soware development [Nus96]; or conflicts between requirments [Rob97, Lam98b]. The objective here is to specialisuch strategies to the resolution of obstacles to goals durrequirements engineering, and to make them explicitterms of specification transformation rules in the formframework of temporal logic.

The obstacle resolution process will result in a transformgoal structure, transformed requirements specifications, atransformed domain properties in some cases.

6.1 Obstacle Elimination

Eliminating an obstacle requires one among the conditiodefining an obstructing obstacle in Section 3.1 to be inhiited; the obstruction should be avoided or the obstacle shobe made inconsistent/unfeasible within the domain. Tstrategies below address one of the conditions or the othe

6.1.1 Goal substitution

A most effective way of resolving an obstacle is to identifanalternative goal refinementfor some higher-level goal, inwhich the obstructed goal and obstructing obstacle arelonger present . In the meeting scheduler example, one m

14

be

ta-

e.oltym

eang

ry

n-

:

ned

entthe

st-al.

hatrin-

is,thent:

pt

eliminate the obstacleElectronicAgendaNotMaintained thatobstructs the goalElectronicAgendaUpToDate by choosing analternative refinement for the father goalParticipantsCon-straintsKnown (see Figure 8); the alternative goal refinementconsists in introducing the two companion goalsCon-straintsRequested (under responsibility of the meeting sched-uling software) andConstraintsProvided (still under jointresponsibility of participants and the email system).

Choosing an alternative goal refinement will in general resultin a different design for the composite system.

6.1.2 Agent substitution

Another way of overcoming the obstacle is to consideralter-native agent assignmentsso that the obstacle scenario mayno longer occur. This will in general result in different sys-tem proposals, in which more or less functionality is auto-mated and in which the interaction between the software andits environment may be quite different.

Back to our meeting scheduler example, one might over-come the obstacleParticipantNotResponsive to the goalCon-straintsProvided by assigning the responsibility for that goal tothe participant’sSecretary instead (to overcome subobstaclessuch asEmailNotCheckedRegularly or ParticipantTooBusy), or byassigning the responsibility for the goalParticipantsCon-straintsRequested to the meeting initiator (rather than themeeting scheduling software) --through email, phone calls,etc.

In the electronic reviewing example, one could introduce asoftware agent for checking that no occurrences of thereviewer’s name are found in the review (to overcome theobstacleNonAnonymousReview); a software agent for check-ing destination tables (to overcome the obstacleMessageSent-ToWrongPerson); and so on.

Agent substitution may entail goal substitution and vice-versa.

6.1.3 Obstacle prevention

This strategy resolves the obstruction byadding a new goalrequiring that the obstacle be avoided.

Remember that a goal G has the general form❑ GC whereasan obstacle O to G has the general form◊ OC. To prevent Ofrom being ever satisfied, the followingAvoid goal is thusintroduced:

G*: ❑ ¬ OC

AND/OR refinement and obstacle analysis may thenapplied to the new goal in turn.

Back to our meeting scheduler example, consider the obscle MeetingForgotten that obstructs the goalAchieve [Informed-ParticipantsAttendance] in Figure 3. The prevention strategyyields the new goalAvoid [MeetingForgotten]. The latter maythen be refined into a requirementAchieve [MeetingReminded]under responsibility of the meeting scheduling softwarAnother example of obstacle prevention in a train contrsystem is the introduction of an automatic brake facili(with corresponding goals and agents) to prevent trains froexceeding their speed limit.

It may turn out, after checking with domain experts, that thassertion❑ ¬ OC introduced for obstacle prevention is notgoal/requirement but a domain property that was missifrom the domain theoryDom, making it possible to infer theobstacleO by regression. In such cases the domain theowill be updated instead of the goal structure.

Obstacle anticipationis a substrategy for refining obstacleprevention goals. It is applicable when some persistent codition P can be found such thatP must persist during sometime interval for the obstacle condition OC to become true

OC ⇒ ■≤d P

In such a case, the obstacle prevention goal may be refiby introducing the subgoal

G* : P ⇒ ◊≤d ¬ P

For obstacles toSecurity goals, for example, one might havethe following instantiations:

OC: InformationCorruptedByAgent

P: IntrusionUndetected

Obstacle anticipation patterns may be used when an evcan be identified that necessarily precedes the truth ofobstacle condition.

6.1.4 Goal Deidealization

It is often the case that obstacles are found to obstruct firsketch goal formulations because the latter are too ideSuch goal formulations should then be deidealized so tthey cover the behaviors captured by the obstacle. The pciple is to transform the goalbeing obstructed in order tomake the obstruction disappear.

Let us suggest the technique on an example first.

Consider the obstacleParticipantNotInformedInTime in Figure 3which obstructs the goal

Intended (p, m) ∧ Informed (p, m) ∧ Convenient (p, m)⇒ ◊ Participates(p, m)

The idea is to make the obstructed goal more liberal, thatto weaken it so that it covers the obstacle. In this casegoal weakening is achieved by strengthening its antecede

Intended (p, m) ∧ InformedInTime (p, m) ∧ Convenient (p, m)⇒ ◊ Participates(p, m)

The predicateInformedInTime (p, m) is derived from the corre-sponding obstacle; it requires participants to be keinformed during a time period starting at leastN days beforethe meeting date:

ParticipantsConstraintsKnown

ConstraintsKnownElectronicAgenda Constraints Constraints

ElectronicAgendaNotMaintained

obstructs

Requested ProvidedUpToDate FromAgenda

Fig. 8 - Goal substitution

15

on.

inruc-aseeoin

al

thezeThenthebyerdu-

he

-is

ary).

vi-

area-lye,

omionsue

, oryin

dly

InformedInTime (p, m) ≡ ■≤ (m.Date - Nd) Informed (p, m)

Once this more liberal goal is obtained, the predicates thatwere transformed to weaken the goal are to be propagated inthe goal tree to replace their older version everywhere; thisgenerally results in strengthened brother goals and weakenedhigher-level goals. The result of the change propagation inthe tree shown in Figure 3 will produce a strengthened goalin the middle of the tree, namely,

Intended(p, m) ⇒ ◊ [ InformedInTime (p, m) ∧ Convenient(p, m) ]

The deidealization procedure is similar to the one used forweakening divergent goals [Lam98b]. It is simpler here asonly one goal assertion has to be considered for weakening.The procedure has two steps:

(1) Weaken the goal specification to obtain a more liberal versionthat covers the obstacle. Syntactic generalization operators canbe used here such as adding a disjunct, removing a conjunct,or adding a conjunct in the antecedent of an implication.

(2) Propagate the predicate changes in the goal AND-tree in whichthe weakened goal is involved, by replacing every occurrenceof the old predicates by the new ones.

The cardinality transformations in [Fea93] may be seen as aparticular form of syntactic generalization in step 1 of thissimplified procedure. Step 2 can be done simply by updatingthe instantiations of the goal refinement patterns used tobuild the goal graph, when such patterns have been used[Dar96].

Goal deidealization patternsmay also be used as formalsupport to the deidealization process. Given the obstructedgoal and the obstructing obstacle, they yield deidealized ver-sions of the goal. To illustrate the approach, Table 7 givessome patterns for some of the obstacles from Table 1.

At the end of Section 5.3.1 we considered the resource man-agementAchieve goal

∀ u: User, r: ResourceRequesting (u, r) ⇒ ◊ Allocated (r, u),

and generated the starvation obstacle◊ ∃ u: User, r: ResourceRequesting (u, r) ∧ ❑ [ ¬ Allocated (r, u)U ∃u’ u: Allocated (r, u’) ]

The goal and starvation obstacle match the last row of Table7; we thereby generate the deidealized goal specification

∀ u: User, r: ResourceRequesting (u, r) ∧ (¬ ∃u’ u: Allocated(r,u’))W Allocated(r,u)⇒ ◊ Allocated (r, u)

The new goal version states thatif the user requests theresource and the resource is subsequently kept unallocatedunless allocated to her/it,then the resource is eventually allo-

cated to her/it. The new conditionPW S that strengthens theantecedent has to be propagated into the goalAND-tree. Thegoals that refer to this new predicate as target conditimight be operationalized through a reservation procedure

6.1.5 Domain transformation

This strategy consists in transforming the domain withwhich the software-to-be operates so as to make the obsttion disappear. The set of domain properties is modified soto make the obstacle either inconsistent with the domain (sthe domain-consistency condition in Section 3.1) or nlonger obstructing the goal (see the obstruction conditionSection 3.1).

As an illustration of the first case, consider the goAchieve[AllocatedAmbulanceMobilized] in an ambulance dis-patching system. One obstacle to this goal corresponds tosituation where an ambulance crew decides to mobilianother ambulance than the one allocated by the system.domain property making this possible is that mobilizatioorders received by crews at ambulance stations mentionincident location. The obstacle can then be eliminatedtransforming the mobilization order so that it does no longmention the incident location; the latter information woulthen be provided by a mobile data terminal inside the amblance.

As an illustration of the second case, we can prevent tobstacle InconvenientLocation from obstructing the goalInformedParticipantsAttendance in the meeting scheduler system by transforming the domain so that videoconferencingmade possible; the conjunctm.Location in p.Constraints wouldthen be dropped from the domain property stating necessconditions for meetings to be convenient (see Section 5.1

6.2 Obstacle Reduction

The difference between this class of strategies and the preous one is that here one tries toreduce the occurrences of theobstacle instead of eliminating them completely.

Strategies that act on the motivation of human agentsinstances of this class. The principle is to reduce the situtions in which an agent acts abnormally or irresponsibeither by dissuasion or by providing rewards. For instancmany library systems issue fines to dissuade borrowers frlate returns; insurance systems provide premium reductfor good customers; some transportation companies isrewards for crews arriving on time; and so on.

6.3 Obstacle Tolerance

In cases where the obstacle cannot be thoroughly avoidedwhere avoiding it is simply too costly or not worthy, one maspecify which behaviors will be admissible or toleratedthe presence of the obstacle.

6.3.1 Goal restoration

A first strategy consists ofadding a new goalstating that ifthe obstacle conditionOC becomes true then the obstructegoal assertionG should be satisfied again in some reasonabnear future. This new goal thus takes theAchieve form

G*: OC ⇒ ◊ G

This strategy could be followed for the obstaclePaperLost

goal obstacle deidealized goal

R ⇒ ◊ S ◊ [ R ∧ ¬ P ] R ∧ P ⇒ ◊ S

R ⇒ ◊ S ◊ [ R ∧ ❑ ¬ P ] R ∧ (PW S) ⇒ ◊ S

R ⇒ ◊ S ◊ [ R ∧ ( ¬ SU ¬ P ) ] R ∧ (PW S) ⇒ ◊ S

R ⇒ ◊ S ◊ [ R ∧ ( ¬ SU ❑ ¬ P ) ] R ∧ ❑ ◊ P ⇒ ◊ S

R ⇒ ◊ S ◊ [ R ∧ ❑ ( ¬ SU ¬ P ) ] R ∧ ◊ (P W (P∧S))⇒ ◊ S

TABLE 7. Deidealization patterns for Achieve goals

16

sig-at-ny

ar-cle

o-

ni-

the

d

nddra-alsng

cyc-

endnalm

naln,5

lesed2.red

t)edte-

-

to

that obstructs the goalAchieve[ReviewReturned]. A subgoalrefining the restoration goal will beAchieve[LostPaperResent].

6.3.2 Obstacle mitigation

Another alternative strategy to obstacle elimination is to seekeffective ways of mitigating the consequences of the obsta-cle. The principle is toadd a new goalto attenuate theeffects of obstacle occurrences. Two forms of mitigation canbe distinguished.

Weak mitigationconsists in ensuring some weakened versionG’ of the obstructed goal G whenever the obstacle conditionOC becomes true. A weak mitigation goal thus has the form

G*: OC ⇒ G’

where G’ is a deidealized version of G obtained using thespecification transformations described in Section 6.1.4.

To illustrate this, consider the obstacleLastMinuteImpedimentgenerated in Section 5.1. The introduction of the weak miti-gation goal

Achieve [ImpedimentNotified]

will ensure a weaker version of the goalInformedParticipantsAt-tendance in Section 5.1, namely,

Intended (p, m) ∧ Informed (p, m) ∧ Convenient (p, m)⇒ ◊ [ Participates(p, m) ∨ Excused (p, m) ]

(Note that in this case an obstacle prevention alternative tosuch weak mitigation would yield a goal likeAchieve [Meet-ingReplanned].)

Strong mitigationconsists in ensuring some parent goal G’of G whenever the obstacle condition OC becomes true, inspite of G being obstructed. A strong mitigation goal thushas the form

G*: OC ⇒ G’

where the obstructed goal G is a subgoal of G’.

Figure 9 illustrates this on a mine pump system example[Jos95]. The goalAvoid[MinerInOverfloodedMine] strongly miti-gates the obstacleExcessiveWaterFlow that obstructs the goalWaterFlowLimited by guaranteeing that the parent goalAvoid[MinerDrowning] will be satisfied.

The distinction between strong and weak mitigation some-what corresponds, at the requirements engineering level, totwo different, sometimes confused notions of fault tolerance[Cri91]: one where the program meets its specification inspite of faults, and the other where the program meets aweaker version of the specification.

6.3.3 Do-nothing

For non-critical obstacles whose consequences have nonificant impact on the performance of the system a last stregy is of course to tolerate its occurrences without aresolution action.

7. OBSTACLE ANALYSIS FOR A REAL SAFETY-CRITI-

CAL SYSTEM

The purpose of this section is to illustrate and assess the vious techniques presented in this paper through obstaanalysis of a real safety-critical system for which failure stries have been published [LAS93, Fin96].

From the documentation available in the Inquiry Report othe London Ambulance System [LAS93], we reverse engneered the goal graph for this system. We started fromcommonsense, high-level goalIncidentResolved and refined itprogressively. In addition, a number of goals were elicitefrom explicit or implicit formulations in the Inquiry Report.Formalizing goal specifications and domain properties, aapplying formal refinement patterns [Dar96] led us to finout missing goals. Objects and their relationships, opetions, and domain properties emerged gradually as gowere refined. Agents were identified as active objects amothem --the Computer-Aided Despatch software (CAD), theAutomatic Vehicle Location System (AVLS), the resourceallocator (RA), the control assistant who handles emergencalls (CA), the radio operator, the communication infrastruture, the station printer, the mobile data terminal (MDT), andthe ambulance crew. Goal refinement terminated whrequirements assigned to theCAD and assumptions assigneto the agents in the environment were obtained as termigoals. Figures 10-12 in Appendix 1 provide excerpts frothe goal structure. Note the importance ofAccuracy goals(bottom of Figure 10 and Figure 12).

Obstacles were then derived systematically for each termigoal. Many of them were formalized; a mix of regressioobstruction patterns and informal heuristics from Sectionwere used. We then compared the list of potential obstacthereby obtained with the scenarios which actually occurrduring the two system failures in October-November 199While our obstacles cover the various problems that occuduring those failures (notably,Inaccuracy problems), theyalso cover many other problems that could (but did nooccur --see the comparison tables below. Finally we explorthe space of possible resolutions by application of the stragies discussed in Section 6.

7.1 Obstacle generation

Let us illustrate some of the formal derivations first. Consider the terminal goalIncidentResolvedByIntervention appear-ing at level 2 of the goal tree in Figure 9:

Goal Achieve [IncidentResolvedByIntervention]UnderResponsibility AmbulanceCrewRefines IncidentResolvedFormalDef ∀ a: Ambulance, inc: Incident

Intervention (a, inc) ⇒ ◊ Resolved (inc)

Applying the regression procedure, we negate this goalproduce the high-level obstacleIncidentNotResolvedByInterven-tion:

Avoid[MinerDrowning]

Avoid[MineOverflooded]

Avoid[MinerInOverfloodedMine]WaterExtracted WaterFlowLimited

ExcessiveWaterFlowAlarmIssued MinerOutAfterAlarmobstructs

mitigates

Fig. 9 - Obstacle mitigation

17

t

i-

te.)t arefi-herterncence

ec-o

◊ ∃ a: Ambulance, inc: Incident

Intervention (a, inc) ∧ ❑ ¬ Resolved (inc)

We regress this obstacle through domain properties that pro-vides necessary conditions for incident resolution:

Resolved (inc) ⇒(∀ p: Patient) Injured (p, inc) →

(∀ r: Resource) CriticallyNeeds (p, r) →(∃ ru: ResourceUnit) Unit (ru, r) ∧ UsedOn (ru, p)

Resolved (inc) ⇒(∀ p: Patient) Injured (p, inc) →

(∃ h: Hospital) AdmittedAt (p, h)

Regressing the high-level obstacle above through these twodomain properties yields the following two subobstacles:

Obstacle CriticalCareNotGivenToPatientFormalDef ◊ ∃ a: Ambulance, inc: Incident

Intervention (a, inc)∧ ❑ (∃ p: Patient, r: Resource)

Injured (p, inc) ∧ CriticallyNeeds (p, r)∧ ¬ (∃ ru: ResourceUnit) Unit (ru, r) ∧ UsedOn (ru, p)

andObstacle PatientNotAdmittedToHospital

FormalDef ◊ ∃ a: Ambulance, inc: IncidentIntervention (a, inc)∧ ❑ ∃ p: Patient

Injured (p, inc) ∧ (¬ ∃ h: Hospital) AdmittedAt (p, h)

Regressing the first subobstacleCriticalCareNotGivenToPatientthrough the domain property

Intervention (a, inc)∧ Injured (p, inc) ∧ UsedOn (ru, p)

⇒ InAmbulance (ru, a)∧ ¬ ( ∃ p’: Patient) p’ p∧ UsedOn (ru, p’)

yields the new subobstacle:Obstacle InsufficientResourceInAmbulance

FormalDef ◊ ∃ a: Ambulance, inc: IncidentIntervention (a, inc)∧ ❑ ∃ p: Patient, r: Resource

Injured (p, inc) ∧ CriticallyNeeds (p, r)∧ Intervention (a, inc)∧ (∀ ru: ResourceUnit) Unit (ru, r) →

InAmbulance (ru, a) →(∃ p’: Patient) p’ p∧ UsedOn (ru, p’)

By completing this refinement we obtain a new subobstacleto produce a domain-complete set of subobstacles toCritical-CareNotGivenToPatient:

Obstacle AvailableResourceNotUsedOnPatientFormalDef ◊ ∃ a: Ambulance, inc: Incident

Intervention (a, inc)∧ ❑ ∃ p: Patient, r: Resource

Injured (p, inc) ∧ CriticallyNeeds (p, r)∧ Intervention (a, inc)∧ (∃ ru: ResourceUnit) Unit (ru, r) ∧ InAmbulance (ru, a) ∧ ¬ (∃ p’: Patient) p’ p∧ UsedOn (ru, p’)

Further refinement of the latter subobstacle by, e.g., use ofthe heuristics in Section 5.3, yields new subobstacles such asWrongInfoAboutPatient and ResourceOutOfOrder. In the formercase, one might find out that the incident form produced bytheCAD has inaccurate or missing information.

The complete obstacle refinement tree derived is as follows:

IncidentNotResolvedByIntervention← CriticalCareNotGivenToPatient

← InsufficientResourceInAmbulance← WrongInfoAboutIncident← ResourceUnavailable← ResourceConfusion

← AvailableResourceNotUsedOnPatient← WrongInfoAboutPatient← ResourceOutOfOrder

← PatientNotAdmittedToHospital← PatientNotTransportedToHospital

← PatientNotPutInAmbulance← InsufficientAmbulanceCapacity← PatientNotInAvailableAmbulance

← ...← PatientInAmbulanceNotPortedToHospital

← PatientAtHospitalNotAdmitted← NoBedAvailableAtHospital← AvailableBedNotAssigned

This tree amounts to agoal-based fault tree.

Consider now the terminal goalMobilizedAmbulanceInterventionappearing at level 3 of the goal tree in Figure 9:

Goal Achieve [MobilizedAmbulanceIntervention]UnderResponsibility AmbulanceCrewRefines AmbulanceInterventionFormalDef ∀ a: Ambulance, inc: Incident

Mobilized (a, inc) ∧ TimeDist (a.Loc, inc.Loc) 11⇒ ◊≤11m Intervention (a, inc)

This Achieve goal suggests instantiationsR: Mobilized (a, inc) ∧ TimeDist (a.Loc, inc.Loc) 11

S: Intervention (a, inc)

Negating the goal yields a high-level obstacle:Obstacle MobilizedAmbulanceNotInTimeAtDestination

FormalDef ◊ ∃ a: Ambulance, inc: IncidentMobilized (a, inc) ∧ TimeDist (a.Loc, inc.Loc) 11∧ ❑≤11m ¬ Intervention (a, inc)

The non-persistence obstruction patterns in Table 1 suggeslooking for domain properties taking the form

R ∧ ◊ S ⇒ PW (P ∧ S)

which involves a persistent conditionP that must continu-ously hold, from the time ofR to the time ofS, for R to leadto S. Given the instantiations forR andS, two candidatesPare suggested fromR to satisfy the above persistence condtion:

P1: Mobilized (a, inc)

P2: TimeDist (a.Loc, inc.Loc) < TimeDist (a.Loc, inc.Loc)

(The overline notation is used to denote the previous staThese candidates produce two persistence conditions thadomain properties indeed: the former says that if a sufciently close ambulance is mobilized and intervenes at tlocation within 11 minutes, then it remains mobilized fothat location unless it intervenes at the location; the latsays that the time distance between the mobilized ambulaand the destination keeps decreasing unless the ambulaintervenes at the location. We may therefore apply the sond non-persistence pattern in Table 1 to generate the twfollowing obstacles (one for each persistent condition):

Obstacle AmbulanceMobilizationRetractedFormalDef ◊ ∃ a: Ambulance, inc: Incident

Mobilized (a, inc) ∧ TimeDist (a.Loc, inc.Loc) 11∧ (¬ Intervention(a, inc) U≤11m ¬ Mobilized (a, inc))

18

-he

b-

aedar--ers

in

ld-

a-i-Ind a

is-

rns

ingesds-m.

al

-nala-a

andObstacle MobilizedAmbulanceStoppedOrInWrongDirection

FormalDef ◊ ∃ a: Ambulance, inc: IncidentMobilized (a, inc) ∧ TimeDist (a.Loc, inc.loc) 11∧ ( ¬ Intervention(a, inc) U≤11m

TimeDist (a.Loc, inc.Loc) TimeDist (a.Loc, inc.Loc))

(In the above assertions,PU≤dQ stands for forPU Q ∧ ◊≤dP.)

Further refinement of these formal obstacles based on regres-sion, patterns, and heuristics from Section 5 yield the follow-ing obstacleOR-refinement tree:

MobilizedAmbulanceNotInTimeAtDestination← AmbulanceMobilization Retracted

← MobilizedAmbulanceDestinationChanged← LocationConfusedByCrew

← MobilizedAmbulanceDestinationForgotten← AmbulanceMobilizationCancelled

← MobilizedAmbulanceStoppedOrInWrongDirection← AmbulanceStopped← AmbulanceBreakdownOrAccident← AmbulanceStoppedInTraffic

← AmbulanceInWrongDirection← AmbulanceLost

← CrewInUnfamiliarTerritorry← TrafficDeviation

For the terminal goalAmbulanceMobilizedFromPrintedMobOrderappearing as subgoal of the root goalAmbulanceMobilized inFigure 10, the obstacleOR-refinement tree generated usingour techniques is

MobOrderNotTakenByAmbulance← MobOrderIntendedForUnavailableAmbulance← MobOrderIgnored← MobOrderTakenByOtherAmbulance

Many reported failures were in fact caused by inappropriateresolution of the latter subobstacle [LAS93].

We have compared the set of obstacles generated systemati-cally using our techniques, for the goal structure in Figures10-12, with the scenarios which actually occurred during thetwo major system failures in October-November 1992 asreported in [LAS93]. While our obstacles cover the variousproblems that occured during those failures, they also covermany other potential problems that could (but did not) occur.Tables 8-9 in Appendix 2 summarize the obstacles generatedfor the various terminal goals in Figure 10. The tables pro-vide, for each requirement/assumption, the responsible agentassigned to it, the (sub)obstacles derived, and features of thesatisfying scenarios that occurred during the reported systemfailures. Handling those obstacles during goal-orientedrequirements elaboration would have forced requirementsengineers to raise issues whose resolution hopefully wouldhave resulted in making such scenarios (and others) unfeasi-ble.

7.2 Obstacle resolution

We now discuss various resolution strategies from Section 6for some of the obstacles generated.

Let us first consider the obstacleMobOrderTakenByOtherAmbu-lance seen at the end of Section 7.1 to obstruct the goalAmbu-lanceMobilizedFromPrintedMobOrder.

The obstacle mitigationstrategy would result in letting thesystem know that the mobilization order has been taken bythe other ambulance. A mitigation goal is thus introduced to

resolve this obstacle, say,MobilizationByOtherAmbulanceKnown.

This new goal may be refined into two subgoals, namely,MobilizationByOtherAmbulanceSignalledToRadioOperator ,

assigned toAmbulanceCrew, andMobilizationStatusUpdated,

assigned toRadioOperator. (An alternative refinement/assignment would consist in letting the change be signalled to tMDT instead).

The obstacle preventionstrategy would result here in theintroduction of the new goal

Avoid [AmbulanceMobilizedWithoutOrder]

A benefit of applying this strategy here is that the latter sugoal would also contribute to the other goal

Avoid [DuplicateAmbulanceMobilization]

The new prevention goal might be under responsibility ofhuman agent at the station or might be operationalizthrough an automatic system preventing ambulance depture from station if the MDT is not mobilized. Such alternatives have of course to be evaluated by the stakeholdinvolved.

As suggested in Section 6.1.5, thedomain transformationstrategy to resolve the same obstacle would result heretransforming theMobOrder object so that it does not mentionthe incident location anymore; the latter information wouonly be given by theMDT inside the ambulance. (Such resolution would however be quite risky ifMDT‘s are likely tobreak down.)

The goal substitutionstrategy would result in an alternativeoperationalization in which mobilization orders sent to sttions do not prescribe which particular ambulance to moblize but instead leave that decision to ambulance crews.this case, this goes together with an agent substitution andomain transformation (asMobOrder objects no longer havean attribute indicating the target ambulance).

Finally, theobstacle reductionstrategy might consist here intrying to change ambulance crew practice by a reward/dsuasion system.

Another interesting example of obstacle reduction concethe obstacleCrewInUnfamiliarTerritorry refining AmbulanceLost(see Section 7.1). The obstacle reduction consists in dividthe city into geographic divisions and allocating ambulancto incidents within the same division. This policy was founin the original system, abandoned in the “PanLondon” sytem that failed, and restored in the newly designed systeThis corresponds to goal substitution as well; the goalDivi-sionalAmbulanceAllocated is chosen as an alternative to the go(PanLondon)AmbulanceAllocated in Figure 9.

We now illustrate thegoal restorationstrategy. Consider theobstacle

MDTMobOrderIgnored

that appears at the bottom of Table 8 in Appendix 2. A lowlevel restoration goal would be to generate an audible sigto make crews aware of the mobilization order. An alterntive, higher-level resolution would consist in introducinghigher-level restoration goal

19

-edchasot

erd.

onl-is

.

ysan

ner-mereub-lu-

-a-

lvellychls.

or

ro-f

isandp-al

e-e

ulds.

ayof

-

FailedMobilizationRecovered

to resolve the higher-level obstacleAllocatedAmbulanceNotMobilized

This goal would restore the higher-level goalAllocatedAmbu-lanceMobilized through the following goal refinement tree:

FailedMobilizationRecovered← AmbulanceMobilizationKnown

← ...← UnrespondedAllocationRestored

← UnrespondedAllocationSignalled← SignalledUnrespondedAllocReallocated

For theCrewPushWrongButton subobstacle in Table 9, a resto-ration goal under responsibility ofMDT might be to signal anerror if the pushed button is not the one expected.

Finally, we illustrate thegoal deidealizationstrategy on theoverideal goal

∀ a: Ambulance, inc: IncidentMobilized (a, inc) ⇒ ◊ Intervention (a, inc)

The following obstacle was generated by a non-persistencepattern from Table 1:

◊ ∃ a: Ambulance, inc: IncidentMobilized (a, inc)∧ ( ¬ Intervention (a, inc) U Breakdown (a) )

Using the third deidealization pattern in Table 7 we obtainthe weakened version for that goal:

∀ a: Ambulance, inc: IncidentMobilized (a, inc)

∧ ( ¬ Breakdown(a) W Intervention (a, inc) )⇒ ◊ Intervention (a, inc)

The propagation will result in strengthened companion goalslike

∀ inc: Incident, p: PersonReported (inc, p) ⇒

◊ ∃ a: Ambulance, inc: IncidentMobilized (a, inc)∧ ( ¬ Breakdown(a) W Intervention (a, inc) )

to be refined and deidealized in turn.

7.3 Discussion

Many of the technical problems with the LAS were causedby incomplete identification and resolution of obstacles.These problems have to be identified and resolved at require-ments engineering time, not at programming time when it istoo late. The techniques presented in this paper provide for-mal and heuristic support for generating high-level excep-tions and their resolutions in a systematic way. Requirementsengineers can then concentrate their efforts on assessing withstakeholders which resolution is the most appropriate fortheir domain.

Regression and formal patterns were seen to help identifyingnot only obstacles, but also the companion domain proper-ties that are necessary to derive them.

Our experience in using these techniques for the LAS andother systems revealed a number of issues that are worthpointing out.

• For a number of goals, obstacle identification onlyinvolved a small number of regression steps --sometimes itdid not go further than just negating the goal. For example,

the obstacle to the goalAccurateAmbulanceLocationInfo underresponsibility of theAVLS agent was obtained just by negation; regressing this negation further would have requirdetailed knowledge about properties of this agent whiwere unavailable to us. In this case, further regression wanyway not necessary for obstacle resolution since it is nnecessary to know why theAVLS might fail to locateambulances accurately.

• Finer agent granularity requires goals to be refined furthand thus allows more detailed obstacles to be deriveThere is a trade-off here between the level of abstractiof the specification and the level of detail of obstacle anaysis; the finer-grained the agents are, the more RE workrequired, but the more detailed obstacle analysis will be

• Deciding when to stop obstacle refinement is not alwaeasy. The refinement process may be stopped whenadequate resolution can be selected among those geated; the risk and impact of the obstacle should becoacceptable with respect to the cost for resolving it. Moknowledge about the causes of the obstacle, that is, its sobstacles, may result in the generation of better resotions.

• Domain-completeOR-refinement of obstacles as discussed in this paper allows one to stop looking for alterntive obstacles.

• It is often the case that a new goal is introduced to resoseveralobstacles simultaneously; the new goal actuaresolves an obstacle to some higher-level goal whimight be obstructed by the many obstacles to its subgoaFor example, the new goalAvoid[InaccurateAmbAvailability-Info] may resolve both obstaclesInaccurateAmbAvailabilityOn-MDT andEncodedMDTAvailabilityNotTransmitted.

This suggests an heuristics for resolution selection: favresolutionR1 over R2 if at similar costR1 resolves moreobstacles thanR2.

• It is often the case that an obstacle is resolved by the intduction of several new goals --e.g., a combination oreduction, mitigation, and restoration goals.

• Identifying all the goals obstructed by the same obstaclenecessary for assessing the impact of this obstaclethereby for deciding on an appropriate resolution. To suport this, a cause-effect graph could be built from the gorefinement graph, the obstaclerefinement graph, and theobstruction relation.

• A specific combination of multiple obstacles may somtimes increase their individual effects. This was clearly thcase during the two LAS failures. In such cases one shoclearly favor resolutions that address such combination

• Identifying the implications of an obstacle resolution isserious issue. A new goal introduced for resolution maresolve critical obstacle combinations; but it may alsinterfere with other goals in the goal graph. A new cycle oconflict analysis [Myl92, Lam98b] may therefore berequired.

8. RELATED WORK

In order to get high-quality software, it is of upmost impor

20

--teorbut

an-nts-theenton-edta-

cym

is-ol-cledc-ea-ureOnte-areom

edof

aretsnof

s-rs

ged;ofarehengedtheoris

heici-ues-

ankenes,a-thew-ndnd

tance to reason about exceptions and faults during softwaredevelopment. There has been a lot of software engineeringresearch to address this for the later stages of architecturaldesign or implementation.

Rigorous definitions of various concepts underlying excep-tion handling can be found in [Cri95, Gar99] --such as speci-fication, program correctness, exception, robustness, failure,error, fault, fault tolerance, and redundancy. Exception han-dling for modular programs structured as hierarchies of dataabstractions is also discussed in [Cri95], including the issuesof exception detection and propagation, consistent staterecovery, and masking. A failure is defined as a deviationbetween the actual behavior of the system and that requiredby its specification [And81, Gar99]. An error is a part of thesystem state which leads to failure. The cause of an error is afault. The objective of fault-tolerance is to avoid system fail-ures, even in the presence of faults [Jal94], or to preciselydefine the acceptable level of system behavior degradationwhen faults occur, if the former objective is not realizable[Cri91].

The notion of ideal fault-tolerant component provides a basisfor structuring software systems [And81, Ran95]. A systemis viewed as a set of interacting components that receiverequests for services and produce responses. An idealizedfault-tolerant component should in general provide both nor-mal and exceptional responses. Three classes of exceptionalsituations are identified: interface exception, local exceptionand failure exception. Different parts of the system areresponsible for handling each class of exception.

The concepts involved in fault tolerance are put on more for-mal grounds in [Aro93, Gar99]. What is meant for a programto tolerate a certain class of fault is formally defined in[Aro93]. This paper also illustrates how fault-tolerant pro-grams can be systematically verified and designed. A com-positional method for designing programs that toleratemultiple fault classes is described in [Aro98]. The method isbased on the principle of adding detector and corrector com-ponents to intolerant programs in a stepwise and non-inter-fering manner. Various forms of fault-tolerance are discussedin [Gar99]; they are based on whether a program still satis-fies its safety properties, liveness properties, or both. Detec-tion and correction are also discussed there as the two mainphases in achieving fault-tolerance.

In the database area, [Bor85] describes language mecha-nisms for handling violations of assumptions in a database.Using such mechanisms, programs can be designed to detectand handle exeptional facts, or the database can adjust itsconstraints to tolerate the violation.

All the work reviewed above addresses the later phases ofarchitectural design or programming. At those stages, theboundary between the software and its environment has beendecided and cannot be reconsidered; the requirements speci-fications are postulated realistic, correct and complete --which is rarely the case in practice. Empirical studies havesuggested that the problem should be tackled much earlier inthe software lifecycle [Lut93]. Our work follows that recom-mendation by addressing the problem of handling abnormalbehaviors at requirements engineering time. Reasoning atthis stage, in a goal-oriented way, provides much more free-

dom on adequate ways of handling abnormal behaviorslike, e.g., producing more realistic and more complerequirements, and/or considering alternative requirementsalternative agent assignments that achieve the same goalsresult in different system proposals.

There are however clear analogies between exception hdling at program level and obstacle analysis at requiremelevel. The objective of fault-tolerance is to satisfy the program specification despite the presence of faults whereasobjective of obstacle analysis is to satisfy goals despite agfailures. Some of the obstacle resolution strategies are cceptually close to fault-tolerant techniques lifted and adaptto the earlier phase of requirements engineering. The obscle prevention strategy introduces a form of redundanwhere a new goal is introduced to prevent an obstacle frooccurring. The obstacle anticipation substrategy is remincent of the fault detection and resolution phases for fault-terance. (Note, however, that one should not confuse obstaidentification, which is performed at specification time antakes an “external” view on the system, with obstacle detetion which is performed at run-time by agents “inside” thsystem [Fea98].) The goal restoration and obstacle mitigtion strategies also introduce new redundant goals to enshigher-level goals in spite of the occurrence of obstacles.the other hand, there are important obstacle resolution stragies, such as goal substitution and agent substitution, thatspecific to requirements engineering because of the freedstill left.

In their work, de Lemos et al have alsorecognized the nefor moving towards the requirement analysis phase manythe concerns that may arise during later phases of softwdevelopment --particularly, the possibility of system fauland human errors [Lem95, And95]. They propose aapproach based on an incremental and iterative analysisrequirements for safety-critical systems in the context of sytem faults and human errors. Their scheme is similar to ouin that it consists of incrementally and iteratively identifyinthe defects of a requirement specification being elaboratthey use the identified defects to guide the modificationthe specification. However, no systematic techniquesprovided there for generating the possible faults from telaborated requirement specification, and for transformithe requirement specification so as to resolve the identififaults. Another difference is that their scheme is based onprogressive decomposition of system entities while we favgoal refinement. (See also [Ber98] for a comparison of thwork with ours.)

Some work has also been done at specification level. TJSD method [Jack83] already recognized the need to antpate and handle errors at that level. JSD provides techniqfor handling inputs which are not valid for a given specification (such as meaningless inputs or inputs arriving inunexpected order). Jackson also recognized that mistavalid inputs cannot be handled by the proposed techniquas they may require transformation of the whole specifiction, and that such errors should be taken into account inearlier steps of the specification elaboration process. Hoever, no techniques are provided there to anticipate aresolve such errors. Our techniques for generating a

21

ayo-ate

ls

a-ntsutgri-tedtc.ex-ep-ctitificificesns

ci-

-5].oflo-sesta-

linnts-a-enal

s ton-totheies.n-ceionus

dof

3].on,alese-or-gfor

u-

resolving obstacles at the goal level are intended to fill thatvoid.

Many specification languages provide constructs for specify-ing software functionalities separately for normal and abnor-mal cases, and then in combination. The Z logical schemacombination constructs are typical examples of this [Pot96].

Throughout this paper we have tried to convince the readerabout the importance of exception handling at the require-ments engineering level and, more specifically, at the goallevel. Although there are no other formal techniques at thegoal level that we are aware of, there has been a lot of workaddressing the later stages of RE where a detailed opera-tional model of the software is already available (typicallyunder the form of state machine specifications).

For example, the completeness techniques in [Heim96,Heit96] are aimed at checking whether the set of conditionsguarding transitions in a state machine covers all possiblecases.

Model checking techniques generate counterexamples show-ing that a temporal logic specification is violated by a finitestate machine specification [Hol97, McM93]. In the samevein, planning techniques can be used to exhibit scenariosshowing the inconsistency between an abstract property andan operational model [And89, Fic92, Hal98]. One mightexpect such techniques to be able to generate the scenariossatisfying our obstacles as traces that refute a goal assertionconjoined with the domain theory. However, we currentlyenvision two problems in applying these techniques directlyfor our purpose. On one hand, we want to conduct the analy-sis at the goal level for reasons explained throughout thepaper; model checking requires the availability of an opera-tional description of the target system, or of relational speci-fications [Jac96] that do not fit our higher-level formulationof goals in terms of temporal patterns of behaviour. On theother hand, for the purpose of resolution we need to obtain aformal specification of the obstacle rather than an instance-level scenario satisfying it. A derivation calculus on moreabstract specifications seems therefore more appropriate,even though instance scenarios generated by a tool like Nit-pick [Jac96] could provide concrete insights for identifyingobstacles to relational specifications.

Another important stream of work at the operational specifi-cation level concerns the generation of fault trees from adetailed operational model of the system. The technique in[Lev87] generates fault trees from a Petri-net model. Thistechnique has been adapted to generate fault trees from astate machine model expressed in RSML [Rat96, Mod98].Several other techniques have also been proposed to generateother standard hazard analysis models from RSML specifi-cations [Rat96, Mod98]. Those techniques can however beapplied only once a complete operational specification of thesystem has been obtained. Furthermore, a very detailed oper-ational specification of the environment of the system wouldbe needed to identify faults caused in the environment (e.g.,a detailed model of the behavior of human operators). Incontrast, our techniques are intended to be used earlier in therequirements engineering process when a complete specifi-cation of the system is not yet available and alternative sys-tem boundaries are still being explored. It allows obstacles to

be generated from partial declarative specifications that mbe gradually elicited during the obstacle identification prcess. (Note that the generation of fault trees from a stmachine model is similar to a recursive application of our1-state-back obstacle refinement pattern.) Furthermore, goaprovide a precise entry point for starting hazard analysis.

The heuristics proposed in this paper for identifying obstcles are somewhat related in spirit to safety requiremechecklists [Lev95], in that they embed experience aboknown forms of obstruction. General criteria correpondinto such checklists have been identified in [Jaf91]. These cteria cover exceptional circumstances such as unexpecinputs, computer error, environmental disturbances, eGood RE practices also consider checklists that cover unpected inputs, operators errors, and other faults or exctional circunstances [Som97]. Our heuristics are in facloser to HAZOP-like guidewords that can be used to elichazards [Lev95]; such guidewords are made more spechere thanks to our requirements meta-model and specgoal classifications. More formal HAZOP-based techniquhave been proposed for forward propagation of perturbatiofrom input variables to output variables in operational spefications [Ree97].

Our work builds on Potts’ paper which was the first to introduce the notion of obstacle as a dual notion to goals [Pot9Obstacles are identified there by exploration of scenariosinteraction between software and human agents. This expration is informal and based on heuristics (some of thehave been transposed to this paper, see Section 5.4). Obcle resolution is not studied there.

[Sut98] also builds on Potts’ work by proposing additionaheuristics for identifying possible exceptions and errorssuch interaction scenarios --e.g., scenarios in which evehappens in the wrong order, or in which incorrect information is transmitted. Influencing factors such as agent motivtion and workload are also used to help anticipate whexceptions may occur and assign probabilities to abnormevents. Generic requirements are attached to exceptionsuggest possible ways of dealing with the problem encoutered. The heuristics proposed in [Sut98] are close in spiritours; their generic exception handling requirements sharesame general objective as our obstacle resolution strategTheir work is largely informal and centered around the cocept of scenario. This provides little systematic guidancompared with the range of obstacle generation/resoluttechniques that can be precisely defined through rigororeasoning on declarative specifications of goals.

Deontic logics are formalisms that allow one to specify anreason about normal and abnormal situations by meansmodal operators such as permission and obligation [Mey9Such logics have been proposed for system specificatiallowing one to specify what should happen if an abnormsituation occurs [Mai93, Ken93]. However such approachdo not provide any guidance for elaborating the requirments, in particular the requirements dealing with the abnmal situations. In contrast, our approach for resolvinobstacles is based on goals which serve as a rationaleintroducing new requirements to deal with the abnormal sitations.

22

h-ise-oste

ofral,tlethe

m

et,nlini-ne

d-

u-

-gi-

ive”,on

of

A

f

g

fn

The principle of pattern-directed specification and reasoning,as we applied it in [Dar96] for formal goal refinement and inthis paper for obstacle refinement, has gained recent interestin the research community. For example, Dwyer et al discusstheir experience in building and reusing a rich library of tem-poral patterns that codify in high-level terms property speci-fications to be input to analysis tools such as model checkers[Dwy99].

Our initial ideas were presented in [Lam98a] which thispaper significantly expands on --notably, by a full treatmentof obstacle completeness and AND/OR refinement, a muchmore extensive set of patterns, many more heuristics, moreresolution strategies, and the application to a real safet-criti-cal system. We are also investigating an alternative, dynamicapproach in which system deviations from requirements/assumptions are monitored and reconciled at runtime[Fea98].

9. CONCLUSION

In order to get high-quality software, it is of upmost impor-tance to reason about agent behavior during requirementselaboration --not only software agents, but also the agents inthe environment like devices, operators, users, etc. This pointhas been recently reempahsized in the context of require-ments engineering [Rya96].

The key principle underlying this paper is that obstacle anal-ysis needs to be done as early as possible in the requirementsengineering process, that is, at thegoal level. The earliersuch analysis is started, the more freedom is left for resolv-ing the obstacles. Moreover, goals provide a precise entrypoint for starting analysis in a more focussed way like, e.g.,the construction of fault-trees or threat-trees from negatedgoals.

Another important message is our preference for a construc-tive approach to requirements elaboration, over a posteriorianalysis of possibly poor requirements. It is better to con-struct hopefully complete, realistic and achievable require-ments than to correct poor ones. In the process discussed inthis paper, goal-oriented elaboration of requirements andsystematic obstacle analysis proceed hand-in-hand.

Various formal and heuristic techniques were presented forobstacle generation and refinement from goal specificationsand domain properties; the generation of obstacle resolutionsis achieved through various strategies to eliminate, reduce, ortolerate the obstacle. Domain knowledge was seen to play animportant role in some of these techniques; however, as wepointed out, such knowledge can be elicited gradually duringobstacle analysis.

The techniques were applied to a significant safety-criticalsystem for which failures have been reported; this providedsome basis for assessing them and raising important ques-tions and open issues. Our techniques also allowed us to for-mally generate the 17 obstacles informally identified in[Pot95] for the meeting scheduler benchmark [Fea97], plus adozen more. The space of resolutions was even broader.Within a potentially large space of obstacles and resolutions,the requirements engineer has to decide which ones aremeaningful to the system considered and need to receive

careful attention.

When to apply such or such identification/resolution tecnique may depend on the domain, on the application in thdomain, on the kind of obstacle, on the severity of its consquences, on the likelihood of its occurrence, and on the cof its resolution. Much exciting work remains to be donwith those respects.

We hope to have convinced the reader through the varietyexamples given that the techniques proposed are genesystematic, and effective in generating and resolving subobstacles. Our plan is to integrate these techniques inKAOS/GRAIL environment [Dar98] in the near future sothat large-scale experimentation on industrial projects froour tech transfer institute can take place.

ACKNOWLEDGEMENT

The work reported herein was partially supported by th“Communauté Française de Belgique” (FRISCO projecActions de Recherche Concertées Nr. 95/00-187 - Directiogénérale de la Recherche). Warmest thanks are due to CoPotts for insightful discussions and suggestions that orignally triggered this work. Alessandra Russo pointed out aerror in a regression for the London Ambulance System. Ware grateful to the reviewers for helpful comments and feeback.

REFERENCES

[Amo94][And89] E.J. Amoroso, Fundamentals of Computer Secrity. Prentice Hall, 1994.

[And81]T. Anderson and P.A. Lee,Fault Tolerance: Principles andPractice. Prentice Hall, 1981.

[Ant94] A.I. Anton, W.M. McCracken, and C. Potts, "Goal Decomposition and Scenario Analysis in Business Process Reenneering,Proc. CAISE'94, LNCS 811, Springer-Verlag, 1994,94-104.

[And89] J.S. Anderson and S. Fickas, “A Proposed PerspectShift: Viewing Specification Design as a Planning ProblemProc. IWSSD-5 - 5th Intl. Workshop on Software Specificatiand Design, IEEE, 1989, 177-184.

[And95] T. Anderson, R. de Lemos, and A. Saeed, “AnalysisSafety Requirements for Process Control Systems”, inPredict-ably Dependable Computing Systems, B. Randell, J.C. Laprie,B. Littlewood and H. Kopetz (ds.), Springer-Verlag, 1995.

[Aro93]A. Arora and M.G. Gouda, “Closure and Convergence:Foundation of Fault-Tolerant Computing”,IEEE Trans. Soft-ware Eng., vol. 19, no. 11, pp. 1015- 1027, 1993.

[Aro98] A. Arora and S. Kulkarni, “Component Based Design oMultitolerant Systems”,IEEE Trans. Software Eng., vol. 24,no. 1, pp. 63 - 78, Jan 1998.

[Ber98] D.M. Berry, “The Safety Requirements EngineerinDilemma”, Proc. IWSSD’98 - 9th International Workshop onSoftware Specification and Design, Isobe, IEEE CS Press, April1998.

[Bor85] A. Borgida, “Language Features for Flexible Handling oExceptions in Information Systems”, ACM Transactions oDatabase Systems Vol. 10 No. 4, Dec. 1985, 565-603.

[Bra85] R.J. Brachman and H.J. Levesque (eds.),Readings inKnowledge Representation, Morgan Kaufmann, 1985.

23

e

d

or

nd

n-

g

A

z-c-d

r

.

-

er-”,

s-

t-

M.3.

y

al

:

[But98] R.W. Butler, S.P. Miller, J.N. Potts and V.A. Carreno, “AFormal Methods Approach to the Analysis of Mode Confu-sion”, Proceedings DASC’98 - 17th Digital Avionics SystemsConference, Seattle, November 1998. See also http://shemesh.larc.nasa.gov/fm/fm-now-mode-confusion.html.

[Cof71] E.C. Coffman, M.J. Elphick and J. Shoshani, “SystemDeadlocks”, ACM Computing Surveys, Vol. 3, No. 2, June1971. pp 67-68.

[Cri91] F. Cristian, “Understanding Fault-Tolerant Distributed Sys-tems”,Comm. of the ACM, February 1991.

[Cri95] F. Cristian, “Exception Handling”, in:Software Fault Toler-ance, M.R. Lyu (Ed.), Wiley, 1995.

[Dar91] A. Dardenne, S. Fickas and A. van Lamsweerde, “Goal-Directed Concept Acquisition in Requirements Elicitation”,Proc. IWSSD-6 - 6th Intl. Workshop on Software Specificationand Design, Como, 1991, 14-21.

[Dar93] A. Dardenne, A. van Lamsweerde and S. Fickas, “Goal-Directed Requirements Acquisition”,Science of Computer Pro-gramming, Vol. 20, 1993, 3-50.

[Dar96] R. Darimont and A. van Lamsweerde,“ Formal RefinementPatterns for Goal-Driven Requirements Elaboration” , Proc.FSE’4 - Fourth ACM SIGSOFT Symp. on the Foundations ofSoftware Engineering, San Francisco, October 1996, 179-190.

[Dar98] R. Darimont, E. Delor, P. Massonet and A. van Lamswe-erde, “GRAIL/KAOS: An Environment for Goal-DrivenRequirements Engineering”,Proc. ICSE’98 - 20th Intl. Confer-ence on Software Engineering, Kyoto, April 1998, Vol. 2, 58-62.

[Dij71] E.W. Dijkstra, “Hierarchical Ordering of Sequential Pro-cesses,”Acta Informatica 1, 1971, pp. 115-138.

[Dwy99] M.B. Dwyer, G. S. Avrunin and J.C. Corbett, “Patterns inProperty Specifications for Finite-State Verification”,Proc.ICSE’99 - 21st Intl. Conference on Software Engineering, LosAngeles, May 1999.

[Eas94] S. Easterbrook, “Resolving Requirements Conflicts withComputer-Supported Negotiation”. InRequirements Engineer-ing: Social and Tchnical Issues, M. Jirotka and J. Goguen(Eds.), Academic Press, 1994, 41-65.

[Fea87] M. Feather, “Language Support for the Specification andDevelopment of Composite Systems”,ACM Trans. on Pro-gramming Languages and Systems 9(2), Apr. 87, 198-234.

[Fea93] M. Feather, “Cardinality Evolution in Specifications”,Proc. KBSE’93 - 8th Knowledge-Based Software EngineeringConference, Chicago, September 1993.

[Fea95] M. Feather, “Towards a Derivational Style of DistributedSystem Design”,Automated Software Engineering1(1), 1995,31-60.

[Fea97] M. Feather, S. Fickas, A. Finkelstein and A. van Lamswe-erde , “Requirements and Specification Exemplars”,AutomatedSoftware Engineering Vol. 4 No. 4, October 1997.

[Fea98] M. Feather, S. Fickas, A. van Lamsweerde, and C. Ponsard,“Reconciling System Requirements and Runtime Behavior”,Proc. IWSSD’98 - 9th International Workshop on SoftwareSpecification and Design, Isobe, IEEE CS Press, April 1998.

[Fic92] S. Fickas and R. Helm, “Knowledge Representation andReasoning in the Design of Composite Systems",IEEE Trans.on Software Engineering, June 1992, 470-482.

[Fin96] A. Finkelstein, “The London Ambulance System CasStudy”, Succeedings ofIWSSD8 - 8th Intl. Workshop on Soft-ware Specification and Design, ACM Software EngineeringNotes,September 1996.

[Gar99]F.C. Gartner, “Fundamentals of Fault-Tolerant DistributeComputing in Asynchronous Environment”,ACM ComputingSurveys, Vol. 31, No. 1, March 1999. pp 1-26.

[Gri81] D. Gries, The Science of Programming. Springer-Verlag,1981.

[Hal98] R.J. Hall, “Explanation-Based Scenario Generation fReactive System Models”,Proc. ASE’98, Hawaii, Oct. 1998.

[Heim96] M.P. Heimdahl and N.G. Leveson, “Completeness aConsistency in Hierarchical State-Based Requirements”,IEEETransactions on Software EngineeringVol. 22 No. 6, June1996, 363-377.

[Heit96] C. Heitmeyer, R. Jeffords and B. Labaw, “Automated Cosistency Checking of Requirements Specificatons”,ACMTransactions on Software Engineering and MethodologyVol. 5No. 3, July 1996, 231-261.

[Hol97] G. Holtzman, “The Model Checker SPIN”,IEEE Trans. onSoftware Engineering Vol. 23 No. 5, May 1997, 279-295.

[Jac83] M.A. Jackson,System Development. Prentice Hall, 1983.

[Jac93] M. Jackson and P. Zave, “Domain Descriptions”,Proc.RE’93 - 1st Intl. IEEE Symp. on Requirements Engineerin,Jan. 1993, 56-64.

[Jac95] M. Jackson,Software Requirements & Specifications -Lexicon of Practice, Principles and Pejudices. ACM Press,Addison-Wesley, 1995.

[Jac96] D. Jackson and C.A. Damon, “Elements of Style: Analying a Software Design Feature with a Counterexample Detetor”, Proc. ISTA '96 - Intl. Symp. on Software Testing anAnalysis, ACM Softw. Eng. Notes Vol. 21 No. 3, 1996, 239-249.

[Jaf91] M.S. Jaffe et al., “Software Requirements Analysis foReal-Time Process-Control Systems”,IEEE Transactions onSoftware Engineering, vol. 17, no. 3, March 1991, pp. 241-258

[Jal94] P. Jalote,Fault Tolerance in Distributed Systems, PrenticeHall, 1994.

[Jos95] M. Joseph (ed.),Real-Time Systems: Specification, Verification and Analysis, Prentice Hall, 1995.

[Kec98] D.O. Keck and P.J. Kuehn, “The Feature and Service Intaction Problem in Telecommunication Systems: A SurveyIEEE Trans. on Sofware. Engineering,Special Issue on Manag-ing Feature Interactions in Telecommunication Software Sytems, Vol. 24 No. 10, October 1998, 779-796.

[Kel90] S.E. Keller, L.G. Kahn and R.B. Panara, "Specifying Sofware Quality Requirements with Metrics", in Tutorial: Systemand Software Requirements Enginering, R.H. Thayer andDorfman, Eds., IEEE Computer Society Press, 1990, 145-16

[Ken93] S.J.H. Kent, T.S.E. Maibaum and W.J. Quirk, “FormallSpecifying Temporal Constraints and Error Recovery”,Proc.RE93 - 1st Int. Symp. on Requirements Engineering, San Diego,California, Jan. 1996, pp. 208-215.

[Koy92] R. Koymans,Specifying message passing and time-criticsystems with temporal logic,LNCS 651, Springer-Verlag, 1992.

[Lam91] A. van Lamsweerde, “Learning Machine Learning”, inIntroducing a Logic Based Approach to Artificial Intelligence,

24

ndts

dd

-

nofo.

or

ser-

k

n,

ly-i-

orre

g

,

A. Thayse (Ed.), Vol. 3, Wiley, 1991, 263-356.

[Lam95] A. van Lamsweerde, R. Darimont and P. Massonet, “Goal-Directed Elaboration of Requirements for a Meeting Scheduler:Problems and Lessons Learned”,Proc. RE’95 - 2nd Int. Symp.on Requirements Engineering, York, IEEE, 1995.

[Lam98a] A. van Lamsweerde and E. Letier, “Integrating Obstaclesin Goal-Driven Requirements Engineering”,Proc. ICSE’98 -20th Intl. Conference on Software Engineering, Kyoto, April1998, Vol. 1, 53-63.

[Lam98b] A. van Lamsweerde, R. Darimont and E. Letier, “Man-aging Conflicts in Goal-Driven Requirements Engineering”,IEEE Trans. on Sofware. Engineering,Special Issue on Incon-sistency Management in Software Development, Vol. 24 No.11, November 1998, 908-926.

[Lam98c] A. van Lamsweerde and L. Willemet, “Inferring Declara-tive Requirements Specifications from Operational Scenarios”,IEEE Trans. on Sofware. Engineering,Special Issue on Sce-nario Management, Vol. 24 No. 12, December 1998, 1089-1114.

[LAS93] Report of the Inquiry Into the London Ambulance Ser-vice, February 1993. The Communications Directorate, SouthWest Thames Regional Authority, ISBN 0-905133-70-6.Seealso the London Ambulance System home page, http://hsn.lond-amb.sthames.nhs.uk/http.dir/service/organisation/fea-turs/info.html.

[Lem95] R. de Lemos, B. Fields and A. Saeed, “Analysis of SafetyRequirements in the Context of System Faults and HumanErrors”,Proceedings of the IEEE International Symposium andWorkshop on Systems Engineering of Computer Based Systems.Tucson, Arizona. March 1995. pp. 374-381.

[Lev87] N.G. Leveson and J.L. Stolzy, “Safety Analysis using PetriNets”, IEEE Trans. Software Eng. Vol. 13 No. 3, March 1987,386-397.

[Lev95] N. Leveson,Safeware - System Safety and Computers.Addison-Wesley, 1995.

[Lut93] R. Lutz, “Analyzing Software Requirements Errors inSafety-Critical, Embedded Systems”,Proc. RE93 - 1st Int.Symp. on Requirements Engineering, San Diego, California,Jan. 1996, pp. 126-133.

[Mai93] T. Maibaum, “Temporal Reasoning over Deontic Specifi-cations”, in J. Ch. Meyer and R.J. Wieringa (Eds.),DeonticLogic in Computer Science - Normative System Specification,Wiley, 1993.

[Man92] Z. Manna and A. Pnueli,The Temporal Logic of Reactiveand Concurrent Systems, Springer-Verlag, 1992.

[Man96] Z. Manna and the STep Group, “STeP: Deductive-Algo-rithmic Verification of Reactive and Real-Time Systems”,Proc.CAV’96 - 8th Intl. Conf. on Computer-Aided Verification,LNCS 1102, Springer-Verlag, July 1996, 415-418.

[Mas97] P. Massonet and A. van Lamsweerde, “Analogical Reuseof Requirements Frameworks”, Proc. RE-97 -3rd Int. Symp. onRequirements Engineering, Annapolis, 1997, 26-37.

[McM93] K.L. McMillan, Symbolic Model Checking: An Approachto the State Explosion Problem, Kluwer, 1993.

[Mey85] B. Meyer, “On Formalism in Specifications”,IEEE Soft-ware, Vol. 2 No. 1, January 1985, 6-26.

[Mei93] J. Ch. Meyer and R.J. Wieringa (Eds.),Deontic Logic in

Computer Science - Normative System Specification, Wiley,1993.

[Mod97] F. Modugno, N.G. Leveson, J.D. Reese, K. Partridge, aS.D. Sandys, “Integrated Safety Analysis of RequiremenSpecifications”, Proc. RE-97 -3rd Int. Symp. on RequirementsEngineering, Annapolis, 1997.

[Myl92] J. Mylopoulos, L. Chung and B. Nixon, “Representing anUsing Nonfunctional Requirements: A Process-OrienteApproach”,IEEE Trans. on Sofware. Engineering, Vol. 18 No.6, June 1992, pp. 483-497.

[Myl99] J. Mylopoulos, L. Chung and E. Yu, “From Object-Ori-ented to Goal-Oriented Requirements Analysis”,Communica-tions of the ACM, Vol. 42 No. 1, January 1999, 31-37.

[Nil71] N.J. Nilsson,Problem-Solving Methods in AI, McGraw-Hill, 1971.

[Nus96] B. Nuseibeh “To Be and Not to Be: On Managing Inconsistency in Software Development”,Proc. IWSSD-8 -8th Intl.Workshop on Software Specification and Design, Schloss Velen,1996, 164-169.

[Owr95] S. Owre, J. Rushby, and N. Shankar, "Formal Verificatiofor Fault-Tolerant Architectures: Prolegomena to the DesignPVS", IEEE Transactions on Software Engineering Vol. 21 N2, Feb. 95, 107-125.

[Par95] D.L. Parnas and J. Madey, “Functional Documents fComputer Systems”,Science of Computer Programming,Vol.25, 1995, 41-61.

[Per89] D.E. Perry, “The Inscape Environment”,Proc. ICSE-11,11th Intl. Conf. on Software Engineering, 1989, pp. 2-12.

[Pot95] C. Potts, “Using Schematic Scenarios to Understand UNeeds”,Proc. DIS’95 - ACM Symposium on Designing interactive Systems: Processes, Practices and Techniques, Universityof Michigan, August 1995.

[Pot96] B. Potter, J. Sinclair and D. Till,An Introduction to FormalSpecification and Z. Second edition, Prentice Hall, 1996.

[Ran95]B. Randel and J. Xu, “The evolution of the recovery blocconcept”, in:Software Fault Tolerance, M.R. Lyu (Ed.), Wiley,1995.

[Rat96] V. Ratan, K. Partridge, J.D. Reese and N.G. Leveso“Safety Analysis Tools for Requirements Specifications”,Proc.Compass 96, Gaithersburg, Maryland, June1996.

[Ree97] J.D. Reese and N. Leveson, “Software Deviation Anasis”, Proc. ICSE’97 - 19th Intl. Conference on Software Engneering, Boston, May 1997, 250-260

[Rob89] W. N. Robinson, “Integrating Multiple SpecificationsUsing Domain Goals”,Proc. IWSSD-5 - 5th Intl. Workshop onSoftware Specification and Design, IEEE, 1989, 219-225.

[Rob97] W.N. Robinson and S. Volkov, “A Meta-Model forRestructuring Stakeholder Requirements”,Proc. ICSE19 - 19thInternational Conference on Software Engineering, Boston,May 1997, 140-149.

[Ros77] D.T. Ross and K.E. Schoman, "Structured Analysis fRequirements Definition", IEEE Transactions on SoftwaEngineering, Vol. 3, No. 1, 1977, 6-15.

[Ros92] D.S. Rosenblum, “Towards a Method of Programminwith Assertions”,Proc. ICSE-14, 14th Intl. Conf. on SoftwareEngineering, 1992, pp. 92-104.

[Rub92] K.S. Rubin and A. Goldberg, “Object Behavior Analysis”

25

Communications of the ACM Vol. 35 No. 9, September 1992,48-62.

[Rya96] K. Ryan and S. Greenspan, “Requirements EngineeringGroup Report”, Succeedings ofIWSSD8 - 8th Intl. Workshopon Software Specification and Design, ACM Software Engi-neering Notes, Sept. 1996, 22-25.

[Sae93] A. Saed, R. de Lemos and T. Anderson, “Robust Require-ments Specifications for Safety-Critical Systems”,Proc. SAFE-COMP’93 - 12th Intl. Conf. on Safety, Reliability and Security,Springer-Verlag, 1993.

[Som97] I.Sommerville and P. Sawyer,Requirements Engineering:A Good Practice Guide. Wiley, 1997.

[Sut98] A.G. Sutcliffe, N.A. Maiden, S. Minocha and D. Manuel,“Supporting Scenario-Based Requirements Engineering”,IEEETrans. Software Eng. vol. 24, no. 12, Dec.1998, 1072-1088.

[Wal77] R. Waldinger, “Achieving Several Goals Simultaneously”,in Machine Intelligence, Vol. 8, E. Elcock and D. Michie (Eds.),Ellis Horwood, 1977.

[Yue87] K. Yue, “What Does It Mean to Say that a Specification isComplete?”,Proc. IWSSD-4, Fourth International Workshopon Software Specification and Design, Monterey, 1987.

[Zav97a] P. Zave, “Classification of Research Efforts in Require-ments Engineering”,ACM Computing Surveys, Vol. 29 No. 4,1997, 315-321.

[Zav97b] P. Zave and M. Jackson, “Four Dark Corners of Require-ments Engineering”,ACM Transactions on Software Engineer-ing and Methodology, 1997, 1-30.

26

APPENDIX 1: GOAL STRUCTURE FOR THE LAS SYSTEM

......

IncidentFiled AmbulanceAllocated AllocatedAmbulanceMobilized

IncidentResolved

IncidentRe- AmbulanceIntervention IncidentResolvedByIntervention

NearestAvailableAmbulanceAllocated

NearAmbulanceAvailability

KnownNearestAvailableAmbulanceAllocated

AccurateAmbulanceAvailabilityAndLocationInfo

AccurateAmbulanceLocationInfo AccurateAmbulanceAvailabilityInfo

see fig. 10

......

......

......

......

...... see fig. 11

AmbulanceMobilized MobiliezAmbulanceIntervention

Figure 10: Refinement of the LAS root goal

MobilizationOrderIssuedAtStation

AllocatedAmbulanceMobilizedOnMDT

AmbulanceMobilizedFromOrderOnMDT

AmbulanceMobilizedFromPrintedMobOrder

AccurateAmbulanceAtStationInfo

AllocatedAmbulanceMobilizedAtKnownStation

MobOrderSentToKnownStation

MobOrderTransmittedToStation

ReceivedMobOrderPrintedAtStation

AmbAllocationSentToMDT

AmbAllocationTransmittedToMDT

ReceivedAllocationDisplayedOnMDT

AllocatedAmbulanceMobilized

....

Figure 11: Refinement of the goal AllocatedAmbulanceMobilized

AccurateAmbulanceAvailabilityInfo

AccurateAmbulanceMobilizationInfoAccurateAmbulanceAllocationInfo

AmbulanceMobilizationKnown AmbulanceDeMobilizationKnown

Avoid[UnallocatedAmbulanceMobilized] AllocatedAmbulanceMobilizationAcknowledged

AllocatedAmbMobilzationAcknowledgedOnMDT

MDTMobAckDelivered

ReceivedMobAckRecorded

......

MDTMobAckSent

Figure 12: Refinement of the goal AccurateAmbulanceAvailabilityInfo

27

Table 8: Obstacles to subgoals of the goal Achieve [AllocatedAmbulanceMobilized]

agent goal obstacle Oct/Nov’92 scenario

CAD MobOrderSentToKnownStation

MobOrderNotSent no PSTN line free

MobOrderSentToWrongStation

MobOrderSentToWrongAmbulance

MobOrderSentWithWrongDestination

InvalidMobOrderSent

AmbAllocationSentToMDT

AmbAllocationNotSentToMDT

AmbAllocationSentToWrongMDT

AmbAllocatioSentWithWrongDestination

InvalidAmbAllocationSentToMDT

Communic.Infrastructure

MobOrderTransmittedToStation

MobOrderNotTransmitted radio congestion,radio blackspot

MobOrderDeliveredAtWrongStation

MobOrderCorruptedDuringTransmission→ WrongDestination→ WrongAmbulance→ InvalidMobOrder

AmbAllocationTransmittedToMDT

AmbAllocationNotTransittedToMDT

AmbAllocationTransmittedAtWrongMDT

AmbAllocationCorruptedDuringTransmission→ WrongDestination→ OtherValidMsgDelivered→ InvalidMsgDelivered

StationPrinter

ReceivedMobOrderPrintedAtStation

ReceivedMobOrderNotPrinted

PrintedMobOrderUnreadable

MDT ReceivedAllocationDisplayedOnMDT

ReceivedAllocationNotDisplayedOnMDT

IncorrectDestinationDisplayed

AmbulanceCrew

AmbulaceMobilizedFromPrintedMobOrder

AmbNotMobilizedFromMobOrderAtStation← MobOrderIgnored← AmbNotAt Station← AmbNotAvailable

MobOrderTakenByOtherAmbulance← MobOrderConfuision← AllocatedAmbNotAvailable← AllocatedAmbNotAtStation← established work practice

crews take differentvehicle from thoseallocated by CAD

LocationConfusedByCrew

APPENDIX 2: DERIVED OBSTACLES AND ACTUAL FAILURE SCENARIOS

28

AmbulanceMobilizedFromMobOrderOnMDT

AmbulanceNotMobilizedFromMobOrderonMDT← MDTMobOrderIgnored← CrewNotInAmbulance← AmbulanceNotAvailable

AmbulanceMobilizedWithDifferentDestinationThanMDTDestination← LocationConfusedByCrew← OtherMobilizationDestination

Pending← MDTDestDifferentFrom

DestOnMobOrderAtStation

agent goal obstacle Oct/Nov’92 scenario

AmbulanceCrew

AvoidUnallocated AmbulanceMobilized

MobOrderTakenByOtherAmbulance

crews use differentvehicle

Allocated AmbMobilizationAcknowledgedOnMDT

AmbulanceCrewForgetToAcknowledgeMobilization

crews don’t pressstatus buttons

AmbCrewPushWrongButtonToAcknowledgeMobilization

crews press buttonsin wrong order

MDT MDTMobAckSent MDTMobAckNotSent

MDTSendsOtherMsg

SentMobAckErroneous

Communic.Infrastructure

MDTMobAckDelivered MDTMobAckNotDelivered communicationbottelneck,radio blackspot

MDTMobAckCorrupted

CAD ReceivedMobAckRecorded ReceivedMobAckIgnored failure of system tocatch all data

ReceivedMobAckConfusedWithOtherMsg

ReceivedMobAckRecordedForWrongAmbulance

agent goal obstacle Oct/Nov’92 scenario

Table 9: Obstacles to subgoals of the goal Achieve [AmbulanceMobilizationKnown]

29