Telecommunications service development:a design methodology and its intelligent support

Armin P.-G. Eberlein

Department of Electrical & Electronic Engineering, University of WalesSingleton Park, Swansea SA2 8PP, UK, Tel: +44 1792 295541, Fax: +44 1792 295686

e-mail: A.Eberlein@swansea.ac.uk

Fred Halsall

Department of Electrical & Electronic Engineering, University of WalesSingleton Park, Swansea SA2 8PP, UK, Tel: +44 1792 295685, Fax: +44 1792 295686

e-mail: F.Halsall@swansea.ac.uk

This paper describes a development life cycle for telecommunications services emphasising requirements capture,formal specification and validation. The service is developed along the three dimensions of the methodology: refine-ment, completeness and formality, aiming for a complete, consistent and formally specified service definition. Thedescribed methodology can be integrated into currently existing development life cycles which employ formal methodsfor service creation. Active support for the proposed life cycle is provided by a novel expert system called Require-ments Assistant for Telecommunications Services (RATS) currently under development. It actively helps during re-quirements acquisition and early analysis, and encourages specification reuse with the help of a semi-automated ne-gotiation process. The RATS tool advises the service developer during all stages of the service development and ondifferent levels of abstraction, and provides requirements management facilities, like traceability, impact analysis anddocument generation. Some of the features are illustrated using examples from the Universal Personal Telecommuni-cation (UPT) service.

Keywords: Expert system, telecommunication, service design, design methodology, formal methods, requirementsengineering.

1. INTRODUCTION

Errors in requirements specifications have a signifi-cant effect on software costs and customer satisfac-tion. It is now widely accepted that errors associatedwith requirements specification are the most numer-ous, most costly and most time-consuming to correct.Old studies [Boe84] as well as new studies [Dav93]confirm this. [Eng95] states that $81 billion was spenton cancelled software projects in the USA in 1995alone. Other less well-referenced studies [TTN] claimthat 80% of all defects are inserted in the requirementsphase.

These examples show the importance of require-ments engineering. More than the usual 10% of theproject duration [Lub93] needs to be spent on the re-quirements phase in order to combat the immenseproject costs, delays and even failures. Moreover, fordistributed systems, comprising many interacting sub-systems, this figure should be significantly larger.

Two of the most important factors which determinethe correctness of a software system are

• the quality of the requirements specification,• the quality of the transformation of the require-

ments specification into a concrete software sys-tem.

This paper is primarily concerned with require-ments acquisition, specification and implementationof telecommunications services. Keeping in mind thatthe telecommunications network is, in practice, onelarge distributed system with 70% of its design effortbelonging to the software engineering domain[Ree92], requirements engineering for telecommuni-cations systems and services is a challenging task.Currently, the major problem is not how to find newservice ideas, but rather how to capture all the re-quirements of the new service, specify them in a for-mal way and ensure that the new service does not in-terfere with already existing services [Bou94b]. Thelack of adequate CASE tools [Bub95] for require-

ments engineering means that issues such as require-ments traceability and documentation of rationale aremore difficult to address.

The formal Specification and Description Language(SDL), which has been recommended by the Interna-tional Telecommunication Union (ITU) for the speci-fication of services and protocols for both IntelligentNetwork (IN) and switch-based services, has been ofconsiderable help in terms of software correctness andreliability. Good commercial tool support is nowavailable for SDL, so that once a complete, consistentand formal specification in SDL has been created, theremaining development activities still require sub-stantial effort, but generally proceed without majorconceptual difficulties [Bou94a, Coo93].

The process of requirements elicitation, analysisand formalisation, however, is now a major bottleneckfor implementation of telecommunications services.Initially, informality is not only inevitable, but evendesirable as it is an essential part of the humanthought process and part of a powerful debuggingstrategy for dealing with complexity [Bal78]. Eveninconsistencies are productive, as conflicts increasecreativity. Incompleteness, which can be seen as akind of oversimplification, improves understanding.However, it is difficult to produce a high quality re-quirements document from the vague, unordered, in-accurate, incomplete and even ambiguous or contra-dictory statements typically presented as initial re-quirements. In the final specification, formality is es-sential since this reduces the likelihood of misunder-standing and the loss of requirements.

Even when a good requirements document exists, itwill only be partly implementable due to limitations inthe network, cost and time-to-market considerations.The creative process of matching requirements toleast-cost implementation requires in-depth knowl-edge of the underlying network.

In the scheme proposed here, we have started toimplement a prototype of a novel expert system calledRequirements Assistant for Telecommunications Serv-ices (RATS) which supports requirements elicitationand early analysis, while providing a smooth transitionto SDL-based formal methods. The aim is thus to in-troduce formality at an earlier stage of the develop-ment life cycle without restricting innovation.

2. SERVICE DEVELOPMENT

2.1 Outline of the development process

Figure 1 outlines the proposed development lifecycle and planned tool support for the design of newtelecommunications services, from initial require-ments capture, through to their implementation. Thedevelopment starts with a vague customer idea ofwhat the service is supposed to do. This idea is thenordered and expressed in a semi-formal way with thehelp of the RATS tool. The output of RATS is thentranslated into a formal executable SDL specificationfrom which existing commercial tools can automati-cally generate code. Each one of these steps providesdifferent possibilities for testing (see Section 5.3).

One of the aims of the methodology is to ensurethat the development process is customer-centred[Rau94]. The goal is to offer the customer what hereally wants not only what we think he might want orwhat we can offer most easily. As can be seen inTable 1, the customer is involved in most steps per-formed during service development. Continuous feed-back and agreement by the customer are crucial.

Figure 3 shows another aspect of the methodology.An attempt has been made to combine two extremes:the acquisition of the initial customer requirements isas free as possible in order to encourage innovationand to ensure that the end product meets the initial

Figure 1: The overall methodology for telecommunications service design

customer idea. Later, constraints and formality areintroduced step by step (see Section 2.2.4) until thedesired service is fully formally specified. Within thisprocess there are stages where specification reuse isencouraged (see Section 4.5).

2.2 The overall methodology

2.2.1 The three dimensions of the developmentprocess

Figure 2: The three dimensions of the develop-ment process

Complex processes can be made more accessible bysplitting them up into smaller sub-processes which areideally independent of each other. There have beenattempts to find orthogonal dimensions for require-ments engineering [Poh94]. However, existing ap-proaches do not seem to be very well suited for thedevelopment of telecommunications services. We,therefore, have defined a novel three dimensional de-velopment process as the underlying framework of ourmethodology. The dimensions represent three majorconcerns during service development, with each di-mension having its well-defined states and being inde-pendent of the others. However, practice shows thatone step in the development of a service involves pro-gress in usually more than one dimension. For in-

