Follow Us:

Requirements Engineering

Definition: A requirement is a singular documented need—what a particular product or service should be or how it should perform. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user. Requirements engineering is the discipline concerned with establishing and managing requirements. It consists of requirements elicitation, analysis, specification, verification, and management.

Keywords: analysis, definition, development, elicitation, management, requirements, systems engineering, verification

Context

Requirements are derived from operational needs and concepts and are used as inputs to design and development. Requirements are also an important input to verification, since tests must trace back to specific requirements to determine if the system performs as intended. Requirements indicate what elements and functions are necessary for the particular project. The typical phases of requirements development are eliciting, collecting and developing, analyzing and defining, and communicating and managing requirements. Because of the rapid changes in operational requirements and the pace of technology, increasingly systems engineers are faced with unprecedented levels of uncertainty in developing requirements.

MITRE SE Roles & Expectations: MITRE systems engineers (SEs) are expected to be able to integrate business, mission, and operational needs and transform these needs into system requirements. They elicit, develop, analyze, communicate, and manage requirements as well as facilitate stakeholder engagement and agreement on system requirements. They are expected to be able to decompose operational needs and requirements and flow them down to operational capabilities, technical requirements, technical implementation, and verification of the requirements. MITRE SEs are expected to ensure operational value and traceability from the operational need all the way to the system verification and ultimately to the fielding and sustainment of the system. They are expected to actively mitigate uncertainty in requirements through prototyping and experimentation activities.

Discussion

The articles in this topic address the major phases of requirements engineering.

Requirements engineering starts early in concept development by eliciting and collecting operational needs from the relevant user community, and developing requirements from the needs. It involves more than talking to the user or reading their concept of operations, and asking them to review the requirements you created. It is a disciplined approach that includes collecting, validating, prioritizing, and documenting requirements. The article Eliciting, Collecting, and Developing Requirements describes a disciplined approach that can be used for different types of strategies, from classic large-scale Department of Defense block acquisitions to agile incremental acquisitions.

Towards the end of the eliciting and collecting phase, systems engineers analyze the requirements to ensure they are sound and can form a stable basis for the duration of the planned development and testing period. The article Analyzing and Defining Requirements describes attributes of a well-crafted requirement to minimize design mis-steps, confusion, and re-work downstream. It also references tools that exist within MITRE to support and manage this phase of the requirements engineering effort.

Despite best efforts, sometimes the requirements management techniques described in the previously mentioned articles are insufficient. This occurs most often when the user is unsure of their needs or leading-edge technology is needed to meet requirements. In this environment, key tools in the MITRE systems engineer toolbox are prototyping and experimentation. These are particularly useful for gauging whether a requirement is achievable or assessing feasibility and maturity of a technology to meet a requirement. The article Special Considerations for Conditions of Uncertainty: Prototyping and Experimentation discusses when and how these tools should be applied, the different approaches, "weight" or fidelity available (and which level makes sense for what situations), and ideas for how to evolve the prototyping and experimentation efforts over time to reduce the risk of requirements uncertainty.

References & Resources:

• International Council on Systems Engineering (INCOSE) website.
• Kossiakoff and Sweet, 2003, Systems Engineering: Principles and Practice, Wiley.
• Stevens, et al., 1998, Systems Engineering: Coping with Complexity, Prentice Hall.
• Sutcliffe, A., 1996, "A Conceptual Framework for Requirements Engineering," Requirements Engineering Journal, Volume 1, Number 3, Springer London.
• "Systems Engineering," Wikipedia, viewed March 11, 2010.
• The MITRE Institute, "Requirements Engineering," Systems Engineering Competency Model, section 2.2, viewed February 4, 2010.
• U.S. Department of Homeland Security, Requirements Engineering, viewed March 11, 2010.