PERSPECTIVE: Realizing a Wall Through Requirements Articulation

There’s a lot of discussion about “The Wall” these days for our southern border. Let’s step back and analyze if that’s the real issue…Why a wall? Why not a wall? What’s the real problem?  Many questions—but not a lot of satisfying answers… Let me tell you a little story…

It really didn’t take even my first full day as the Chief Commercialization Officer of the United States to realize that most folks in government often rush to solutions—rather than understand the problem. And truth be told—it’s not much better in the private sector. If you think about it, we can point to many examples in both our professional and private lives where the lack of communication or unclear terminology has created misunderstandings, problems and myriad other issues. Effective communication is critical in the cost-effective and efficient interactions between various parties seeking a mutually beneficial relationship or partnership—for example—the U.S. government’s need to protect its people and property.

At every step of product development, it is critical to understand and meet user needs.

Developing requirements to guide effective product development is not a trivial effort; but with proper planning, dedication and communication, successful product development can yield measurable positive results and provide DHS (U.S. Department of Homeland Security) operating components, first responders, CIKR (Critical Infrastructure and Key Resources) owners and operators and other stakeholders with resources necessary to carry out their mission-critical objectives to protect our nation.

The initial phase of product realization is a mission needs assessment. This assessment should be conducted in relation to the overall mission for an organization. This exercise identifies capabilities needed to perform required functions, highlights deficiencies in a functional capability and documents the results of the analysis. Some of these capabilities may already be addressable with existing products, systems or services currently accessible by an organization. Analysis may also show that material solutions may not be necessary to solve a problem, as issues may be resolved through resource redistribution, staffing adjustments, standards development and other actions that do not require the fielding of new technologies. Additionally, a mission needs assessment serves to identify deficiencies in current and projected capabilities. In the event that current products are not able to address a particular capability; a capability gap exists. Briefly, capability gaps are defined by the difference between current operational capabilities and those necessary capabilities needed to perform mission-critical objectives that remain unsatisfied. Capability gaps must be listed in terms of an overall need to perform a specific task and should avoid explaining how that task should be achieved. Capability gaps that are discovered and articulated from a mission needs assessment form the foundation of solving problems.

For example, faced with the problem of potential intruders to a sensitive facility, we might define the requirement as “build a wall,” whereas the real requirement is “detect, thwart, and capture intruders.” Our wall might “thwart” intruders (or might not, if they’re adept at tunneling), but it would not detect them or facilitate their capture. In short, the solution would not solve the problem. See Figure 1.

The robust capability gap to “detect, thwart, and capture intruders” includes no preconceived solutions and prompts us to analyze alternative conceptual solutions and choose the best.

One way to ensure that we are defining a problem, rather than a solution, is to begin the statement of the requirement with the phrase “we need the capability to …” It’s nearly impossible to complete this sentence with a solution (“a wall”), and much easier to complete the sentence with a problem (“capability to detect intruders”). Capability gaps and requirements should address what a system should do, rather than how to do it. This approach is sometimes called capability-based planning. It is a very simple, yet powerful concept.

Properly defining clear and concise capability gaps is a necessary first step in product realization. This high-level understanding of a problem is a key part in the communication of needs. One may find that capability gaps are oftentimes common for multiple cross-sections of DHS operating components and supporting elements such as the first responder community and private sector critical infrastructure owner/operators.

Why Requirements?

Discovering Capability Gaps that exist within a particular functional area are paramount. These broad descriptions of department-level identified mission needs that are not met given current products and/or standards catalog opportunities for enhanced mission effectiveness or address deficiencies in national capability. However, capability gaps are just the first step in providing solutions to mission-critical needs. Operational requirements bring detailed information to support the capability gaps and define actionable information through detailed definitions of the problems, which need to be further delineated into technical requirements.

