Requirements Elicitation and Analysis

This quiz covers the four-step elicitation and analysis cycle, stakeholders and their identification, the challenges of eliciting requirements, and the four main discovery techniques: requirements discovery (viewpoints), interviewing, scenarios, use cases, and ethnography - including their strengths, limitations, and how they complement each other

download Export

search_insights Statistics

stylus_note White Board

Quran

calculate Calculator

dictionary Dictionary

fullscreen Full Screen

more_vert More

QUESTION OF

volume_mute Read quiz aloud

Views #: 226

Questions #: 22

Time: 20 minutes

Pass Score: 80.0%

Style

Step

List

Mode

Exam

Practice

The Elicitation and Analysis Cycle

2 pts

volume_mute

Please drag and drop the options to sort them

The requirements elicitation and analysis process consists of four activities that cycle iteratively. Sort them in the correct cyclic order starting from the first activity.

Requirements Discovery

Requirements Classification and Organization

Requirements Prioritization and Negotiation

Requirements Specification

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Definition of a Stakeholder

1 pts

volume_mute

A system stakeholder is best defined as:

Anyone who should have some direct or indirect influence on the system requirements

Only the end-users who will interact directly with the completed system

Only the people who will pay for the system to be developed

Only the software engineers who will build the system

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Stakeholders for MHC-PMS

2 pts

volume_mute

For the MHC-PMS mental health care patient information system, which of the following are system stakeholders? Select all that apply.

Patients whose information is recorded in the system

The shareholders of the company that procures the system

A medical ethics manager who ensures the system meets ethical guidelines

Medical receptionists who manage patients' appointments

Healthcare managers who obtain management information

Nurses who coordinate consultations and administer treatments

Doctors responsible for assessing and treating patients

IT staff responsible for installing and maintaining the system

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Difficulties in Elicitation

2 pts

volume_mute

Which of the following are recognized difficulties in eliciting and understanding requirements from stakeholders? Select all that apply.

All stakeholders are always available and willing to participate in requirements meetings

Stakeholders often don't know what they want except in the most general terms and may make unrealistic demands

Political factors may influence requirements — managers may demand requirements to increase their organizational influence

Different stakeholders have different and sometimes conflicting requirements

Stakeholders naturally express requirements in their own terms with implicit domain knowledge that engineers may not understand

The economic environment changes during analysis, causing requirements priorities to shift

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Requirements Discovery — Definition

1 pts

volume_mute

Requirements discovery (sometimes called requirements elicitation) is the process of:

Testing the requirements document for completeness and consistency

Negotiating conflicts between stakeholder requirements

Gathering information about the required system and existing systems, and distilling user and system requirements from this information

Writing requirements into a formal specification document

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Viewpoints

1 pts

volume_mute

A viewpoint in requirements discovery is best described as:

A prioritized list of features ranked by business value

A formal mathematical model of the system

A UML diagram showing the system architecture

A way of collecting and organizing requirements from a group of stakeholders who have something in common

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Viewpoints — Independence

1 pts

volume_mute

True or False: Different viewpoints on a system problem are completely independent of each other with no shared or overlapping requirements.

True

False

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Types of Interviews

1 pts

volume_mute

To complete the line match

Click on an item in the first group
Click on an item in the second group
To delete a match, double click on a line

Interview Type

Closed Interviews

Open Interviews

Description

No pre-defined agenda; the requirements engineering team explores a range of issues with stakeholders to develop a better understanding of their needs

The stakeholder answers a pre-defined set of questions

Requirements engineering interviews can be of two main types. Match each type to its description.

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

What Interviews Are Good For

1 pts

volume_mute

Interviews are good for which of the following? Select all that apply.

Discovering organizational requirements and constraints driven by subtle power relationships

Understanding the difficulties that stakeholders face with current systems

Eliciting deep domain knowledge and terminology from application specialists

Getting an overall understanding of what stakeholders do and how they might interact with the new system

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Two Reasons Interviews Fail for Domain Knowledge

2 pts

volume_mute

Interviews can be difficult for eliciting domain knowledge for two specific reasons. Identify both reasons.

Some domain knowledge is so familiar to stakeholders that they assume it is obvious and don't think to mention it

Interviews always take too long for domain knowledge topics

Domain knowledge can only be captured in mathematical notation

Domain specialists are always too busy to participate in interviews

Domain specialists use terminology and jargon that is specific to their domain, which requirements engineers may misunderstand

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Effective Interviewer Characteristics

2 pts

volume_mute

Which two characteristics make a requirements interviewer most effective?

They always use only closed questions with a fixed questionnaire

They are open-minded, avoid pre-conceived ideas, and are willing to change their mind when stakeholders raise surprising requirements

They insist on meeting minimum interview length targets regardless of content

They prompt interviewees using a springboard question, a requirements proposal, or a prototype to get discussions going

They interview only senior managers, avoiding end-users

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Scenarios — Definition and Purpose

1 pts

volume_mute

Why are scenarios useful in requirements elicitation?

They replace the need for any other elicitation technique

People find it easier to relate to real-life examples rather than abstract descriptions; scenarios let stakeholders understand and criticize how they might interact with a system