stance, the completeness of a specification increasesthrough refinement of requirements. The followingsections describe the three dimensions and give moredetails about the proposed methodology.

2.2.2 Completeness

Completeness is a major concern during require-ments acquisition. A requirements specification (RS)can be seen as complete when all necessary require-ments of the service have been stated. This is a non-trivial task as it involves a high amount of creativity,with the service design expert being the main con-tributor to completeness. However, our methodologyprovides some means which help in completely defin-ing a service.

As will be explained later in Section 2.3.1, themethodology includes requirements documents whichenforce a certain degree of completeness. The brain-storming session is, in the first instance, only intendedto collect requirements without any evaluation (seeFigure 3). Next to putting the focus on requirementsacquisition rather than analysis, this encourages inno-vation. Another major step towards completeness isachieved by the service definition template (SDT)which contains predefined headings relevant for serv-ice development.

Use cases are another means of increasing com-pleteness [Jac93] by taking the designer through se-quences of service behaviour and user-service interac-tions.

The methodology considers the development ofnon-functional requirements (NFRs). NFRs are oftenreferred to as system constraints, goals or quality at-tributes and can be seen as the driving force behinddesign decisions [Chu95, Myl92] and therefore playan important role. NFRs need to be satisfied by eitherfunctional requirements or implementation constraints(see Section 2.3.2) thus raising new issues. Each func-tional requirement needs to have parallel and excep-tional behaviour assigned to it. If this is not required,

Figure 3: The requirements acquisition process (example: UPT service)

the designer is forced to explicitly state it.

Finally, the formal specification in SDL encouragescomplete specification of the functional behaviour(see Section 5).

All these measurements increase completeness;however they cannot ensure it. Orthogonal incom-pleteness, if it does not lead to inconsistencies, simplycannot be detected by tools.

Additionally, a different kind of completeness ex-ists: in order for a requirements specification to becomplete, it also needs to contain the rationale behinddesign decisions, and the requirements need to betraceable to their source. This is described in moredetail in Section 3 which deals with requirementsmanagement.

2.2.3 Refinement

As shown in Figure 2, the refinement dimension ofour methodology is geared towards the intelligentnetwork (IN) architecture. However, the architectureas recommended by the ITU in the [Q.12xx]-series, isstill not common practice. Especially the concept ofservice independent building blocks (SIBs) is hardlyused by service providers for service modelling.Therefore, the methodology guidelines (see Sec-tion 2.4 and Table 1) do not go quite as far as thetheoretical framework shown in Figure 2. We use themore practical approach of building services out ofservice features (SFs) and service features out of sub-features.

This assumes a mapping process from one level ofrefinement to another. As described in Section 4.5,this gives the possibility of reusing already existingfunctional blocks. Specification reuse is another activeresearch area [Bel93] which provides an easy meansfor cost-cutting by reducing the design effort and im-provement of software reliability.

After the acquisition of the high-level service re-quirements, a grouping into self-contained functionalblocks has to be performed, resulting in a service de-scription consisting of service features. This processwill be relatively straightforward where the service iscomposed from sequences of call routing features, asis the case for telemarketing services such as Ad-vanced Freephone. However, in cases where a serviceis composed from a set of independently accessiblefeatures (such as Short Code Dialling, Diversion, etc.)in a Centrex Service, it will be necessary to describethe service as a parallel composition of the componentservice features. A particular mechanism for thisparallel composition will then be required, and willvary between implementations.

2.2.4 Formality

Formality plays an increasingly important role insoftware design and modelling. As the size of softwareprojects increases, tool support becomes essential.Formality offers many advantages such as automatedanalysis and verification of specifications and designsteps with mathematically clear proofs, automatedcode and test case generation, as well as concise de-scriptions of the intended software system.

One of the aims of the RATS tool is to make thetransition from informality to formality easier by in-serting semi-formal steps. Only the combination of theexpressiveness of informal, natural language, theclearness of semi-formal methods and the precision offormal languages can ensure high quality software.

The first step towards formality is accomplished inour methodology by assigning each requirement to acertain sub-class (functionality, topic, goal, informa-tion, implementation constraint). This channels thefurther development of each specific requirement (seeFigure 4) and is a means of providing requirementspecific guidance.

The functional requirements are specified using ause case design process which gradually increases theformality (see Section 2.3.3) and enables a smoothtransition to a fully formalised service specificationusing SDL.

2.3 Low-level development

2.3.1 Requirements documents

Unlike current practice, our methodology is notdocument-based, but requirements-based. The advan-tage of a requirements-based approach is its flexibilityand emphasis on requirements development, manage-ment and traceability. The document-based approachlacks these characteristics which is an obvious weak-ness of the current practice. However, as requirementsdocuments play a crucial role as basis for contracts,they cannot be avoided. Our approach tries to bringthe advantages of both ideas together by being re-quirements-based but providing facilities for docu-ment generation. A requirements document is, in theend, a structured collection of requirements containedin the knowledge base of the RATS tool.

2.3.2 Development of non-functional requirements

The design of non-functional requirements (NFRs)is a topic on its own. There are very sophisticated ap-proaches available [Chu93, Dar93a]. However, theirpracticability has not been proven in real world proj-ects of a larger scale. This approach uses a simplified

version which is however applicable for large-scalesoftware projects.

Using an object-oriented approach, we define a re-quirements sub-class hierarchy part of which can beseen in Figure 13 in the Appendix. Each instance ofrequirement has to be additionally an instance of oneof these sub-classes. During the development of re-quirements, only certain transitions are allowed thusrestricting and directing the NFR development. Theassumption behind these transition restrictions is thateach subclass is connected with a certain level of ab-straction. A requirement can then only change itssubclass during the development process if the transi-tion leads to a NFR subclass with either the same levelor a lower level of abstraction than the current sub-class. Additionally, the transition needs to be mean-ingful from a methodological viewpoint. At last, eachNFR has to be satisfied by one or more implementa-tion constraints or functional requirements. These as-sumptions and rules lead to the transition diagram forNFRs shown in Figure 4.

Figure 4: Possible transitions in the NFR devel-opment process

2.3.3 Development of functional requirements

Functional requirements are developed with usecases which have become a very popular concept insoftware engineering. Most of the commonly usedobject-oriented analysis (OOA) methods such asOOSE [Jac93], OMT [Rum91], Booch [Boo94],ROOM [Sel94] and Fusion [Col94] have been ex-tended to incorporate use cases or scenarios. Casestudies have shown that use cases and scenarios are avery natural way of describing requirements [Dar93b].We found use cases not only very suitable for theelicitation and notation of requirements, but also as anexcellent means of bridging the gap between infor-mality and formality.

