CHAPTER 19

SCENARIOS AND QUALITY REQUIREMENTS IN TELECOMMUNICATIONS

Juha Savolainen

Nokia Research Center, Helsinki, Finland

TYPE OF PROJECT

This chapter describes the development of a base station in the telecommunications domain. The project involved a large number of developers working in multiple sites at several countries. In this case study, only one project is covered, although many parts of the approach have been used for other projects over the years. The experiences gathered from different projects and domains are collected as the Lessons Learnt.

APPLICABILITY

The approach represented in this chapter has been applied mainly to large telecommunications systems and to some embedded devices. The management of product quality in the telecommunications domain is a challenging task, where the work products of hundreds of engineers need to be assembled to create the final product release. Therefore, a careful and scalable way is needed to propagate quality characteristics from system level down to individual components. There is no major obstacle to using this approach for smaller scale systems, but modifications may be needed to adapt it to other domains. Possible adaptations are discussed further in the Lessons Learnt section.

In this chapter, we will perform quality refinement using example scenarios to detect potential trouble spots in the software architecture. The assumption is that when the most demanding aspects of the software are produced to the desired quality, the system will most likely have the characteristics that the various stakeholders have expressed.

Our approach relies on the accurate choice of techniques for analyzing the characteristics of the solution. These techniques will presumably differ somewhat when operating in another domain. The selection of evaluation techniques that match the characteristics of the domain, as well as the needs and expectations of stakeholders, is crucial for the success of the quality management process.

POSITION IN THE LIFE CYCLE

ROLES PLAYED BY SCENARIOS

Scenarios were applied to identify and specify (using a tabular format) the functional requirements of the system. The scenarios were also employed to assist and verify the refinement of quality requirements. A subset of the requirements was selected to form a set of architecturally significant requirements, which were used to validate the architecture. The validation is greatly assisted by using scenarios.

STRENGTHS

The main strengths of our approach come from improved understanding of the critical requirements of the system. Concentration on key requirements and then thorough investigation of their fulfillment allow you to gain confidence on the software architecture. The increased understanding of the key requirements for the system improves the architecture by aligning subsystem design better with overall objectives. When software designers know what is wanted from a product, they can design a system that has those properties.

WEAKNESSES

Besides bringing benefits, all practical methods have limitations. In our case, the approach does not guarantee that the system will ultimately satisfy the requirements of its stakeholders. By selecting just a few representative scenarios from the set of all possible scenarios, we favor practicality over the completeness of the approach. In this way, we are able to perform the analysis within the time constraints of a typical industrial project.

The approach relies heavily on the ability of the analyst and other experts to select effective scenarios—those that illustrate the key qualities wanted by stakeholders. If inappropriate scenarios are selected, the approach will not provide reliable results. Unfortunately, there is no formal way to select the right scenarios. The selection has to be made using the analyst's experience and the heuristics that guide the selection of architecturally significant requirements.

CASE STUDY

The telecommunications project described here developed a base station for third generation (3G) networks. The transition from previous GSM-based networks to WCDMA 3G-networks posed new challenges to the development organization. Next-generation base stations were to have much higher data transmission speeds, completely different algorithms, and potentially changed network layout.

The basic concept of the base station is simple. It interacts with a mobile device over the air interface, transmitting and receiving information using microwaves. The data is then sent to other network elements responsible for switching and routing the data to its final destination. The air interface is highly standardized and its functionality is well known. The real challenge for base station development is satisfying the quality requirements that apply to its operation.

This case study is used to demonstrate how scenarios can be used together with quality requirements to help create large-scale high-quality products. The diagrams, requirements, and designs have been modified to limit the complexity of the example, to increase the readability of the case study, and to prevent disclosure of company-specific information. The structure of this case study is shown in a sequential fashion, but this should not be read as implying that a classical waterfall process was used. On the contrary, the actual process was highly iterative, and multiple increments were used during the creation of the product. (Life-cycle process models are discussed by Andrew Farncombe in Chapter 15 of this volume.)

