As we look at architectures and stage 5, maybe one of the questions that you have is why do we really need architectures? You may have heard that term before. It has a lot of different meanings to a lot of different people. But from a systems engineering perspective, we want to be able to have a conceptual model of what the system we're trying to develop. One of the most difficult elements of systems engineering is recognizing that so many people, all the stakeholders, have different points of view. If you look at the different systems here people will look at the system and so many different ways. If you can have conceptual models where you can baseline people and how to view the system, you will be able to more systematically work together as a team. You'll be able to define structure and these architectures, as well as when you have the different elements starting to come into place, you can start defining how do they interact, what type of information gets passed? How might they be laid out physically, and how might they work together to create a capability? This is all really important because in the end, we want to be able to look at these things as a holistic system, complex system, system a system or enterprise system and we want to make logical decisions to figure out what does it do? How do we start dressing gaps? How do we design? How do we move forward to realize this system for operational use? On stage 6, we're going to look at functional analysis and functional allocation. First, let's define what is a function. Oftentimes when we think of a system, we think of its physical instantiation. But one of the critical elements and systems engineering is to define the functions of a system first. We talked about concepts, we talked about architectures. But what we really want to do is start looking at the system definition in terms of functions. Being able to put functions together first allows you to baseline what the system needs to do, which then allows you later to look at different physical options to realize this system. Let's just say for example, we want to monitor a patient, which you'll see number 1 is that these come in the form of a verb noun monitor's the verb, patient is the noun. I'm not telling you how to monitor the patient. I just know that I need to monitor the patient. Let's just say I need to enter data. Verb, noun. I'm not telling you how to enter data. I just know I need to do it. Transfer information, same thing, as well as prescribes treatment. If you could string these together, you could see that we'd have a series of functions where we're monitoring a patient, entering a data, transferring the information, as well as prescribing a treatment. I'm not telling you physically how to do it. That will come later. But if we don't have a baseline function, we won't really know what physical elements are the best fit. You'll see later on as well is that you can put numbers to these. I'm going to monitor the patient how accurately? How quickly? I can start putting numbers to these, which then allows me to have a tradespace to determine what systems, physical systems. My best be the answer to the systems in the state that we realize. Further emphasize the important of functions within the systems engineering process. Here are a few other ideas to let you know why we actually really need to focus on functions first. Many times when people think of a system, they jump immediately to a physical solution. When you jump to have immediate physical solution, you limit the ideas that you bring forward. So let's talk about the system in terms of functions first. It allows you to understand what the system needs to accomplish, not how, but what needs to be accomplished. After that, you can think through what are those fundamental tasks. You can describe those fundamental tasks in that verb, noun construct that we talked about earlier. Now, after you do that, you can start thinking through more creatively what type of physical solutions? Because let's just say we want to enter data. You can enter data in so many different ways. You can do it via keyboard, you can do it via voice, you can maybe do it touchpad, but you can come up with all kinds of different options. But if I would have immediately jump to, I'm going to go on a keyboard and enter data, I would've limited my ideas and creativity for a better solution. Coming up with functions first, it allows you to describe the system functionally. That then allows you to have more creative physical solutions later. On stage 7 of the systems engineering process, we're going to be talking about developing requirements. What I want to make sure is clear is that when we get to this stage 7, we are no longer talking operational requirements. We are talking engineering level requirements. For example, when we started this process here, let's just say we had an operational requirement based on the operational lead, where you want to prescribe a treatment to a patient with 99 percent accuracy within a certain time limit. Very high-level operational metrics. We next want to say, functionally, how might we do this? Number 1, we can monitor a patient. We can enter data, we can transfer the information and we can prescribe a treatment. What we're doing now is instantiating those functions within engineering solutions. But what you'll see is potentially monitoring a patient comes down to how quickly, how accurately, and that plays into the engineering solution. But what you'll find in the end is that that engineering metric that we define here will go towards actually addressing the operational requirements. So don't be confused when we talk about requirements at stage 7, that they're the same as what we talked about in stage 3. We're talking engineering level metrics and requirements that go to support the operational requirements that we talked about earlier. Also, when we talk about requirements, be clear that those requirements mean it is essential that there be there. It's not something we'd like to have or want to have. It's essential to meet this overriding operational requirement that we defined earlier based on the need and the gap.
