Concept and requirements definition translates priority operational needs in the enterprise architecture into preliminary requirements and a concept of use for the capability needed to improve service delivery. It also quantifies the service shortfall in sufficient detail for the definition of realistic preliminary requirements and the estimation of potential costs and benefits. Finally, concept and requirements definition identifies the most promising alternative solutions able to satisfy the service need, one of which must be the alternative in the enterprise architecture.

Planning for concept and requirements definition begins when a roadmap in the enterprise architecture specifies action must be taken to address a priority service or infrastructure need. These needs typically relate to existing or emerging shortfalls in the “as is” architecture or essential building blocks of the “to be” architecture. Should a service organization wish to pursue an investment opportunity not in an enterprise architecture roadmap, it must first develop architectural change products and amendments and get endorsement from the cognizant architectural review board.

The FAA may undertake research activity or employ research by other agencies or industry to define the operational concept, develop preliminary requirements, demonstrate and refine computer-human interfaces, reduce risk, or achieve customer buy-in to potential solutions to mission need.

A nonmaterial solution that emerges during concept and requirements definition may be implemented without proceeding further in the lifecycle management process, provided it satisfies the need, can be achieved within approved budgets, and is acceptable to users and customers. This determination is made by the Vice President or Director of the service organization with the mission need with the concurrence of the appropriate enterprise architecture control board.

Key functional disciplines such as safety, security, and human factors must participate in the activities of concept and requirements definition in order to determine mandatory requirements and evaluate their impact on potential alternative solutions.

The key activities of concept and requirements definition are shown in Figure 2.3.4-1.

 Figure 2.3.4-1 Key Activities of Concept / Requirements Definition

• Conduct detailed shortfall analysis. The priority infrastructure or service shortfall in the enterprise architecture and its impact on service delivery is quantified in sufficient detail to serve as the basis for (1) determining realistic and economic alternative solutions to the service need, (2) developing a concept of use, and (3) defining preliminary program requirements. This detailed shortfall analysis is also the basis for quantifying likely program costs and benefits during investment analysis.
• Develop range of alternatives.  The marketplace is surveyed to identify feasible and economic alternative solutions to the service need. Both material and non-material alternatives are evaluated. One must be the hypothesized "best" alternative in the enterprise architecture. Key factors to consider are safety, operational cost efficiencies (particularly those related to telecommunications and information systems security), technological maturity, and impact on the workforce and enterprise architecture. Alternatives should be qualitatively different from each other (e.g., different technologies such as ground-based versus airborne solutions or different acquisition strategies such as developmental versus commercially available items). Low risk, cost-effective, and operationally suitable commercial or non-developmental solutions are preferred. Alternatives may not meet 100 percent of preliminary requirements. Concept and technical descriptions are developed for each alternative.
• Define concept(s) of use.  The concept of use explains how new capabilities will function within the existing operational environment and how they will satisfy the service need. It defines key elements of the required capability and the roles and responsibilities of key participants (e.g., controllers, maintenance technicians, pilots). It explains operational issues that system engineers must understand when developing requirements; identifies procedural issues that may lead to operational change; and establishes a basis for evaluating benefits. If proposed alternative solutions are significantly different from each other, more than one concept of use may be required. The concept of use is recorded in the preliminary program requirements document.
• Develop preliminary requirements. The functional analysis performed during service analysis is the foundation for defining preliminary requirements. Preliminary requirements specify how well the new capability must perform intended functions. Safety, security, integrated logistics support, and human factors are key disciplines that must be considered. Preliminary requirements specify only function and performance, and do not define a solution. They must be expressed such that the degree to which different solutions satisfy them can be measured and evaluated. Research and analysis or even prototyping may be necessary to define preliminary requirements adequately. They are recorded in the preliminary program requirements document.
• Estimate rough lifecycle costs.  A rough lifecycle cost is developed for the range of alternatives that will be evaluated during initial investment analysis. A preliminary assessment of the availability of funding is also conducted. The head of the line of business uses this information as a basis for determining whether to pursue this service need in competition with all other service needs.
• Develop enterprise architecture products and amendments. Enterprise architecture products and amendments include the operational (business rule) and systems (engineering) view families. These families facilitate development, support, and execution of both service and infrastructure investment programs.
• Plan for investment analysis. The plan for investment analysis defines: (1) scope and assumptions; (2) alternatives and rough-order lifecycle cost estimates; and (3) organizational roles and responsibilities. It also specifies (4) a target schedule and defines (5) the resources needed for the work. By signing the plan for investment analysis, the organizations that will conduct the analysis agree to provide the resources necessary to complete the work.
• Prepare for the investment analysis readiness decision. This includes development of the decision package, verification that the activities of concept and requirements definition are complete, and pre-briefings to designated decision-makers.

The ATO Executive Council chaired by the Chief Operating Officer or the Associate or Assistant Administrator (non-ATO) of the line of business with the need conducts the investment analysis readiness review. This review determines whether there is sufficient information (i.e., data, planning, and resources) to begin investment analysis. Before the review, the ATO Operations Planning organization and the service organization jointly develop information to support the readiness decision. Readiness is based on development of sound and measurable preliminary requirements; a concept of use acceptable to users; a viable set of alternative that would satisfy the need; and the availability of resources to conduct investment analysis.

The Vice Presidents (ATO) or Directors (non-ATO) of the service organization with the mission need and the operating service organization approve the plan for initial investment analysis.