9.3.1.1 Requirements

Requirements describe the technical capabilities and levels of performance that a system must have and any constraints on the system or system design. System engineers translate stakeholder needs into clear requirement statements specific enough for domain engineers to implement and test in order to verify that they are satisfied. Requirement engineering is a critical specialty that involves extensive analysis and management, especially when there are requirement changes in later stages of the life cycle. Requirement changes typically have the highest impact on cost and schedule due to the redesign and rework needed to implement the change. In order to mitigate a change's impact, it is important to establish a logical requirement structure with auditable records that can be traced to functions, objectives, and system features. Understanding which functions, objectives, and system features satisfy requirements will reduce the impact of a requirements change when they occur. The Model-Based Systems Engineering (MBSE) approach is a new paradigm that supports the specification, analysis, design, and verification of a complex system using an integrated system model with a dedicated tool. The integrated system model effectively manages the auditable records of a system design by defining a system element once to be used throughout the model. As a result, once a change is made to an element in the integrated system model, the dedicated tool will instantly identify how the change will impact the system. The MBSE approach is gaining popularity and is expected to become a common state of practice in the near future (National Defense Industrial Association, 2011).

Each requirement can be classified as either a desired capability or a constraint that must be met (Parnell et al., 2011). The arrow from the Requirements decision node to the Functions decision node in Figure 9.2 represents how the desired capabilities inform what functions the system must perform in order to achieve the objectives. Requirements influence the value functions indirectly through the Functions and Objectives decision nodes in two ways. First, the desired capabilities inform the threshold and objective values used to define the shape of the value function. Second, the constraints are those that define the screening criteria, minimum acceptable value, or walk-away point that eliminates alternatives from the decision.

9.3.1.2 Functions

A function is an action that transforms inputs and generates outputs, involving data, materials, and/or energies (SEBoK, 2015). The INCOSE Systems Engineering Handbook (SEH) defines a function as a characteristic task, action, or activity that must be performed to achieve a desired outcome (SEBoK, 2015). Functional analysis is a key systems engineering task that identifies the system functions and system element interfaces required to perform the performance objectives (Parnell et al., 2011). The arrow from the Functions decision node to the Objectives decision node in Figure 9.2 represents how functions are used to identify the fundamental objectives we want to achieve; see Section 7.8 for a discussion on how to develop a functional hierarchy.

Functions are allocated to structural elements of the system alternative that performs them. Depending on the system decision, these system elements may be subsystems, components, or parts. Each system element has system features that define the element's characteristics. System engineers use models and simulations, subject matter expertise (SME), operational testing results, and data from legacy systems to decide which functions will be allocated to each system feature. The arrow from the Functions decision node to the System Alternatives decision node in Figure 9.2 represents the functional allocation to the system features; these allocations depend heavily on the perspective of how functions will be satisfied. In Figure 9.3, we show an example of a functional allocation to subsystems from the squad enhancement design example.

9.3.1.3 Objectives

An objective is a statement of something that we desire to achieve (Keeney, 1992). Identifying the objectives we use to evaluate our system alternative is the most critical step in the decision process; see Chapter 7 for a detailed discussion on the development of the objectives. Figure 9.2 shows two outgoing arrows from the Objective decision node: one to the Scenarios uncertainty node that represents the objective's influence on the scenario context and another to the Value Function constant node. Each objective has one or more value functions that assess a system alternative's achievement of that objective.

9.3.1.4 System Alternatives

This decision node involves the selection of alternatives within the decision space that will be considered in the system decision. The decision space involves the exploration of creative alternatives that span the opportunity space as much as possible; Chapter 8 will discuss in detail methods system engineers can use to generate these creative alternatives. The alternatives within the decision space are what the SEBoK refers to as the physical architecture. System alternatives each have a collection of elements with system features that define the characteristics of the alternative. The settings of the system features distinguish one alternative from another. The arrow in Figure 9.2 from the System Alternative decision node to the System Feature uncertainty node represents how the alternative has system features that define its characteristics. For the squad enhancement design example, we have seven alternatives. Table 9.1 shows each alternative for our example, along with their system features that define their unique characteristics; the types of UAVs are from the example in Chapter 5.

