Comparing requirements analysis methods for developing reusable component libraries

www.elsevier.com/locate/jss

The Journal of Systems and Software 79 (2006) 273–289

Comparing requirements analysis methodsfor developing reusable component libraries

Alistair Sutcliffe a,*, George Papamargaritis b, Liping Zhao a

a Centre for HCI Design, School of Informatics, University of Manchester, P.O. Box 88, Manchester M60 1QD, UKb BT Exact Technology, Orion Building MLB1/pp12, BT Adastral Park, Martlesham Heath, Ipswich IP5 3RE, UK

Received 5 May 2005; accepted 23 June 2005Available online 15 August 2005

Abstract

Two approaches to requirements modelling are compared—the Domain Theory [Sutcliffe, A.G., 2002. The Domain Theory: Pat-terns for Knowledge and Software Reuse. Lawrence Erlbaum Associates, Mahwah, NJ.] and Problem Frames [Jackson, M., 2001.Problem Frames: Analysing and Structuring Software Development Problems, Pearson Education, Harlow.]—as a means ofdomain analysis for creating a reusable library of software components for constructing telemedicine applications. Experience ofapplying each approach as a domain analysis method to specify abstract components (object system models and Problem Frames)is reported. The two approaches produced detailed specifications although at different levels of abstraction: problems frames werebetter for monitoring, updating and data integrity requirements whereas the Domain Theory proved more useful for task supportand user interface requirements. The lessons learned from using model-based approaches to requirements specification, and theirmerits for creating consistent specifications for reuse libraries, are discussed.� 2005 Elsevier Inc. All rights reserved.

Keywords: Requirements specification; Reuse; Domain analysis; Generic models; Problem frames

1. Introduction

Few methods exist for requirements analysis andspecification of reusable software, in spite of over 20years� interest in software reuse. The current practiceof developing application frameworks (Fayad andJohnson, 2000), product lines, or families of reusablesoftware components is frequently not specified, sodevelopment of new reuse libraries proceeds on an adhoc basis. Even when processes for developing reusablecomponents are given (e.g., Weiss and Lai, 1999;Clements and Northrop, 2001) these supply little guid-ance about the level of abstraction to adopt when

0164-1212/$ - see front matter � 2005 Elsevier Inc. All rights reserved.doi:10.1016/j.jss.2005.06.027

* Corresponding author. Tel.: +44 0 161 200 3315/306 3315; fax: +440 161 306 3324.

E-mail addresses: [email protected] (A. Sutcliffe),[email protected] (G. Papamargaritis).

specifying reusable components. Domain analysis andengineering analysis methods such as FODA (Simosand Anthony, 1998; Vici et al., 1998) tend to be exten-sions of ‘‘vanilla’’ systems analysis and approachrequirements specification simply as an exhaustive exer-cise in identifying and cataloguing functions within aparticular domain. Little advice is given to help the soft-ware engineer determine the granularity or abstractionof components; furthermore, the scope of a domain isleft to the individual�s experience.

The Domain Theory (Sutcliffe and Maiden, 1998;Sutcliffe, 2000, 2002) proposed a more systematic ap-proach to deriving requirements specifications for reuse.It provided a library of generic models and a design forreuse process that have been applied to creating reus-able libraries of components for information retrievalapplications (Sutcliffe and Carroll, 1999; Sutcliffe andDimitrova, 1999; Sutcliffe and Ennis, 2000). However,

274 A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289

the process relied on expert knowledge of the applica-tion area and the Domain Theory models to identifymany components. One motivation for this paper is tosubject the Domain Theory to further testing while alsodeveloping an improved method of domain analysis andcomponent identification.

Problem Frames (Jackson, 2001) provide another setof abstract models by which reusable specifications canbe developed. However, there are few reports of theapplication of Problem Frames in practice (Bray,2002), apart from a recent case study (Hall et al.,2002). Problem Frames share a concern with the Do-main Theory over the nature of dependencies betweenthe real world and the machine which is to be designed.Tracing dependency may therefore provide a good start-ing point for an analytic process by which componentsmight be discovered. A second motivation for this re-search was to compare Jackson�s Problem Frames andconcept of investigating the boundaries between theenvironment and designed components with theDomain Theory requirements specification process.

The paper follows a case study application of theDomain Theory and Problem Frames in a commercialproject to create a reuse library in the CSCW (computersupported collaborative work) area. The paper is struc-tured in four sections. First the Domain Theory and itsanalytic process are described, followed by an intro-duction to the case study domain. This is followed bya report of the case study experience of applying theDomain Theory process and Problem Frames, and theresulting reuse library. Problem Frames and their appli-cation are then described. The second author carried outthe case study as the user of the Domain Theory, whilethe first author was the user of Problem Frames, so theexercise carried out a limited test of the comprehensibil-ity and utility of both theories with novice users. Thepaper concludes with a section on the lessons learnedand a discussion of the research contributions.

1.1. Related work

Domain analysis methods are the conventional ap-proach to developing reuse libraries (Weiss and Lai,1999; Clements and Northrop, 2001) which advocatefunctional decomposition and modelling product linespecification composed of common components andvariation points where specialisations will be introducedduring design by reuse. Jarzabek et al. (2003) employ usecases to specify semi-generic requirements with customi-sation scripts for reservation applications in a domainanalysis method. The approach to separating specifica-tion of stable common parts of a system from thechangeable components was first introduced by Jacksonin his distinction between entities (stable core processes)and functions in Jackson Systems Development (Jack-son, 1983). However, domain analysis methods give

little advice on partitioning systems into components,so reuse libraries with different component granularitiesand boundaries can arise by application of the samemethod to a single problem by different developmentteams. To address the consistency of the componentsproblem, several reuse libraries have been posited atthe requirements specification level. For instance, con-ceptual modelling patterns (Fowler, 1997) describe busi-ness organisational structures with transaction patternsfor accounting applications (sales, money transfer).Taxonomies of Generic Tasks have been described byZhou and Feiner (1998) who focus on tasks associatedwith information visualisation such as comparing, eval-uating, identifying and classifying objects; while Weh-rend and Lewis� (1990) taxonomy covers genericinformation processing tasks with mappings to suitablevisualisations. In knowledge engineering, Generic Taskshave been proposed, such as diagnosis and analysis(Breuker and Van Der Velde, 1994); however, thesetasks record problem-solving processes as templatesfor building expert systems rather than specifyingrequirements to support human activity.

In requirements engineering, reusable requirementswere described by Lam et al. (1997), who proposed aprocess for generalising requirements by parameterisa-tion, and abstraction of functions and data structures.Generic functional requirements were specified assemi-formal structured narratives with parameters thatcould be specialised by adding constraints, objects, ordetails of methods. Tool support for this approachwas developed that provided requirements documenta-tion management with traceability between abstractrequirements and rationale justifying the need in the do-main (Lam et al., 1997). The MRAM method (Mannionet al., 1999) structures requirements for product familiesusing hierarchical decomposition techniques with heu-ristics for identifying dependencies between require-ments that indicate alternative designs and optionalrequirements for different versions. The ERP (EnterpriseResource Plans) literature describes reuse libraries insome detail, and although methods for their applicationin reuse are specified, little detail is given of the processby which ERPs were created in the first place (Kellerand Teufel, 1998), although some clues to the originsof the SAP library can be found in Scheer (1994). Mod-els at the design level of abstraction have been proposedby Shaw (1991), and architectures and components forconstructing generalised software architectures at thesystem level by Harandi and Lee (1991); and in moredetail by Smith (1992), whose reusable components forplanning and scheduling algorithms were derived fromair traffic control domains. The object-oriented patternsin the GOF library (Gamaa et al., 1995) provide solu-tions for design problems with collections of objects;for example, interfacing (Facade), handling polymor-phism (Factory), encapsulation (Proxy), etc.

