5 Requirement Elicitation and Collaboration
If there is one skill that defines Business Analysis more than any other, it is the ability to understand what people truly need. This chapter addresses that skill directly. Requirement elicitation is not just gathering information. It is uncovering needs that stakeholders may not even know they have, clarifying desires that are initially vague, and building shared understanding among people with different perspectives.
The work we discuss here is both art and science. There are techniques you can learn and practice. But there is also judgment that develops only through experience. My goal is to give you the techniques while helping you understand the judgment that makes them effective.
5.1 What Is a Requirement?
Before we discuss how to gather requirements, we must define what we mean by the term. A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an objective.
Read that definition carefully. Requirements are not features. They are not specifications. They are not the things that developers build. Requirements are needs. They describe what stakeholders require to accomplish their goals.
This distinction matters because it keeps us focused on the right question. We do not ask “what should the system do?” We ask “what do stakeholders need to accomplish?” The system exists to serve stakeholders, not the other way around.
Requirements communicate and clarify business needs or required capabilities. They bridge the gap between problems that need solving and solutions that address those problems.
5.2 Types of Requirements
Not all requirements are the same. The course material identifies four distinct types, each serving a different purpose.
Business requirements sit at the highest level (Figure 5.1). They are statements of goals, objectives, and outcomes that describe why a change has been initiated. Business requirements can apply to an entire enterprise, a specific business area, or a particular initiative. They are developed during strategy analysis and answer the fundamental question: why are we doing this?
Here is an example of a business requirement: “We need an online presence to help us service customers worldwide.” Notice that this statement does not specify any particular technology or approach. It describes a business need that could be addressed in many different ways.
Stakeholder requirements describe the needs of specific stakeholder groups that must be met to achieve business requirements. They serve as a bridge between high-level business requirements and detailed solution requirements.
For example: “We need to showcase our departments’ offerings online.” This requirement is more specific than the business requirement but still leaves room for different implementation approaches.
Solution requirements describe the capabilities and qualities that a solution must have to meet stakeholder requirements. This category divides into two subcategories.
Functional requirements describe what the solution must do in terms of behavior and information management. “The website must allow customers to search for products by category” is a functional requirement.
Non-functional requirements describe conditions under which the solution must remain effective or qualities it must have. “The website must load within three seconds on standard broadband connections” is a non-functional requirement. Non-functional requirements often address performance, security, usability, reliability, and similar concerns.
Transition requirements describe capabilities needed to move from the current state to the future state that are not needed once the transition is complete. Examples include data conversion utilities, training programs, and temporary processes that support parallel operations during cutover.
5.3 Attributes of Good Requirements
Writing requirements well is harder than it appears. Good requirements share certain attributes that make them useful for development and verification.
Good requirements are unambiguous. They can be interpreted only one way. If different readers could reasonably reach different conclusions about what a requirement means, it needs revision.
Good requirements are testable. You can verify whether they are met. “The system must be user-friendly” is not testable. “New users must be able to complete a basic transaction within five minutes without assistance” is testable.
Good requirements are clear, which means concise, terse, and precise. They contain no unnecessary words and convey meaning efficiently.
Good requirements are correct. They accurately reflect what stakeholders actually need.
Good requirements are understandable. The audience can comprehend them without extensive explanation.
Good requirements are feasible. They can realistically be implemented given available technology, time, and resources.
Good requirements are independent. They can stand alone without requiring understanding of other requirements to make sense.
Good requirements are atomic. Each requirement contains only one thing. Combining multiple needs into a single requirement creates problems during design, development, and testing.
Good requirements are necessary. They reflect actual needs rather than preferences or assumptions about what might be useful.
Good requirements are implementation-free. They describe what is needed, not how to achieve it. “The system must store customer addresses” is implementation-free. “The system must store customer addresses in an Oracle database” is not.
5.4 The Elicitation Process
Elicitation is not a single activity but a series of tasks that work together.
Preparation ensures that everyone is ready for productive elicitation activities. Conducting elicitation involves actually gathering information. Documenting results captures what was learned. Confirming results validates that the documented information is accurate.
5.5 Preparing for Elicitation
Preparation involves ensuring that stakeholders have the information they need to contribute effectively and understand what they will be asked to do.
Resource preparation identifies the people, facilities, and equipment needed. Who needs to participate? Where will activities take place? What materials or technology are required?
Ground rules establish expectations for elicitation activities like brainstorming sessions, focus groups, interviews, observations, prototyping exercises, and requirements workshops. What behaviors are expected? What behaviors are prohibited?
Informing stakeholders means notifying appropriate parties of the plan. Let people know what to expect, why their participation matters, and how to prepare.
Process agreements establish how feedback will flow during elicitation and how results will be verified and approved.
5.6 Conducting Elicitation
Conducting elicitation is where you actually gather information about stakeholder needs. This work requires careful attention to several factors.
Tracking guards against scope creep by tracing requirements back to business goals and objectives. When a potential requirement emerges, ask whether it supports the defined business need. If not, it may belong in a different initiative.
Attributes documentation captures metadata about requirements as they are elicited. Recording the source, value, and priority of each requirement aids management throughout the lifecycle.
Metrics tracking records participation and time spent, providing a basis for future planning.
5.7 Elicitation Techniques
Business Analysts use many techniques to elicit requirements (Figure 5.2). Each has strengths and weaknesses that make it more or less suitable for different situations.
5.7.1 Interviews
Interviewing is the process of interacting with individual stakeholders to understand their needs and perspectives. Interviews work well for gathering detailed information from specific individuals.
Interviews can be structured, with a predefined set of questions, agenda, and execution pattern. Structured interviews ensure consistency and coverage but may miss unexpected insights.
Interviews can be unstructured, with free-flowing conversation that follows whatever topics emerge. Unstructured interviews capture unexpected information but may miss important topics.
Questions within interviews can be closed-ended, providing options for responses and yielding objective data. They can be open-ended, allowing subjective responses that reveal deeper perspectives. They can be probing, following up on initial answers to explore issues more deeply.
Interviews are not ideal for building consensus. When you need agreement among multiple stakeholders, other techniques work better.
5.7.2 Observation
Observation involves studying stakeholders as they perform their work to document details about current processes. Watching people work often reveals information that interviews miss, because people do not always accurately describe what they actually do.
Passive or invisible observation means watching without interrupting. Stakeholders perform their work normally while the observer records what happens.
Active or visible observation involves interaction. The observer asks questions and requests explanations while watching work occur.
Shadowing means following someone throughout their day, learning by comprehensive observation.
Apprenticing means actually participating in the work alongside stakeholders, learning by doing.
Observation works best for processes that occur regularly and predictably. It is less suitable for exception handling or fraud detection, where normal observation would not capture the relevant scenarios.
5.7.3 Brainstorming
Brainstorming uses the creative power of a group to generate many ideas quickly. It works well when you need diverse options or want to explore possibilities without immediately evaluating them.
The cardinal rule of brainstorming is: do not debate ideas during the session. Evaluation kills creativity. When people fear criticism, they censor themselves. Brainstorming separates idea generation from idea evaluation.
Anonymous brainstorming, where contributors are not identified, can increase participation by reducing social pressure.
5.7.4 Prototyping
Prototyping creates visual representations of potential solutions to elicit feedback.
Wireframes are low-fidelity representations showing basic layout and placement without detailed design. They help stakeholders understand structure and flow.
Mockups are medium-fidelity representations with more defined visual elements.
Prototypes are high-fidelity representations that look and feel close to the final product. They may include interactive elements that simulate actual functionality.
5.7.5 Workshops
Workshops are focused events attended by key stakeholders and subject matter experts for a concentrated period of time. They may be held for different purposes including planning, analysis, design, scoping, requirements elicitation, modeling, or any combination of these.
Workshops bring stakeholders together to collaborate on achieving a predefined goal. They are particularly effective for building consensus and clarifying issues that affect multiple parties.
Benefits of workshops include rapid, high-quality decision making, greater buy-in from all stakeholders, building team spirit, building consensus, and clarification of issues.
5.8 The GAIN Framework
When conducting elicitation conversations, I recommend a structure that helps ensure you gather complete information. GAIN stands for Goal, Achievement Value, Issues, and Needs.
G for Goal: Ask about the stakeholder’s ideas. What are they trying to accomplish? What does success look like to them?
A for Achievement Value: Try to understand the importance of what was mentioned. Why does this goal matter? What happens if it is not achieved?
I for Issues: Ask about obstacles. What problems might prevent achieving the listed goals? What has gone wrong in the past?
N for Needs: Determine who else to consult and what resources are required. Is there anyone else you should talk to? What information would help move forward?
5.9 Confirming Elicitation Results
After gathering information, you must confirm that what you documented accurately reflects what stakeholders actually said and meant. Misunderstandings caught early are easy to correct. Misunderstandings caught during testing are expensive disasters.
Document analysis compares elicitation results against source information or other existing documents.
Interviews with stakeholders verify that the documented information is correct.
Reviews allow groups to examine elicitation results and provide feedback.
Workshops walk through elicitation results using predetermined agendas, scripts, or scenario tests.
5.10 Managing Stakeholder Collaboration
Collaboration does not happen automatically. It requires ongoing management to keep stakeholders engaged and working toward common goals.
Gaining agreement on commitments ensures that everyone understands and accepts their responsibilities.
Monitoring stakeholder engagement tracks whether people are participating as expected and addresses issues when they are not.
Continuous collaboration maintains relationships and communication throughout the initiative.
5.11 Case Example: The Hospital Scheduling System
Regional Medical Center needed a new scheduling system. The existing system was twenty years old, and everyone complained about it. Schedulers spent hours on manual workarounds. Physicians grumbled about appointment conflicts. Patients waited too long.
The Business Analyst assigned to the project recognized that thorough elicitation would be critical. She planned a comprehensive approach using multiple techniques.
She started with interviews across different departments. Schedulers described the complex constraints they juggled: physician preferences, room availability, equipment needs, staff certification requirements. Nurses explained that they needed visibility into schedules across multiple units. Physicians revealed that their scheduling preferences had been ignored for years. Administrators wanted reports that the current system could not produce.
But interviews were not enough. The Business Analyst also conducted observation, watching schedulers do their work. She discovered something surprising: the schedulers had developed informal practices that violated official procedures but actually made the system work. They had workarounds that management did not know about. A new system that enforced official procedures would fail because those procedures were inadequate.
Focus groups with patients revealed another dimension. Patients did not care about internal scheduling complexity. They cared about being able to get appointments when they needed them, getting reminders so they did not forget, and not waiting in the waiting room. Scheduling was the number one source of patient dissatisfaction.
Prototyping helped evaluate vendor options. The Business Analyst created wireframes showing key workflows, then had stakeholders compare how different vendor products would support those workflows. This revealed gaps that generic vendor demonstrations would have hidden.
Finally, workshops brought stakeholders together to prioritize requirements and build consensus. When scheduling priorities conflicted between departments, workshops provided a forum to work through the conflicts rather than letting them fester.
The project took longer than the organization initially expected. But it worked. The new system addressed real needs because those needs had been thoroughly elicited and validated. Adoption was smooth because stakeholders had been involved throughout and felt ownership of the solution.
Now that you understand how to elicit requirements from stakeholders, let us explore how to manage those requirements throughout their lifecycle.
5.12 Review Questions
Which type of requirement describes capabilities needed only during the transition from current state to future state?
- Business requirements
- Stakeholder requirements
- Solution requirements
- Transition requirements
A requirement stating “The system must be easy to use” violates which attribute of good requirements?
- Independent
- Testable
- Atomic
- Necessary
What is the cardinal rule of brainstorming?
- Limit sessions to one hour
- Ensure equal speaking time for all participants
- Do not debate ideas during the session
- Always have a senior manager present
In the GAIN framework, what does “A” represent?
- Action items to complete
- Achievement Value or importance
- Assumptions to validate
- Alternatives to consider
What is the key difference between functional and non-functional requirements?
- Functional requirements are more important
- Functional requirements describe behavior; non-functional requirements describe qualities
- Non-functional requirements are optional
- Functional requirements come from users; non-functional requirements come from IT
1-d, 2-b, 3-c, 4-b, 5-b