9.3.2.1 Stakeholder Needs

In the early stages of the conceptual design, stakeholders develop need statements that express what they think the system should be able to do from their perspectives. The arrow in Figure 9.2 from the Stakeholder needs uncertainty node to the Requirements decision node represents the need's refinement into a system requirement. The uncertainty associated with stakeholder needs is the result of an unclear problem statement within the opportunity space and ill-defined values in the objective space. To address this challenge, we use a value hierarchy that captures a composite perspective of multiple stakeholders with conflicting objectives. For the squad enhancement design example, the key stakeholders include the decision-makers responsible for the system decisions, the acquisition personnel who manage the development, the technologists that develop the technology, the specialty engineers who design the system, the contractors that build the systems, the logistical personnel who distribute and maintain the system, and the soldiers who operate the system.

9.3.2.2 Adversary/Competition

This type of uncertainty node involves the external factors that influence the outcome of a scenario; this relationship is represented by the arrow in Figure 9.2 from the Adversary/Competition uncertainty node to the Scenarios uncertainty node. In defense, information security, and homeland defense type problems, we typically have adversaries while in the private sector, we have competitors that influence the outcome of a scenario. For the squad enhancement design example, the adversaries are the enemy forces that fight against the squad.

9.3.2.3 Scenarios

Scenarios involve political–military situations, missions, and the environment. Scenarios allow systems engineers to understand how a system will operate in different environmental conditions. In order to evaluate the system, system engineers can leverage operational simulations that model the system performing its intended purpose within different scenarios. Because there are many situational outcomes for each scenario, we should use stochastic models that simulate multiple scenarios or run trials. In Figure 9.2, there are two outgoing arrows from the Scenarios uncertainty node to the Priorities and System Models uncertainty nodes; these arrows represent the following two influences: first, each scenario typically has different priorities that depend on the scenario's context; second, scenarios influence the development of system simulation models by specifying what should occur during the conduct of the simulation. In the squad enhancement design example, we use two scenarios that represent the assault and defend missions.

In the assault scenario, the squad conducts an assault to seize terrain and destroy the enemy. The squad moves toward the enemy with their robot in front and UAV flying overhead. The squad calls for indirect fire as they approach the enemy. The enemy is positioned on high ground with Improvised Explosive Devices around their perimeter. The squad establishes a support by fire position with the Automatic Weapons and Grenadiers while the Rifleman assaults the enemy. The enemy calls for another enemy element to reinforce their position. The squad calls indirect fire on the reinforcements once they identify their location.

In the defensive scenario, the squad is in a defensive position in a combat outpost with 10 ft walls, two gate entry points, and fighting positions around their perimeter. Robots are positions outside the perimeter to act as forward sensors. Six enemy insurgents approach the combat outpost wearing suicide vests and attempt to detonate at the gate to breach into the combat outpost, make entry, and detonate additional suicide vest within the perimeter. The enemy then calls indirect fire from a mortar position that is beyond line of friendly sight. Enemy crew serve weapons open fire on the combat outpost from a long range distance while the enemy approaches the combat outpost from three different directions. The squad calls for indirect fire once they identify enemy force locations beyond line of sight. A UAV will loiter over the area of operations in order to provide early warning to the squad.

When developing a scenario, we must ensure that the entire system has an opportunity to perform all of its intended functions in order to properly evaluate each alternative. For example, in the assault and defense scenario, the UAV and robot have an opportunity to identify the enemy and provide earlier warning to the squad beyond line of sight. In addition, both scenarios have enough hostile enemies that fire at the squad in order to evaluate the system effectiveness with regard to the protection function.

9.3.2.4 Priorities