A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289 275

Component-based development (Levi and Arsanjani,2002) describes goal-oriented processes with responsibil-ity allocation of services in conceptual architecture torequirements. This method for domain analysis andcomposing services was illustrated by creating a frame-work for web e-commerce domains (e.g., sales,brokerage).

2. Overview of the Domain Theory

This section gives a brief description of the DomainTheory. For a more complete description of the theory,the reuse library of models and processes, see Sutcliffe(2002). The models pertinent to the case study in thispaper are illustrated when the case study is explained,and given in the book�s appendix A. The theory pro-poses a component-based ontology composed of fami-lies of generic models describing transaction-orientedproblems, and generic tasks which describe humangoal-oriented activity. In object-oriented parlance, theDomain Theory posits generic models organised in aclass hierarchy of object collaborations, i.e., it is acollection of objects that transform initial states into asingle desired goal state.

The top levels of the tree have been pruned, becausemodels at such high levels of abstraction do not containsufficient knowledge to be informative. The OSM (Ob-ject System Model) hierarchy starts at a meaningful levelwith nine separate trees, or OSM families: Allocationdescribes matching- and broking-style problems: ObjectContainment models transaction processing problems,such as sales order processing, loans, and inventorymanagement; Composition models assembly and manu-

Fig. 1. Object Sensing OSM with as

facture, with its inverse abstraction Decomposition thatdescribes disaggregation; Sensing monitors and detectsproblems; Construction models manufacturing and pro-cesses that change objects; Logistics models movementof goods and messages; Agent Control is for commandand control applications; and Simulation representsdecision support and other interactive modellingapplications.

OSM families can be organised into groups accordingto their interaction with entities in the system environ-ment. System input arrives via an Object Sensing Modelthat detects and interprets events in the world. These canrange from simple validation routines for data entry tocomplex event monitoring and interpretation. ObjectInventory, Accounting Object Transfer, Object Return-ing and Object Allocation all model transactions on con-ceptual entities that correspond to real world entities asthey are sold, purchased, hired, serviced, etc. The outputfrom these models is management information. Anothergroup of OSMs, Object Construction, Composition andDecomposition, model manufacturing systems and areusually associated with an Agent Control OSM thatorganises and plans the operations. The Object Logisticsfamily has a specific purpose in transporting objectsthrough space. Agent Control OSMs directly affect theworld through a device, while Object Simulation repre-sents a modelled world to the user on a VDU or otherdevice.

In a similar manner to OSMs, Generalised Tasksare organised in 11 families: Information Acquisition,Analysis/modelling, Diagnosis, Information Retrieval,Validation/testing, Progress tracking, Planning/schedul-ing, Navigation, Judgement/decision-making, Explana-tion/advising, and Matching. During the specification

sociated generic requirements.

276 A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289

process, Generalised Tasks are specialised to more con-crete examples; for instance, the generalised model ofDiagnosis determines the cause of some malfunction ina system, locating its cause and proposing remedialtreatment, whereas instantiations may vary from medi-cal diagnosis of a patient�s illness to the technical diag-nosis of a fault in a photocopier.

Design rationale and generic requirements are at-tached to each model to provide reusable knowledgethat can be specialised into functional requirements inthe new application, and a checklist of issues that mayrequire in-depth analysis. An example of an OSM withattached generic requirements and design rationale isillustrated in Fig. 1.

The requirements problem draws attention to issuesthat need to be resolved, e.g., detectability of events, suchas the properties of the hardware sensor device that cap-tures events, the range of physical spectrum it is sensitiveto, how it is connected to the external world and thesoftware machine. Fidelity of detection draws attentionto calibrating sensors so they detect significant eventswithout false alarms, while sample frequency explainsthe problem of how often the device needs to sample,given the anticipated frequency distribution of environ-mental events. The requirements problems are linkedeither to generic requirements or design rationale thatprovides trade-off advice related to the problem. Sofidelity of detection is linked to GR2, event filters thatpropose a functional requirement to screen out un-wanted noise; while rare events monitor (GR3) adviseson the trade-off of detecting rare events which may besignificant or so infrequent that they can be discounted.

3. Case study: Component engineering for collaborative

telemedicine applications

We illustrate the process of discovering appropriatereusable components by a case study specification of areuse library for middleware components to supportCSCW applications with a telemedicine reuse librarybuilt on top of it as an application layer. The case studywas part of a research project in BTexaCT Technologiesin the component-based service provision area (Rudkinand Smith, 2000; Rudkin et al., 2001). The businessmotivation was to create a reuse library for CSCWapplications, and also to create a reusable applicationframework for telemedicine. Hence part of the reuse isin the area of middleware network services and part be-longs in an end-user application domain. The problemwas how to partition this problem space when the com-ponents interacted, e.g., end-user interaction in the med-ical domain may have implications for CSCW support.The monitoring service consisted of a set of diagnosticsensors (hardware components) and methods that inter-preted critical patient properties (blood pressure, ECG

signals and temperature) supplied from the sensors.Two scenarios of use were employed to motivate theanalysis as follows:

3.1. Scenario 1. Patient monitoring

Mr. Jones has chronic diabetes and kidney problems.He is in a nursing home waiting for a transplant opera-tion, but his condition needs to be monitored to ensurethat he takes insulin to correct fluctuations in his bloodsugar, and diuretic drugs for his kidney complaint. Attwo-hourly intervals he has to place a small blood sam-ple in a blood-sugar analyser. While he is in bed he isconnected to a heart-rate monitor that also detects hisGSR (Galvanic Skin Response), providing data on hisdiuretic condition. When the monitoring system detectsany deviation from acceptable limits in his blood sugar,blood osmotic pressure or heart rate, the resident nurseis alerted to take appropriate action.

3.2. Scenario 2. Collaborative diagnosis

Three consultants are discussing Mr. Jones� case atdifferent locations. They can inspect X-rays of his kid-neys and pancreas, MR scans of the same, recordingsof ECG electrocardiograms, and his history of bloodsugar and osmotic pressure readings over severalmonths. In addition there is a simulation of various drugtreatments which allows doctors to test different drugcombinations and observe the effects on blood sugarand osmotic pressure over time. The doctors are con-nected by a video conferencing system and can vieweach other and/or the medical data; however, they can-not view all of it at once, so they have to agree whichitems are on a shared display. The consultants reviewMr. Jones� history, then view the MR and X-ray datato decide whether a transplant is necessary in the nearfuture. Some disagreement on this point leads them toinvestigate treatment options. They review a range ofdrug treatment options before agreeing the appropriatecombination to test in the simulation. Once they haveviewed the simulation results they record a commondiagnosis and treatment plan.

4. Domain analysis method

The Domain Theory design process starts by identify-ing the requirements of a new application in order tomatch them to Generic Tasks and object models. Theprocess follows a walkthrough-style analysis and startsby identifying any sub-systems in the application. Thesemay be suggested by geographical distribution, owner-ship by different parts of the organisation, or by locatingwho operates the system. A dual track approach is usedwhich first decomposes the application to discover

A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289 277

OSMs and Generalised Tasks, and secondly tracesdependencies between components following eventthreads. Combination of the top-down and more bot-tom-up event analysis identifies the appropriate set ofabstract models.

The following questions help to discover OSMs orGeneralised Tasks inherent in the system.

• Who or what are the agents that carry out activityand tasks within the system? List the responsibilitiesof the agents. Agent responsibility relationships pointto tasks. Doctors, consultants and nurses are theprincipal agents in the system, with responsibilitiesfor monitoring the patients� health and diagnosingillness, and deciding on treatments.