The lack of formality in use case design has alreadybeen pointed out, and some suggestions for improve-ment have been made [Hsi94, Reg95, Reg96]. Wehowever, are not only interested in introducing for-mality in use case design in order to give them a for-mal basis, but in using them as a means to make thetransition to a formal service specification in SDL

easier. Our approach, therefore, tailors use cases to-wards the SDL notation (see Figure 5 and 6). An in-crease in practicability has be achieved by implement-ing our use case modelling approach in the RATStool, thus providing active support to the service de-signer.

Three kinds of use cases are employed in the RATSmethodology. Each kind is organised in an overallstructure showing how the individual use cases makeup the overall behaviour of the system. Initially, thebehaviour is described with textual use cases, whichare then translated into structured use cases which inturn form the basis of the formalised use cases. Thenotation of the latter is geared towards an easy trans-lation of the specification into SDL which is the basisfor fully formalised specification, analysis, simulation,validation, automatic code and text case generation.

The following gives an outline of some of the usecase attributes. Textual use cases consist of:• use case title• involved actors• use case description

Structured use cases contain additionally the fol-lowing attributes:• use case summary• precondition• flowcondition• postcondition

Formalised use cases contain all the above men-tioned attributes, however the use case description isreplaced by a chain of atomic actions. Each atomicaction has three attributes:• one single actor• kind of action (input, output, system operation)• description of action

The system specification using structured use casesis one of the major milestones in the developmentprocess. Constraints ensure that the postcondition ofone use case, and the precondition of the immediatelyfollowing use case are identical. Organising use casesinto overall use case structures can be seen as a bot-

Figure 5: Use case design in RATS

tom-up approach, suitable to detect gaps and incom-pleteness.

The formalised use case version is oriented towardsthe SDL specification language. Some concepts of theformalised use case specification can be directlymapped into SDL. Figure 6 gives a few examples howthis can be achieved using the graphical version ofSDL:

Figure 6: Mapping of formalised use cases to SDL

Finally, use cases can be reused as test cases. Asthey describe the desired system behaviour, the finalspecification and implementation can be tested forcompliance with the initial requirements specified inuse cases.

2.4 Methodology guidelines

The methodology outlined here is based on thetheoretical framework of Figure 2. We make the as-sumption that the initial starting point of the servicedevelopment is an incomplete, informal, high-leveldescription of the desired service. The aim is a com-plete, consistent, fully formalised and refined specifi-cation. A further assumption is that the ideal servicedevelopment is along a straight line from this initialpoint in the development space to the desired endpoint. This has not been proven; however, real lifeexperience underlines the feasibility of this assump-tion.

The ideal line will never be achievable in practice.As shown in Figure 2, the actual service developmentlooks much more like a waved curve oscillatingaround the ideal line. The task of the methodologyguidelines is to ensure that the developer does notdiverge too far from the ideal line but stays as close aspossible to it.

Table 1 describes the actions to be performed stepby step by the service designer during service devel-opment. Further details are given in Section 4.4.4 inwhich we outline the implementation of the method-ology in the RATS tool. This implementation auto-

Action by Reason Document

outline service customer customer centred RE ICD1

brainstorming cust., RE eng.encourage innovation,increase completeness

BL2

evaluate brainstorming list (BL) cust., RE eng.increase agreement BLcategorise requirements RE engineer increase formality BLdefine service cust., RE eng.increase completeness SDT3

group requirements into self-contained functional blocks RE engineer preparation to find reusablefunctional blocks

SDT

add alternative behaviour RE eng., cust.increase completeness SDTdefine behaviour with textual use cases RE eng., cust.increase formality SDTrefine and decompose non-functional requirements and satis-fy them with textual use cases or implementation constraints

RE eng., cust.address non-functionalrequirements

SDT

organise textual use cases into overall use cases of textualuse cases

RE engineer better overview, bottom-upapproach, increase completeness

SDT

define states in the behaviour RE engineer improve structure, makes transla-tion into structured use cases easier

SDT

translate textual use cases into structured use cases RE engineer increase formality SDTorganise structured use cases into overall use cases of struc-tured use cases

RE engineer better overview, bottom-upapproach, increase completeness

SDT

add exceptional behaviour RE eng., cust.increase completeness SDTtranslate structured use cases into formalised use cases RE engineer increase formality SDTtranslate formalised use cases into SDL RE engineer increase formality SDT /

SDL-ToolSDL design service

designer,customer

formal analysis, verification,simulation, validation, testing,code generation

SDT /SDL-Tool

1 ICD : Initial Customer Description2 BL : Brainstorming List3 SDT: Service Definition Template

Table 1: Methodology guidelines for service development

matically introduces iterations in the life cycle whennecessary.

3. REQUIREMENTS MANAGEMENT

Requirements management is an important subjectin requirements engineering. It includes issues like theoverall definition of the requirements engineeringprocess as well as the integration of its phases, themanagement of unstable, evolving and changing re-quirements, documentation of decision rationale, re-quirements reuse, requirements documentation, impactassessment of changing requirements, traceability andso on. As some of these issues are described in other

sections, we want to focus here on how these charac-teristics are achieved within our methodology.

Many issues of requirements management are ad-dressed by the three kinds of requirements links shownin Figure 7 and Table 2.

History links show the historical development of arequirement. Each requirement has a history link to atleast that one requirement which initiated it. Historylinks need to be annotated with attributes like when,why and by whom the requirement was inserted intothe specification. This could be a different personfrom the person who actually stated the requirement(e.g. the customer) which is an attribute of each re-

Operation Description Old Requirement New Requirement Change of Linksin KB 1 in Doc2 in KB in Doc history logical structure

create create a new requirement n/a3 n/a yes op4 n/a op op

edit minor textual editing withoutrecording of the change

no no, n/a5 yes yes, op5 no no no, op

5

refine a parent requirement is refinedinto subrequirements

yes yes, n/a5 yes op yes yes op

collapse several similar requirements aresimplified into one requirement

yes no, n/a5 yes yes, op

5 yes yes yes, op5

replace6 a requirement is replaced by oneor more other requirements

yes no, n/a5 yes yes, op

5 yes yes yes, op5

delete a requirement has been rejected yes no, n/a5 n/a n/a no no yes, no

5

prune &craft

the location of requirements in arequirements structure is changed