A requirement is an attribute of a product, service or system necessary to produce an outcome(s) that satisfies the needs of a person, group or organization. Requirements therefore define “the problem.” In contrast, “the solution” is defined by technical specifications.

Defining requirements is the process of determining what to make before making it. Requirements definition creates a method in which appropriate decisions about product or system functionality and performance can be made before investing the time and money to develop it. Understanding requirements early removes a great deal of guesswork in the planning stages and helps to ensure that the end-users and product developers are “on the same page.”

Requirements provide criteria against which solutions can be tested and evaluated. They offer detailed metrics that can be used to objectively measure a possible solution’s effectiveness, ensuring informed purchasing decisions on products, systems or services that achieve the stated operational goals. A detailed requirements analysis can uncover hidden requirements as well as discover common problems across programs and various DHS operating components. Detailed operational requirements will guide product development so that solutions’ specifications actively solve the stated problems.

We could save ourselves a lot of work if we jump straight to “the solution” without defining “the problem.” Why don’t we do that? Because if we take that shortcut we are likely to find that our solution may not be the best choice among possible alternatives or, even worse, we’re likely to find that our “solution” doesn’t even solve the problem!

Defining requirements and adhering to developing solutions to address those needs is often referred to as “requirements-pull.” In this situation, user requirements drive product development and guide the path forward as the requirements dictate. This is a powerful circumstance in which fulfilling requirements becomes the central focus of product development and no possible solution is disregarded given it facilitates addressing the stated operational requirements.

At the other extreme from the “requirements-pull” or “market-pull”, approach is “technology push.” Here we start with a solution (perhaps a new technology) and see what problems it might enable us to solve. The danger in this approach is to become enamored of “the solution” and neglect to ensure that it actually solves a problem. With technology push, it is likely that actual user requirements may be modified, or even ignored in order to “force-fit” the desired solution. A historical example was the product known as Picture Phone introduced (and discontinued) in the 1960s when the advance of telecommunications technology first made possible the transmission and display of video as well as voice. Picture Phone, which allowed telephone users to see each other during a call, was a technological success but a market disaster. It turned out that callers generally don’t want to be seen, as a bit of unbiased market analysis would have disclosed.

Technology push should not be ignored, but if the goal is successful transition to the field with acceptable risk, the technology being pushed must be compared to alternative solutions against a real set of user requirements.

Aside from assuring that the “solution” actually solves the “problem,” requirements- driven design has a further advantage in that the requirements provide criteria against which a product’s successful development can be measured. Specifically, if the product was developed to address a set of quantified operational requirements, then its success is measured by Operational Test and Evaluation (OT&E) to validate that an end-user can use the product and achieve the stated operational goals.

Prior to OT&E, it is common practice to subject products to Developmental Test and Evaluation (DT&E). The purpose of DT&E is to verify that the product meets its technical specifications, which are the engineers’ interpretation of the operational requirements. Such DT&E does not obviate the need for OT&E, which validates that the engineers’ solution is not only technically successfully but also represents a successful interpretation of the end users’ needs, satisfying the original operational requirements (not just the technical specifications) when operated by representative users.

Often requirements are stated in terms of “threshold values” and “objective values,” where the “objective value” is the desired performance and the “threshold value” is the minimum acceptable performance. This formalism is useful in allowing stretch goals to be asserted without saddling the system development with unacceptable risk.

The Requirements Hierarchy and Traceability

To reiterate the definitions above, the documents that govern product realization include requirements, which define the problem, and specifications, which define the solution. Nevertheless, the hierarchy of requirements and specifications is more complex than that simple dichotomy, as previously discussed and revisited in Figure 2.

The Hierarchy is divided into two domains, operational requirements and technical requirements, highlighted in yellow and blue in the figure, representing the “problem space” and the “solution space” respectively. The DHS stakeholder, representing the end users in the field (the operators), is also responsible for all operational requirements, from the top-level mission requirements to the detailed system-level operational requirements. It is important to articulate these operational requirements in detail to avoid misunderstandings later in the product development life cycle. A system developer is responsible for translating the operational requirements into a system solution, documented in a hierarchy of technical specifications.

