Telecommunications service development: a design methodology and its intelligent support

Armin P.-G. Eberlein Department of Electrical & Electronic Engineering, University of Wales Singleton 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 Wales Singleton 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: refinement, completeness and formality, aiming for a complete, consistent and formally specified service definition. The described methodology can be integrated into currently existing development life cycles which employ formal methods for service creation. Active support for the proposed life cycle is provided by a novel expert system called Requirements Assistant for Telecommunications Services (RATS) currently under development. It actively helps during requirements acquisition and early analysis, and encourages specification reuse with the help of a semi-automated negotiation process. The RATS tool advises the service developer during all stages of the service development and on different levels of abstraction, and provides requirements management facilities, like traceability, impact analysis and document generation. Some of the features are illustrated using examples from the Universal Personal Telecommunication (UPT) service. Keywords: Expert system, telecommunication, service design, design methodology, formal methods, requirements engineering.

1. INTRODUCTION
Errors in requirements specifications have a significant effect on software costs and customer satisfaction. It is now widely accepted that errors associated with requirements specification are the most numerous, 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 spent on cancelled software projects in the USA in 1995 alone. Other less well-referenced studies [TTN] claim that 80% of all defects are inserted in the requirements phase. These examples show the importance of requirements engineering. More than the usual 10% of the project duration [Lub93] needs to be spent on the requirements phase in order to combat the immense project costs, delays and even failures. Moreover, for distributed systems, comprising many interacting subsystems, this figure should be significantly larger.

Two of the most important factors which determine the correctness of a software system are the quality of the requirements specification, the quality of the transformation of the requirements specification into a concrete software system. This paper is primarily concerned with requirements acquisition, specification and implementation of telecommunications services. Keeping in mind that the telecommunications network is, in practice, one large distributed system with 70% of its design effort belonging to the software engineering domain [Ree92], requirements engineering for telecommunications systems and services is a challenging task. Currently, the major problem is not how to find new service ideas, but rather how to capture all the requirements of the new service, specify them in a formal way and ensure that the new service does not interfere with already existing services [Bou94b]. The lack of adequate CASE tools [Bub95] for require-

ments engineering means that issues such as requirements traceability and documentation of rationale are more difficult to address. The formal Specification and Description Language (SDL), which has been recommended by the International Telecommunication Union (ITU) for the specification of services and protocols for both Intelligent Network (IN) and switch-based services, has been of considerable help in terms of software correctness and reliability. Good commercial tool support is now available for SDL, so that once a complete, consistent and formal specification in SDL has been created, the remaining development activities still require substantial effort, but generally proceed without major conceptual difficulties [Bou94a, Coo93]. The process of requirements elicitation, analysis and formalisation, however, is now a major bottleneck for implementation of telecommunications services. Initially, informality is not only inevitable, but even desirable as it is an essential part of the human thought process and part of a powerful debugging strategy for dealing with complexity [Bal78]. Even inconsistencies are productive, as conflicts increase creativity. Incompleteness, which can be seen as a kind of oversimplification, improves understanding. However, it is difficult to produce a high quality requirements document from the vague, unordered, inaccurate, incomplete and even ambiguous or contradictory statements typically presented as initial requirements. In the final specification, formality is essential since this reduces the likelihood of misunderstanding and the loss of requirements. Even when a good requirements document exists, it will only be partly implementable due to limitations in the network, cost and time-to-market considerations. The creative process of matching requirements to least-cost implementation requires in-depth knowledge of the underlying network.

In the scheme proposed here, we have started to implement a prototype of a novel expert system called Requirements Assistant for Telecommunications Services (RATS) which supports requirements elicitation and early analysis, while providing a smooth transition to SDL-based formal methods. The aim is thus to introduce formality at an earlier stage of the development life cycle without restricting innovation.

2. SERVICE DEVELOPMENT
2.1 Outline of the development process
Figure 1 outlines the proposed development life cycle and planned tool support for the design of new telecommunications services, from initial requirements capture, through to their implementation. The development starts with a vague customer idea of what the service is supposed to do. This idea is then ordered and expressed in a semi-formal way with the help of the RATS tool. The output of RATS is then translated into a formal executable SDL specification from which existing commercial tools can automatically generate code. Each one of these steps provides different possibilities for testing (see Section 5.3). One of the aims of the methodology is to ensure that the development process is customer-centred [Rau94]. The goal is to offer the customer what he really wants not only what we think he might want or what we can offer most easily. As can be seen in Table 1, the customer is involved in most steps performed during service development. Continuous feedback 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 is as free as possible in order to encourage innovation and to ensure that the end product meets the initial

Figure 1: The overall methodology for telecommunications service design

customer idea. Later, constraints and formality are introduced step by step (see Section 2.2.4) until the desired service is fully formally specified. Within this process there are stages where specification reuse is encouraged (see Section 4.5).

stance, the completeness of a specification increases through refinement of requirements. The following sections describe the three dimensions and give more details about the proposed methodology. 2.2.2 Completeness

2.2 The overall methodology

2.2.1 The three dimensions of the development process

Completeness is a major concern during requirements acquisition. A requirements specification (RS) can be seen as complete when all necessary requirements of the service have been stated. This is a nontrivial task as it involves a high amount of creativity, with the service design expert being the main contributor to completeness. However, our methodology provides some means which help in completely defining a service. As will be explained later in Section 2.3.1, the methodology includes requirements documents which enforce a certain degree of completeness. The brainstorming session is, in the first instance, only intended to collect requirements without any evaluation (see Figure 3). Next to putting the focus on requirements acquisition rather than analysis, this encourages innovation. Another major step towards completeness is achieved by the service definition template (SDT) which contains predefined headings relevant for service development. Use cases are another means of increasing completeness [Jac93] by taking the designer through sequences of service behaviour and user-service interactions. The methodology considers the development of non-functional requirements (NFRs). NFRs are often referred to as system constraints, goals or quality attributes and can be seen as the driving force behind design decisions [Chu95, Myl92] and therefore play an important role. NFRs need to be satisfied by either functional requirements or implementation constraints (see Section 2.3.2) thus raising new issues. Each functional requirement needs to have parallel and exceptional behaviour assigned to it. If this is not required,

