Lecture 12

Requirements Elicitation
Interacting with stakeholders 1 to
discover their requirements. Domain
requirements are also discovered at
this stage.

Requirements are
documented and input Groups related
into the next round of requirements and
iteration. organises them into
coherent clusters.

Prioritising requirements and

resolving requirements conflicts.

2
Requirements Elicitation
Interviews
1

Scenarios

Prototypes
Elicitation Facilitated meetings
Techniques
Observation

User stories

Other techniques

3
 Interviewing
1
• Formal or informal interviews with stakeholders are part of most RE
processes.
• Types of interview
1. Closed interviews based on pre-determined list of questions
2. Open interviews where there is no predefined agenda. Various
issues are explored with stakeholders.
• Effective interviewing
1. Be open-minded, avoid pre-conceived ideas about the
requirements and are willing to listen to stakeholders.
2. Prompt the interviewee to get discussions going using a
requirements proposal, or by working together on a prototype
system.

4
Scenarios
1

• Scenarios are real-life examples of how a system can be used.

• They should include
1. A description of the starting situation;
2. A description of the normal flow of events;
3. A description of what can go wrong;
4. Information about other concurrent activities;
5. A description of the state when the scenario finishes.

5
 Scenario for Collecting Medical History in
MHC-PMS 1

6
Use Cases
1
• Use-cases are a scenario based technique in the UML which identify the
actors in an interaction and the interaction itself.
• A set of use cases should describe all possible interactions with the
system.
• High-level graphical model supplemented by more detailed tabular
description.
• Sequence diagrams may be used to add detail to use-cases by showing
the sequence of event processing in the system.

7
 Use Cases for the MHC-PMS
1

8
 Ethnography
1

• People often find it very difficult to explain how they carry out their
routine tasks and how they work together in particular situation.
1. How to tie a shoelace?
2. Difficult to describe but easy to demonstrate process
• Observation is a better way of understanding this type of tasks to
understand what support people need from a computer-based system
• Ethnography is an observational technique that can be used to
understand operational processes and help derive requirements for
these processes.
• A social scientist spends a considerable time observing and analysing
how people actually work.

9
 Ethnography
1
• People do not have to explain or articulate their work.
• Ethnographic studies have shown that work is usually richer and more
complex than suggested by simple system models.
• For example observing workers in a bank to understand their everyday
work and hence derive requirements for computer support.
• Ethnography studies cannot be carried out according to a formula
1. They are dependent on the personality of ethnographer
2. The type of process being studied
3. People involved in the process
4. To be effective, the ethnographer must be accepted by the
people being studied
5. The people must feel comfortable to carry on their daily tasks in
the presence of ethnographer.

10
 Requirement Analysis detail understanding of existing system or requirement

design use case system

memorize it in detail cnvert use case into
1
 Analyze requirements to:
 detect and resolve conflicts between requirements; - not know which one to began with
- one requirement depended on other

 discover the bounds of the software and how it must interact with its
environment user requirement
function requirement
 elaborate system requirements to derive software requirements

 Requirements analysis process:

 Use one of a number of analysis methodssame technique as elisitation technique

 Classify requirements

11
Requirement Analysis : classify requirement

1
 Requirements
money, policy
classification to identify:
organization requirement function and non function requirement
 Process requirements or product requirements

 Functional and non-functional requirements

grwoing
 High-level requirements or an emergent requirements

 Requirement priority

 Scope of the requirement

 Other characteristics of the requirement

12
Requirement Analysis
use case diagramsanalysis
1

data flow models design \\

state models

Conceptual goal-based models

Models user interactions

object models

data models

others design

13
Requirement Analysis
type of factors to select model?
1
 How to choose a model? choosing model: process requirement
 The nature of the problem

 The expertise of the software engineer

 The process requirements of the customer

 It is useful to start by building a model of the software context

 To identify the intended software interfaces with the environment

14
 1

15