Hubbry Logo
Requirements elicitationRequirements elicitationMain
Open search
Requirements elicitation
Community hub
Requirements elicitation
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Requirements elicitation
Requirements elicitation
Requirements elicitation
View on Wikipedia
from Wikipedia

In requirements engineering, requirements elicitation is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders.[1] The practice is also sometimes referred to as "requirement gathering".

The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do or not do (for Safety and Reliability). Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing and prototyping.

Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process. Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements.

Commonly used elicitation processes are the stakeholder meetings or interviews.[2] For example, an important first meeting could be between software engineers and customers where they discuss their perspective of the requirements.


The requirements elicitation process may appear simple: ask the customer, the users and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of business, and finally, how the system or product is to be used on a day-to-day basis. However, issues may arise that complicate the process.

In 1992, Christel and Kang identified problems that indicate the challenges for requirements elicitation:[3]

  1. 'Problems of scope'. The boundary of the system is ill-defined or the customers/users specify unnecessary technical details that may confuse, rather than clarify, overall system objectives.
  2. Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable.
  3. Problems of volatility. The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility

Requirements quality can be improved through these approaches:[4]

  1. Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation.
  2. Consistent language. Using simple, consistent definitions for requirements described in natural language and use the business terminology that is prevalent in the enterprise.
  3. Guidelines. Following organizational guidelines that describe the collection techniques and the types of requirements to be collected. These guidelines are then used consistently across projects.
  4. Consistent use of templates. Producing a consistent set of models and templates to document the requirements.
  5. Documenting dependencies. Documenting dependencies and interrelationships among requirements.
  6. Analysis of changes. Performing root cause analysis of changes to requirements and making corrective actions.

Guidelines

[edit]

In 1997, Sommerville and Sawyer suggested a set of guidelines for requirements elicitation, to address concerns such as those identified by Christel and Kang:[5]

  • Assess the business and technical feasibility for the proposed system
  • Identify the people who will help specify requirements and understand their organizational bias
  • Define the technical environment (e.g., computing architecture, operating system, telecommunications needs) into which the system or product will be placed
  • Identify "domain constraints" (i.e., characteristics of the business environment specific to the application domain) that limit the functionality or performance of the system or product to be built
  • Define one or more requirements elicitation methods (e.g., interviews, focus groups, team meetings)
  • Solicit participation from many people so that requirements are defined from different points of view; be sure to identify the rationale for each requirement that is recorded
  • Identify ambiguous requirements as candidates for prototyping
  • Create usage scenarios or use cases to help customers/users better identify key requirements

Sequence of steps

[edit]

In 2004, Goldsmith suggested a "problem pyramid" of "six steps which must be performed in sequence":[6]

  1. Identify the real problem, opportunity or challenge
  2. Identify the current measure(s) which show that the problem is real
  3. Identify the goal measure(s) to show the problem has been addressed and the value of meeting it
  4. Identify the "as-is" cause(s) of the problem, as it is the causes that must be solved, not the problem directly
  5. Define the business "wants" that must be delivered to meet the goal measure(s)
  6. Specify a product design how to satisfy the real business requirements

However Goldsmith notes that identifying the real problem "is exceedingly difficult".[6]

Complementary approaches

[edit]

In 2008, Alexander and Beus-Dukic proposed a set of complementary approaches for discovering requirements:[7]

Alexander and Beus-Dukic suggested that these approaches could be conducted with individuals (as in interviews), with groups (as in focused meetings known as workshops, or via Electronic meeting systems), or from "things" (artifacts) such as prototypes.[7]

Non-functional requirements

[edit]

In 2009, Miller proposed a battery of over 2,000 questions to elicit non-functional requirements.[8] Her approach is to build a stakeholder profile and then interview those stakeholders extensively. The questions are grouped into three sections, all focused on user needs:[8]

  1. Operation: how well does the [needs editing] use?
  2. Revision: how easy is it to correct errors and add functions?
  3. Transition: How easy is it to adapt to changes in the technical environment?

In 2013, Murali Chemuturi suggested the usage of Ancillary Functionality Requirements instead of Non-Functional Requirements as "Non-Functional" connotes "never functional". Second, these requirements in fact fulfill some requirements which are supportive to main or Core Functionality Requirements. [9]

Bibliography

[edit]

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Requirements elicitation

View on Grokipedia
from Grokipedia
Requirements elicitation is the process of seeking, uncovering, acquiring, and elaborating requirements for computer-based systems, involving the discovery, emergence, and development of stakeholder needs through communication and . As the foundational phase of in , it aims to identify functional and non-functional requirements, constraints, and expectations from users, customers, and other stakeholders to ensure the resulting system aligns with intended purposes. The importance of requirements elicitation cannot be overstated, as it directly influences outcomes; incorrect, incomplete, or misunderstood requirements are among the primary causes of poor , cost overruns, and delayed deliveries. Historical analyses, such as a 1982 U.S. Government Accountability Office survey of federal software contracts, revealed that 47% of delivered systems were never used and 29.7% were paid for but not delivered, largely attributable to elicitation deficiencies. In modern contexts, including agile and applications, effective elicitation remains essential for adapting to evolving stakeholder needs and reducing rework, which can account for up to 40-60% of development costs in flawed projects. Key techniques in requirements elicitation encompass a range of methods tailored to project contexts, such as interviews (structured, unstructured, or semi-structured) for direct stakeholder input, workshops and joint application design (JAD) sessions for collaborative group discussions, prototyping to visualize and refine ideas iteratively, and or to capture real-world behaviors. Other approaches include questionnaires for broad , brainstorming for idea generation, and goal-based methods like scenarios or use cases to structure requirements around objectives. In agile environments, techniques such as user stories and iterative feedback loops emphasize continuous elicitation to accommodate change. Despite its centrality, requirements elicitation faces persistent challenges, including communication barriers between stakeholders and analysts due to differing vocabularies and perspectives, difficulties in articulating , cognitive limitations in expressing needs, and conflicts arising from diverse stakeholder priorities. These issues can lead to incomplete specifications, particularly in complex domains like mobile applications or AI systems, where domain-specific techniques and tools are increasingly vital for . Ongoing research focuses on integrating AI-assisted methods and hybrid approaches to enhance accuracy and efficiency in this phase.

