Introduction to the User Requirements Notation: learning by example

Abstract

Recognizing the need for a notation that would be used in the very first and often informal stages of the development cycle, the International Telecommunication Union (ITU-T) initiated a question on a User Requirements Notation (URN), which will be standardized as the Z.150 series of Recommendations. URN supports the development, description, and analysis of requirements for telecommunications systems and services, as well as for other types of complex reactive, distributed, and dynamic systems. Through a wireless telephony example, this paper gives an overview of the core elements and typical usage of the two complementary notations comprised in URN. The Goal-oriented Requirement Language (GRL) is used to describe business goals, non-functional requirements, alternatives, and rationales, whereas Use Case Map (UCM) enables the description of functional requirements as causal scenarios. This paper also briefly explores methodology elements and the complementarity between URN and the existing ITU-T languages.

Introduction

Requirements engineering has become an essential part of all development processes, especially in the area of complex reactive and distributed systems, which includes telecommunications services. However, few standardized notations and techniques can address the needs specific to visualizing and analyzing functional (behaviour) and non-functional requirements (NFRs, such as performance, cost, security, and usability). The User Requirements Notation (URN), to be published by the International Telecommunications Union (ITU-T) in 2003, pioneers work in the standardization of visual notations that address these needs [16]. URN will allow software engineers and requirements engineers to discover or specify requirements for a proposed system or an evolving system, and review such requirements for correctness and completeness. Standardization of a formally defined notation used for capturing and analyzing user requirements aims to make requirements engineering activities more rigorous and predictable and the results yielded by these activities clearer, more consistent, correct, and complete. These results should lead to a reduction of development costs, earlier delivery of products to market, and increased customer satisfaction.

URN focuses on user requirements (desired goals or functions that users or other stakeholders expect the system to achieve) but it also enables the description of their refinement as system requirements (expression of ideas to be embodied in the system or application under development). Like most notations in ITU-T’s family of languages, URN is graphical, because graphical presentations are often compact and evocative.

The URN is intended for use in requirements descriptions in specifications developed by national and international standards organizations. In ITU-T, requirements descriptions are often called Stage 1 descriptions (e.g., Q.65 [13]). The URN is also intended for use by commercial organizations developing requirements specifications for new products and product extensions; these specifications are not necessarily governed by standards.

In order to cope with the ever-increasing complexity of requirements engineering activities for emerging telecommunications services, reactive systems, and distributed systems, URN is defined to have the following capabilities [16]:

• capture user requirements when very little design detail is available;

• describe scenarios as first class entities without requiring reference to system sub-components, specific inter-component communication facilities, or sub-component states;

• facilitate the transition from a requirements specification to a high-level design involving the consideration of alternative architectures and the discovery of further requirements that must be vetted by the stakeholders;

• have dynamic refinement capability with the ability to allocate scenario responsibilities to architectural components;

• be applicable to the design of policy-driven negotiation protocols involving dynamic entities;

• facilitate detection and avoidance of undesirable interactions between services (also called features in this paper);

• provide insight at the requirements level that enables designers to reason about feature interactions and performance trade-offs early in the design process;

• provide facilities to express, analyze and deal with goals and non-functional requirements;

• provide facilities to express the relationship between goals and system requirements;

• provide facilities to capture reusable analysis and design knowledge related to know-how for addressing non-functional requirements;

• provide facilities to trace and transform requirements to other languages (especially ITU-T notations and UML);

• provide facilities to connect URN elements to external requirements objects;

• provide facilities to manage evolving requirements.

Since it is next to impossible to find a single notation that could satisfy all these ambitious objectives, the current proposal for URN combines two complementary notations: the Goal-oriented Requirement Language (GRL) for goals and NFRs, and Use Case Maps (UCMs) for scenarios. The nature and content of GRL and UCMs will be illustrated in 3 Goals, non-functional requirements, and GRL, 4 Scenarios, functional requirements, and use case maps, respectively. As the standard is still evolving and not yet completed, this tutorial focuses on the core notation elements that are the most stable and the most useful. More advanced concepts and notation elements may be tackled at times, but they will not be systematically covered.

In order to illustrate typical applications of the notations, we will use an example from the wireless telephony domain. Though inspired from previous work on the application of UCMs to 2.5 G and 3 G wireless standards in TIA, 3GPP, and 3GPP2 [2], [4], [12], [27], and especially from the work done by Andrade and Logrippo [6], [7], this partial example is artificial and is not a case study as such. It is meant to illustrate a variety of notation elements in a context simpler than real wireless systems and standards, which would need to address many more concerns. In order to help the readers unfamiliar with background terminology and structural concepts commonly found in wireless telephony, a brief introduction to TIA’s Wireless Intelligent Network (WIN) is given in Section 2.

URN does not impose any process or methodology on its users. However, elements of typical processes and relations to other languages are explored in Section 5, followed by our conclusions. As a convenience to the reader, Appendix A provides a summary of the main notation elements found in GRL and UCM.