Welcome back to cyber is it's of course I'm your instructor, Brad Roads. Let's talk about context, can offs and requirements documents.
In this lesson in this video, we're gonna cover context What it is, where it comes from. We're gonna talk about Akon ups a concept of operations document. Typically the first thing written when we're building requirements for a system and then we're gonna talk about other requirements, documents that and you will be
required to know is an ISI or provide inputs to or, in the case of one of them, right it.
So context for an organization comes from these five areas. First off is the mission in business. What does the business do? What is its mission? If you're a cybersecurity organization, for example, you're probably gonna be building cybersecurity related products. Probably. You're not gonna be making sponges.
Eso You had to know that the users users could be consumers. They could be operators with any organization system owners, etcetera, etcetera. Users have a huge impact on context and what products and what services are supposed to be. Organizational culture is huge when it comes to system context.
If you have an agile organization that is always on the move and always developing new things,
then that's awesome. That's great, right? If you're in a very static, very risk averse organizational culture, then what you're doing is probably gonna go very slow. If you're fast mover budgets, budgets have a huge impact on on context for organizations. Um, if if you wanna build the greatest, uh,
crock pot and make it a coyote crockpot that's connect to the Internet does amazing things in his
controlled from afar. Wherever you are in the world to make sure your beef roast is ready to go when you get home for dinner. Awesome. If you don't have the budget to build that, you're not actually going to build a build it. And so that's important.
And last but not least, the security security is huge when it comes to context. When we put a system out in the world that is exposed to the Internet or has a hours of service or product that does the same that consumers use. We are as an organization ultimately responsible for
the goods and the bads of that product, and if a security breach happens, that's our responsibility to
another piece of context. This system context, as we talked about previously systems engineering, takes a whole bunch of different systems, elements and modules and puts them together into a system of interest that importantly, operates in a specific operating environment. So
you have to understand the operational environment. You have to understand the elements and the enabling systems that fit into this system and interest,
and then you need to understand that context. So that is your developing security controls. They fit in and don't become a burden.
Next, we have the con ups and you see the graphic on the left hand side of the screen there, and that graphic shows you that we find needs. We find the operational environment would find what supports needed. Ah, lot of times we'll find operational scenarios. This is typically for government systems, always built as the first thing we need to defined.
What is it we want the system or the system of systems to do
you find it in a condoms document. You see this less frequently in the commercial space, However, starting to kind of catch on. We're starting to see organizations frame things earlier, which you might term is a con ups before they even start building them so that they can identify the appropriate requirements and resource is and needs.
There's a whole lot of other requirements documents that you're going to deal with as an issue. But here's the four main ones. First off is the sent the Systems Engineering Master plant. Remember Issues, information systems, security engineer, and that's a nesting under the systems engineer and under the systems engineer, they have toe
plan out how they're gonna integrate all of those system elements to build the system of interest. Well, guess what?
They do that via a simp.
The next thing you see up there is the Q MP, the quality management plan. Why do we have a Q MP? Because if we don't write down what we're gonna do for quality, it doesn't get done. So you have to do that and you actually have to document it.
The next one is something we've talked about quite frequently. Configuration management or change management. The CMP. We need to start that very early in the project of developing a system or service or a product, right? That is where we do it. We start there in the CMP, and we start as early as possible. Changes early are way less expensive,
And then finally, the one that is most important to the issue is the information protection policy or plan. And this comes out of the requirements analysis, looking at potentially harmful events and harmful to information section. So think threats and vulnerabilities that I PP is our major contribution to the overarching systems engineering requirements set.
But these air not all of the requirements documents that you probably should know
A Z we get towards the end of the course. I'm provide you with a specific reference that you should procure. If you're actually really going to study for the ESOP examine, take it on Gittel list a whole bunch more documents, and we'll talk about that later.
In this lesson, we covered the context what it is, obviously lots of things that contribute to context. We also talked about system context and that that system of interest in why that's important. We reviewed that contact with the very first requirements documents written. And then we talked about other requirements, including highlighting that the I P P is the one the issue is most concerned about.
We'll see you next time