Tools for Requirements Capture, Formal Specification and Validation of IN Services Armin Eberleina Michael Crowtherb Fred Halsalla a Department of Electrical & Electronic Engineering, University of Wales, Singleton Park, Swansea SA2 8PP, UK Tel: +44 1792 295541, Fax: +44 1792 295686 e-mail:
[email protected] b B68/2, BT Laboratories, Martlesham Heath, Ipswich IP5 7RE, UK e-mail:
[email protected]
ABSTRACT We describe an overall development life-cycle for IN services with emphasis on support for requirements capture and formal specification and validation. 1
A novel intelligent tool (RATS ) is being developed to assist with requirements capture and early analysis, leading to formal specifications of the service at different stages of refinement. The tool assists by providing facilities for requirements traceability as well as impact analysis of requirements change. It offers active guidance for requirements development in three dimensions (refinement, formality and completeness) with the help of a negotiation process. Existing service creation tools can then be used to implement the service. Some of the features of our methodology are illustrated using examples from the Universal Personal Telecommunication (UPT) service.
1. INTRODUCTION 2
For several years we have used the language SDL to specify services and protocols for both IN and switchbased services. 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 [Coo93, Kel94a]. The process of requirements elicitation and analysis is now a major conceptual bottleneck for implementation of IN services. 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. A degree of formality is desirable, as this reduces the likelihood of misunderstanding and loss of requirements.
Figure 1: The overall methodology for IN service design 2 1
RATS: Requirements Assistant for Telecommunications Services
SDL is the ITU recommended Specification and Description Language [Z.100]
Even when a good requirements document exists, it will only be partly implementable due to limitations in the network and cost and time-to-market considerations. The creative process of matching requirements to least-cost implementation requires in-depth knowledge of the under-lying network. We have, therefore, started to implement a prototype tool (RATS) which supports requirements elicitation and analysis while providing a smooth transition to SDL-based formal methods. Its aim is to introduce formality at an earlier stage of the development life cycle without restricting innovation. The following paragraphs, and figure 1, outline our methodology and planned tool support for the development of new IN services from initial requirements capture through to their implementation. 2. REQUIREMENTS MANAGEMENT The RATS tool stores all requirements in an objectoriented database. Here, the term requirement is used in a very general way to represent functional and nonfunctional requirements, goals, issues, clarifying information, use cases [Jac93], atomic actions as well as SDL specifications. This uniform treatment of very different kinds of requirements is very useful for telecommunications services and goes beyond the capabilities of commercially available requirements engineering tools (e.g. DOORS, RTM) [Bub95, www-1]. It allows a high degree of flexibility and ease of management at all levels of abstractions. Requirements are represented as objects using an object-oriented knowledge representation language, TELOS [Myl90]. Depending on the kind of a requirement, it will be assigned attributes. These attributes include links between requirements, which are automatically established as operations are carried out on requirements. Some of the requirements links are illustrated in figure 2.
History links play an important role for tracing back the requirements to the original source and the rationale for each modification within this chain. Logical links are crucial for finding out what effects the change of a requirement has. Structure links establish the structure of requirements within requirements documents. 3. OUTLINE OF THE RATS TOOL With the increasing complexity and diversity of telecommunications networks, it has become difficult for service developers to have adequate understanding of the network 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 structure of the tool is illustrated in figure 3. The trade-off of this approach is that changes in the domain models and the development processes 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). Information related to IN is contained in the development models and in the module containing the Supplementary services. Supplementary services are assumed to be constructed from service features (SF). An SF is an element of service functionality that is discernible to a user or customer. In practice, this means an SF can be independently provisioned for a user, operates independently of other SFs or is billed separately. For ex-
Figure 2: Requirements links in RATS (ex: UPT service)
Figure 3: Outline of the RATS tool ample, the UPT service could be composed from an Authentication feature, giving remote access to a customer’s service data (including diversion target), and a Diversion feature. These are separate SFs because they operate at different times. SFs can be compiled from service independent 1 building blocks (SIB ) using a service creation tool. A SIB is a network-wide service capability that can be reused by different SFs. Characteristics of SFs and SIBs, including their behaviour in terms of use case definitions and SDL specifications, can be contained in this knowledge base and are available for reuse. 4. SERVICE DEVELOPMENT The development models describe how the requirements for an IN service are developed into specifications which can be used to procure new or enhanced network components. Our approach combines 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 is really what the customer wants. Later, constraints and formality are introduced step by step until the desired service is completely and formally specified. It is critical to the successful launch of IN services to achieve this creative compromise between marketing ideas and what a network can provide. 4.1 Intelligence of RATS to support service development The development models allow the RATS tool to provide two kinds of active guidance to the developer: • methodology related guidance • object related guidance. 1
We have assumed in this paper that SIBs can be used to construct SFs, even though this approach has not been fully validated.
The first one guides the developer through the overall development process of the service, the latter provides assistance for each individual requirements object (e.g. requirements document, use case, goal, etc.) As can be seen in figure 3, the intelligence of the RATS tool is mainly contained in the development models. The intelligence aspects of RATS are described in more detail in [Ebe96]. 4.2 Requirements acquisition The development life cycle starts with an initial customer description (ICD) of the desired service. This is to ensure customer centred requirements engineering. In a brainstorming session, requirements engineers create together with the customer a list of topics to be considered (brainstorming list - BL). First, this is done without any evaluation or criticism in order to encourage innovation. In a second step, the list is evaluated and agreed on. As these requirements are the starting points of the whole requirements engineering process, there needs to be a very conscientious annotation. The rationale for and source of requirements are essential for traceability. A great deal of completeness during requirements acquisition is achieved with the help of a generic service definition template (SDT) which ensures that all relevant topics are addressed. Requirements acquisition continues throughout the development of the requirements, which is addressed in section 4.3.3. 4.3 Requirements development During the service design, a decomposition of nonfunctional requirements (e.g. security, reliability, etc.) takes place. These requirements finally need to be satisfied either by implementation constraints or by functional requirements thus leading to a higher degree of completeness. The development process of functional requirements is three dimensional (see figure 4). Each dimension has
Figure 4: The dimensions and stages of the development process of functional requirements well defined states pointing out how far the service development has been done and what needs to be addressed next. The intelligence contained in the RATS tool ensures that the service designer takes a route through this cube close to the ideal line from the starting point to the end point. 4.3.1 Formality A first step towards formality is accomplished by assigning each requirement to a certain subclass (e.g. functionality, topic, goal, etc.). The categorisation of requirements allows the RATS tool to provide requirements specific guidance. The development of each functional requirement starts as a textual use case (contains only a textual description of a user-system interaction). After a definition of states within the service behaviour, the textual use cases are transformed into structured use cases (additionally containing pre-, flow- and post-conditions as well as a use case summary [cf. Reg95, Loe95]). Finally the structured use cases are transformed into formalised use case descriptions (consist of atomic actions of kind Input, Output and System Operation) which can be easily translated into a formal and executable specification using SDL. The advantages of a formal service specification in SDL are described in section 5. 4.3.2 Refinement After the definition of the new service in the service definition template, from a user's perspective, a negotiation process between the user's idea and the available network and service capabilities takes place. This attempts to bring two aims together: 'designing what the
customer really wants' and 'reuse of existing components'. The goal is to implement as much as possible of the desired service out of existing SFs and bearer service capabilities, and to develop new components only where necessary. This means that after the acquisition of the high level service requirements the functional requirements need to be grouped into self-contained functionality blocks that can be implemented. Depending on the level of abstraction, these blocks can represent SFs or SIBs. The refinement 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. The feature descriptions may be refined by mapping onto sequences of new or reused SIBs. Again, we also need to describe how these building blocks are composed to satisfy the feature descriptions. These refinements can be semi-automated by assigning characteristics to SFs and SIBs. A comparison between characteristics of the desired function and the already existing functions enables the RATS tool to suggest SFs and SIBs which might be reused to achieve the wanted functionality. Clearly, there needs to be
control of the terms used for characteristics; this is where the Data Dictionary starts to be justified. 4.3.3 Completeness Completeness on a high level of the service description has already been achieved using a service definition template (see section 4.2). On a lower level, completeness is increased by considering normal, parallel and exceptional behaviour for SFs and SIBs. This completion can be formalised by use cases joined into overall use case structures. The RATS tool supports this process by pointing out to the designer where parallel and exceptional behaviour is missing. It then either needs to be defined or explicitly stated that no such behaviour is necessary. 5. FORMAL REQUIREMENTS SPECIFICATION 5.1 Formal specifications SDL is a language for describing real-time, reactive systems such as telecommunications networks and systems, that has been developed and standardised by the ITU-T [Z.100]. There are three main components to the language: • System behaviour is described by a set of SDL processes. Each process is based on a communicating extended finite state machine. • There are comprehensive constructs to describe the structure of systems, which are an extension and formalisation of block diagrams and also support object-oriented structuring concepts. • There are constructs to describe data which is exchanged with a system and which is stored and manipulated by a system. SDL supports service specification by providing clear and complete behaviour descriptions and has been used to develop rigorous specifications of telecommunications services and protocols [Cro93]. 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 like • All the attributes have been defined • Interfaces are used consistently 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, SF or SIB levels 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 services features. The UPT feature models were pair-wise tested against models of switchbased call completion features. The analysis detected 16 feature interaction problems which will now be resolved in the service implementation being developed. 5.3 Implementation and testing SDL specifications of SFs and/or SIBs 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 in-house development, the SDL would form an input to the project developing the required components. Having procured a service platform including the required SIBs, 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 user case specifications of that SF’s behaviour which were produced during requirements development. The required service can now be constructed by provisioning the right combination of SFs for customers. If more classical software development techniques are to be employed, the SDL descriptions of SFs and/or services will provide unambiguous specifications for these developments too. Finally the complete service implementation can be tested against the service level use cases, whose development from the initial requirements can be traced. 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. 6. CONCLUSIONS Our suggested complete development of IN services is novel in four ways: • Requirements are captured freely from customers and a best-fit with existing infrastructure is achieved by negotiation mediated by the RATS tool. The tool uses knowledge about telecommunication networks, SFs and SIBs to actively support this process. • Requirements are managed uniformly and in electronic format, regardless of levels of abstraction, allowing much improved standards of traceability over current commercial tools.
• An intermediate formal description of the IN service is developed, using the specification language SDL, in advance to implementation. This encourages complete and unambiguous specifications and allows early validation activities such as service simulation and feature interaction analysis. • The entire development life cycle is supported by different kinds of tools which ensure high quality of the service software. 7. REFERENCES Belina, F. et al “SDL with Applications from Protocol Specification”, Prentice Hall, 1991. [Bub95] Bubenko, J. “Challenges in Requirements Engineering”, Second IEEE Int. Symp. on RE, March 1995.
[Kel94a] Kelly, B. et al “Evolution of some Test Generation Tools on a real Protocol Example”, 7th International Workshop on Protocol Test Systems, November 1994. [Kel94b] Kelly, B. et al “Feature Interaction Detection using SDL Models”, Globecom’94, 1994. [Kel95]
[Loe95]
[Bel91]
[Coo93] Cookson, M. et al “Design Methodology using SDL”, BT Technology Journal, Vol. 11, No. 4, pp. 16-24, October 1993. [Cro93] Crowther, M. “Modelling and Validation of Telephony Network Signalling”, SDL Forum, October 1993. [Ebe96] Eberlein, A. et al “An Expert System For The Development of New Telecommunications Services” , Eighth International Conference on Artificial Intelligence Applications, October 1996. [I.210] ITU-T Recommendation I.210 “Principles of Telecommunication Services Supported by an ISDN and the Means to Describe Them”, March 1993. [Jac93] Jacobson, I. “Object-Oriented Software Engineering - A Use Case driven Approach”, Addison-Wesley, 1993.
[Myl90]
[Ree92] [Reg95]
Kelly, B. et al “Feature Interactions in Telecommunications Systems”, KYOTO'95, 1995. Loenvig, B. “Experiences with Requirements Capturing, Specification and OO Requirements Analysis”, OOPSLA'95 Workshop on Requirements Engineering: Use Cases and More, 1995. Mylopoulos, J. et al “TELOS: Representing Knowledge about Information Systems”, ACM Transactions of Information Systems 8 (4), pp. 325-362, 1990. Reed, R. et al “Methods for Service Software Design”, IEE 1992. Regnell, B. et al “Improving the Use Case driven Approach to Requirements Engineering”, 2nd IEEE Intnational Symposium on Requirements Engineering, March 1995.
[Sim81] Simon, H. A. “The Sciences of the Artificial”, Second Edition, Cambridge, MA, The MIT Press, 1981. [www-1] http://www.incose.org/workgrps/tools/ tooltax.html [Z.100]
ITU-T Recommendation Z.100 “CCITT Specification and Description Language (SDL)”, June 1994.
