Analyzing and Defining Requirements
Definition: The engineering analysis that ties the needs of users and other stakeholders to the system to be built in a quantifiable and traceable manner.
Keywords: analyze, develop, development methods, measures of effectiveness, measures of performance, performance engineering, requirements
MITRE SE Roles & Expectations: MITRE systems engineers (SEs) are expected to be able to analyze systems requirements to determine if they can be tested, verified, and/or validated, and are unique, complete, unambiguous, consistent, and obtainable, and to trace all requirements to original business and mission needs. They are expected to review requirements to determine conformance with government policy for developing the system and identify potential integration and interoperability challenges.
How can we judge if a system meets the needs of a user community? One way is to look at the system requirements and compare those statements to how the system was built, installed, and operated. For large enterprise systems, traditionally there has been a substantial lag between requirements definition and field operation of a system. This often affects both the effectiveness of a system and how the system is perceived, e.g., the system is stale and outdated: it does not meet my needs. In part, this lag is addressed by spiral or incremental approaches to enterprise capability development (see the article on Eliciting, Collecting, and Developing Requirements). The implication for requirements is that they should be defined in detail in time to support the increment or spiral in which they will be developed. This mitigates the problem of locking down a requirement so early that it contributes to the perception of staleness when it is finally delivered. Additionally, when allocating requirements to an increment or spiral, they should be stable enough over the increment's planned development and testing period that the capability can still be expected to meet the user needs when delivered. Beyond that, requirements analysis during concept development must be efficient, accurate, rational, and traceable.
Characteristics of Good Requirements
MITRE systems engineers encounter many types of projects and systems—from research and development, to technical consulting work, to acquisition. Whatever the context, a good requirements statement typically has the following characteristics :
- Traceable: A requirement must be traceable to some source such as a system-level requirement, which in turn needs to be traced back to an operational need and be attributable to an authoritative source, whether a person or document. Each requirement should have a unique identifier allowing the software design, code, and test procedures to be precisely traced back to the requirement.
- Unambiguous: Test the wording of the requirement from different stakeholders' perspectives to see if it can be interpreted in multiple ways.
- Specific and singular: Needed system attributes (e.g., peak load) are described clearly as atomic, singular thoughts.
- Measurable: System functions can be assessed quantitatively or qualitatively.
- Performance specified: Statements of real-world performance factors are associated with a requirement.
- Testable: All requirements must be testable to demonstrate that the end product satisfies the requirements. To be testable, requirements must be specific, unambiguous, and quantitative whenever possible. Vague, general statements are to be avoided.
- Consistent: Requirements must be consistent with each other; no requirement should conflict with any other requirement. Check requirements by examining all requirements in relation to each other for consistency and compatibility.
- Feasible: It must be feasible to develop software that will fulfill each software requirement. Requirements that have questionable feasibility should be analyzed during requirements analysis to prove their feasibility. If they cannot be implemented, they should be eliminated.
- Uniquely identified: Each need is stated exactly once to avoid confusion or duplicative work. Uniquely identifying each requirement is essential if requirements are to be traceable and able to be tested. Uniqueness also helps in stating requirements in a clear and consistent fashion.
- Design-free: Requirements should be specified at the requirements level and not at the design level. Describe the requirement functionally from a requirement point of view, not from a design point of view, i.e., describe the functions that the system must satisfy. A requirement reflects "what" the system shall accomplish, while the design reflects "how" the requirement is implemented.
- Using "shall" and related words: In specifications, using the word "shall" indicates a binding provision, i.e., one that must be implemented by the specification users. To state non-binding provisions, use "should" or "may." Use "will" to express a declaration of purpose (e.g., "The government will furnish...") or to express future tense.
Each of these characteristics contributes to the integrity and quality of the requirements and the system or capability to be developed. Enforcing these characteristics during the requirements activity helps keep the entire development effort organized and reproducible, and avoids issues later in the life cycle. The goal of a requirements process is to define a system or capability that ties the needs of the users and other stakeholders to the system to be built so that it satisfies the needs within a specified schedule and cost, and possesses the required performance characteristics—including characteristics like information assurance, quality, reliability, internationally enabled, and sustainability. Observing the above requirements characteristics will help to maintain engineering rigor, content, and value of the engineering analysis.
Measures Associated with Requirements Analysis 
The typical categories of measures associated with determining if a system complies with the requirements include:
- Measures of Effectiveness (MOEs) are measures of mission success stated under specific environmental and operating conditions, from the users' viewpoint. They relate to the overall operational success criteria, e.g., mission performance, safety, availability, security, etc.
- Measures of Performance (MOPs) characterize specific physical or functional characteristics of the system's operation, measured under specified conditions. They differ from MOEs in that they are used to determine whether the system meets performance requirements necessary to satisfy the MOE.
- Key Performance Parameters (KPPs) are a stakeholder-defined measure that indicates a minimal and critical system performance and level of acceptance.
Best Practices and Lessons Learned
- Baseline and agree. Developing requirements is usually a collaborative activity, involving users, developers, maintainers, integrators, etc., so avoid placing the responsibility of requirements analysis solely on one stakeholder. When all team members acknowledge a set of requirements is done, this is called a baseline (realizing that this will evolve—see bullet below on "Be flexible").
- Requirements analysis is an iterative process, so plan accordingly. At each step, the results must be compared for traceability and consistency with users' requirements, and then verified with users, or go back into the process for further analysis, before being used to drive architecture and design.
- Pay special attention to interface requirements. Requirements must clearly capture all the interactions with external systems and the external environment so that boundaries are clear. Remember that external interfaces can be influenced by the architecture of a system or subsystems. In some cases, hidden external interfaces will be established because internal subsystem-to-subsystem communications use an external medium (e.g., radios connect subsystems via airwaves) or other assets that are not part of the system (e.g., satellite relay, external network). Examples of tools for recognizing external interfaces include the DoD Architecture Framework (DoDAF) operational and system views referred to as OV-1, OV-2, and SV-1 diagrams.
- Be flexible. To balance out rigidness of baselining requirements, a development team should consider what constitutes a "change of requirements" as distinguished from a valid interpretation of requirements. The key is to find a balance between adherence to a baseline and sufficient flexibility (e.g., to encourage innovation, support the changing mission).
- Use templates and tools that suit your needs. To get started quickly, make use of resources provided by your sponsor organization or internal MITRE resources.
- Use storyboarding, use cases, campaign modeling and simulation tools, and other tools that capture users, their activities, and the information flows. Prototyping and experiments are effective ways to collect the information.
- MIL-STD-490A, "Specification Practices," is a military standard for defining specification of military systems. Although it is officially cancelled, it provides descriptions of various types of specifications and their contents.
- Data Item Description DI-IPSC-81431A, "System/Subsystem Specification," is a template for a traditional military system or subsystem specification. It describes the format and contents of a traditional specification. It often requires tailoring to a particular application. It is a useful tool to stimulate thought on topics to be included in the requirements. There are specialized database tools that are designed to capture and manage requirements. A good source for information on available tools is the INCOSE website  under Requirements Management. The list is free to the public.
References & Resources
- Florence, A., April 2002, "Reducing Risks Through Proper Specification of Software Requirements," STSC CrossTalk, vol. 15 no. 4.
- Roedler, G. J. and C. Jones, 2005, Technical Measurement: A Collaborative Project of PSM, INCOSE, and Industry.
- INCOSE website.
Additional References & Resources
Ho, Chih-Wei, et al., 2006, "On Agile Performance Requirements Specification and Testing," IEEE Agile Conference.
Kossiakoff, A. and W. Sweet, December, 2002, Systems Engineering Principles and Practice, Wiley-Interscience.
Light, M., April 18, 2005, "Agile Requirements Definition and Management Will Benefit Application Development," Gartner RASCore Research Note G00126310, R1741.
Perron, J., Fall 2007, "User-Centered Requirements Analysis: Who, What, When, Where, Why & How," SEPO Collaborations, Vol. 5, Issue 2.