•
•
•
•
Transactions
Transformation
DB
Business analysis
Requirements
Task list
Data model
Outputs from system analysis
End-user, possibly
with no or low
technical background
Interface
• Systems for storage, transformation and
retrieval of data
• Example: Enterprise Resource Planning
Information systems
Workplace definition
Goal analysis
Process analysis
Problem analysis
Strength analysis
Resource analysis
Communication analysis
Task description template
• Might not involve any software development at all
• Uses own notation, which might be translated to UML
• Puts high attention to multi-perspective evaluation
–
–
–
–
–
–
–
• Model and develop business processes and activities:
The information systems
community
Guest
System boundary
Receptionist
Self checkout
Record guest
data
Find room
Print rooms
to clean
Invoicing
Manage personnel
Hotel system
Cleaner
Market hotel
Manager
Transforms later to use-cases
The
Themeeting
meetingplace
placeis
is
system
systemanalysis
analysis––
requirements
requirementsengineering
engineering
• Emphasis is on the process
• Emphasis is on goal fulfilment
• Entry point is the Requirements
specification
• The means is a chain of operations:
The software engineering
community
•
•
•
•
•
•
Subject
Course code
Max-enrolment
Enrolled-in
Name
Personal number
Curriculum
Think-aloud test
Normal users
Observation test
Automatic logging
Heuristic evaluation 50% hit rate
User review with expert users
Avoid trade-union representatives and ITexperts
Usability testing
Course
Student
Data model: ER-diagram
•
•
•
•
•
•
•
•
•
Input: artefact, test tasks (realistic, closed)
Participants: test user, facilitator, log keeper
Explain purpose
Background and daily matters
Task
Observe
If necessary: give hints
Debriefing
Output: List of problems
Testing process
Different
formats
•
•
•
•
•
Missing function
Task failure
Annoying
Medium problem
Minor problem
Usability problem severity
classes
– Task analysis
– Prototyping (HI-FI, LO-FI), 3 rounds?
• Relevance
• Efficiency
• Attitude
• Learnability
Usability engineering:
Usability
• Originally a political view of system development
• The users shall have the power of system
development
• The maintenance and development of user
professional skill is emphasized
• Engineers shall implement prototypes and give
alternatives
• Light-version: Participatory design
The Scandinavian approach
From Carlshamre (2001)
A Usability Perspective
on Requirements Engineering
Doctoral dissertation, Linköping
University, Sweden.
Usability
metrics
Can go really wrong!
Creative and fun.
Can be used for other
purposes too.
Increase comprehension,
reduce learing period.
Often used in graphical
user interface (GUI) design.
• Embrace change
Lundsten
Lundsten&&Holst
HolstLiTH-IDA-Ex-03/068-SE
LiTH-IDA-Ex-03/068-SE
– The user is presented with information of all
phones connected
– The user changes parameters for a phone
– The user activates a dialup connection
– The user inactivates a dialup connection
• The customer is always available
• The customer writes user stories, ex:
User stories in eXtreme
Programming
Metaphors
• Make frequent small releases
• Lundsten and Holst: one release per week
in two major iterations
• Create spike solutions to gain more
confidence in planning
• Never add functions early
Prototyping in eXtreme
Programming
• Refactor mercilessly to keep the design simple.
• Refactor whenever and wherever possible.
• Lundsten & Holst: refactoring for each user story
gave confidence to change the system
• Architecture evolves: 4 major changes, ex: new
layer to manage multi-threading
• One approach to avoid the maintainability
problem
Refactoring in eXtreme
Programming
• Can you translate the action diagram and
the problem diagram into UML?
• Reflections?
Home assignment