Introduction

Definition

Requirements elicitation is the systematic process of seeking, uncovering, acquiring, and elaborating the needs, expectations, and constraints of stakeholders to establish the foundational requirements for a software or system development project. This activity emphasizes discovery and extraction of , often through direct interaction, to ensure that the elicited requirements accurately reflect the intended system's purpose and functionality. As a critical early step, it lays the groundwork for subsequent development phases by transforming abstract stakeholder visions into concrete, actionable insights. At its core, requirements elicitation involves active communication with diverse stakeholders, such as end-users, clients, and domain experts, to gather explicit information while also uncovering that may not be immediately apparent. This process bridges the gap between user needs—often expressed in non-technical terms—and the technical specifications required by developers, thereby reducing misunderstandings and aligning the system with real-world demands. Techniques employed during elicitation aim to reveal hidden assumptions, resolve ambiguities in stakeholder perspectives, and integrate varied viewpoints into a cohesive set of preliminary requirements. Requirements elicitation is distinct from related activities in requirements engineering, such as requirements analysis, which focuses on refining and interpreting the gathered data to resolve conflicts and ensure completeness, or requirements specification, which involves documenting the validated requirements in a formal, structured format. While elicitation centers on the initial discovery and articulation of needs, analysis evaluates and prioritizes them, and specification produces the definitive output for implementation. This separation ensures that elicitation remains focused on exploration without prematurely imposing structure or validation. As the inaugural phase of the requirements engineering process, requirements elicitation directly feeds into design, implementation, and validation stages by providing a robust foundation of stakeholder-aligned requirements that guide the entire lifecycle. Its success determines the quality and relevance of the final system, as incomplete or misaligned elicitation can propagate errors throughout development. By prioritizing stakeholder involvement from the outset, elicitation establishes a collaborative framework that enhances outcomes and stakeholder satisfaction.

Historical Context and Evolution

Requirements elicitation emerged in the and as part of the foundational shift toward structured in , where early practitioners focused on systematically gathering user needs to mitigate project failures observed in the nascent field. Influential works, such as Barry Boehm's Software Engineering Economics (1981), emphasized the economic importance of upfront requirements activities, highlighting how poor elicitation contributed to cost overruns and advocating for cost-effective models like to inform requirements prioritization. This period laid the groundwork by integrating elicitation into broader lifecycles, drawing from techniques developed by figures like Edward Yourdon and Tom DeMarco. In the and , requirements elicitation evolved with the rise of object-oriented methods and collaborative techniques, moving beyond individual interviews toward group-based approaches to capture complex stakeholder interactions. Joint Application Design (JAD), formalized in the late 1970s by researchers Chuck Morris and Tony Crawford, gained widespread adoption in the for facilitating structured workshops that accelerated requirements gathering and improved consensus among diverse users. The decade also saw the standardization of practices, exemplified by the IEEE Std 830-1998, which provided recommended guidelines for software requirements specifications, emphasizing completeness, consistency, and traceability in elicitation outputs. The marked a with the advent of agile methodologies, which reframed elicitation as an iterative, evolving process rather than a one-time upfront activity. The Agile Manifesto () and frameworks like Scrum promoted continuous refinement through user stories and backlog grooming, enabling adaptive responses to changing needs in dynamic environments. This evolution influenced practices in the 2010s, where and delivery extended elicitation into ongoing feedback loops, treating requirements as living artifacts updated via automated pipelines and stakeholder collaboration. From the 2010s to 2025, digital tools and further transformed elicitation, incorporating platforms for broader input and (NLP) to analyze unstructured stakeholder since around 2015. Seminal reviews highlight NLP's role in automating detection and in requirements texts, enhancing efficiency in large-scale projects. By 2023–2025, generative AI models, such as adaptations of large language models, began assisting in generating and refining requirements from initial prompts, with systematic reviews documenting their integration for tasks like and validation, though challenges in accuracy persist.

The Elicitation Process

Preparation and Planning

