Premium
Implementing Structured Requirements to Improve Requirements Quality
Author(s) -
Carson Ronald S.
Publication year - 2015
Publication title -
incose international symposium
Language(s) - English
Resource type - Journals
ISSN - 2334-5837
DOI - 10.1002/j.2334-5837.2015.00048.x
Subject(s) - requirements engineering , computer science , requirements management , requirements analysis , non functional requirement , quality (philosophy) , requirements elicitation , set (abstract data type) , software engineering , verifiable secret sharing , grammar , systems engineering , risk analysis (engineering) , reliability engineering , software , engineering , programming language , software system , software construction , philosophy , linguistics , epistemology , medicine
The Boeing Company has implemented a standard approach to the engineering of high‐quality requirements using the concept of “structured, natural language”, a specific grammar for how to write requirements. This approach helps our requirements engineers write more unambiguous and verifiable requirements as required by ISO/IEC/IEEE 29148:2011 and related commercial and military standards. Boeing has identified four types of specification requirements, plus a verification requirement type. Each type of requirement has a standard grammar, a set of mandatory and optional elements that ensure verifiability related to the type. This approach is implied by recent guidance from the International Council on Systems Engineering (INCOSE), and by recommendations of other industry practitioners. In combination with these standards for writing requirements we have also integrated a scoring method for evaluating how well any requirement satisfies the standard criteria. This approach provides immediate feedback to the requirement writer regarding the absence of critical information or deficiencies in the information provided, e.g., unobservable functions, or ambiguous performance criteria or conditions. In contrast with other industry methods we score elements of the requirement individually on a graded (rather than binary) scale. We are thus able to not only score for the presence or absence of a required element, but are able to identify degrees of compliance with the Boeing standard. This enables us to quantify the risk of less‐than‐perfect requirements.