BS ISO IEC 26551-2016 Software and systems engineering Tools and methods for product line requirements engineering《软件和系统工程 生产线需求工程的工具和方法》.pdf

《BS ISO IEC 26551-2016 Software and systems engineering Tools and methods for product line requirements engineering《软件和系统工程 生产线需求工程的工具和方法》.pdf》由会员分享，可在线阅读，更多相关《BS ISO IEC 26551-2016 Software and systems engineering Tools and methods for product line requirements engineering《软件和系统工程 生产线需求工程的工具和方法》.pdf（78页珍藏版）》请在麦多课文档分享上搜索。

1、BSI Standards Publication BS ISO/IEC 26551:2016 Software and systems engineering Tools and methods for product line requirements engineeringBS ISO/IEC 26551:2016 BRITISH STANDARD National foreword This British Standard is the UK implementation of ISO/IEC 26551:2016. It supersedes BS ISO/IEC 26551:20

2、12 which is withdrawn. The UK participation in its preparation was entrusted to Technical Committee IST/15, Software and systems engineering. A list of organizations represented on this committee can be obtained on request to its secretary. This publication does not purport to include all the necess

3、ary provisions of a contract. Users are responsible for its correct application. The British Standards Institution 2016. Published by BSI Standards Limited 2016 ISBN 978 0 580 91403 4 ICS 35.080 Compliance with a British Standard cannot confer immunity from legal obligations. This British Standard w

4、as published under the authority of the Standards Policy and Strategy Committee on 31 May 2016. Amendments/corrigenda issued since publication Date T e x t a f f e c t e dBS ISO/IEC 26551:2016 Software and systems engineering Tools and methods for product line requirements engineering Ingnierie du l

5、ogiciel et des systmes Outils et mthodes pour lingnierie dexigences pour gammes de produits INTERNATIONAL STANDARD ISO/IEC 26551 Reference number ISO/IEC 26551:2016(E) Second edition 2016-05-01 ISO/IEC 2016 BS ISO/IEC 26551:2016ii ISO/IEC 2016 All rights reserved COPYRIGHT PROTECTED DOCUMENT ISO/IEC

6、 2016, Published in Switzerland All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permiss

7、ion. Permission can be requested from either ISO at the address below or ISOs member body in the country of the requester. ISO copyright office Ch. de Blandonnet 8 CP 401 CH-1214 Vernier, Geneva, Switzerland Tel. +41 22 749 01 11 Fax +41 22 749 09 47 copyrightiso.org www.iso.org ISO/IEC 26551:2016(E

8、)BS ISO/IEC 26551:2016ISO/IEC 26551:2016(E)Foreword vi Introduction vii 1 Scope . 1 2 Normative references 1 3 T erms and definitions . 1 4 Reference model for product line requirements engineering 3 5 Product line scoping . 7 5.1 Product scoping 8 5.1.1 Purpose of product scoping 8 5.1.2 Structure

9、information to be used for scoping . 9 5.1.3 Identify products . 9 5.1.4 Analyse common and variable features 10 5.1.5 Define a product portfolio 10 5.2 Domain scoping .10 5.2.1 Purpose of domain scoping .10 5.2.2 Identify functional domains 11 5.2.3 Map features to functional domains 11 5.2.4 Defin

10、e domain scope .12 5.3 Asset scoping .12 5.3.1 Purpose of asset scoping 12 5.3.2 Gather historical data from existing single products 13 5.3.3 Estimate additional effort required to adapt potential assets .14 5.3.4 Estimate expected development effort for new products in the product portfolio defini

11、tion 14 5.3.5 Estimate economic benefits from reusing proposed assets 14 5.3.6 Derive asset proposals from economic evaluation results .15 6 Domain requirements engineering .15 6.1 Domain requirements elicitation .16 6.1.1 Purpose of the domain requirements elicitation 16 6.1.2 Draw a context diagra

12、m 17 6.1.3 Gather domain information .17 6.1.4 Identify initial domain requirements 18 6.1.5 Review the elicited initial domain requirements .18 6.2 Domain requirements analysis 19 6.2.1 Purpose of the domain requirements analysis .19 6.2.2 Classify and balance initial domain requirements 20 6.2.3 A