Preparation and planning form the foundational phase of requirements elicitation, ensuring that subsequent activities are targeted, efficient, and aligned with project objectives. This phase involves defining the boundaries of the elicitation effort, assembling necessary resources, and mitigating potential obstacles to facilitate meaningful stakeholder interactions. According to the BABOK Guide, the purpose of preparing for elicitation is "to understand the scope of the elicitation activity, select appropriate techniques, and plan for (or procure) appropriate supporting materials and resources," which helps business analysts create an elicitation activity plan as the primary output. This planning draws on inputs such as stakeholder engagement approaches and business needs to establish a structured framework that minimizes ambiguities and enhances the quality of gathered information. Stakeholder identification is a critical initial step, involving the systematic mapping of individuals or groups who may influence or be affected by the system under development. Techniques such as stakeholder analysis matrices are employed to categorize stakeholders by their roles, levels of influence, power, and specific needs, enabling prioritization based on potential impact on project outcomes. For instance, the RACI (Responsible, Accountable, Consulted, Informed) matrix can be applied to clarify responsibilities in the elicitation process, assigning clear roles to stakeholders for activities like providing input or reviewing outputs, thereby reducing conflicts and ensuring comprehensive representation. This approach, as outlined in requirements engineering literature, helps identify critical stakeholders—such as end-users or regulators—who must be involved early to avoid gaps in requirements coverage. In global or distributed teams, additional consideration is given to cultural and geographical factors that might affect participation. Scope definition establishes the project's boundaries, objectives, and specific goals for the elicitation to prevent scope creep and focus efforts on relevant areas. This includes delineating the business domain, organizational culture, environmental constraints, and solution scope, often documented in a vision and scope statement that outlines high-level needs and assumptions. By clearly articulating what is in and out of bounds, planners ensure that elicitation targets verifiable requirements without unnecessary expansion. The BABOK Guide emphasizes confirming the scope with key stakeholders to align expectations and set measurable objectives for the elicitation outcomes. Resource allocation encompasses selecting tools, assigning team roles, and scheduling sessions to support effective elicitation. Business analysts, facilitators, and subject matter experts are typically designated, with tools like meeting software (e.g., virtual collaboration platforms) or recording devices procured to accommodate session formats. planning covers participant availability, session agendas, and locations—virtual or in-person—to optimize engagement. This allocation ensures that resources match the chosen approach, such as allocating time for preparation in complex projects involving multiple stakeholder groups. Risk assessment identifies potential issues that could undermine the elicitation process, such as stakeholder unavailability, biases, or gaps, particularly in diverse teams where cultural differences may influence communication. The BABOK Guide recommends using risk analysis to evaluate disruptions, like incomplete participation, and developing mitigation strategies, such as backup scheduling or alternative engagement methods. Early identification of these risks allows for proactive adjustments, ensuring the reliability of the elicited data. Documentation setup involves preparing standardized templates and tools for capturing raw elicitation data, such as requirement logs or matrices, to maintain consistency and from the outset. These templates typically include fields for stakeholder sources, requirement descriptions, and initial priorities, facilitating organized storage and later analysis. By establishing these formats in advance, planners enable efficient recording during sessions and support the transition to validation phases.

Execution and Data Collection

The execution phase of requirements elicitation involves direct engagement with stakeholders through scheduled interactive sessions, such as semi-structured interviews or workshops, where analysts employ and probing questions like "why" and "how" follow-ups to uncover underlying needs and clarify ambiguities. These interactions aim to elicit that stakeholders may not initially articulate, fostering a collaborative environment to gather comprehensive insights into . During these sessions, various data types are collected to capture raw requirements information, including verbal inputs from discussions, written feedback through questionnaires or notes, observational records of stakeholder behaviors in real or simulated settings, and existing artifacts such as process documents or prototypes. This multifaceted approach ensures a broad spectrum of evidence, from explicit statements to implicit patterns, which forms the foundation for subsequent analysis. Effective session facilitation is crucial to maintain productivity and inclusivity, involving the management of by resolving conflicts through of key stakeholder inputs, discussions to adhere to project schedules, and implementing recording mechanisms such as audio transcription or structured note-taking protocols to document proceedings accurately. Skilled facilitators, often experienced requirements engineers, guide these sessions to encourage balanced participation and prevent dominance by individual voices. The process is inherently iterative, with multiple rounds of engagement conducted to refine initial data captures, particularly in agile development contexts where feedback loops integrate ongoing stakeholder input to evolve requirements progressively. This repetition allows for validation of early findings and adaptation to emerging insights, enhancing the completeness and relevance of the collected data. Ethical considerations underpin the execution phase, requiring explicit consent from stakeholders for and usage, as well as strict measures to ensure of sensitive information shared during interactions. These practices align with normative ethical principles, mitigating risks of and building trust, especially when dealing with diverse or vulnerable stakeholder groups.

Analysis and Validation

Following the collection of raw inputs from stakeholders, the analysis phase begins with data categorization to organize disparate ideas into coherent groups. This involves sorting elicited requirements, observations, and feedback into logical categories to identify patterns and reduce redundancy. A common technique is affinity diagramming, where team members post notes representing individual requirements on a board and iteratively group similar items based on thematic affinity, fostering collaborative insight into user needs. This method, rooted in contextual design practices, helps transform into hierarchical representations that reflect stakeholder priorities without imposing preconceived structures. Conflict resolution addresses discrepancies arising from diverse stakeholder perspectives, ensuring alignment on requirements. techniques facilitate discussion to reconcile differing views, often through structured dialogues that clarify assumptions and trade-offs. matrices, such as the —which categorizes requirements as Must have (essential for success), Should have (important but not vital), Could have (desirable if time permits), or Won't have (out of scope)—provide a framework for resolving conflicts by assigning relative importance and deferring non-critical items. This approach, integrated with in some extensions, quantifies stakeholder agreement and minimizes bias in . Effective resolution prevents and builds consensus, with to records for future reference. Validation techniques verify the completeness, accuracy, and feasibility of analyzed requirements through iterative feedback. Reviews and walkthroughs involve stakeholders examining documented requirements in structured sessions to detect ambiguities or omissions, often using checklists aligned with attributes like clarity and consistency. Prototypes serve as tangible models to elicit further validation, allowing users to interact with mockups and provide refinements that confirm alignment with needs. These methods create feedback loops, with prototyping identified as the most adopted validation approach in empirical studies due to its ability to reveal unarticulated requirements early. Establishing links validated requirements back to their original sources, such as stakeholder interviews or prototypes, enabling auditability and impact analysis. This bidirectional mapping—forward to design elements and backward to elicitation artifacts—supports and compliance verification. Tools and matrices facilitate this by documenting relationships, ensuring that modifications propagate correctly across the development lifecycle. In practice, enhances , as demonstrated in collaborative environments where it coordinates updates among distributed teams. Finally, output preparation refines validated requirements into structured formats for downstream use. Raw data is transformed into user stories—concise descriptions following the format "As a [user], I want [feature] so that [benefit]"—to promote agile implementation and ongoing refinement. Alternatively, use cases detail scenarios with actors, preconditions, and postconditions to specify functional flows comprehensively. These outputs, often derived through iterative evolution from initial ideas, ensure requirements are actionable and testable.

