How to Prepare for Software Requirements Sessions with Your Users - Tip 4

Our final suggestion on this topic is to Sit With Your Users.

If your users are extremely busy, and the project involves changes to or replacement of an existing solution, then turn the challenge into an advantage. Sit beside the users while they perform their job tasks.

Typically this is a good way to elicit requirements because users cannot always articulate their needs if they are used to completing tasks without thinking about them. This technique will require follow-up meetings with the users after, but then those meetings can be prepared for as above, with intelligent questions based on the observations, thereby shortening the time that users are away from their work.

Let's recap, we've now offered the following suggestions to prepare for requirements sessions with users:

1. Organize Your Time
2. Prepare Your Requirements Models In Advance
3. Prepare Your Elicitation Questions in Advance
4. Sit With Your Users

There are many ways in which requirements analysts can intelligently prepare for requirements sessions with users. Typically a mix of the above suggestions will work well on any project. These tips will help the analyst and users get the most value out of the available time.

By the way, you can download all of these tips in a whitepaper that I've written. Enjoy!

How to Prepare for Software Requirements Sessions with Your Users - Tip 2

Last time we talked about organizing your time.

Today's suggestion: Prepare Your Requirements Models In Advance

Prepare draft requirements models in advance of the meeting. The reality is that good requirements analysts do in fact know quite a bit about the business processes and requirements. There is a misconception that they should remain unbiased; however, these individuals become experts in the systems they are capturing requirements for and that expertise should be utilized to its full advantage.

As an example, if you are going to cover a topic with a user about how he or she does a task, then you can try to come up with the obvious use cases in advance. You can then take it one step further and actually try to write the header information and normal course for the use cases. Similarly, you may find it valuable to draft state diagrams, where you capture the states and transitions that are obvious and highlight the unknown ones for completion in the meeting. Virtually all requirements models can be pre-drafted if you know a little bit about the business.

In doing these models ahead of time, you will find yourself jotting down lots of questions in the margins, like "What really happens at this step?" or "Should they do X instead of Y?". Even if you throw away the draft model because it was all wrong (which rarely happens), there is still a value from the time investment because you came up with a list of detailed questions. Essentially this is a brainstorming tool for you.

Starting from a blank slate can seem like a daunting task, so once you have draft models, in the meetings with users, you can use these models to work from. Similarly to the authoring experience, reviewing the models will spur questions in the reader’s mind. Therefore they make an excellent tool with which to facilitate a user meeting.

See another great post on how to choose a requirements model.

Come back for part 3 next!

How to Prepare for Requirements Sessions with Your Users - Tip 1

This is the first part of a four part series on how to prepare for software requirement sessions to be most effective with your users' time (and yours!).

Can You Get All of Your Requirements In One Session?

There is general agreement in the software industry that talking to end users to gather requirements is critical to the success of the project. However, a common issue is that users are particularly busy. For example, if an organization decides to add features to a call center application, talking to the call center representatives is critical, but it’s also costly to pull them away from taking calls. In addition, requirements analysts are extremely busy and may have to limit how much time they spend with any one user.

A common issue in gathering requirements is leaving a stakeholder meeting where you missed major requirements because the “next question” to ask did not occur to you at the time. It is unreasonable to think that this will never happen. The reality of software requirements efforts is that they are iterative. In addition, there is quite a bit of critical analysis that must take place, and that analysis cannot always happen immediately in a meeting environment. Whatever the reason, there is certainly a need to get the most out of time spent with the users. So how do you best prepare for meetings with your end users?

Software Requirements Sessions Tip 1: Organize Your Time

Requirements analysts should realize that the software requirements life cycle can be time intensive - including time to analyze, edit, review, and update. The key is to maximize the value from everyone’s time.

Make sure that requirements sessions are well planned, inviting the minimal group of people necessary to get value out of the meeting. The burden of extra time spent should be on the requirements analyst, not the users who are being taken away from their primary jobs. Prepare an agenda and appropriate artifacts prior to the sessions in order to keep the meeting focused on making valuable progress.

In dealing with any super-users who are unable to commit much time, it is important to zero in on specifically what information they must provide. Then allow these users to suggest alternative users to meet with to provide additional information, ensuring them you will allow them to review what the alternative users provided.

