Leaving technology out of requirements gathering

I'm going to suggest a minimal way to gather requirements, one that produces a (minimum) requirements document in an iterative and agile manner.

A little background

In the systems space, it is common to write up a "requirements document" that attempts to capture all of the business requirements for a system.  Doing so, of course, is a great example of BDUF and this runs into the YAGNI concept rather forcefully.  My gut tells me to minimize these works of fiction, and to produce them in an automated and repeatable way.

But what drives the creation of these things anyway?  let's look at that question.

The problem with a requirements document is that we don't have a good practice, as an industry, for putting ONLY IMPORTANT STUFF into the requirements document.  We spend a lot of time collecting, and documenting, requirements, when most of the words in the document are not requirements. 

Let's focus on what matters.  Requirements should create an agreement between business and IT, describing the "things that technical people need to know" in order to assist in problem solving and empowering business change.

So, what do technical people need to know?  I did a little browsing on the idea, focusing on BPM tools (because I'm looking at BPM concerns these days).  I ran across Shaji Sethu's site along the way. He shares a mind map of technologies and features for Business Process Management (BPM) that he uses when collecting business and technical requirements.  This approach is not dissimilar from the one taken on the Savvion site, where you can find a list of features to consider for BPM tools. (see link here).

If you follow these ideas, and ask about a long list of features, and ask about various technologies, what will you get?  Will you create an environment where the business describes the minimum amount of information needed to share the things that technical people need to know?

Or will you create a situation where the business feels like they are being asked to decide on technical details and features?  And if you ask the business to make technical decisions, is that appropriate?  Are you allowing the IT department the flexibility that they need?  Are you asking the business to become expert at things that they don't, or shouldn't, care about?

An alternative approach to requirements gathering

Based on the notion of model driven development, I'd like to automatically generate a simple document that provides information in a document that is auto-generated out of a modeling tool.  That way, we can gather information incrementally and consistently, and put out a document daily or a couple of times each week.

I've got the tools that do it.  The challenge is not so much the tools.  It goes back to "what do we include in the requirements document itself?"  Do we ask about a long list of features? 

I believe that is a path of pain.  If you ask a business person about a feature (like "do you need to be able to simulate a business process"), will they say "no?"  At best, they will ask about the feature, and will try to construct a business scenario where that feature is useful, and if it sounds appealing, then the feature becomes a requirement.  This is a useful way to sell things, and vendors like to encourage this thinking, but it is a poor way to buy. 

Analogy: Do you need the seats in your car to automatically adjust to your settings?  Think about it.  You hop into your car, and your spouse was driving it yesterday, so you press a button and the seat and mirrors automatically adjust to your settings.  Cool.  But is it a requirement?  Do you limit the selection of cars to those models that offer this feature? 

Not if the goal is to get to work in an inexpensive way. 

It makes more sense to avoid discussions of features until you understand the problems the business needs to solve, and then describe the processes that the business will use to solve them (at least from a high level).

So instead of a large mind map of features and technologies, consider the following map for BPM.

This is not a perfect list.  I don't believe in perfect.  I believe in "pretty good." 

So you start with these business objectives, and you sit with your business and you ask which of these scenarios they care about.  It is fairly easy to get a "no" answer to some of these.  These map to business problems, not business solutions, and when you are describing requirements, you are describing the problems.

For each of the elements in the tree, have your business user provide a 'valuation.'  I like the "thousand dollar" approach.  Tell your business user that they have an imaginary amount of money to spend.  I like using $1,000.  Have them put the money on the leaves of the tree, in proportion to the amount of value that they would get.  The business person must spend all of the money, and they cannot divide the money equivalently. 

What you will get is 20 or 30% of the money going to one scenario, and over 50% going to one group.  Focus there.  Solve the problems for that space.  For everything where the business user put 5% or less of the money, drop it. 

This map is generic.  You can use it again and again.  Different business users will give you different values depending on the problems they want to solve. 

From there, you can map features, and from there, technologies. 

This approach allows you to produce a much smaller 'requirements' document, much more quickly. 

I call the diagram above a "scenario map."  If you know of other scenario maps running around the Internet, please share them. 

And let me know what you think...

 [added by Nick: I don't have time to fix the things wrong with this post, but I'll add a couple of 'afterthoughts' that help refine the idea.  I don't think there is anything wrong with the core idea, but the places where you can use it are narrower than I imply.  (a) this approach works if you know the solution space first, and then if you tie the business capabilities to the problem space second.  That is backwards for most folks, because it implies you know the solution before you have modeled the problem.  So I would say that this approach is good for BUY-VS-BUILD DECISIONS, but not normal IT software development requirements.  (b) There is an opportunity for Completely missing the boat, even in a b-v-b process implied above.  You have to select the solution space, first.  You could, potentially, select the wrong class of solutions, and then proceed to pick the 'best' solution, within the wrong space.  I need to think this idea through a bit before I suggest that anyone actually use it.  YOUR SUGGESTIONS ARE WELCOME.]

Technorati Tags: BPM,Requirements Gathering,Analysis,Software Development