Techniques and Methods

Traditional Techniques

Traditional techniques in requirements elicitation form the bedrock of practices, focusing on individual or artifact-based methods to systematically gather stakeholder needs without relying on or advanced tools. These approaches, which gained prominence in the structured phases of projects during the 1980s, prioritize depth and precision in capturing requirements through personal interaction or review of existing materials. In such projects, techniques like interviews often dominated the upfront requirements phase to establish comprehensive specifications before proceeding to and . Interviews remain one of the most widely adopted traditional methods, enabling direct dialogue between analysts and stakeholders to uncover explicit and implicit requirements. They are categorized into three formats: structured interviews, which employ predefined closed questions to ensure consistency and facilitate quantitative analysis; semi-structured interviews, blending fixed queries with open-ended follow-ups to balance standardization and adaptability; and unstructured interviews, characterized by free-form discussions using open questions to explore unanticipated insights. The primary advantages include their capacity to provide in-depth understanding, clarify ambiguities on the spot, and build rapport for ongoing elicitation, making them particularly effective for complex or novel domains. However, drawbacks encompass high time consumption, dependency on interviewer expertise to mitigate bias, and potential for limited scalability due to one-on-one nature. In 1980s waterfall projects, such as those involving knowledge acquisition for management information systems, structured interviews were frequently used to systematically document user needs, aligning with the model's emphasis on sequential, verifiable phases. Surveys and questionnaires offer a scalable alternative for eliciting requirements from larger or dispersed stakeholder groups, typically through distributed forms containing standardized questions. Design principles emphasize clarity and brevity, incorporating multiple-choice options for categorical responses, Likert scales (e.g., 5-point agreements from "strongly disagree" to "strongly agree") to gauge attitudes quantitatively, and a mix of open and closed questions to capture both structured data and qualitative nuances. Distribution can occur via offline methods like mailed paper forms or, in later adaptations, online platforms for broader reach. Analysis involves statistical tools for quantitative responses, such as frequency distributions for multiple-choice items or mean scores for Likert scales, enabling pattern identification across responses. Advantages include cost-effectiveness, anonymity to encourage honest input, and efficiency in handling diverse populations, though limitations arise from shallow depth, risk of misinterpretation without clarification, low response rates, and inability to probe responses dynamically. These techniques were integral in 1980s waterfall initiatives for validating initial interview findings across user bases in large-scale system developments. Document analysis involves systematically reviewing existing artifacts, such as organizational policies, user manuals, specifications, or procedural guidelines, to extract implied or explicit requirements. This method uncovers baseline needs by identifying gaps, consistencies, or historical precedents in the materials, often serving as a preparatory step before direct . Its strengths lie in being non-intrusive and inexpensive, providing objective context when primary stakeholders are unavailable, and allowing cross-verification of other elicitation outputs. Conversely, it can be time-intensive to navigate voluminous or disorganized documents, and the information may be outdated, incomplete, or biased toward the "as-is" state rather than future needs. In projects of the , document analysis was commonly applied to analyze prior system documentation for enhancements, ensuring in sequential development cycles. , also known as direct observation in the Project Management Body of Knowledge (PMBOK) Guide's Collect Requirements process, is a technique involving the systematic observation of users in their work environment without interfering in their routine to capture implicit needs, real processes, and behaviors that may not be revealed in interviews or questionnaires. It can be passive (no interaction with the subjects) or active (involving interactions such as asking questions during the process). This approach is particularly useful when stakeholders cannot clearly explain their needs or processes, especially in software or systems projects. Often implemented as shadowing or direct watching of users in their natural work environment, it captures real-time behaviors, workflows, and unspoken needs that may not surface through verbal methods. Analysts monitor tasks to document processes, pain points, and inefficiencies, sometimes combining it with minimal or post-observation debriefs. Benefits encompass high reliability, authentic insights into actual usage, revelation of , effective capture of implicit requirements, and minimal disruption when conducted unobtrusively, proving valuable for understanding contextual requirements. Drawbacks include its time-consuming nature, often requiring multiple sessions, resource intensity, potential for or Hawthorne effects (altered behavior under scrutiny), and limitation to observable current practices without revealing future aspirations. Ethical guidelines stress obtaining from participants, respecting by avoiding sensitive data capture, and ensuring observations do not interfere with operations. During 1980s eras, shadowing was employed in projects like process re-engineering for enterprise systems to baseline existing operations before specifying new requirements.

Collaborative and Group Techniques