The highest-level type of technical “specification” is actually called a performance “requirement.” A performance requirement actually represents a bridge from operational requirements to the engineering interpretation of those requirements. Put another way, in the course of developing a new system it is necessary to transform the system operational requirements, which are stated from a given Operating Component’s perspective as required outcomes of system action, into a set of system performance requirements, which are stated in terms of engineering characteristics.

Working through the requirements hierarchy, requirements development is the process of decomposing the problems broadly outlined in the capability gaps gleaned from the mission needs assessment.

The requirements and specifications are described below, first those that define the problem and then those that define the solution:

• Problem Definition
  • Mission Needs Statement (MNS)/Capability Gap is required by the DHS Acquisition Review Process (Management Directive 102-01) and is developed by the DHS sponsor (Custom Borders Protection, for example) who represents the end users .MNS provides a high-level description of the mission need (or, equivalently, capability gap), and is used to justify the initiation of an Acquisition program.

• Operational Requirements Document (ORD) is also required by the DHS Acquisition Review Process and, like the MNS, is developed by the DHS stakeholder. The ORD specifies operational requirements and a concept of operations (CONOPS), written from the point of view of the end The ORD is independent of any particular implementation, should not refer to any specific technologies and does not commit the developers to a design. A well written ORD states the problem that must be solved along with the necessary capabilities that a system must perform.

• Solution Definition
  • Performance Requirements represent a bridge between the operationally oriented view of the system defined in the ORD and an engineering- oriented view required to define the solution. Performance requirements are an interpretation, not a replacement of operational requirements. Performance requirements define the functions that the system and its subsystems must perform to achieve the operational objectives and define the performance parameters for each function. These definitions are in engineering rather than operational terms.
  • Functional Specifications define the system solution functionally, though not Sometimes called the “system specification” or “A-Spec,” these specifications define functions at the system, subsystem, and component level including:
    • Configuration, organization, and interfaces between system elements
    • Performance characteristics and compatibility requirements
    • Human engineering
    • Security and safety
    • Reliability, maintainability and availability
    • Support requirements such as shipping, handling, storage, training and special facilities
• Design Specifications convert the functional specifications of what the system is to do into a specification of how the required functions are to be implemented in hardware and The design specifications therefore govern the materialization of the system components.
• Material Specifications are an example of lower-level supporting specifications that support the higher-level specifications. Material specifications define the required properties of materials and parts used to fabricate the system. Other supporting specifications include Process Specifications (defining required properties of fabrication processes such as soldering and welding) and Product Specifications (defining required properties of non-developmental items to be procured commercially).

Characteristics of Good Requirements

Requirements engineering is difficult and time-consuming, but must be done well if the final product or system is to be judged by the end users as successful. From the International Council of Systems Engineers (INCOSE) Requirements Working Group1, here are eight attributes of good requirements:

Developing Operational Requirements (ORDs): Customer Input

So far, we’ve discussed operational requirements but have not provided any insight into how to develop them. In an effort to provide a basic framework for the articulation and documentation of operational requirements, the operational requirements document (ORD) was created. ORDs provide a clear definition and articulation of a given problem, providing several layers of information that comprise the overall problem. Using resources such as this book and the accompanying template, we have tried to simplify and streamline the process of communicating requirements. ORDs can be used in Acquisition, Procurement, Internal Development, Commercialization and Outreach Programs – any situation that dictates detailed requirements (e.g. RFQ, BAA, RFP, RFI, etc.). It’s clear to see that it’s cost-effective and efficient for both DHS and all of its stakeholders to communicate needs clearly and effectively.

Let’s first look at the contents of a typical Operational Requirements Document (ORD) shown in Figure 3.