n/a n/a n/a n/a no yes yes

createalternative

alternative ideas can be pursued yes yes, n/a5 yes op yes yes op

createparallel

behaviour

parallel behaviour is being defined yes yes, n/a5 yes op yes yes op

createexceptionalbehaviour

exceptional behaviour is beingdefined

yes yes, n/a5 yes op yes yes op

1 KB : Knowledge Base2 Doc: Document3 n/a: not applicable

4 op: optional5 depending on the original requirement6 similar to “edit” , however, the change is recorded

Table 2: Possible operations on requirements in RATS

Figure 7: Requirements links in RATS (example: UPT service)

quirement. Thus history links mainly provide the pre-traceability, i.e. the tracing back of a requirement tothe rationale, and persons behind it, and its develop-ment. This is illustrated in Figure 8.

Logical links may often be parallel to history links.However, their task is more forward oriented and re-lated to post-traceability. For instance they link up agoal with the functional requirements or implementa-tion constraints which satisfy it. This approach allowspost-traceability which goes beyond other work whichsees post-traceability only as “ those aspects of a re-quirement’s life that result from inclusion in the re-quirements specification” [Got94]. Post-traceability inRATS provides the necessary means for impactanalysis of requirements change, i.e. it shows all re-quirements which are logically affected by a changeof the requirement concerned.

Structure links have the task of organising re-quirements into requirements structures. A require-ments structure can be a document, an overall usecase, a service or service feature. With the help ofthese links, requirements can be included in require-ments structures, thus facilitating documentation de-spite the chosen requirements-based approach. Thislink provides the necessary means to insert, delete andprune&craft requirements in a structure.

4. THE RATS TOOL

4.1 Overview of the RATS tool

The increase of complexity and diversity of thetelecommunications network makes it difficult for aservice developer to have adequate understanding ofthe infrastructure supporting the range of differentservices. These characteristics, however, are highlyrelevant to the analysis of service requirements andmust be taken into account if the requirements are tobe implementable. We decided, therefore, to use aknowledge based approach as the basis of the RATStool. The knowledge base comprises two parts:

• the main characteristics of the telecommunicationsdomain,

• information about the employed developmentprocess methodology.

The trade-off of this approach is that changes in thedomain models and the development processes (i.e.the higher layers of the models) involve considerableeffort. However, major changes to network character-istics and development processes do not occur as fre-quently as commercial services are launched. For in-stance, the ISDN network infrastructure has been de-veloped and deployed over a period of more than tenyears and now supports more than 30 service features,such as Diversion features and Call Completion toBusy Subscriber (CCBS).

Requirements Acquisit ion and Specification Implementation

history link is not part of trace

history link is part of trace

requirement is not part of trace

requirement is part of trace

requirement whose history is to be tracedstakeholder to be consulted

stakeholder not affected

R15

R16

R6

R5

R4

R1

C4

R10

R14

R13

R12

R11

R8

R7

R9

R2

R3C5

C3

C2

C1

Figure 8: Pre-traceability in RATS

The knowledge contained in RATS is expressed ina knowledge representation language called Telos[Myl90]. It integrates an axiomatised object-orientedkernel with a predicative assertion language. A partialversion of Telos is implemented in an experimentaldeductive object base management system calledConceptBase [Jar93, Jar96] which is the tool withwhich RATS has been developed.

Next to the knowledge relevant to service devel-opment, RATS contains layers providing intelligenceon several levels of abstraction. A graphical user inter-face (GUI), an inference engine, as well as a framegenerator, make the tool more user friendly. The ar-chitecture of the RATS tool is shown in Figure 9.

4.2 The domain models

As has been mentioned above, the domain modelscontain the main characteristics of the telecommuni-cations domain, conceptually expressed in Telos. Cur-rently, the still incomplete RATS prototype containsinformation from more than 80 recommendations andstandards.

Due to a clear separation of the development anddomain models, a great variety of models can be usedwithin RATS. Three different kinds of models can bedistinguished according to their source:

• Standards: These models are very detailed andbased on standards, i.e. can be seen as electronicversions of standards and are suitable for teachingpurposes.

• Expert knowledge: Such kinds of models are builton knowledge of experts. They are often very dif-

ferent to standards and are probably the most suit-able ones for RATS as they reflect ‘real-world’situations.

• ‘Quick models’: These models contain only theinformation which is absolutely essential to sup-port the service design process.

This shows that the RATS tool can accommodatevery different kinds of domain models which mighthave been created by different people for differentpurposes. This is possible by introducing a negotiationlayer (see Section 4.5) between the domain modelsand the development models.

In Figure 9 several aspects of the telecommunica-tions domain are mentioned:

• Customer Profile: This database contains infor-mation about the customer himself, the subscribednetworks, the subscribed bearer, tele- and supple-mentary services, his interface structure, his prem-ises equipment (CPE) and the local exchange he isconnected to.

• Customer Premises Equipment (CPE): Severalkinds of CPEs (e.g. PABX, ISDN- or analoguetelephone, LAN) are described within the CPEknowledge base as well as their reference points(e.g. R-, S-, T-Interface for ISDN) and the func-tionality they contain (e.g. TE1/2, TA, NT1/2 forISDN).

• Network Transport Capability: This knowledgebase contains the characteristics of different kindsof networks. In the case of ISDN, it can contain in-formation about generic network characteristics as

Figure 9: The RATS tool architecture

well as recommended and available basic networkservices. Network service interworking issues areincluded here.

• Supplementary Services: Here information aboutthe supplementary services, their main character-istics as well as their specifications is available. Incase the service provider offers many intelligentnetwork (IN) services, it might contain parts of theIN architecture.

• Feature Interaction: This is a very important topicwhich if not considered can have devastating ef-fects on the network [Bou94b]. Different levels ofsophistication can be introduced. A simple ap-proach is to store only known feature interactionsin this knowledge base. A more sophisticated ap-proach assigns characteristics to services andpoints out suspicious feature combinations.

• Network Interworking: The increasing variety ofnetworks, demands facilities for interworking be-tween networks. Interworking possibilities need tobe specified and stored in this knowledge base.

• Switch: As long as the intelligent network conceptis still not extensively implemented, switch-basedservices play a crucial role. The different types ofswitches, as well as their services, are stored here.

• Data Dictionary: The data dictionary is part of theformalisation process. All people involved inservice design need to assign the same meaning tothe terms used. This is done with the help of thedictionary.

4.3 The development models