Collaborative and group techniques in requirements elicitation involve structured interactions among multiple stakeholders to generate, refine, and validate requirements through shared discussion and consensus-building, leveraging collective expertise to address diverse perspectives. These methods emphasize facilitation to ensure equitable participation and mitigate biases, often resulting in higher stakeholder buy-in compared to individual approaches. Workshops and Joint Application Development (JAD) sessions are facilitated meetings designed to elicit requirements efficiently by bringing together users, developers, and analysts in a structured environment with predefined agendas. In JAD, key roles include a neutral facilitator to guide discussions, a to document outputs, and participants representing various stakeholders to provide input on workflows, elements, and features. The process typically spans phases such as preparation, session execution focusing on open issues, and documentation, yielding outcomes like joint agreements on functional requirements and reduced ambiguities through real-time resolution. Studies show these sessions are most effective in small, focused projects, with improvements in requirements definition and efficiency observed in 10-30% of projects, though they require skilled to avoid developer dominance. Brainstorming and focus groups facilitate idea generation by assembling stakeholders in moderated sessions that encourage free-flowing input without immediate criticism, adhering to rules like deferring judgment to promote creativity. In brainstorming, participants rapidly propose ideas on system expectations, moderated to prevent dominant voices from overshadowing quieter contributors, followed by post-session synthesis to prioritize and refine outputs into actionable requirements. Focus groups, similarly, involve targeted discussions among 5-10 experts to explore needs and build consensus, with the moderator ensuring balanced participation and summarizing key themes for validation. These techniques excel at revealing conflicts early and generating diverse ideas, though they demand careful handling of biases to maintain objectivity. Prototyping serves as a collaborative tool where stakeholders iteratively review low-fidelity mocks, such as sketches or wireframes, to elicit feedback on and through guided walkthroughs. This approach allows groups to visualize requirements early, fostering bidirectional communication and refining designs based on collective reactions, often reducing elicitation time by enabling quick iterations. Participants discuss prototypes in sessions, identifying gaps or preferences, which leads to more intuitive and user-committed specifications. The employs anonymous, iterative surveys among experts to achieve consensus on requirements prioritization without direct confrontation, typically involving 3-5 rounds of feedback and refinement. In the first round, requirements are elicited broadly; subsequent rounds present aggregated responses for experts to adjust rankings anonymously, converging on agreed priorities while minimizing group influence. This technique suits dispersed stakeholders and produces precise specifications by eliminating disputes, though it requires to manage complexity. Overall, these techniques enhance and requirement completeness by promoting shared understanding, as seen in agile retrospectives where group consensus strengthens team alignment. Advantages include faster feedback and reduced inconsistencies through diverse input, particularly in small groups of 2-3 analysts that optimize creativity and coverage. However, risks such as , dominant participants, and higher costs in larger sessions can undermine effectiveness, necessitating skilled facilitation to balance dynamics.

Advanced and AI-Assisted Techniques

has emerged as a scalable method for gathering diverse stakeholder inputs in requirements elicitation by leveraging online platforms to solicit feedback from large, distributed groups. This approach often involves posting structured queries, such as user stories or feature requests, on platforms like or , where participants contribute ideas asynchronously. For instance, pull-based feedback mechanisms allow crowds to refine requirements through iterative voting and commenting, enhancing inclusivity for global projects. A systematic mapping study identified 's potential for just-in-time , particularly in market-driven , by enabling rapid collection of user preferences without traditional workshops. Social media analysis complements by mining from platforms for implicit requirements, using basic to gauge user opinions on features. Techniques involve extracting posts and reviews via APIs, then applying keyword matching or polarity scoring to identify positive, negative, or neutral sentiments toward existing systems. Aspect-based , for example, categorizes feedback by specific product attributes like or , revealing unmet needs in app reviews. This method supports proactive elicitation in consumer-facing software, where provides real-time insights into evolving demands. Natural Language Processing (NLP) tools advance elicitation by automating the of interview transcripts and documents to detect ambiguities, inconsistencies, and key entities. Algorithms such as and dependency identify stakeholders, actions, and constraints in raw text, flagging vague phrases like "user-friendly" for clarification. models, including supervised classifiers, further enable pattern detection across datasets, such as clustering similar requirements from multiple sources to uncover hidden themes. These techniques reduce manual effort in analysis. Generative AI, particularly adaptations of GPT models since 2023, facilitates requirement drafting and simulation by processing prompts to produce structured outputs like use cases or user stories. For example, models can ingest stakeholder descriptions to generate initial requirement sets, incorporating to suggest non-obvious constraints. In simulating dialogues, AI acts as a virtual stakeholder, probing for details in iterative conversations to refine ambiguous inputs. A highlights GPT's role in RE tasks, with applications in elicitation. Interface analysis and reverse engineering employ specialized tools to examine existing systems for implied requirements, focusing on user interactions and data flows. Tools like API proxies (e.g., ) capture and dissect communication protocols, while disassemblers (e.g., ) reverse-compile binaries to reveal undocumented functionalities. This method uncovers legacy constraints or integration points, essential for modernization projects, by mapping observed behaviors to formal . In practice, it integrates with elicitation to validate stakeholder claims against actual system outputs, minimizing gaps in functional coverage. As of 2025, trends in requirements elicitation emphasize (VR) integration for immersive prototyping, allowing stakeholders to interact with 3D models to elicit feedback on spatial and experiential requirements. VR platforms enable remote , where users simulate workflows in virtual environments to reveal issues early. Ethical AI use has gained prominence, with strategies like diverse training datasets and fairness audits ensuring equitable elicitation outcomes, particularly in diverse stakeholder groups. Case studies from AI-driven pipelines, such as automated requirement extraction in workflows at firms, demonstrate efficiency gains by embedding NLP and generative models for continuous feedback loops.

Challenges in Requirements Elicitation

Common Pitfalls