• Describe goal-oriented activities and the states theyproduce once complete. Activities either attain ormaintain goal states. Most tasks have achievementgoals but monitoring tasks might have maintenancegoals. The system goals are to ensure that the patientremains healthy, or at least that the treatment is suc-cessful and the patient�s condition does not deterio-rate. The goals indicate tasks of monitoring,diagnosis and treatment.

• Describe the agents or objects acted on by the system,and the nature of the state change they undergo. Thepatient agent is changed by the system when treat-ments are carried out. However, doctors and nursesmay act on patients in the real world, so the Agent

NatureNature of Changeof Change

disc

continuous

2D

movement

existence

3D

attributepropertyattribute

value

space

movementtype

fenvironm

discrete

continuous

Monitored ObjectMonitored Object

type of change

discrete

continuous

Fig. 2. Decision tree for discovering sub-c

Control OSM may be appropriate; alternatively, thetreatment may in some sense improve patients� healthso an Object Repair OSM could also be indicated.

• Describe the life histories of the objects changed bythe system and the nature of their change. A decisiontree guides object model identification (see Fig. 2). Ifthe composition of the object is changed in any way,it belongs to the Object Construction family; other-wise, any change in ownership is evaluated. If theobject life history leads to a permanent change thenObject Supply abstraction is indicated; however, ifownership change is temporary then a loan (ObjectHiring) is appropriate; but if a relationship is formedthat could be a precursor of ownership change, thenObject Allocation models reservation, booking andmatching applications. Other possibilities for concep-tual objects are movement across some physical spacein Object Messaging, or being represented to theexternal world in Object Simulation. The patientagent is physical and the initial state can be assumedto be unsatisfactory, so Object Repair is indicated.However, representations of the patient are also dis-played to users (doctors, nurses) in the real worldso Object Simulation may be involved. If these con-ceptual representations are changed in some waythe conceptual Object Construction is implicated.

• Define the boundaries of the real world that needs tobe modelled in the system. The system will interactwith the physical world through sensors and devices;

2D Object Movement Sensing,e.g. ant changes direction

2D Continuous Movement,e.g. ships at sea

Object Property Sensing,e.g. colour in chemical reaction

Continuous Value Sensing,e.g. heart beat monitoring

Continuous Value Sampling,e.g. blood pressure monitoring

Create-Object Instance Monitoring,e.g. any database update

Delete

rete

reeent

2D Constrained Object MovementSensing, e.g. trains in track sectors

3D Continuous, Constrainede.g. air traffic control

Value Sample Sensing, e.g. periodiccheck on group membership

3D Constrained Flexible,e.g. manufacturing cells

lasses in the Object Sensing family.

278 A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289

however, many information systems simply processconceptual representations of their physical counter-parts. The telemedicine domain clearly has a physicalpresence in the patient; however, it also needs a rep-resentation of the patient that is shared between thedoctors, and this information has to be transported,so an Object Messaging model is indicated withObject Simulation and conceptual Object Construc-tion because changes will be made to the model.

• Trace events from their origin in the system environ-ment through the system components to their des-tination, ending in either a data structure update oran event being passed back to the system envi-ronment. Event tracing flows from patients tomonitoring devices and displays; it also flowsbetween doctors and information displays duringconsultation.

4.1. Domain analysis: Patient monitoring

Patient monitoring involves detecting events, so Ob-ject Sensing models are required. Object Repair recordsthe treatment events that help the patient�s conditionand these events will originate from doctors or nurses.Patients will be assigned to nurses/doctors, hence an Ob-ject Allocation model will process input lists of patientsand medical staff. Devices connected to the patient toadminister drugs or other treatments indicate AgentControl models. Information about the patient has tobe transmitted between doctors, indicating ObjectMessaging.

Input events to most systems are processed by an Ob-ject Sensing Model that detects events emanating fromthe real world. In the telemedicine application thereare two possible sources: the patient who is being mon-itored, and one or more doctors who will be diagnosingproblems and initiating treatments. Tracing the ObjectSensing tree sub-classes (see Fig. 2), the best fit is Ob-ject/Agent property sensing since we wish to detect theproperties of the patient such as blood sugar, osmoticpressure, heart rate, etc.

Sensing will be passive as the machine will beresponding to events created by the patient. Require-ments problems indicated by the Object PropertySensing Model are: fidelity of detecting events to avoidfalse alarms; sampling rate and frequency of statechange in the world, to avoid missing rapid changes;interpretation of events and the context of change;and false events caused by oversensitive detectingdevices.

Interpreting events depends on the computer systempossessing a model of the observed phenomenon (i.e.,the patient); however, the accuracy of event interpreta-tion depends on the fidelity and detail contained in thepatient model. This creates further requirements for an

accurate and up-to-date model of the patient, which inturn raises the question of how such a model is updated.This indicates Object Sensing to capture the inputs andObject Construction to update the model.

Generic requirements associated with the OSM areimported into the specification and specialised asfollows:

1. Reliable event detector and interpreter: a non-func-tional requirement which needs to be specialised asa quantifiable target, e.g. the event sensor will detectall patient events within 5 ms and report significantchanges with less that 0.001% errors.

2. Sampling rate control: user interface features to setthe monitoring interval for each variable.

3. Tuning sensing mechanism to eliminate false alarms:controls on the hardware-software interface so deviceevent detection can be customised.

4. Interpreters/filters to eliminate false alarms: ability tochange ranges and pattern recognisers, e.g., heartbeat irregularities.

5. Log file for history analysis of events: raises thequestion of how much data is stored and for howlong, thus implying a requirement for an archiveprocess.

Once incoming events have been detected and inter-preted, the information needs to be distributed to oneor more medical staff who are responsible for the pa-tient�s care. This implies an Object Messaging modelto transport messages to several destinations. In thiscase the associated requirements problems are: band-width and network constraints on throughput; detectionof network congestion; and messages that may get lostor corrupted, indicating requirements to counteractmessage delivery problems. Furthermore, informationwithin the message may be confidential and it certainlyneeds to be secure, so this adds requirements for securetransmission. The generic requirements list for this partof the system is:

1. Access protocol for message transmission, e.g., tokenring, CSMA/CA (Carrier Sense, Multiple Access/Collision Avoidance: the Ethernet protocol).

2. Adaptable route planning to avoid networkcongestion.

3. Error recovery protocols (acknowledge, resend).4. Message preparation and formatting (packet

protocols).5. Message assembly.6. Detecting message loss (packet headers, sequence

codes).

Many of these requirements may be beyond ourimmediate control; however, we can specify a qualityof service that the network provider should supply.

A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289 279

Once the information has been transported to a doc-tor�s or nurse�s workstation it has to be displayed in acomprehensible manner to the user. In Domain Theoryterms this points to an Object Simulation model whichrepresents patient monitoring information in the contextof the patient model, i.e., the danger zone for heart rateis interpreted by reference to an individual patient modelto account for age, general health, etc. So far the domainanalysis has only traced one causal chain of events. Thetelemedicine domain also needs to support the doctor�sactivity in analysing patients� problems from monitoreddata, diagnosing any causes of change and carrying outeffective treatment.

4.2. Domain analysis: diagnostic support

This analysis uses the Domain Theory�s GeneralisedTask models. A decision tree (see Fig. 3) guides the ana-lyst towards appropriate Generalised Tasks, in this caseDiagnostic and Matching to control allocation of usersto collaboration sessions and control for access toshared artefacts.