The development models form the underlyingstructural concept of the development methodology.Several viewpoints of it have already been described.The overall context is shown in Figure 1, the theoreti-cal framework is outlined in Figure 2, a document-based view is given in Figure 3, and the practical stepsto be performed during service design are described inTable 1. Further issues like the intelligence and thenegotiation process are outlined in Sections 4.4 and4.5.

The development models contain complex object-oriented class hierarchies. The models are orientedtowards the conceptual inheritance of the modelledentities rather than the development process (cf. Sec-tion 4.4.1.2). This increases reusability and providesgeneric templates but does not allow a great deal ofprocess guidance. We, therefore, generated specificmodels contained in the intelligence layer (see Sec-tion 4.4) which gives detailed advice to the developer.

4.4 The intelligence layer

4.4.1 Intelligence implementation using Telos

This section is to briefly outline the possibilitiesavailable to implement intelligence within a Telossystem.

4.4.1.1 Passive guidance

Passive guidance is a basic, but essential means toprovide guidance during development. The followingconcepts are rigid constraints which prevent the in-sertion of inconsistent objects into the knowledgebase:

• Object-orientation: Conceptual, object-orientedmodelling using formal languages with their fea-tures of inheritance, classification, specialisationand instantiation is a means for some basic formsof intelligence.

• Telos axioms: Telos and its implementation in theConceptBase tool contain several axioms whichare automatically enforced as soon as an object isinserted into the knowledge base. Constructs notcomplying with these rules are rejected.

• Permanent user-defined constraints and rules:The created domain and development modelscontain a large number of permanent, user-definedconstraints and rules which ensure model consis-tency and help in the correct development of serv-ices.

However, such rigid constraints are only desired forserious consistency violations. Some inconsistencies(especially incompleteness) can be temporarily ac-ceptable or even desirable [Fin94]. To accommodatethis, there also need to be soft constraints:

• Temporary user-defined constraints and rules: Aset of user-defined constraints and rules are avail-able but only triggered at certain milestones of thedevelopment life cycle, in order to check consis-tency and completeness.

• Meta-rules and state-classes: The RATS toolcontains, at a high layer of the models, genericmeta-rules which assign an object to certain state-classes showing the state an object is currently inwith respect to the development process.

Passive guidance is very important, but its capa-bilities are limited. It can only state: “Don’t do that!”However, what is expected from an expert system isthe additional feature of active guidance: “Do this!”

4.4.1.2 Active guidance

There are again several means by which activeguidance can be achieved using Telos. Some of thepossibilities are briefly outlined here:

• Strings assigned to classes: The classes of the de-velopment models contain strings which point outthe next steps which normally have to be per-formed. However, this allows only general guid-ance as it is connected to a class and not to the cur-rent state of a specific instance.

• Guidance derived from development models:Some rough guidance can be derived from the de-velopment models. However, this demands modelswhich are oriented towards the development proc-ess rather than the conceptual inheritance of char-acteristics (cf. Section 4.3). In some cases, thesetwo aspects might be the same; however, this can-not generally be assumed.

• Special attributes pointing to the next object:Special attributes can be created which point to theobject to be dealt with next. This is similar to theprevious possibility, except that it gives more free-dom for the conceptual model.

• Intelligence models using rules and intelligenceobjects: The most general approach for activeguidance involves the creation of special intelli-gence models. Rules assign intelligence objects tospecific instances of any requirements object de-pending on the actual state of this particular in-stance. Complex rules have to be created in orderto allow such individual, active guidance (cf.Figure 10).

• Parameter rules and queries for intelligence ob-jects: Queries for possible parameters for the in-telligence objects can be defined.

4.4.2 Intelligence implementation in the RATS tool

Figure 10 shows the general principle by which in-telligence models are implemented within RATS.Several pools exist containing intelligence objects,intelligence rules, parameter queries and parameterrules.

The intelligence rules assign the appropriate intelli-gence object to any requirements object (e.g. goal, usecase) depending on its current state. Using a genericquery all the intelligence objects assigned to a certainrequirements object can be retrieved. The intelligenceobjects contain the necessary information to furtherdevelop the requirements object. In some cases theintelligence objects have associated parameter querieswhich give more details with the help of further rules.

The domain knowledge and the development mod-els of RATS form the fundament of the RATS tooland are used by the intelligence layer which itself issplit into two parts providing guidance at two differentlevels of abstraction: at a lower level, object relatedguidance, and at a higher level, methodology relatedguidance. These levels are further explained in thefollowing sections.

4.4.3 Object related guidance

Object related guidance is concerned with intelli-gence for the concepts at a low level of abstraction(e.g. documents, goals, use cases). The service de-signer can ask the tool how he should proceed with anindividual instance of any requirements object andwill receive object specific instructions.

In order to illustrate how RATS offers object re-lated guidance by combining the approaches men-tioned in Section 4.4.1, we use a simple example:

Let us assume, the Universal Personal Telecom-munication (UPT) service is to be defined. Object-orientation and Telos axioms ensure that the defini-tion is an instance of the class ServiceDefini-tionTemplate (which is a sub-class of Require-mentsDocument) in order to enable the inheritance ofits attributes. Let us say that this document still con-tains some requirements which have not yet got thestatus agreed. Meta-rules and state-classes informthe designer that there is still something wrong withthis document and hence the document is assigned tothe state-class InconsistentObject. Intelligencemodels using rules and intelligence objects point outto the designer that he should try to get the statusagreed for all requirements in this requirementsdocument. Parameter rules and queries for intelli-gence objects point out which particular requirementsstill need to get the status agreed (e.g. UPTPT7 in

Generic Query:“ What to do next?”

Pool ofParameterRules

Pool ofIntelligenceRules

RequirementsObject

Get status ‘agreed’ forall requirements in thisrequirements document.

Telos object

UPTPT7

Pool ofParameterQueries

PInt1

PInt3

PInt4

Pool ofIntelligenceObjects

Int1

Int2

Int3

Int4

Figure 10: Implementation of intelligence modelswithin RATS

Figure 10). In case the designer ignores these mes-sages and tries to assign the status agreed to thewhole document (even if it still contains requirementswithout the status agreed), permanent user-definedconstraints and rules will reject this attempt.

4.4.4 Methodology related guidance

Methodology related guidance is implemented in away similar to object related guidance. However, itsbackground and task are different: While object re-lated guidance is concerned about conceptual issues ofa lower layer, methodology related guidance dealswith methodological issues of a higher layer. It assistswith the overall service design guiding the designerthrough the development process of the whole service.

RATS contains the implementation of the method-ology, the theoretical framework of which is shown inFigure 2, and guidelines described in Table 1.