Figure 2: The three dimensions of the development process Complex processes can be made more accessible by splitting them up into smaller sub-processes which are ideally independent of each other. There have been attempts to find orthogonal dimensions for requirements engineering [Poh94]. However, existing approaches do not seem to be very well suited for the development of telecommunications services. We, therefore, have defined a novel three dimensional development process as the underlying framework of our methodology. The dimensions represent three major concerns during service development, with each dimension having its well-defined states and being independent of the others. However, practice shows that one step in the development of a service involves progress in usually more than one dimension. For in-

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

the designer is forced to explicitly state it. Finally, the formal specification in SDL encourages complete specification of the functional behaviour (see Section 5). All these measurements increase completeness; however they cannot ensure it. Orthogonal incompleteness, if it does not lead to inconsistencies, simply cannot be detected by tools. Additionally, a different kind of completeness exists: in order for a requirements specification to be complete, it also needs to contain the rationale behind design decisions, and the requirements need to be traceable to their source. This is described in more detail in Section 3 which deals with requirements management. 2.2.3 Refinement As shown in Figure 2, the refinement dimension of our methodology is geared towards the intelligent network (IN) architecture. However, the architecture as recommended by the ITU in the [Q.12xx]-series, is still not common practice. Especially the concept of service independent building blocks (SIBs) is hardly used by service providers for service modelling. Therefore, the methodology guidelines (see Section 2.4 and Table 1) do not go quite as far as the theoretical framework shown in Figure 2. We use the more practical approach of building services out of service features (SFs) and service features out of subfeatures. This assumes a mapping process from one level of refinement to another. As described in Section 4.5, this gives the possibility of reusing already existing functional blocks. Specification reuse is another active research area [Bel93] which provides an easy means for cost-cutting by reducing the design effort and improvement of software reliability. After the acquisition of the high-level service requirements, a grouping into self-contained functional blocks has to be performed, resulting in a service description consisting of service features. This process will be relatively straightforward where the service is composed from sequences of call routing features, as is the case for telemarketing services such as Advanced Freephone. However, in cases where a service is composed from a set of independently accessible features (such as Short Code Dialling, Diversion, etc.) in a Centrex Service, it will be necessary to describe the service as a parallel composition of the component service features. A particular mechanism for this parallel composition will then be required, and will vary between implementations.

2.2.4 Formality Formality plays an increasingly important role in software design and modelling. As the size of software projects increases, tool support becomes essential. Formality offers many advantages such as automated analysis and verification of specifications and design steps with mathematically clear proofs, automated code and test case generation, as well as concise descriptions of the intended software system. One of the aims of the RATS tool is to make the transition from informality to formality easier by inserting semi-formal steps. Only the combination of the expressiveness of informal, natural language, the clearness of semi-formal methods and the precision of formal languages can ensure high quality software. The first step towards formality is accomplished in our methodology by assigning each requirement to a certain sub-class (functionality, topic, goal, information, implementation constraint). This channels the further development of each specific requirement (see Figure 4) and is a means of providing requirement specific guidance. The functional requirements are specified using a use case design process which gradually increases the formality (see Section 2.3.3) and enables a smooth transition to a fully formalised service specification using SDL.

2.3 Low-level development

2.3.1 Requirements documents Unlike current practice, our methodology is not document-based, but requirements-based. The advantage of a requirements-based approach is its flexibility and emphasis on requirements development, management and traceability. The document-based approach lacks these characteristics which is an obvious weakness of the current practice. However, as requirements documents play a crucial role as basis for contracts, they cannot be avoided. Our approach tries to bring the advantages of both ideas together by being requirements-based but providing facilities for document generation. A requirements document is, in the end, a structured collection of requirements contained in 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 approaches available [Chu93, Dar93a]. However, their practicability has not been proven in real world projects of a larger scale. This approach uses a simplified

version which is however applicable for large-scale software projects. Using an object-oriented approach, we define a requirements sub-class hierarchy part of which can be seen in Figure 13 in the Appendix. Each instance of requirement has to be additionally an instance of one of these sub-classes. During the development of requirements, only certain transitions are allowed thus restricting and directing the NFR development. The assumption behind these transition restrictions is that each subclass is connected with a certain level of abstraction. A requirement can then only change its subclass during the development process if the transition leads to a NFR subclass with either the same level or a lower level of abstraction than the current subclass. Additionally, the transition needs to be meaningful from a methodological viewpoint. At last, each NFR has to be satisfied by one or more implementation constraints or functional requirements. These assumptions and rules lead to the transition diagram for NFRs shown in Figure 4.

