Welcome back to CyberRays. It's of course I'm your instructor. Red Roads.
Let's talk about functional analysis
in this lesson. We're gonna define functional analysis what it is we're gonna talk about the basic parts and then we're gonna talk real briefly about a functional diagram and what that leads us to.
So functional analysis. Pretty straightforward as an ISI. That's where we take requirements and translate them into the functions and criteria that we need for systems development. And so, from, ah, systems engineering perspective and a system security engineering perspective we're taking and
the requirements and we're putting them into bins and those bins allow us to frame out what the system actually needs to do functionally. And then we create the requirements that we're actually going to test, too.
The basics of functional analysis Pretty straightforward. We look at concepts and alternatives. We want to have different options because not every requirement has to be a technical solution.
We're gonna create those hierarchies of of the framework we're gonna say, OK, this is the starting point of been one and under. Been one we're gonna frame out. Here's the eight different things that need to be done to make sure that function is completed. We're gonna do modeling and decomposition. And this is really important. If we don't
model what we want the system to be as an engineer, then the system isn't going to behave that way.
Same thing with decomposition. We have to take all the tasks and activities on. We have to think like a user. We have to do that. True engineering work to figure out. Are the functions going toe work as designed?
We're going to do both top down design and bottom up verification. And when we do top down design, that means we we say Okay, as a top level down to the next sub level, sub level sub level. What does the system need to do? And then we're going to stop and we're gonna put on our
builder hat, our engineer hat. We're gonna work our way back up to the top to see if that makes sense. Ultimately, we're breaking down higher functions in tow, lower level functionalities to ensure that all the components are allocated to functions.
So here's a functional diagram, and as you can see, it's pretty straightforward. It's really not rocket sciences. Here's our top level function. We have sub functions, and then we have sub sub functions that allow us to map out what needs to be completed to ensure a function which is usually a complex piece or module of a system gets done. So what are we really building here?
We're really building the work breakdown structure for a system
so that we could actually take these functions and these different requirements and hand them to a builder, a developer, and they could build it. And ultimately, what is the WBS? It is our product oriented description of items, of things, of stuff that needs to be built, whether it's for the system engineers
or for the information systems, security engineers
or whatever specialty engineering needs to occur to ensure the function of a system in this particular case.
So in this video we talked about functional analysis, we defined it. We looked at the basics of a functional analysis and we talked about the creation of a functional diagram which is actually leading us down the road of creating something we call a work breakdown structure. And if you don't know what if you're not really comfortable with what A W B s is a work breakdown structure
probably ought to do some digging on that as you prep for the SF exam.