Welcome back to CyberRays. It's of course, I'm your instructor. Brad Roads. Let's jump into requirements. Traceability.
In this video, we're going to cover questions about requirements, Traceability.
We're going to talk about the requirements traceability matrix, which is how we track requirements. We're gonna talk about why we should do RTM.
what should be traceable when we talk about requirements? Well, it's kind of like stakeholders, everything. Everything needs to be traceable. Um, if we don't trace everything that we're gonna miss something pretty straightforward,
another question I wanna ask ourselves when we talk about requirements. Traceability is linkages.
Who who's responsible? One for making them and to How do we make sure they're defined? Well, we really have to look at linkages because if we don't, then it's very possible that one module or one part of that system of interest won't actually connected work correctly with another.
So who is responsible for building the requirements? Traceability matrix. Well, it really comes down to,
uh, the systems engineer. They're responsible for the overall system. But when it comes to information systems, security requirements, that's the ISI. The ISI is responsible for that.
When should we and How should we construct in RTM that requirements traceability matrix, which we'll talk about next? Well, it needs to be created, Uh, from the very beginning of this, the design and planning section. That's it. You have to start from the beginning. If you're not tracing from requirements from the beginning, you're going to miss something, and you're gonna try to bolt on requirements.
You get sculpt creeps. It's a big mess.
How do you make a requirement? Traceability matrix. Well, that's up to you. You could do it in a spreadsheet for a simple project you could use Jezeera at last. See in some of those tools you could use Microsoft Project. There's multiple ways to create requirements. Traceability matrix. It's ultimately up to your organization, but regardless of how you do it, you need to make one.
So this is a quick example from NIST, the National Institute of Standards and Technologies. It's a requirements traceability, matrix, and as you can see, you have identify IRS of for testing on one side, and then you have the actual requirements on the top, and so obviously you can
manage those links. However you want to. Ah, good way to build a requirements Traceability matrix
is to use a relational database. That's an easy way to sort of build that out and track linkages from different pieces and components. I've seen that done before, but regardless of how you do it, a requirements traceability matrix allows you to trace requirements and track requirements and keep them in the forefront of your mind as you're developing developing your systems.
So why do we do RTM? Why do we make why do we build a requirements? Traceability matrix? Pretty straightforward We needed for verification. So did we build the right requirements? Validation. Did we build the requirements right? Or did we meet
the mission needed the intent of what we were building and then finally change management. Why will change Management's interesting if we don't do good change management, we have a problem. But if we have not done requirements traceability, how do we know what requirements get updated or tweaked or changed in change management? If we have no idea
what those requirements are linked, Thio
So as you can see requirements, traceability is incredibly important to the ISI.
So in this lesson we talked about questions related to requirements, traceability we reviewed a requirements Traceability matrix. We talked about why you do requirements traceability, matrixes and why you do requirements. Traceability in general. We'll see you next time.