In a multiple-objective decision model, priorities are instantiated using swing weights (Chapter 2). If we have one scenario, the priorities would be constant. In general, when there are multiple scenarios, the priorities will be different for each of them (Parnell et al., 1999). The swing weight matrix is a useful way to assess swing weights (Parnell et al., 2013). In the squad enhancement design example, we evaluate the system with respect to the assault and defense scenarios; Tables 9.2 and 9.3 show the swing weight matrices for each scenario, respectively. Within each matrix, the value measures are placed in different importance columns depending on whether they are mission-critical, enable, or enhance the system's capabilities. The row of the matrix classifies the value measure's impact on capability and is based on the range of the value measure scale (large, medium, or small capability gap between the walk-away and the ideal levels). Placing the value measures within the columns and rows of the swing weight matrix provides both a subjective importance criteria and an objective criteria based on the impact of the value measure scale's range. The scenario swing weights quantify the trade-offs between the value measures differently, which have an impact on our decision.

It is important to understand how changes in the swing weight assignments impact the results of the alternative values. A common approach to visualizing the impact of swing weight changes is with a line chart that varies the weight from 0 to 1; see Section 5.3.15.

9.3.2.5 Technology Maturity

Technological maturity is one of the most difficult uncertainty nodes to assess and typically has the highest impact on each alternative's risk. The Department of Defense has established nine Technical Readiness Level criteria (TRL 1–9) that describe categories of system readiness acquisition managers use to classify system technological maturity (Mankins, 1995). Each subsystem, component, or part has system features with their own unique level of maturity. The technology drives the uncertainty in the system features and the data used to populate the value measures. Existing system alternatives that are already in use may have features with high levels of technical maturity while nonexistent, conceptual systems may have low levels of maturity. Low levels of system feature maturity can cause higher risk of achieving system value, cost, and schedule. System integration is another challenge that we can classify within the Technology Maturity uncertainty node. Functional analysis identifies the component and part integration requirements that are often the leading cause of system redesign and rework during the life cycle. Depending on the technological maturity of the component or part, there may be significant uncertainty in its ability to integrate with other components or parts in the system. These integration challenges add an additional layer of complexity that increases the risk of achieving system value, cost, and schedule. The arrow in Figure 9.2 from the Technology Maturity uncertainty node to the System Features uncertainty node represents the risk technology imposes on the system feature settings that define each alternative.

9.3.2.6 System Features

System features are the characteristics or design parameters that define each alternative. The types of features coincide with the type of system decision within each phase of the life cycle (concept, architecture, design, or operations). A system feature is analogous to what is known as a local property within physical architecture: a property that is local to a single system element (SEBoK, 2015). In Figure 9.2, the System Features uncertainty node influences the System Models, Value Measure Data, and Resource (Cost) uncertainty nodes. System Models model alternatives within a scenario by setting the model inputs so that the model run represents the alternative of interest. As a result, the system features that define the characteristics of an alternative become the inputs to the simulation model(s). When models are not used to evaluate the whole system or a subset of the system, we acquire value measure data from subject matter experts, development testing, operational testing, and legacy system architectures. System feature settings drive the cost of the alternative. Typically, costs are decomposed into different components that are allocated to subsets of system features. As a result, we can attribute the cost drivers to system features of the alternative. Table 9.1 has examples of system feature settings for each of the seven alternatives in the squad enhancement design example.

9.3.2.7 System Models

System models are critical to understanding the behavior of a system, especially in the early stages of the life cycle. There are many types of models that represent different domains and perspectives; they include operational simulations that model a system performing a mission, models that estimate life cycle costs, physics-based computational models that help understand system feasibility, and many more. Because models are abstractions of reality, they must be verified and validated so that they can accurately inform the system decision. The arrow in Figure 9.2 from the System Models uncertainty node to the Value Measure Data uncertainty node represents how the model outputs generate the data used to evaluate an alternative. For each alternative in the squad enhancement design example, we modeled the assault and defense scenarios using an agent-based simulation; for each scenario, we executed 100 trails. The value model used four model outputs to populate the data for the following value measures: Beyond Line of Sight Awareness, Line of Sight Distance, Protection, and Logistical Impact. Because the model is stochastic, each alternative has 100 different outcomes for each of the four outputs.

