Welcome back to CyberRays. It's of course, I'm your instructor. Brad Roads. Let's jump into stakeholder requirements.
So this ah lesson, this video is gonna cover stakeholders on the types of requirements that we have to deal with as he sees
stakeholders. So we talked a little bit about what stakeholders are. They could be, what anyone on din fact there anyone who perceives
they are affected by the system or products. So that's a pretty wide variety of people.
Um, but in general, there's five types of stakeholders I want you to remember. One is users and consumers. They're kind of a big stakeholder. If you build a system that doesn't meet their needs, they're not gonna use it or they're gonna work around it, and that's never a good place to be.
Another one is shareholders. Um, those air folks in publicly traded companies that own stock or own a portion of the company, they drive things in my regular job. I work for a board and their share, their basically stakeholder shareholders, and they have a lot of say in the direction of our organization where we go, so you have to be cautious about them
business executives. Thus, C suite. The all knowing, all powerful C suite. You need to understand that executives and your organization or stakeholders whether they are someone you work for, directly or not, they believe that they have importance and you need to listen to them.
Of course, organizational departments themselves to remember our three chair model of the organization and then the mission and business processes. And then, obviously the systems well, in the mission slash business areas, right, close your organizational departments. Maybe that's finance or I T. Or Cyber security or admin will you name it?
All of those folks have requirements and needs that you need to understand.
And then the one up here that I don't want you to forget about his government regulators and also those NGOs, non governmental organizations think like certifying bodies. Like, say, an I T. Or something like that. Those organizations have a direct impact in your systems. If you don't follow regulations and you can't operate your system, then maybe you're not making any money, and that's a bad thing.
So there are six requirement types. The first one is business.
Uh, you need to build systems that meet some sort of business need. If you're building a system that doesn't meet a business need or assailable product, probably wanna ask yourself why it's being built.
You obviously get requirements from stakeholders. We talked about them already, and those requirements can be really, really awesome and great. And sometimes those requirements, you're just going to scratch your head up.
You can have solution requirements, and those could be technical or nontechnical. Remember, we've talked about this. These are the champions of simple and being the champion of simple means that sometimes a non technical of policy or procedure, maybe is the thing that answers the question versus having to spend a lot of money on a technical solution
requirements or related to transition. We bring systems in tow, operations and maintenance and then dispose of them all the time. And we have to understand that as part of the life cycle of a system as a information systems security engineer, projects and products and capabilities air going to transition.
Obviously there may be project overhead. Those those types of requirements are tied to like, you know, reports and everything like that, and tracking resource uses all that stuff that's those air project requirements. And then finally, and last but not least, we have quality requirements. If you are not building to quality or building quality capabilities or quality systems,
we're probably going to be used
on if they're not gonna be used again saying back to the same thing we talked about for you might not be making any money or you might not be having a job because you didn't build to quality. So those requirements and so these are the six sort of general over arching requirements you need to pay attention to as an ISI when you're doing, ah, system design and planning.
So in this lesson, we reviewed stakeholders as it relates to systems, requirements and planning. And we talked about the requirements types and where they come from.
We'll see you next time.