Another item that we'll look at in stage three is the idea of what a need is. If you look at this definition here, a need is a gap. You currently perform a function and activity, but there's a gap in what you need done. What you're doing with a need is creating a general description of what is needed. An understanding of what the shortcomings are and the narrative format. What's important to know is you are not deriving a solution yet. You're just simply saying what I need, and recognize at this point in the systems engineering approach, you're not putting any quantitative measures. We'll do that in the next stage, but what you're doing is simply putting a narrative form to saying what I need. That is, what I do now, I need to do this, what is that narrative description? And finally, what you'll need to understand is that a need is not a want. You may want something, but you need to understand the drivers of your problem and understand what you really need and not what you want. In this final part of stage three, we will talk about requirements. If you recall, in this stage three, the first thing we talked about was the scope. What is the baseline of the system? Next, we talked about, what are the needs of the system? That is we have a problem. We have a gap. What are those needs in a narrative form? What we're now doing, is now taking those needs and putting them in a quantitative expression. So they must derive directly from the needs. Let's say you need to get medication to a patient. We're now going to say, I need to get medication to a patient within three hours, or I need to get medication to a patient within ten minutes. You are now putting quantitative measures. It's going to be a task, but what you want to understand is this is not an engineering metric. What I mean by that is, I'm simply saying I need to get medication to a patient and a certain amount of time. I'm not telling you how I'm going to do it. I'm not telling you how I'm going to put a drone in there and deliver to them and some type of engineering format. I'm just telling you, I need to get it to the patient in a certain amount of time. In what you saw is that I'm describing a solution. I'm not saying how I'm going to do it, I just say I need to do it in the certain amount of time in this case. And always remember, when you have a requirement, it's not a want, what do you actually need to solve the problem? And what type of measures are required to solve that problem? In this next part, stage four, we're going to talk about concept exploration. What's important to know when we look at concept exploration, we are taking the information from the previous stage. That is the problem, scope and baseline. The needs as well as the requirements, and then trying to figure out what type of concepts can address the requirements that we push forward. As an example, let's just say we have an operational need to get more timely access to a ventilator system in an ICU. That's the narrative, we put some numbers on that. Now let's just say we need access to the ventilator PEEP settings within three seconds. This is just a notional example, but you can see we put quantitative measures on there. Next, you can see maybe we get it in ten seconds now, but we have a gap of seven seconds. So, what concepts can we look at in order to close that gap from ten seconds to three seconds? And that's what we'll talk about next. As we look at stage four of concept exploration, there are so many different ways to explore concepts through modeling and mock up of specific areas. Just as a few examples, let's just say you're trying to come up with a concept for a process or maybe within an ICU. You can make some model mock up of an ICU, run through these various tasks. And just get a sense potentially, of how you might explore building a different ICU, just by simple modeling. However, maybe there's an, within the context of an ICU, you're trying to just figure out the physical footprint, where might things fit within an ICU. So you don't have to build the full functionality and the different elements that go into an ICU. You can just have a physical mock up to see physically how things are put together. But as the example they were looking at earlier, that is maybe we're actually trying to look at maybe some human machine interface. And get the access to a ventilator that we talked about earlier, down by seven seconds because that's the gap. We can come up with some type of human machine interface mock up to explore concepts, to see if we can actually address that gap. So there are a number of ways that you can explore these concepts in the systems engineering process. One of the critical stages and element within the system engineering process is developing architectures. So think about where we've been. We've identified the scope. We've identified needs, requirements, gaps. We looked at concepts, but now what we need to do is put those concepts based on the needs and requirements into some structure, because without structure, it's hard to understand how all the elements interact. So the idea of an architecture allows you to develop conceptual models that define structure behavior of the system, or in our case complex system, system of system or enterprise system. We're trying to think through and take a holistic view of all the elements within our system, system of system or enterprise system, so we understand how they interact and how they might interconnect and structure. We'll learn more in the next module the details of how to put our architectures together or healthcare system. But recognize that absence architecture, we don't start developing an integrated view of the problem that we're to solve.