9.3.2.8 Value Measure Data

Data, information, and knowledge along with values and alternatives are what drive decisions. Data is for the systems engineer what electricity is for the electrical engineer and construction material is for the civil engineer; it is the underlying commodity to base all system engineering methods, processes, and activities. We use data to populate value measures for each alternative. Value measures quantify the objectives we use to evaluate our alternatives. See Section 7.7 for details on how to develop value measures. Generally, we obtain data from models and simulations, subject matter experts, development testing, operational testing, and legacy system architectures. The data we use are either known (deterministic) or uncertain (stochastic). Chapter 3 describes a number of ways to handle uncertainty. In this chapter, we demonstrate the use of discrete probability elicitations for the constructed scale value measures, SME estimation of triangular distribution parameters, and agent-based simulation output data for the natural scale value measures.

Table 9.4 shows the value measures used for the squad enhancement design example. Additionally, the table indicates the functions and objectives the value measure evaluates, their types, minimal acceptable levels, ideal levels, and type of uncertainty data.

Table 9.5 shows the assault scenario alternative data for each value measure. The value measure data with a single number in the table are deterministic, while the data with a distribution are stochastic; the mean is shown in the upper right corner. The distributions in Table 9.5 are the actual data distributions used in the model. We note the importance in considering the variability rather than relying on the mean only; the input distributions shown in Table 9.5 indicate that there is significant uncertainty in the alternatives' performance. A companion Excel file is provided on the Wiley website for this book.

Table 9.5 Squad Scores on Each Value Measure

9.3.2.9 Resources (Cost)

Systems require a number of resources in order to bring the system into being. The most common type of resource that will generally always be present is cost. Life cycle cost estimation is a challenging endeavor, especially for unprecedented systems. Chapter 4 reviews a number of different cost estimating methods. For the squad enhancement design example, the cost model decomposes the system into cost components that align with the major subsystems of the squad system; this alignment serves as the allocation of cost components to subsystems. The cost components are the soldier sensor, radio, rifle, protective suit, the UAV, and robot. In order to capture the life cycle costs, the model incorporates four types of costs: unit costs, training, maintenance, and disposal. The problem assumes that the deterministic costs are derived from the learning curve, analogy, or the cost estimating relationship methods described in Chapter 4. The component costs that are stochastic are derived from a triangular distribution with parameters elicited from subject matter experts.

9.3.3.1 Value Functions

Value functions show the returns to scale of the value measures. These functions translate the raw value measure data into a scale between 0 and 100 (0 and 1 or 0 and 10 can also be used). The value function range should include the walk-away point or minimal acceptable value, the threshold, the objective, and the ideal values. The shape of the value function is often dictated by the requirements defined by the systems engineer as either a desired capability or a constraint. The constraints are what set the minimal acceptable level or walk-away point, while the desired capabilities help determine the marginally acceptable, target, stretch goal, and meaningful limit levels; see Section 5.3.2. Table 9.6 shows the value functions for the squad enhancement design example.

Table 9.6 Squad Enhancement Design Example Value Functions

9.3.4.1 Total Value

The decision total value can be calculated based on decision, the value measure score, the value functions, and the priorities (swing weights) using the additive value model (see equations (2.1) and (2.2)). One way to understand how each alternative achieves each of the objectives in the value hierarchy is to use a value component chart. Figure 9.4 shows the value components of each alternative as a stacked bar chart. To the right, we see the Ideal alternative that represents the maximum possible value score, derived from the swing weights for each value measure. The Hypothetical Best alternative is the maximum value achieved for each value measure in the set of alternatives. The difference between the Ideal and Hypothetical Best is the value gap that the set of alternatives cannot achieve with existing technologies. Depending on its size, we may want to consider including other new alternatives that close the gap. In addition, we may have an opportunity to combine components from the existing alternatives to create new alternative. When we reconfigure system components to create new alternatives, we must consider the system integration challenges that may result as described earlier in the Technology Maturity uncertainty node section.