Communication barriers frequently undermine requirements elicitation, as differences in , , and perspectives between stakeholders and analysts lead to misinterpretations. For instance, technical can create a "culture gap" between users' everyday language and analysts' specialized terms, resulting in incomplete or distorted requirements. According to a 1992 SEI report, 56% of errors in installed systems were due to poor communication between users and analysts, which reportedly required up to 82% of staff time for corrections in some studies. Additionally, —unarticulated assumptions held by stakeholders—remains unexpressed, exacerbating misunderstandings and contributing to defects in 12-71% of software project failures. Stakeholder-related issues compound these challenges, including incomplete identification of all relevant parties, their unavailability during elicitation, or conflicting priorities among groups such as users, developers, and sponsors. Excluding end-users, for example, often results in gaps, as their practical insights are overlooked in favor of managerial or technical viewpoints. Resistance from stakeholders, driven by power dynamics or lack of commitment, further hinders and accurate need articulation. Ambiguity and incompleteness plague elicited requirements, with vague phrasing like "user-friendly" lacking measurable criteria, rendering them untestable and prone to varied interpretations. Natural language's inherent ambiguities, such as synonyms or homonyms, amplify this, while evolving stakeholder needs introduce , expanding requirements beyond initial bounds without clear boundaries. Incompleteness arises when stakeholders articulate only partial needs, leaving critical elements unaddressed and increasing risks. Feasibility oversights occur when early elicitation ignores technical, resource, or environmental constraints, leading to requirements that prove impractical during later stages. Stakeholders may demand unneeded or unfeasible features misaligned with organizational capabilities, complicating and integration. In contemporary contexts as of 2025, over-reliance on AI-assisted elicitation introduces pitfalls such as overlooking human nuances in requirements, where AI's limited explainability fails to capture evolving or context-specific stakeholder values. This can also precipitate data breaches, as AI tools process sensitive without adequate safeguards for non-deterministic human-AI interactions.

Strategies to Overcome Challenges

One effective to mitigate incomplete or biased requirements is adopting a multi-technique approach, which involves combining diverse elicitation methods such as interviews, prototypes, and workshops to achieve and validate findings across sources. This helps cross-verify stakeholder inputs, reducing the of overlooking critical needs or introducing errors from a single method's limitations. A practical guideline in projects is to employ multiple complementary techniques to ensure comprehensive coverage and robustness in the elicited requirements. To address communication barriers and ambiguities during elicitation, analysts should prioritize techniques, including paraphrasing stakeholder statements to confirm understanding and probing for clarification on vague responses. Complementing this, the use of structured requirement checklists, such as the VOLERE template, promotes completeness by systematically covering functional, non-functional, and constraint aspects of requirements. The VOLERE framework, developed by Suzanne and James Robertson, includes detailed prompts for attributes like rationale, originator, and fit criteria, ensuring elicited requirements are precise and verifiable. When stakeholder conflicts arise over competing priorities, applying prioritization frameworks like the can categorize requirements into must-be, one-dimensional, and attractive types based on their impact on user satisfaction, facilitating consensus on what to implement first. Alternatively, value versus effort matrices plot requirements on axes of (e.g., impact or user benefit) against development effort (e.g., time or resources), identifying quick wins in the high-value, low-effort quadrant while deprioritizing low-value, high-effort items. Ensuring requirements remain aligned with evolving needs requires continuous validation through early prototyping and iterative feedback loops, where stakeholders review tangible models or mockups to confirm interpretations. In agile environments, practices like sprint reviews provide structured opportunities at the end of each for stakeholders to inspect deliverables, discuss adaptations, and validate progress against initial requirements. This iterative validation minimizes drift and incorporates changes incrementally, enhancing overall requirement quality. Finally, equipping requirements analysts with training in soft skills—such as empathy, negotiation, and facilitation—is essential to navigate diverse stakeholder dynamics effectively. Organizations like the International Institute of Business Analysis (IIBA) emphasize interpersonal competencies alongside technical knowledge in their competency models for business analysts. As of 2025, best practices emphasize ethical considerations in hybrid human-AI workflows, including human oversight to mitigate biases and ensure fairness when using AI tools for requirements elicitation (e.g., via natural language processing for pattern detection).

Eliciting Specific Requirement Types

Functional Requirements

Functional requirements specify the behaviors and functions that a system must perform to meet user needs and business objectives, focusing on what the system does rather than how it performs. These requirements are action-oriented, describing specific operations such as , user interactions, or responses to inputs; for example, "The shall process a payment transaction by deducting funds from the user's account and crediting the merchant's account." They must be verifiable through testing to confirm compliance, atomic to represent indivisible units of functionality without decomposition into sub-tasks, and traceable to higher-level business goals or stakeholder needs for ongoing management and impact analysis. Elicitation of functional requirements often employs use cases and scenarios to capture system interactions with users or external entities. Use cases outline sequences of actions, including actors (e.g., users or systems), preconditions, basic flows, alternative paths, and exceptions, typically visualized in UML use case diagrams where ovals represent use cases like "log in" or "process order," connected to actor stick figures. In agile environments, user story mapping facilitates elicitation by organizing user stories—concise descriptions in the format "As a [user], I want [function] so that [benefit]"—into visual maps that align stories with user journeys and prioritize them iteratively. This approach defers detailed specifications, using stories as conversation starters to refine functional needs through team collaboration. In systems, functional requirements might include "The user shall log in via and password, with the system authenticating credentials and granting access to the account dashboard," which traces to broader processes like user and secure transaction enablement. Another example is "The system shall add selected items to the upon user confirmation, updating the cart total in real-time," linking to and fulfillment processes to support generation. Validation of functional requirements emphasizes ensuring completeness and avoiding over-specification to maintain clarity and feasibility. Completeness is assessed using traceability matrices that map requirements to test cases, user needs, and business objectives, confirming all functions are covered without gaps. Over-specification is mitigated by adhering to appropriate levels, such as user-goal atomicity, preventing unnecessary details that could inflate implementation costs or introduce inconsistencies. Techniques like prototyping and stakeholder reviews further verify that requirements accurately reflect intended behaviors. Elicitation approaches differ by project context: in structured, predictive methodologies like , functional requirements are elicited upfront through detailed and , aiming for comprehensive specifications early to minimize changes. In contrast, agile iterative processes elicit them incrementally via ongoing collaboration, refining user stories in sprints to adapt to evolving needs while maintaining .