Each row in Table 1 represents a state in the devel-opment life cycle. The current state of the develop-ment process is determined by rules. Transitions fromone state to the next are achieved by performing ap-propriate actions. An important advantage of this ap-proach is the benefit of automatic process iteration. If,for instance, a service has already been specified usingstructured use cases and the customer wants an addi-tional requirement to be included, rules will automati-cally initiate re-engineering of the service from theappropriate point of the life cycle. Depending on thekind of change, the re-engineering has to start at dif-ferent stages in the life cycle (see Figure 11). Addinga high-level non-functional requirement to an alreadyexisting requirements specification will cause a fall-back to a very early stage, while adding a minor low-level functionality (e.g. change of an announcement)will only set back the development process by a fewstates. This automatic iteration process to the nearestpossible state in the life cycle, is an excellent meansof ensuring that the re-engineering effort is kept to aminimum.

4.4.5 Intermodel consistency

Another task of the intelligence layer is to ensureintermodel consistency. Rules are used to guaranteemeaningful usage of the libraries contained in the in-dependently of each other created domain models,taking care that the elements used from different do-main libraries fit together. The following few linesshow a Telos rule in frame syntax ensuring that onlysuch basic network services are specified in a servicedefinition which are also offered by at least one of thechosen networks:

NetworkAndBasicServicesFitTogether_rule:$forall f1/ServiceDefinitionTemplate (exists e1,e5/NegotiationObject e2/NW e4/Library (f1 containsNetwork e1) and (f1 containsBasicServices e5) and (e1 linksToLibrary e2) and (e5 linksToLibrary e4) and not(exists e3/BasicNWService (e2 offers e3) ==> (e4 in e3)))==> (f1 IntelligenceObject Int25)$

4.5 The negotiation layer

In order to enable the use of different kinds of do-main models (see Section 4.2) and to offer active, do-main specific guidance, there needs to be an interfacebetween the development models and the domainmodels. This interface is provided by the negotiationlayer. Intermodel consistency could be another task ofthis layer, however, RATS provides this in the intelli-gence layer (see Section 4.4.5).

Despite informal negotiation being very much partof everyday life, negotiation behaviour during re-quirements specification has not yet been exploredvery well [Rob90]. In this case, a relatively simpleapproach is taken.

Negotiation objects: These objects are a sub-classof the class Requirement. They therefore inherit allcharacteristics of this class but represent a specialfunction in the chain of requirements development.From a requirements management viewpoint they arethe “end” of a chain of requirements, i.e. they link toan object in one of the domain models. These nego-tiation objects play a distinct role as they have to per-form the connection between the development processand the different kinds of domain models thus allow-ing a clear separation between the models.

Keywords: The negotiation process itself is similarto the problem of software reuse [Bel93]. In our case,keywords of three different categories (see Figure 12)are employed, supported by two kinds of meta-attributes which can reuse already existing domainobjects, or allow new keywords to be inserted.

Action 4

Action 5

Action 6i teration for low-level requirementschange

iteration for high-level requirementschange

State 7

State 6

State 5

State 4

normal development

iterative development

Figure 11: Development process iterations

• Description: This meta-attribute allows a textualdescription to be assigned to each object. This canbe, for example, a textual description of a teleserv-ice. The string contained in this description can beused for a keyword search. The advantage of thisapproach is that already existing objects of thedomain models can be reused.

• KW: The second meta-attribute is the KW-attribute. It also allows reuse of existing domaininformation by just adding a KW-link between theobject to be characterised and the characterisingobject.

There is one major impact on the domain modelswhich they have to comply with in order to enableRATS to actively support this negotiation process. Asthe negotiation process is done by a string comparisonbetween the desired keywords provided by the servicedesigner and the keywords assigned to existing do-main objects, the keywords need to be expressed inpositive terms. This can be expressed with the term“positive modelling” which means that the keywordsmust not contain any negative expressions but onlypositive characteristics of the objects to be described.

4.6 RATS Implementation and perform-ance

As has been mentioned earlier, the RATS tool isimplemented in a knowledge representation languagecalled Telos using a deductive object base manage-ment system called ConceptBase. ConceptBase canrun on a UNIX platform or an Intel-PC running So-laris 2.4 or higher. Over recent years, ConceptBasehas been drastically improved, both in stability andperformance. Nevertheless, it still contains only a sub-set of the concepts of the powerful Telos language andstability needs further improvement.

Performance is another issue. The current, incom-plete RATS prototype has a size of about 1.8 MBytes,and contains altogether some 290 user-defined rulesand 63 user-defined constraints. Rules are an excellentmeans to automatically assign redundant informationto other objects. However, they drastically slow downthe performance, especially if rules use informationwhich has to be retrieved by other rules. Such chainsof rules must be avoided. Recursion can provide verygood facilities for queries, however, it also slowsdown the performance of RATS remarkably.

During modelling, a compromise needs to be foundbetween

• nice, proper and modular modelling using the fullrange of Telos features, and

• acceptable performance.

As soon as the models get larger, a very fundamen-tal rule has to be considered: applications need to becharacterised by many classes (hundreds to thousands)but not many instances in each class [Jar93]. This de-mands a trade-off between generic modelling allowinga high degree of reusability and performance on theother hand. The more general the class-models are, themore instances they will contain and the lower theperformance will be. Especially in requirements engi-neering, where there might be many thousands of re-quirements (i.e. instances in the class Requirement),performance will be an issue of concern.

On the other hand the acceptable response time ofan expert system is relatively small. Our own experi-ence shows that most queries need to be answeredwithin 5 secs to give the system user the necessaryfeeling of satisfaction. The maximum tolerable re-sponse time is around 20-30 secs. But queries can veryeasily be created which need much longer.

Individual ISDN in NW with offers,attribute ISDNoffers : BasicISDNService accessibleVia,attribute ISDNaccessibleVia : UserISDNInterface description,KW,attribute description1 : "Integrated Services Digital Network" KW,attribute Keywords1 : "voice, 3.1kHz, 7kHz, 15kHz, audio, available, circuit-swiched, digital, tones, announcements, sound, text, facsimile, fax, videotex"; Keywords2 : 64kbps; Keywords3 : Speech; Keywords4 : Video; Keywords5 : Demand; Keywords6 : Permanent; Keywords7 : Reservedend

Figure 12: Usage of keyword categories in RATS (example: ISDN; meta-attributes in bold)

Keywords of category 1:reuse of existing domain object descriptions

Keywords of category 2:reuse of existing domain objects

Keywords of category 3:new strings added into domain models tocharacterise domain objects

