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 & 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 systems 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 systems 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.


Frequently MITRE 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 comprising the system-level technical requirements are one of the most important products that MITRE can develop for the customer. Often, the system-level technical requirements are used in a government activity with the objective of acquiring 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 by the product vendors as their 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 that are 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 Requirements Engineering in the Guide) 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.


Ideally system-level technical requirements are developed after user requirements are defined. When 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 requirements that exist. In most government departments and agencies, system requirements are needed before development, manufacture, or construction. Once established, the system requirements exist and evolve for the life of the system. 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 get 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 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 to this day. They 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 [4]. Many projects today use electronic software tools to capture and manage requirements and other information. MITRE SEs are expected to understand the various types of tools and media, and their advantages and disadvantages, when capturing system requirements in different situations. 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 systems 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).

There are two cautions when working with user requirement documents. First, the needs are frequently expressed in user operational lingo that may not be meaningful to engineers. An even more insidious problem is that while the language may be meaningful to both operators and engineers, it may also convey different interpretations, resulting in a lack of clarity about intent by the operators and the engineers. Systems engineers need to explicitly account for and resolve this language divide and may have to translate operational terminology into engineering requirements. Second, 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 systems engineer to do substantial work to achieve a set of requirements that are testable and can be built with reasonable technological risk.

In the requirement example above, there appears to be a straightforward performance requirement of 100 miles, but to a radar engineer it begs the question of "detect what?" and "how well?" There are both physics-related and technological challenges with detecting objects that are small and far away. Even for large objects, it is impossible to guarantee detection 100 percent of the time. 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 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.

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

System-Level Requirements Checklist

Checklist Item


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. There are few requirements that 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 (non-operating 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 utilize a transport mechanism that is not part of the system is a hidden external interface. For example, two subsystems that communicate internally with each other over a sensitive but unclassified network as the internal interface (the data exchanged between them) and an external interface (the wiring and internet protocols to enable the data exchanges with the 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.

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.


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.
    • Avoid qualitative words like "maximize" or "minimize." 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.
    • 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 for verifying them.
  • Avoid 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.
    • Example: The system shall process a minimum of 100 transactions/sec.
    • Example: The system shall be operable up to and including 30,000 ft.
    • Example: The system shall operate in temperatures between 5 and 35 degrees Celsius.


If objective performance values are included as goals, ensure 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.

Example: The system shall be maintainable by an Air Force level 5 technician.

Example: 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.

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 that there is no 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.


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, databases, or word processors 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.

Refer to the SE Guide article Assess the Design's Ability to Meet the System Requirements for related information.

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 enough detail so that there is sufficient information to implement the right system, yet not too much detail to restrict designers unnecessarily. One can think of 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, one 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 too high of a level of detail, 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.

Too low of a level of detail 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 to be included in the final product. As a design concept is explored, people on the customer/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 commonly purchased media such as compact disks.

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 the users and 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. Often, there are many stakeholder organizations and individuals with 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. Coworkers and the sponsor have opinions based on their experience and perceptions. Sometimes political implications (real or assumed) exist when a requirement challenge is initiated by a sponsor senior leader or end user. 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.

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

  • 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 have a concern 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 include as a requirement.
    • Any Party: They 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 their position has merit, technical or otherwise.

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

References & Resources

  1. The MITRE Institute, September 1, 2007, MITRE Systems Engineering (SE) Competency Model, Version 1, section 2.2, "Requirements Engineering."
  2. Department of Defense, December 8, 2008, DoD Instruction 5000.02.
  3. Chairman of the Joint Chiefs of Staff, March 1, 2009, Joint Capabilities Integration And Development System (CJCSI 3170.01G).
  4. Stevens, R., P. Book, K. Jackson, and S. Arnold, 1998, System Engineering: Coping with Complexity, Prentice Hall.
  5. Blanchard, B. and W. Fabrycky, 1998, Systems Engineering and Analysis, Prentice Hall.
  6. International Council on Systems Engineering (INCOSE), January 2010, INCOSE Systems Engineering Handbook, Version 3.2, INCOSE-TP-2003-002-03.2.
  7. International Council on Systems Engineering (INCOSE), INCOSE Systems Engineering Handbook.

Additional References & Resources

Navy PEO Integrated Warfare Systems, October 27, 2008, Surface Navy Combat Systems Development Strategy Acquisition Management Plan (AMP).


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team