13、nalyse commonalities and variabilities .20 6.2.4 Model domain requirements 21 6.2.5 Create prototypes and analyse feasibility .21 6.2.6 Develop conceptual test cases and scenarios for acceptance testing 22 6.2.7 Review the analysed domain requirements 22 6.3 Domain requirements specification 23 6.3.

14、1 Purpose of the domain requirements specification .23 6.3.2 Identify sources of domain requirements .23 6.3.3 Establish traceability . 24 6.3.4 Document domain requirements .24 6.3.5 Review the domain requirements specification 25 6.4 Domain requirements verification and validation 25 6.4.1 Purpose

15、 of the domain requirements verification and validation .25 6.4.2 Verify domain requirements .26 6.4.3 Validate domain requirements .26 6.4.4 Validate conceptual test cases and scenarios for acceptance testing 27 ISO/IEC 2016 All rights reserved iii Contents PageBS ISO/IEC 26551:2016ISO/IEC 26551:20

16、16(E)6.4.5 Baseline domain requirements 27 6.4.6 Initiate change management process .28 6.5 Domain requirements management .28 6.5.1 Purpose of the domain requirements management 28 6.5.2 Manage domain requirements change.29 6.5.3 Manage traceability 30 6.5.4 Manage versions of domain requirements .

17、30 6.5.5 Record and report status .30 6.5.6 Manage process improvement 31 6.5.7 Manage feedback 31 7 Variability management in requirements engineering 32 7.1 Variability in textual requirements 32 7.1.1 Purpose of variability in textual requirements.32 7.1.2 Define requirements variability in textu

18、al requirements .33 7.1.3 Document requirements variability in textual requirements 33 7.2 Variability in requirements models .33 7.2.1 Purpose of variability in requirements models33 7.2.2 Define requirements variability in model .34 7.2.3 Document requirements variability in requirements model .34

19、 7.3 Variability mechanisms in requirements 35 7.3.1 Purpose of variability mechanisms in requirements 35 7.3.2 Identify variability mechanisms in requirements 35 7.3.3 Guide the use of variability mechanisms in requirements .36 7.3.4 Verify the usage of variability mechanisms in requirements .36 7.

20、3.5 Improve variability mechanisms in requirements 37 7.4 Traceability between requirements variability and variability model 37 7.4.1 Purpose of traceability between requirements variability and variability model 37 7.4.2 Define explicit links between requirements variability and variability model

21、37 8 Asset management in requirements engineering 38 8.1 Domain requirements artefacts as domain assets 38 8.1.1 Purpose of domain requirements artefacts as domain assets .38 8.1.2 Identify domain requirements artefacts managed as domain assets39 8.1.3 Define configuration and annotation 39 8.2 Appl

22、ication requirements artefacts as application assets 40 8.2.1 Purpose of application requirements artefacts as application assets 40 8.2.2 Identify application requirements artefacts managed as application assets .40 8.2.3 Define configuration and annotation for application requirements assets .40 9

23、 Application requirements engineering .41 9.1 Application requirements elicitation 42 9.1.1 Purpose of the application requirements elicitation .42 9.1.2 Draw a context diagram for an application 42 9.1.3 Identify the requirements gaps between domain and application requirements 43 9.1.4 Bind the be

24、st matching variants 43 9.1.5 Select domain assets 44 9.1.6 Review the elicited application requirements 44 9.2 Application requirements analysis .45 9.2.1 Purpose of the application requirements analysis 45 9.2.2 Classify and balance application specific initial requirements .46 9.2.3 Analyse commo

25、nalities and variabilities .46 9.2.4 Model application specific requirements 47 9.2.5 Create prototypes and analyse feasibility .47 9.2.6 Develop conceptual test cases and scenarios for acceptance testing 48 9.2.7 Review the analysed application requirements .48 9.3 Application requirements specific

26、ation .49 9.3.1 Purpose of the application requirements specification 49 9.3.2 Identify sources of application specific requirements .50 9.3.3 Establish traceabilities for application specific requirements 50 iv ISO/IEC 2016 All rights reservedBS ISO/IEC 26551:2016ISO/IEC 26551:2016(E)9.3.4 Document

27、 application specific requirements 50 9.3.5 Document the rationale for variability decision 51 9.3.6 Review the application requirements specification .51 9.4 Application requirements verification and validation.51 9.4.1 Purpose of the application requirements verification and validation 51 9.4.2 Ve