5. FORMAL REQUIREMENTS SPECI-FICATION

5.1 Formal specifications

SDL has been developed for use in telecommuni-cation networks, systems and protocols but can, ingeneral, be applied to all real-time, interactive anddistributed systems for the description of system be-haviour and structure on all levels of abstraction. Thelanguage has been developed and standardised by theInternational Telecommunication Union (ITU) overseveral years in [Z.100]. The basis for description ofbehaviour is extended state machines which commu-nicate with each other and with the environment viasignals. There are three main components to the lan-guage:

• System behaviour: The behaviour of the system isdescribed by a set of SDL processes. Each processis defined as an extended finite state machine, thatworks autonomously and concurrently with otherprocesses. Communication between processes isperformed asynchronously by signals.

• System structure: There are comprehensive con-structs to describe the structure of systems in orderto cope with complexity. A system contains one ormore blocks interconnected with each other andwith the environment by channels. A block canagain be partitioned into sub-blocks, creating a hi-erarchical block tree structure. Later versions ofSDL additionally support object-oriented structur-ing concepts.

• Abstract data: All data types, predefined as well asuser-defined, are specified in an implementation-independent way only in terms of their properties.They describe data which is exchanged with thesystem and which is stored and manipulated by it.

SDL supports service specification by providingclear and complete behaviour descriptions and hasbeen extensively used to develop rigorous specifica-tions of telecommunications services and protocols[Cro93].

5.2 Analysis, simulation and validation offormal specifications

Good quality commercial tools are now availablewhich allow checking of SDL descriptions. Checkingcan include static properties, such as

• all the attributes have been defined• interfaces are used consistently

Dynamic properties of SDL specifications can alsobe checked by simulation, showing that the functionalrequirements are satisfied. This checking could beapplied to SDL representing service components at theservice and service feature level of refinement, provid-ing the opportunity to validate these descriptions at anearly stage.

SDL has also been used to analyse groups of tele-communications services for interaction problems. Anexample, documented in [Kel95], describes an analy-sis of models of UPT service features. The UPT fea-ture models were pair-wise tested against models ofswitch-based call completion features. The analysisdetected 16 feature interaction problems which couldthen be resolved in the subsequent service implemen-tation.

5.3 Implementation and testing

SDL specifications of services and service features(SFs) can be used as part of the implementation proc-ess to obtain service platforms offering the requiredcomponents. If the service platform is procured from athird party, the SDL would form part of the require-ments specification. If the service platform is an in-house development, the SDL would form an input tothe project developing the required components.

Having procured a service platform, the requiredSFs would be constructed using a service creation toolappropriate to the particular platform. The behaviourof the SF could then be tested against the higher leveluse case specification of that SF’s behaviour whichwas produced during requirements development. Af-terwards, the required service can be constructed byprovisioning the right combination of SFs for custom-ers.

Even if more classical software development tech-niques are to be employed, the SDL descriptions ofservices and service features will provide unambigu-ous specifications for these developments as well.

Finally, the complete service implementation canbe tested against the service level use cases (see Sec-tion 2.3.3), whose development from the initial re-quirements can be traced. Additionally, some of theSDL tools automatically generate test cases to be runagainst the specification and implementation of thesystem. So the cycle of service development is com-plete, and we can assess the conformance of the serv-ice to the initial requirements, because key steps in thetraceable development of requirements are describedformally, supporting testing.

6. CONCLUSION AND FUTURE WORK

RATS is an attempt to combat the problem of re-quirements engineering for telecommunications serv-ices. It is not a solution to all the issues raised in thispaper. However, its approach and initial results arepromising. The knowledge based approach to RATSgives it a stable basis providing many opportunitiesfor active assistance.

The novelties of the described approach can besummarised as follows:

• The methodology outlines an overall life cycle of asystem, starting at the initial customer idea andleading to the testing of the implementation.

• Requirements are captured freely from customersand a best fit with the existing infrastructure isachieved by a semi-automated negotiation processencouraging reuse of existing components.

• The transition from an informal to a fully formalsystem specification, is done in a smooth andgradual manner.

• Very different kinds of requirements are treateduniformly and in electronic format allowing im-proved requirements management facilities. Aprocess for decomposition of non-functional re-quirements is included.

• The methodology can be integrated into existingservice development life cycles and has continuoussupport by tools.

Despite focusing on the telecommunications do-main in this paper, it can be said that the RATS meth-odology is essentially generic and can be used for thedevelopment of many different kinds of real-timesoftware systems specifiable in SDL. Also the RATStool is partly generic with only the lowest layer of thetool (see Figure 9) being domain specific. The domainknowledge of the present version of the RATS tool isgeared towards the intelligent network architectureand the ISDN network; however, many different do-mains can be conceptually modelled and used in theRATS tool.

Although the RATS methodology has reached acertain degree of maturity, the implementation of themethodology in the RATS tool is not yet complete.More domain specific help could be provided to thedesigner if more domain models were contained in theRATS tool. Additionally, the graphical user interface,the inference engine and the frame generator requirefurther work before a more comprehensive case studycan be done. This will also help to make more obviousany possible performance problems.

Acknowledgements

The authors are grateful to British Telecom forsupporting this research, especially to Kevin Woollardand Michael Crowther for many helpful discussions.The authors also thank Prof. M.G. Rodd for his en-couragement to publish this paper as well as theanonymous referees for their valuable comments andsuggestions on an earlier version of this paper.

REFERENCES

[Bal78] Balzer R., Goldman N. and Wile D. Infor-mality in Program Specifications, IEEE Transactionson Software Engineering, 4, (2), pp. 94-103 (1978).

[Bel93] Bellinzona R., Fugini M.G. and Demey V.Reuse of Specifications and Designs in a DevelopmentInformation System, IFIP Transactions A - ComputerScience and Technology, 30, pp. 79-96 (1993).

[Boe84] Boehm B.W. Verifying and ValidatingSoftware Requirements and Design Specifications,IEEE Software, 1, (1), pp. 75-88 (1984).

[Boo94] Booch G. Object-Oriented Analysis andDesign with Applications, Benjamin/Cummings Publi-cations (1994).

[Bou94a] Boullier L., Kelly B., Phalippou M.,Rouger A. and Webster N. Evaluation of some TestGeneration Tools on a real Protocol Example, Pro-ceedings of the Seventh International Workshop onProtocol Test Systems (1994).

[Bou94b] Bouma L.G. and Velthuijsen H. FeatureInteractions in Telecommunications Systems, IOSPress, Amsterdam, The Netherlands (1994).