Software systems are specified by identifying what a system should do under specific circumstances. The specification of the system's behavior is done by describing functional requirements. The nonfunctional requirements define the constraints that the system should conform to while operating. Functional requirements are very effectively described by using scenarios, which pinpoint the actual required behavior. Defining the behavior as an interaction between the actor and the system makes scenarios intuitive, easy to understand, and very approachable by various stakeholders.

Nonfunctional requirements (including qualities such as security, dependability, interoperability, performance) typically affect many scenarios. If we are building a system that is supposed to be very secure, many aspects of the system's operation come into play. We must somehow be able to authenticate that the user is what she claims to be. In addition, we must provide services for access control and guarantee the protection of data from unauthorized disclosure. These are critical requirements in this context. These requirements typically affect every scenario that describes interactions between the system and the user.

Nonfunctional requirements can be specified with the help of scenarios. Despite their name, nonfunctional requirements are actually closely connected to system behaviour. Let us first consider performance.

Performance characteristics are very important for a telecommunications system. The speed of user data processing and the number of concurrent managed connections that the system allows are critical requirements for the success of the product. These qualities, however, attach to only a subset of base stations scenarios. For example, there is no extensive requirement for the number of concurrent users or for the high speed of the maintenance interface of a network device. Whether a network element responds within 60 ms or 500 ms to a maintenance mode change does not affect the user's perception of the system. Identifying which scenarios the quality requirements are attached to is a critical phase of specification. If we do not identify all the scenarios that are constrained by the specified qualities, we could easily design a product with inferior characteristics. Conversely, having strict quality requirements for unnecessary scenarios can make our task of designing the system much harder, and might lead to a product that is too complex and expensive for customers' needs.

Scenarios

Scenarios are created during the requirements specification phase. These scenarios form the basis on which the system is created. In this stage, scenarios are used to specify requirements for the system under development. They treat the system as a black box, describing only the interactions between the system and the actor. (The concept of the actor in the Unified Modeling Language is explained by Peter Haumer in Chapter 12 of this volume—see for example his Figure 19.2.) Later, we will define realizations of the scenarios that define the collaboration of architectural elements when performing the scenario. Each scenario is defined within a scope where it applies.

Our initial list included scenarios like

All these scenarios see the systems from the mobile user's perspective, treating the system as a black box.

The software architecture documentation focuses on how the system will satisfy the key requirements. The properties of the architecture can be made concrete by describing how the scenario is performed by the collaborating architectural elements. These interactions clearly take place within the system boundary and, therefore, are out of reach of the black-box scenarios. This is the reason why the software architecture can only be described by using white-box scenarios. We cannot easily discuss the properties of the architecture unless we allow ourselves to define the scenarios in the context of the pieces of which the architecture is formed. This does not mean that scenarios that do not uncover the architectural pieces are without merit. On the contrary, black-box scenarios allow us to easily define the requirements for the architecture without prematurely diving into design. Restricting yourself to only discussing interaction between the environment and the system limits the ways in which you might accidentally start designing the various components of the system while doing requirements.

Quality Requirements

The structure of the software architecture is strongly affected by the quality requirements that the system has to satisfy. A system designed for maximum reliability using highly redundant hardware and advanced software techniques typically has a very different structure than a system aimed at low-cost, mass product markets. For us to be successful in developing systems with strict quality requirements, we must understand correctly the key user requirements for all the wanted characteristics. Naturally, the system must also realize its functional requirements, but those only drive the architectural choices when they are attached to major quality constraints.

Quality Models – Defining What We Want

A quality model defines the main quality requirements that the system should fulfill. The quality model is a refinement hierarchy that makes general quality requirements more concrete and easier to measure.

The need for such a model is real. Most requirement documents, which I have read during my professional career, specify many wonderful properties of the future products. All these systems shall be extremely fast, very reliable, and highly usable. But what does it mean to have a fast system? Does it move quickly or does it have the fastest user interface ever? Or can it process calculations faster than the latest supercomputers? Inability to connect a quality requirement to the corresponding functionality renders a specification worthless. The requirement specifications should be always as concrete and measurable as possible.

