ITU-T Z 150-2011 User Requirements Notation (URN) C Language requirements and framework (Study Group 17)《用户需求符号(URN)语言需求和框架 17号研究组》.pdf

《ITU-T Z 150-2011 User Requirements Notation (URN) C Language requirements and framework (Study Group 17)《用户需求符号(URN)语言需求和框架 17号研究组》.pdf》由会员分享，可在线阅读，更多相关《ITU-T Z 150-2011 User Requirements Notation (URN) C Language requirements and framework (Study Group 17)《用户需求符号(URN)语言需求和框架 17号研究组》.pdf（40页珍藏版）》请在麦多课文档分享上搜索。

1、 International Telecommunication Union ITU-T Z.150TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (02/2011) SERIES Z: LANGUAGES AND GENERAL SOFTWARE ASPECTS FOR TELECOMMUNICATION SYSTEMS Formal description techniques (FDT) User Requirements Notation (URN) User Requirements Notation (URN) Language re

2、quirements and framework Recommendation ITU-T Z.150 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

3、Message Sequence 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.

4、319 Extended MML 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.

5、409 Quality aspects 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.150 (02/2011) i Recommendation ITU-

6、T Z.150 User Requirements Notation (URN) Language requirements and framework Summary Recommendation ITU-T Z.150, together with other Recommendations in the ITU-T Z.150 series, defines URN (User Requirements Notation), which is intended for the elicitation, analysis, specification, and validation of

7、requirements. URN combines modelling concepts and notations for goals (mainly for non-functional requirements and quality attributes) and scenarios (mainly for operational requirements, functional requirements, and performance and architectural reasoning). Such a notation is needed to capture user r

8、equirements prior to any design. This Recommendation focuses on language requirements for URN and on providing the context for a requirements engineering framework. History Edition Recommendation Approval Study Group 1.0 ITU-T Z.150 2003-02-13 17 2.0 ITU-T Z.150 2011-02-13 17 Keywords Evaluation, fo

9、rmal specification, functional requirements, goal, graphical notation, hierarchical decomposition, non-functional requirements, requirements engineering activities, scenario, transformation. ii Rec. ITU-T Z.150 (02/2011) FOREWORD The International Telecommunication Union (ITU) is the United Nations

10、specialized agency in the field of telecommunications, 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 t

11、hem with a view to standardizing telecommunications 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

12、-T Recommendations is covered by the procedure laid 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 use

13、d for conciseness to indicate both a telecommunication 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

14、 Recommendation is achieved when all of these mandatory 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

15、any party. INTELLECTUAL PROPERTY RIGHTS ITU draws 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 Pro

16、perty Rights, whether asserted by ITU members or 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, i

17、mplementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2011 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior wr

18、itten permission of ITU. Rec. ITU-T Z.150 (02/2011) iii Table of Contents Page 1 Scope 1 1.1 Motivation 1 1.2 Document organization 3 2 References. 3 3 Definitions 3 4 Abbreviations and acronyms 5 5 Scope of URN . 5 5.1 What is URN? . 5 5.2 What is URN-NFR? . 6 5.3 Why goal-oriented requirements eng

19、ineering? 7 5.4 What is URN-FR? 8 5.5 Intended usage 8 6 Language requirements for URN-NFR 9 6.1 Expressing tentative, ill-defined and ambiguous requirements 9 6.2 Clarifying, exploring, and satisficeing goals and requirements . 9 6.3 Expressing and evaluating measurable goals and NFRs 10 6.4 Argume

20、ntation 10 6.5 Linking high-level business goals to system requirements 10 6.6 Multiple stakeholders, conflict resolution and negotiation support . 10 6.7 Requirements prioritization 10 6.8 Requirements creep and churn and other evolutionary forces . 10 6.9 Integrated treatment of functional and non

21、-functional requirements . 11 6.10 Multiple rounds of commitment . 11 6.11 Life-cycle support . 11 6.12 Traceability . 11 6.13 Ease of use and precision . 11 6.14 Modularity 12 6.15 Reusable requirements 12 6.16 Performance indicators . 12 7 Language requirements for URN-FR . 12 7.1 System trigger a

22、nd termination conditions . 12 7.2 System operations and responses . 13 7.3 Complex and lengthy behaviour . 13 7.4 Relationships among scenarios . 14 7.5 Scenario cancellation and failure handling . 14 7.6 Time-dependent behaviour . 14 iv Rec. ITU-T Z.150 (02/2011) Page 7.7 Component definition . 15

23、 7.8 Environment specification 15 8 Other language requirements for URN . 15 8.1 Requirements traceability . 15 8.2 Requirements test case specification 17 8.3 Evaluation of goal and NFR satisfaction 17 8.4 Performance analysis of requirements 18 8.5 Change management 18 8.6 Concrete representations

24、 18 8.7 Usability . 19 8.8 Extensibility 19 9 Language requirements summary . 19 9.1 Requirements table format . 19 9.2 URN requirements table . 19 Appendix I Requirements engineering activities 23 Appendix II Guidelines for the maintenance of URN 26 II.1 Maintenance of URN 26 II.2 Rules for mainten

25、ance 26 II.3 Change request procedure 27 Bibliography. 29 Rec. ITU-T Z.150 (02/2011) v Introduction a) Coverage: This Recommendation focuses on language requirements for URN and on providing the context for a requirements engineering framework. Other Recommendations in the ITU-T Z.150 series define

