Making Requirements Collection Less Tedious

Published January 26, 2015 by Chris Boulanger

Whether you’re a developer or a client hiring one, it helps having a straightforward, visual way of presenting your ideas and what you think the software will do. This gets overlooked in the early planning when you’re trying to get requirements right. And it can drain client enthusiasm from a project.

Where Frustrations Arise

If a dev team is experienced with clients that don’t have technical backgrounds, then they will have a lot of discussions during requirements setting and get to what they need. This is one of the best things a firm can do for it’s client…and also the first thing that clients get frustrated about.

Clients get frustrated because they don’t realize upfront how much help they need to give developers in figuring out how their application will operate. The client sits with the account executive or technical lead and describes what they want as best they can, but this isn’t enough for the developers.

They come back with:

Questions about who will input things.

Questions about what type of information will be inputted.

How things will be inputted

Questions about if things will need to edited after they’re created.

Questions about how much use the application will get.

And these questions are just preliminary. If both the developer and client are lucky, then the client will keep answering questions until the team has a pretty good idea of what they need to build. This process can take weeks, but it’s worth it because editing a word doc is a lot cheaper than fixing software.

“I’ve Already Told You What I Want”

Ideally, a client can hire a digital project mananger or software consultant to help them, but even then you may have issues translating what a client sees in their head (or hears from their customers) into requirements that engineers can use.

After a while, clients start getting annoyed. They start wondering about all the emails and Word-doc revisions and teleconferences, and why they haven’t even seen a sketch yet. They start thinking, “I’ve already told these guys everything they need to know, so why aren’t they getting it done?”

Not soon after this, the angry emails start or they start pushing for faster delivery. The developers start making guesses, the work speeds up, and the client gets happy again…for a while.

It took me a few projects to realize it, but bad or incomplete requirements is the main way you get stuck over-budget, behind schedule or with a canceled project. The rush to results keeps teams from thoroughly fleshing out requirements, so you end up with a requirement set that misses some nuance or misses a need entirely. And we don’t see what’s missing until we’re into the sprints or (god forbid) user acceptance testing.

Speaking in (Tech) Tongues

Let me get the cliches and “IT Crowd” jokes out of the way now, so we can talk about communication.

Most engineers do not suffer from Aspergers, constantly talk in jargon, have poor listening skills, or think themselves too smart to talk to anyone that isn’t in tech.

However, they’ve spent years learning very specific ways of defining, discussing and designing software.

Over time, they’ve become conditioned to working with a specific set of routines, rules and roles to accomplish their projects. In order to work with them, clients have to help them translate ideas into the frameworks the developers know. This is beneficial and largely painless, but it can be time-consuming and boring for clients.

Make it a Little Easier on Everyone

I’m still looking for that, but I’ve found that using a very simple diagramming process makes explaining requirements much easier and more interactive.

This won’t remove the need for requirements discussions and revisions. But it will give clients and developers a common visual language for referring to the different requirements of the application and let clients be active participants.

Diagramming on A Dime

There are several different languages and patterns available to software developers for diagramming how things will work; with the UML and MVC being two that are used a lot. But most of these lexicons are too ugly or get too complicated for a laymen.

If clients want to get requirements figured out more quickly, and developers want requirements fleshed out more clearly, then we need something that’s simple for both sides to understand and that both sides can quickly change.

Ideally, this method should:

Not require any special skills (just basic computer experience)

Be portable (you can run it anywhere)

Be visual (less room for confusion)

Employ a small amount of iconography and terminology

The Power of Process Diagrams

At a very high-level, programming requires you to conceptualize 2 things: a logical set of procedures for performing tasks; and a collection of objects that will be created/edited/deleted by these procedures. Put another way, you have Inputs, a Process and then Outputs. The Output of one Process can become the Input of another, and Processes can be strung together.

Yes, this is very simplified, but honestly this is all a non-technical client needs to understand to keep things moving.

If we break things down this way, then either the client or the developers can easily represent parts of the application in process diagrams.

Here is an example using the process of creating an account record:

This is simple and a bit ugly, but it only takes 2 minutes to create from scratch. And there is a enough information here to get a conversation going. From looking at this, you can get:

# of fields that client expects

What those field should be called.

That this information needs to be stored in an Account Record.

That you’ll need a form to input it.

None of this is rocket-science and there is a lot more to discover, but this slide gives you a visual aid for discussing the account creation process with clients. You can also start thinking about the structure of information and storage of it. If you think there are some obvious things they need to add, then you can do it in minutes.

Maybe you think they will need to collect additional information.

Maybe you decide that they’ll need a profile page.

Download the PPT versions of the slides above. Whether you are the client or the developer, you can quickly edit and adapt these in PowerPoint. I’d suggest doing a live editing session where you put a number of slides like this up on a big screen and work through them. They have very few elements and can be styled anyway you want.

Developers can create a deck from initial conversations, ask the client to make edits with them, and then use them to get a stronger draft statement of requirements written.

Clients can create their own deck and send it to the developers. Just think of what you want your software to do and create a slide.

Why Bother with Any of This

The point here isn’t to replace the requirements gathering process because we know that developers need it. The point is to make that process a bit more transparent and approachable for clients, so they can stay involved and feel like progress is being made.

It’s when we lose the client’s attention that things go awry. When they don’t understand the import of the questions being asked or feel that they aren’t getting their money’s worth. With this approach, you have an easy-to understand, easy-to-create and easy-to-share artifact that lets you show progress quickly. Compare this to the time it takes to get a mockup or even a storyboard in place. Even better, this is something that clients can work on with you and it’s a hell of lot more appealing than reading through version 20 of an SRS.