supplement 02 (b)user requirements1 supplement 02 (b) i.requirements gathering and task analysis...
TRANSCRIPT
Supplement 02 (b) User Requirements 1
Supplement 02 (b) i. Requirements gathering and Task Analysis
ii. User Requirements
And Franchise Colleges
By MANSHA NAWAZ
Supplement 02 (b) User Requirements 2
Learning Objectives
• The Problem of Establishing User Requirements
• What do we start with?• What do we need to achieve?
• Reflections on the Problem Domain• What is important?• What abstractions can we use?
Supplement 02 (b) User Requirements 3
i. Requirements gathering and Task Analysis
• Requirements gathering is a central part of systems development
• Analysis involves understandingunderstanding as well as representationrepresentation of requirements
• Requirements should include functional, data functional, data and usabilityusability requirements
• In user-centreduser-centred approaches, requirements gathering almost always involves some designdesign
Supplement 02 (b) User Requirements 4
Requirements Gathering Techniques
• Traditional, Structured Methods use a toolkit of techniques for gathering requirements– input from client in the form of a Problem Statement– interviews, questionnaires, observation, document
analysis
• Functional Requirements modelled through Data -Flow Diagrams
• Data requirements through Entity-Relationship Models
Supplement 02 (b) User Requirements 5
Traditional “life-cycle” model of software development
Requirements Gathering
Requirements Specification
Design
Implementation
Maintenance
Supplement 02 (b) User Requirements 6
A User- centered approach to software development
Evaluation
Implementation
Task analysis/functional analysis
PrototypingRequirementsspecification
Conceptual design/Formal design
Star Model (Hartson & Hix)
Supplement 02 (b) User Requirements 7
User-Centered Approach
• Analyst can additionally use cognitive and other task analysis techniques
• Prototyping and Requirements animation can be used to facilitate requirements gathering
• Object Technology has added Object/Class modelling and Use Cases to the toolkit
• These techniques facilitate an approach which engages users throughout the lifecycle
Supplement 02 (b) User Requirements 8
Usability Requirements
• Core requirements are viewed as “black box” functions plus key non-functional non-functional requirementsrequirements (e.g., speed of response etc.)
• Usability requirements are often overlookedusability = “Any system designed for people to use should be easy
to learn (and remember), useful, that is contains functions people really need in their work, and be easy and pleasant to use”(Gould and Lewis, 1985)
Supplement 02 (b) User Requirements 9
Components of Usability
• Learnability– time and effort required to reach a specified level of
performance
• Throughput– tasks accomplished by experienced users, speed,
number of errors etc.
• Flexibility– system’s ability to respond to change
• Attitude– positive feelings of users to the system
Supplement 02 (b) User Requirements 10
Components of a Usability Study
• A Usability Study gathers Usability Requirements alongside functional, data specs. etc. and can involve– Usability Models– Usability Metrics– Usability Specifications
Supplement 02 (b) User Requirements 11
Task analysis
• Describes behavior at 3 levels– goals, tasks and actions
• Tasks are usually viewed in terms of tasks and subtasks• Hierarchical Task Analysis Hierarchical Task Analysis (HTA) focuses on what
actually happens in terms of tasks and subtasks• Cognitive task analysis Cognitive task analysis focuses on aspects of the
cognitive characteristics of the users’ work
Supplement 02 (b) User Requirements 12
Goal-Task-Action
• Goal (a.k.a. “external task”)– the state of the system the user wishes to achieve– e.g, produce a spreadsheet report, calculate
payroll figures etc.,
• Task (a.k.a. “internal task”)– activities thought to be necessary to achieve the
goal
• Action– a task that involves no problem solving, or control structure
Supplement 02 (b) User Requirements 13
Hierarchical Task Analysis
• Aim is to describe a task in terms of a hierarchy of operations and plans where– operations = Goal-Task-Action– plans = specification of conditions under which (sub)
tasks are carried out
• Can be captured graphically– using a form of structure chart
Supplement 02 (b) User Requirements 14
Partial HTA chart for Editing Text in Windows
0. Edit Text
1. Cut Text
1. Use Menu option
2. Use Hot-key Combo.
3. Use ToolbarIcon 4. Use Delete
1. Select Text 2. Press Ctrl + X
Plan 1.2: 1,2
Plan 1: According to Requirements
Supplement 02 (b) User Requirements 15
Hierarchical Task Analysis techniques
• StartingStarting the analysis– specify area of work or main task– break down into 4 - 8 subtasks– draw subtasks out into layered plans
• ProgressingProgressing the analysis– determine “granularity” of analysis– choose depth-first or breadth-first– document (notation in Preece p.415)
• FinalizingFinalizing the analysis– check for consistency, integrity– present to external “task expert” for confirmation
Supplement 02 (b) User Requirements 16
b. User RequirementsWe start with nothing!
• At first we know nothing of what users want• … and maybe little about the organisation.• This may be:
– a manufacturing business– a supermarket chain– a software house– a government department– an electricity generating company
Supplement 02 (b) User Requirements 17
User Requirements–We start with nothing!
• Within the organisation, the problem domain may be:– real-time—e.g. industrial process control– transaction processing—e.g. customer orders– safety-critical—e.g. air traffic control– communications—e.g. with sales reps– database—e.g. personnel records
Supplement 02 (b) User Requirements 18
User Requirements–We start with nothing!
• Users work in widely differing contexts and organisations
• Their need for information and computer support also varies tremendously
• We must begin by finding out about:– their circumstances– their problems– what they want
Supplement 02 (b) User Requirements 19
User Requirements– What do we need to achieve?
• The goal is simple: to learn enough to develop a computerised IS that will be useful to:– these specific users, in...– these particular circumstances, with...– these unique problems
• We must also document what we learn, so others can access our knowledge
Supplement 02 (b) User Requirements 20
User Requirements– What is important?
• What matters depends on the problem domain:– for control systems, process and timing
matter– for record-keeping systems, data matters– for financial system, security matters
• Note these are not mutually exclusive
• It’s more a matter of emphasis
Supplement 02 (b) User Requirements 21
User Requirements– What is important?
• Let’s consider a few examples.– Real-time: a car cruise control system– Safety-critical: an air traffic control system– Transaction processing: a travel agency
booking system
Supplement 02 (b) User Requirements 22
User Requirements for a car cruise control system
• What would we need to know to develop a car cruise control system?
Supplement 02 (b) User Requirements 23
User Requirements for a car cruise control system
– engine fuel demand– vehicle electronics interface standards– driver ergonomics (to design the controls)– timing and synchronisation information
• We will need to know about:– how engine
components work
Supplement 02 (b) User Requirements 24
User Requirements for an air traffic control system
• What would we need to know to develop an air traffic control system?
Supplement 02 (b) User Requirements 25
User Requirements for an air traffic control system
– aircraft navigation / instrument landing systems– throughput of stacks and queues– priority of different types of aircraft– user characteristics and environment– emergency routines
• Clearly different from car cruise control. We need to know:– number of flights and aircraft handled
Supplement 02 (b) User Requirements 26
Cruise control and air traffic control systems compared
• Similarities:– Timing and synchronisation are important– Safety issues are important
• Contrasts: for air traffic control...– Much more data is required for system running– Relationships among data matters– User issues are much more important
Supplement 02 (b) User Requirements 27
User Requirements for a travel agency booking system
• What would we need to know to develop a travel agency booking system?
Supplement 02 (b) User Requirements 28
User Requirements for a travel agency booking system
– journeys– customer characteristics– user characteristics
• Clearly different again. We need to know about:– holiday and travel operators– current prices and discounts
– destinations– network characteristics
Supplement 02 (b) User Requirements 29
Travel agency bookings and air traffic control compared
• Some similarities:– Data / relationships among data important– Response time an issue (but not milliseconds!)
• Contrasts: for travel agency bookings...– No significant safety issues– Remote network access vital– Non-technical users– Customer issues?—E.g. multimedia interface?
Supplement 02 (b) User Requirements 30
User Requirements– What abstractions can we use?
• Which abstractions are useful depends on the type of information that matters.
• We may need to capture details of:– Timings and sequence– Data (and relationships / structure of data)– Processes– Other aspects, e.g. users issues and safety
factors
Supplement 02 (b) User Requirements 31
Modelling Requirements for Air Traffic Control
• Has both Real-Time Process Control and TPS Aspects1. Number of flights and aircraft handled
2. Aircraft navigation / instrument landing systems
3. Throughput of stacks and queues
4. Priority of different types of aircraft
5. Emergency routines
• For each of the above requirements state the relative importance of modelling Data, Process & Time and suggest suitable models to be developed.