The path to requirements elicitation is something that analysts are rarely taught. Everyone knows that it involves interviews and research, but within most organizations, exactly how the interviews and research should be conducted is nebulous.
I once took a requirements course that used the design of an ATM machine as an illustration for the requirements gathering process. That scenario is hardly representative of real life. Everyone already knows what an ATM machine is, and how it should function. A few bells and whistles may be different, or it even may have an unexpected feature such as fingerprint analysis instead of a pin number to confirm one's identity. But we all know what money is, what a bank account is, and why people come to an ATM machine.
In real life, the direction that an analyst receives for new project is likely to be much more opaque, like this:
"Our goal is to build a snibbet system that will also accommodate our widgets when appropriate. On occasions that snibbets and widgets intersect, we will map the resulting snidget to its appropriate location. These locations will in turn map to a modget. Individual modgets may activate multiple snibbets; you must implement logic to determine if one or multiple snibbets belong in the widget calculations or if they must be excluded."
From this direction, a host of questions will arise, and unearthing their answers will likely take weeks: What are snibbets? What are widgets? Why would it be appropriate for them to intersect? What would warrant such an instance? What are the resulting outcomes? And so on.
As you pursue the answers to such questions, the following may help you nail down unambiguous requirements more quickly and explicitly.
The Interview Process
-
Research as much as you can in advance in order to ask precise questions, but phrase them in a way that they’re open-ended, even if you think you know the answer. Don’t ask "The slow delivery time is a major problem with the current system, isn't it?" or even "What problems do you see with the current system?" but "Would you say that you see any problems with the current system? Can you please give me specific examples, or show me?"
-
Provide the questions several days in advance to your interviewee, so that s/he can do any necessary research. Explain what you want to accomplish with your project.
-
If you don’t already have a relationship with your interviewee, it may be helpful to begin with a bit of small talk to build a rapport. Establish an open relationship, and encourage the interviewee to call you anytime if they think of anything else.
-
Cover all of your questions in the interview, but do not be afraid to follow your interviewee down a separate road of dialogue to see where it leads. Some of your most crucial discovery will come from unexpected information that your interviewee volunteers.
-
Listen closely for words or phrases you don't know, or what the interviewee isn't saying. "We had a system that sent things via email until two years ago." Why did you choose to get rid of that system? Do you see any limitations in the new system?
-
If you (1) have multiple interviewees who are pressed for time with other projects or (2) have many potential interviewees who may or may not know any useful information, you may want to schedule a group interview. Group interviews normally result in cross-departmental or cross-organizational discussions that can offer new insights as well. (But make sure you stay in control of facilitating the discussion, or it can simply turn into a venue for airing grievances and waste a lot of time.)
-
After the meeting or interview, synopsize your findings as soon as possible while they’re fresh. Send your synopsis to your interviewee(s) to be sure that you are all on the same page. Reading over your notes may spur other insights that s/he will volunteer.
Unearthing your Unknowns
Discovery goes well beyond the interview, however. In our widget example above, after the analyst had deciphered the language and learned what each of the new terms meant, how they intersected, how they were built, and why the user even wanted the change—and after the project was implemented—the last thing s/he would want to hear is, "You didn't incorporate fidgets? Why, that leaves out a whole section of widgets. This is going to be useless." Such oversights are almost always expensive to correct in terms of resource effort.
All of this leaves the business analyst to find a way to discover what s/he doesn't know, and which other people may not think to volunteer. The best way to extract this information is to find ways to make the end product or service as tangible as possible, and to show it to the right people.
(Agile development has been a major step in overcoming requirements omissions. But whether your organization follows the agile model or not, the quality of feedback you get during each [or one] iteration depends on the clarity of information you provide for review. There are three key ways, whether your development process is iterative or not, to help eliminate unknowns.)
-
Make sure your feedback group is broad enough. Include savvy users and novices. (If you don’t want to reveal what you’re creating to your competitors, it may be necessary to ask your users to sign a non-disclosure form. Be sure to check with your legal department.) Don’t overlook training, customer care, and sales.
-
Provide a prototype before requirements are reviewed, and invite your stakeholders to "drive." Include both business owners and a core group of key users in your stakeholder group. Give them plenty of time (at least a week) to review. Even if your company has not adopted an iterative development cycle, try to create at least two prototype iterations in response to their feedback.
If someone in your organization is not designated to create prototypes (or if one will not be provided until after your requirements are due), try creating static mock-ups. A PowerPoint™ will be far less effective than an interactive prototype, but a static visual is better than no visual at all. Clarify that you are not looking for feedback to tweak the bells and whistles at this stage (i.e., "I think the Save button should go at the top") but rather to clarify functionality. If you’ll be providing a usability review, reassure your feedback group that they can make those finer tweaks later.
-
Provide exhaustive use cases for every scenario, and use simple diagrams and language. A use case review can be the tool that helps your stakeholders identify that you left fidgets out altogether. Despite what documentation you may have read on use cases, don't make your diagrams or examples overly technical, and do not use analyst-specific language. This is not for your engineers to review; it's for users (probably customers) and business owners. Straightforward language will better enable them to identify gaps that will help you define your requirements.
As you continue to experiment with and refine your elicitation process, any lack of familiarity with a system or product will decrease in significance. The interview and feedback process will enable you to write strong requirements. No requirement document is completely exhaustive, but like agile development, good feedback elicitation can guarantee yours doesn’t have to be.
Author: Morgan Masters is Business Analyst and Staff Writer at ModernAnalyst.com, the premier community and resource portal for business analysts. Business analysis resources such as articles, blogs, templates, forums, books, along with a thriving business analyst community can be found at http://www.ModernAnalyst.com