Figure 5: Use case design in RATS easier. Our approach, therefore, tailors use cases towards the SDL notation (see Figure 5 and 6). An increase in practicability has be achieved by implementing our use case modelling approach in the RATS tool, thus providing active support to the service designer. Three kinds of use cases are employed in the RATS methodology. Each kind is organised in an overall structure showing how the individual use cases make up the overall behaviour of the system. Initially, the behaviour is described with textual use cases, which are then translated into structured use cases which in turn form the basis of the formalised use cases. The notation of the latter is geared towards an easy translation of the specification into SDL which is the basis for fully formalised specification, analysis, simulation, validation, automatic code and text case generation. The following gives an outline of some of the use case attributes. Textual use cases consist of: use case title involved actors use case description Structured use cases contain additionally the following attributes: use case summary precondition flowcondition postcondition Formalised use cases contain all the above mentioned attributes, however the use case description is replaced by a chain of atomic actions. Each atomic action has three attributes: one single actor kind of action (input, output, system operation) description of action The system specification using structured use cases is one of the major milestones in the development process. Constraints ensure that the postcondition of one use case, and the precondition of the immediately following use case are identical. Organising use cases into overall use case structures can be seen as a bot-

Figure 4: Possible transitions in the NFR development process 2.3.3 Development of functional requirements Functional requirements are developed with use cases which have become a very popular concept in software engineering. Most of the commonly used object-oriented analysis (OOA) methods such as OOSE [Jac93], OMT [Rum91], Booch [Boo94], ROOM [Sel94] and Fusion [Col94] have been extended to incorporate use cases or scenarios. Case studies have shown that use cases and scenarios are a very natural way of describing requirements [Dar93b]. We found use cases not only very suitable for the elicitation and notation of requirements, but also as an excellent means of bridging the gap between informality and formality. The lack of formality in use case design has already been pointed out, and some suggestions for improvement have been made [Hsi94, Reg95, Reg96]. We however, are not only interested in introducing formality in use case design in order to give them a formal basis, but in using them as a means to make the transition to a formal service specification in SDL

tom-up approach, suitable to detect gaps and incompleteness. The formalised use case version is oriented towards the SDL specification language. Some concepts of the formalised use case specification can be directly mapped into SDL. Figure 6 gives a few examples how this can be achieved using the graphical version of SDL:

2.4 Methodology guidelines

The methodology outlined here is based on the theoretical framework of Figure 2. We make the assumption that the initial starting point of the service development is an incomplete, informal, high-level description of the desired service. The aim is a complete, consistent, fully formalised and refined specification. A further assumption is that the ideal service development is along a straight line from this initial point in the development space to the desired end point. This has not been proven; however, real life experience underlines the feasibility of this assumption. The ideal line will never be achievable in practice. As shown in Figure 2, the actual service development looks much more like a waved curve oscillating around the ideal line. The task of the methodology guidelines is to ensure that the developer does not diverge too far from the ideal line but stays as close as possible to it. Table 1 describes the actions to be performed step by step by the service designer during service development. Further details are given in Section 4.4.4 in which we outline the implementation of the methodology in the RATS tool. This implementation autoby Reason Document
ICD 2 BL
1

Figure 6: Mapping of formalised use cases to SDL Finally, use cases can be reused as test cases. As they describe the desired system behaviour, the final specification and implementation can be tested for compliance with the initial requirements specified in use cases.
Action
outline service brainstorming evaluate brainstorming list (BL) categorise requirements define service group requirements into self-contained functional blocks add alternative behaviour define behaviour with textual use cases refine and decompose non-functional requirements and satisfy them with textual use cases or implementation constraints organise textual use cases into overall use cases of textual use cases define states in the behaviour translate textual use cases into structured use cases organise structured use cases into overall use cases of structured use cases add exceptional behaviour translate structured use cases into formalised use cases translate formalised use cases into SDL SDL design

customer customer centred RE cust., RE eng. encourage innovation, increase completeness cust., RE eng. increase agreement RE engineer increase formality cust., RE eng. increase completeness RE engineer preparation to find reusable functional blocks RE eng., cust. increase completeness RE eng., cust. increase formality RE eng., cust. address non-functional requirements RE engineer better overview, bottom-up approach, increase completeness RE engineer improve structure, makes translation into structured use cases easier RE engineer increase formality RE engineer better overview, bottom-up approach, increase completeness RE eng., cust. increase completeness RE engineer increase formality RE engineer increase formality service designer, customer formal analysis, verification, simulation, validation, testing, code generation

BL BL 3 SDT SDT SDT SDT SDT SDT SDT SDT SDT SDT SDT SDT / SDL-Tool SDT / SDL-Tool

1 2

ICD: Initial Customer Description BL: Brainstorming List 3 SDT: Service Definition Template

Table 1: Methodology guidelines for service development

Figure 7: Requirements links in RATS (example: UPT service) matically introduces iterations in the life cycle when necessary. sections, we want to focus here on how these characteristics are achieved within our methodology. Many issues of requirements management are addressed by the three kinds of requirements links shown in Figure 7 and Table 2. History links show the historical development of a requirement. Each requirement has a history link to at least that one requirement which initiated it. History links need to be annotated with attributes like when, why and by whom the requirement was inserted into the specification. This could be a different person from the person who actually stated the requirement (e.g. the customer) which is an attribute of each reNew Requirement in KB in Doc
yes
5

3. REQUIREMENTS MANAGEMENT
Requirements management is an important subject in requirements engineering. It includes issues like the overall definition of the requirements engineering process as well as the integration of its phases, the management of unstable, evolving and changing requirements, documentation of decision rationale, requirements reuse, requirements documentation, impact assessment of changing requirements, traceability and so on. As some of these issues are described in other
Operation
create edit refine collapse replace delete prune & craft create alternative create parallel behaviour
6

Description
create a new requirement minor textual editing without recording of the change a parent requirement is refined into subrequirements several similar requirements are simplified into one requirement a requirement is replaced by one or more other requirements a requirement has been rejected the location of requirements in a requirements structure is changed alternative ideas can be pursued parallel behaviour is being defined

Old Requirement 1 2 in KB in Doc

n/a
3

Change of Links history logical structure