Even if we manage to do a good job with the initial requirements, we may lose sight of them during the development project. The high-level goals are forgotten and they fail to guide the development work of the various subsystems and components that are created. The most common problem is that initial requirements remain at the system level and they are not sufficiently taken into account during subsystem design. Correct subsystem design requires that the high-level requirements be transformed into subsystem-specific requirements.

A basic quality model is typically created at the first stage of product development. The model is formed after initial workshops among the most critical stakeholders of the project. Initially, it contains only vague hopes for the system's characteristics. To prevent ambiguity in the specifications, these definitions must be made more concrete without delay. The easiest way to do this is to create a scenario that defines the quality requirement in the context of system functionality.

Many quality requirements can be derived from domain properties. Systems that belong to the same domain typically share many characteristics. For telecommunications systems, these domain requirements often include high reliability and good performance. Since network elements handle between hundreds to tens of thousands of calls, a failure in such a device can have major consequences. The performance of the system should be adequate to handle the high load associated with the number of concurrent calls. In addition to that, the reliability of the system must be very high to guarantee service to mobile network users. Figure 19.1 describes the quality tree for our base station case study. For a real base station, the number of quality requirements is naturally much higher than shown in the figure.

FIGURE 19.1 A quality tree for a base station

Figure 19.1 shows the qualities initially considered important for our case study. The leaf nodes (such as ‘User data transfer’) describe concrete scenarios for which the defined quality is important. Scenarios are added early to make qualities concrete. Typically, only most relevant scenario is added, but nothing prevents the listing of additional ones if this is felt important. Most of the scenarios presented were invented in the previous phase, but some may emerge while creating the quality tree. In any case, the resulting tree is not considered to be a complete mapping of scenarios to qualities. Nor are the scenarios themselves completely specified. Initially, only small narratives are recorded, focusing on interplay between the functionality and related quality constraints.

The Architecture Trade-off Analysis Method (ATAM) was created by the Software Engineering Institute (SEI) to evaluate software architectures (Kazman, Klein and Clements 2000). This method uses scenarios to assess the architecture against the identified quality characteristics. It matches quality attributes to scenarios in the same way that is demonstrated here. In fact, many architecture analysis methods are of great help when applying our approach for software architecture specification. All these architecture evaluation methods provide guidance and examples how to match together specifications on the wanted characteristics and the realization of the architecture.

Organizing quality requirements into hierarchies is nothing new. Besides using the approach for single products it can be also adapted to a case when you are building a family of systems. Quality refinement for product families has been demonstrated in an earlier paper by the author (Kuusela and Savolainen 2000).

Architecturally Significant Requirements (ASRs)

A large system may have a huge number of requirements. Nobody is able to handle all the requirements simultaneously while architecting the system. Development of the software architecture relies on identifying the critical requirements that the system should satisfy. These requirements are said to be architecturally significant. Unfortunately, there is no simple way to identify architecturally significant requirements (ASRs) from the set of all possible requirements. There are, however, some general guidelines for identifying ASRs (Jazayeri, Ran, and van der Linden 2000). According to Alexander Ran, ASRs include

• Characteristics that give the reason for building a new product
• Aspects of the product that crosscutting most of the system
• Requirements that impact the coordination or management of the subsystems

In our case, requirements emerging from the transition to 3G are the main source of ASRs. Many ASRs are recorded in the list of key scenarios together with a quality model. They are also recorded in tabular format. Typically, ASRs reflect the needs of all the stakeholders of the project. Therefore, some ASRs are added to restrict the choices of product development on how to develop the system. An example of such an ASR is

ASR.1 Base station shall be easily configured.

Refinement of ASRs

Earlier we identified a major problem—that a critical system-level requirement may be forgotten during the development. To fight this problem, we try to create component requirements from those defined for the whole system. Again both scenarios and quality requirements are tackled.

The basic process for ASR refinement is easy. First, identify architecturally significant requirements at system level. For each ASR, decide whether it is relevant for every subsystem of the architecture. Record the subsystems that are affected by the ASR. This is typically done together with chief and subsystem architects.