[Bub95] Bubenko J. A. Challenges in RequirementsEngineering, Proceedings of the Second IEEE Inter-national Symposium On Requirements Engineering,York, U.K. (1995).

[Chu93] Chung L. Representing and Using Non-Functional Requirements: A Process-Oriented Ap-proach, PhD Thesis, University of Toronto, DKBS-TR-93-1 (1993).

[Chu95] Chung L., Nixon B. and Yu E. Using Non-Functional Requirements to Systematically SelectAmong Alternatives in Architectural Design, Proceed-ings of Seventeenth International Conference on Soft-ware Engineering (ICSE-17), Workshop on Architec-tures for Software Systems, Seattle, Washington(1995).

[Col94] Coleman D. Object-Oriented Development- The Fusion Method, Prentice Hall (1994).

[Coo93] Cookson M.D. and Woodsford, S.G. De-sign Methodology using SDL, BT Technology Journal,11, (4), pp. 16-24 (1993).

[Cro93] Crowther M. Modelling and Validation ofTelephony Network Signalling, Proceedings of SDLForum (1993).

[Dar93a] Dardenne A., Fickas S. and van Lam-sweerde A. Goal-Directed Requirements Acquisition,Science of Computer Programming, 20, pp. 3-50(1993).

[Dar93b] Dardenne A. On the Use of Scenarios inRequirements Acquisition, University of Oregon,Technical Report, CIS-TR-93-17 (1993).

[Dav93] Davis A.M. Software Requirements - Ob-jects, Functions and States, Prentice Hall (1993).

[Eng95] English E. Industry Trends, IEEE Com-puter, 28, (8), p.14 (1995).

[Fin94] Finkelstein A., Gabbay D., Hunter A.,Kramer J. and Nuseibeh B. Inconsistency Handling inMulti-Perspective Specifications, IEEE Transactionson Software Engineering, 20, (8), pp. 569-578 (1994).

[Got94] Gotel O. and Finkelstein A. An Analysis ofthe Requirements Traceability Problem, Proceedingsof the First International Conference on RequirementsEngineering, Colorado Springs (1994).

[Hsi94] Hsia P., Samuel J., Gao J., Kung D.,Toyoshima Y. and Chen C. Formal Approach to Sce-nario Analysis, IEEE Software, 11, (2), pp. 33-41(1994).

[Jac93] Jacobson I. Object-Oriented Software En-gineering - A Use Case driven Approach, Addison-Wesley (1993).

[Jar93] Jarke M. Eherer S., Gallersdörfer R., Jeus-feld M. and Staudt M. ConceptBase - A DeductiveObject Base Manager, University of Aachen, Ger-many, (1993).

[Jar96] Jarke M., Jeusfeld M. and Staudt M. Con-ceptBase V4.1 User Manual, http://www.i5.informatik.rwth-aachen.de/CBdoc/userManual/,(1996).

[Kel95] Kelly B., Crowther M., King J., Masson R.and DeLapeyre J. Service Validation and Testing, ,Proceedings of Feature Interactions in Telecommuni-cations Systems, KYOTO'95 (1995).

[Lub93] Lubars M., Potts C. and Richter C. A Re-view of the State of the Practice in RequirementsModelling, Proceedings of the First InternationalSymposium on Requirements Engineering, San Diego,CA (1993).

[Myl90] Mylopoulos J., Borgida A., Jarke M. andKoubarakis M., Telos: A language for representingknowledge about information systems, ACM Transac-tions on Information Systems, 8, (4), pp. 325-362(1990).

[Myl92] Mylopoulos J., Chung L. and Nixon B.Representing and Using nonfunctional Requirements:A Process-Oriented Approach, IEEE Transactions onSoftware Engineering, 28, (6), pp. 483-497 (1992).

[Poh94] Pohl K., The three Dimensions of Re-quirements Engineering - A Framework and its Apli-cations, Information Systems, 19, (3), pp. 243-258(1994).

[Q.12xx] Q-Series of ITU-T Recommendations onIntelligent Networks.

[Rau94] Rauterberg M. and Strohm O. About theBenefits of User-Oriented Requirements EngineeringProceedings of the First International Workshop onRequirements Engineering: Foundation of SoftwareQuality, Utrecht, Netherlands (1994).

[Ree92] Reed R., Bouma W., Marques M.M. andEvans J. Methods for Service Software Design, Pro-ceedings of the Eighth International Conference onSoftware Engineering for Telecommunication Systemsand Services, Florence, Italy, pp. 127-134 (1992).

[Reg95] Regnell B., Kimbler K. and Wesslén A.Improving the Use Case Driven Approach to Re-quirements Engineering, Proceedings of the SecondIEEE International Symposium on Requirements En-gineering, York, UK (1995).

[Reg96] Regnell B., Andersson M. and BergstrandJ. A Hierarchical Use Case Model with GraphicalRepresentation, Proceedings of the IEEE InternationalSymposium and Workshop on Engineering of Com-puter-Based Systems, Friedrichshafen, Germany(1996).

[Rob90] Robinson, W. N. Negotiation BehaviourDuring Requirements Specification, Proceedings ofthe 12th IEEE International Conference on SoftwareEngineering, Nice, France (1990).

[Rum91] Rumbaugh J. Object-Oriented Modellingand Design, Prentice Hall (1991).

[Sel94] Selic B., Gullekson G. and Ward P. Real-time Object-Oriented Modeling, Whiley&Sons (1994).

[TTN] Testing Techniques Newsletter, SoftwareResearch, Inc., 625 Third Street, San Francisco, CA94107-1997, USA, ttn@soft.com,http://www.soft.com

[Z.100] ITU-T Recommendation Z.100 CCITTSpecification and Description Language (SDL),(1994).

Authors’ Biographies:

Armin Eberlein graduated with a Diplom-Ingenieur (FH) from the “Fachhochschule für Technik” in Mannheim,Germany in 1993. He then spent some time working as hardware and software developer in Siemens in Munich, Ger-many. This was followed by a postgraduate course in Communication Systems at the University of Wales, Swansea,UK, leading to a Master's degree. He is currently a senior research assistant as well as studying for a PhD also inSwansea. His research is sponsored by British Telecom and concerned with formal methods in system design, AI intelecommunications and new methodologies for service design.

Fred Halsall is Professor of Communications Engineering at the University of Wales, Swansea and head of theCommunications Research Group. The Group is involved in research in computer network modelling, software engi-neering, and high bit rate data transmission over radio. He has published widely in these and related areas. He is aFellow of the IEE.

APPENDIX

Figure 13: Parts of the object-oriented requirements subclass hierarchy