The generalised model of Diagnosis, derivedfrom Rasmussen (1986), contains sub-goals for monitor-ing and interpreting events, before arriving at a causaldiagnosis for those events (see Fig. 4). The General-ised Task specialises in models for causal diagnosiswith living things, designed artefacts and complexsystems.

pathol

n

commun

sensemaking

understandingcurrent world

acting inthe world

gatheringinformation

need new

fin

monexis

model future

ordering futureworld

fut

futuredecisionfuture

future

Relationship oftask and real world

Fig. 3. Decision tree to iden

Requirements problems include: gathering informa-tion for diagnosis when the signs might not be immedi-ately accessible; structuring facts to create a model ofthe problem; and determining the degree of automation,which is dependent on the degree of predictability in thedomain.

Functional allocation in diagnosis may vary fromnear-complete automation in deterministic domains(e.g., electrical fault finding) to collaborative models inless deterministic domains (e.g., medical diagnosis). Inthe latter, the computer supplies information on thefaulty system, lists of potential faults, signs and symp-toms, possible causes, with repair strategies for faulttypes. Given the poor track record of medical diagnosticexpert systems, only partial support for the users� task isadvisable by pre-processing information, e.g. screeningout hypotheses that do not match known observations.Functional requirements associated with partial auto-mation are:

1. Pre-processors to sort and rank symptoms andobserved problems in order of severity, importance,time, etc.

2. Question checklist dialogues to ensure full capture ofdiagnostic information.

3. System model simulations to locate problems andsupport diagnostic reasoning.

4. Expert system inference to diagnose possible causesfrom observed signs.

Diagnosis

Analysis/Modelling

Validation

Explaining/Advising

Information Acquisition

Information Retrieval

Progress Tracking

Forecast

Planning/Scheduling

Matching

Decision

Control

Navigation

ogy

ew domaintestingicating

info.

d existing

itorting

ure state

action

relations

action

tify Generalised Tasks.

Diagnosis

Gatherfacts

Confirmcause

Formhypotheses

Analysecause

Locateproblem

Carry outrepair

Planrepair

Checkresults areconsistent

Run test

Selectcausal hypo-

thesis

Remedyproblem

Testeffectiveness

repairsub-task* *

diagnosticheuristics

& strategies

Fig. 4. Goal hierarchy for the Diagnosis task.

280 A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289

5. Interactive microworld system models with ‘‘what-if?’’ testing facilities.

6. Automatic implementation of treatments for identi-fied problems.

7. Suggestions for potential cures/treatments.8. Facilities for follow-up tests to confirm diagnosis.9. Guided assistance for treatment/repair strategies and

procedures.

The reusable knowledge associated with the taskmodel helps to elaborate the requirements specificationas well as indicating architectural components for sys-tem models, simulations for check treatments, and advi-sory sub-systems.

4.3. Domain analysis: CSCW layer

The collaboration sub-system needs to deliver mes-sages to several users as well as controlling interactionwith shared objects. The goal of delivering messagespoints towards an Object Messaging OSM. Apart fromtransmission of ordinary messages (interaction requests,audio/video communication among users), transmissionof real-time audio or video content may be necessary fortelemedicine purposes (e.g., cardiogram audio samples,endoscope images, etc.). The system must ensure thatthe appropriate communication quality and reliabilityis associated with critical tasks (i.e., patient monitoring,examination).

Following the event trace walkthrough, the first needis for the system to register users to ensure only author-ised users can gain access. The goal state in this problemis for all the system usage requests to be identified andauthenticated, which points to an Object Allocationmodel. Once users have been registered, the problemof shared object control arises. The assumption is that

only one user can interact with a shared object at once,hence a prioritisation process is necessary. An ObjectAllocation model is employed for this purpose. A userwill be allocated control until it is relinquished or thesystem enforces a timeout to ensure that access is dis-tributed more democratically.

The composite architecture of both sub-systems isillustrated in Fig. 5.

Space precludes exhaustive description of all the gen-eric requirements, so we have selected an example of de-sign rationale for allocation of access control in ObjectMessaging systems which indicates trade-offs amongthree options for shared object control (Fig. 6), asfollows:

1. System-based: if the client requests the floor, the sys-tem assigns it to that client if the floor is free; if not,then the client�s request is queued. As soon as thefloor becomes free because the previous ownerreleases it, the system assigns it to the longest-waitingclient.

2. Manager-based: a user is given authority for theresource allocation. The user-manager assigns thefloor to a participant or releases it on anotherrequest. If the manager releases control it returns toa system mode.

3. Token-based: in this case, the user who owns thefloor may choose the next owner of the floor. If thecurrent owner releases the floor then the controlswitches to a system mode. A specialisation of thisoption is round robin-based token control.

Generally one option would be chosen for implemen-tation; however, to preserve flexibility when construct-ing a reuse library we intended to provide the reuserwith the choice of all three options.

Allocator

reserveallocate

Allocator System World

locations

PatientTransporter

transfer

Sensor

detect

Monitor

interpret

Patient

diagnoseupdate

Object

edit

User

request

Sender Receiver

Owner

manipulate

resource

information

Model,information

1

2

3used

by

move

lockunlock

ownedby

patientevents

existsin

Object Allocation:Object Allocation:passwordpassword

Object Allocation:Object Allocation:shared object controlshared object control

Object Messaging:Object Messaging:communicationcommunication

ObjectObjectSensingSensing

authenticate

Fig. 5. Composite system architecture after the modelling phase, showing the CSCW and patient monitoring components with interfaces betweensub-systems: (1) logon authorisation; (2) shared object allocation; (3) patient monitoring data. The Diagnosis task and Object Construction OSMshave been omitted for simplicity.

SharedFloor

Control

Token Holder

Manager Controlled

Queue Based

Equal Sharing

ResponseTime

ImplementationCost

+

+

-

-

-

+

+

Designissue

OptionsGeneric

requirements

Selection criteriaNon-functional requirements

Fig. 6. Design rationale for shared object control. Positive influencesare marked with a plus sign, negative or decreasing influences with aminus sign; thus the manager-controlled option has a positive influenceon cost and response time.

A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289 281

5. Problem Frames

Problem Frames were intended as a formal approachto requirements specification rather than a method fordesign for reuse so this case study applies Jackson�s the-ory in a new way. Problem Frames (Jackson, 2001) are aset of generic models that describe recurring software

engineering problems, although at a higher level ofabstraction than the Domain Theory. Jackson drawsattention to the connection between the designed systemand the real world in which it is or will be embedded. Hesees requirements engineering as the process of precisespecification of the dependencies between designed sys-tems and the external world. Domains are divided intothree types: lexical domains, which are symbol systemssuch as text, diagrams and models; causal domains thatmodel laws and predictable behaviours in the real world;and biddable domains that exhibit behaviour but haveno guarantee of reliability, e.g., human users are bidda-ble in the sense that they may or may not respond.Applications are decomposed using five abstract Prob-lem Frames, described by Jackson (2001) as follows.

5.1. Required Behaviour

‘‘There is some part of the physical world whosebehaviour is to be controlled so that it satisfies certainconditions. The problem is to build a machine that willimpose that control.’’

There is no direct equivalent of this frame in the Do-main Theory, as it refers to compliance with physicallaws or conditions that exist in the real world. Instead,the Domain Theory specifies abstract models for

282 A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289

Required Behaviour in problem contexts of control,construction, and transaction processing.

5.2. Commanded Behaviour

‘‘There is some part of the physical world whosebehaviour is to be controlled in accordance with com-mands issued by the operator. The problem is to builda machine that will accept the operator�s commandsand impose control accordingly.’’

The nearest analogue in the Domain Theory is theAgent Control OSM, which models the behaviour ofthe controller and controlled agent.

