Views of Requirements

Share This Post

There is an architectural pattern in software engineering known as Model-View-Controller. This pattern suggests (among other things) the separation of data (Model) from the display of that data (View). The reason for this distinction is that there may be many different ways to display data in a way that is useful for the consumer of the data. An accountant may want to view financial data in a table, while executive management might prefer a pie chart.

There is a similar pattern that we can apply to requirements. At the risk of overloading terms, Requirements (data) have different Models (display of data). The models that we use are basically ways of displaying data to the consumer of that data. A tester may be interested in a long list of “System shall…” statements, because each statement gives them an opportunity to write a test. A system architect may be more interested in Swim-Lane Diagrams because they highlight the interfaces between systems. A business user may be most interested in Use Cases because they allow a review of how they use the system. A GUI designer may be interested in Click-Action-Response Tables since they specify how some elements of the user interface interact. The Models aren’t the requirements, they are a “View” of the requirements.

More To Explore

Email in toolbar

Getting More out of Transactional Emails

Are you taking advantage of all of the opportunities to promote your brand? Emails are great way to interact with your customers, and both marketing and transactional emails can be

Visuals in Requirements Mapping

In Praise of Requirements Mapping

Learn how to tie software requirements together with visual models and other artifacts created during the analysis process.