The complexity of the intended system and its operational context will govern the required level of detail in the ORD. The most difficult sections to develop are typically Section 4.0, which describes the capabilities required of the system to be developed, and Section 1.6, which describes the operational and support concepts.\

There is no “silver bullet” to solve the potential challenges in developing an ORD, but since the issues are universal, there is a wealth of literature that offers approaches to requirements development. As an example, here are nine requirements-elicitation techniques described in the Business Analyst Body of Knowledge (from the International Institute of Business Analysis).

1. Brainstorming
   • Purpose
     • An excellent way of eliciting many creative ideas for an area of interest. Structured brainstorming produces numerous creative ideas.
   • Strengths
     • Able to elicit many ideas in a short time period.
     • Non-judgmental environment enables outside-the-box thinking.
   • Weaknesses
     • Dependent on participants’ creativity.

2. Document Analysis
   • Purpose
     • Used if the objective is to gather details of the “As Is” environment such as existing standard procedures or attributes that need to be included in a new system.
   • Strengths
     • Not starting from a blank page.
     • Leveraging existing materials to discover and/or confirm requirements.
     • A means to crosscheck requirements from other elicitation techniques such as interviews, job shadowing, surveys or focus groups.
   • Weaknesses
     • Limited to “as-is” perspective.
     • Existing documentation may not be up-to-date or valid.
     • Can be a time-consuming and even tedious process to locate the relevant information.

3. Focus Group
   • Purpose
     • A means to elicit ideas and attitudes about a specific product, service or opportunity in an interactive group environment. The participants share their impressions, preferences and needs, guided by a moderator.
   • Strengths
     • Ability to elicit data from a group of people in a single session saves time and costs as compared to conducting individual interviews with the same number of people.
     • Effective for learning people’s attitudes, experiences and desires.
     • Active discussion and the ability to ask others questions creates an environment where participants can consider their personal view in relation to other perspectives.
   • Weaknesses
     • In the group setting, participants may be concerned about issues of trust, or may be unwilling to discuss sensitive or personal topics.

• Data collected (what people say) may not be consistent with how people actually behave.
• If the group is too homogenous, the group’s responses may not represent the complete set of requirements.
• A skilled moderator is needed to manage the group interactions and discussions.
• It may be difficult to schedule the group for the same date and time.

4. Interface Analysis
   • Purpose
     • An interface is a connection between two components. Most systems require one or more interfaces with external parties, systems or devices. Interface analysis is initiated by project managers and analysts to reach agreement with the stakeholders on what interfaces are needed. Subsequent analysis uncovers the detailed requirements for each interface.
   • Strengths
     • The elicitation of the interfaces’ functional requirements early in the system life cycle provides valuable details for project management:
       • Impact on delivery date. Knowing what interfaces are needed, their complexity and testing needs enables more accurate project planning and potential savings in time and cost.
       • Collaboration with other systems or projects. If the interface to an existing system, product or device and the interface already exist, it may not be easily changed. If the interface is new, then the ownership, development and testing of the interface needs to be addressed and coordinated in both projects’ plan. In either case, eliciting the interface requirements will require negotiation and cooperation between the owning systems.
     • Weaknesses
       • Does not provide an understanding of the total system or operational concept since this technique only exposes the inputs, outputs and key data elements related to the interfaces.

5. Interview
   • Purpose
     • A systematic approach to elicit information from a person or group of people in an informal or formal setting by asking relevant questions and documenting the responses.
   • Strengths
     • Encourages participation and establishes rapport with the stakeholder.
     • Simple, direct technique that can be used in varying situations.
     • Allows the interviewer and participant to have full discussions and explanations of the questions and answers.
     • Enables observations of non-verbal behavior.

• The interviewer can ask follow-up and probing questions to confirm own understanding.
• Maintain focus using clear objectives for the interview that are agreed upon by all participants and can be met in the time allotted.