Come back soon for part 2!

How do you prepare for a requirements session? I'd love to hear your answer in the comments.

Ask, Don't Tell

As you may have surmised from other posts, I'm a daddy. I have an almost-two-year-old little boy who, as his age would suggest, is in the midst of the "terrible twos" (by the way, most people I've talked to about the phenomenon agree that it starts around 18 months and lasts until college). He's extremely strong-willed, and he is also extremely vocal. So, when he doesn't want to leave the kitchen even though you're trying to cook, or empty the dishwasher, or clean up, or unload the groceries, he's very clear about it!

I used to try to instruct him to come out of the kitchen, or come with Daddy, or play with puzzles, in order to get him to do what I want (leave the kitchen), and he simply replies, "NO! NO! NO!" Eventually, I found a surprisingly powerful way to deal with his less-than-helpful single-mindedness, though -- asking questions. If, instead of suggesting an approach, I ask him if he would prefer to read a book or flop on the bed, he usually picks one of the two choices and quickly runs out of the kitchen. If, instead, I had suggested that we do one or the other (or both), it would have been NO-time again. When it's his choice, though, he's happy to oblige.

I've found the same approach to be equally powerful with my requirements work. If I come into a requirements gathering situation and begin telling people how things are going to go/work, I find that I often encounter resistance (stated or unstated). However, if I plan ahead and have several options available in my toolbelt, then I have the ability to ask SMEs how they'd like to work together. They get to be in charge of the decision, even though I've only offered them viable choices to pick from. I realize that this may be a bit deceptive, but I think of it instead as me helping my SMEs make good choices, often in spite of any preconceived notions about requirements work.

It's important to note that, both with my son and with my SMEs, I limit the choices. I don't ask my little boy "What would you like to do?," but instead "Would you like to do X or Y?" Similarly, I don't ask SMEs how they would like to provide their requirements, I ask them "Would it be better to sketch out the existing process on the whiteboard or for me to watch you work through it at your desk?" I don't offer alternatives that I don't think would work (like "playing with knives" for my two-year-old or like "please fill out this use case template for me" with my SMEs), just those I think are solid options for the situation.

It's hard to follow this approach all the time, especially when I'm in a frustrating situation or environment, but when I'm able to take a step back and put the other person in the driver's seat (but only of a car that I think is appropriate), we both win.

That's a Completely Useless Answer!

Have you ever asked someone a question, only to have him/her respond with, "Well, it depends..."? It can be extremely frustrating, especially when all you want is a simple, direct answer. For example, if I'm looking for directions to a restaurant and someone tells me that it depends on whether I want to take the most quick, the most direct, or the most scenic route, I probably don't mind the clarifying question. If, on the other hand, that person just says, "It depends" and stops talking, then a very annoyed look will probably appear on my face.

But the answer to many questions DOES depend on additional information that the asker doesn't provide. I may know that my car is low on gas, or that the dinner reservation is in 10 minutes, or that I just rented a convertible and want to drive around with the top down, any of which would allow someone to suggest an applicable route to dinner. But because those things are an integral part of my world that I don't consciously consider when phrasing the question, they're probably not on the tip of my tongue when I'm posing my question.

As a result, what often happens is that the person asking the question gets either a non-response ("It depends...") or an inappropriate response given my specific (but unstated) objective. The answer is either annoying or just plain wrong for the situation -- and in either case, the person who asked it probably thinks "That's a completely useless answer!" Unfortunately, if you ask enough vague questions, people stop answering them, and if you answer enough questions inappropriately or with only "it depends," people stop asking you for answers. Neither of those situations is good for someone in the requirements business!

In earlier posts, both Joyce and I extolled the virtues of context, and this is another great example of the importance of that kind of additional information. When you're meeting with stakeholders to gather requirements, explain the context for your involvement with the project and the questions you're asking. When you're answering requirements questions, don't just stop with "It depends" -- tell them what it depends upon and what some possible answers are for each situation. You'll build credibility with your team, establish a reputation as a reliable source of information, and (perhaps most importantly) not be the cause of that annoyed look on anyone's face!