"Requirements Elicitation Techniques" compares various techniques' relative effectiveness. The higher the level in the diagram, the more effective the technique; for example, active stakeholder participation in requirements modeling is generally more effective than simply observing users doing their jobs, which in turn is usually more effective than reading existing documentation. But it's all situational—you could easily learn about the most critical requirement in a face-to-face interview, even though you've had active stakeholder participation since your project's start. On the diagram's left side are collaborative techniques, and on the right side are techniques that restrict your interaction with stakeholders. In general, you should use techniques toward the top of the diagram rather than those toward the bottom, and collaborative techniques over restricted interaction techniques.
 Requirements Elicitation Techniques The higher the level in the diagram, the more effective the technique; for example, active stakeholder participation in requirements modeling is generally more effective than simply observing users doing their jobs, which in turn is usually more effective than reading existing documentation. Collaborative techniques are found on the diagram's left side, and techniques that restrict your interaction with stakeholders are on the right. |
Collaboration Is Job #1
"Who's Better, Who's Best?" compares the
strengths and weaknesses of four techniques offering the greatest opportunity
for agility. First, active stakeholder participation is a core practice of
Agile Modeling (AM), an extension of Extreme Programming (XP)'s on-site customer
practice. In XP, the customer role is filled by one or more people who are
available to provide domain-related information to the team and to make requirements-related
decisions in a timely manner.
On-site customers are a second key success factor for any project because they reduce the wait time for critical information. AM takes this practice one step further by having stakeholders actively involved in your modeling efforts—they're the business experts, so they're the ones best suited to model the business. The secret? Take an inclusive approach to modeling that uses simple techniques such as sketching and paper prototyping, and simple tools such as plain old whiteboards. By adopting these techniques (see www.agilemodeling.com/essays/inclusiveModeling.htm for details), you'll discover that stakeholders can be effective members of your development team throughout your project's lifecycle.
Focus groups are another useful collaborative approach. Invite a group of actual and/or potential end users to brainstorm requirements. Focus groups work well when your stakeholders are dispersed and/or difficult to identify, which is particularly true when you're developing commercial software. They're also a great technique for defining the initial, high-level requirements at the beginning of your project.
| Who's Better, Who's Best? | |||
| Comparing the collaborative requirements elicitation techniques | |||
| Technique | Strengths | Weaknesses | Staying Agile |
| Active Stakeholder Participation | Information is provided to the team in a timely manner. Decisions are made in a timely manner. The people with the domain knowledge define the requirements. | Many stakeholders need to learn modeling skills. Stakeholders often aren't available 100 percent of the time. Airs your dirty laundry to stakeholders (so manage their expectations accordingly). Stakeholders need to be educated in their role | It doesn't get more agile than this. |
| On-Site Customer | Information is provided to the team in a timely manner. Decisions are made in a timely manner. | Airs your dirty laundry to stakeholders. Stakeholders need to be educated in their roles. | Get your stakeholders involved with development by evolving toward an active stakeholder approach. |
| Focus Groups | Significant amounts of information can be gathered quickly. | Must be planned in advance. Much unimportant information will be conveyed. It's difficult to identify the right people. Focus groups can be diverted by a strong-willed individual. | Hold it in a room with whiteboards or flip-charts, so people can draw as they talk. |
| Face-to-Face Interviews | You can elicit information quickly from a single person. People will tell you things privately that they wouldn't publicly. | Interviews must be scheduled in advance. Interviewing skills are difficult to learn. You often hear the ideal way that people work, or want to work, not how they actually do it. | Be prepared to follow up after the interview. Hold the interview at a whiteboard, so that you can sketch as you talk, turning the interview into a model-storming session. Actively listen to what they're saying. |
The fourth collaborative technique is the traditional, face-to-face interview. Although interviews are sometimes impromptu events, they're usually scheduled at a specific time and place. Effective interviewers give interviewees at least an informal agenda to allow them time to prepare, as well as a copy of your interview notes with some follow-up questions for post-interview review. Interviews are great for stakeholders who have valuable information to share, but who can't be actively involved with the project team. You can often turn critics into allies simply by interviewing them to discover their requirements and then keeping them informed of your progress.
Traditional Techniques Revisited
Restrictive techniques that more tightly control the way in which you interact with your stakeholders are also effective for eliciting requirements—and they can be applied in a relatively agile manner (see "From JAD to Booksense").
| From JAD to Booksense | |||
| Comparing the restricted interaction techniques | |||
| Technique | Strengths | Weaknesses | Staying Agile |
| Joint Application Design (JAD) | Facilitator can keep the group focused. Significant amounts of information can be gathered quickly. Works well when stakeholders are dispersed and can only meet irregularly. | Facilitation requires great skill. JADs must be planned in advance. | Loosen the rules about when people can talk. Hold it in a room with whiteboards or flip-chart papers so people can draw as they talk. |
| Observation | Helps to identify what people actually do. Provides significant insight to developers regarding their stakeholder environments. | It's hard to merely observe; you also want to interact. Seems like a waste of time because you're "just sitting there. Can be difficult to get permission. | This is best done passively. Expect to identify more stakeholders who may be able to actively participate with your team. |
| Electronic Interviews | Supports environment with dispersed stakeholders. Potentially provides a permanent record of the conversation. Often enhances existing stakeholder relationships. | Limited information can be conveyed electronically. Risky when it's your only means of communication. | Be prepared to follow up after the interview. Write concise, focused questions. Ideally used to support other techniques. |
| Legacy Code Analysis | Identifies what has actually been implemented. | The actual requirements usually differ from your current ones. It can be difficult to extract requirements from legacy code, even with good tools. | Must be tempered with more interactive techniques. Analyze the legacy in an incremental, just-in-time (JIT) manner. |
| Reading | Opportunity to learn the fundamentals of the domain before interacting with stakeholders. | Practice usually differs from written information. There are limits to how much you can read and comprehend at a single sitting. | Read details in a JIT manner. |
A Joint Application Design (JAD) session is a facilitated, highly structured meeting that has defined rules of behavior. An agenda and information package; for example, your project vision and charter documents, is distributed before a JAD so that participants can come prepared. Official meeting minutes are written and distributed afterward, and the facilitator is responsible for ensuring that action items are fulfilled. By holding a JAD session early in your project, you not only elicit your system's initial requirements, you also soothe the fears of the traditionalists by getting your project started on the right foot.
Observation of your end users is a critical technique for anyone involved with requirements elicitation. The goal? To watch end users do their daily work to determine what actually happens in practice instead of the often unrealistic picture you receive via other elicitation techniques. After an observation session, you should take notes and then ask questions to discover why the end users were doing what they were doing. Observation often provides those "aha!" moments, when you truly understand what you need to build.
Electronic interviews, often by telephone, video conferencing or e-mail, are also vital. Ideally, your primary elicitation approach should be based on face-to-face communication, but because your stakeholders may not always be immediately available, a quick e-mail is a great way to get the tidbits of information that you need.
Most project teams find that they must interface with, if not extend, existing legacy systems. To identify what the system currently implements, you often need to perform legacy code analysis, in which you work through the existing code and data sources to discover what was actually built.
Reading is also an effective requirements elicitation technique. Internally, you may have existing, albeit out-of-date, system documentation and/or business documentation (perhaps even enterprise business models). Externally, there may be websites describing similar systems; perhaps your competitors' sites, or even textbooks describing the domain in which you're currently working. Reading can give you a good foundation from which to ask intelligent questions using other elicitation techniques.
Grandpa Got It Right
My grandfather always told me to use the best tool for the job, and the only way I could do that was to keep a wide range of tools at my disposal and know how to use them appropriately. My advice to you is the same as grandpa's: Learn a range of requirements elicitation techniques and then apply the right one for the situation at hand. The more techniques you have in your intellectual toolkit, the more effective you'll be.
Scott W. Ambler is a Canada-based software process improvement (SPI) consultant, mentor and trainer with AmbySoft Inc. He has written several books and is a regular speaker at software conferences worldwide.