Why should you use requirement models? Isn’t it faster to just start listing the functional requirements? In this post I’ll explain why you shouldn’t do that – and why requirement models are so powerful.

Provide Context
You cannot pick up a list of 500 system shall statements and quickly get a grasp of what the system needs to do. Higher level models, such as System Context Diagrams, Entity Relationship Diagrams, Process Flows, and Organizational Charts are great ways to understand the complete picture. Other models can provide important contextual reference for developers, testers, and others that need to consume the requirements (Use Cases are great for doing this).

Help Derive Requirements
Models can help you generate requirements quicker than you could than without them. Use Cases are a great example of this – once you’ve generated the series of interactions, it is relatively easy to examine each step and ask the question “what does the system need to do to support this step?” Likewise, you can examine interfaces within a System Context Diagram and start thinking about what requirements are necessary to support them.

Prevent Missing Requirements
Going back to the proverbial list of 500 system shall statements – it is nearly impossible to look at a list like that and determine if anything is missing. There’s a post here that describes this in more detail.

Easy to Utilize
Most models are easy to read and use. If you’ve ever had difficulty getting stakeholders or end users to review your 200-page document (and who doesn’t love to read those!?), consider leveraging models to shorten the review time. It’s a lot easier for someone to validate requirements while using a Process Flow or Use Case than it is without them.

So avoid the temptation to jump straight into the requirements – your requirements will be more complete, have more context, and will make it easier for others to validate and use your requirements.