5.3. Information Display

‘‘There is some part of the physical world aboutwhose states and behaviour information is continuouslyneeded. The problem is to build a machine that will ob-tain this information from the world and present it atthe required place in the required form.’’

Mapping to the Domain Theory for this frame in oneto many, as the problem is decomposed into ObjectSensing which obtains information about the physicalworld, Object Messaging if the information has to betransported to the required place, and then an ObjectSimulation OSM to represent it in the required form.

5.4. Workpieces

‘‘A tool is needed to allow the user to create and edita certain class of computer processable text or graphicobjects, or similar structures, so that they can be subse-quently copied, printed, analysed or used in other ways.The problem is to build a machine that can act as thistool.’’ Workpieces maps to a Conceptual Object Con-struction OSM.

5.5. Transformation

‘‘There are some given computer readable input fileswhose data must be transformed to give certain requiredoutput files. The output data must be in a particular for-mat and it must be derived from the input data accord-ing to certain rules. The problem is to build a machinethat will produce the required outputs from the inputs.’’

This Problem Frame maps to several OSM trans-action families that require data transformation, e.g.,Object Inventory, Object Hiring, Object Allocation.

Each frame encapsulates objects in the real world,objects in the required system, and connections betweenthem that formally model the assumptions made aboutthe system. For example, the Workpiece frame describesthe interaction between events and their effect on amodel held in the machine. Problem Frames have‘‘frame concerns’’ which record issues that need to be

addressed in a class of problems, in a similar mannerto the Domain Theory�s requirements problems; in addi-tion, more general concerns are described, such as issuesof overrun, initialisation, reliability, identity of individu-als, and completeness. Problem Frames also indicaterequirements for correct behaviour; for example, inWorkpieces one frame concern draws attention to theneed to validate that commands are syntactically correctand appropriate for a context, thereby preventing errorssuch as trying to edit a record before it has been created.A limited number of composite Problem Frames are de-scribed: for instance, the Model View Controller genericarchitecture can be mapped to Workpiece frames forupdating the model and the display, CommandedBehaviour for user editing controls, and RequiredBehaviour for maintaining consistency between themodel, edits and the view on the model. Compositeframes are associated with concerns such as precedence,consistency between domain descriptions, interferenceof interactions between frames, and scheduling ofmachines that share a common domain.

5.6. Domain analysis using Problem Frames

Identification of Problem Frames relies on investigat-ing the connection between the real world and designedmachine, and inquiring about the dependencies between‘‘domain properties’’: facts and laws which are known tobe true in the real world, and specifications of the de-signed machine that meet the stated system require-ments. Problems are decomposed and mapped toProblem Frames using the following heuristics (Jackson,2001):

• Identifying the core problem. This is similar to theessential system model (McMenamin and Palmer,1984) or the entity model in JSD (Jackson, 1983),and represents the objects involved in the process thatachieves the major system goal.

• Identifying the ancillary problems that surround thecore, especially information processing sub-problems.These map to functions in JSD, also error handlingroutines.

• Standard decomposition of sub-problems, using com-binations of Problem Frames to build compositeframes, also investigating the dependency of staticor dynamic models on the physical world.

• Identifying concerns and difficulties. Frames can bediscovered from frame concerns.

• Different tempi: more than one temporal pace in anapplication, where one part changes quickly whilethe other changes over a longer period of time. Thissuggests two dynamic and static model sub-problems.

• More than two moods. If the frame has more thanone indicative mood (domain properties, facts, laws)and more than two optative statements (i.e., require-

A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289 283

ments which state the goal to be achieved and thebehaviour specification of the machine that achievesthe goals) then there are probably more frames inthe application.

• Complex domains or requirements. These usuallyhave several Problem Frames, although no criteriafor assessing complexity are stated by Jackson. Sub-sets of heuristics are given for combinations of prob-lems frames such as Required and CommandedBehaviour.

• Modelling the user: a separate sub-problem.

Space precludes a more complete description of Jack-son�s theory for which the reader is referred to Jackson(2001).

5.7. Problem Frame analysis: patient monitoring

In Problem Frame terms, patient monitoring is a cau-sal domain. The accuracy of event interpretation de-pends on the fidelity and detail contained in thepatient model. An Information Display Problem Framemodels monitoring events in the external world, with aTransformation frame interpreting them with referenceto the system�s internal model of the external entity(i.e., the patient) and representing the events for theusers (nurses/doctors). The frame models the changefrom analogue values to a representation of the patient�sblood pressure, EEG, etc. The monitoring and interpret-ing part of the patient sub-system is modelled by twointerconnected Problem Frames: Information Displayand Transformation. The Transformation frame con-cern is the need to interpret data as quickly as possibleto make sure it is accurate, because if it is too slow,

Patient ModelRanges, Threshold

Monitoringmachine

Seniornurse

Designeddomain

Designedmachine

Patientgiven domain

Requirements

settingsthresholds

rangesthresholdspatient ID

KeyKey

ranges

softwarealgorithms

assumptionsdata settings,parametersDBMS, files

external agentor entity

dependenciesshared phenomena

requirements

Fig. 7. Information Display Problem Frame diagram for the patient monitornot been illustrated.

the monitored world will have changed so the interpre-tation of the patient�s state will be inaccurate. TheDomain Theory uses one OSM (Object Sensing) formonitoring and one Generic Task for interpreting. Boththeories draw attention to the need to interpret externalevents by reference to the system model of externalentities; however, the Domain Theory requirementsproblems concern detecting events, whereas ProblemFrames tend to focus more on transformation ofrepresentations.

The patient monitoring and data display for nurses ismodelled by an Information Display frame (see Fig. 7).Implicit in this frame is a patient model sub-system(thresholds/settings) which is composed of a WorkpieceProblem Frame for updating the model either from user-initiated edits or automatic updates collected by themonitoring system (illustrated in Fig. 8). Many Infor-mation Display frames will be necessary to model mon-itoring of different sensor devices, e.g., (blood pressure,temperature, ECG, etc.), and data from these frameshas to be integrated. Mapping data integration to Prob-lem Frames is not direct; either a Connection frame ormore usefully a Transformation frame can be used.The patient monitoring Information Display frame isassociated with an Identity frame concern, which drawsattention to the need to specify the integrity of modelupdating to preserve the individual�s identity, hence anupdate to Mr. Jones� blood pressure alert threshold en-tered by the doctor has to be faithfully registered withMr. Jones� record in the Patient database. There is an-other identity concern in the patient monitoring sub-sys-tem which points out that the connection between theindividual patient, the hardware sensor, and the eventstream processed in the software machine all need to

Patients

s Monitorpatients

Nurses’UI

Monitoringdevices

vitalsigns

eventsmeasures

notifymessage

alert settings

alert

patientinformation

Sub-problem

ing sub-system. The Transformation frame for event interpretation has

SharedControlling

Doctor

Modeleditor

User/Patientmodel

Displayrequirements

Modelrequirements

Displayhandler

Informationdisplay,

Patient data

Workpiecesproblem frame

InformationDisplay

problem frame

updates

Patient

settings

alerts,patient data

editrequirements

Fig. 8. Problem diagram in the patient model sub-system. Notillustrated are other instances of Information Display frames whichspecify editing controls and feedback on the display.

284 A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289

be checked to ensure they monitor the same individual.In Domain Theory terms this sub-system contains Ob-ject Construction to build and update the model, andObject Simulation to represent it. The Domain Theoryand Problem Frames propose similar abstractions anddraw attention to the similar problems expressed asframe concerns or requirements issues (e.g., updateintegrity problem in Workpieces).

