BS ISO/IEC 26551:2016 – TC:2020 Edition
$280.87
Tracked Changes. Software and systems engineering. Tools and methods for product line requirements engineering
| Published By | Publication Date | Number of Pages |
| BSI | 2020 | 165 |
PDF Catalog
| PDF Pages | PDF Title |
|---|---|
| 95 | Foreword |
| 96 | Introduction |
| 98 | 1 Scope 2 Normative references 3 Terms and definitions |
| 100 | 4 Reference model for product line requirements engineering |
| 104 | 5 Product line scoping |
| 105 | 5.1 Product scoping 5.1.1 Purpose of product scoping |
| 106 | 5.1.2 Structure information to be used for scoping 5.1.3 Identify products |
| 107 | 5.1.4 Analyse common and variable features 5.1.5 Define a product portfolio 5.2 Domain scoping 5.2.1 Purpose of domain scoping |
| 108 | 5.2.2 Identify functional domains 5.2.3 Map features to functional domains |
| 109 | 5.2.4 Define domain scope 5.3 Asset scoping 5.3.1 Purpose of asset scoping |
| 110 | 5.3.2 Gather historical data from existing single products |
| 111 | 5.3.3 Estimate additional effort required to adapt potential assets 5.3.4 Estimate expected development effort for new products in the product portfolio definition 5.3.5 Estimate economic benefits from reusing proposed assets |
| 112 | 5.3.6 Derive asset proposals from economic evaluation results 6 Domain requirements engineering |
| 113 | 6.1 Domain requirements elicitation 6.1.1 Purpose of the domain requirements elicitation |
| 114 | 6.1.2 Draw a context diagram 6.1.3 Gather domain information |
| 115 | 6.1.4 Identify initial domain requirements 6.1.5 Review the elicited initial domain requirements |
| 116 | 6.2 Domain requirements analysis 6.2.1 Purpose of the domain requirements analysis |
| 117 | 6.2.2 Classify and balance initial domain requirements 6.2.3 Analyse commonalities and variabilities |
| 118 | 6.2.4 Model domain requirements 6.2.5 Create prototypes and analyse feasibility |
| 119 | 6.2.6 Develop conceptual test cases and scenarios for acceptance testing 6.2.7 Review the analysed domain requirements |
| 120 | 6.3 Domain requirements specification 6.3.1 Purpose of the domain requirements specification 6.3.2 Identify sources of domain requirements |
| 121 | 6.3.3 Establish traceability 6.3.4 Document domain requirements |
| 122 | 6.3.5 Review the domain requirements specification 6.4 Domain requirements verification and validation 6.4.1 Purpose of the domain requirements verification and validation |
| 123 | 6.4.2 Verify domain requirements 6.4.3 Validate domain requirements |
| 124 | 6.4.4 Validate conceptual test cases and scenarios for acceptance testing 6.4.5 Baseline domain requirements |
| 125 | 6.4.6 Initiate change management process 6.5 Domain requirements management 6.5.1 Purpose of the domain requirements management |
| 126 | 6.5.2 Manage domain requirements change |
| 127 | 6.5.3 Manage traceability 6.5.4 Manage versions of domain requirements 6.5.5 Record and report status |
| 128 | 6.5.6 Manage process improvement 6.5.7 Manage feedback |
| 129 | 7 Variability management in requirements engineering 7.1 Variability in textual requirements 7.1.1 Purpose of variability in textual requirements |
| 130 | 7.1.2 Define requirements variability in textual requirements 7.1.3 Document requirements variability in textual requirements 7.2 Variability in requirements models 7.2.1 Purpose of variability in requirements models |
| 131 | 7.2.2 Define requirements variability in model 7.2.3 Document requirements variability in requirements model |
| 132 | 7.3 Variability mechanisms in requirements 7.3.1 Purpose of variability mechanisms in requirements 7.3.2 Identify variability mechanisms in requirements |
| 133 | 7.3.3 Guide the use of variability mechanisms in requirements 7.3.4 Verify the usage of variability mechanisms in requirements |
| 134 | 7.3.5 Improve variability mechanisms in requirements 7.4 Traceability between requirements variability and variability model 7.4.1 Purpose of traceability between requirements variability and variability model 7.4.2 Define explicit links between requirements variability and variability model |
| 135 | 8 Asset management in requirements engineering 8.1 Domain requirements artefacts as domain assets 8.1.1 Purpose of domain requirements artefacts as domain assets |
| 136 | 8.1.2 Identify domain requirements artefacts managed as domain assets 8.1.3 Define configuration and annotation |
| 137 | 8.2 Application requirements artefacts as application assets 8.2.1 Purpose of application requirements artefacts as application assets 8.2.2 Identify application requirements artefacts managed as application assets 8.2.3 Define configuration and annotation for application requirements assets |
| 138 | 9 Application requirements engineering |
| 139 | 9.1 Application requirements elicitation 9.1.1 Purpose of the application requirements elicitation 9.1.2 Draw a context diagram for an application |
| 140 | 9.1.3 Identify the requirements gaps between domain and application requirements 9.1.4 Bind the best matching variants |
| 141 | 9.1.5 Select domain assets 9.1.6 Review the elicited application requirements |
| 142 | 9.2 Application requirements analysis 9.2.1 Purpose of the application requirements analysis |
| 143 | 9.2.2 Classify and balance application specific initial requirements 9.2.3 Analyse commonalities and variabilities |
| 144 | 9.2.4 Model application specific requirements 9.2.5 Create prototypes and analyse feasibility |
| 145 | 9.2.6 Develop conceptual test cases and scenarios for acceptance testing 9.2.7 Review the analysed application requirements |
| 146 | 9.3 Application requirements specification 9.3.1 Purpose of the application requirements specification |
| 147 | 9.3.2 Identify sources of application specific requirements 9.3.3 Establish traceabilities for application specific requirements 9.3.4 Document application specific requirements |
| 148 | 9.3.5 Document the rationale for variability decision 9.3.6 Review the application requirements specification 9.4 Application requirements verification and validation 9.4.1 Purpose of the application requirements verification and validation |
| 149 | 9.4.2 Verify application specific requirements 9.4.3 Validate application specific requirements |
| 150 | 9.4.4 Validate conceptual test cases and scenarios for acceptance testing 9.4.5 Baseline application specific requirements |
| 151 | 9.4.6 Initiate application change management process 9.5 Application requirements management 9.5.1 Purpose of the application requirements management |
| 152 | 9.5.2 Manage application specific requirements change 9.5.3 Manage application specific traceability |
| 153 | 9.5.4 Manage versions of application specific requirements artefacts 9.5.5 Record and report status of application requirements management 9.5.6 Manage application specific process improvement |
| 155 | Annex A (informative) Comparison of requirements engineering tasks between single product and product line |
| 157 | Annex B (informative) Process mapping with ISO/IEC 12207, ISO/IEC/IEEE 15288, and ISO/IEC/IEEE 29148 |
| 160 | Annex C (informative) A construct for process, method, tool, and aspect |
| 161 | Bibliography |
Related products
-
BS ISO/IEC/IEEE 26511:2018 – TC:2020 Edition
Tracked Changes. Systems and software engineering. Requirements for managers of information for users of systems,…
-
BS ISO 23551-8:2023 – TC
Tracked Changes. Safety and control devices for gas burners and gas-burning appliances. Particular requirements –…
-
BS ISO/IEC/IEEE 26515:2018 – TC:2020 Edition
Tracked Changes. Systems and software engineering. Developing information for users in an agile environment Published…
-
BS ISO/IEC 26550:2015 – TC:2020 Edition
Tracked Changes. Software and systems engineering. Reference model for product line engineering and management Published…