Non-Functional Requirements

Non-functional requirements (NFRs) specify the qualities, constraints, and performance attributes that a must exhibit, rather than its specific behaviors, making their elicitation essential for ensuring overall viability. Unlike functional requirements, which define what the system does, NFRs address how well it performs, often influencing decisions across the entire . Eliciting NFRs requires targeted approaches to capture stakeholder expectations on aspects like speed, , and , as these are frequently implicit or overlooked during initial discussions. Common categories of NFRs include performance efficiency, , , and reliability, as outlined in the ISO/IEC 25010:2023 standard for systems and models. For performance, requirements might mandate response times under 2 seconds for user interactions to maintain efficiency in high-traffic environments. NFRs often reference standards like the (WCAG) 2.2, requiring conformance to Level AA for perceivable, operable, understandable, and robust content to support diverse users. NFRs typically demand adherence to protocols such as those in NIST's cryptographic standards, including AES-256 encryption for data transmission to protect against unauthorized access. Reliability requirements could specify 99.9% uptime over a monthly period, ensuring minimal disruptions in mission-critical applications. Elicitation of NFRs commonly employs checklists derived from the ISO 25010 quality model to systematically probe stakeholders on each characteristic, facilitating comprehensive coverage without omission. against industry standards, such as comparing load times to established benchmarks, helps set realistic thresholds informed by peer systems. Stakeholder workshops are particularly effective for negotiating trade-offs, where participants discuss conflicts like balancing enhancements against impacts, using techniques like pairwise comparison to prioritize. Unique challenges in eliciting NFRs stem from their inherent subjectivity and difficulty in measurement, as qualities like "intuitive" interfaces resist precise quantification compared to functional outputs. Stakeholders may struggle to articulate vague preferences, leading to incomplete specifications that propagate risks into development. A notable example is the 2012 Knight Capital incident, where inadequate elicitation of reliability and performance NFRs—such as robust error-handling and deployment safeguards—resulted in a software causing over $460 million in erroneous trades within 45 minutes due to unmitigated system controls. To integrate NFRs effectively, they are often linked to functional requirements through mechanisms like security wrappers that embed around core functionalities without altering behaviors. employs cost-benefit models, evaluating the trade-offs in effort versus gains, such as weighing the expense of for reliability against potential costs. As of 2025, elicitation practices increasingly emphasize NFRs, such as energy-efficient algorithms to reduce carbon footprints, guided by catalogs like NFR4SUSTAIN that map requirements to environmental impacts. Similarly, AI requirements focus on , requiring elicitation of fairness metrics like demographic parity in outputs to prevent discriminatory outcomes.

