SessionFive023

An Amateur's Guide to Communicating Requirements

Presenter: Brian Marick

Request from Brian Marick

I'll need about 1/3 of the people in the morning session of "An Amateur's Guide to Communicating Requirements" to volunteer to demonstrate some skill to other people. It might be a card trick, a coin trick, origami, building a house of cards, juggling, situps, headstands, or flipping pancakes over in a skillet. It's best if the skill involves some object, so this is a plea for you to bring that object. Thanks.

We're all familiar with traditional requirements gathering: interview and observe a subset of users, then try to write clear, unambiguous, complete, and testable statements of their requirements. Many of us have tried hard to do that and failed. From that, some of us conclude that we should try harder and smarter. I conclude that the whole idea is broken. You not only can't write precise statements in /here/ that represent the world out /there/, you can't even come close enough.

In this session, I hope to convince you that my claim is at least plausible. The next question is: "And then what?" We'll start to explore ways of putting ourselves in situations where we can create better systems without being able to specify requirements.

Learning objectives
- Flaws with the default model.
- At least one technique that doesn't depend on the default model.
- The merits of practice vs. observation.

At least six people. Max 15?

Equipment: small tables that people can cluster around, or the long rectangular tables (where each group of three can surround an end). Lots of flipcharts and such supplies.

ProgramScheduleAndSessions2005

Updated: Thursday, November 3, 2005