It’s been a while since I’ve led a requirements session for an interactive application – but no worries, I found it’s like riding a bike. After a few minutes the old habits come back, and iterative ideas and cascading creativity starts to flow.
What has changed, however, is the application platform, the office environment, and the various knowledge capture tools at our disposal. So, in the spirit of knowledge retention and sharing, here’s a brain dump of ideas that I feel will improve your requirements gathering sessions …
- Think of it as an interactive presentation – so all of the classic rules for preparation and setup apply. Arrive early, get set up and have everything running before people arrive.
- Make sure you can bring the original application (if it’s a rework) up on the screen: check in advance that you can attach to the network.
- The best sessions are interactive, with application mock-up tools. Have a copy of Visio, PowerPoint or something similar ready to go – so you can paint screens and interactively work things while they watch.
- Use a room with a big screen TV or projector, so your audience can “see over your shoulder” as you work. However, if possible, you should face your audience – have them look behind you at the screen / projection, while you look at the display on your laptop.
- This allows you to have a conversation with your audience, as they express their ideas, needs, and wants. Also, you’ll be able to see their facial expressions as you mock things up on the screen – and get those critical first impressions.
- This also allows your audience to see what you are typing. They are proofreading your work – not for typos, but to make sure their ideas are captured correctly.
- Make sure you know where the local printer is, and can print to it. Waiting for a series of changes to be “painted” on the screen may take too long; it might be easier just to take a print screen and mark it up.
- When sketching on paper, have a couple of different color pens on hand, and color-code your scribbles; red = follow-up / things to fix, blue = talking points, etc. When capturing ideas on the hard copy, your fixes & follow-ups are easily distinguishable. A highlighter might be good idea, too.
- re: typing / data capture: Consider using a simple text editor, Notepad or something similar. Key is not to worry too much about formatting the text or correcting typos. As long a you can decipher your hacking, that should be ok.
- However, a spell checking word processor might be preferable to Notepad – your typos will get automatically fixed up.
- Always number your requirements / items to attack. Then you have a finite, trackable list of stuff that is either go or no go.
- Consider creating an auto-numbered spreadsheet for a Requirements list – you can bring it up on the screen as well. Create additional columns for notes, resource assignments, effort estimates – stuff like that.
- Bring a digital voice recorder to the session. Let the folks know that they are being “taped” – but it’s only so you can go back and replay the discussion while cleaning up your notes. This will also allow you to stop typing and continue the in-depth conversation – which is where all the value happens.
- Set clear expectations of what you want to accomplish in the meeting – and set a time limit; iterative work is easily digested when taken in small bites.
There is a lot of power in truly collaborative requirements sessions – the ultimate users of your system will readily accept the results when they are truly part of the design process and experience.
This Post Has 0 Comments