Requirements Methodology

If you listen to James Bach enough, you will eventually hear the idea that every practitioner should be able to articulate his strategy and methodology - preferably quickly - and defend it's reasoning. Bach is generally talking about testing, but I'd like to talk about my philosophy on requirements for a bit.

Now, I view software development as craft, so I don't think it is possible to create a "three steps to success" or "requirements in 15 minutes" book or blog post. If you want that, Google for it, you can find it, but I doubt it will be very good. Instead, I will try to create an overall theory on requirements - a work in progress - that should provide the principles and tools to help someone improve his or her skills.

I don't want to tell you what to do; I want to provide tools to help people figure it out for themselves.

Without further ado, here's my elevator speech on requirements:

1) Requirements are hard
2) Requirements are like Othello
3) The goal of requirements (the why) is to create a shared understanding of what will be done by decreasing ambiguity
4) The Requirements work isn't done until the project is done, but the requirements phase can end when both:
A) The team agrees that what they have now is good enough to start real work
B) The Ambiguity Ratio is a price the customer is willing to pay. (In other words, the development staff thinks they can deliver the project in somewhere between six months and three months, and the customer is willing to deal with that uncertainty. If there are not, then there is more work to do.)
5) Requirements are not gathered; they evolve
6) To improve requirements, you need feedback. Faster feedback removes ambiguity more quickly, making requirements get "done" faster.

A few consequences of these ideas ...

1&2 - These say that requirements are a craft that can be honed through repitition - just like skiing or golf. Sure, you can watch a golf instructional video or read a book, but to get good, you have to play golf - a lot. One thing that I think can help is simulations and learning exercises.

3 - If you write a complete, comprehensive, correct requirements doc and throw it in a drawer without team buy-in, you have just wasted an incredible amount of time, and probably killed a tree or two.

4 - Some people expect requirements to be perfect. Others expect them to be vague and fluffy. Some use them to show the customer "look, we did what you said" afterward. Some use them to know what to do during the project - what to develop, what to test. Different people have different expectations, desires, and uses for requirements. Ultimately, the customer has to decide if the requirements are 'good enough'. (Still working on this one; more to come.)

5 - Fred Brooks wrote thirty years ago that we should "Plan to throw one away; you will anyway." What he was trying to do was recommend that we use prototypes to gather feedback into a developing system; otherwise you risk throwing the entire system away. If the requirements are developed in a big-bang, no-feedback, up-front way, it is just as likely that the eventual system is acceptable, but the thing you have to throw away is the requirements document - and that is a formula for all kinds of problems.

5 Again, and 6 - This makes me predisposed toward feedback quickly, using fast requirements techniques like the planning game in extreme programming. Also, the people who will be doing the work need to be involved in the requirement process. (More about that later, perhaps)

PostScript I: Jerry Weinberg has an interesting book on requirements. It doesn't give Pat answers, but instead explores the general concept, helping to develop a craft approach. Mostly, he provides suggestions to experiment with. It's thick and a bit tougher than his usually stuff, but I found it well worth the investment of my time.

PostScript II: I will be giving a short talk on this on March 13th, from 11:00 AM-12:00AM, at Ferris State University in Big Rapids, Michigan, to the local student chapter of the Association of IT Professionals. If you would like to attend, drop me a line.