This is a question that came up repeatedly in the classes I have taught these past few months.  My answer is always the same: “Any and all models that are needed to define the problem space and derive the requirements.”  The reaction to this is almost always identical: “But I thought we ONLY needed to create User Stories in an Agile environment.”

The first time the question came up (along with my response and the accompanying reaction), I was a little surprised and thought it an anomaly; something unique to the inquirer. But as the question continued to come up, I realized there was a significant problem of both comprehension and perception on this topic.

Model-driven requirements definition is perceived as a methodology created solely for teams using Waterfall development practices. It is perceived to be totally unnecessary and unsuitable for use by Agile teams. To say that I find this distressing would be to put it mildly. Because it is simply not true.

So, let me clarify some things that may be causing confusion once and for all here.

1. Model-driven requirement creation is development methodology agnostic. It is appropriate  no matter what development methodology is used by a team – Waterfall,  Iterative, Agile, Kanban, or any variants of these.

2. ArgonDigital has defined a wide variety of models (over 20 different models) in our practice because no single model can adequately define, capture or describe all the different characteristics of a software solution.
   • The inability of any one model to define all aspects of a system holds true regardless of the development methodology used.
   • Put differently, a model does not become inherently more or less powerful at conveying different aspects of a system simply by switching from Waterfall to Agile or vice versa.
     • A process flow cannot be used to clearly describe object states and transitions just by changing development methodology from Waterfall to Agile.
     • The appropriate model to use to capture object states would be a State Diagram or State Table regardless of development methodology used.
     • The appropriate models to use will be driven by the specific characteristic of the system to be defined, and not by the development methodology.

3. This requirements approach does not impose any limitations on when a specific model or models should be created during the development life cycle.
   • The development methodology used – Agile, Waterfall, Iterative –  will drive when different models are created to support development.
     • Waterfall teams will create all the models they need and derive requirements from them before they begin any development.
     • Agile teams create their models and derive requirements just in time for development.
   • Some models, like the Business Objectives Model which defines the purpose and expected outcomes of a project, will always be done at the start of any project regardless of development methodology.
     • This is common sense.
     • We want to know the business problems to be solved by a solution before we start any project, regardless of development methodology used.

4. User Stories are one of the key models that Agile teams use to describe the software they are building. But there is no reason it should be the ONLY model used by Agile teams.
   • User Stories are very good at describing a chunk of functionality that needs to be built from the perspective of what a potential user of the system hopes to accomplish.
   • However, they are almost useless when it comes to describing all manner of rich functionality that are found in most software solutions, like: Object States, Data Definition, Cardinality of Data Objects, Systems, Interfaces, Process Flows, Complex Decisions, Project Objectives, System Flows, Data Flows and User Interface Definitions; just to name a few.
   • Reiterating a point I made earlier, User Stories do not magically become smart and acquire mystical powers to describe all the different characteristics of a solution just because Agile is used as the development methodology.
     • Anymore than they lose their magical powers of communication if we switch from Agile to Waterfall.

5. ArgonDigital uses model-driven requirements definition because it is the only way that we have found to ensure the following:
   • The CORRECT features are built
   • Only the NECESSARY features are built
   • The CORRECT requirements for any feature are captured
   • Requirements are NOT MISSED
   • Model-driven requirements definition ensures these objectives are met regardless of development methodology used – Waterfall, Iterative or Agile

I hope that I have cleared the air of any confusion around the necessity of using model-driven requirements definition in an Agile world. The unique characteristics of Agile development, such as: constant communication among all team members, continuous delivery of functioning software chunks to users and constant adjustment of development priorities, are NOT a substitute for good model-driven requirement development practices.