Agile Requirements Modeling

Agile Requirements Modeling
Scott W. Ambler

Agile Modeling Many traditional project teams run into trouble when they try to define all of the requirements up front, often the result of a misguided idea that developers will actually read and follow what the requirements document contains.   The reality is that the requirements document is usually insufficient, regardless of how much effort goes into it, the requirements change anyway, and the developers eventually end up going directly to their stakeholders for information anyway (or they simply guess what their stakeholders meant).   Agilists know that if they have the ability to elicit detailed requirements up front then they can also do the same when they actually need the information.   They also know that any investment in detailed documentation early in the project will be wasted when the requirements inevitably change.   Agilists choose to not waste time early in the project writing detailed requirements documents because they know that this is a very poor way to work.


Table of Contents

  1. Agile requirements modeling in a nutshell
  2. Where do requirements come from?  
  3. Best practices
  4. Types of requirements
  5. Potential requirements artifacts
  6. Techniques for eliciting requirements
  7. Common requirements modeling challenges  
  8. Agile requirements change management


1. Agile Requirements Modeling in a Nutshell

Figure 1 depicts the Agile Model Driven Development (AMDD) lifecycle, which depicts how Agile Modeling (AM) is applied by agile software development teams.   The critical aspects which we're concerned about right now are initial requirements modeling, iteration modeling, and model storming.   The fundamental idea is that you do just barely enough modeling at the beginning of the project to understand the requirements for your system at a high level, then you gather the details as you need to on a just-in-time (JIT) basis.



Figure 1. The... [continues]

Read full essay