1、 International Telecommunication Union ITU-T Z.151TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (10/2012) SERIES Z: LANGUAGES AND GENERAL SOFTWARE ASPECTS FOR TELECOMMUNICATION SYSTEMS Formal description techniques (FDT) User Requirements Notation (URN) User Requirements Notation (URN) Language de
2、finition Recommendation ITU-T Z.151 ITU-T Z-SERIES RECOMMENDATIONS LANGUAGES AND GENERAL SOFTWARE ASPECTS FOR TELECOMMUNICATION SYSTEMS FORMAL DESCRIPTION TECHNIQUES (FDT) Specification and Description Language (SDL) Z.100Z.109 Application of formal description techniques Z.110Z.119 Message Sequence
3、 Chart (MSC) Z.120Z.129 User Requirements Notation (URN) Z.150Z.159Testing and Test Control Notation (TTCN) Z.160Z.179 PROGRAMMING LANGUAGES CHILL: The ITU-T high level language Z.200Z.209 MAN-MACHINE LANGUAGE General principles Z.300Z.309 Basic syntax and dialogue procedures Z.310Z.319 Extended MML
4、 for visual display terminals Z.320Z.329 Specification of the man-machine interface Z.330Z.349 Data-oriented human-machine interfaces Z.350Z.359 Human-machine interfaces for the management of telecommunications networks Z.360Z.379 QUALITY Quality of telecommunication software Z.400Z.409 Quality aspe
5、cts of protocol-related Recommendations Z.450Z.459 METHODS Methods for validation and testing Z.500Z.519 MIDDLEWARE Processing environment architectures Z.600Z.609 For further details, please refer to the list of ITU-T Recommendations. Rec. ITU-T Z.151 (10/2012) i Recommendation ITU-T Z.151 User Req
6、uirements Notation (URN) Language definition Summary Recommendation ITU-T Z.151 defines the User Requirements Notation (URN) intended for the elicitation, analysis, specification and validation of requirements. URN combines modelling concepts and notations for goals (mainly for non-functional requir
7、ements and quality attributes) and scenarios (mainly for operational requirements, functional requirements and performance and architectural reasoning). The goal sub-notation is called goal-oriented requirements language (GRL) and the scenario sub-notation is called use case map (UCM). History Editi
8、on Recommendation Approval Study Group 1.0 ITU-T Z.151 2008-11-13 17 1.1 ITU-T Z.151 (2008) Cor. 1 2012-04-29 17 2.0 ITU-T Z.151 2012-10-14 17 ii Rec. ITU-T Z.151 (10/2012) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunica
9、tions, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunicati
10、ons on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure l
11、aid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommuni
12、cation administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these ma
13、ndatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draw
14、s attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or
15、 others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not repr
16、esent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2013 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T Z.151 (10/20
17、12) iii Table of Contents Page 1 Scope 1 1.1 Goal modelling with URN 1 1.2 Scenario modelling with URN . 2 1.3 Documentation structure 3 2 References. 3 3 Definitions 4 3.1 Terms defined elsewhere 4 3.2 Terms defined in this Recommendation . 4 4 Abbreviations and acronyms 5 5 Conventions 6 5.1 Gramm
18、ars . 6 5.2 Basic definitions . 6 5.3 Presentation style 6 6 URN basic structural features . 7 6.1 URN abstract grammar metaclasses . 8 6.2 URN concrete grammar metaclasses 12 7 GRL features . 14 7.1 GRL basic structural features . 14 7.2 GRL actors 19 7.3 GRL intentional elements . 21 7.4 GRL links
19、 . 24 7.5 GRL strategies 32 7.6 GRL indicators . 37 7.7 GRL contribution contexts . 43 7.8 GRL concrete grammar metaclasses 46 8 UCM features . 62 8.1 UCM basic structural features 63 8.2 UCM maps and path nodes . 65 8.3 UCM stubs and plug-ins . 92 8.4 UCM components . 102 8.5 UCM scenario definitio
20、ns . 110 8.6 UCM performance annotations 120 8.7 UCM concrete grammar metaclasses . 130 9 Data language . 131 9.1 URN data model . 131 9.2 URN data types . 132 9.3 Grammar for expressions . 134 iv Rec. ITU-T Z.151 (10/2012) Page 9.4 Grammar for actions . 136 9.5 Grammar for failures 137 10 URN inter
21、change format 137 11 URN analysis 138 11.1 GRL model evaluation . 138 11.2 UCM scenario path traversal 140 12 Compliance statement . 145 13 Tool compliance . 150 13.1 Definitions of valid tools 150 13.2 Conformance 150 Annex A URN interchange format: XML schema . 151 Appendix I Summary of the URN 17
22、0 I.1 Summary of abstract metamodel 170 I.2 Summary of concrete metamodel . 175 I.3 Summary of URN symbols 178 Appendix II Examples of GRL model evaluation algorithms 179 II.1 Introduction 179 II.2 Example of quantitative evaluation algorithm . 181 II.3 Example of qualitative evaluation algorithm .
23、185 II.4 Example of hybrid evaluation algorithm 192 II.5 Calculating with exceeding expectations . 193 Appendix III Examples of UCM path traversal mechanisms . 194 III.1 Introduction 194 III.2 Example of depth-first UCM path traversal mechanism 194 III.3 Example of breadth-first UCM path traversal m
24、echanism . 199 Bibliography. 205 Rec. ITU-T Z.151 (10/2012) v Introduction Coverage User Requirement Notation (URN) has concepts for the specification of goals, non-functional requirements, rationales, indicators, behaviour, scenarios and structuring. This Recommendation focuses on the definition of
25、 an abstract syntax, a concrete graphical syntax and an interchange format for URN. An assessment of conformity of the current URN representation to the language requirements for URN (Recommendation ITU-T Z.150) is also included. Application URN is applicable within standards bodies and industry. UR
26、N helps to describe and communicate requirements, and to develop reasoning about them. The main application areas include telecommunication systems, services and business processes, but URN is generally suitable for describing most types of reactive systems and information systems. The range of appl
27、ications is from descriptions of business goals and requirements to high-level system design and architecture. Status/Stability This Recommendation contains the stable definition of URN. URN components for goal modelling and scenario modelling have been used for more than a decade. The main text is
28、accompanied by the following: Annex A: URN Interchange Format: XML Schema Appendix I: Summary of the URN Appendix II: Examples of GRL Model Evaluation Algorithms Appendix III: Examples of UCM Path Traversal Mechanisms URN Change Request Form Rec. ITU-T Z.151 (10/2012) 1 Recommendation ITU-T Z.151 Us
29、er Requirements Notation (URN) Language definition 1 Scope This Recommendation defines the User Requirements Notation (URN) intended for the elicitation, analysis, specification and validation of requirements. URN allows software and requirements engineers to discover and specify requirements for a
30、proposed system or an evolving system, and analyse such requirements for correctness and completeness. URN combines modelling concepts and notations for goals and intentions (mainly for non-functional requirements and quality attributes) and scenarios (mainly for operational requirements, functional
31、 requirements and performance and architectural reasoning). In particular, URN has concepts for the specification of goals, non-functional requirements, rationales, indicators, behaviour, scenarios and structuring. This Recommendation focuses on the definition of an abstract syntax, a concrete graph
32、ical syntax, and an interchange format for URN. An assessment of conformity of the current URN representation to the language requirements for URN ITU-T Z.150 is also included. URN is applicable within standards bodies and industry. URN helps to describe and communicate requirements, and to develop
33、reasoning about them. The main application areas include telecommunications systems, services and business processes, but URN is generally suitable for describing most types of reactive systems and information systems. The range of applications is from business descriptions of goals and requirements
34、 to high-level design. URN is a notation that complies with ITU-T Z.150. It includes concepts and notations satisfying the language requirements of Z.150s URN-NFR (for non-functional requirements) and URN-FR (for functional requirements). URN integrates these concepts and notation into a single lang
35、uage. 1.1 Goal modelling with URN The subset of the URN language that addresses ITU-T Z.150 URN-NFR language requirements is named goal-oriented requirement language (GRL), which is a language for supporting goal-oriented modelling and reasoning about requirements, especially non-functional requirem
36、ents and quality attributes. It provides constructs for expressing various types of concepts that appear during the requirement process. GRL has its roots in two widespread goal-oriented modelling languages: i* and the NFR framework. Major benefits of GRL over other popular notations include the int
37、egration of GRL with a scenario notation and a clear separation of GRL model elements from their graphical representation, enabling a scalable and consistent representation of multiple views/diagrams of the same goal model. There are four main categories of concepts in GRL: actors, intentional eleme
38、nts, indicators and links. The intentional elements in GRL are goals, softgoals, tasks, resources and beliefs. They are intentional because they are used for models that allow answering questions such as why particular behaviours, and informational and structural aspects were chosen to be included i
39、n the system requirements, what alternatives were considered, what criteria were used to deliberate among alternative options, and what the reasons were for choosing one alternative over the other. Actors are holders of intentions; they are the active entities in the system or its environment (e.g.,
40、 stakeholders or other systems) who want goals to be achieved, tasks to be performed, resources to be available and softgoals to be satisfied. Indicators make real-world measurements available for reasoning in the goal model, allowing for a more accurate assessment of the satisfaction of actors. Lin
41、ks are used to connect isolated elements in the requirement model. Different types of links 2 Rec. ITU-T Z.151 (10/2012) depict different structural and intentional relationships (including decompositions, contributions and dependencies). This kind of modelling is different from the detailed specifi
42、cation of “what“ is to be done. Here the modeller is primarily concerned with exposing “why“ certain choices for behaviour and/or structure were made or constraints introduced. The modeller is not yet interested in the operational details of processes or system requirements, or component interaction
43、s. Omitting these kinds of details during early development and standardization phases allows taking a higher level (sometimes called a strategic stance) towards modelling the current or the future standard or software system and its embedding environment. Modelling and answering “why“ questions lea
44、ds one to consider the opportunities stakeholders seek out and/or vulnerabilities they try to avoid within their environment by utilizing capabilities of the software system and/or other stakeholders, by trying to rely upon and/or assign capabilities and by introducing constraints on how those capab
45、ilities ought to be performed. GRL supports the analysis of strategies, which help reach the most appropriate trade-offs among (often conflicting) goals of stakeholders. A strategy consists of a set of intentional elements and indicators that are given initial satisfaction values. These satisfaction
46、 values capture contextual or future situations as well as choices among alternative means of reaching various goals. For indicators, these satisfaction values are based on real-world measurements. These satisfaction values are then propagated to the other intentional elements through their links, e
47、nabling a global assessment of the strategy being studied as well as the global satisfaction of the actors involved. A good strategy provides rationale and documentation for decisions leading to requirements, providing better context for standards/system developers and implementers while avoiding un
48、necessary re-evaluations of worse alternative strategies. GRL also provides support for reasoning about scenarios by establishing correspondences between intentional GRL elements and non-intentional elements referring to scenario models of URN-FR. Modelling both goals and scenarios is complementary
49、and aids the identification of further goals and additional scenarios (and scenario steps) important to stakeholders, thus contributing to the completeness and accuracy of requirements. 1.2 Scenario modelling with URN The subset of the URN language that addresses Z.150 URN-FR language requirements is named use case map (UCM). UCM specifications employ scenario paths to illustrate causal relationships among responsibilities. Furthermore, UCMs provide an integrated view of behaviour and structure by allowing the super