References

  1. https://link.springer.com/content/pdf/10.1007/3-540-28244-0_2.pdf
  2. https://www.sei.cmu.edu/documents/1564/1994_011_001_16238.pdf
  3. https://ieeexplore.ieee.org/document/10771003
  4. https://ieeexplore.ieee.org/document/9676192
  5. https://ieeexplore.ieee.org/document/8513829
  6. https://link.springer.com/chapter/10.1007/3-540-28244-0_2
  7. https://ieeexplore.ieee.org/document/7856459/
  8. https://www.computer.org/csdl/proceedings-article/re/2017/3191a476/12OmNqC2uTH
  9. https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/iet-sen.2017.0144
  10. https://link.springer.com/article/10.1007/s00766-022-00381-9
  11. https://www.researchgate.net/publication/360911377_The_Stakeholder-Profile_Framework_for_Tacit_Knowledge_Acquisition_in_Requirements_Elicitation_Interviews
  12. https://ieeexplore.ieee.org/book/5989265
  13. http://ieeexplore.ieee.org/document/855582/
  14. https://dl.acm.org/doi/10.5555/539425
  15. https://dl.acm.org/doi/book/10.1145/539289
  16. https://dl.acm.org/doi/pdf/10.1145/153571.163265
  17. https://standards.ieee.org/ieee/830/1222/
  18. https://link.springer.com/article/10.1007/s00766-023-00396-w
  19. https://dl.acm.org/doi/10.1145/3444689
  20. https://arxiv.org/abs/2409.06741
  21. https://www.iiba.org/knowledgehub/business-analysis-body-of-knowledge-babok-guide/4-elicitation-and-collaboration/4-1-prepare-for-elicitation/
  22. https://business-analysis-excellence.com/wp-content/uploads/2020/04/Week-2-Requirements-Elicitation-and-Collaboration.pdf
  23. https://www.adaptiveus.com/blog/raci-matrix/
  24. https://www.ifi.uzh.ch/dam/jcr:3fd4da15-79bf-4870-90d0-f251a7d1a1a8/GlinzWieringa2007.pdf
  25. https://link.springer.com/article/10.1007/s00766-019-00326-9
  26. https://scholarsjunction.msstate.edu/cgi/viewcontent.cgi?article=6656&context=td
  27. https://ieeexplore.ieee.org/document/6636709
  28. https://www.wiley.com/en-us/Requirements+Engineering%3A+Processes+and+Techniques-p-9780471972082
  29. https://link.springer.com/chapter/10.1007/978-3-031-42307-9_19
  30. http://nuchi.acm.org/2005/01mtg/XPUni2004Beyer4.pdf
  31. https://link.springer.com/chapter/10.1007/978-3-031-08169-9_2
  32. https://ieeexplore.ieee.org/document/8342602
  33. https://ieeexplore.ieee.org/document/9558838
  34. https://ieeexplore.ieee.org/iel7/6287639/9312710/09558838.pdf
  35. https://link.springer.com/article/10.1007/s00766-018-0306-1
  36. https://link.springer.com/article/10.1007/s00766-022-00383-7
  37. https://thesai.org/Downloads/Volume9No1/Paper_45-Requirement_Elicitation_Techniques_for_Open_Source_Systems.pdf
  38. https://scholar.google.com/scholar_lookup?&title=Knowledge%20acquisition%20using%20structured%20interviewing%3A%20An%20empirical%20investigation&journal=Journal%20of%20Management%20Information%20Systems&volume=7&issue=1&pages=123-140&publication_year=1990&author=Agarwal%2CR.&author=Tanniru%2CM.R.
  39. https://jyx.jyu.fi/bitstreams/2326ca20-60bd-4426-8fc8-a73891024b74/download
  40. https://opus.lib.uts.edu.au/rest/bitstreams/da901b5d-21c8-42a8-9cb3-4aff2f23eab7/retrieve
  41. https://www.businessanalyststoolkit.com/wp-content/uploads/2020/08/701-Elicitation-Techniques.pdf
  42. https://www.pmmajik.com/project-requirement-gathering-observations/
  43. https://brainsensei.com/all-you-need-to-know-about-the-collect-requirements-process/
  44. https://dl.acm.org/doi/pdf/10.1145/336512.336523
  45. https://www.researchgate.net/publication/335418911_A_Review_and_Comparison_of_the_Traditional_Collaborative_and_Online_Collaborative_Techniques_for_Requirement_Elicitation
  46. https://www.sei.cmu.edu/documents/424/2013_019_001_297234.pdf
  47. https://www.sciencedirect.com/science/article/abs/pii/S0164121298100808
  48. https://www.researchgate.net/publication/287718449_A_Proposed_Process_Model_for_Requirements_Engineering_using_Delphi_Techniques_for_Prioritisation
  49. https://www.sciencedirect.com/science/article/pii/S0950584923000836
  50. https://onlinelibrary.wiley.com/doi/full/10.1002/smr.2199
  51. https://link.springer.com/article/10.1007/s00766-022-00384-6
  52. https://www.sciencedirect.com/science/article/pii/S0952197625006323
  53. https://dl.acm.org/doi/10.1145/3418994.3419004
  54. https://arxiv.org/pdf/2202.05065
  55. https://research.manchester.ac.uk/files/183513868/2020_12_16_NLP4RE_Accepted.pdf
  56. https://arxiv.org/html/2511.01324v3
  57. https://arxiv.org/html/2409.06741v1
  58. https://dl.acm.org/doi/10.1145/3696673.3723053
  59. https://www.apriorit.com/dev-blog/366-software-reverse-engineering-tools
  60. https://blog.dreamfactory.com/reverse-engineering-apis-the-benefits-and-tools
  61. https://ieeexplore.ieee.org/document/9974443
  62. https://dl.acm.org/doi/10.1145/3649595
  63. https://www.brookings.edu/articles/algorithmic-bias-detection-and-mitigation-best-practices-and-policies-to-reduce-consumer-harms/
  64. https://smartdev.com/ai-use-cases-in-devops/
  65. https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=12785
  66. https://ieeexplore.ieee.org/document/5633807
  67. https://www.researchgate.net/publication/281965015_Requirements_Elicitation_Problems_A_Literature_Analysis
  68. https://www.scitepress.org/Papers/2023/118423/118423.pdf
  69. https://dl.acm.org/doi/10.1145/1167948.1167980
  70. https://link.springer.com/article/10.1007/s10664-018-9620-y
  71. https://www.volere.org/templates/volere-requirements-specification-template/
  72. https://www.volere.org/
  73. https://www.sciencedirect.com/science/article/pii/S0164121220302417
  74. https://www.iiba.org/business-analysis-blogs/6-skills-for-your-everyday-business-analysis-practices/
  75. https://dl.acm.org/doi/full/10.1145/3719006
  76. https://re-magazine.ireb.org/articles/functional-requirements-and-their-levels-of-granularity
  77. http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
  78. https://www.altexsoft.com/blog/functional-and-non-functional-requirements-specification-and-types/
  79. https://www.mountaingoatsoftware.com/articles/advantages-of-user-stories-for-requirements
  80. https://www.geeksforgeeks.org/software-engineering/software-engineering-requirements-validation-techniques/
  81. https://www.engr.colostate.edu/~drherber/files/Rosson2025a.pdf
  82. https://www.researchgate.net/publication/252044757_A_survey_on_issues_in_non-functional_requirements_elicitation
  83. https://www.w3.org/TR/WCAG22/
  84. https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines
  85. https://ksiresearch.org/seke/seke16paper/seke16paper_195.pdf
  86. https://www.perforce.com/blog/alm/what-are-non-functional-requirements-examples
  87. https://www.designgurus.io/answers/detail/how-to-capture-non-functional-requirements
  88. https://link.springer.com/article/10.1007/s00766-020-00333-1
  89. https://www.sec.gov/files/litigation/admin/2013/34-70694.pdf
  90. https://link.springer.com/chapter/10.1007/978-3-540-73031-6_20
  91. https://dl.acm.org/doi/10.1145/3672608.3707916
Add your contribution
Related Hubs
User Avatar
No comments yet.