73,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Complete and comprehensive manual for eliciting, defining, and managing needs and requirements, integration, verification, and validation across the lifecycle
The INCOSE Needs and Requirements Manual presents product development and systems engineering practices, activities, and artifacts from the perspective of needs, requirements, verification, and validation across the system lifecycle. Composed of 16 chapters, this book provides practical guidance to help organizations understand the importance of lifecycle concepts, needs, requirements, verification, and validation activities, enabling them to successfully and effectively implement these activities during product development, systems engineering, and project management.
The parent handbook published by Wiley, INCOSE Systems Engineering Handbook, divides the system lifecycle into a series of processes, with each process described in terms of a series of activities. This Manual provides more detail needed by practitioners to successfully implement these activities, with guidance and lessons learned from hundreds of years of collective experience of the authors, contributors, and reviewers. For example, while the Handbook mentions the need to define the problem statement, mission, goals, and objectives for a system, the Manual provides detailed guidance on doing so.
Sample topics covered in the INCOSE Needs and Requirements Manual include:
- Defining the problem, opportunity, or threat and defining a mission statement, goals, objectives, and measures.
- Identifying external and internal stakeholders, eliciting stakeholder needs and requirements, defining drivers and constraints, and assessing risk.
- Performing lifecycle concept analysis and maturation and defining an integrated set of needs that represents the scope of the project.
- Transforming the integrated set of needs into well-formed design input requirements.
- Using attributes to manage needs and requirements across the lifecycle.
- Continuous integration, verification, and validation across the lifecycle.
- Moving between levels of the architecture, flow down and allocation of requirements, and budgeting performance, resource, and quality requirements.
- Defining the system verification and system validation success criteria, method, strategy, and responsible organizations.
- Planning and executing successful system verification and validation programs.
- Managing needs, requirements, verification, and validation across the lifecycle.
- Understanding the importance of an integrated, collaborative project team and effective communication between team members
The INCOSE Needs and Requirements Manual is an essential accompanying reference to the INCOSE Systems Engineering Handbook for novice and seasoned system engineers, software engineers, project managers, product developers, tool vendors, course developers, educators, trainers, customers, suppliers, non-SE stakeholders , as well as researchers and students studying systems engineering and systems design.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 1225
Veröffentlichungsjahr: 2024
Ähnliche
Table of Contents
COVER
TABLE OF CONTENTS
TITLE PAGE
COPYRIGHT
INCOSE NOTICES
ADDITIONAL COPIES/GENERAL INFORMATION
PREFACE
AUTHORS
MAJOR CONTRIBUTORS
REVIEWERS
REVISION HISTORY
LIST OF FIGURES
LIST OF TABLES
1 INTRODUCTION
1.1 PURPOSE
1.2 SCOPE
1.3 AUDIENCE
1.4 APPROACH
1.5 MAPPING OF NRVV ACROSS STANDARDS
1.6 THE FIVE NRVV ACTIVITY AREAS DISCUSSED IN THIS MANUAL
1.7 NEEDS AND REQUIREMENTS MANUAL ORGANIZATION
2 DEFINITIONS AND CONCEPTS
2.1 ONTOLOGY USED IN THIS MANUAL
2.2 DEFINITIONS
2.3 BASIC CONCEPTS
3 INFORMATION-BASED NEEDS AND REQUIREMENT DEVELOPMENT AND MANAGEMENT
3.1 INFORMATION-BASED NEEDS AND REQUIREMENTS DEFINITION AND MANAGEMENT
3.2 EXPRESSION OF TEXT-BASED NEEDS AND REQUIREMENTS WITHIN RMTS VERSUS MODELS AND DIAGRAMS
4 LIFECYCLE CONCEPTS AND NEEDS DEFINITION
4.1 INTRODUCTION
4.2 PREPARE FOR LIFECYCLE CONCEPTS AND NEEDS DEFINITION
4.3 DEFINE INPUTS TO LIFECYCLE CONCEPTS ANALYSIS AND MATURATION
4.4 CAPTURE PRELIMINARY INTEGRATED SET OF LIFECYCLE CONCEPTS
4.5 LIFECYCLE CONCEPTS ANALYSIS AND MATURATION
4.6 DEFINE AND RECORD THE INTEGRATED SET OF NEEDS
4.7 PLAN FOR SYSTEM VALIDATION
4.8 BASELINE AND MANAGE LIFECYCLE CONCEPTS AND NEEDS DEFINITION OUTPUTS
5 NEEDS VERIFICATION AND VALIDATION
5.1 NEEDS VERIFICATION
5.2 NEEDS VALIDATION
5.3 MANAGE NEEDS VERIFICATION AND VALIDATION RESULTS
5.4 USE OF ATTRIBUTES TO MANAGE NEEDS VERIFICATION AND VALIDATION
6 DESIGN INPUT REQUIREMENTS DEFINITION
6.1 PREPARE FOR DESIGN INPUT REQUIREMENTS DEFINITION
6.2 PERFORM DESIGN INPUT REQUIREMENTS DEFINITION
6.3 BASELINE AND MANAGE DESIGN INPUT REQUIREMENTS
6.4 ARCHITECTURAL LEVELS, FLOW DOWN, ALLOCATION, AND BUDGETING
6.5 SUMMARY OF DESIGN INPUT REQUIREMENTS DEFINITION
7 REQUIREMENTS VERIFICATION AND VALIDATION
7.1 REQUIREMENTS VERIFICATION
7.2 REQUIREMENTS VALIDATION
7.3 MANAGE REQUIREMENTS VERIFICATION AND VALIDATION RESULTS
7.4 USE OF ATTRIBUTES TO MANAGE REQUIREMENTS VERIFICATION AND VALIDATION
8 DESIGN VERIFICATION AND DESIGN VALIDATION
8.1 DESIGN DEFINITION PROCESS OVERVIEW
8.2 EARLY SYSTEM VERIFICATION AND VALIDATION
8.3 UPDATING SYSTEM VERIFICATION AND VALIDATION ARTIFACTS
8.4 DESIGN VERIFICATION
8.5 DESIGN VALIDATION
8.6 MANAGE DESIGN VERIFICATION AND VALIDATION RESULTS
8.7 USE OF ATTRIBUTES TO MANAGE DESIGN VERIFICATION AND DESIGN VALIDATION
9 PRODUCTION VERIFICATION
9.1 PRODUCTION VERIFICATION DEFINED
9.2 SCALABILITY, REPEATABILITY, AND YIELD
9.3 PRODUCTION VERIFICATION VERSUS SYSTEM VERIFICATION
9.4 VERIFICATION AND VALIDATION OF THE MANUFACTURING SYSTEM
9.5 SPECIAL CONSIDERATIONS
9.6 PRODUCTION VERIFICATION
10 SYSTEM VERIFICATION AND VALIDATION COMMON PRINCIPLES
10.1 PLANNING STAGE
10.2 DEFINING STAGE
10.3 EXECUTION STAGE: PERFORMING THE
PROCEDURES
10.4 REPORTING STAGE: DOCUMENTING THE RESULTS
10.5 APPROVAL STAGE
10.6 USE OF ATTRIBUTES TO MANAGE SYSTEM VERIFICATION AND VALIDATION ACTIVITIES
10.7 MAINTAINING THE SYSTEM VERIFICATION AND VALIDATION ARTIFACTS
11 SYSTEM VERIFICATION AND SYSTEM VALIDATION PROCESSES
11.1 SYSTEM VERIFICATION AND VALIDATION PER LEVEL
11.2 MANAGING THE PROJECT’S SYSTEM VERIFICATION AND VALIDATION PROGRAMS
11.3 SYSTEM VERIFICATION ACTIVITIES
11.4 SYSTEM VALIDATION PROCESS
12 THE USE OF OTS SYSTEM ELEMENTS
13 SUPPLIER-DEVELOPED SOI
13.1 CUSTOMER/SUPPLIER RELATIONSHIPS
13.2 CUSTOMER/SUPPLIER VERIFICATION VERSUS VALIDATION CONSIDERATIONS
13.3 ADDRESSING THE EVOLUTIONARY NATURE OF INTERFACE DEFINITIONS
14 NEEDS, REQUIREMENTS, VERIFICATION, AND VALIDATION MANAGEMENT
14.1 PREPARE FOR NEEDS, REQUIREMENTS, VERIFICATION, AND VALIDATION MANAGEMENT
14.2 PERFORM NEEDS, REQUIREMENTS, VERIFICATION, AND VALIDATION MANAGEMENT
15 ATTRIBUTES FOR NEEDS AND REQUIREMENTS
15.1 ATTRIBUTES TO HELP DEFINE NEEDS AND REQUIREMENTS AND THEIR INTENT
15.2 ATTRIBUTES ASSOCIATED WITH SYSTEM VERIFICATION AND SYSTEM VALIDATION
15.3 ATTRIBUTES TO HELP MANAGE THE NEEDS AND REQUIREMENTS
15.4 ATTRIBUTES TO SHOW APPLICABILITY AND ENABLE REUSE
15.5 ATTRIBUTES TO AID IN PRODUCT LINE MANAGEMENT
15.6 GUIDANCE FOR USING ATTRIBUTES
16 DESIRABLE FEATURES OF AN SE TOOLSET
16.1 CHOOSING AN APPROPRIATE TOOLSET
16.2 DESIRABLE FEATURES OF AN SE TOOLSET
APPENDIX A: REFERENCES
APPENDIX B: ACRONYMS AND ABBREVIATIONS
APPENDIX C: GLOSSARYGLOSSARY
APPENDIX D: COMMENT FORM
INDEX
END USER LICENSE AGREEMENT
List of Tables
Chapter 1
TABLE 1.1 NRVV Use Cases.
TABLE 1.2 NRVV Activities as Addressed by Various Organizations and Standard...
Chapter 2
TABLE 2.1 Verification and Validation Definitions in Context.
TABLE 2.2 Verification and Validation Comparisons in Terms of Outcomes.
Chapter 4
TABLE 4.1 Potential Stakeholders over the System Lifecycle.
TABLE 4.2 Example Stakeholders’ Perspectives and Concerns.
TABLE 4.3 Example Checklist for an Elicitation Session.
TABLE 4.4 Preliminary Integrated Set of Lifecycle Concepts.
Chapter 6
TABLE 6.1 Needs-to-Requirements Transformation Matrix.
TABLE 6.2 Example LIR Trace Matrix.
TABLE 6.3 Interface Requirements Audit Spreadsheet.
TABLE 6.4 Example Interface Requirements Audit.
TABLE 6.5 Example Allocation Matrix.
Chapter 10
TABLE 10.1 Tracking Preliminary and Final System Verification and Validation...
TABLE 10.2 Example System Validation Matrix (SVaM).
TABLE 10.3 Example System Verification Matrix (SVM).
TABLE 10.4 Example System Verification Compliance Matrix (SVCM).
Chapter 15
TABLE 15.1 Example Implementation Status Recording and Reporting.
List of Illustrations
Chapter 1
FIGURE 1.1 Relationships Between INCOSE Requirements Working Group (RWG) Pro...
FIGURE 1.2 Relationship of INCOSE SE HB Technical Processes and NRVV Activit...
Chapter 2
FIGURE 2.1 Lifecycle Concepts, Integrated Set of Needs, and Design Input Req...
FIGURE 2.2 Needs Versus Requirements—Different Perspectives.
FIGURE 2.3 NRVV Activity Relationships to the INCOSE SE HB.
FIGURE 2.4 Entity–Relationship Diagram for Customers, Concepts, Entities, Ne...
FIGURE 2.5 Entity–Relationship Diagram for Needs and Requirements Terms.
FIGURE 2.6 Levels in the Context of an Organization.
FIGURE 2.7 Portfolio of Projects Within the Operational Level.
FIGURE 2.8 Supplier-Developed System.
FIGURE 2.9 Levels of a System—Hierarchical View.
FIGURE 2.10 Interactions and Dependences Internal and External to a System....
FIGURE 2.11 Holistic View of the SOI.
FIGURE 2.12 Verification and Validation Confirm that SE Artifacts Generated ...
FIGURE 2.13 Needs Verification and Validation.
FIGURE 2.14 Post-production Verification and Validation.
FIGURE 2.15 Lifecycle Processes in Relation to the SE Vee Model.
FIGURE 2.16 Integrated, Multidiscipline, Collaborative Project Team.
FIGURE 2.17 Project Team Organization.
FIGURE 2.18 Communications Model [18, 19].
FIGURE 2.19 System Development Activities Across the Lifecycle.
Chapter 3
FIGURE 3.1 I-NRDM + MBD = MBSE.
FIGURE 3.2 Information-based Requirement Development and Management Model....
Chapter 4
FIGURE 4.1a Lifecycle and Needs Definition Activities Part 1.
FIGURE 4.1b Lifecycle and Needs Definition Activities Part 2.
FIGURE 4.2
Lifecycle Concepts and Needs Definition
IPO Diagram.
FIGURE 4.3 Example Context Diagram, Boundary Diagram, and External Interface...
FIGURE 4.4 Inputs to the Lifecycle Concepts Analysis and Maturation Activiti...
FIGURE 4.5 Fundamental System Model.
FIGURE 4.6 Functional/Activity Analysis using a SIPOC Diagram.
FIGURE 4.7 Generic Functional Flow Block Diagram or Activity Flow Diagram.
FIGURE 4.8 System Architecture Diagram.
FIGURE 4.9 The Line Between Design Inputs and Design Outputs.
FIGURE 4.10 Input/output Risk Assessment.
FIGURE 4.11 Zeroing in on a Set of Feasible Lifecycle Concepts, Needs, and A...
FIGURE 4.12 Provided Capability Includes People, Process, and Products.
FIGURE 4.13 Sources of the Integrated Set of Needs.
FIGURE 4.14 Needs Feasibility/Risk Bucket.
Chapter 5
FIGURE 5.1 Needs Verification and Needs Validation Overview.
FIGURE 5.2 Needs Verification IPO Diagram.
FIGURE 5.3 Needs Validation IPO Diagram.
Chapter 6
FIGURE 6.1 Design Input Requirements Definition IPO Diagram.
FIGURE 6.2 Design Input Requirement Definition Activities.
FIGURE 6.3 Function with Multiple Performance Characteristics.
FIGURE 6.4 The “Line” Between Design Inputs and Design Outputs.
FIGURE 6.5 The “Line” Within a System Architecture.
FIGURE 6.6 SOI Requirements “Trace to Source” Includes Parent Requirements a...
FIGURE 6.7 Traceability Relationship Meta-model.
FIGURE 6.8 Example Requirement Parent/Child Trace.
FIGURE 6.9 Complexity is a Function of the Number of Interactions Among Syst...
FIGURE 6.10 An Interface is a Boundary, Not a Thing.
FIGURE 6.11 Example External Interface, Context, or Boundary Diagram.
FIGURE 6.12 Example System-to-System Interface Diagram.
FIGURE 6.13 New System 2 Interactions with an Existing System 1.
FIGURE 6.14 New System 2 and System 3 Interactions.
FIGURE 6.15 Interactions Between the Spacecraft Bus and the Payload.
FIGURE 6.16 Interface Requirement Traceability.
FIGURE 6.17 Requirements Feasibility/Risk Bucket.
FIGURE 6.18 PBS and Associated Sets of Engineering Artifacts.
FIGURE 6.19 Document Tree Diagram Example for the Lid Installation Robot.
FIGURE 6.20 Flow down of Design Input Requirements via Allocation and Budget...
FIGURE 6.21 Requirements At One Level Drive the Requirements at the Next Lev...
FIGURE 6.22 Alternate Architecture for Software-Intensive Systems.
FIGURE 6.23 Architecture for a Medical Diagnostic System.
FIGURE 6.24 Allocation and Budgeting Example.
FIGURE 6.25 Allocation and Budgeting Dependencies.
FIGURE 6.26 Allocation and Budgeting Across Interface Boundaries.
FIGURE 6.27 System Architecture Hierarchy Mapped to the SE Vee Model.
Chapter 7
FIGURE 7.1 Design Input Requirements Verification and Validation.
FIGURE 7.2 Requirements Verification IPO Diagram.
FIGURE 7.3 Requirements Validation IPO Diagram.
Chapter 8
FIGURE 8.1 Design Verification and Validation.
FIGURE 8.2 Zeroing in On a Feasible Design and Physical Architecture.
FIGURE 8.3 Design Verification IPO Diagram.
FIGURE 8.4 Design Validation IPO Diagram.
Chapter 9
FIGURE 9.1 Production Verification.
FIGURE 9.2 Production Verification IPO Diagram.
Chapter 10
FIGURE 10.1 System Verification and Validation Stages.
FIGURE 10.2 System Verification and Validation Process Artifacts.
FIGURE 10.3 Success Criteria Influence on System Verification and Validation...
FIGURE 10.4 Iterative Relationship Between Success Criteria, Strategy, and M...
FIGURE 10.5 Procedure Development IPO Diagram.
FIGURE 10.6 Visualizations of the Project’s System Verification and Validati...
Chapter 11
FIGURE 11.1 System Verification and Validation Processes.
FIGURE 11.2 Bottom-up View of System Verification and Validation.
FIGURE 11.3 System Verification IPO Diagram.
FIGURE 11.4 Holistic view of the SOI.
FIGURE 11.5 System Validation IPO Diagram.
Chapter 12
FIGURE 12.1 OTS Determination as Part of Architecture and Design.
FIGURE 12.2 OTS Evaluation for Usage [63].
Chapter 13
FIGURE 13.1 Contract Type and Approach.
Chapter 14
FIGURE 14.1 Needs, Requirements, Verification, and Validation Management IPO...
FIGURE 14.2 Needs, Requirements, Verification, and Validation Management Act...
Chapter 16
FIGURE 16.1 Establishing Traceability Between Data and Information From Diff...
Guide
COVER
TABLE OF CONTENTS
TITLE PAGE
COPYRIGHT
INCOSE NOTICES
PREFACE
AUTHORS
MAJOR CONTRIBUTORS
REVIEWERS
REVISION HISTORY
LIST OF FIGURES
LIST OF TABLES
BEGIN READING
APPENDIX A: REFERENCES
APPENDIX B: ACRONYMS AND ABBREVIATIONS
APPENDIX C: GLOSSARY
APPENDIX D: COMMENT FORM
INDEX
END USER LICENSE AGREEMENT
Pages
iii
iv
xv
xvi
xvii
xviii
xix
xx
xxi
xxii
xxiii
xxiv
1
2
3
4
5
6
7
8
9
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
63
64
65
66
67
68
69
70
71
72
73
74
75
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
277
278
279
280
281
282
283
284
285
286
287
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
445
446
447
448
449
450
451
452
453
454
455
456
457
459
460
461
462
463
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
487
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
INCOSE NEEDS AND REQUIREMENTS MANUAL
NEEDS, REQUIREMENTS, VERIFICATION, VALIDATION ACROSS THE LIFECYCLE
INCOSE-TP-2021-002-012024
Prepared by:
Requirements Working GroupInternational Council on Systems Engineering (INCOSE)7670 Opportunity Road, Suite 220San Diego, California 92111-2222 USA
Written by:
Louis S. WheatcraftMichael J. RyanTami Edner Katz
Copyright © 2025 by John Wiley & Sons, Inc. All rights reserved, including rights for text and data mining and training of artificial intelligence technologies or similar technologies.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey.Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permission.
Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.
Library of Congress Cataloging-in-Publication Data Applied for:
Hardback ISBN: 9781394152742
Cover Design: WileyCover Image: Courtesy of Michael J. Ryan and Louis S. Wheatcraft
INCOSE NOTICES
This INCOSE Technical Product was prepared by the International Council on Systems Engineering (INCOSE). It is approved by the INCOSE Technical Operations Leadership for release as an INCOSE Technical Product.
Author Use
. Authors have full rights to use their contributions in a totally unfettered way with credit to the INCOSE Technical source. Abstraction is permitted with credit to the source.
INCOSE Use
. Permission to reproduce and use this document or parts thereof by members of INCOSE and to prepare derivative works from this document for INCOSE use is granted, with attribution to INCOSE and the original author(s) where practical, provided this copyright notice is included with all reproductions and derivative works.
External Use
. This document may not be shared or distributed to any non-INCOSE third party. Requests for permission to reproduce this document in whole or part, or to prepare derivative works of this document for external and commercial use should be addressed to the INCOSE Central Office, 7670 Opportunity Rd., Suite 220, San Diego, CA 92111-2222.
Electronic Version Use
. Any electronic version of this document is to be used for personal, professional use only and is not to be placed on a non-INCOSE sponsored server for general use.
Any additional use of these materials must have written approval from INCOSE Central.
ADDITIONAL COPIES/GENERAL INFORMATION
Copies of the Needs and Requirements Manual, as well as any other INCOSE document can be obtained from the INCOSE Store. General information on INCOSE, the Requirements Working Group, any other INCOSE working group, or membership may also be obtained from the INCOSE Central Office at:
International Council on Systems Engineering
Telephone: +1 858-541-1725
7670 Opportunity Road, Suite 220
Toll Free Phone (US): 800-366-1164
San Diego, California 92111-2222 | USA
Fax: +1 858-541-1728
E-mail:
Web Site:
http://www.incose.org
PREFACE
This Manual has been prepared and produced by a volunteer group of authors and contributors within the Requirements Working Group (RWG) of the International Council on Systems Engineering (INCOSE).
AUTHORS
The principal authors of this Manual are:
Lou Wheatcraft, Wheatland Consulting, LLC, USA
Michael Ryan, Capability Associates Pty Ltd, AU
Tami Katz, BAE Systems, USA
MAJOR CONTRIBUTORS
Those who made a significant contribution to the generation of this Manual are:
Mark Abernathy, Retired, USA
James R. Armstrong, Stevens Institute of Technology, USA
Brian Berenbach, Georgia Institute of Technology, USA
Simone Bergamo, Thales, FR
Ronald S. Carson, PhD, Seattle Pacific University, USA
Jeremy Dick, Retired, UK
Celeste Drewien, Sandia National Labs, USA
James R. van Gaasbeek, Retired, USA
Rick D. Hefner, Caltech, USA
Henrick Mattfolk, Whirlpool, USA
Lamont McAliley, Veracity Engineering, USA
Donald McNally, Woodward, USA
Kevin E. Orr, Eaton Corporation, USA
Michael E. Pafford, Retired, USA
Susan E. Ronning, ADCOMM Engineering LLC, USA
Raymond B. Wolfgang, Sandia National Labs, USA
Gordon Woods, East West Railway Company, UK
Richard Zinni, Harris Corporation, USA
REVIEWERS
In addition to the authors and contributors, below are the names of those who submitted review comments that were included during the development of this Manual:
Angel Agrawal, Northrop Grumman, USA
Ben Canty, Ball Aerospace and Technologies Corporation, USA
James B. Burns, Johns Hopkins University, USA
Ken Eastman, Ball Aerospace and Technologies Corporation, USA
Raymond Joseph, Odfjell Terminal, Houston, USA
Jenn Molloy, Ball Aerospace and Technologies Corporation, USA
Michele Reed, Shell Products and Technology, USA
Andreas Vollerthun, Dr., KAIAO-Consulting, DE
Beth Wilson, retired, USA
REVISION HISTORY
Revision
Revision Date
Change Description and Rationale
1.0
January 2022
First release
1.1
May 2022
Editorial and alignment with other RWG products
2.0
November 2024
Major update based on use and comments and alignment with other RWG products.
LIST OF FIGURES
1.1. Relationships Between INCOSE Requirements Working Group (RWG) Products and the INCOSE SE HB and SEBoK.
1.2. Relationship of INCOSE SE HB Technical Processes and NRVV Activities Discussed in this Manual.
2.1. Lifecycle Concepts, Integrated Set of Needs, and Design Input Requirements.
2.2. Needs Versus Requirements—Different Perspectives.
2.3. NRVV Activity Relationships to the INCOSE SE HB.
2.4. Entity–Relationship Diagram for Customers, Concepts, Entities, Needs, and Requirements Terms.
2.5. Entity–Relationship Diagram for Needs and Requirements Terms.
2.6. Levels in the Context of an Organization.
2.7. Portfolio of Projects Within the Operational Level.
2.8. Supplier-Developed System.
2.9. Levels of a System—Hierarchical View.
2.10. Interactions and Dependences Internal and External to a System.
2.11. Holistic View of the SOI.
2.12. Verification and Validation Confirm that SE Artifacts Generated During Transformation are Acceptable.
2.13. Needs Verification and Validation.
2.14. Post-production Verification and Validation.
2.15. Lifecycle Processes in Relation to the SE Vee Model.
2.16. Integrated, Multidiscipline, Collaborative Project Team.
2.17. Project Team Organization.
2.18. Communications Model [18, 19].
2.19. System Development Activities Across the Lifecycle.
3.1. I-NRDM + MBD = MBSE.
3.2. Information-based Requirement Development and Management Model.
4.1a. Lifecycle and Needs Definition Activities Part 1.
4.1b. Lifecycle and Needs Definition Activities Part 2.
4.2.Lifecycle Concepts and Needs Definition IPO Diagram.
4.3. Example Context Diagram, Boundary Diagram, and External Interface Diagram.
4.4. Inputs to the Lifecycle Concepts Analysis and Maturation Activities.
4.5. Fundamental System Model.
4.6. Functional/Activity Analysis using a SIPOC Diagram.
4.7. Generic Functional Flow Block Diagram or Activity Flow Diagram.
4.8. System Architecture Diagram.
4.9. The Line Between Design Inputs and Design Outputs.
4.10. Input/output Risk Assessment.
4.11. Zeroing in on a Set of Feasible Lifecycle Concepts, Needs, and Architecture.
4.12. Provided Capability Includes People, Process, and Products.
4.13. Sources of the Integrated Set of Needs.
4.14. Needs Feasibility/Risk Bucket.
5.1. Needs Verification and Needs Validation Overview.
5.2. Needs Verification IPO Diagram.
5.3. Needs Validation IPO Diagram.
6.1. Design Input Requirements Definition IPO Diagram.
6.2. Design Input Requirement Definition Activities.
6.3. Function with Multiple Performance Characteristics.
6.4. The “Line” Between Design Inputs and Design Outputs.
6.5. The “Line” Within a System Architecture.
6.6. SOI Requirements “Trace to Source” Includes Parent Requirements and Needs.
6.7. Traceability Relationship Meta-model.
6.8. Example Requirement Parent/Child Trace.
6.9. Complexity is a Function of the Number of Interactions Among System Elements.
6.10. An Interface is a Boundary, Not a Thing.
6.11. Example External Interface, Context, or Boundary Diagram.
6.12. Example System-to-System Interface Diagram.
6.13. New System 2 Interactions with an Existing System 1.
6.14. New System 2 and System 3 Interactions.
6.15. Interactions Between the Spacecraft Bus and the Payload.
6.16. Interface Requirement Traceability.
6.17. Requirements Feasibility/Risk Bucket.
6.18. PBS and Associated Sets of Engineering Artifacts.
6.19. Document Tree Diagram Example for the Lid Installation Robot.
6.20. Flow down of Design Input Requirements via Allocation and Budgeting.
6.21. Requirements At One Level Drive the Requirements at the Next Level.
6.22. Alternate Architecture for Software-Intensive Systems.
6.23. Architecture for a Medical Diagnostic System.
6.24. Allocation and Budgeting Example.
6.25. Allocation and Budgeting Dependencies.
6.26. Allocation and Budgeting Across Interface Boundaries.
6.27. System Architecture Hierarchy Mapped to the SE Vee Model.
7.1. Design Input Requirements Verification and Validation.
7.2. Requirements Verification IPO Diagram.
7.3. Requirements Validation IPO Diagram.
8.1. Design Verification and Validation.
8.2. Zeroing in On a Feasible Design and Physical Architecture.
8.3. Design Verification IPO Diagram.
8.4. Design Validation IPO Diagram.
9.1. Production Verification.
9.2. Production Verification IPO Diagram.
10.1. System Verification and Validation Stages.
10.2. System Verification and Validation Process Artifacts.
10.3. Success Criteria Influence on System Verification and Validation Planning and Implementation.
10.4. Iterative Relationship Between Success Criteria, Strategy, and Method.
10.5. Procedure Development IPO Diagram.
10.6. Visualizations of the Project’s System Verification and Validation Data and Information.
11.1. System Verification and Validation Processes.
11.2. Bottom-up View of System Verification and Validation.
11.3. System Verification IPO Diagram.
11.4. Holistic view of the SOI.
11.5. System Validation IPO Diagram.
12.1. OTS Determination as Part of Architecture and Design.
12.2. OTS Evaluation for Usage [63].
13.1. Contract Type and Approach.
14.1. Needs, Requirements, Verification, and Validation Management IPO Diagram.
14.2. Needs, Requirements, Verification, and Validation Management Activities.
16.1. Establishing Traceability Between Data and Information From Different Tools.
LIST OF TABLES
1.1 NRVV Use Cases.
1.2 NRVV Activities as Addressed by Various Organizations and Standards.
2.1 Verification and Validation Definitions in Context.
4.1 Potential Stakeholders over the System Lifecycle.
4.2 Example Stakeholders’ Perspectives and Concerns.
4.3 Example Checklist for an Elicitation Session.
4.4 Preliminary Integrated Set of Lifecycle Concepts.
6.1 Needs-to-Requirements Transformation Matrix.
6.2 Example LIR Trace Matrix.
6.3 Interface Requirements Audit Spreadsheet.
6.4 Example Interface Requirements Audit.
6.5 Example Allocation Matrix.
10.1 Tracking Preliminary and Final System Verification and Validation Status.
10.2 Example System Validation Matrix (SVaM).
10.3 Example System Verification Matrix (SVM).
10.4 Example System Verification Compliance Matrix (SVCM).
15.1 Example Implementation Status Recording and Reporting.
1INTRODUCTION
1.1 PURPOSE
This Needs and Requirements Manual (NRM) presents systems engineering (SE) from the perspective of the definition and management across the system lifecycle of needs, requirements, verification, and validation (NRVV). NRVV are common threads that tie together all lifecycle activities and processes.
As presented in this Manual, for acceptance, certification, and qualification, the system or product being developed is verified against design input requirements and validated against its integrated set of needs. To successfully complete system verification and system validation, the needs and requirements of the system as well as the system verification and validation artifacts must be managed throughout the entire system lifecycle. This Manual provides practical guidance on the concepts and activities required to achieve those outcomes.
As shown in Figure 1.1, this Manual supplements and elaborates the INCOSE Systems Engineering Handbook (SE HB) [1] and the Systems Engineering Body of Knowledge (SEBoK) [2], providing more detailed guidance on the “what,” “how,” and “why” concerning NRVV across the system lifecycle. The NRM also addresses ambiguity and inconsistencies in NRVV terminology and ontology.
Figure 1.1 shows this Manual is further elaborated by several supporting guides. The Guide to Needs and Requirements (GtNR) [3] and the Guide to Verification and Validation (GtVV) [4] focus further on the “what” and “how” of the specific processes being implemented within an organization. The level of detail is similar in content to an organization’s Work Instructions (WIs) or Standard Operating Procedures (SOPs). These guides reference this Manual for specific guidance on the “why” and underlying concepts, maintaining consistency in approach and ontology defined in this Manual.
FIGURE 1.1 Relationships Between INCOSE Requirements Working Group (RWG) Products and the INCOSE SE HB and SEBoK.
Although this Manual addresses the activities and underlying analysis associated with defining individual and sets of needs and design input requirements, the actual writing of the need and requirement statements is covered in the INCOSE Guide to Writing Requirements (GtWR) [5]. The GtWR includes a list of key characteristics of well-formed needs and requirements and sets of needs and requirements, as well as a set of rules that can help achieve those characteristics. Throughout this Manual, when the activities being discussed contribute to a given characteristic defined in the GtWR, a trace to that characteristic is included.
Figure 1.1 also shows that this Manual and the associated guides advocate a data-centric approach to Project Management (PM) and SE as defined in the INCOSE RWG Whitepaper Integrated Data as a Foundation of Systems Engineering[6], as discussed in Chapter 3 of this Manual.
1.2 SCOPE
To support PM and SE from an NRVV perspective, this Manual:
Provides PM and SE practitioners with an understanding of the best practices for effective NRVV definition and management throughout the system lifecycle.
Helps organizations understand that NRVV are key elements of SE activities.
Provides guidance to the successful implementation of NRVV activities as part of PM and SE, in any domain.
Reinforces the idea that adequate definition of lifecycle concepts and a well-formed set of needs is a prerequisite to the definition of a well-formed set of system design input requirements.
Provides practical, cross-domain guidance to enable organizations to integrate best practices and concepts within their PM and SE processes, activities, WIs, and procedures.
Provides a clear description of how the terms verification and validation are applied to the artifacts generated across the system lifecycle.
Describes the importance of planning early for verification and validation activities across the lifecycle and the inclusion of verification and validation artifacts in system models.
Provides thorough guidance to readers on planning, definition, execution, and reporting of verification and validation activities across the system lifecycle.
Provides guidance and best practices that will help customers avoid accumulating technical debt and enable projects and suppliers to deliver a winning product.
Presents a data-centric approach to NRVV definition and management.
Provides guidance for organization- and enterprise-wide sharing of data and information associated with developing and managing an integrated set of needs, the resulting design input requirements, and design output specifications, as well as verification and validation artifacts throughout the system lifecycle.
1.3 AUDIENCE
This Manual is intended for those whose role is to perform NRVV activities throughout the system lifecycle. This includes those who verify that the design and realized System of Interest (SOI) meet the requirements and those who validate that the requirements, design, and realized SOI meet the needs in the intended operational environment when used by the intended users and mitigate risk of any misuse of the SOI and losses because of misuse.
This Manual is addressed to practitioners of all levels of experience. Someone new to PM and SE should find the specific guidance useful, and those more experienced should be able to find new insights concerning NRVV across all stages of the system lifecycle, which is often absent from other texts, guides, or standards, particularly in terms of a data-centric perspective.
Major user groups who will benefit from the use of this Manual include systems engineers, requirements engineers, business analysts, product developers, system architects, configuration managers, designers, testers, verifiers, validators, manufacturers, coders, operators, users, disposers, course developers, trainers, tool vendors, project managers, acquisition personnel, lawyers, regulators, and standards organizations. Specific use cases for various classes of readers are shown in Table 1.1.
1.4 APPROACH
While this Manual addresses the specific application of the activities and concepts associated with NRVV, the specifics of “how” this information is applied are not prescribed. For example, while the use of models and a data-centric approach is advocated, the specifics concerning how to implement these concepts within the project’s toolset are not addressed; while the use of Requirement Management Tools (RMTs) is advocated, the specifics concerning any particular RMT are not discussed. In this regard, this Manual is structured to enable other INCOSE Working Groups (WGs) and tool vendors to develop domain or tool-specific guides that tailor these contents to best fit the needs of the organization.
There are many use cases for how organizations practice SE to develop systems and products. This Manual presents a generic set of concepts and activities that can be applied. It is not intended that organizations adopt all the activities presented, but rather use the best practices presented to tailor their product development activities and processes appropriate to their domain, product line, workforce, and culture in such a way that provides the most value. For additional guidance concerning tailoring, refer to Chapter 4 of the INCOSE SE HB [1].
TABLE 1.1NRVV Use Cases.
Reader
Use Cases
Novice practitioners
: those new to SE and NRVV
Learn and understand NRVV terminology, concepts, and best practices
Access a structured, unambiguous, and comprehensive source of information and knowledge to help learn NRVV from a data-centric perspective
Learn a consistent and unambiguous ontology (meta-model) for NRVV
Seasoned practitioners
: those experienced in SE and NRVV but not from a data-centric perspective
Gain more in-depth understanding of NRVV from a data-centric perspective
Reinforce, refresh, build upon, and renew their NRVV knowledge
Tailor the concepts in the NRM to their organization’s product line, processes, and culture
Adopt the NRVV best practices presented in this Manual
Use this Manual to help mentor novice practitioners in the realm of NRVV
Course developers/educators/trainers:
individuals or organizations that specialize in training practitioners and other stakeholders in NRVV processes and tools
Use a structured, unambiguous, and comprehensive source of information and knowledge to help teach NRVV from a data-centric perspective
Suggest relevant NRVV topics to trainers for their course content
Present a consistent and unambiguous ontology for NRVV.
Lead SE curricula development and revision inside their own organizations based on best practices and knowledge presented in this Manual
Tool vendors:
organizations that provide applications that enable the data-centric practice of SE
Implement recommended features in a toolset to enable practitioners to develop and manage NRVV across the system lifecycle from a data-centric perspective
Align their PM and SE toolset products with a comprehensive set of NRVV activities and artifacts and underlying data and information
Apply Artificial Intelligence (AI) as a “digital assistant,” helpful in the performance of the activities defined in this Manual
Project managers:
those who manage product development projects
Understand overall product development lifecycle processes from the perspective of SE and NRVV
Understand what a data-centric practice of SE means and its advantages
Understand the value and importance of SE and NRVV activities to project success—and the importance of budgeting for and scheduling such activities
Understand how measures and metrics managed within the SE toolset can help better manage product development projects
Provide an accurate and comprehensive SE and NRVV reference, for both training and practitioner use
Provide more accurate cost and schedule estimates for complex systems engineering projects
Suggest cost and schedule savings to complex systems engineering projects, even without an engineering background
Non-SE stakeholders:
those involved in non-SE project activities
Understand basic terminologies, scope, best practices, artifacts, and value associated with SE and NRVV from a data-centric perspective
Understand how various NRVV activities and artifacts relate to other SE and PM activities and artifacts
Understand NRVV activities and the various opportunities for cross-functional collaboration between non-SE stakeholders and SE practitioners
Customers:
those who request a work product or outsource the development of an SOI to a supplier.
Understand overall product development lifecycle processes from the perspective of SE and NRVV activities.
Understand the role that both the customer and supplier have in these activities.
Suppliers:
those who supply an SOI to a customer.
Understand the importance of clearly defining in the supplier
Statement of Work
(
SOW
), Statement of Objectives (SOO), Performance Work Statement (PWS), or Supplier Agreement (SA) processes and deliverables and the relationships of the customer/supplier roles and responsibilities concerning the development, manufacturing, coding, verification, and validation of an SOI.
Understand the relationship between needs and a customer’s strategic objectives driving them.
Understand why the integrated system must be managed across all lifecycle activities.
Understand why an integrated set of needs must be defined, against which the integrated system will be validated prior to defining the set of design input requirements.
Understand the value of providing suppliers with the underlying analysis and resulting data and information used to define the integrated set of needs and set of design input requirements.
Note: The end item being developed can be referred to as either a system or a product. Either term implies the integrated system, which comprises subsystems and lower-level system elements (assemblies, sub-assemblies, and components) that are defined within the system architecture. An SOI is a specific entity (system, subsystem, or system element) that is to be defined, developed, verified, validated, and delivered to either internal or external customers and then used, sustained, and retired. The concepts discussed here apply to any SOI, no matter where it exists in the physical architecture, so the term SOI will be used to stand for both systems and products.
1.5 MAPPING OF NRVV ACROSS STANDARDS
Various PM and SE organizations and standards may name and group the NRVV activities discussed in this Manual differently, combining several of these activities and assigning various names to the resulting technical processes as shown in Table 1.2.
TABLE 1.2NRVV Activities as Addressed by Various Organizations and Standards.
PMI
®
SEI
®
/CMMI
®
ISO/IEC/IEEE 15288/29148
INCOSE SE HB
NASA NPR 7123 & SE HB
Requirements Development
X
X
Requirements Management
X
X
X
Business or Mission Analysis Process
X
X
Stakeholder Needs and Requirements Definition
X
X
Systems Requirements Definition
X
X
Stakeholder Expectations Definition
X
Technical requirements definition
X
System verification
X
X
X
X
X
System validation
X
X
X
X
X
The Project Management Institute (PMI®) and Carnegie Mellon’s Software Engineering Institute (SEI®) Capability Maturity Model Integrated (CMMI®) separate requirements development and management into two separate processes, “Requirements Development” and “Requirements Management.” Verification and validation of the lifecycle concepts and needs and of the resulting design input requirements are divided between the two main processes. Lifecycle concepts analysis and maturation and needs definition are included as part of Requirements Development, and management of lifecycle concepts and needs is included as part of Requirements Management.
ISO/IEC/IEEE 15288 [7] defines needs and requirements in terms of organizational levels: organizational (enterprise), strategic, operational, system, and system elements. Lifecycle concepts, needs, and requirements (CNR) are defined for each level at a level of abstraction appropriate to that level. The INCOSE SE HB divides requirement development and management into three technical process areas in accordance with ISO/IEC/IEEE 15288: Business or Mission Analysis Process for lifecycle CNR at the strategic level, Stakeholder Needs and Requirements Definition Process for lifecycle CNR at the operational level, and Systems Requirements Definition Process for lifecycle CNR at the system level and below. Chapter 2 of this Manual provides a more detailed discussion of levels of lifecycle CNR.
In the context of the CMMI, Requirement Development process, ISO/IEC/IEEE 15288, ISO/IEC/IEEE 29148 [8], and INCOSE SE HB [1] separate Requirements Development activities into the above mentioned three areas such that Business or Mission Analysis Process and Stakeholder Needs and Requirements Process correspond to the development of stakeholder needs, and System Requirements Definition Process corresponds to the development of the system-level requirements.
Within ISO/IEC/IEEE 15288, ISO/IEC/IEEE 29148, and the INCOSE SE HB technical processes, system-level lifecycle CNR are combined into one process area: Systems Requirements Definition. In addition, in these documents, there is no separate needs and requirement management process to address the activities associated with needs and requirements management. Instead, needs and requirements management is included as part of the Systems Requirements Definition Process activities, and other technical process.
While including the lifecycle processes contained in ISO/IEC/IEEE 15288, ISO/IEC/IEEE 29148 also includes clause 6.6 concerning requirements management as a distinct activity.
The National Aeronautics and Space Administration (NASA) NASA Procedural Requirements (NPR) 7123.1C, NASA SE Processes and Requirements Document [9], and the companion NASA SE HB NASA/SP-2016-6105 [10] define three process areas that address needs and requirements: Stakeholder Expectations Definition, Technical Requirements Definition, and Requirement Management. The Stakeholder Expectations Definition and Requirements Definition processes are similar to those defined in ISO/IEC/IEEE 15288, ISO/IEC/IEEE 29148, and INCOSE SE HB; however, NASA includes a separate crosscutting Requirement Management process.
Another difference between the NASA SE HB and the INCOSE SE HB is that the NASA SE HB Stakeholder Expectations Definition Process does not use the terms stakeholder needs and stakeholder requirements. However, the form of communicating stakeholder expectations is not specifically stated, implying that the stakeholder expectations are communicated via Operations Concept (OpsCon) and Concept of Operations (ConOps) documents. See Chapter 4 for a more detailed discussion concerning OpsCon versus ConOps.
All organizations include distinct verification and validation processes; however, the organizational element within an organization responsible for these activities tends to vary. PMI/CMMI places verification and validation activities as part of Quality Management (QM), while INCOSE and NASA place verification and validation activities as part of SE.
1.6 THE FIVE NRVV ACTIVITY AREAS DISCUSSED IN THIS MANUAL
As shown in Figure 1.2, the five NRVV activity areas defined below trace to, and are an elaboration of, the Business or Mission Analysis, Stakeholder Needs and Requirements Definition, System Requirements Definition, Verification, and Validation technical process activities defined in ISO/IEC/IEEE 15288 and INCOSE SE HB. Note: These activity areas are highly integrated with and dependent on the other technical processes defined in ISO/IEC/IEEE 15288 and INCOSE SE HB, including the Architectural Definition Process, Design Definition Process, and Integration Process as well as the crosscutting Interface Management and the technical management processes. Because of the dependencies, the activities and processes shown in Figure1.2, are best performed concurrently rather than serially.
FIGURE 1.2 Relationship of INCOSE SE HB Technical Processes and NRVV Activities Discussed in this Manual.
The focus of this Manual is on the NRVV activities required for an SOI to be developed, managed, delivered, used, sustained, and retired. This Manual divides these activities into the following five activity areas:
Lifecycle Concepts and Needs Definition:
The focus is on defining a feasible set of lifecycle concepts and a well-formed integrated set of needs that will result in an SOI that will meet the defined problem or opportunity;
mission, goals, and objective
s (
MGO
s); measures; needs; and requirements defined at the operational and strategic levels of the organization as well as by an external customer.
Lifecycle Concepts and Needs Definition activities are discussed in detail in
Chapters 4
and
5
.
Design Input Requirements Definition:
The focus is on transforming the baselined integrated set of needs for an SOI into well-formed design input requirements expressed as “shall” statements that are inputs for defining the SOI physical architecture, flowing requirements down the architecture, and realization of the SOI via a design solution. The design input requirements address what the system, subsystem, or system element must do to satisfy their integrated set of needs from which they were transformed without stating how they are to be implemented (design outputs).
Design Input Requirements Definition is discussed in detail in
Chapters 6
and
7
.
System Verification
. The focus is on planning for system verification, executing those plans, recording the results, and reporting the results to an Approval Authority
. System Verification is discussed in detail in
Chapters 10
and
11
.
System Validation
. The focus is on planning for system validation, executing those plans, recording the results, and reporting the results to an Approval Authority
. System Validation is discussed in detail in
Chapters 10
and
11
.
Needs, Requirements, Verification, and Validation Management
. The focus is on managing the sets of needs and the sets of design input requirements, including managing the needs and requirement definition activities, managing the flow down (allocation and budgeting) of requirements from one level to another, validating bidirectional traceability, and managing the design and system verification and validation artifacts.
Needs, Requirements, Verification, and Validation Management are discussed in detail in
Chapter 14
.
1.7 NEEDS AND REQUIREMENTS MANUAL ORGANIZATION
This Manual is organized as follows:
Chapter 1
introduces the Manual.
Chapter 2
provides definitions and discusses key concepts and ontology used throughout the Manual.
Chapter 3
discusses the concept of
Information-based Needs and Requirements Definition and Management
(
I-NRDM
).
Chapter 4
discusses Lifecycle Concepts and Needs Definition activities.
Chapter 5
discusses Need Verification and Validation activities.
Chapter 6
discusses Design Input Requirements Definition activities.
Chapter 7
discusses Design Input Requirement Verification and Validation activities.
Chapter 8
discusses Design Verification and Design Validation activities.
Chapter 9
discusses Production Verification activities.
Chapter 10
discusses system verification and validation common principles.
Chapter 11
discusses System Verification and Validation activities.
Chapter 12
discusses the use of
Off-the-Shelf
(
OTS
) system elements.
Chapter 13
discusses design and system verification and design and system validation considerations when using supplier-developed system elements.
Chapter 14
discusses Needs, Requirements, Verification, and Validation Management activities.
Chapter 15
discusses the use of attributes.
Chapter 16
discusses the desirable features of an SE toolset.
Appendix A
lists references for sources of information in this Manual.
Appendix B
lists acronyms and abbreviations used in this Manual.
Appendix C
provides a glossary defining key terms used in this Manual.
Appendix D
provides a comment form and address to which comments on this Manual can be sent.
2DEFINITIONS AND CONCEPTS
The Needs, Requirements, Verification, and Validation (NRVV) concepts discussed in this Manual are better understood if based on consistent definitions of key terms and an understanding of basic concepts.
2.1 ONTOLOGY USED IN THIS MANUAL
Various authoritative sources provide a wide range of different views of NRVV, which often leads to confusion regarding the concepts themselves as well as the appropriate authoritative source. Consequently, a major challenge in developing this Manual was in the provision of an ontology, in particular the use of various terms and their relationships, especially with respect to the context of their usage.
To establish a framework for NRVV, this Manual presents a specific ontology. The reader is cautioned to be aware of the specific use of terms in context as they read this Manual and the associated INCOSE Requirement Working Group (RWG) guides, particularly if they are familiar with the concepts, processes, activities, and terminology referred to in the PMI® documents, Carnegie Mellon’s SEI CMMI®, the International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE) standards, INCOSE’s SE HB, or National Aeronautics and Space Administration (NASA) procedure requirements standards and handbooks, and other organizations’ standards associated with product and system development. Because of the differences in the use of terms in these various organizational standards, discussion of the differences and challenges is appropriate, so the following paragraphs provide examples of ontology challenges and how they are addressed in this Manual. (Section2.2and the Glossary provide definitions of key terms used in this Manual and its supporting Guides.)
2.1.1 Stakeholder Expectations, Needs, and Requirements
Various guides, textbooks, and standards refer to stakeholder “expectations, needs, and requirements,” “stakeholder needs,” or “user needs and requirements” as if they are the same, often combining them in a single document, such as a User Requirements Document (URD), Program [or Project] Requirements Document (PRD), Stakeholder Requirements Document (StRD), or Stakeholders Needs Document (StND)—communicating both the needs and requirements in the form of “shall” statements.
This can result in confusion as to the scope of each of the terms, in terms of what is an “expectation” versus what is a “need” as opposed to what is a “requirement.” All three terms can have different contractual meanings, and the resultant System of Interest (SOI) may not be what the customer expected if all three terms are not clarified and agreed-to. In addition, stakeholder expectations can be communicated in various forms, such as user stories, use cases, user scenarios, operational scenarios, Concepts of Operation (ConOps), Operational Concepts (OpsCon), or as textual statements.
For some practitioners, as described in ISO/IEC/IEEE 29148 [8], “stakeholder expectations” are communicated in terms of stakeholder needs and then transformed into stakeholder requirements. The purpose of both stakeholder needs and requirements is to represent a user-oriented view of the system as viewed externally: what stakeholders need from the system, what they need the system to do, how they plan to interact with the system, and what interactions the system has with its external environment.
To minimize confusion, this Manual refers to stakeholder needs, which is inclusive of stakeholder requirements.
Section 1.8 of the GtWR [5] provides a more detailed discussion concerning stakeholder expectations, stakeholder needs, and stakeholder requirements as opposed to system requirements.
2.1.2 Needs Versus Requirements
To avoid ambiguity in the use of the terms “needs” and “requirements,” this Manual follows the conventions for each described below.
2.1.2.1 Integrated Set of Needs The integrated set of needs represents the integrated and baselined set of needs that were transformed from the set of lifecycle concepts for the SOI. This concept is highlighted below and further discussed in Chapters 4 and 5.
To establish a complete understanding of what is needed from the SOI, maturation and analysis of the lifecycle concepts are undertaken, which is an input into defining a fully integrated set of needs at the project/system level (shown in Figure 2.1).
Stakeholder expectations, needs, and requirements are treated as inputs into this process, which can be in the form of stakeholder needs and requirements (or other forms of expression), the problem statement, the mission statement, goals, objectives, and measures (or some combination of those forms). These elements are established using the processes of Business or Mission Analysis and Stakeholder Needs and Requirements Definition as described in ISO/IEC/IEEE15288 and the INCOSE SE HB. Note that any customer-supplied system requirements are treated as higher-level requirements that are inputs into the lifecycle concepts analysis and maturation and needs definition activities.
The use of the word “integrated” with the “set of needs” is important. As shown in Figure 2.1, there are many possible inputs into the lifecycle concepts and needs definition activities. These inputs can be poorly communicated and may be inconsistent, incomplete, incorrect, or not feasible. As part of the lifecycle concepts analysis and maturation activities and the needs analysis activities, these issues are addressed such that the resulting integrated set of needs is consistent, complete, correct, and feasible. The integrated set of needs represents the scope of the project and is what the SOI design input requirements, design, and the SOI are validated against, as discussed in Chapters 7, 8, 10, and 11.
FIGURE 2.1 Lifecycle Concepts, Integrated Set of Needs, and Design Input Requirements.
The need statements for an SOI are written in a structured, natural language and have the characteristics defined in the GtWR for well-formed need statements and sets of needs. Because needs are not requirements, they do not contain the word “shall.” As discussed later in this Manual, a common error is to communicate the stakeholder, user, or customer needs as “shall” statements, adding confusion as to what are needs as opposed to what are requirements.
2.1.2.2 Design Input Requirements The design input requirements represent the technical design-to set of system requirements for the SOI. This concept is discussed in Chapters 6 and 7.
Design input requirements are established through a transformation from the baselined integrated set of needs as shown in Figure 2.1 and are inputs to the Architecture Definition and Design Definition processes of ISO/IEC/IEEE 15288. The design input requirements are written in a structured, natural language as textual “shall” statements that have the characteristics defined in the GtWR for well-formed requirement statements and sets of requirements. The set of design input requirements is the focus of both design verification discussed in Chapter 8 and system verification discussed in Chapters 10 and 11.
The term “structured, natural language” refers to the textual form of need and requirement statements such that the sentence is not treated as an atomic entity [11] but has a grammatical structure appropriate for communicating needs and requirements; for example, “When <condition clause>, the <subject clause> shall <action verb clause> <object clause> <optional qualifying clause>.” This allows specific templates and a set of rules to be defined, such as those in the INCOSE GtWR that will result in the needs and requirements having the characteristics of well-formed need statements and requirement statements.
FIGURE 2.2 Needs Versus Requirements—Different Perspectives.
2.1.2.3 Different Perspectives Communicated by Needs and Requirements As illustrated in Figure 2.2, the approach taken in the Guide to Needs and Requirements (GtNR), GtWR, and this Manual, which is consistent with ISO/IEC/IEEE 29148, is that the integrated set of needs communicates the stakeholder’s perspective concerning their expectations of what they need the SOI to do, while the design input requirements communicate the customer/developer perspective concerning what the SOI must do to meet the set of needs.
2.1.3 Stakeholder Requirements Versus System Requirements in the Context of System Verification and System Validation
Use of the term “stakeholder requirements” to reflect needs defined at the operational level may lead to confusion with the SOI requirements, which are defined at the system, subsystem, and system element levels (refer to Section 2.3 for a detailed discussion on organizational levels). It can be confusing if the word “requirement” is used in both the context of system verification (meeting the system requirements) and system validation (meeting the operational-level stakeholder requirements), which is advocated in ISO/IEC/IEEE 15288 and the INCOSE SE HB. To avoid confusion, rather than defining system validation with respect to meeting stakeholder requirements, the following definitions are used in this Manual:
System verification
addresses whether the SOI meets its design input requirements.
System validation
addresses whether the SOI can do what is intended when operated in the operational environment when used by the intended users, does not enable unintended users to negatively impact the intended use of the system, or use the system in an unintended way,
as defined by the integrated set of needs
.
In this context, the operational-level stakeholder needs, along with any customer-supplied system requirements, are integrated with other sets of stakeholder needs that were obtained during elicitation activities. These are identified as drivers for the SOI and are addressed during the activities associated with SOI lifecycle concepts analysis and maturation and the definition of the integrated set of needs.
Note that the integrated set of needs will include references (via traceability) to the operational-level stakeholder needs and requirements as appropriate. Similarly, the resultant set of design input requirements will contain child requirements that trace to the applicable higher-level allocated stakeholder requirements and customer-supplied system requirements, as well as trace to the set of needs or other sources from which they had been transformed.
2.1.4 Requirements Versus Specifications and Documents Versus Specifications
Other sources of confusion are the use of “document” versus “specification” and the use of “requirements” versus “specifications.” These terms are often used interchangeably: requirement document or requirement specification, for example, System Requirements Document (SRD), Software Requirements Specification (SRS), or Software Requirements Document (SRD). In this context, the words “document” and “specification” when used in their singular form, represent containers of design input requirements. However, the terms document, specification, and requirements represent different concepts, which are described further below.
2.1.4.1 Design Inputs Versus Outputs A distinction is made between the terms for requirements and specifications, where requirements refer to inputs into the design process and specifications refer to design outputs as part of the design definition process. It is also common practice to refer to documentation concerning as-built system characteristics as specifications.
FIGURE 2.3 NRVV Activity Relationships to the INCOSE SE HB.
As shown in Figure 2.3, the integrated set of needs and resulting set of design input requirements are considered inputs into the Architecture Definition and Design Definition processes of ISO/IEC/IEEE 15288, which transform the design input requirements into sets of design output specifications (outputs of the architecture and design definition processes activities) to which the system element is realized.
The use of design input requirements is appropriate in that they are inputs to the architecture and design definition processes as opposed to outputs of these processes.
The INCOSE SE HB [1] refers to outputs of the design definition process in terms of design definition records, artifacts, reports, strategy/approach as well as system design characteristics and design descriptions. NASA’s SE HB refers to design outputs as “design descriptions.” Design outputs are also often referred to as end-item specifications or the Technical Data Package (TDP), which include parts lists [Bill of Materials (BOM)], drawings, wiring diagrams, plumbing diagrams, labeling diagrams, requirements, logic diagrams, algorithms, computer-aided design (CAD
