REQUIREMENTS ANALYSIS

The Systems Engineering Process

The Systems Engineering Process

SYSTEMS ENGINEERING PROCESS INPUTS
The inputs to the process include the customer's requirements and the project constraints. Requirements relate directly to the performance characteristics of the system being designed. They are the stated life-cycle customer needs and objectives for the system, and they relate to how well the system will work in its intended environment.

Requirements are the primary focus in the systems engineering process because the process's primary purpose is to transform the requirements into designs. The process develops these designs within the constraints. They eventually must be verified to meet both the requirements and constraints.

Types of Requirements
Requirements are categorized in several ways. The following are common categorizations of requirements that relate to technical management:

Customer Requirements
Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in Figure.

Operational Requirements - Basic Questions
Operational distribution or deployment: Where will the system be used?
Mission profile or scenario: How will the system accomplish its mission objective?
Performance and related parameters: What are the critical system parameters to accomplish the mission?
Utilization environments: How are the various system components to be used?
Effectiveness requirements: How effective or efficient must the system be in performing its mission?
Operational life cycle: How long will the system be in use by the user?
Environment: What environments will the system be expected to operate in an effective manner?

Functional Requirements
The necessary task, action or activity that must be accomplished. Functional (what has to be done) requirements identified in requirements analysis will be used as the top-level functions for functional analysis.

PerformanceRequirements
The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements.

Design Requirements
The "build to," "code to," and "buy to" requirements for products and "how to execute" requirements for processes expressed in technical data packages and technical manuals.

Derived Requirements
Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.

Allocated Requirements
A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.

Attributes of Good Requirements
A requirement must be achievable. It must reflect need or objective for which a solution is technically achievable at costs considered affordable.
It must be verifiable—that is, not defined by words such as excessive, sufficient, resistant, etc. The expected performance and functional utility must be expressed in a manner that allows verification to be objective, preferably quantitative.
A requirement must be unambiguous. It must have but one possible meaning.
It must be complete and contain all mission profiles, operational and maintenance concepts, utilization environments and constraints. All information necessary to understand the customer's need must be there.

Attributes of Good Requirements
It must be expressed in terms of need, not solution; that is, it should address the "why" and "what" of the need, not how to do it.
It must be consistent with other requirements. Conflicts must be resolved up front.
It must be appropriate for the level of system hierarchy. It should not be too detailed that it constrains solutions for the current level of design. For example, detailed requirements relating to components would not normally be in a system-level specification.

The purpose of Requirements Analysis is to:
Refine customer objectives and requirements;
Define initial performance objectives and refine them into requirements;
Identify and define constraints that limit solutions; and
Define functional and performance requirements based on customer provided measures of effectiveness.

In general, Requirements Analysis should result in a clear understanding of:
Functions: What the system has to do,
Performance: How well the functions have to be performed,
Interfaces: Environment in which the system will perform, and
Other requirements and constraints.

Inputs to Requirements Analysis

Requirements Analysis is a process of inquiry and resolution. The following are typical questions that can initiate the thought process:
What are the reasons behind the system development?
What are the customer expectations?
Who are the users and how do they intend to use the product?
What do the users expect of the product?
What is their level of expertise?

Requirements Analysis is a process of inquiry and resolution. The following are typical questions that can initiate the thought process:
With what environmental characteristics must the system comply?
What are existing and planned interfaces?
What functions will the system perform, expressed in customer language?
What are the constraints (hardware, software, economic, procedural) to which the system must comply?
What will be the final form of the product: such as model, prototype, or mass production?

REQUIREMENTS ANALYSIS OUTPUTS
The requirements that result from requirements analysis are typically expressed from one of three perspectives or views. These have been described as the Operational, Functional, and Physical views. All three are necessary and must be coordinated to fully understand the customers' needs and objectives. All three are documented in the decision database.

Operational View
Operational need definition,
System mission analysis,
Operational sequences,
Operational environments,
Conditions/events to which a system must respond,
Operational constraints on system,
Mission performance requirements,
User and maintainer roles (defined by job tasks and skill requirements or constraints),
Structure of the organizations that will operate, support and maintain the system, and
Operational interfaces with other systems.

Functional View
System functions,
System performance,
Qualitative — how well
Quantitative — how much, capacity
Timeliness — how often
Tasks or actions to be performed,

Functional View
Inter-function relationships,
Hardware and software functional relationships,
Performance constraints,
Interface requirements including identification of potential open-system opportunities (potential standards that could promote open systems should be identified),
Unique hardware or software, and
Verification requirements (to include inspection, analysis/simulation, demo, and test).

Physical View
Configuration of System:
Interface descriptions,
Characteristics of information displays and operator controls,
Relationships of operators to system/ physical equipment, and
Operator skills and levels required to perform assigned functions.
Characterization of Users:

Physical View
Handicaps (special operating environments), and
Constraints (movement or visual limitations).
System Physical Limitations:
Physical limitations (capacity, power, size, weight),
Technology limitations (range, precision, data rates, frequency, language),
Government Furinished Equipment (GFE), Commercial-Off-the-Shelf (COTS), Nondevelopmental Item (NDI), reusability requirements, and
Necessary or directed standards.