Page 6 of the systems engineering approach is functional analysis and functional allocation. I emphasized in the last module the importance of functions because what you don't want to do when you come into a problem statement is immediately jump to a physical solution, because that greatly restricts your options. What you first want to do is look at the problem from a functional perspective. Give a description, give a narrative to the problem, describe functionally what needs to happen, what needs to be accomplished. Don't tell me how to accomplish what needs to be accomplished, what functions. Understand the fundamental task, what are you trying to do. Don't immediately say, "This is the answer." Try to understand what the problem is, and then when you do that, you create functions that allow you to come up with some creative solutions. Remember last module, we talked about different ways to implement a specific data entry: keyboard, voice, touchpad, whatever, you don't have to have a specific physical solution, come up with creative ways. Now remember, what we talked about as well, we talked about needs, requirements, gaps, we just talked about concept and architectures. When we talk about functions, we're able to now describe the problem narratively. You'll see in just a moment here how we go down this process and eventually end up with functions, and those functions eventually allow us to describe things quantitatively. Not only how, but how well. That sets the stage for requirements and design. Further looking at functions and the functional allocation analysis, let's see where we've been and then see how we get to functions. If you recall, at the very beginning we talked about a need. We said the needs are in a narrative form. We don't give quantitative measures at this point. Let's just say I need to describe a treatment for cancer patients, we then say, "Okay, let's put some numbers to that. What is the operational requirement?" Maybe I need to get the right treatment with a certain level of accuracy within a certain timeline. Let's just say, "I know what I can do, but now I have a gap." How do we address that gap? Remember, the first thing we talked about is, let's come up with some concepts. We did some brainstorming for the context of an ICU. Now maybe those ideas can be put in some type of architecture form. Remember, we want to be able to structure this, show how they interact, show some of the activities. Here's some ideas just to get the ball rolling, but eventually we want to get to the point where we create functions. Remember, functions come in the form of a verb-noun. First of all, when we want to prescribe, probably the first thing we do is monitor a patient. I'm not telling you how to do it, but we'll monitor it. Eventually, we will be entering data, verb-noun format. We're going to be transferring and transitioning that information somewhere, and eventually we're going to prescribe a treatment. What's interesting to note here is that concepts, architectures, and functions, they are going to iterate. You may change your functions, you may change your concepts, you may change your architectures, so don't view this as a linear sequence here. You may in some cases even say, "Hey, I have some gaps. Let's functionally figure out what happens." Eventually I'll come up with concepts and architectures. This is an iterative process here, but eventually, what you're going to do as you sprinkle these through and iterate on these, that's where you're going to start refining and defining your requirements, which is the next stage. In the previous slide, I'd mentioned the next step, stage 7 is developing requirements. If you recall, we looked at functions, we looked at concept, and we looked at architectures. Those blended together and iterated on, allow us to start refining what our requirements are. Remember the confusing part might be, requirements start at the beginning, but we emphasize them now because now we're in the midst of the design. You will have early on operational requirements, you have functional requirements as well as performance. We're also getting now into the idea of performance and the physical and the interface requirements. Remember we talked interfaces later after the design. All these folks here have requirements. Don't be confused that it just occurs at one stage, they occur through the entire process, they're just different types of requirements. What's important that you need to understand is that as you go down this process here, the requirements hang together. You'll see in the next slide an example of that. Also, what you want to be able to do is, once you're done at the very bottom, if you design, you want to be able to trace back up and say, "I made this decision in this design decision, because in the end as I trace it up, it addresses that operational need." When you do these design requirements, make sure that they perform balanced allocations, is showing integrated design, don't over-emphasize something, it is a balanced design. Coordinate with everybody. Remember, cost is an issue here. When you start developing requirements, you can have the greatest piece of equipment, but if it cost way too much, no one's ever going to get it. I commented earlier, you want to be able to show traceability, defend, why did you choose what you chose? I can show that because I can trace it up here and show you how it's an operational need. Then also when you do it this way, there's a structured approach. It is not just hap hazard analysis, we are very clear and very structured why we built these requirements.