n/a op no yes yes yes no yes yes yes op no, op op yes, op yes, op yes, no yes op op
5 5

n/a no, n/a

op

no yes yes yes yes n/a yes yes

yes yes yes yes n/a n/a

yes, op op yes, op yes, op n/a n/a op op

no yes

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

yes yes no no yes yes

yes yes

create exceptional behaviour is being exceptional defined behaviour

1 2

yes

yes, n/a

yes

op

yes

yes

op

KB: Knowledge Base Doc: Document 3 n/a: not applicable

4 5

op: optional depending on the original requirement 6 similar to edit, however, the change is recorded

Table 2: Possible operations on requirements in RATS

R10 R1 R4 R2 R5 R6 R3 R9 R14 Requirements Acquisition and Specification R16 C5 R8 R7 C1 R11 R12 R13 R15 C3 C4 C2

Implementation

requirement whose history is to be traced requirement is part of trace requirement is not part of trace

stakeholder to be consulted stakeholder not affected

history link is part of trace history link is not part of trace

Figure 8: Pre-traceability in RATS quirement. Thus history links mainly provide the pretraceability, i.e. the tracing back of a requirement to the rationale, and persons behind it, and its development. This is illustrated in Figure 8. Logical links may often be parallel to history links. However, their task is more forward oriented and related to post-traceability. For instance they link up a goal with the functional requirements or implementation constraints which satisfy it. This approach allows post-traceability which goes beyond other work which sees post-traceability only as those aspects of a requirements life that result from inclusion in the requirements specification [Got94]. Post-traceability in RATS provides the necessary means for impact analysis of requirements change, i.e. it shows all requirements which are logically affected by a change of the requirement concerned. Structure links have the task of organising requirements into requirements structures. A requirements structure can be a document, an overall use case, a service or service feature. With the help of these links, requirements can be included in requirements structures, thus facilitating documentation despite the chosen requirements-based approach. This link provides the necessary means to insert, delete and prune&craft requirements in a structure.

4. THE RATS TOOL

4.1 Overview of the RATS tool
The increase of complexity and diversity of the telecommunications network makes it difficult for a service developer to have adequate understanding of the infrastructure supporting the range of different services. These characteristics, however, are highly relevant to the analysis of service requirements and must be taken into account if the requirements are to be implementable. We decided, therefore, to use a knowledge based approach as the basis of the RATS tool. The knowledge base comprises two parts: the main characteristics of the telecommunications domain, information about the employed development process methodology. The trade-off of this approach is that changes in the domain models and the development processes (i.e. the higher layers of the models) involve considerable effort. However, major changes to network characteristics and development processes do not occur as frequently as commercial services are launched. For instance, the ISDN network infrastructure has been developed and deployed over a period of more than ten years and now supports more than 30 service features, such as Diversion features and Call Completion to Busy Subscriber (CCBS).

The knowledge contained in RATS is expressed in a knowledge representation language called Telos [Myl90]. It integrates an axiomatised object-oriented kernel with a predicative assertion language. A partial version of Telos is implemented in an experimental deductive object base management system called ConceptBase [Jar93, Jar96] which is the tool with which RATS has been developed. Next to the knowledge relevant to service development, RATS contains layers providing intelligence on several levels of abstraction. A graphical user interface (GUI), an inference engine, as well as a frame generator, make the tool more user friendly. The architecture of the RATS tool is shown in Figure 9.

ferent to standards and are probably the most suitable ones for RATS as they reflect real-world situations. Quick models: These models contain only the information which is absolutely essential to support the service design process. This shows that the RATS tool can accommodate very different kinds of domain models which might have been created by different people for different purposes. This is possible by introducing a negotiation layer (see Section 4.5) between the domain models and the development models. In Figure 9 several aspects of the telecommunications domain are mentioned: Customer Profile: This database contains information about the customer himself, the subscribed networks, the subscribed bearer, tele- and supplementary services, his interface structure, his premises equipment (CPE) and the local exchange he is connected to. Customer Premises Equipment (CPE): Several kinds of CPEs (e.g. PABX, ISDN- or analogue telephone, LAN) are described within the CPE knowledge base as well as their reference points (e.g. R-, S-, T-Interface for ISDN) and the functionality they contain (e.g. TE1/2, TA, NT1/2 for ISDN). Network Transport Capability: This knowledge base contains the characteristics of different kinds of networks. In the case of ISDN, it can contain information about generic network characteristics as

4.2 The domain models

As has been mentioned above, the domain models contain the main characteristics of the telecommunications domain, conceptually expressed in Telos. Currently, the still incomplete RATS prototype contains information from more than 80 recommendations and standards. Due to a clear separation of the development and domain models, a great variety of models can be used within RATS. Three different kinds of models can be distinguished according to their source: Standards: These models are very detailed and based on standards, i.e. can be seen as electronic versions of standards and are suitable for teaching purposes. Expert knowledge: Such kinds of models are built on knowledge of experts. They are often very dif-

Figure 9: The RATS tool architecture

well as recommended and available basic network services. Network service interworking issues are included here. Supplementary Services: Here information about the supplementary services, their main characteristics as well as their specifications is available. In case the service provider offers many intelligent network (IN) services, it might contain parts of the IN architecture. Feature Interaction: This is a very important topic which if not considered can have devastating effects on the network [Bou94b]. Different levels of sophistication can be introduced. A simple approach is to store only known feature interactions in this knowledge base. A more sophisticated approach assigns characteristics to services and points out suspicious feature combinations. Network Interworking: The increasing variety of networks, demands facilities for interworking between networks. Interworking possibilities need to be specified and stored in this knowledge base. Switch: As long as the intelligent network concept is still not extensively implemented, switch-based services play a crucial role. The different types of switches, as well as their services, are stored here. Data Dictionary: The data dictionary is part of the formalisation process. All people involved in service design need to assign the same meaning to the terms used. This is done with the help of the dictionary.

