Chapter7 Requirement Elicitation
Lecture 1
Chapter7 Requirement Elicitition
Topic cover
➢ Requirements elicitation techniques
Interviews
Workshops
Focus groups
Observations
Questionnaires
System interface analysis
User interface analysis
Document analysis
➢ Planning elicitation on your project
➢ Preparing for elicitation
➢ Performing elicitation activities
➢ Following up after elicitation
Organizing and sharing the notes
Documenting open issues
➢ Classifying customer input
➢ How do you know when you’re done?
➢ Some cautions about elicitation
➢ Assumed and implied requirements
➢ Finding missing requirements
Chapter7 Requirement Elicitition
Requirements elicitation techniques
Elicitation techniques in software projects involve methods for uncovering and understanding requirements, blending
facilitated and independent activities to gather diverse perspectives efficiently.
The following sections describe several techniques commonly used to elicit requirements
▪ Interviews
▪ Workshops
▪ Focus groups
▪ Observations
▪ Questionnaires
▪ System interface analysis
▪ User interface analysis
▪ Document analysis
Chapter7 Requirement Elicitition
Interviews
Define: and potential biases.
User interviews are essential interactions Detail:
facilitated by business analysts to gather direct Interviews typically involve oneonone or
insights from stakeholders regarding software smallgroup sessions facilitated by business analysts
requirements. They offer advantages such as direct (BAs) to elicit requirements. These sessions are
access to user perspectives and flexibility in structured to explore specific topics related to the
scheduling, but may suffer from limited perspectives software system.
Chapter7 Requirement Elicitition
Interviews
Advantages: Disadvantages:
Direct Insight: Interviews provide direct access Limited Perspective: Interviews may not capture
to user insights and preferences, allowing for a the full range of user perspectives and
deeper understanding of requirements. requirements, as they rely on the insights of a
Rapport Building: Establishing rapport with select group of stakeholders.
interviewees enables a comfortable environment Bias Risk: Interviewer bias or leading questions
for sharing thoughts and concerns, particularly on can influence responses, potentially skewing the
sensitive topics. gathered requirements.
Flexibility: Interviews are easier to schedule and Time and Resource Intensive: Conducting
lead compared to largegroup activities like multiple interviews can be timeconsuming and
workshops, making them suitable for projects resourceintensive, especially for largescale
with time constraints. projects with diverse user groups.
Expert Engagement: Interviews with domain Scope Drift: Without careful facilitation,
experts help newcomers gain domain knowledge interviews may veer offtopic, leading to
quickly, facilitating the formulation of initial discussions that do not align with the project
requirements and models. objectives.
Chapter7 Requirement Elicitition
Workshops
Define: Detail:
Requirements workshops are structured sessions Methodology: Requirements workshops bring
where a diverse group of stakeholders collaborate to together stakeholders and content experts to
define, refine, and finalize user requirements collectively define, create, refine, and finalize
deliverables, facilitated by a designated individual. deliverables representing user requirements, such
as models and documents.
Chapter7 Requirement Elicitition
Workshops
Advantages: Disadvantages:
▪ Collaboration: Workshops foster stakeholder ▪ Resource Intensive: Workshops may require
collaboration, enabling effective resolution of significant time and resources, including
disagreements and consensus building. numerous participants and extended duration.
▪ Efficiency: Multiple stakeholders participate ▪ Complex Planning: Effective planning is
concurrently, leading to quicker elicitation and essential to avoid time wastage during sessions,
refinement of requirements. necessitating thorough preparation and
▪ Structured Approach: Facilitation ensures that organization.
workshops stay focused on objectives, ▪ Scope Management: Careful monitoring is
minimizing scope drift and maximizing required to prevent discussions from delving into
productivity. unnecessary details, ensuring alignment with
▪ Quick Turnaround: Workshops are beneficial project scope.
when rapid elicitation turnaround is required due ▪ Facilitation Challenges: Facilitators must
to schedule constraints. manage multiple roles simultaneously, including
guiding discussions, notetaking, timekeeping,
and ensuring all voices are heard.
Chapter7 Requirement Elicitition
Focus groups
Define: Detail:
A focus group is a representative Focus groups involve interactive sessions
gathering of users convened in a where users share their attitudes,
facilitated activity aimed at generating impressions, preferences, and needs
input and ideas on a product's functional regarding a product. Facilitation ensures
and quality requirements. discussions stay on topic without
influencing expressed opinions.
Chapter7 Requirement Elicitition
Focus groups
Advantages: Disadvantages:
▪ User Insights: Focus groups provide ▪ Limited Decision Authority: Participants
valuable insights into users' attitudes, typically lack decisionmaking authority for
preferences, and needs, aiding in requirements, potentially impacting the
requirement exploration. efficacy of generated input.
▪ Representation: Careful selection of ▪ Subjectivity: Feedback obtained from focus
participants ensures representation from groups is subjective and may not always
diverse user backgrounds, enhancing the align with broader user sentiments or project
validity of feedback. objectives.
▪ Feedback Evaluation: While qualitative,
feedback from focus groups can be further
evaluated and prioritized to inform
requirement development.
Chapter7 Requirement Elicitition
Observations
Define: Detail:
Observations involve directly observing users as Observations entail silently or interactively observing
they perform their tasks to gain insights into their users as they carry out their tasks, allowing
workflows, identify problems with current systems, business analysts (BAs) to validate information
and gather information to inform system collected from other sources and identify
improvements. opportunities for system enhancements.
Chapter7 Requirement Elicitition
Observations
Advantages: Disadvantages:
▪ Validation of Information: Observations validate ▪ Time Consuming: Observations can be
information obtained from other elicitation timeconsuming, particularly for tasks requiring
techniques, ensuring accuracy and completeness. extended periods to complete.
▪ Problem Identification: Direct observation helps ▪ Limited Scope: Not suitable for every user or
identify issues with current systems and task, observations may not capture all relevant
workflows, enabling targeted improvements. information, necessitating supplementary
▪ UserCentric Insights: Observations provide elicitation techniques.
usercentric insights into task execution, facilitating
the identification of requirements that align with
user needs.
Chapter7 Requirement Elicitition
Questionnaires
Define: Detail:
Questionnaires are a method of surveying large Questionnaires involve presenting a set of
groups of users to gather insights into their needs. wellwritten questions to users, covering various
They are costeffective and can be easily aspects of their needs and experiences. The
administered across different geographical locations. responses collected are analyzed to inform
decisionmaking and prioritize requirements.
Chapter7 Requirement Elicitition
Questionnaires
Advantages: decisionmakers.
Disadvantages:
▪ CostEffective: Questionnaires are
inexpensive, making them suitable for ▪ Limited Depth: Questionnaires may lack
surveying large user populations without the depth of insights obtained through more
significant financial investment. interactive elicitation techniques like
▪ Wide Reach: They can be administered interviews or observations.
easily across geographical boundaries, ▪ Potential for Bias: Users' responses may
allowing for the collection of diverse be influenced by the phrasing of questions
perspectives. or the structure of the questionnaire, leading
▪ Input for Other Techniques: Analyzed to biased results.
questionnaire results can serve as valuable
input for other elicitation techniques, such
as workshops or discussions with
Chapter7 Requirement Elicitition
System interface analysis
Define: ▪ Identifies Redundancies: It helps identify existing
Interface analysis is an independent elicitation technique functionality in interfacing systems that may negate the
involving the examination of systems connected to your need for duplication in your system, thus optimizing
own. It focuses on revealing functional requirements related development efforts.
to data and service exchange between systems.
Disadvantages:
Detail:
Interface analysis entails identifying and examining the ▪ Complexity: Analyzing multiple system interfaces can
interfaces between your system and others. It involves be complex and timeconsuming, especially in
understanding the data and services exchanged, as well as environments with numerous interconnected systems.
any associated requirements and rules. ▪ Dependency on System Understanding: Interface
analysis effectiveness relies on a comprehensive
Advantages: understanding of both your system and the systems it
▪ Reveals Functional Requirements: Interface analysis interfaces with, which may require significant domain
uncovers requirements related to data exchange and knowledge.
functionality between systems, providing crucial insights for
system design and development.
Chapter7 Requirement Elicitition
User interface analysis
Define: ▪ Efficiency: By studying existing UIs, analysts can learn
User Interface (UI) analysis is an independent elicitation about common user actions and workflows, potentially
technique used to study existing systems, either directly or reducing the need for extensive user interviews or
through documentation like screen shots or user manuals, training sessions.
to discover user and functional requirements.
Disadvantages:
Detail: ▪ Assumption Avoidance: It's essential to avoid
UI analysis involves examining the interfaces and assuming that all functionality observed in existing
interactions of existing systems to identify user systems is necessary or optimal for the new system. The
requirements and functionality. This can be done by analysis should focus on identifying requirements
interacting directly with the system or by reviewing relevant to the specific context and objectives.
documentation such as screen shots or user manuals. ▪ Flexibility Consideration: UI analysis should not
constrain the design of the new system based solely on
Advantages: the layout or functionality of existing systems. The focus
▪ Comprehensive Understanding: UI analysis provides should be on meeting user needs and system objectives
insight into the user experience and functionality of rather than replicating existing interfaces.
existing systems, helping in the identification of potential
features
Chapter7 Requirement Elicitition
Document analysis
Advantages:
▪ Comprehensive Insight: It provides a comprehensive
Define: understanding of existing systems, business
Document analysis is an elicitation technique involving the processes, and industry standards, helping to uncover
examination of existing documentation to uncover potential requirements.
potential software requirements. This includes various ▪ Time Efficiency: Document analysis can expedite the
types of documents such as requirements specifications, elicitation process by reducing the time needed for
business processes, user manuals, and problem reports. elicitation meetings, as researchers can prepare
requirements beforehand.
Detail: Disadvantages:
Document analysis involves reviewing a range of ▪ Risk of Outdated Information: There's a risk that the
documents, including requirements specifications, user available documents may not be uptodate, leading to
manuals, business processes, and problem reports, to discrepancies between documented requirements and
extract relevant information regarding software the actual needs of the system.
requirements. ▪ Overlooking Unspoken Requirements: Documents
may not capture all implicit or unspoken requirements,
potentially missing important aspects of the system.
Chapter7 Requirement Elicitition
Chapter7 Requirement Elicitation
Lecture 2
Chapter7 Requirement Elicitition
Planning elicitation on your project
Introduction:
➢ Early planning of requirements elicitation crucial for
project success.
➢ A welldefined plan sets realistic expectations and
secures commitment from stakeholders.
➢ Flexibility in planning is essential for adapting to
evolving project needs.
FIGURE 71 Suggested elicitation techniques by project characteristic.
Chapter7 Requirement Elicitition
Planning elicitation on your project
Key Components of Elicitation Plan:
➢ Elicitation Objectives:
Define objectives for the entire project and each activity.
➢ Elicitation Strategy and Planned Techniques:
Select appropriate techniques based on stakeholder groups, access, and time constraints.
Techniques may include questionnaires, workshops, customer visits, and individual interviews.
➢ Schedule and Resource Estimates:
Identify participants and estimate effort and calendar time required.
Estimate Business Analyst (BA) time for preparation and followup analysis.
➢ Documents and Systems for Independent Elicitation:
Identify necessary materials for document, system interface, or user interface analysis.
➢ Expected Products:
Anticipate deliverables such as use cases, Software Requirements Specification (SRS), and quality attribute
specifications.
➢ Elicitation Risks:
Identify potential obstacles, assess severity, and plan mitigation strategies.
Chapter7 Requirement Elicitition
Preparing for elicitation
Definition:
Facilitated sessions extract project requirements from stakeholders. Preparation
involves defining scope, crafting agendas, and preparing questions. Facilitators use
openended questions and straw man models to guide discussion, fostering
collaboration. Flexibility ensures all topics are covered effectively.
FIGURE 72 Activities to prepare for a single elicitation session
Chapter7 Requirement Elicitition
Preparing for elicitation (Preparation Tips)
➢ Scope and Agenda: Leveraging Dissatisfaction:
▪ Define session scope aligned with project objectives. ▪ Use dissatisfaction with current systems as a catalyst for
▪ Communicate agenda and objectives to stakeholders in improvement.
advance. ▪ Solicit feedback on the current system's pain points for
➢ Resources: insight into desired improvements.
▪ Schedule physical resources and participant availability. ➢ Flexibility in Questioning:
▪ Ensure access to necessary documentation and ▪ Be adaptable and willing to deviate from prepared
systems. questions.
➢ Understanding Stakeholders: ▪ Solicit feedback from participants to ensure all relevant
▪ Identify relevant stakeholders and their preferences. topics are covered.
▪ Provide supporting documentation for nonnative ➢ Straw Man Models:
speakers ▪ Create draft models (e.g., use cases, process flows) to
➢ Prepared Questions: aid discussion.
▪ Prepare a set of questions to guide the session. ▪ Use existing knowledge and resources to develop initial
▪ Phrase questions to avoid leading responses and models, inviting feedback for refinement.
uncover true needs.
➢ Roleplaying and Probing:
▪ Put yourself in the user's shoes or play the role of an
apprentice.
Chapter7 Requirement Elicitition
Performing elicitation activities
FIGURE 73 The perform elicitation activities step for a single elicitation session.
Chapter7 Requirement Elicitition
Performing elicitation activities
Conducting elicitation activities involves straightforward actions such as interviewing individuals or analyzing documents. However,
facilitating such activities requires careful consideration and the following tips can be helpful:
➢ Educate Stakeholders: ▪ Use walls for drawing diagrams or creating lists.
▪ Explain your elicitation approach and its benefits. ▪ Provide sticky notes and markers for interactive
▪ Describe exploration techniques like use cases or process participation.
flows. ▪ Encourage movement and engagement with the "Wall of
▪ Clarify how their input will be captured and shared for Wonder" collaboration pattern.
review. ➢ Facilitate Remote Sessions Creatively:
➢ Take Good Notes: ▪ Utilize online conferencing tools for shared slides and
▪ Assign a dedicated scribe to take accurate notes. interactions.
▪ Include attendee list, decisions made, actions to be taken, ▪ Use videoconferencing to show remote participants
outstanding issues, and key discussions. whiteboard activities.
▪ Utilize shorthand, fast typing, or recording devices if ➢ Use Toys Appropriately:
necessary. ▪ Incorporate simple toys to stimulate creativity and
➢ Prepare Questions Ahead: engagement.
▪ Plan questions in advance to maintain flow and focus. ▪ For example, use modeling clay to visually represent
▪ Develop a shorthand notation for capturing spontaneous product vision and inspire ideas.
questions.
Chapter7 Requirement Elicitition
Following up after elicitation
FIGURE 74 Activities to follow up after an elicitation session
Once an elicitation activity concludes, there are crucial followup tasks to
undertake. These include organizing and sharing notes, documenting open
issues, and categorizing the newly acquired information.
Chapter7 Requirement Elicitition
Following up after elicitation
➢ Organizing and Sharing Notes:
▪ Consolidate input from various sources, especially after leading interviews or workshops.
▪ Review and update notes promptly after the session to maintain accuracy.
▪ Share consolidated notes with participants for review and verification.
▪ Address any inconsistencies or gaps through additional discussions.
▪ Consider sharing notes with stakeholders not present to keep them informed and address any
concerns.
➢ Documenting Open Issues:
▪ Identify items needing further exploration or resolution.
▪ Review notes and parking lots for unresolved issues or knowledge gaps.
▪ Record open issues in an issuetracking tool with relevant details (e.g., notes, progress, owner, due
date).
▪ Utilize the same issuetracking tool used by development and testing teams for consistency.
Chapter7 Requirement Elicitition
Classifying customer input
Customers rarely present a neatly packaged list of their
needs. Analysts must categorize the various pieces of
requirements information they gather during elicitation
activities to document and utilize them effectively. Below are
nine categories for classifying requirements, along with
examples and indicators to listen for during elicitation
sessions:
FIGURE 75 Classifying customer input.
Chapter7 Requirement Elicitition
Classifying customer input
Business Requirements:
Descriptions of financial or marketplace benefits desired by customers or the developing organization.
Examples: "Increase market share in region X by Y percent within Z months," "Save $X per year on electricity."
User Requirements:
General statements of user goals or business tasks needed to be performed.
Examples: "Print a mailing label for a package," "Calibrate the pump controller first thing every morning."
Business Rules:
Statements specifying conditions or constraints that apply to user activities.
Examples: "New clients must pay 30 percent of estimated fees in advance," "Timeoff approvals must comply with HR policy."
Functional Requirements:
Descriptions of system behaviors and actions available to users.
Examples: "Highpressure warning light comes on if pressure exceeds 40.0 psi," "User can sort project list alphabetically."
Quality Attributes:
Statements describing desirable system characteristics such as speed, usability, reliability, and security.
Examples: "Mobile software must respond quickly to touch commands," "Shopping cart mechanism must be simple to use."
Chapter7 Requirement Elicitition
Classifying customer input
➢ External Interface Requirements:
▪ Descriptions of connections between the system and external entities.
▪ Examples: "Manufacturing execution system must control the wafer sorter," "Mobile app should send check image to the
bank."
➢ Constraints:
▪ Restrictions that limit developer options, such as language, size, or encryption requirements.
▪ Examples: "Files submitted electronically cannot exceed 10 MB," "Browser must use 256bit encryption for secure
transactions."
➢ Data Requirements:
▪ Descriptions of data formats, types, structures, or reports to be generated.
▪ Examples: "ZIP code consists of five digits followed by an optional hyphen and four digits," "Order includes customer
information, shipping details, and product details."
➢ Solution Ideas:
▪ Suggestions for specific ways to interact with the system, which may need further probing to identify underlying
requirements.
▪ Examples: "Select the state from a dropdown list," "Swipe with a finger to navigate between screens."
Chapter7 Requirement Elicitition
Chapter7 Requirement Elicitation
Lecture 3
Chapter7 Requirement Elicitition
How do you know when you’re done?
Determining when requirements elicitation is complete isn't straightforward, especially in iterative development like agile
projects. However, certain indicators suggest you're nearing a point of diminishing returns:
➢ Users exhaust their ability to propose new use cases or user stories, typically in order of decreasing importance.
➢ Proposed new scenarios don't yield additional functional requirements and may overlap with previously captured use
cases.
➢ Users revisit issues already discussed in prior sessions.
➢ Proposed features or requirements fall outside the project scope or are deemed low priority.
➢ Users suggest capabilities for future product iterations rather than the current one.
➢ Few questions arise from developers and testers during requirements review.
Chapter7 Requirement Elicitition
Some cautions about elicitation
Mastering elicitation discussions is a skill that develops with experience and training. Here are some key cautions to
streamline the learning process:
➢ Balance Stakeholder Representation:
▪ Ensure diverse stakeholder input to avoid overlooking important requirements or relying solely on outspoken
individuals.
➢ Define Scope Appropriately:
▪ Clearly define project scope to prevent accumulating unnecessary requirements or missing crucial ones.
➢ Avoid RequirementsVersusDesign Argument:
▪ Recognize the overlap between requirements and design, using prototypes and analysis models to clarify user needs.
➢ Research Within Reason:
▪ Avoid extensive research during elicitation; treat feasibility investigations as separate project tasks.
Chapter7 Requirement Elicitition
Assumed and implied requirements
➢ Not all requirements will be explicitly documented, posing a risk of delivering a solution that diverges from
stakeholders' expectations.
➢ Assumed requirements are expectations not explicitly expressed, varying among individuals and leading to
misunderstandings.
➢ Implied requirements are necessary to fulfill other stated requirements but are not explicitly mentioned.
➢ Mitigate risks by actively identifying and addressing knowledge gaps.
➢ Surface assumptions during elicitation sessions by asking probing questions and confirming their validity.
➢ Review features of existing systems to identify necessary requirements for replacements.
➢ Identify implied requirements by scrutinizing initial elicitation results for areas of incompleteness.
➢ Revisit stakeholders to uncover missing requirements and involve new stakeholders to identify gaps.
➢ Read between the lines during discussions to uncover implicit expectations.
➢ Pose contextfree questions to elicit insights that standard questions might not reveal.
Chapter7 Requirement Elicitition
Finding missing requirements
➢ Decompose highlevel requirements: Break down vague highlevel requirements into more detailed specifications to
ensure clarity and prevent gaps between expectations and deliverables.
➢ Ensure comprehensive user class input: Confirm that all user classes have provided input to cover diverse
perspectives and needs.
➢ Trace requirements to functional specifications: Establish clear links between system requirements, user
requirements, eventresponse lists, and business rules to ensure that all necessary functionality is derived.
➢ Check boundary values: Examine boundary conditions to identify missing requirements, especially in scenarios
where specific values are not explicitly defined.
➢ Represent requirements in multiple formats: Utilize visual analysis models alongside textual descriptions to identify
missing elements more easily.
➢ Address complex Boolean logic: Review requirements with complex logic structures to ensure that all possible
conditions are covered, including "else" scenarios.
➢ Use checklists: Develop checklists of common functional areas and periodically compare them with specified
functions to identify any gaps.
➢ Leverage data models: Ensure that all data entities have corresponding functionality for creation, retrieval, updating,
and deletion, as represented by the CRUD operations (Create, Read, Update, Delete).
Chapter7 Requirement Elicitition
Chapter7 Requirement Elicitition