9.3.4.2 Total Cost

The total cost value node is the estimated total life cycle cost for each alternative. Because life cycle cost is such an important aspect of any systems decision, we often exclude cost as a value measure and treat it as an independent variable. An effective way to understand the trade-offs between value and cost is to use a Pareto chart. The Pareto chart is a scatter plot with cost on the horizontal axis and value on the vertical axis; each dot represents an alternative's total life cycle cost and total value score. Figure 9.5 shows a deterministic cost versus value Pareto chart using the average costs and value scores from the squad enhancement design example. We used a notional cost spreadsheet model described in Section 9.3.2 to calculate each alternative's life cycle cost. We can see that the Sustainable and Survivable alternatives are deterministically dominated by all the others. It makes no sense to select a dominated alternative when we can select nondominated alternative with a higher value for less cost. The set of nondominated alternatives is known as the Pareto Frontier.

However, Figure 9.5 does not consider the uncertainty associated with each alternative's value and cost and does not show the risk or the probability of a lower value. The majority of value trade-off studies in the literature are deterministic. Eliminating deterministically dominated alternatives without considering risk may lead to the wrong decision. Cost estimation techniques already incorporate uncertainties using Monte Carlo simulations and other methods. A major contribution of our approach is that we simultaneously integrate value trade-off uncertainties and cost uncertainties in order to facilitate better value and risk identification. If we do not consider how much variation there is in the consequences of our decision, we may end up making the wrong decision.

9.3.4.3 Integrated Trade-Off Analysis

The integrated trade-off analysis value node represents our approach that simultaneously models value and cost uncertainties to better identify value and risk. Figure 9.6 illustrates the integrated approach by showing how we use a variety of uncertainty modeling methods to propagate uncertainty through the value and life cycle cost models in order to analyze value and risk. After performing a Monte Carlo simulation, we have a collection of value and cost vector data for each alternative.

When faced with an uncertain system decision, we can leverage three types of analytical charts that help the systems engineer understand the risk associated with a decision and identify what drives the uncertainties in each alternative. First, stochastic Pareto charts identify nonstochastically dominated alternatives with respect to value and cost; second, cdf charts (S-curves) compare the alternative risk profiles; and third, tornado charts identify the value measures and cost components that have the highest impact on the alternative uncertainties. We will now describe each of these charts separately and use the squad enhancement design example to demonstrate the insights we can obtain from them with respect to value and cost.

9.3.4.4 Stochastic Pareto Chart

In order to address the limitations of the deterministic Pareto chart, we create a stochastic Pareto chart, shown in Figure 9.7, by displaying a two-dimensional box plot for each alternative's cost and value. The boxes along each axis represents the second and third quantiles while the lines represent the first and fourth quantiles of the vector output data from the value and cost models. We can create these box plots in Microsoft Excel using a scatter plot with a combination of four data series for each alternative, two for the cost axis and two for the value axis. The lines, otherwise known as whiskers, are created from the vector data using the maximum and minimum data points. The boxes are created using the third quantile, mean, and first quantile; to create the box, increase the line style width of the data series. The box plots allow us to understand the uncertainty associated with each alternative's cost and value simultaneously.

The stochastic Pareto chart allows us to consider value, risk, and dominance simultaneously. In addition, it provides important information for affordability analyses (see Chapter 3). We can see in Figure 9.7 that Sustainable is stochastically dominated by all other alternatives and can be eliminated from consideration. If Performance and Defendable are affordable we then focus on understanding what drives their uncertainty to mitigate risk. If Defendable is not affordable, we then consider either LongRange or Survivable. If we used the deterministic Pareto chart from Figure 9.5 to eliminate the Survivable alternative as a dominated solution, we would have missed an important trade-off consideration. We can see in Figure 9.7 that LongRange has a higher risk in value (probability of lower value) compared to Survivable. We may want to accept a higher cost by choosing Survivable to mitigate the risk associated with LongRange. Of course, an alternative is to choose LongRange to reduce the risk. In order to better understand the risk implications, we can use cdf charts to compare alternative risk profiles.