Then refine the ASRs for each subsystem where that requirement was relevant. Ideally, subsystem ASRs should describe concrete requirements for that subsystem. That is, the requirement should not apply system-wide. Rather it should describe some concrete characteristics of the subsystem. It should be easy to check whether the ASR is fulfilled in the subsystem architecture. This is assisted by explicitly demonstrating how the ASRs are fulfilled, by tying them to the architectural solutions at each level of architectural documentation.

In our case study, we divided up the ASRs according to the components in the architecture, and created new requirements for the corresponding components. For example, to match

ASR.1 Base station shall be easily configured,

we can now add a requirement

ASR.ANT.1 Adapt to different antenna configurations

to the Antenna component. For the data processor component the requirement becomes

ASR.DP.1 Easy changeability of data processing algorithms.

The structure of the software architecture is described in the following section.

FIGURE 19.2 Simplified component architecture

Software Architecture

For a large project it is impractical to have the software specified, designed, and documented in one document or by one person. It is necessary to have different scopes where each of those phases can be done semi-independently. On the basis of our knowledge of the required functionality and qualities, an initial architectural model is created. In this section, we introduce a partial component architecture of the base station.

Figure 19.2 shows the component architecture of the base station. Our example consists of four major components. The basic operation of the system can be described by extending the basic scenario to cover the collaboration of individual components.

Documentation of the software architecture serves many purposes. It describes the key concepts and principles on which the architecture is designed. It defines the main architectural styles, and lays down the fundamental building blocks of the software. This documentation gives the rationale for key decisions such as division of the architecture into subsystems, selected communication mechanisms, and the hardware deployment of the software.

Despite that, many traditional architecture methods apply a very structure-oriented view; but the behavioral aspects are equally important. Ignoring behavioral characteristics of the architecture reduces the focus on satisfying the main functionality of the system, and thus may easily lead to overly complex solutions that wrongly emphasize flexibility. Excess flexibility may reduce performance because of higher processing power requirements, and may adversely affect maintainability by making the architecture more complicated.

Other approaches such as Jan Bosch's architecture transformation (Bosch 2000) rely on late introduction of quality characteristics. Architecture is first designed using the functionality of the system, and then evaluated against the wanted quality requirements. If the characteristics of the system do not match the requirements, the architecture is transformed. During the transformation, architectural patterns and styles are injected into the design to provide the wanted properties. For systems that operate in very constrained domains this may result in major overhauls of the system design, making such process unlikely to be a success when taking into account the economic constraints.

In these domains, systems must be designed considering both functional and quality aspects simultaneously. Unfortunately, it is very difficult to define a formal process that would take both of these aspects into account simultaneously. Until software engineering matures enough to provide us tools to do so, architecting will remain a process that is largely guided by heuristics and intuition (Maier and Rechtin 2000) in addition to theoretical models. But you can still at least specify and document the wanted characteristics in a way that allows you to describe functional and quality characteristics together in the context of the software architecture.

What kind of scenarios should be documented? Clearly having all possible scenarios described in the architecture document would be overkill for a large system. We have to be able to select those scenarios that greatly contribute to the understanding of the software architecture. In our approach, those scenarios come from two categories. In the first category belong scenarios that represent the basic functionality of the system. For a mobile phone, it would be the ability to place a call and send an SMS message. In the context of the architecture, these scenarios would describe how the architectural elements collaborate to produce this functionality. That lays the foundation for improving architectural understanding.

Scenarios that are related to the architecturally significant requirements form the second category. Again, for a mobile phone these could include the ability to send highspeed data and perform a video playback. Here, the first scenario would test the speed of the encoding and compression functionality by measuring the throughput of the system, and the latter would evaluate the efficiency of the video codecs, determining if enough processing power exists to perform this operation.

Examples in Documenting Specific Quality Characteristics

Typically, when the architecture document is created, the document is used to communicate the intent of the high-level design to the subsystem architects. Naturally, the architecture specification by itself is not enough to establish a common vision, so close collaboration among chief architects and subsystem architects is required. But this process is greatly facilitated by suitable architecture documentation. Ideally, the document describes aspects of the system design that are meaningful for the subsystem architects and developers.

