Documente Academic
Documente Profesional
Documente Cultură
Requirements Elicitation II
Organizational
Requirements
Engineering
Prof. Dr. Armin B. Cremers
Sascha Alda
Overview
z
Elicitation Techniques
Scenarios
Interviews
Observation
Prototyping
Identifying actors
Best practice for modeling use cases
Refinement of use cases
Conclusions
Armin B. Cremers, Sascha Alda
This lesson
Interviews Techniques
During analysis
Discussing use cases with client and users
Correction and refinement (requirements and functionality)
Brainstorming
z
Structured brainstorming
Brainstorming
Let each team member have a turn to give his or her input as
answer to the question.
If a team member can't think of any input when his or her turn comes,
he simply needs to say 'Pass,' and the next member gets the turn.
Ensure that all the members have a full understanding the question
Other team members can ask the input giver what he or she
actually means by his or her input.
Armin B. Cremers, Sascha Alda
Future Workshop I
z
Participants
Goal
Future Workshop II
Three Phases
z
Critique:
Utopia:
Implementation planning
Future Workshop II
Techniques and Tools
z
Critique
Utopia
Structured brainstorming
Contributions from all participants (participants can speak freely)
Often useful: Restrict contributions to 30 seconds
Visualization/Logging of contribution on cards/stickers
Usage of software support (Whiteboards, Anonymous discussion tools)
Structured brainstorming
Using problem situations/contexts to generate positive visions of the
future
Re-grouping of contributions according to new future scenarios and
refinement in (smaller) work groups
Implementation planning
10
Scheduling (!)
11
Observation
z
Approach: adopt methods e.g. from the social sciences which has
proved to be valuable in understanding actual work processes
Approach presented here: Ethnography
12
Ethnography
z
z
z
13
Ethnography Guidelines
Assume that people are good at doing their job and look for nonstandard ways of working (resist on individual experience)
Spend time getting to know the people and establish a trust
relationship
Keep detailed notes of all work practices. Analyze them and draw
conclusions from them
Combine observation with open-ended interviewing
Organize regular de-briefing session where the ethnographer talks
with people outside the process
14
Ethnography Guidelines
Ethnographic
Analysis
Focussed
Ethnography
Debriefing
Meetings
System
prototyping
System
Prototype
User
Experiments
z
z
z
15
Ethnography
Viewpoints
z
16
Ethnography
Pros and Cos
z
z
17
Mock-Ups I
z
Advantages
18
Mock-Ups II
z
Alternative: Prototypes
19
Prototyping
z
20
Prototyping benefits
z
z
21
Types of prototyping
z
Throw-away prototyping
22
Prototyping
Costs and Problems
z
z
z
23
Approaches to prototyping
z
Paper prototyping
Wizard of Oz prototyping
Executable prototyping
24
HTML browsers
Java (Swing, AWT classes for GUI generation)
Static elements (GUI-components) and behavior visualization
25
Overview
z
Elicitation Techniques
Scenarios
Interviews
Observation
Prototyping
Identifying actors
Best practice for modeling use cases
Refinement of use cases
Conclusions
Armin B. Cremers, Sascha Alda
26
Identification of actors
z
z
z
z
z
z
z
z
27
Actor
possess
Responsibility
1
has
n
names
Goal
Use Case
1
contains
n
calls
Scenario
condition
succeed / fail
28
z
z
z
z
z
29
30
(Success scenarios)
(Failure sc.)
31
Elicitation Guideline:
z
z
32
Elicitation Guideline:
Which user groups are supported by the system to perform their work?
What are the goals of an actor? Does each actor has a goal?
33
Elicitation Guideline:
Develop First Scenario
z
For each use case write the main success scenario (the happy
day scenario).
34
35
Types of failures:
z
z
Alternate scenarios
Use Cases (<<extends>> relationship)
Recoverable extensions (rejoin the main course later on)
Non-recoverable extensions (abort the course of interaction
directly)
Anticipatable vs. non-anticipatable failures
36
37
Use cases should be named with verb phrases. The name should
indicate the goal the users tries to accomplish
z
z
38
39
Terms that developers and users must clarify to understand use cases
Recurring nouns in the use cases (e.g. Report, Ticket, Book)
Real-world entities that the system must track (e.g. Person, Resource)
Processes, Use Cases (OrderBook, ReportIncident)
Data sources and sink (e.g. Database, Printer)
40
Non-functional Requirements:
z
41
Non-functional Requirements:
Some possible questions
z
Performance characteristics
42
Summary
z
43