Often, business analysts see visual models as a discrete part of the requirements process. At some point they’ll create the visual models, and then they will file them away in a section of the requirements document that will never be looked at again. Sometimes, they are completed after the requirements have already been completed, as a sort of instruction manual for them.
What we propose is something different entirely. The visual models are meant to be used every step of the way. They should be the first thing you create and the requirements should never be elicited or reviewed without them. From the start, consider them as permanently attached to the requirements, whenever you show one, show the other as well.
In order to do this, traceability cannot be an afterthought. It needs to be built into the requirements from the beginning. Every time a new requirement is written, add the models it traces to. Every time a new model is created, add that traceability to existing requirements. This is the only way you’ll know which models to show with which requirements.
If you encounter a functional requirement that doesn’t trace to a model, you know you have a problem. Either the requirement is out of scope, or you need to create a new model. If you don’t do this, you run the danger of having system functions that aren’t modeled, and that puts your requirements at risk of being incomplete and not properly understood by users.
You will never stop needing context and categorization for your requirements, no matter what your’re using them for. That is what the models provide, and why you need to leverage them throughout every stage of the software development lifecycle. Since you already put in the time and effort to create them, use them for all they’re worth. Treat them not as an afterthought, or a step that your boss is making you do, but as central to all your requirements gathering efforts from beginning to end.
