Scribd
Upload
15 views

Chapter 3-Requirements Elicitation

Chapter 3 of the document focuses on requirements elicitation in software engineering, detailing its aims, challenges, and processes. It outlines various techniques for gathering requirements from stakeholders, including interviews, ethnography, facilitated meetings, prototypes, and stories/scenarios. The chapter emphasizes the importance of understanding stakeholder perspectives and the complexities involved in accurately capturing system requirements.

Uploaded by

jexijeg969
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
15 views

Chapter 3-Requirements Elicitation

Chapter 3 of the document focuses on requirements elicitation in software engineering, detailing its aims, challenges, and processes. It outlines various techniques for gathering requirements from stakeholders, including interviews, ethnography, facilitated meetings, prototypes, and stories/scenarios. The chapter emphasizes the importance of understanding stakeholder perspectives and the complexities involved in accurately capturing system requirements.

Uploaded by

jexijeg969
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 19

Umm AL-Qura University

College of Engineering and


Computing at Al-Qunfudhah
Computing Department

Software Engineering
(SE3037)
Chapter 3: Requirements
Elicitation
Outline
• Requirements Elicitation
• Process Requirements Sources
• Elicitation Techniques
Requirements Elicitation
• The aims of the requirements elicitation are to understand the work that
stakeholders do and how they might use a new system to help support that work.

• Also known as requirements capture, requirements discovery, requirements


acquisition and requirement gathering.

• Involves technical staff working with customers to find out about the application
domain, the services that the system should provide and the system’s operational
constraints.

• May involve end-users, managers, engineers involved in maintenance, domain


experts, trade unions, etc. These are called stakeholders.
Problems of Requirements
Elicitation and Analysis
• Eliciting and understanding requirements from system stakeholders is
a difficult process for several reasons:
• Stakeholders don’t know what they really want.
• Stakeholders' express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organizational and political factors may influence the system requirements.
• The requirements change during the analysis process. New stakeholders may
emerge, and the business environment may change.
The Requirements Elicitation and
Analysis Process
• Requirements discovery
• Interacting with stakeholders to discover
their requirements. Domain requirements
are also discovered at this stage.
• Requirements classification and
organization
• Groups related requirements and organizes
them into coherent clusters.
• Requirements prioritization and
negotiation
• Prioritizing requirements and resolving
requirements conflicts.
• Requirements documentation
• Requirements are documented and input
into the next round of the spiral
Example - ATM Stakeholders
• Bank customers
• Representatives of other banks
• Bank managers
• Counter staff
• Database administrators
• Security managers
• Marketing department
• Hardware and software maintenance engineers
• Banking regulators

7
Viewpoints
• Viewpoints are a way of structuring the requirements to represent the perspectives of
different stakeholders.

• Stakeholders may be classified under different viewpoints.

• This multi-perspective analysis is important as there is no single correct way to analyse


system requirements.

• We may identify viewpoints using :


• Providers and receivers of system services;
• Systems that interact directly with the system being specified;
• Regulations and standards;
• Sources of business and non-functional requirements.
• Engineers who have to develop and maintain the system;
• Marketing and other business viewpoints.
Requirements Elicitation
Techniques
• Requirements elicitation involves meeting with stakeholders of different kinds to discover
information about the proposed system.

• Also, from existing systems and their usage and information from documents of various
kinds.

• There are fundamental approaches to requirements elicitation:


• Interviewing, where you talk to people about what they do.
• Observation or ethnography, where you watch people doing their job to see what artifacts
• Facilitated meetings
• Prototypes
• Stories and scenarios

• You should use a mix to collect information.


Interviewing
• In formal or informal interviewing, the RE team puts questions to
stakeholders about the system that they use and the system to be
developed.

• There are two types of interview:


• Closed interviews where a pre-defined set of questions are answered.
• Open interviews where there is no pre-defined agenda, and a range of issues
are explored with stakeholders.
Interviews
• An interview is a systematic attempt to collect information from a person.