Problem Frames are difficult to map in detail totask-based activity. An Information frame models therepresentation of the patient monitoring data, whileCommanded Behaviour frames can be applied to match-ing symptoms to possible causes in diagnosis and thenmatching the diagnosed causes to treatments (seeFig. 9). In contrast, the diagnostic part of the applica-tion is modelled in considerable detail by the DomainTheory as a single Generalised Task and by three OSMs,

Doctor

Diagnosismachine

Patientmodel

Analysisrequirements

Diagnosticrules

analysis request

symptoms

predictions

Fig. 9. Commanded Behaviour Problem diagram for the diagnosissupport sub-system. This frame is associated with an InformationDisplay frame for representing the results of the diagnosis.

which describe requirements for task support and infor-mation requirements as well as drawing attention torequirements trade-offs when automating diagnosisaccording to the accuracy of information and determin-ism of diagnostic rules.

5.8. Problem Frame analysis: CSCW sub-system

The CSCW component contains four sub-systems.First is message passing, which involves encoding anddecoding packets, modelled respectively as a Transformframe for encoding, followed by a Commanded Behav-iour frame for addressing, and two Required Behaviourframes, one for dispatching and controlling the routing,and another for handling the communication protocolacknowledgements. Error checking for lost packets addsmore Required Behaviour frames. Allocating users tocollaborative sessions by a logon facility suggests aCommanded Behaviour to assigned valid users (seeFig. 10). Control of shared access to a common artefact,i.e., editing the patient model, is a Workpiece frame withCommanded Behaviour to control access of users to ses-sions; the same is true for viewing/editing the rights overa shared artefact. Integrating Problem Frames withshared phenomena (in this case, users) raises composi-tion concerns of consistency, precedence, interferenceand scheduling. For instance, a request to edit an arte-fact from a user who has not joined the current sessionis a nonsense. Specifying requirements to handle theseconcerns necessitates modelling permissible event se-quences at the state transition level, as well as handlingidentity concerns for authorised users. Access rights willultimately depend on domain-specific requirements suchas constraints on the number of nurses and doctors whocan join a particular session. To handle these functionsthe generic CSCW modules need parameterised controls

User

Allocationmachine

Registeredusers

Logonrequirements

Sessionallocationmachine

logon request

Authorisedusers

artefact

Sessioncontrol

requirements

access requestusers

Fig. 10. Commanded Behaviour Problem Frames diagram in theCSCW sub-system for allocating users to sessions, and controlledaccess to shared artefacts.

A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289 285

and editors to set such parameters (more Workpieceframes).

Message handling in the CSCW sub-system involvesseveral decompositions covered in Jackson�s book inthe packet-router problem. In the Domain Theory, theCSCW is composed of message-passing OSMs. Turn-taking for conversation management in CSCW is mod-elled by another Commanded Behaviour ProblemFrame, or in the Domain Theory by an Object Alloca-tion OSM, with an Associate Generic Task. Space pre-cludes further description of specification; however, itshould be noted that the preceding description only cov-ers the Problem Diagram level; the Jackson approachprogresses to more formal specification of requirementsfor the designed system and assumptions about thedomain at the Problem Frame diagram level.

6. Lessons learned

6.1. Identifying abstractions

Problem Frames were identified using Jackson�sproblem decomposition heuristics and following depen-dency links from event output from one frame to an-other. The small number of Problem Frames madeidentification relatively easy; for example the CSCWproblems involved access control and session allocation,which strongly indicated Commanded Behaviourframes. Similarly, information monitoring indicatedInformation Display frames, and any need to changerepresentations of input events into output suggested aTransformation frame. Editing operations and user-ini-

Table 1Abstract models identified in case study sub-systems by the Domain Theory

Modules OSM

TeleMedicine

1. Patient monitor Object Sensing2. Patient state interpreter Interpret & Judgement G

3. Diagnostic assistant Diagnosis GTObject SimulationObject Allocation

4. Patient model Object ConstructionObject Simulation

5. Treatment control Agent ControlObject Repair

CSCW

6. Message passing Message Transfer

7. Shared access to object control Object AllocationObject Construction—A

8. Common object display Object SimulationObject Construction

9. Turn-taking access control Object AllocationObject Construction

tiated changes to internal system models were easilyidentified as Workpiece problems. Difficulties withProblem Frames arose when connecting and integratingthem. The models rapidly grew into multi-frame repre-sentations. Although some reduction in complexitywas possible by using frame context diagrams, therewas no escape from the need to specify detailed inter-frame connections and formally model the dependenciesbetween the domain properties (indicative requirements)and required system behaviour (optative requirements).

Domain Theory models were identified by severalstrategies, such as following event dependencies, linksbetween models in the Domain Theory library, identifi-cation heuristics and lexical identification using synonymtables. Since the Domain Theory did not explicitly allo-cate methods (i.e., tasks) to objects, some confusionarose because of the redundancy between OSMs andGeneric and Generalised Tasks. For instance, ObjectAllocation modelled the problem in an object-orientedview, while Matching (Generalised Task) described aprocess-oriented view. Some system componentsmapped naturally to Generic Tasks, e.g., diagnosis andinterpreting event patterns, whereas others mapped moreeasily to OSMs, such as Monitoring and Object Sensing.Object Repair was not an obvious abstraction for thediagnosis and treatment sub-system, and the multiple in-stances of Object Allocation encountered the same diffi-culty as the Commanded Behaviour Problem Frame:namely, it was hard to integrate turn-taking controland shared-object control in the CSCW layer.

A summary of the modules identified from both theDomain Theory and Problem Frames analysis is givenin Table 1.

and Problem Frames approaches

Problem Frame

Information DisplayTs Transformation

Required BehaviourTransformationInformation DisplayCommanded BehaviourWorkpieceInformation DisplayCommanded Behaviour

Transform—encodingCommand—dispatchWorkpiece (model)

gent Control Commanded Behaviour—AllocateWorkpieceInformation DisplayWorkpieceInformation Display

286 A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289

Fifteen OSMs were necessary for the core applicationbut adding user interfaces for editing the registered usersdatabase and three Object Sensing Models for othermonitoring devices took the total to 19 plus 3 GenericTasks. The core model needed 17 Problem Frames; how-ever, each interactive user interface is modelled by atleast two or three Information Display frames, andmore Information Display instances were required formodelling monitoring devices, bringing the total to 23which would be increased when more monitoring de-vices were attached. Both the Domain Theory and Prob-lem Frames contributed requirements and insights intothe specification of the patient monitoring and nursealert functions, e.g., identity concern and fidelity ofevent capture Generic Requirement. Both approacheswere weak on integration of several data sources. Prob-lem Frames modelled the diagnostic support componentas Transformation and Commanded Behaviour fortreatment, but gave little guidance about the functionalrequirements. The Domain Theory�s generalised taskmodels provided more specification detail, as well asguidance on functional allocation. However, both theo-ries provided little advice about the user interfacerequirements, e.g., alert function modality, messageformat, etc. for the nurses or doctors.

In the CSCW layer both theories provided reusablerequirements and specification advice for the sharedartefact and session control components, but were lessforthcoming on the generic dialogue control and presen-tation layer. Problem Frames dealt with these issues inthe composite Model View Controller frame and indi-rectly addressed CSCW concerns of shared viewpointsand constructing different presentations on one sharedobject for each user (Rodden, 1991) by Interaction andConsistency frame concerns.

6.2. Lessons learned: reusing knowledge