28、rify application specific requirements .52 9.4.3 Validate application specific requirements52 9.4.4 Validate conceptual test cases and scenarios for acceptance testing 53 9.4.5 Baseline application specific requirements.53 9.4.6 Initiate application change management process .54 9.5 Application requ

29、irements management 54 9.5.1 Purpose of the application requirements management .54 9.5.2 Manage application specific requirements change .55 9.5.3 Manage application specific traceability 55 9.5.4 Manage versions of application specific requirements artefacts 56 9.5.5 Record and report status of ap

30、plication requirements management .56 9.5.6 Manage application specific process improvement56 Annex A (informative) Comparison of requirements engineering tasks between single product and product line 58 Annex B (informative) Process mapping with ISO/IEC 12207, ISO/IEC/IEEE 15288, and ISO/ IEC/IEEE

31、29148 .60 Annex C (informative) A construct for process, method, tool, and aspect 63 Bibliography .64 ISO/IEC 2016 All rights reserved vBS ISO/IEC 26551:2016ISO/IEC 26551:2016(E) Foreword ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)

32、 form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and I

33、EC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC J

34、TC 1. The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of document should be noted. This document was drafted in accordance with th

35、e editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives). Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of

36、any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents). Any trade name used in this document is information given for the convenience of users and does not constitute an endorsem

37、ent. For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISOs adherence to the WTO principles in the Technical Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information The committee responsi

38、ble for this document is ISO/IEC JTC 1, Information technology, Subcommittee SC 7, Software and systems engineering. This second edition of ISO/IEC 26551 cancels and replaces the first edition (ISO/IEC 26551:2012), which has been technically revised.vi ISO/IEC 2016 All rights reservedBS ISO/IEC 2655

39、1:2016ISO/IEC 26551:2016(E) Introduction The main purpose of this International Standard is to establish a baseline for the capabilities of tools and methods of software and systems product line (SSPL) requirements engineering. This International Standard defines how the tools and methods can suppor

40、t the software and systems product line specific requirements engineering processes. A decision for the initial boundaries of domain is made to define a product line scope before initiating domain requirements engineering processes. Domain requirements engineering is carried out in a comprehensive m

41、anner because common and variable requirements and captured variabilities have consequential impacts on member products in a product line. The outcomes of domain requirements engineering processes are transferred into the requirements of a family of products at the application requirements engineeri

42、ng processes. Therefore, requirements engineering tools and methods are to be considered (both engineering processes), namely domain requirements engineering, and application requirements engineering. Product line requirements engineering can be differentiated from a single product requirement engin

43、eering because of the following reasons: There are two core processes in requirements engineering, domain requirements engineering and application requirements engineering. The major aims of the domain requirements engineering processes are to analyse commonality and variability for a family of prod

44、ucts and to prepare necessary variability information for variability modelling. The major aims of the application requirements engineering processes are to define application specific requirements and bind variability defined in domain requirements engineering processes; It is essential to analyse

45、the costs and benefits estimate of a product line and thereby, an organization can make a go/no-go decision. Moreover, the costs and benefits estimate plays a pivotal role as an indicator for assessing the effectiveness and efficiency of a product line. A detailed comparison showing the differences

46、in requirements engineeing tasks between single product and product line is described in Annex A. This International Standard can be used in the following modes: by the users of this International Standard: to benefit people who develop, operate, and manage requirements engineering for software and

47、systems product lines; by a product line organization: to provide guidance in the evaluation and selection for tools and methods for product line requirements engineering; by providers of tools and methods: to provide guidance in implementing or developing tools and methods by providing a comprehens

48、ive set of the capabilities of tools and methods for product line requirements engineering. The ISO/IEC 26550 family of standards addresses both engineering and management processes and covers the key characteristics of product line development. The ISO/IEC 26550 family of standards provides an over

49、view of the consecutive International Standards (i.e. this International Standard through ISO/IEC 26599), as well as the structure of the model: ISO/IEC 26550, ISO/IEC 26551 and ISO/IEC 26555 are published. ISO/IEC 26557, ISO/IEC 26558 and ISO/IEC 26559 are to be published. ISO/IEC 26552, ISO/IEC 26553, ISO/IEC 26554, ISO/IEC 26556, ISO/IEC 26560, ISO/IEC 26561, ISO/IEC 26562, ISO/IEC 26563 are planned International Standards. Processes and capabilities of methods and tools for domain requirements eng