• Interviewing success depends on ability to identify:


• workflows,
• factors that influence the operations of systems, and
• the elements (documents, procedures, policies, etc.) that make up systems.

• Poorly performed interviews may:


• lead to systems which do not meet the needs of the organization
• affect the attitudes of the users and have a negative effect on the entire project
effort
Five Steps of the Interview
Process
• Preparing for the interview

• Planning and scheduling the interview

• Opening and closing the interview

• Conducting the interview

• Following up for clarification


Interviews in Practice
• Normally a mix of closed and open-ended interviewing.

• Interviews are good for getting an overall understanding of what stakeholders do and
how they might interact with the system.

• Interviews are not good for understanding domain requirements


• Requirements engineers cannot understand specific domain terminology;
• Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t
worth articulating.

• To be an effective interviewer:
• Interviewers should be open-minded, willing to listen to stakeholders and should not have pre-
conceived ideas about the requirements.
• Interviewers should prompt the interviewee with a question or a proposal and should not simply
expect them to respond to a question such as ‘what do you want’.
Ethnography
• In ethnography, a social scientist spends a considerable amount of time
observing and analyzing how people actually work.

• People do not have to explain or articulate their work.

• Social and organizational factors of importance may be observed.

• Ethnographic studies have shown that work is usually richer and more
complex than suggested by simple system models.
Perform Ethnography
• Immerse yourselves in the working environment where the system will be used

• Observe the day-to-day work and notes the actual tasks in which participants are involved

• This helps discover implicit system requirements that reflect the actual rather than formal
processes in which people are involved

• Advantage
• Discovers many user tasks and business processes that are too subtle and complex for their actors to
describe easily.

• Disadvantage:
• Expensive (analyst works in client environment)
• Observer should be detached: end-user based, non-judgmental so not appropriate for discovering
organisational or domain requirements
Scope of Ethnography
• Ethnography is particularly effective for discovering two types of
requirements:

• Requirements that are derived from the way that people actually work rather
than the way in which process definitions suggest that they ought to work.
• People may have “short cuts” or use their previous knowledge and experience to better
perform their role which may not be evident.

• Requirements that are derived from cooperation and awareness of other


people’s activities.
• People do not work in isolation and may share information and use dialogue with
colleagues to inform decisions.
Facilitated Meetings
• Purpose: try to achieve a summative effect, whereby a group of people can
bring more insight into their software requirements than by working
individually.

• Advantage:
• Brainstorm and refine ideas that may be difficult to bring to the surface using interviews.
• Conflicting requirements surface early on in a way that lets the stakeholders recognize
where these occur.
• May result in a richer and more consistent set of requirements than might otherwise be
achievable.

• Disadvantage:
• Meetings need to be handled carefully (hence the need for a facilitator) to avoid poor
group dynamics
• Meetings are time consuming (hence the need for a facilitator)
Prototypes
• Valuable tool for clarifying ambiguous requirements.
• Act in a similar way to scenarios by providing users with a context within
which they can better understand what information they need to
provide.
• Wide range of prototyping techniques—from paper mockups of screen
designs to beta-test versions of software products
• Protypes can also be used requirements validation
• Low fidelity prototypes are often preferred to avoid the stakeholder
“anchoring” on minor, incidental characteristics that could limit design
flexibility
• Disadvantage: Choose implementation too early
• Risk: Rough prototype becomes the product
Stories and Scenarios
• People find it easier to relate to real-life examples than abstract
descriptions.
• Stories and scenarios are a description of how the system can be
used for some particular task.
• They describe what people do, what information they use and produce, and
what systems they may use in this process.
• A scenario may include:
• A description of the starting situation;
• A description of the normal flow of events;
• A description of what can go wrong;
• Information about other concurrent activities;
• A description of the state when the scenario finishes.

You might also like