Once the abstractions had been identified, both theo-ries guided the software engineer towards identifyingimportant problems inherent in the application domain.Problem Frames do so partly by encouraging more for-mal specification of the dependencies between the realworld domain properties and machine requirementsand partly through frame concerns that draw attentionto typical pitfalls in specification. The Domain Theorypresents advice explicitly in the form of requirementsproblems that point to pitfalls, associated with genericrequirements that present solutions as functionalrequirements.

Frame concerns were useful in pointing out severalpotential pitfalls, such as the need to specify identityof individuals (in patient records, patient monitoringdata); in update integrity of patient data, accuracy andrecency of data; and in synchronisation of control inCSCW conversation and access to shared artefacts

(e.g., the individual who edits can also talk about theedits). However, composite frame concerns are not at-tached to particular Problem Frames so reuse of thisknowledge was almost a separate process from specifica-tion. Informal inspection of dependencies betweenProblem Frames uncovered some potential flaws inspecification in handling error conditions, such as lostconnections between individuals and maintaining con-versational threads for recovery.

Problem Frames partitioned the system into more,lower-level components, while drawing attention to sev-eral specification problems as frame concerns for updateintegrity, access to shared data, synchronising queuesand controlling execution sequences. Identification ofProblem Frames was more difficult because Jackson�smethod relies on examples and a few heuristics to helpthe user discover appropriate abstractions. Further-more, the detailed level of specification implied by Prob-lem Frames made for a complex specification requiring alarge number of interfaces between individual frames.This specification proved to be time consuming. Thevalue in Problem Frame analysis lay in identificationof frame concerns which pointed out aspects of the spec-ification that required detailed design to ensure correctsystem behaviour. Problem Frames also encouragedformalisation of the dependencies between domainproperties, requirements and specifications. However, acomplete formal specification was not attempted, firstbecause of the effort required and secondly becauseinterfaces between frames on which formalism dependedwere difficult to define precisely. In particular this prob-lem arose in biddable domains involving the human-computer interface where unpredictable user behaviourwas difficult to anticipate.

Both theories helped to develop component specifica-tions; however, the reuse library needed to be designedand implemented as software components. DomainTheory models and Problem Frames were mapped asobject-oriented (OO) patterns (Gamaa et al., 1995);however, this exercise showed only a weak dependencybetween the requirements specification models and OOpatterns. For instance, Object Sensing mapped to theObserver patterns which provides an object collabora-tion design for monitoring, but other patterns such asuse of Facade for hiding different implementation varia-tions, Factory for flexible implementation of differentmethods (such as the shared access protocols) and Proxyto control client server communication in the CSCWlayer, had few dependencies with requirements models.

6.3. Comparison of the approaches

The Domain Theory and Problem Frames both pro-vide improved analytic techniques compared to stan-dard domain analysis methods because they drawattention to the nature of abstractions inherent in all

Table 2Summary of comparison between the Domain Theory and Problem Frame approaches

Feature Domain Theory Problem Frames

Generic models provided 12 families, 56 OSM models, 12 Generalisedand 22 Generic Tasks

5 Problem Frames

Source of models Elicited from experts + theoretical analysis Theoretical analysisAnalysis process Identify abstraction, reuse generic models

and associated requirementsUse Problem Frames to reason about requirementsdependencies and constraints

Analysis heuristics No, but implicit in OSM and task model families Frame concernsFormal specification No, UML modelling language Possible FOL expression of dependencies and constraints

A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289 287

applications at a deep level. They also provide more pro-cess guidance and heuristics than Fowler�s conceptualpatterns. However, the two approaches function at dif-ferent levels of abstraction. The differences betweenthe approaches are summarised in Table 2.

The Domain Theory provides a more comprehensivelibrary of reusable models, and this drives the analysisapproach in which abstractions in the domain are iden-tified by matching to generic models; the models andreusable requirements can then be used to structurethe component library. In contrast, Problems Framesis a reasoning-intensive approach where the models(frames) act as cognitive probes to promote reasoningabout the dependencies between the domain and thespecified solution. The focus is on understanding thedependencies between the real world and the designedmachine (indicative and optative requirements in Jack-son terminology), then specifying the solution to dealwith the constraints and desired system behaviour.Frame concerns draw attention to general specificationissues and more formal specification is possible. How-ever, the number of problem types addressed by Jack-son�s method is restricted; for instance, active softwareagents, or problems of spatial movement and planningare not dealt with directly. In contrast, the Domain The-ory level of abstraction is closer to specific types of prob-lems, e.g., OSM families are given for active agents(Agent Control) and spatial problems (Object Logistics).

7. Discussion

Development of reusable software will necessitateadvances beyond the current generation of domainanalysis methods. These provide process guidance forproblem decomposition and indexing of reusable com-ponents, but little else. The contribution of this paperhas been to apply two theories to design for reuse andevaluate their potential for improving domain analysisand specification of reuse libraries.

The Domain Theory (Sutcliffe, 2002) and ProblemFrames (Jackson, 2001) contributed in different ways.The Domain Theory provides a library of generalisedmodels that act as templates for conceptual modelling.These abstractions proved reasonably easy to identify

using decision trees and heuristics. The generic problemspointed to issues that required further analysis; however,the Domain Theory did not provide detailed problemanalysis advice, whereas frame concerns did draw atten-tion to specification issues more precisely. The genericrequirements and functional allocation advice in theDomain Theory were more useful for developing therequirements specification, e.g., in the diagnosis sub-system where generalised task models advised on func-tional allocation. Problem Frames, in contrast, were lessuseful for specification of task support functions. To anextent the approaches are complementary; the DomainTheory is a knowledge-intensive approach providingmany reusable abstractions to guide thought, whereasProblem Frames provide few abstractions but moreanalysis guidance. The danger of the Domain Theoryapproach is that the models could be reused ‘‘as is’’without much thought; however, the models are moreaccessible. The converse may be true of ProblemsFrames; since the models and approach are less accessi-ble, more reasoning may be applied.

Few other methods have addressed the problem ofidentifying a reusable set of abstractions for use inrequirements specification. Reusable software architec-tures have been produced for system families in flexiblemanufacturing (Gomaa, 1995), but these are more do-main specialised; for instance, Automatic Guided Vehi-cle components would be decomposed from the DomainTheory viewpoint into a collaboration of Object Sens-ing, Agent Control and Object Logistics abstractions.Design-level abstractions are well known from theGOF (Gang of Four) Object Oriented design patterns(Gamaa et al., 1995), and some design patterns map di-rectly to Domain Theory models, such as Observer de-sign pattern to Object Sensing models (Papamargaritisand Sutcliffe, 2004). However, most GOF patterns re-flect design rather than requirements concerns. TheKAOS language and GRAIL tool (Van Lamsweerdeand Letier, 2000; Van Lamsweerde, 2001) have beenused to create generic models, for instance in hospitalreservation systems. KAOS does not propose a compre-hensive set of reusable generic models; instead it gives ageneral process for formal specification of requirementsand constraints using a goal decomposition method.However, Van Lamsweerde has specified generic types

288 A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289

of goals and obstacles building on the Inquiry Cycleconcepts of attainment and maintenance goals. Thesecan be seen as precursors of generic models. A largenumber of product lines have been proposed but eachauthor creates new families on an ad hoc basis, with lit-tle generality beyond the scope of the original domainanalysis. The case study we have reported is, we believe,the first attempt to develop reusable software at morethan one level of abstraction so it can be reused moreflexibly. Clearly we will have to wait for evidence of re-use of the telemedicine library to evaluate the utility ofapplying the Domain Theory and Problem Frames todesign for reuse.

Acknowledgements

The authors wish to thank BTexaCT Technologieswho supported GP�s research, and Chris Voudouriswho provided access to the Telemedicine domain.AGS would like to thank Michael Jackson for answersto several queries on Problem Frames; however, any er-rors in the specification are the author�s responsibility.

