Import Requirements from Microsoft Word into Simulink | AUV Deep Dive, Part 1

So, in our autonomous underwater vehicle demo, we've been starting with this document of requirements for our system. And we import these requirements into Simulink so that we can make sure that we're actually meeting them as we design our models. And ensure that we're maintaining a digital thread throughout the entire process. So in this video, we're going to walk through the process of actually taking these requirements, importing them into Simulink, and what that looks like.

Our requirements are in Word, as you can see. So in this video, we're showing that process. But you could also do this for other requirements management tools like DOORS^® So here I just have a blank architecture model. And say that this is the model that I want to import my requirements into, and I'm going to start drawing out in architecture and starting to link things. So what I could do here is I'll come over to my apps tab. And I'll click requirements manager.

So it's going to open up a new set of buttons for me in this requirements view down here that we call "requirements perspective." So I'll import my requirements with this Import button here. And I just have a few options to select, so I can pick different document types. Here I'm using Word, but here some of the other options that we have for importing requirements. And I just have to choose which Word document I want to import.

And then it's going to give me some options. In this case, I used bookmarks in my work document to signify what my different requirements were. And how I want them imported. And names. But you could also-- there's a few other options here for how you actually get that information into Simulink requirements. And also important, I'm going to check here to allow updates from an external source. This means that, as I update my Word document, and my Simulink requirements that I've imported, become kind of out of date because the Word document has been updated. Simulink requirements will flag that let me know, and help me update my requirements accordingly. So I'm always working with the latest and greatest requirements.

So I'll click Import. It's going to go through my document and import those requirements into Simulink. So you can see now, if I open up my requirements perspective here. Make it a little bigger. And do some resizing of my rows. You can see they actually have a whole set of requirements imported. I'll make this even bigger. I've got my different sections that you saw in that Word document before for the different things that my AUV is going to need to do.

I can drill down to lower and lower levels, and eventually just start looking at some of these requirements. And eventually linking them to pieces of my architecture. When I imported this, worth noting that it generated a couple of files for me here. So this requirements file, that actually stores the information, and once I save my model it's going to generate a links file. So it can keep track of when I actually start linking elements of my model to these different requirements. It'll help me keep track of where those links are, and if they're up to date.

So let's see how we'd actually start linking some of these requirements to components. I'll give myself some room here. And say, in my "Untitled Architecture," I'm just going to bring in a placeholder

component, but you could think of this as actual components of our architecture that we'd be building up. You can then drag and drop from our requirements perspective here onto our component.

Before I do that, I want to add a couple of columns to my view here. So I come here, I want to show my implementation status. And also my verification status. Change my sizing a bit here. So these bars are going to help us tell if all of our requirements have actually been linked to different components, whether it's in this architecture model, another one, a Simulink model. And it's also going to help us check if those requirements have been linked to test cases. And if they've been run, and therefore verified whether they pass or fail.

So, for example here, if I pick this estimate pose requirement. I can just click it, drag it, drop it on to my component. It's linked now you can see that I've got a little requirements icon here. And it's saying this block implements this requirement. You can also see that my implementation bar just jumped up here. So this requirement is now fully implemented because I've attached it to something.

But if we take a look, these bars are kind of cumulative. So if I look at my very top bar of all my requirements, you can see it's just a tiny, tiny amount implemented. Just one implemented. And I haven't done anything with the other 34. So that helps me keep track of my progress as I go of how many of my requirements have been implemented or not. All right, so let's skip ahead to see what this looks like towards the end.

So if I zoom into this requirements perspective here, you can see I have my same set of requirements. But now I have a far more fleshed out architecture model. I have Simulink models that are linked to this architecture. And you can tell because I now have some colors in my verified column that have not only implemented all my requirements, and linked them to pieces, but I've also linked all of them to test cases. And I've run those test cases and can see almost everything passed, but one thing failed. So being able to bring in our requirements and attach them to all these different kinds of model components, like architecture, simulations, tests, and even generated code. It really helps us create that digital thread and maintain traceability throughout the entire model-based design process.