supplement 02 (b)user requirements1 supplement 02 (b) i.requirements gathering and task analysis...

32
Supplement 02 (b) User Requirements 1 Supplement 02 (b) i. Requirements gathering and Task Analysis ii.User Requirements And Franchise Colleges By MANSHA NAWAZ

Upload: christine-ryan

Post on 30-Dec-2015

215 views

Category:

Documents


0 download

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.

Supplement 02 (b) User Requirements 32

Establishing User Requirements

• At the start we know nothing at all

• By the end of this stage we have:– Decided (more or less) what matters – Found out what users want– Recorded all this in an appropriate way

• Utilise Rich Pictures

SUMMARY