Agile requirements gathering

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 thought on “Agile requirements gathering

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 )

Google+ photo

You are commenting using your Google+ 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 )

w

Connecting to %s