• Weaknesses
  • Interviews are not an ideal means of reaching consensus across a group of stakeholders.
  • Requires considerable commitment and involvement of the participants.
  • Training is required to conduct good interviews. Unstructured interviews, especially, require special skills. Facilitation/virtual facilitation and active listening are a few of them.
  • Depth of follow-on questions may be dependent on the interviewer’s knowledge of the operational domain.
  • Transcription and analysis of interview data can be complex and expensive.
  • Resulting documentation is subject to interviewer’s interpretation.

6. Observation
   • Purpose
     • A means to elicit requirements by assessing the operational environment. This technique is appropriate when documenting details about current operations or if the project intends to enhance or change a current operational concept.
   • Strengths
     • Provides a realistic and practical insight into field operations by getting a hands-on feel for current operations.
     • Elicits details of informal communication and ways people actually work around the system that may not be documented anywhere.
   • Weaknesses
     • Only possible for existing operations.
     • Could be time-consuming.
     • May be disruptive to the person being shadowed.
     • Unusual exceptions and critical situations that happen infrequently may not occur during the observation.
     • May not well work if current operations involve a lot of intellectual work or other work that is not easily observable.

7. Prototyping
   • Purpose
     • Prototyping, when used as an elicitation technique, aims to uncover and visualize user requirements before the system is designed or developed.

• Strengths
  • Supports users who are more comfortable and effective at articulating their needs by using pictures or hands-on prototypes, as prototyping lets them “see” the future system’s interface.
  • A prototype allows for early user interaction and feedback.
  • A throwaway prototype is an inexpensive means to quickly uncover and confirm user interface requirements.
  • A revolutionary prototype can demonstration what is feasible with existing technology, and where there may be technical gaps.
  • An evolutionary prototype provides a vehicle for designers and developers to learn about the users’ interface needs and to evolve system requirements.
• Weaknesses
  • Depending on the complexity of the target system, using prototyping to elicit requirements can take considerable time if the process is bogged down by the “how’s” rather than “what’s”.
  • Assumptions about the underlying technology may need to be made in order to present a starting prototype.
  • A prototype may lead users to set unrealistic expectations of the delivered system’s performance, reliability and usability characteristics.

8. Requirements Workshop
   • Purpose
     • A requirements workshop is a structured way to capture requirements. A workshop may be used to scope, discover, define, prioritize and reach closure on requirements for the target system. Well-run workshops are considered one of the most effective ways to deliver high quality requirements quickly. They promote trust, mutual understanding, and strong communications among the project stakeholders and project team, produce deliverables that structure, and guide future analysis.
   • Strengths
     • A workshop can be a means to elicit detailed requirements in a relatively short period of time.
     • A workshop provides a means for stakeholders to collaborate, make decisions and gain a mutual understanding of the requirements.
     • Workshop costs are often lower than the cost of performing multiple interviews.
     • A requirements workshop enables the participants to work together to reach consensus, which is typically a cheaper and faster approach than doing serial interviews as interviews may yield conflicting requirements and the effort needed to resolve those conflicts across all interviewees can be very costly.
     • Feedback is immediate, if the facilitator’s interpretation of requirements is fed back immediately to the stakeholders and confirmed.

• Weaknesses
  • Due to stakeholders availability it may be difficult to schedule the workshop.
  • The success of the workshop is highly dependent on the expertise of the facilitator and knowledge of the participants.
  • Requirements workshops that involve too many participants can slow down the workshop process thus negatively affecting the schedule. Conversely, collecting input from too few participants can lead to overlooking requirements that are important to users, or to specifying requirements that do not represent the needs of the majority of the users.

