Agile requirements gathering

January 5, 2010

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. (…) The goal is to understand the requirements at a high-level, it isn’t to create a detailed requirements specification early in the lifecycle, a traditional practice referred to as “Big Requirements Up Front” (BRUF) which proves to be very risky in practice. Traditional theory is that BRUF is a best practice, but experience shows otherwise. 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 any investment in detailed documentation early in the project will be wasted when the requirements inevitably change.

Scott W. Ambler

http://www.agilemodeling.com/essays/agileRequirements.htm
http://www.agilemodeling.com/essays/initialRequirementsModeling.htm#UsageModel
http://www.agilemodeling.com/essays/initialArchitectureModeling.htm

Advertisements

One Response to “Agile requirements gathering”


  1. Interesting; have u seen Maiden’s comments on the downsides of Agile Requirements tending to focus on Functional, rather than non-Functional requirements? There’s not time to specify abstracts??


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s