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.