9. Survey/Questionnaire
   • Purpose
     • A means of eliciting information from many people, anonymously, in a relatively short time. A survey can collect information about customers, products, operational practices and attitudes. A survey is often referred to as a questionnaire.
   • Strengths
     • When using ‘closed-ended’ questions, effective in obtaining quantitative data for use in statistical analysis.
     • When using open-ended questions, the survey results may yield insights and opinions not easily obtainable through other elicitation techniques.
     • Does not typically require significant time from the responders.
     • Effective and efficient when stakeholders are not located at one place.
     • May result in large number of responses.
     • Quick and relatively inexpensive to administer.
   • Weaknesses
     • Use of open-ended questions requires more analysis.
     • To achieve unbiased-results, specialized skills in statistical sampling methods are needed when the decision has been made to survey a sample subset.
     • Some questions may be left unanswered or answered incorrectly due to their ambiguous nature.
     • May require follow up questions or more survey iterations depending on the answers provided.
     • Not well suited for collecting information on actual behaviors.

Addressing Requirements Versus Proposing Solutions

When employing efforts to elicit and explain requirements using any of these methods, it is imperative to steadfastly avoid requirements that define potential solutions or otherwise restrict the potential solution space. Again, requirements only deal with the problem at hand and do not discuss the preferred or desired tool or way to go about solving the problem. Any standards or limitations that a system must address within a given scenario are important to mention within an ORD, but entire solution sets may not be discounted as potential scientific advances may make certain technologies feasible.

While it is necessary and useful to understand the current state-of-the-art within a given technology space and knowledge about potential solutions that may already be in development, requirements are meant to simply define problems. Properly drafted requirements allow for a variety of solutions, each with their own advantages and disadvantages, for consideration as potential ways to address a problem. Solution- agnostic requirements prevent limiting and defining the outcome of product realization. Within the context of the Operational Requirements Document Template described in detail below, the solution definition aspect of the Requirements Hierarchy is purposefully not addressed. This is useful given that an open and honest review of one’s needs might show that a preconceived notion about a desired solution may turn out not to be the best solution, or that modifications to existing products or services may be necessary and useful to end users.

The following insert provides the Operational Requirements Document template. This template guides you through drafting a new ORD by describing the information that should be captured in each section of the document. This template is useful in organizing and delineating the problem to be solved. Several important topics are covered by the template and it assists in presenting many questions that must be addressed in order to articulate fully and clearly the desired outcome from deploying a system to address a problem.

Operational Requirements Document Template

1. General Description of Operational Capability

In this section, summarize the capability gap which the product or system is intended to address, describe the overall mission area, describe the proposed system solution, and provide a summary of any supporting analyses. Additionally, briefly describe the operational and support concepts. 

• Capability Gap

Describe the analysis and rationale for acquiring a new product or system, and identify the DHS Component, which contains or represents the end users. Also, name the Capstone IPT, if any, which identified the capability gap.

• Overall Mission Area Description

Define and describe the overall mission area to which the capability gap pertains, including its users and its scope.

• Description of the Proposed System

Describe the proposed product or system. Describe how the product or system will provide the capabilities and functional improvements needed to address the capability gap. Do not describe a specific technology or system solution. Instead, describe a conceptual solution for illustrative purposes. 

• Supporting Analysis

Describe the analysis that supports the proposed system. If a formal study was performed, identify the study and briefly provide a summary of results.

• Mission the Proposed System Will Accomplish

Define the missions that the proposed system will be tasked to accomplish. 

• Operational and Support Concept

• Concept of Operations

Briefly describe the concept of operations for the system. How will the system be used, and what is its organizational setting? It is appropriate to include a graphic that depicts the system and its operation. Also, describe the system’s interoperability requirements with other systems. 

• Support Concept

Briefly describe the support concept for the system. How will the system (hardware and software) be maintained? Who will maintain it? How, where, and by whom will spare parts be provisioned? How, where, and by whom will operators be trained?

2. Threat

If the system is intended as a countermeasure to a threat, summarize the threat to be countered and the projected threat environment.

3. Existing System Shortfalls

Describe why existing systems cannot meet current or projected requirements. Describe what new capabilities are needed to address the gap between current capabilities and required capabilities.