4.4 The intelligence layer

4.4.1 Intelligence implementation using Telos This section is to briefly outline the possibilities available to implement intelligence within a Telos system. 4.4.1.1 Passive guidance Passive guidance is a basic, but essential means to provide guidance during development. The following concepts are rigid constraints which prevent the insertion of inconsistent objects into the knowledge base: Object-orientation: Conceptual, object-oriented modelling using formal languages with their features of inheritance, classification, specialisation and instantiation is a means for some basic forms of intelligence. Telos axioms: Telos and its implementation in the ConceptBase tool contain several axioms which are automatically enforced as soon as an object is inserted into the knowledge base. Constructs not complying with these rules are rejected. Permanent user-defined constraints and rules: The created domain and development models contain a large number of permanent, user-defined constraints and rules which ensure model consistency and help in the correct development of services. However, such rigid constraints are only desired for serious consistency violations. Some inconsistencies (especially incompleteness) can be temporarily acceptable or even desirable [Fin94]. To accommodate this, there also need to be soft constraints: Temporary user-defined constraints and rules: A set of user-defined constraints and rules are available but only triggered at certain milestones of the development life cycle, in order to check consistency and completeness. Meta-rules and state-classes: The RATS tool contains, at a high layer of the models, generic meta-rules which assign an object to certain stateclasses showing the state an object is currently in with respect to the development process. Passive guidance is very important, but its capabilities are limited. It can only state: Dont do that! However, what is expected from an expert system is the additional feature of active guidance: Do this!

4.3 The development models

The development models form the underlying structural concept of the development methodology. Several viewpoints of it have already been described. The overall context is shown in Figure 1, the theoretical framework is outlined in Figure 2, a documentbased view is given in Figure 3, and the practical steps to be performed during service design are described in Table 1. Further issues like the intelligence and the negotiation process are outlined in Sections 4.4 and 4.5. The development models contain complex objectoriented class hierarchies. The models are oriented towards the conceptual inheritance of the modelled entities rather than the development process (cf. Section 4.4.1.2). This increases reusability and provides generic templates but does not allow a great deal of process guidance. We, therefore, generated specific models contained in the intelligence layer (see Section 4.4) which gives detailed advice to the developer.

4.4.1.2 Active guidance There are again several means by which active guidance can be achieved using Telos. Some of the possibilities are briefly outlined here: Strings assigned to classes: The classes of the development models contain strings which point out the next steps which normally have to be performed. However, this allows only general guidance as it is connected to a class and not to the current state of a specific instance. Guidance derived from development models: Some rough guidance can be derived from the development models. However, this demands models which are oriented towards the development process rather than the conceptual inheritance of characteristics (cf. Section 4.3). In some cases, these two aspects might be the same; however, this cannot generally be assumed. Special attributes pointing to the next object: Special attributes can be created which point to the object to be dealt with next. This is similar to the previous possibility, except that it gives more freedom for the conceptual model. Intelligence models using rules and intelligence objects: The most general approach for active guidance involves the creation of special intelligence models. Rules assign intelligence objects to specific instances of any requirements object depending on the actual state of this particular instance. Complex rules have to be created in order to allow such individual, active guidance (cf. Figure 10). Parameter rules and queries for intelligence objects: Queries for possible parameters for the intelligence objects can be defined. 4.4.2 Intelligence implementation in the RATS tool Figure 10 shows the general principle by which intelligence models are implemented within RATS. Several pools exist containing intelligence objects, intelligence rules, parameter queries and parameter rules. The intelligence rules assign the appropriate intelligence object to any requirements object (e.g. goal, use case) depending on its current state. Using a generic query all the intelligence objects assigned to a certain requirements object can be retrieved. The intelligence objects contain the necessary information to further develop the requirements object. In some cases the intelligence objects have associated parameter queries which give more details with the help of further rules.

Telos object

Generic Query: What to do next?

Pool of Intelligence Objects Pool of Parameter Queries

RequirementsObject

Int1 Int2 Int3

Get status agreed for all requirements in this requirements document.

PInt1

PInt3 PInt4
Pool of Parameter Rules

Int4
Pool of Intelligence Rules

UPTPT7