They provide formal mathematical proofs of system correctness

They automatically generate source code for the system

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Elements of a Scenario

2 pts

volume_mute

At its most general, a scenario should include which of the following elements? Select all that apply.

A description of the system state when the scenario finishes

A description of what can go wrong and how it is handled

A description of what the system and users expect when the scenario starts (initial assumption)

A description of the normal flow of events

A detailed cost-benefit analysis of the feature

Information about other activities that might be going on at the same time

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Use Cases — Origin

1 pts

volume_mute

Use cases as a requirements discovery technique were first introduced in:

Extreme Programming (Beck, 1999)

The UML standard developed by OMG

The Objectory method (Jacobson et al., 1993)

The IEEE software engineering standards

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

UML Use Case Diagram Elements

1 pts

volume_mute

In a UML use case diagram, how are actors and interactions represented?

Actors as stick figures; each class of interaction as a named ellipse; lines link actors to interactions

Both actors and interactions as named rectangles connected by labeled arrows

Actors as rectangles; interactions as arrows

Actors as clouds; interactions as rounded rectangles

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Use Cases vs. Scenarios

1 pts

volume_mute

True or False: There is a hard and fast distinction between scenarios and use cases — they are fundamentally different techniques with no overlap.

True

False

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Limitations of Use Cases

2 pts

volume_mute

Use cases and scenarios are effective for eliciting requirements from stakeholders who interact directly with the system. However, they are NOT effective for which types of requirements? Select all that apply.

Functional requirements describing user interactions

High-level business and non-functional requirements

Constraints on system behavior from external regulations

Domain requirements

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Ethnography — Definition

1 pts

volume_mute

Ethnography is best described as:

An observational technique where an analyst immerses in the working environment where the system will be used, observing day-to-day work to discover implicit requirements

A technique for formally specifying requirements in a mathematical notation

A graphical modeling technique using UML diagrams

A structured interview technique using closed questions

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Why Ethnography Discovers What Interviews Miss

1 pts

volume_mute

Why do people often find it difficult to articulate details of their work in an interview, making ethnography necessary?

Because the work details are second nature to them — they understand their own work but may not recognize its relationship to other work in the organization, and social factors only become clear to an unbiased observer

Because interview sessions are always too short to cover work details

Because they are deliberately hiding information from the requirements engineer

Because they are not intelligent enough to describe their work

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Two Types of Requirements Ethnography Discovers

2 pts

volume_mute

Ethnography is particularly effective for discovering two specific types of requirements. Identify both.

Requirements derived from the hardware platform the system will run on

Requirements derived from the way people actually work, rather than how process definitions say they ought to work

Requirements derived from cooperation and awareness of other people's activities in the workplace

Requirements derived from the marketing strategy of the client organization

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Ethnography and Prototyping Combined

1 pts

volume_mute

How does combining ethnography with prototyping improve the requirements elicitation process?

Prototyping proves the ethnographic findings are correct

Ethnography is only used to evaluate the final prototype before delivery

The prototype replaces the need for ethnographic observation entirely

Ethnography informs prototype development (fewer refinement cycles), and the prototype then focuses the ethnography by identifying new questions for the ethnographer to explore

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Limitations of Ethnography

2 pts

volume_mute

Which of the following are recognized limitations of ethnography as a requirements elicitation technique? Select all that apply.

It cannot always identify organizational or domain requirements

It always produces mathematically precise requirement statements

It requires expensive specialized video recording equipment

It should be used to complement other elicitation approaches rather than as the sole technique

Its focus on end-user work means it may not identify new features that should be added to the system

note_alt Add notes

flag Flag

volume_mute

Correct Answer

Explanation

Undergraduate Professional

The Elicitation and Analysis Cycle

Correct Answer

Explanation

Definition of a Stakeholder

Correct Answer

Explanation

Stakeholders for MHC-PMS

Correct Answer

Explanation

Difficulties in Elicitation

Correct Answer

Explanation

Requirements Discovery — Definition

Correct Answer

Explanation

Viewpoints

Correct Answer

Explanation

Viewpoints — Independence

Correct Answer

Explanation

Types of Interviews

Interview Type

Description

Correct Answer

Explanation

What Interviews Are Good For

Correct Answer

Explanation

Two Reasons Interviews Fail for Domain Knowledge

Correct Answer

Explanation

Effective Interviewer Characteristics

Correct Answer

Explanation

Scenarios — Definition and Purpose

Correct Answer

Explanation

Elements of a Scenario

Correct Answer

Explanation

Use Cases — Origin

Correct Answer

Explanation

UML Use Case Diagram Elements

Correct Answer

Explanation

Use Cases vs. Scenarios

Correct Answer

Explanation

Limitations of Use Cases

Correct Answer

Explanation

Ethnography — Definition

Correct Answer

Explanation

Why Ethnography Discovers What Interviews Miss

Correct Answer

Explanation

Two Types of Requirements Ethnography Discovers

Correct Answer

Explanation

Ethnography and Prototyping Combined

Correct Answer

Explanation

Limitations of Ethnography

Correct Answer

Explanation

Quran Recitation

Query Dictionary

Select a result: