Difference between revisions of "Requirement (glossary)"

From SEBoK
Jump to: navigation, search
(Created page with '''<blockquote>A comprehensive, integrated plan that identifies the acquisition approach and describes the business, technical, and support strategies that management will follow ...')
 
m (Text replacement - "<center>'''SEBoK v. 2.3, released 30 October 2020'''</center>" to "<center>'''SEBoK v. 2.4, released 19 May 2021'''</center>")
 
(27 intermediate revisions by 9 users not shown)
Line 1: Line 1:
''<blockquote>A comprehensive, integrated plan that identifies the acquisition approach and describes the business, technical, and support strategies that management will follow to manage program risks and meet program objectives. The Acquisition Strategy should define the relationship between the acquisition phases and work efforts, and key program events such as decision points, reviews, contract awards, test activities, production lot/delivery quantities, and operational deployment objectives. (DAU February 19, 2010)</blockquote>''
+
''<blockquote>Statement that identifies a product* or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability.'' (ISO/IEC 2007)</blockquote>
  
====Source====
+
<blockquote>*includes product, service, or enterprise.</blockquote>
DAU. February 19, 2010. ''Defense Acquisition Guidebook (DAG)''. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).  
+
 
 +
===Source===
 +
ISO/IEC. 2007. ''Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-Intensive Systems''. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2007.  
  
 
===Discussion===
 
===Discussion===
Discussion as to why this is the "consensus" definition for the SEBoK.
+
A requirement is “a statement that identifies a system, product or process characteristic or constraint, which is unambiguous, clear, unique, consistent, stand‐alone (not grouped), and verifiable, and is deemed necessary for stakeholder acceptability.” (INCOSE 2010)
 +
 
 +
INCOSE. 2010. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1: 362.
  
 
[[Category:Glossary of Terms]]
 
[[Category:Glossary of Terms]]
 +
 +
<center>'''SEBoK v. 2.4, released 19 May 2021'''</center>

Latest revision as of 19:47, 18 May 2021

Statement that identifies a product* or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability. (ISO/IEC 2007)

*includes product, service, or enterprise.

Source

ISO/IEC. 2007. Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-Intensive Systems. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2007.

Discussion

A requirement is “a statement that identifies a system, product or process characteristic or constraint, which is unambiguous, clear, unique, consistent, stand‐alone (not grouped), and verifiable, and is deemed necessary for stakeholder acceptability.” (INCOSE 2010)

INCOSE. 2010. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1: 362.

SEBoK v. 2.4, released 19 May 2021