9.3.4.5 Cumulative Distribution Function (S-Curve) Charts

The cdf chart displays an alternative's potential outcomes by accumulating the area under the outcome's probability mass functions for discrete data and the probability density functions for continuous data. Typically, the shape of the line in the chart is an S-curve that depicts the probability that the outcome will be at or below a given value. The horizontal axis has the outcome scale, either value or cost, while the vertical axis has the probability. Figure 9.8 shows a cdf chart with six S-curves that represent the uncertain alternative value outcomes, otherwise known as the risk profiles. Sustainable is deterministically dominated by the other five alternatives. Attack is deterministically dominated by Survivable, Defendable, and Performance. Survivable is deterministically dominated by Defendable and Performance. The Performance and Defendable alternatives stochastically dominate all others because their S-curves are positioned completely to the right of all others. The risk profiles of Survivable and LongRange value cross indicating that there is no clear winner between the two; we may want to accept a higher cost by choosing Survivable to mitigate the risk associated with LongRange. The cdf chart tells us that there is a 43% chance Survivable will outperform LongRange and that Survivable has less risk due to its steeper risk profile. In general, when the risk profiles of alternatives cross, we then consider risk preference (risk-averse, risk-neutral, or risk-taking) during our system decision. A risk-averse decision would spend more for Survivable to guarantee a higher value, while a risk-taking decision would select LongRange to save money with the risk of achieving less value.

When we want to understand how to best mitigate an alternative's risk, we can use tornado diagrams to identify the value measures and cost components that have the highest impact on value and cost, respectively.

9.3.4.6 Tornado Diagrams

An effective way to identify the impact of uncertainty is to perform sensitivity analysis using tornado diagrams. Tornado diagrams allow us to compare the relative importance of each uncertain input variable with horizontal bars; the longer the bar, the higher the impact on the output variable's variation. The bars are sorted so that the longest bars are at the top; sorting the bars in this way makes the diagram look like a tornado. The length of the bars depends on the type of tornado diagram. Deterministic tornado diagrams vary each input variable using low, base, and high settings while all other input variables are held constant. A stochastic tornado diagram uses the vectors of input and output variable trials from a Monte Carlo simulation (Parnell et al., 2013). The low end of the bar is the average output variable from the subset of trials where the input is less than a specified lower percentile. Similarly, the high end of the bar is the average output variable from the subset of trials where the input is greater than a specified higher percentile. For the squad enhancement design example, we use stochastic tornado diagrams with a low percentile of 0.3 and a high percentile of 0.7. Figure 9.9 shows the value and cost tornado diagrams for the Performance alternative. The input variables for value are the value measures and the input variables for cost are the cost components. The horizontal axis shows each input variable's impact on the total variation for the value and cost. We can see in Figure 9.9 that the LethalMitigation value measure has the highest impact on the value's variation while the Lenses cost component has the highest impact on the cost's variation.

Prior to performing the integrated trade-off analysis, we allocated functions and cost components to subsystems (see Figure 9.3 for an example). Our value hierarchy contains objectives that assess the performance of functions and value measures that define how well an alternative achieves the objectives. As a result, the value measures are indirectly allocated to system features through the objectives and functions. Cost components are generally allocated directly to subsystems. Because of these indirect and direct allocations, we can use tornado diagrams to identify the system features that have the highest impact on the system decision. Figure 9.10 illustrates how we use tornado diagrams to indirectly trace high impact value measures and directly trace cost components to system features.

As we learned from our stochastic Pareto chart and cdf charts, we do not have a clear winner between the Survivable and LongRange alternatives. To help understand how these alternative uncertainties impact the system decision, we can use tornado diagrams to identify the system features that are driving risk.