As discussed before, some scenarios are selected to be part of the architecture documentation because they contribute to some important quality characteristics. In this section, we provide examples on how to document those scenarios for the selected quality attributes, and how to use scenarios to validate that the selected architectural choices were correct.

Documenting Performance Characteristics

Achieving the performance characteristics is important for most embedded systems. In our case, we identified the scenario transmit high-speed data as the most challenging one from the performance perspective. For the performance characteristics this means defining the time budgets for the subsystems and possibly exposing the rationale behind the decisions by including the preliminary performance analysis results.

The time budgets can be easily created with the help of the white-box scenario. After identifying the collaboration of architectural elements for the scenario, maximum execution times for each element can be listed. The sum of the execution times of the elements in the collaboration should be less than the time allowed for the scenario. This way of creating the time budgets is very easy, but unfortunately it is not enough to completely verify the response time characteristics for a complex embedded device with multiple, different interactions running concurrently in the system.

As with any quality attribute, there are many methods and techniques for evaluating and validating system properties. In the case of performance, our initial approach for dividing the allowed response time into time budgets of the architectural elements does not take account the effect of shared resources. Such sharing happens in almost all systems, since hardware resources are typically used by more than one entity. Therefore, some processes must wait for access to needed resources. This means that for accurate performance estimation, the possible blocking of shared resources must be considered. Many different methods allow analysis at various level of detail: for example, queuing network analysis (Smith and Williams 2002) (Menasce, Almeida, and Dowdy 2004); rate monotonic analysis (Klein et al. 1993, Briand and Roy 1999).

It is important to notice that execution times are not the only performance-related parameters that need to be specified. Defining the constraints on memory usage, available communication links, and process creation is equally important.

Documenting Modifiability Characteristics

In our initial scenario list, we did not identify any scenarios for validating the modifiability of the architecture. This is because modifiability does not attach to current functionality. Rather, it explores the amount of change needed when the current functionality is changed or new functions appear.

Ideally, we could change any requirement we like and still be able to make this change quickly with minimal adaptation of other assets. This requires that any change would always nicely localize in the architecture, either by having a single module that realizes the requirement or by having explicit points that provide places where additional functionality can be easily attached. In real life, no architecture allows flexibility for all imaginable changes. All modularizations of the architecture leave many changes that do not localize into a small set of software modules; and excess flexibility has potentially a large negative impact on other qualities such as understandability of the system, development cost, maintainability, and performance. This all means that the modifiability of the system can only be analyzed against an identified change.

For our project, this means listing the possible changes in form of scenarios that briefly describes the change in the context of the system. For these kinds of scenarios it is better to be too concrete than too abstract. This is because you want to have a way to test the architecture and demonstrate its properties. One scenario for our case could be

where ABCD is the actual type of the future antenna. This type of scenario is clearly superior to an alternative scenario

The latter scenario is too generic to be easily analyzed, and it cannot be fulfilled by almost any system, because the scenario does not state which piece of hardware is to be added to the base station. It is not possible to integrate a hair dryer or a toaster into the base station, and it is hard to see that this kind of requirement would ever emerge.

The change of antenna type fortunately localizes into the module HW Drivers. The layered architecture view covering the module structure is shown in Figure 19.3. The scenario claims that the addition of the future antenna should happen without any changes to the software. This means that either a driver for the future antenna already exists in the module or that a compatible driver can be used. In real life, this means that at least the driver interface—if not the actual code—must be investigated for compatibility.

LESSONS LEARNT

Describing and documenting the satisfaction of quality requirements was more difficult than initially estimated. Varying quality requirements, different architectural views and evolving solutions make universally applicable guidelines difficult to give. Lack of books, scientific articles, or tutorial material on how to combine different techniques makes this particularly challenging. But even if the design solutions are documented in an imperfect way, our approach promotes subsystem architects and developers to think about the key requirements and create solutions that, more often than not, satisfy the identified needs.

FIGURE 19.3 Layered view of the base station

