Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 6: Establishing Requirement - Coggle Diagram
Chapter 6: Establishing Requirement
Data gathering: Five key issues
Setting goals: Decide how to analyse data once collected
Identifying participants: Decide who to gather data from
Relationship with participants: Clear and professional, informed consent when appropriate
Triangulation: Look at data from more than one persepective
Pilot studies: Small trial of main study
Observation
Direct observation in the field
Structuring frameworks
Degree of participation
Ethnography
Direct observation in controlled environments
Indirect observation: tracking users' activities
Techniques in data gathering
Recorded audio/video
Taking notes
Problems with data gathering
Identifying and involving stakeholders: users, managers, developers, customer reps, union reps
Involving stakeholders: workshops, interviews, workplace studies, co-opt stakeholders onto the development team
Real users, not managers: traditionally a problem in software engineering
Requirements management: version control, ownership
Communication between parties: within development team, with customer/user, between users
Domain knowledge distributed and implicit: difficult to dig up and understand; knowledge articulation
Availability of key people
Political problems within the organisation
Dominance of certain stakeholders
Economic and business environment changes
Balancing functional and usability demands
Some basic guidelines
Focus on identifying the stakeholders' needs
Involve all the stakeholder groups
Involve more than one representative from each stakeholder group
Use a combination of data gathering techiniques
Support the process with props such as prototypes and task descriptions
Run a pilot session
Quantitative & Qualitative
Quantitative data -expressed as number
Qualitative data - difficult to measure sensibly as numbers, eg. count number of words to measure dissatisfaction
Quantitative analysis - numerical methods to ascertain size, magnitude, amount
Qualitative analysis - expresses the nature of elements and is represented as themes, patterns, stories
Task descriptions
Scenarios: an informal narrative story, simple, 'natural' personal, not generalisable
Use cases: Assume interaction with a system; Assume detailed understanding of the interaction
Essential use cases: Abstract away from the details; Does not have the same assumptions as use cases
Task Analysis
Task descriptions are often used. to envision new systems or devices
Task analysis is used mainly to investigate an existing situation
It's important not to focus on superficial activities
Many techniques, the most popular is Hierarchical Task Analysis (HTA)
Hierarchical Task Analysis
Involves breaking a task down into subtasks, then sub-sub-tasks and so on. There are grouped as plans which specify how the tasks might be performed in practice
HTA focuses on physical and observable actions, and includes looking at actions not related to software or an interaction device
Start with a user goal which is examined and the main tasks for achieving it are identified
Tasks are sub-divided into sub-tasks