4. Capabilities Required
   • Operational Performance Parameters

Identify operational performance parameters (capabilities and characteristics) required for the proposed system. Articulate the requirements in output-oriented and measurable terms. Use Threshold/Objective format and provide criteria and rationale for each requirement.

• Key Performance Parameters (KPPs)

The KPPs are those attributes or characteristics of a system that are considered critical or essential. Failure to meet a KPP threshold value could be the basis to reject a system solution.

• System 

• Mission Scenarios

Describe mission scenarios in terms of mission profiles, employment tactics, and environmental conditions. 

• System Performance Parameters

Identify system performance parameters. Identify KPPs by placing an asterisk in front of the parameter description.

• Interoperability

Identify all requirements for the system to provide data, information, materiel, and services to and accept the same from other systems, and to use the data, information, materiel, and services so exchanged to enable them to operate effectively together. 

• Human Interface Requirements

Discuss broad cognitive, physical, and sensory requirements for the operators, maintainers, or support personnel that contribute to, or constrain, total system performance. Provide broad staffing constraints for operators, maintainers, and support personnel. 

• Logistics and Readiness

Describe the requirements for the system to be supportable and available for operations. Provide performance parameters for availability, reliability, system maintainability, and software maintainability. 

• Other System Characteristics

Characteristics that tend to be design, cost, and risk drivers. 

5. System Support

Establish support objectives for initial and full operational capability. Discuss interfacing systems, transportation and facilities, and standardization and interoperability. Describe the support approach including configuration management, repair, scheduled maintenance, support operations, software support, and user support (such as training and help desk).

• Maintenance

Identify the types of maintenance to be performed and who will perform the maintenance. Describe methods for upgrades and technology insertions. Also, address post-development software support requirements.

• Supply

Describe the approach to supplying field operators and maintenance technicians with necessary tools, spares, diagnostic equipment, and manuals.

• Support Equipment

Define the standard support equipment to be used by the system. Discuss any need for special test equipment or software development environment.

• Training

Describe how the training will ensure that users are certified as capable of operating and using the proposed system. 

• Transportation and Facilities

Describe how the system will be transported to the field, identifying any lift constraints. Identify facilities needed for staging and training. 

6. Force Structure

Estimate the number of systems or subsystems needed, including spares and training units. Identify organizations and units that will employ the systems being developed and procured, estimating the number of users in each organization or unit.

7. Schedule

To the degree that schedule is a requirement, define target dates for system availability. If a distinction is made between Initial Capability and Full Operational Capability, clarify the difference between the two in terms of system capability and/or numbers of fielded systems.

8. System Affordability

Identify a threshold/objective target price to the user at full-rate production. If price is a KPP, include it in the section on KPPs above.

*Please Note: See some of my published books for a full set of real-world example ORDs that clearly illustrate how to effectively use this template and other previously described methods.

Tom Cellucci

H.E. The Hon, Sir Dr. Thomas A. Cellucci, PhD, MBA is a serial entrepreneur, currently managing several high-tech firms. He was appointed the US Department of Homeland Security’s Director of the Research & Development Partnerships (RDP) Group managing over $12B in assets and over1700 team members. He was also the first Chief Commercialization Officer in the US Federal Executive Branch and continues to assist the President of the United States and Chairman of the Joint Chiefs. In 1999, he founded Cellucci Associates, Inc. with headquarters at Harvard Square in Cambridge, MA. Cellucci writes about the intersection of emerging technology, commercialization, and implementation to protect the homeland. Cellucci earned a PhD in Physical Chemistry from the University of Pennsylvania (1984), an MBA from Rutgers University (1991) and a BS in Chemistry with Honors from Fordham University (1980). He holds two endowed Chairs at prestigious universities in Kazakhstan and has taught at Harvard Business School, Princeton University and the University of Pennsylvania.

See Full Bio