We can see from the top bar of the tornado diagrams in Figure 9.11 that the radio drives the majority of the risk for the LongRange value while soldier sensor drives the majority of its cost. The protective suit drives the majority of the risk for the Survivable value while the soldier sensor drives the majority of its cost. These subsystems and the system features that characterize them have the highest impact on the system decision. These insights provide a clearer understanding of what drives the alternatives' risk and how to prioritize system feature refinements. For example, the systems engineer can reduce the risk of the LongRange alternative by investing more resources into improving the radio's range, security, and bandwidth features.

9.5.3.1 Random Mode

In this mode, random inputs are generated with built-in Excel generators. This can quickly create interactive Monte Carlo simulations in Excel, in which thousands of trials are run before the user's finger leaves the <Enter> key. Since inputs are produced dynamically by Excel, the resulting output distributions will vary from run to run.

9.5.3.2 SIP Library Mode

Stochastic library mode utilizes precompiled Monte Carlo trials (SIPS) to represent the uncertainty in the model inputs. This guarantees repeatability of results across multiple users and trials and allows results to be aggregated across applications. A SIP Library may be either built into the model workbook or linked to as an external file, for example, in the cloud, so that many users share a common set of trials.

We used the SIP Library Mode for the squad enhancement design example model. This model does contain macros for data manipulation, but the simulation is entirely performed within the Data Table. Within our squad enhancement model, there are three types of uncertain data: simulation output data, elicited discrete probability distributions, and triangular distributions. The model used the INDEX function and the Data Table functionality to generate the random variates for each of the discrete and triangular distributions. We used the SIPmath^TM Modeler Tool Add-in to define cells as inputs for the simulation data SIPs. We defined the cells that needed the discrete and triangular distributions as output cells in order to generate a SIP of random variates from each of these distributions. Finally, we defined the cells that contained the total value scores and life cycle costs for each alternative as outputs to generate their SIPs of random variates. The SIPmath^TM Modeler Tool Add-in uses the Microsoft Excel sparkline feature to display the input and output data distributions within a cell (see Table 9.5 for an example).

9.5.4.1 Triangular and Discrete Probability Distribution Output Creation

Within our model, we have a worksheet named “Uniform Library” that has a collection of columns with 100 trials from a uniform distribution, the 101st row contains the mean, the 102nd row contains the 5th percentile, and the 103rd row contains the 95th percentile. We created these columns using the RAND Excel function and copied and pasted special values; we create a unique named range for each of them in the same way we did for the input distributions. We must ensure that we create the same number of trials for the uniform distributions as we do for the input distributions defined earlier. In another area of our workbook, we have triangular distribution formulas with the minimum, maximum, and mode parameter entry cells for each value measure and cost component that use them. For the discrete probability distributions, we use a probability table that contains a row for each constructed scale category and an ascending cumulative table that adds the probabilities for each category. The VLOOKUP formula has the last parameter set to “True” so that the function looks up the closes matching random number value (between 0 and 1) within the cumulative table and returns the category number. For each distribution, the cell assigned for the random number parameter uses an INDEX function with a named range that represents a unique uniform random number column as the array parameter and the “PM_Index” as the row index parameter. In the “PMTable” worksheet, if we enter 101 as the “PM_Index,” we can show the mean value for all inputs and outputs in our model. For each cell in Figure 9.12 that uses the triangular and discrete distributions, we set them equal to the cells that provide the output for each of the distributions. We then select each cell in the alternative data entry area shown in Figure 9.12, click “Define Outputs” in the SIPmath ribbon, assign the appropriate output named range, and click ok; we should now see sparklines that show the output distributions of the 100 trials of uniform random variates that were passed through each of the triangular and discrete distribution functions. You will now see the output data columns from these distributions in the “PMTable” worksheet.

9.5.4.2 Value and Cost Output Creation

In order to create these output columns, we simple select the cells that contain the value and cost outputs, click the “Define Outputs” in the SIPmath ribbon, and designate the output named ranges. We should now see sparklines for the resulting distributions. Table 9.5 shows a screenshot of the squad model input data entry area with the sparklines for each uncertain input.