Develop System-Level Technical Requirements


Definition: System-level technical requirements is a general term used to describe the set of statements that identifies a system's functions, characteristics, or constraints.

Keywords: acquisition development program, requirement, specification

MITRE SE Roles and Expectations: The MITRE systems engineer (SE) is expected to have a sound understanding of what a system requirement is intended to convey, what constitutes a good system requirement, how to identify a poorly written requirements statement, and what constitutes a good set of system requirements. MITRE SEs are expected to be able to transform business/mission and operational needs into system requirements, including [1]:

  • Exploring and recommending creative ways to elicit, analyze, and document user requirements.
  • Transforming and integrating business/mission and operational needs into system requirements, including unstated or implied needs.
  • Promoting shared understanding and facilitating stakeholder agreement about system requirements.
  • Integrating new requirements generated by prototypes into the system requirements.
  • Analyzing the interrelationships, priorities, cost, implementation, and environmental implications of system requirements.
  • Defining system boundaries, including how the system interacts with both inputs from and outputs to users, equipment, or other systems.

Background

MITRE often plays a central role in developing system-level technical requirements, interpreting them, and assessing designs against them. Developing the right system requires the right information to communicate what the system is intended to do and what conditions or constraints its design must accommodate.

Collectively the descriptions and constraints that make up the system-level technical requirements are one of the most important products that MITRE can develop for the sponsor. The system-level technical requirements are often used in a government activity in order to acquire a capability, system, or product to meet a user need. They are used as part of a procurement contract solicitation or prototyping/experimentation effort and as product vendors' design criteria. System-level technical requirements describe the users' needs and provide information for the finished system to meet legal restrictions, adhere to regulations, and interoperate or integrate effectively with other systems. The decisions made when defining system-level technical requirements can affect the number of potential solutions, the technical maturity of the potential solutions, system cost, system evolution, and development time and phasing. Requirements definition (see the SEG's Requirements Engineering) confers an obligation and an opportunity for MITRE to influence the system development in ways that improve the ability of systems to interoperate with other systems. Poor requirements often result in solutions that are at high risk of failing to meet the user need, cost, schedule, and ability to interoperate.

Application

Ideally, system-level technical requirements are developed after user requirements are defined. When this is not the case, a preliminary version of the system requirements may be drafted for developing a prototype or experimentation system to confirm, clarify, or discover user requirements. Prototypes or experimentation systems are also instrumental in validating that key technologies needed to meet the requirements are sufficiently mature and can meet the existing requirements. In most government departments and agencies, system requirements are needed before development, manufacture, or construction because they were provided to industry in a request for proposal against which bidders propose their solution. Once established, the system requirements exist and evolve for the life of the system. They may be used as references to re-procure replacement components as systems age and parts become no longer available over the system's lifespan. They may be, and frequently are, updated as the user defines new needs or when the environment in which the system operates changes [2, 3]. In evolutionary or incremental acquisitions, the system requirements generally are defined in greater detail as the increment in which they are implemented draws near.

Many projects capture their system requirements using formal "shall" requirement statements in a system specification document. Use of the term "shall" in acquisition programs has contractual implications and drives a mandatory implementation by the developer of a capability to meet the "shall." Selective use of "shalls" can be beneficial in situations in which needs are likely to evolve over time. Exhaustive and excessive use of "shall" statements can be constricting and costly. A term such as "should" can be used to both show government preference and allow some freedom in design and management/negotiation (e.g., time-driven, capability-driven, cost-driven) of system requirements intended to meet user needs over time.

The term "document" (or "documented") has a long history in referring to requirements and is commonly used today. The terms should not be construed generally to mean that the information exists in paper form or is even organized as a paper substitute, such as a word-processed document. Many projects today use electronic software tools to capture and manage requirements and other information. When capturing system requirements in different situations, MITRE SEs are expected to understand the various types of tools and media as well as their advantages and disadvantages. Some projects, especially those involving software-intensive systems, use modeling tools or languages to describe major system elements, required behaviors, and interfaces. Examples include Unified Modeling Language (UML) and System Modeling Language (SysML).

Development of System-Level Requirements

When developing system requirements, a good rule of thumb is to provide designers and test engineers with what they must know, but leave as much "white space" as possible for clever designers to explore design options (many times through prototypes of different forms or experiments).

An obvious place to start developing system requirements is with the user requirements—high-level expressions of user needs that the system is expected to satisfy. Examples of Department of Defense (DoD) user requirement sources include the initial capabilities document (ICD), the capability development document (CDD), and the capability production document (CPD) [3, 4].

When working with user requirement documents, consider these two cautions:

  1. The needs are frequently expressed in user operational lingo that may not be meaningful to engineers. A more insidious problem is that even when the language may be meaningful to both operators and engineers, it may also convey different interpretations to each of them, resulting in a lack of clarity about intent. Systems engineers need to explicitly account for and resolve this language divide and may have to translate operational terminology into engineering requirements.
  2. User requirements often are not expressed in ways that unambiguously cover acceptance or test criteria. What appears to be a clear user requirement (e.g., "detect airborne objects out to a range of 100 miles") often requires the SE to do substantial work to achieve a set of requirements that is testable and can be built with reasonable technological risk. The performance requirement of 100 miles appears to be straightforward, but a radar engineer may ask: "detect what?" and "how well?" Detecting objects that are small and far away involves physics-related and technological challenges. Even for large objects, detection 100 percent of the time is impossible to guarantee. To write an effective system requirement for a designer to implement a solution, an SE would have to derive additional requirements and/or verification criteria to define how small an object must be to be detected and what the acceptable likelihood is that a given object within range will be detected. Similarly, in a Maglev train development, the user's need to transit a great distance in a short time will eventually establish requirements for train speed parameters. The need to transport passengers will form the basis for safety requirements and maximum noise tolerances.

In the vast majority of cases, the MITRE SE will benefit from working with the end users to create a mutual understanding of their needs and the capabilities and technology available and feasible to support them.

System requirements should be tracked or traced to the user requirements. Tracing a requirement means to cross-reference the source (in this case, user) requirement on which a system-level requirement is based, and also to reverse-reference which system requirement(s) implement the source requirements. Tracing user to system-level requirements helps ensure that all requirements have some user basis and that all user requirements are included in the system requirements for development. It is advisable to place the assumptions, constraints, and analyses associated with any derived requirements into a decision and/or requirements database as well.

It is possible to manually manage user to system-level requirement cross-references. Many projects use spreadsheets or databases to manage requirement information. However, it is recommended that a project adopt a commercial requirements tool to aid in the process. Specialized database tools, such as DOORS (by IBM Rational), can be used to capture text requirements statements, diagrams, verification requirements, and other electronic files.

Consider using the following checklist when developing a set of system-level requirements [5, 6, 7].

System-Level Requirements Checklist

Checklist Item

check

The system-level technical requirements are traceable to the user requirements.

 

Each system requirement describes something relevant: a function the system must perform, performance a function must provide, a constraint on the design, or a reference such as to an interface definition.

 

The level of detail that the requirements provide about system functionality is appropriate.

The requirements are sufficient to describe what the overall system must do, what its performance must be, and what constraints an engineer should consider. Few requirements specifically affect the design of only one component of the system. The major requirements drivers (e.g., those stressing the design) and associated risks should be identified.

 

The requirements include any legal or regulatory constraints within which the system must perform.

Example: There may be restrictions on the use or quantity of certain hazardous materials in a system.

 

The requirements include enterprise architecture constraints within which the system must integrate (or toward which the system is desired to migrate).

Requirements include appropriate open systems and modularity standards.

Examples:

  • DoD Net-Ready requirements
  • Modular open system architecture concepts
  • Electronic Systems Center strategic technical plan goals

 

Environmental design requirements are specified.

More than one environment may need to be specified to account for active operational use, storage (nonoperating condition), or subsystems that may be in differing usage locations.

Example: A control unit may be in a controlled office environment and the other major components may be outdoors. Thus two environments must be defined and associated with the functionality operating in each environment.

 

All external interfaces for the system are included. Major internal interfaces may also be included if they are important to system modularity or future growth in capability.

These may include physical (mechanical fastening, electrical wiring, connectors), functional (mechanical stress transfer points, cooling, power sources, antennas, wire message formats, data exchanges), and software (software interface specifications, library calls, data formats, etc.).

Remember that an internal interface between two subsystems that use a transport mechanism that is not part of the system is a hidden external interface.

Example: Two subsystems that communicate internally with each other over an external communications network have both an internal interface (the data exchanged between them) and an external interface (the wiring and internet or other protocols to enable the data exchanges over the external network).

 

Requirement statements use the word "shall" or "should."

The word "shall" has meaning in contractual language and is enforceable legally. Other words like "will," "may," "should," and "must" may show intent but are not legally binding in contracts. In some situations, it may be desirable to use "should" to show the government's intent and preference while at the same time allowing flexibility and latitude. Avoid the phrase "shall not." It is very difficult to prove a negative statement.

Example: "The system shall have a mean time between failures of greater than 500 hours."

 

Requirements statements are unambiguous

Terminology is clear without the use of informal jargon. Statements are short and concise so the requirements are uniquely testable and verifiable.

 

Performance requirements statements (including logistics/sustainment/support) are quantifiable, testable, and/or verifiable.

Avoid:

  • The phrase "shall not." It is very difficult to prove a negative.
  • Qualitative and subjective words like "maximize, "minimize," "normal," "readily accessible," "upgradable," "cost effective," and "safe." They force an engineer to judge when the design is good enough. The user may think that the engineer did not "minimize enough" and get into a legal argument with the contractor.
  • Ambiguous adverbs and adjectives such as "significant," "timely," "precise," "integrated," "approximately," "many," "few," and "limited."
  • Comparative phrases such as "better than" and "higher quality."
  • Specific, one-point values when defining requirements. Use ranges (minimum of, more than, less than, maximum of, within, etc.) to accommodate appropriate interpretation. Using a single point value may cause arguments if the system is tested at that exact value only, or if a test appears to be successful from an intent perspective but does not meet the exact value stated in the system requirement.

Note: Every user requirements document includes: "the system shall be easy to use" requirement. Talk to other MITRE staff for examples from other projects and seek out a human factors specialist for requirements wording that is suitable both for specifying these requirements and methodologies and for verifying them.

Examples:

  • The system shall process a minimum of 100 transactions/sec.
  • The system shall operate in temperatures between 5 and 35 degrees Celsius.

 

If objective performance values are included as goals, they are clearly identified and distinguished from firm requirements.

User requirement documents refer to threshold requirements (those that must be provided) and objective requirements (better performance has value to the user but not above the objective requirement).

Example: The system shall detect and display up to 100 targets within the surveillance volume with a goal of detecting and displaying up to 125 targets.

 

The operational and support environment is described and defined.

Examples:

  • The system shall be maintainable by an Air Force level 5 technician.
  • The system shall be reparable while in flight.

 

The requirements include appropriate use of government and industry specifications, standards, and guides.

Only include them if they are relevant and ensure that the correct version is listed in a list of reference documents.

 

Verification approaches for all system performance and sustainability requirements are complete and appropriate.

The verification methods must be defined.

Every requirement must have a verification method identified.

If a requirement cannot easily be verified by a direct inspection, measurement, or one-time demonstration of the requirement, the verification requirement should include an expanded test criteria description to ensure against disagreement later in the program. This can include describing the number of trials, statistical criteria to be used, conditions of the test such as simulated inputs, etc.

Upgrade efforts may add a few unique, new requirements. For cost reasons, there may be a desire to limit verification testing to that new functionality. Often, adding new features affects the specific tested configuration of components that implement unchanged functionality. In these cases, it is recommended to define regression verifications that successfully must be passed to ensure that the functionality that should not be affected still functions.

 

References to requirements in other documents such as a standard must uniquely identify the document and version (revision identification, date, etc.). Standards may be updated over time. Not including a full description of the reference document may introduce ambiguity as to which version the systems engineer intended.

 

For related information, see the SEG article Assess the Design's Ability to Meet the System Requirements.

Best Practices and Lessons Learned

The devil's in the (right level of) details. The primary challenge associated with developing system-level requirements is to provide sufficiently detailed information to implement the right system, yet not too much detail to restrict designers unnecessarily. Consider a car analogy. If you were specifying requirements for a public transportation vehicle, you might specify the number of passengers, speed the vehicle must be capable of, and distance that must be covered. If it were intended to be a concept like an automobile, you would add requirements associated with single-user operation and with the regulations that affect automobile design to allow it to operate on public roadways.

With a level of detail that is too general, the designer has insufficient information to provide a system that will meet the user need, and the designer will have to guess what was intended. In the automobile example, failing to include a requirement for a minimum amount of cargo space could result in a design with insufficient cargo space, yet the system would be compliant with the requirements. Do not assume that another person's view of a logical, detailed design choice will match yours.

A level of detail that is too specific can artificially constrain the design. Additional requirements may prevent a designer from making choices that can provide innovative solutions. This problem is often encountered because people have a natural tendency to want something they have seen and would like it to be included in the final product. As a design concept is explored, people on the sponsor side discover design details and then try to ensure that the particular feature of interest is included in the requirements. In the car example, such a person might try to specify a particular high-end sound system with custom interfaces for their favorite player when all that is required is compatibility with standardized media interfaces such as USB ports.

System cost is likely to increase from adding too many low-level requirements to the system specification. Every system requirement provided to a contractor has a cost, even if they had already planned to include it in their design. Every requirement must be documented, allocated to design specifications, tracked, and formally tested. Contractors will bid that work. In addition, the detail requirements become a permanent part of the top-level system requirements for all future upgrades until it is explicitly changed.

Close communications with users and the use of prototypes, experiments, etc. are mechanisms to ensure a collective understanding of what is needed and to manage level-of-details requirements issues.

Stakeholders agreement. Because system-level technical requirements are central to the definition of what is to be procured and have significant effects on program acquisition risk, cost, and schedule, reaching agreement on system requirements is challenging but critical. Many stakeholder organizations and individuals often have differing opinions. Contractors may argue to mitigate their risk or slant a requirement in their favor. Users may try to guide design or get additional capability. Co-workers and the sponsor have opinions based on their experience and perceptions. Sometimes political implications (real or assumed) exist when a sponsor senior leader or end user initiates a requirement challenge. If you are an engineer defining system technical requirements, you will eventually encounter arguments about:

  • What a requirement statement or a specific word within a requirement statement means
  • Whether a requirement should be included or excluded
  • Whether a requirement is specifying too much or too little performance
  • Whether a requirement directs design and should be removed
  • Whether a requirement should be added to guide design and ensure that a specific feature is provided.

To resolve requirement arguments, it is often helpful to understand the source of the objection to your system requirement. The source of someone's argument often comes from one of the following situations:

  • They have experience and are really trying to help.
    • They might not always be right, but they believe they are helping build a better set of requirements.
    • You may have to do more research or make a judgment as whether their position has merit.
  • They are concerned about how someone else may interpret the requirement.
    • Contractors: They are afraid of how their words could be interpreted by others. Losing an argument about an interpretation of a requirement late in the program is highly undesirable to the contractor because of the higher cost and schedule impact due to late design changes.
    • Program office person or user representative: They are afraid the requirement will not force the contractor to provide a specific design feature that they want included in the system.
  • They want the program to adopt a competing technical approach.
    • Contractors: They want to slant the acquisition toward their specific solution to get the contract award or allow them to meet the requirement with a solution they have already identified.
    • Any party: They may have a valid technical solution or they may want to have the project adopt their requirement over yours to demonstrate their contribution.
  • They insist on a specific detail or feature the system must have, and they want specific words to be included as a requirement. Any party can fear that if you don't specify the requirement explicitly, they will not get it.
  • Resolving any of these issues requires a mixture of negotiation ability, technical expertise, and an ability to understand the root cause of the other person's concern. Choosing clear requirements language is a good starting point. Being consistent with specification wording and using terminology similar to that employed in past projects with the contractor can also help. Understanding and experiencing the operational environment will give the MITRE SE additional knowledge on which to judge the requirements. In other cases, the SE will have to explore the other person's objections and determine whether that position has merit, technical or otherwise.

    For related information, see the SEG topics Requirements Engineering and System Architecture.

    References and Resources

  1. The MITRE Institute, September 1, 2007, MITRE Systems Engineering (SE) Competency Model, Ver.1, Sect. 2.2, "Requirements Engineering."
  2. MIL-HDBK-520A, System Requirements Document Guidance, December 19, 2011.
  3. Department of Defense, January 7, 2015, DoD Instruction 5000.02, Operation of the Defense Acquisition System.
  4. Chairman of the Joint Chiefs of Staff, January 23, 2015

Publications

Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Questions?
Contact the SEG Team