A few thoughts on how to gather and refine requirements

1. Ask Questions

This may seem obvious, but too many software requirements gathering sessions involve the gatherer making statements. Sometimes their in reaction to client questions. Sometimes the gatherer simply makes them himself.

In any case, here are some starter questions.

• What does this software need to do?

• Is this internal or external facing?

• If internal, is the aim to make more money or cost less money?

• If external, is success measured in conversions, dollars, or some other means?

• What’s the timeline?

• What’s the budget?

2. Challenge Assumptions

So you’ve asked all your questions now, right? Good. Now ask some more. Ask them about the stuff the client just told you.

• Both iOS and Android apps at launch? Why not just one or the other?

• All reporting functionality day 1? What data will they have to report on day 1?

• Does it really need to support ALL browsers?

Admittedly, this is when the client may start to wonder whether you want their money. You probably may kill a sacred cow or two with this conversation.

Stay positive and curious. If a client gets flustered, don’t get flustered back and start to argue. Just acknowledge their feelings and move along.

3. Priorities: Think Small First

You have now challenged the client on the necessity of different components. You may have left your requirements meeting brimming with ideas that you need to determine the priority on, or maybe you’ll enter into a session where the client is prioritizing stuff with you.

As you’re determining priority, if possible, try to solve the core need and only the core need with any recommendations. In this pile of statements of got-to-haves is a real, narrow need. Find it.

Scope will naturally to expand by itself. You don’t need to help it along.

Sure, there’s likely a bunch of other nice things that will include, and the more stakeholders, the broader the need becomes. But when faced with the opportunity to create one system to rule them all, resist it.

4. Priorities (Again): Balance Wants Against Needs

During this prioritization, recognize one unfailing fact: people want what they don’t need and need what they don’t want.

In particular, you’re going to have a client who is going to want to push the boring parts down the road, like security, data-integrity, etc. You know, the easy stuff (I joke). This is completely normal, so don’t get all uppity about it.

On the other hand, judiciously determine in your heart of hearts to not create a death trap for the system’s users, your client, and yourself. It is possible to gently nudge the client in the right direction. If you can, just assume it to be true and state it so. Whatever you do, don’t grandstand.

In general, there exists a not-so-obvious portion of complexity that the client won’t tell you about because he doesn’t know it’s there. It’s hard to see, but it’s really big like the part of an iceberg underwater.

Also, like an iceberg underwater, that’s the part of the project that may kill you in the long run. Find it.

5. Let the Client Make the Hard Decision

After you’ve listened to the client tell everything he needs, then get into making hard choices. This will likely be a different meeting or a series of emails or comments on Trello card. Whatever the form, this will be considered the spec. This is what you’re building.

In here, though, don’t agonize on the scope. Your job is to build a scope that’s in budget and in timeline. (You did gather those with your questions, right?)

If you can separate out pieces, show them what you can fit in the time and money box based on their prioritization. Then show them what you can’t fit inside. Be ready to swap stuff in and out.

6. Ink is Better than Air

Awesome you gathered all the requirements. You’re done, right? Not quite.

Regardless of your methodology is — waterfall, Agile, scrumfall, Post-Agile, GROWs — in all things, get it in writing. I don’t care who writes it as long as it gets written.

Summary

Nothing earth shattering here, I hope. What do you all use as principles or rules of thumb for gathering requirements?