UXD » We Don’t Need No Stinkin’ Requirements

We Don’t Need No Stinkin’ Requirements

Alice Toth, Thursday, August 30, 2007 @ 11:52 am

The other day I was reviewing a statement of work for a potential project when the client came to the line item allocating time for requirements. Oh, the client stated, we don't need to gather requirements. We do Agile development.

*Sigh* This myth of no requirements needed seems to be prevalent lately.

Well I hate to break the myth, but projects still need requirements regardless of the method used for development. The reality is you can’t create something unless you know what it needs to do. In order to know what it needs to do, you need requirements (business, technical and user).

The differences come in with the methods for gathering requirements. Some teams make requirements gathering the central activity, creating documentation detailing everything down to the nth degree before development begins. Other teams put less emphasis on knowing all beforehand and instead start with sketches or three sentence "stories", knowing that details will be filled in and added as the project progresses. Side note: make sure you have some way of documenting those hallway conversations because, yes, those are actually requirements gathering and it's good to keep a record somewhere accessible by the project team.

At the most basic level, the purpose of requirements is to define the problem you're trying to solve. Whether your team waits for a complete definition of the problem before starting development or starts with the basic outline depends on your development method. But you still need requirements. After all, if you don't define the problem, how do you know when you’ve solved it.

Not sure how to write requirements? Check out my colleague's post: Writing Requirements

Topics: Requirements Alice Toth, Requirements

user experience design

Comments: 3 so far

Correct me if I’m wrong, but one of the things I remember about Agile Developement is the fact that REQUIREMENTS for the project are written, but the difference is that they are more loose and informal AND basically are not that precise (the developement is done in iterations no longer than 3 months and above those 3 months no planning is made, it is argumented by the fact that financial market as well as other factors to consider change and going beyond that time frame may lead to maladjustment with the status quo which changed during that time.

Comment by mojojojo_, Friday, September 7, 2007 @ 12:15 am
No requirements? A consultants dream! Where do I sign up?

Davo

Comment by David, Friday, September 7, 2007 @ 11:08 am
mojojojo: Yes, requirements in the Agile process are much more loose and informal than in, say, a waterfall process. Think of them as “just enough” requirements. And I’ve been on teams where the iterations are of two-week durations with a *release* being 4 iterations or 2 months. Once the Agile process is adapted to the team (or vice versa), I think the process works very well. You just have to be comfortable with not knowing everything about everything.

Davo: I believe we call that a grad school project.

Comment by Anonymous, Sunday, September 9, 2007 @ 11:20 pm