Requirements Elicitation Quiz

Requirements Elicitation Challenges

• Requirements elicitation is complicated by three common syndromes
• The "Yes, But" syndrome: Users initially express enthusiasm but quickly identify potential improvements or features; this stems from human nature and the user's inability to fully visualize the software's functionality until it's complete
• The "Undiscovered Ruins" syndrome: Searching for requirements is like searching for hidden treasures; the more you find, the more you realize there are still more to uncover. This arises from the fact there may be initially hidden or unknown needs.
• The "User and the Developer" syndrome: A profound gap in communication arises due to differing perspectives, backgrounds, motivations, and objectives; users and developers often view systems in the context of their different worlds, which can cause hurdles in understanding.

Requirements Elicitation Process

• Requirements elicitation is the process of gathering and uncovering specific needs for a system through communication with stakeholders, including customers, users, and other invested individuals.

Bridging the Gap Between Users and Developers

• Collaboration between users and developers with varied backgrounds is crucial for the process
• Users with application domain knowledge: possess in-depth understanding of the specific application domain
• Developers with solution domain knowledge: possess deep familiarity with software development methodologies and approaches
• Utilizing scenarios and use cases allows linking the user perspective with technical requirements.
• Scenarios demonstrate a step-by-step description of system usage.
• Use cases offer a high-level view of functionality performed by several scenarios.

Requirements Process Stages

• Requirements Elicitation: Defining the system in consumer-friendly terms (problem description)
• Requirements Analysis: Defining the system technically in terms the developer understands (problem specification).

Requirements Engineering

• Requirements elicitation, analysis, specification, verification, and management are all sequential stages in the process.

Difficulties in Requirements Engineering

• Businesses operate in dynamic environments with evolving requirements for support systems
• Multiple stakeholders with differing priorities/goals frequently participate in the process
• Requirements are often influenced by political factors and organizational considerations that stakeholders might not admit openly

Requirements Change

• System requirements reflect the outside world; therefore, changes outside the system frequently lead to evolving requirements.
• These changes stem from multiple external factors, including technology updates, organizational changes, shifts in the market, economic fluctuations, and modifications in the political or legal contexts.

Barriers to Requirements Elicitation

• The "Yes, But" syndrome: Users initially express enthusiasm but quickly identify potential improvements or features.
• The "Undiscovered Ruins" syndrome: There exist hidden needs or unknown user issues that surface upon investigation.
• The "User and Developer" syndrome: Users and developers often hold different perspectives regarding the system.

The "Yes, But" Syndrome

• Two immediate reactions often occur when users first encounter a system: awe and criticism; this is fundamental human nature.
• Acknowledge anticipated "buts", and allocate resources for feedback.
• Software, unlike physical tools, doesn't gain real-world meaning unless it's complete.
• Addressing "yes, buts" early is key

The "Undiscovered Ruins" Syndrome

• Teams struggle to determine when they've captured all critical requirements.
• First, identify the core problems to be solved by the system.
• Next, uncover hidden needs and stakeholder inputs.

The "User and Developer" Syndrome

• Users and developers come from different backgrounds, perspectives, and speaking different terminologies.
• There is a notable communication gap between them.

The User and Developer Syndrome: Solutions

• The user is a recognized domain expert who can provide valuable insight
• Alternative communication and selection methods can improve understanding.
• Early implementation of user-centered techniques like storyboarding, role-playing, and prototypes can facilitate effective collaboration and requirements elicitation.
• By placing the analyst in the user's role, one can gain a more profound understanding of user needs and concerns.

What's Next?

• Exploring interviewing techniques, including conducting interviews.
• Exploring workshops for identifying needs, brainstorming ideas, and reducing complexity.
• Examining the process of storyboarding.
• Discussing product or system features

Key Points: Product or System Features

• The development team must actively participate in the elicitation of system requirements.
• Product or system features are high-level expressions of intended system functionality.
• Limit the number of system features to values between 25 and 99 for clarity, simplicity, and reduction in complexity.

Stakeholder and User Needs

• The reflection of business, personal, and operational issues—both problems and opportunities— driving the justification for creating a system.
• Examples include streamlining inventory management and improving sales order entry efficiency.

Problem and Solution Domains

• Users' needs (in their terms) form the basis of the Problem Domain.
• System features, which fulfill user needs, belong in the Solution Domain.
• Software requirements connect these domains.

Features

• Features are services provided by a system to address one or more stakeholder needs.
• Users frequently conflate features with requirements, but understanding the differentiation between needs and features is critical.
• Features are convenient for describing functionality without getting bogged down in details or complexities.
• High-level abstractions are used to describe functionality and services.

Examples of Features

• Application domains such as elevator control systems, inventory management, defect tracking, payroll, home lighting automation, weapons control, or shrink-wrap application designs are key use cases.
• Examples of features related to these domains include manual control during emergencies or situations requiring system shutdown; the ability to track inventory levels; or to track defects and associated analysis.

Managing Complexity

• Limit the number of features to help avoid getting bogged down in the specifics of every nuance.
• Attributes allow for detailed tracking of additional information about features.

Interviewing

• Interviewing is a direct technique for gathering information
• Use context-free questions to avoid biasing the interviewee.
• Interviews are not substituted for questionnaires.
• It can discover undisclosed needs, enhance requirements comprehension, and initiate required changes.

Interviewing Steps

• Planning: Determine who should be interviewed, establish interview goals and objectives, prepare questions, and gather related documents
• Conducting: Introduce yourself and explain the process. Ask open-ended and closed-ended questions
• Follow-up: Summarize next steps and document the interview, evaluate the interview's effectiveness

Context-Free Questions

• Explore the system's scope and potential value.
• Understand the problem and its environmental context.

Effective Interviewers

• Interviewers should be open-minded and actively listen and should avoid pre-conceived ideas.
• Guide the interview with effective prompts to facilitate discussion of system requirements.
• Interviewing teams should have defined roles (e.g., questioners, note-takers).

Interviewing Continued

• Sufficient time should be allocated for interviews, and breaks should be planned to avoid fatigue.
• Use role-playing to address poorly articulated user needs.
• Provide necessary data entry activities and real-world simulated scenarios to allow deeper exploration of the context.
• Use diagrams to help clarify difficult procedures or systems.
• Provide summaries immediately after the interview.

HOLIS Case Study

• The case study explored needs of homeowners for a new home lighting system.
• Homeowner's perspective highlighted desire for flexibility and compatibility with various technological advancements, ease of use, and low costs.
• Distributor's perspective focused on strong product differentiation, easy salesman training, shop demonstrations, and high gross margins.

Test your knowledge on the process of requirements elicitation, including the challenges presented by human nature and communication barriers between users and developers. This quiz covers key concepts, methods, and critical actions involved in successful requirements gathering. Ideal for students of software engineering and project management.