# 9 - Quantitative Methods in Systems Engineering

I'd like to discuss a little bit why we use methods and models. Throughout the lifecycle, methods and models are used for multiple purposes. Some of the types of decisions that we might make are defining the problem or opportunity space, deciding on concept architectures, and making trade off decisions.

So what is trade off analysis?

Well, it's a decision making activity, and it's for the purpose of selecting from alternative solutions on the basis of the benefit to the overall system and its stakeholders.

So examples of the types of methods are decision matrix methods that let you compare alternatives in a fairly simple way, trade study method, which adds a bit more formality to this, and then trade space exploration methods, which allows you to explore the whole solution space. Trade studies for us is looking at how we can balance cost, performance, schedule, and even risk. It's gathering all that information and looking at those alternatives, and then coming up with what we feel is the best solution for the stakeholders.

So what are the basics of formal trade off analysis? One is first to define the process that you're going to use. And second to define your objective for the study. And importantly, to define the criteria before you identify alternatives. Once you identify alternatives, you compare these and then perform sensitivity analysis to see what types of particular attributes are really driving your decisions.

Next, you want to document your recommendations, the results, and the rationale. And most importantly, to communicate those results clearly with all of the others who need to have that information.

So why are trade-offs necessary? Well, there are always limitations that face us, say, around resources, time, money, space. We have to balance different multiple stakeholder needs. There may be physical or practical limitations that needed to be traded off. Some of the example trade-offs that you'll see out there are cost schedule, cost benefit, capability and affordability.

And so what you're doing is you're really revealing the critical system issues by stripping away the properties that are not your immediate concern.

In trade off analysis, there are various types of models that can be used. A common classification is schematic models, math models, and physical models.

- Schematic models may be graphical or conceptual. They help you to understand the overall context. And they're really useful for communicating with others.

- Math models can help you to understand relationships and dependencies, and of course, they help you to model functionality performance and behavior.

- Physical models can give you that more realistic feeling in your trade off analysis and they can aid with validation.

So to sum up, methods and models are highly useful throughout our whole lifecycle. We can advocate using all different types of models in trade off analysis from schematic, to math, to physical. And finally to remember that in trade off analysis you're getting a lot of information. It's important to not only document this but to really go out there to communicate it so that your entire team understands what these models are telling you.

Tradespace Exploration

Let's start off by talking about a decision problem that many of us face in our lives. Perhaps we're entering a new phase of our life and we're trying to figure out where we should live. One option is to choose an easy solution. At my parents' house. I can live with them. It's free. Or is it? Thinking more deeply about this, I realize that even though I may not be paying any dollars to live with my parents, it's actually quite stressful to live with them. This brings up an important point. That is when we think about the cost of our alternatives, there are often multi-criteria.

In this particular case, the cost is more than just dollars. It includes stress. Perhaps instead I want to consider a different alternative. Maybe I want to buy a new house. Well, in considering a new house, that's going to be quite pricey. You have to pay a lot, but it's not going to be stressful. But I care about more than just cost. I care about the benefit as well. Why would I pay a lot of money to have a new house unless I was going to get something for it? In this particular case, I want to buy a new house because I want to have a nice, large place to live. I don't want to live in my old bedroom any longer.

I also care about how far I have to commute to work. It turns out my parents' house is pretty far away. In this case, just like cost, benefit is a multi-criteria consideration that I care about. I care about my commute distance. I care about my comfort. I care about the noise of my neighbors. In this example, living with my parents is a low cost, also low benefit alternative. It's far from work. And buying a new house is a high benefit, high cost solution. 

This brings up an important aspect of decision problems. When we propose multiple alternatives, we often discover there are trade-offs among the different criteria we care about, considering how they fall between benefit and costs. Now we can identify patterns. There are two key types of alternatives in this representation. We have the Pareto front, which are our most efficient benefit and cost alternatives. And we have the dominated alternatives. Those that are not on the Pareto front. These are the solutions that are inferior in terms of benefit or cost as compared to other alternatives. The Pareto front represents the highest benefit for a given cost or the lowest cost for a given benefit alternatives. These solutions are the ones that exhibit the core trade-offs that we're going to have to consider when deciding which alternative we like the best. Another thing we can consider in this representation are budget constraints. These represent the maximum we're willing to pay in terms of cost for picking an alternative. We represent this as a vertical line in a benefit-cost tradespace representation. Anything higher than the budget constraint is deemed infeasible and no alternatives there are attractive. Below the budget constraint, these alternatives are feasible and are potentially good solutions. Additionally, we can think about desires constraints on the benefit axis. These might specify minimum acceptable levels for things like square footage or commute time. In this example, anything below the desires constraint would be deemed infeasible. And anything above that would be deemed feasible, potentially attractive. In this representation, we can see there's a quadrant that's leftover of acceptable and attractive alternatives, but there's still a trade-off that exists on that Pareto front.

Picking a particular alternative along with Pareto front is a subjective judgment call that the decision-maker needs to make. There's no right answer, at least in this representation. In this example, a shared condo is the higher benefit, higher cost alternative that I decided to go with. Now, even for this very simple problem, using this representation was a very powerful way of thinking about a structured means for solving our decision problems. That is, in general, we define a problem. We derive criteria. We propose alternatives. We evaluate those alternatives. And then we assess those alternatives in terms of whether they meet our constraints and whether there are good enough solutions in there that I'm willing to select one and walk away. The objectives and goals can be derived into criteria for evaluation. These are particular metrics that we're going to evaluate using different modeling and simulation techniques, and/or other means for generating data. We often call these attributes as an operationalization of criteria that represent value.

What's the miles per gallon for my car? We use these value criteria to propose possible solutions. For example, where should I live in the prior example? Or what type of car should I buy? There are many different ways of generating alternatives. One particular consideration is the number of alternatives we generate. We can look at one. Perhaps that's a good solution. We can look at a few, which begin to give us some insight into different trade offs that might exist. Or we can look at many possible solutions where we could begin to see the trade space amongst the many criteria that we care about. The value proposition that we're trying to evaluate, such as where should I live, may actually change over time or be context dependent. Having a structured framework for considering these things allows us to deal with that extra complexity. Additionally, we can get deeper insights into the relationship between what I want and what I can actually get. One of the techniques is multi-attribute tradespace exploration, which is a structured framework for thinking through a decision problem and proposing solutions. It allows us to look at a large number of alternatives and understand the relationship between different values I might have and what I might be able to achieve technically. Additionally, it provides a very useful mechanism for communicating among different stakeholders to identify trade-offs between what people ask for and what's technically feasible.