References

Bray, I.K., 2002. Expertise: An Introduction to Requirements Engi-neering. Addison-Wesley, Reading, MA.

Breuker, J., Van Der Velde, W., 1994. CommonKADS Library forModelling. IOS Press, Amsterdam.

Clements, P., Northrop, L.M., 2001. Software Product Lines: Practicesand Patterns. Addison-Wesley, Reading, MA.

Fayad, M.E., Johnson, R.E., 2000. Domain-Specific ApplicationFrameworks: Frameworks Experience by Industry. Wiley, NewYork.

Fowler, M., 1997. Analysis Patterns: Reusable Object Models.Addison-Wesley, Reading, MA.

Gamaa, E., Helm, R., Johnson, R., Vlissides, J., 1995. Design Patterns:Elements of Reusable Object-Oriented Software. Addison-Wesley,Reading, MA.

Gomaa, H., 1995. Reusable software requirements and architecturesfor families of systems. Journal of Systems and Software 28, 189–202.

Hall, J.G., Jackson, M.J., Laney, R.C., Nusibeh, B., Rananotti, L.,2002. Relating software requirements and architectures usingproblem frames. In: Greenspan, S., Saddiqui, J., Pohl, K. (Eds.),Proceedings of RE 02, 1st International Conference on Require-ments Engineering. IEEE Computer Society Press, Los Alamos,CA, pp. 137–145.

Harandi, M.T., Lee, M.Y., 1991. Acquiring software design schemas: amachine learning perspective. In: Proceedings of the 6th Confer-ence on Knowledge Based Software Engineering (Syracuse NY).IEEE Computer Society Press, Los Alamos, CA, pp. 239–250.

Jackson, M., 1983. Systems Development. Prentice Hall, London.Jackson, M., 2001. Problem Frames: Analysing and Structuring

Software Development Problems. Pearson Education, Harlow.Jarzabek, S., Ong, W.C., Zhang, H., 2003. Handling variant require-

ments in domain modeling. Journal of Systems and Software 68 (3),171–182.

Keller, G., Teufel, T., 1998. SAP/R3 Process Oriented Implementa-tion. Addison-Wesley, Longman, Reading, MA.

Lam, W., McDermid, J.A., Vickers, A.J., 1997. Ten steps towardssystematic requirements reuse. In: Proceedings ISRE �97: 3rd IEEEInternational Symposium on Requirements Engineering (Annapo-lis MD). IEEE Computer Society Press, Los Alamitos CA, pp. 6–15.

Levi, K., Arsanjani, A., 2002. A goal-driven approach to enterprisecomponent identification and specification. Communications of theACM 45 (10), 45–52.

Mannion, M., Kaindl, H., Weadon, J., 1999. Reusing single systemrequirements from application family requirements. In: Proceed-ings of the International Conference on Software Engineering,ICSE 99. IEEE Computer Society Press, Los Alamitos CA.

McMenamin, S.M., Palmer, J.F., 1984. Essential Systems Analysis.Yourdon Press, Englewood Cliffs, NJ.

Papamargaritis, G., Sutcliffe, A.G., 2004. Applying the domain theoryto design for reuse. BT Technology Journal 22 (2), 104–115.

Rasmussen, J., 1986. Information Processing in Human ComputerInteraction: An Approach to Cognitive Engineering. NorthHolland, Amsterdam.

Rodden, T., 1991. A survey of CSCW systems. Interacting withComputers 3 (3), 319–353.

Rudkin, S., Alan, S., Papamargaritis, G., 2001. COMPOSE: AComponent-Based Service Provision Architecture. BTexact Tech-nologies, Martlesham.

Rudkin, S., Smith, A. 2000. A scheme for component-based servicedeployment. In: Proceedings: Conference on Universal ServiceMarkets, Munich.

Scheer, A.W., 1994. Enterprise-Wide Data Modelling. Springer-Verlag, Berlin.

Shaw, M., 1991. Heterogeneous design idioms for software architec-ture. In: Proceedings 6th International Workshop on SoftwareSpecification and Design. IEEE Computer Society Press, LosAlamitos, CA, pp. 158–165.

Simos, M., Anthony, J., 1998. Weaving the model Web: a multi-modeling approach to concepts and features in domain engineer-ing. In: Devanbu, P., Poulin, J. (Eds.), Proceedings of the FifthInternational Conference on Software Reuse (Victoria BC). IEEEComputer Society Press, Los Alamitos, CA, pp. 94–102.

Smith, D.R., 1992. Track assignment in an airtraffic control system: arational reconstruction of system design. In: Proceedings of theKBSE 92, Knowledge Based Software Engineering. IEEE Com-puter Society Press, Los Alamitos, CA, pp. 60–68.

Sutcliffe, A.G., 2000. Domain analysis for software reuse. Journal ofSystems and Software 50 (3), 175–199.

Sutcliffe, A.G., 2002. The Domain Theory: Patterns for Knowledgeand Software Reuse. Lawrence Erlbaum Associates, Mahwah, NJ.

Sutcliffe, A.G., Carroll, J.M., 1999. Designing claims for reuse ininteractive systems design. International Journal of Human–Computer Studies 50 (3), 213–241.

Sutcliffe, A.G., Dimitrova, M.T., 1999. Patterns, claims and multi-media. In: Sasse, A., Johnson, C. (Eds.), Proceedings of theINTERACT 99 IFIP TC.13 International Conference on Human–Computer Interaction. IFIP/IOS Press, Amsterdam, pp. 329–335.

Sutcliffe, A.G., Ennis, M., 2000. Designing intelligent assistance forend-user information retrieval. In: Paris, C., Ozkan, N., Howard,S., Lu, S. (Eds.), Proceedings of the OZCHI-2000 (Sydney).CSIRO/CHISIG, Canberra, pp. 202–210.

Sutcliffe, A.G., Maiden, N.A.M., 1998. The domain theory forrequirements engineering. IEEE Transactions on Software Engi-neering 24 (3), 174–196.

Van Lamsweerde, A., 2001. Goal-oriented requirements engineering: aguided tour. In: Proceedings of the RE�01—5th IEEE InternationalSymposium on Requirements Engineering, Toronto, August, 2001.IEEE Computer Society Press, Los Alamitos, CA, pp. 249–263.

A. Sutcliffe et al. / The Journal of Systems and Software 79 (2006) 273–289 289

Van Lamsweerde, A., Letier, E., 2000. Handling obstacles in goal-oriented requirements engineering. IEEE Transactions on SoftwareEngineering 26 (10), 978–1005.

Vici, A.D., Argentieri, N., Mansour, A., d�Alessandro, M., Favaro, J.,1998. FODAcom: an experience with domain analysis in the Italiantelecom industry. In: Devanbu, P., Poulin, J. (Eds.), Proceedings ofthe Fifth International Conference on Software Reuse, pp. 166—175.

Wehrend, R., Lewis, C., 1990. A problem-oriented classification ofvisualization techniques. In: Proceedings First IEEE Conference on

Visualization: Visualization 90. IEEE Computer Society Press, LosAlamitos CA, pp. 139–143.

Weiss, D.M., Lai, C.T.R., 1999. Software Product-Line Engineering:A Family-Based Software Development Process. Addison-Wesley,Reading, MA.

Zhou, M.X., Feiner, S.K., 1998. Visual task characterization forautomated visual discourse synthesis. In: Karat, C.M., Lund, A.,Coutaz, J., Karat, J. (Eds.), Human Factors in Computing SystemsCHI 98 Conference Proceedings (Los Angeles). ACM Press, NewYork, pp. 392–399.