It’s easy on a technical project to get caught up in the specific technology being implemented – the cool user interface, the underlying architecture, the components that ensure good things like scalability, performance, and productivity. But all of those rely on being fed quality requirements to meet a client’s needs. The role of the analysts on a project – those who are capturing the business processes, the desired system functionality to map to those processes, and the priority/severity of needs – is a crucial one.
This blog post is not about rehashing the Use Case vs. Post-It argument (read: Big Design Up Front and KanBan-ish styles). Instead I wanted to share some techniques that I use when gathering requirements. These do lend themselves well to Agile projects, but the outputs can definitely be integrated into more traditional, structured requirement documents if need be. How the requirements get documented is a moot point if the quality of the requirements themselves is poor, and that’s what I want to focus on – methods that produce higher quality requirements.
Organized Think Tank
I was on a project recently where I was meeting with people from eight different departments within an organization. Each department had their own meeting, and had multiple people represented. My job was to collect what they liked about their current system, what they didn’t like, and what they felt was missing.
The key when dealing with groups of people is control. You want to avoid having one or two people dominate a discussion, and you also want those who are quiet or less likely to speak up to voice their thoughts/concerns/understanding. The way I approached my situation was using a technique I call the “Organized Think Tank.” There’s probably a more accurate name for this, and it’s very similar to User Story Mapping, but let’s use that moniker for now. Here’s how you run one.
First, provide all attendees with a large post-it note pad (the ones about the size of a recipe card) and a marker. Explain to everyone why you’re collecting information from them, what it will be used for, and why their input is so important. Now here’s where you can customize it based on your situation. For me, I wanted input on their existing system – the good, the bad, and what was missing. For the first round, I asked everyone to write down on their post-it notes what they liked about the system. Once everyone was done, I had them post them on a wall under a “What’s Good” header post-it note. Then I read through them and, as a group, we discussed: did we need clarification, was there another slant that someone had, was there extra information someone could provide. We then repeated this for what was bad and what was missing.
By going through this exercise, a few things were accomplished:
Control - With very little effort, I was able to control a group. By placing structure on how people could communicate, we avoided any one person taking control of the conversation and ensured everyone had a voice. Also, notice that I had them write things down. Instead of me as the analyst having to feverishly type on my laptop what people were saying, they wrote it themselves. I was free to moderate.
Perspective - When we got to discussing the bad and missing items, it was interesting to find that certain things people thought didn’t work right or were missing, actually did work or did exist. What we uncovered through this is that due to a lack of initial training materials, a number of the staff wasn’t aware of the capabilities of the system.
We also uncovered underlying reasons for similar comments. Two people from different groups might comment that reports were unusable. But in discussing those and fleshing them out, we might find that one was speaking about how too many fields were being returned while the other was talking about not being able to locate reports due to confusing navigation.
Interaction - Yes, you will still have a few people wanting to dominate discussion with this method; but, at the same time, those who normally would never have spoken up or had a chance to speak, were able to contribute and share their ideas, concerns, and needs.
Validation - By going through the post-its and discussing each one, we were also able to eliminate ones the group determined weren’t really valid. And we could highlight items that were deemed higher priority or more critical for the group.
This technique works best when you’re dealing with groups. In my case, I had meetings where only one or two people would be in attendance. In those cases, I opted for a more conversational style. Reading people and using the best technique for them is another blog post, but remember that the goal is to produce quality requirements, so you shouldn’t feel that if you start with one technique you have to use it in every situation.
But what about the detailed requirements? Surely post-it notes can’t capture things at a deep enough level to actually perform work on them! Well, that’s somewhat true. Requirements gathering is not a point-in-time event. It’s an ebb-and-flow process with multiple pass overs. Also, we need to re-think what a requirement is. A requirement is not a use case, it’s not a diagram, it’s not a post-it – it’s a need that the solution requires to meet a specific end. How we document and organize that need in the scope of a project is a separate concern.
Value Stream Mapping
Another technique I use is Value Stream Mapping. I was part of an analysis exercise where an organization wanted to improve its internal systems, but weren’t really sure how. To start, we wanted to get an idea of what their key value processes were – that is, what was it that organization did that resulted in the biggest value? In this case, it was collecting memberships so we mapped out how they did that.
We assume that people working in an organization know how that organization functions, especially for key operational processes. But that is far from the truth. I even think of Online – I don’t know all the various operational processes or who’s involved. With the group that I was value stream mapping with, that was the case as well. For them, they were a smaller organization – eight people. And yet, at the end of the exercise, one of them turned to the others and said “I had no idea that you did all of that just to process a membership.” He thought it was a much simpler process, and questioned the value of even going through the exercise at the beginning. By the end he saw the value.
So, how do you do Value Stream Mapping? Honestly there’s no real secret to it – get a whiteboard, a group of people, and start asking them how they perform a key process to their organization. Ask who does what when, what systems are involved, what type of data is passed (note that “data” could be an email to someone, a file printed and placed on a processing stack, etc.), what the timing is – and draw it out. It’s amazing how things will come out that you never expected and that they themselves never fully realized.
I want to reiterate what I wrote earlier, as it’s a very important concept:
A requirement is not a use case, it’s not a diagram, it’s not a post-it – it’s a need that the solution requires to meet a specific end. How we document and organize that need in the scope of a project is a separate concern.
Requirements are the lifeblood of a project. They’re the things that fuel construction and drive value in a solution. They’re also very abstract – at their simplest, they’re a need. We document and pretty them up, decorate them with fancy diagrams and autograph them with sign offs. But ultimately, requirements gathering is needs gathering, and triaging those needs based on value.
If you’ve been stuck “doing” requirements the same way, try either of the techniques I talked about here or others that are out there. I’m currently reading a book called Innovation Games by Luke Hohmann, which has many different creative ways to better understand solution requirements.
Requirements gathering can be fun, exciting, and fulfilling. It’s all about the people and their needs, not the document templates and diagrams that we create.