Figure 10: Implementation of intelligence models within RATS The domain knowledge and the development models of RATS form the fundament of the RATS tool and are used by the intelligence layer which itself is split into two parts providing guidance at two different levels of abstraction: at a lower level, object related guidance, and at a higher level, methodology related guidance. These levels are further explained in the following sections. 4.4.3 Object related guidance Object related guidance is concerned with intelligence for the concepts at a low level of abstraction (e.g. documents, goals, use cases). The service designer can ask the tool how he should proceed with an individual instance of any requirements object and will receive object specific instructions. In order to illustrate how RATS offers object related guidance by combining the approaches mentioned in Section 4.4.1, we use a simple example: Let us assume, the Universal Personal Telecommunication (UPT) service is to be defined. Objectorientation and Telos axioms ensure that the definition is an instance of the class ServiceDefinitionTemplate (which is a sub-class of RequirementsDocument) in order to enable the inheritance of its attributes. Let us say that this document still contains some requirements which have not yet got the status agreed. Meta-rules and state-classes inform the designer that there is still something wrong with this document and hence the document is assigned to the state-class InconsistentObject. Intelligence models using rules and intelligence objects point out to the designer that he should try to get the status agreed for all requirements in this requirements document. Parameter rules and queries for intelligence objects point out which particular requirements still need to get the status agreed (e.g. UPTPT7 in

Figure 10). In case the designer ignores these messages and tries to assign the status agreed to the whole document (even if it still contains requirements without the status agreed), permanent user-defined constraints and rules will reject this attempt. 4.4.4 Methodology related guidance Methodology related guidance is implemented in a way similar to object related guidance. However, its background and task are different: While object related guidance is concerned about conceptual issues of a lower layer, methodology related guidance deals with methodological issues of a higher layer. It assists with the overall service design guiding the designer through the development process of the whole service. RATS contains the implementation of the methodology, the theoretical framework of which is shown in Figure 2, and guidelines described in Table 1. Each row in Table 1 represents a state in the development life cycle. The current state of the development process is determined by rules. Transitions from one state to the next are achieved by performing appropriate actions. An important advantage of this approach is the benefit of automatic process iteration. If, for instance, a service has already been specified using structured use cases and the customer wants an additional requirement to be included, rules will automatically initiate re-engineering of the service from the appropriate point of the life cycle. Depending on the kind of change, the re-engineering has to start at different stages in the life cycle (see Figure 11). Adding a high-level non-functional requirement to an already existing requirements specification will cause a fallback to a very early stage, while adding a minor lowlevel functionality (e.g. change of an announcement) will only set back the development process by a few states. This automatic iteration process to the nearest possible state in the life cycle, is an excellent means of ensuring that the re-engineering effort is kept to a minimum.
State 4 Action 4 State 5 iteration for highlevel requirements change Action 5 State 6 Action 6 normal development iterative development State 7 iteration for lowlevel requirements change

4.4.5 Intermodel consistency Another task of the intelligence layer is to ensure intermodel consistency. Rules are used to guarantee meaningful usage of the libraries contained in the independently of each other created domain models, taking care that the elements used from different domain libraries fit together. The following few lines show a Telos rule in frame syntax ensuring that only such basic network services are specified in a service definition which are also offered by at least one of the chosen 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 domain models (see Section 4.2) and to offer active, domain specific guidance, there needs to be an interface between the development models and the domain models. This interface is provided by the negotiation layer. Intermodel consistency could be another task of this layer, however, RATS provides this in the intelligence layer (see Section 4.4.5). Despite informal negotiation being very much part of everyday life, negotiation behaviour during requirements specification has not yet been explored very well [Rob90]. In this case, a relatively simple approach is taken. Negotiation objects: These objects are a sub-class of the class Requirement. They therefore inherit all characteristics of this class but represent a special function in the chain of requirements development. From a requirements management viewpoint they are the end of a chain of requirements, i.e. they link to an object in one of the domain models. These negotiation objects play a distinct role as they have to perform the connection between the development process and the different kinds of domain models thus allowing a clear separation between the models. Keywords: The negotiation process itself is similar to the problem of software reuse [Bel93]. In our case, keywords of three different categories (see Figure 12) are employed, supported by two kinds of metaattributes which can reuse already existing domain objects, or allow new keywords to be inserted.

Figure 11: Development process iterations

Individual ISDN in NW with offers,attribute Keywords of category 1: ISDNoffers : BasicISDNService reuse of existing domain object descriptions 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; Keywords of category 2: Keywords of category 3: Keywords5 : Demand; reuse of existing domain objects new strings added into domain models to Keywords6 : Permanent; characterise domain objects Keywords7 : Reserved end

Figure 12: Usage of keyword categories in RATS (example: ISDN; meta-attributes in bold) Description: This meta-attribute allows a textual description to be assigned to each object. This can be, for example, a textual description of a teleservice. The string contained in this description can be used for a keyword search. The advantage of this approach is that already existing objects of the domain models can be reused. KW: The second meta-attribute is the KWattribute. It also allows reuse of existing domain information by just adding a KW-link between the object to be characterised and the characterising object. There is one major impact on the domain models which they have to comply with in order to enable RATS to actively support this negotiation process. As the negotiation process is done by a string comparison between the desired keywords provided by the service designer and the keywords assigned to existing domain objects, the keywords need to be expressed in positive terms. This can be expressed with the term positive modelling which means that the keywords must not contain any negative expressions but only positive characteristics of the objects to be described. Performance is another issue. The current, incomplete RATS prototype has a size of about 1.8 MBytes, and contains altogether some 290 user-defined rules and 63 user-defined constraints. Rules are an excellent means to automatically assign redundant information to other objects. However, they drastically slow down the performance, especially if rules use information which has to be retrieved by other rules. Such chains of rules must be avoided. Recursion can provide very good facilities for queries, however, it also slows down the performance of RATS remarkably. During modelling, a compromise needs to be found between nice, proper and modular modelling using the full range of Telos features, and acceptable performance. As soon as the models get larger, a very fundamental rule has to be considered: applications need to be characterised by many classes (hundreds to thousands) but not many instances in each class [Jar93]. This demands a trade-off between generic modelling allowing a high degree of reusability and performance on the other hand. The more general the class-models are, the more instances they will contain and the lower the performance will be. Especially in requirements engineering, where there might be many thousands of requirements (i.e. instances in the class Requirement), performance will be an issue of concern. On the other hand the acceptable response time of an expert system is relatively small. Our own experience shows that most queries need to be answered within 5 secs to give the system user the necessary feeling of satisfaction. The maximum tolerable response time is around 20-30 secs. But queries can very easily be created which need much longer.

4.6 RATS Implementation and performance

As has been mentioned earlier, the RATS tool is implemented in a knowledge representation language called Telos using a deductive object base management system called ConceptBase. ConceptBase can run on a UNIX platform or an Intel-PC running Solaris 2.4 or higher. Over recent years, ConceptBase has been drastically improved, both in stability and performance. Nevertheless, it still contains only a subset of the concepts of the powerful Telos language and stability needs further improvement.

