Views of Requirements

ArgonDigital - enterprise automation experts

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

b2b auto pay

B2B Auto Pay: Automation Use Cases

Migrating a B2B “Auto Pay” Program Companies migrating to SAP often have daunting challenges to overcome in Accounts Receivable as part of the transition. You might have different divisions running

ArgonDigital | Making Technology a Strategic Advantage