26、the notation for URN. b) Applications: URN is applicable within standards bodies and industry. URN helps to describe and communicate requirements, and to develop reasoning about them. The main application areas include telecommunication systems and standards, services, and business processes, but UR

27、N is generally suitable for describing most types of reactive systems and information systems. The range of applications is from business goals and requirements description to high-level system design and architecture. c) Status/Stability: This Recommendation provides the scope and requirements for

28、URN. The main text is accompanied by the following: Appendix I: Requirements engineering activities. Appendix II: Guidelines for the maintenance of URN. Bibliography. Rec. ITU-T Z.150 (02/2011) 1 Recommendation ITU-T Z.150 User Requirements Notation (URN) Language requirements and framework 1 Scope

29、This Recommendation provides motivation, scope and language requirements for the ITU-T User Requirements Notation. The specification of compliant notations belongs to other Recommendations. The text of this clause is not normative. 1.1 Motivation A notation is needed that can describe user requireme

30、nts, goals and scenarios without any reference to specific inter-component communication facilities or system components and their states, but at the same time can capture the user requirements prior to design. The focus during the requirements specification stage is on behaviour and on quality attr

31、ibutes. The notation can also be used during the high-level design phase when activities or responsibilities specified in the scenarios are allocated to components. Scenario specification without sub-system component reference would facilitate reusability of scenarios across a wide range of architec

32、tures. The ability of the notation to straddle requirements specification and high-level design will facilitate negotiations between stakeholders and implementers. Before URN was recommended, there was an increasing demand for non-static protocols with policy-driven negotiation using dynamic entitie

33、s. Agent-based systems are examples of systems that require such policy-driven mechanisms. When specifying this kind of protocol, it is not possible to make an early commitment to messages and components at the requirements capture phase. There is also the need for detection and avoidance of undesir

34、able interactions between features or services. Older techniques require large investment in terms of messages and components that need to be checked for interactions. Using the notation specified in this Recommendation can provide insights at the requirements level and enable designers to reason ab

35、out feature interactions early in the design process. It is also important to deal with business objectives, goals, qualities, and non-functional requirements (NFRs) in a more systematic manner during requirements analysis and design. NFRs are requirements such as stringent performance constraints,

36、systems operational costs, reliability, maintainability, portability, interoperability, robustness, and the like. In software development practice, many NFRs are stated only informally, making them difficult to analyse, specify and enforce during software development and to be validated by the user

37、once the final system has been built. Goals and NFRs, however, do play a crucial role during system development, serving as selection criteria for choosing among alternatives during requirements analysis, for example, determining where the system boundaries should be and what functional requirements

38、 to include in the system. Many of the alternative approaches to deal with NFRs originated from the technical work related to quality metrics. Such approaches attempt to quantify NFRs and then measure to what extent an existing system or parts of it meet the desired non-functional requirements. Usef

39、ul metrics exist for NFRs such as performance, reliability, software complexity, and development process maturity. Other approaches, which recognize that many NFRs are often difficult, if not impossible, to quantify, use qualitative-oriented methods such as architectural change scenarios or combinat

40、ions of both qualitative and quantitative methods to evaluate systems. These approaches, however, assume an already existing software system (or parts thereof) that is evaluated for its NFR properties. They do not assist in the specification of NFRs prior to building the system, nor do they provide

41、support 2 Rec. ITU-T Z.150 (02/2011) during the analysis and design of systems. The notation proposed herein deals with NFRs and goals during the process of requirements analysis and system design; it allows for the expression of conflict between goals, of decisions that resolve conflicts and of the

42、 rationale for the trade-off decisions. In addition, given that telecommunication systems are increasingly developed in the context of organization objectives and business processes, URN is also meant to be used to capture such objectives and processes. The unique combination of goals and scenarios

43、found in URN enables not only to describe and analyse “what“, “when“, “who“, and “where“ aspects of business processes, but also “why“ aspects and how they relate to business objectives. The User Requirements Notation is defined to have the following capabilities: a) describe scenarios as first clas

44、s entities without requiring reference to system subcomponents, specific inter-component communication facilities, or subcomponent states; b) capture user requirements when very little design detail is available; c) facilitate the transition from a requirements specification to a high level design i

45、nvolving the consideration of alternative architectures and the discovery of further requirements that must be vetted by the stakeholders; d) have dynamic refinement capability with the ability to allocate scenario responsibilities to architectural components; e) be applicable to the design of polic

46、y-driven negotiation protocols involving dynamic entities; f) facilitate detection and avoidance of undesirable interactions between features; g) provide insight at the requirements level that enables designers to reason about feature interactions and performance trade-offs early in the design proce

47、ss; h) provide facilities to express, analyse and deal with goals and non-functional requirements; i) provide facilities to express the relationship between goals and system requirements; j) provide facilities to capture reusable analysis and design knowledge related to know-how for addressing non-f

48、unctional requirements; k) provide facilities to trace and transform requirements to other languages (especially ITU-T notations and UML); l) provide facilities to connect URN elements to external requirements objects; m) provide facilities to manage evolving requirements; n) provide facilities to m

49、easure the satisfaction of goals and qualities; o) provide facilities to interchange URN models; p) provide means of analysing goal and scenario models; q) provide lightweight mechanisms to extend or tailor the language to a specific domain. The previous methods that used informal natural language for capturing requirements can leave too much open for interpretation and can contain invalid logic. Manual methods are used to validate these specifications with the result that defects are sometimes not caught until the implementatio