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

2. Supplement 02 (b)User Requirements2 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?

3. Supplement 02 (b)User Requirements3 i. Requirements gathering and Task Analysis Requirements gathering is a central part of systems development understanding representationAnalysis involves understanding as well as representation of requirements functional, data usabilityRequirements should include functional, data and usability requirements user-centred designIn user-centred approaches, requirements gathering almost always involves some design

4. Supplement 02 (b)User Requirements4 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

5. Supplement 02 (b)User Requirements5 Traditional “life-cycle” model of software development Requirements GatheringRequirements Specification Design Implementation Maintenance

6. Supplement 02 (b)User Requirements6 A User- centered approach to software development Evaluation Implementation Task analysis/ functional analysis Prototyping Requirements specification Conceptual design/ Formal design Star Model (Hartson & Hix)

7. Supplement 02 (b)User Requirements7 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

8. Supplement 02 (b)User Requirements8 Usability Requirements non-functional requirementsCore requirements are viewed as “black box” functions plus key non-functional requirements (e.g., speed of response etc.) Usability requirements are often overlooked usability = “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)

9. Supplement 02 (b)User Requirements9 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

10. Supplement 02 (b)User Requirements10 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

11. Supplement 02 (b)User Requirements11 Task analysis Describes behavior at 3 levels –goals, tasks and actions Tasks are usually viewed in terms of tasks and subtasks Hierarchical Task AnalysisHierarchical Task Analysis (HTA) focuses on what actually happens in terms of tasks and subtasks Cognitive task analysisCognitive task analysis focuses on aspects of the cognitive characteristics of the users’ work

12. Supplement 02 (b)User Requirements12 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

13. Supplement 02 (b)User Requirements13 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

14. Supplement 02 (b)User Requirements14 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 Toolbar Icon 4. Use Delete 1. Select Text2. Press Ctrl + X Plan 1.2: 1,2 Plan 1: According to Requirements

15. Supplement 02 (b)User Requirements15 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

16. Supplement 02 (b)User Requirements16 b. User Requirements We 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

17. Supplement 02 (b)User Requirements17 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

18. Supplement 02 (b)User Requirements18 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

19. Supplement 02 (b)User Requirements19 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

20. Supplement 02 (b)User Requirements20 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

21. Supplement 02 (b)User Requirements21 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

22. Supplement 02 (b)User Requirements22 User Requirements for a car cruise control system What would we need to know to develop a car cruise control system?

23. Supplement 02 (b)User Requirements23 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

24. Supplement 02 (b)User Requirements24 User Requirements for an air traffic control system What would we need to know to develop an air traffic control system?

25. Supplement 02 (b)User Requirements25 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

26. Supplement 02 (b)User Requirements26 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

27. Supplement 02 (b)User Requirements27 User Requirements for a travel agency booking system What would we need to know to develop a travel agency booking system?

28. Supplement 02 (b)User Requirements28 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

29. Supplement 02 (b)User Requirements29 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?

30. Supplement 02 (b)User Requirements30 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

31. Supplement 02 (b)User Requirements31 Modelling Requirements for Air Traffic Control Has both Real-Time Process Control and TPS Aspects 1.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.

32. Supplement 02 (b)User Requirements32 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