5. FORMAL REQUIREMENTS SPECIFICATION

5.1 Formal specifications
SDL has been developed for use in telecommunication networks, systems and protocols but can, in general, be applied to all real-time, interactive and distributed systems for the description of system behaviour and structure on all levels of abstraction. The language has been developed and standardised by the International Telecommunication Union (ITU) over several years in [Z.100]. The basis for description of behaviour is extended state machines which communicate with each other and with the environment via signals. There are three main components to the language: System behaviour: The behaviour of the system is described by a set of SDL processes. Each process is defined as an extended finite state machine, that works autonomously and concurrently with other processes. Communication between processes is performed asynchronously by signals. System structure: There are comprehensive constructs to describe the structure of systems in order to cope with complexity. A system contains one or more blocks interconnected with each other and with the environment by channels. A block can again be partitioned into sub-blocks, creating a hierarchical block tree structure. Later versions of SDL additionally support object-oriented structuring concepts. Abstract data: All data types, predefined as well as user-defined, are specified in an implementationindependent way only in terms of their properties. They describe data which is exchanged with the system and which is stored and manipulated by it. SDL supports service specification by providing clear and complete behaviour descriptions and has been extensively used to develop rigorous specifications of telecommunications services and protocols [Cro93].

Dynamic properties of SDL specifications can also be checked by simulation, showing that the functional requirements are satisfied. This checking could be applied to SDL representing service components at the service and service feature level of refinement, providing the opportunity to validate these descriptions at an early stage. SDL has also been used to analyse groups of telecommunications services for interaction problems. An example, documented in [Kel95], describes an analysis of models of UPT service features. The UPT feature models were pair-wise tested against models of switch-based call completion features. The analysis detected 16 feature interaction problems which could then be resolved in the subsequent service implementation.

5.3 Implementation and testing

SDL specifications of services and service features (SFs) can be used as part of the implementation process to obtain service platforms offering the required components. If the service platform is procured from a third party, the SDL would form part of the requirements specification. If the service platform is an inhouse development, the SDL would form an input to the project developing the required components. Having procured a service platform, the required SFs would be constructed using a service creation tool appropriate to the particular platform. The behaviour of the SF could then be tested against the higher level use case specification of that SFs behaviour which was produced during requirements development. Afterwards, the required service can be constructed by provisioning the right combination of SFs for customers. Even if more classical software development techniques are to be employed, the SDL descriptions of services and service features will provide unambiguous specifications for these developments as well. Finally, the complete service implementation can be tested against the service level use cases (see Section 2.3.3), whose development from the initial requirements can be traced. Additionally, some of the SDL tools automatically generate test cases to be run against the specification and implementation of the system. So the cycle of service development is complete, and we can assess the conformance of the service to the initial requirements, because key steps in the traceable development of requirements are described formally, supporting testing.

5.2 Analysis, simulation and validation of formal specifications

Good quality commercial tools are now available which allow checking of SDL descriptions. Checking can include static properties, such as all the attributes have been defined interfaces are used consistently

6. CONCLUSION AND FUTURE WORK

Acknowledgements RATS is an attempt to combat the problem of requirements engineering for telecommunications services. It is not a solution to all the issues raised in this paper. However, its approach and initial results are promising. The knowledge based approach to RATS gives it a stable basis providing many opportunities for active assistance. The novelties of the described approach can be summarised as follows: The methodology outlines an overall life cycle of a system, starting at the initial customer idea and leading to the testing of the implementation. Requirements are captured freely from customers and a best fit with the existing infrastructure is achieved by a semi-automated negotiation process encouraging reuse of existing components. The transition from an informal to a fully formal system specification, is done in a smooth and gradual manner. Very different kinds of requirements are treated uniformly and in electronic format allowing improved requirements management facilities. A process for decomposition of non-functional requirements is included. The methodology can be integrated into existing service development life cycles and has continuous support by tools. Despite focusing on the telecommunications domain in this paper, it can be said that the RATS methodology is essentially generic and can be used for the development of many different kinds of real-time software systems specifiable in SDL. Also the RATS tool is partly generic with only the lowest layer of the tool (see Figure 9) being domain specific. The domain knowledge of the present version of the RATS tool is geared towards the intelligent network architecture and the ISDN network; however, many different domains can be conceptually modelled and used in the RATS tool. Although the RATS methodology has reached a certain degree of maturity, the implementation of the methodology in the RATS tool is not yet complete. More domain specific help could be provided to the designer if more domain models were contained in the RATS tool. Additionally, the graphical user interface, the inference engine and the frame generator require further work before a more comprehensive case study can be done. This will also help to make more obvious any possible performance problems. The authors are grateful to British Telecom for supporting this research, especially to Kevin Woollard and Michael Crowther for many helpful discussions. The authors also thank Prof. M.G. Rodd for his encouragement to publish this paper as well as the anonymous referees for their valuable comments and suggestions on an earlier version of this paper.