Good practical examples are needed that clearly demonstrate how scenarios can be described in different architectural views. This collection of examples should be large enough to cover many different circumstances. Depending on the abstraction level, a quality requirement can be most easily described in a view that matches the level of detail. For example, when describing a performance critical scenario at high level, the most appropriate method would be to show that scenario as a collaboration of architectural elements. However, better estimations can be made when the scenario is mapped to the process structure. Since for large systems, at high level, the process structure may not exist, the preferred representation of the performance critical scenario, and its location in the architecture description, may depend on whether the documentation is describing large subsystems or individual components. Describing quality scenarios in complex industrial projects is not easy, and it requires much more hands-on training than we initially anticipated.

The major benefit of our approach is the concretization of the key requirements that guide the development of the software architecture. Refining the needed quality characteristics down to subsystems seems to improve the resulting system considerably. Defining subsystem requirements exposes the hidden assumptions that people make when interpreting system-level requirements.

The duality of scenarios and quality requirements makes one wonder what comes first. Which is more important? Should I specify my scenarios first or start from the quality requirements? The only right answer is that both are equally important. However, the order in which you should specify the requirements is dominated by your domain.

Suggestions for Well-Understood Domains

In a well-understood domain, the choice among competing products can be based on required qualities. For example; how light the product is, how often it has to be recharged, and whether the measurements of the device can be trusted to determine whether the device will be commercially successful. Typically, all the competing products in a market offer very similar functionality. In this case, I suggest that you start by defining those critical qualities that your product should possess. Then identify which scenarios contribute for the qualities that you just discovered. Especially, try to identify new scenarios that might provide the user added value. These discoveries might allow your product to be differentiated from the other products in the market place. Additionally, your existing assets may become handy. You may be able to also reuse existing scenario descriptions from your the previous products.

Suggestions for Emerging Markets

For emerging markets things are different. If the concept of the product is vague, inventing good, measurable quality requirements is a daunting task. Then, concentrating on user scenarios is most likely the best approach. Concentrating on what the system should do and the most valuable scenarios for the user of the system builds a basis on which the first prototypes can be built. When you have managed to identify the exact user goals in terms of scenarios—discovering the quality requirements becomes much easier.

These are just suggestions for some possible circumstances that you may encounter while trying to apply these ideas. You should first understand your problem and then adapt the ideas presented in this book to fit your problem. There is no such thing as one size fits all.

ACKNOWLEDGEMENTS

I would like to thank all the people working for the base station domain without whom this chapter would not have been possible. Especially I would like to thank (in no particular order) Aki Nyyssönen, Ari Evisalmi, Pekka Rusi, Eero Lähde, Aapo Rautiainen, Tuomo Vehkomäki, and Tanya Widen for their commitment throughout the project.

KEYWORDS

System Specification

Quality Requirements

Software Design

Software Architecture

REFERENCES

Bosch, J., Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach, Addison-Wesley, 2000.

Briand, L. and Roy, D., Meeting Deadlines in Hard Real-Time Systems—The Rate Monotonic Approach, IEEE Computer Society Press, 1999.

Jazayeri, M., Ran, A., and van der Linder, F., Software Architecture in Practice, Addison-Wesley, 2000.

Kazman, R., Klein, M., and Clements, P., ATAM: Method for Architecture Evaluation, Technical Report CMU/SEI-2000-TR-004, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, August 2000.

Klein, M., Ralya, T., Pollak, B., Obenza, R., and Harbour, M., A Practioner's Handbook for RealTime Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems, Kluwer Academic Publishers, 1993.

Kuusela, J. and Savolainen, J., requirements engineering for product lines, International Conference on Software Engineering (ICSE2000), IEEE, 2000, pp. 61–69.

Maier, M. and Rechtin, E., The Art of Systems Architecting, CRC Press, 2000 (based on Systems Architecting by E. Rectin, Prentice Hall, 1990).

Smith, C. and Williams, L., Performance Solutions—A Practical Guide to Creating Responsive, Scalable Software, Addison-Wesley, 2002.