REFERENCES
[Bal78] Balzer R., Goldman N. and Wile D. Informality in Program Specifications, IEEE Transactions on Software Engineering, 4, (2), pp. 94-103 (1978). [Bel93] Bellinzona R., Fugini M.G. and Demey V. Reuse of Specifications and Designs in a Development Information System, IFIP Transactions A - Computer Science and Technology, 30, pp. 79-96 (1993). [Boe84] Boehm B.W. Verifying and Validating Software Requirements and Design Specifications, IEEE Software, 1, (1), pp. 75-88 (1984). [Boo94] Booch G. Object-Oriented Analysis and Design with Applications, Benjamin/Cummings Publications (1994). [Bou94a] Boullier L., Kelly B., Phalippou M., Rouger A. and Webster N. Evaluation of some Test Generation Tools on a real Protocol Example, Proceedings of the Seventh International Workshop on Protocol Test Systems (1994). [Bou94b] Bouma L.G. and Velthuijsen H. Feature Interactions in Telecommunications Systems, IOS Press, Amsterdam, The Netherlands (1994). [Bub95] Bubenko J. A. Challenges in Requirements Engineering, Proceedings of the Second IEEE International Symposium On Requirements Engineering, York, U.K. (1995). [Chu93] Chung L. Representing and Using NonFunctional Requirements: A Process-Oriented Approach, PhD Thesis, University of Toronto, DKBSTR-93-1 (1993). [Chu95] Chung L., Nixon B. and Yu E. Using NonFunctional Requirements to Systematically Select Among Alternatives in Architectural Design, Proceedings of Seventeenth International Conference on Software Engineering (ICSE-17), Workshop on Architectures 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. Design Methodology using SDL, BT Technology Journal, 11, (4), pp. 16-24 (1993). [Cro93] Crowther M. Modelling and Validation of Telephony Network Signalling, Proceedings of SDL Forum (1993). [Dar93a] Dardenne A., Fickas S. and van Lamsweerde A. Goal-Directed Requirements Acquisition, Science of Computer Programming, 20, pp. 3-50 (1993). [Dar93b] Dardenne A. On the Use of Scenarios in Requirements Acquisition, University of Oregon, Technical Report, CIS-TR-93-17 (1993). [Dav93] Davis A.M. Software Requirements - Objects, Functions and States, Prentice Hall (1993). [Eng95] English E. Industry Trends, IEEE Computer, 28, (8), p.14 (1995). [Fin94] Finkelstein A., Gabbay D., Hunter A., Kramer J. and Nuseibeh B. Inconsistency Handling in Multi-Perspective Specifications, IEEE Transactions on Software Engineering, 20, (8), pp. 569-578 (1994). [Got94] Gotel O. and Finkelstein A. An Analysis of the Requirements Traceability Problem, Proceedings of the First International Conference on Requirements Engineering, Colorado Springs (1994). [Hsi94] Hsia P., Samuel J., Gao J., Kung D., Toyoshima Y. and Chen C. Formal Approach to Scenario Analysis, IEEE Software, 11, (2), pp. 33-41 (1994). [Jac93] Jacobson I. Object-Oriented Software Engineering - A Use Case driven Approach, AddisonWesley (1993). [Jar93] Jarke M. Eherer S., Gallersdrfer R., Jeusfeld M. and Staudt M. ConceptBase - A Deductive Object Base Manager, University of Aachen, Germany, (1993). [Jar96] Jarke M., Jeusfeld M. and Staudt M. ConceptBase 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 Telecommunications Systems, KYOTO'95 (1995).

[Lub93] Lubars M., Potts C. and Richter C. A Review of the State of the Practice in Requirements Modelling, Proceedings of the First International Symposium on Requirements Engineering, San Diego, CA (1993). [Myl90] Mylopoulos J., Borgida A., Jarke M. and Koubarakis M., Telos: A language for representing knowledge about information systems, ACM Transactions 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 on Software Engineering, 28, (6), pp. 483-497 (1992). [Poh94] Pohl K., The three Dimensions of Requirements Engineering - A Framework and its Aplications, Information Systems, 19, (3), pp. 243-258 (1994). [Q.12xx] Q-Series of ITU-T Recommendations on Intelligent Networks. [Rau94] Rauterberg M. and Strohm O. About the Benefits of User-Oriented Requirements Engineering Proceedings of the First International Workshop on Requirements Engineering: Foundation of Software Quality, Utrecht, Netherlands (1994). [Ree92] Reed R., Bouma W., Marques M.M. and Evans J. Methods for Service Software Design, Proceedings of the Eighth International Conference on Software Engineering for Telecommunication Systems and Services, Florence, Italy, pp. 127-134 (1992). [Reg95] Regnell B., Kimbler K. and Wessln A. Improving the Use Case Driven Approach to Requirements Engineering, Proceedings of the Second IEEE International Symposium on Requirements Engineering, York, UK (1995). [Reg96] Regnell B., Andersson M. and Bergstrand J. A Hierarchical Use Case Model with Graphical Representation, Proceedings of the IEEE International Symposium and Workshop on Engineering of Computer-Based Systems, Friedrichshafen, Germany (1996). [Rob90] Robinson, W. N. Negotiation Behaviour During Requirements Specification, Proceedings of the 12th IEEE International Conference on Software Engineering, Nice, France (1990). [Rum91] Rumbaugh J. Object-Oriented Modelling and Design, Prentice Hall (1991). [Sel94] Selic B., Gullekson G. and Ward P. Realtime Object-Oriented Modeling, Whiley&Sons (1994).

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

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

Authors Biographies:
Armin Eberlein graduated with a Diplom-Ingenieur (FH) from the Fachhochschule fr Technik in Mannheim, Germany in 1993. He then spent some time working as hardware and software developer in Siemens in Munich, Germany. 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 in Swansea. His research is sponsored by British Telecom and concerned with formal methods in system design, AI in telecommunications and new methodologies for service design. Fred Halsall is Professor of Communications Engineering at the University of Wales, Swansea and head of the Communications Research Group. The Group is involved in research in computer network modelling, software engineering, and high bit rate data transmission over radio. He has published widely in these and related areas. He is a Fellow of the IEE.

APPENDIX

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