Usability and Human Factors Requirements Engineering This material
Usability and Human Factors Requirements Engineering This material (Comp 15 Unit 2) was developed by Columbia University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number 1 U 24 OC 000003. This material was updated by The University of Texas Health Science Center at Houston under Award Number 90 WT 0006. This work is licensed under the Creative Commons Attribution-Non. Commercial-Share. Alike 4. 0 International License. To view a copy of this license, visit http: //creativecommons. org/licenses/by-nc-sa/4. 0/.
Requirements Engineering Lecture – Learning Objectives • Explain the role of requirements gathering in usability evaluation • Identify the uses, advantages, and disadvantages of data collection methods used for requirements gathering • Demonstrate an understanding of how to conduct a workflow analysis – Identify contextual design principles as they apply to the healthcare setting • Describe the methods to interpret results of data collection 2
What Are Requirements? • An explanation of what the system should “be” or should “do” • Documentation of “needs” in order to communicate between everyone involved in system development • A set of goals that define objectives for design 3
What Are We Trying to Achieve? • Identify needs so that the system can support the user’s goals • Produce a set of stable requirements that can be moved forward into the design activity 4
Why Do We Need Requirements? • To make communication clear, unambiguous and specific on system “needs” • To identify potential mismatch between user needs and designers’ understanding • To reduce the time and costs involved in developing a system • To evaluate the functions of a system during testing 5
What Documents Do We Need to Communicate Requirements? • • • Product Requirements Documentation Development Estimates Prototype Test Case Scenarios Maintenance Plan Product Support Documentation 6
Different Types of Requirements? • Requirements are conventionally categorized into the two groups: – Functional Requirements – Non-functional Requirements • Can also be grouped into more precise categories: – Data requirements – Technological requirements 7
Functional Requirements • Describe the capabilities of the system • Describe what the user should be able to do with the system • Examples: – “The order entry screen will allow the user to enter the first and last name of the patient” – “The order entry screen will display the first and last name of the patient” 8
Non-functional Requirements • • • Everything else: User characteristics General and technical constraints Security Organizational environment 9
Specific Requirement Types Data Requirements • Data types, size/amount, persistence, standards of accuracy Environmental requirements/contexts of use • Lighting, noise, privacy and traffic Organizational environment • Is management supportive? Quality/availability of user support? Resources for training? Technological environment • Platform, interoperability, compatibility User characteristics • Experts vs. novices 10
Methods for Eliciting Requirements Technique Use Advantages Disadvantages Questionnaires Answer specifics Reach many people Response rate Interviews Explore Issue Personal Contact Time consuming Focus Groups /Workshops Multiple views Build consensus Not all voices heard Naturalistic Observation Context of user activity Observing work Very time consuming Documentation analysis Procedures, Regulations. Operational insight May be difficult to comprehend without insider help Cognitive Research Skill, knowledge Model of performance Complex, time 1. 1 Table: (Preece, 2007). 11
Health Care Workflow • Medical work is collaborative • Coordination of tasks is required • Medical record is used as a coordinating tool to communicate activities and patient status • There is no single, unambiguous perspective on tasks and processes performed by users, who are the medical staff 12
Analysis of Workflow of Nurse Case Manager (Kaufman, 2009) 13
Analyzing Workflow • • Tasks that people do Roles of the various actors Event sequence for a particular process Describe technologies, documents or artifacts (e. g. , post-it notes) • The nature of the communication process 14
Schematic of Nurse Workflow (Kaufman, 2009) 15
Contextual Inquiry (Holtzblatt and Jones, 1993) • Approach to uncovering requirements related to the context of use in health care workflow • Understanding tasks being performed at work, • Structure of an organization • Roles within health care organization • Structured approach to the collection and interpretation of data from fieldwork • Emerged from ethnographic method • Much more focused and limited in scope • Interpreted observations versus rich description 16
Contextual Inquiry (Cont’d – 1) • Apprenticeship model • Designer works as apprentice to user (learning the ropes) • Contextual Interview • Lengthy interview that also involves observation and reconstruction of past events • Guided by four principles: • • Context: emphasis on seeing what happens in workplace Partnership: developer and user collaborate in understanding work Interpretation: observations interpreted to be used in design Focus: data gathering focused on goals and specific questions 17
Context of Requirements • The context of health care helps in understanding what happens in the workplace • This includes the social and cultural structure of the organization – The employees of an organization may be more accepting of changes in workflow and technology than a different organization – The beliefs and attitudes of an organization has an impact on the success of implementing a new system 18
Partnership in Requirements • Learning about the workplace through observation and discussion with users • The roles and responsibilities of health care workers influence their perspective on system needs – Defining requirements necessitates a partnership with users to understand their concerns with technology and to utilize their ideas for improvement 19
Interpretation Into Requirements • Observations of the workplace are interpreted into system needs • Assumptions and dependencies must be examined – Requirements should be based on the actual tasks and processes within the workplace – Reducing or eliminating repetitive tasks can be accomplished through identification of other people’s activities 20
Focus on Goals • Focus on the goals of developing requirements • To understand why or how something is done • To understand why or how something is not done • To understand how the context of health care work practices impact system needs 21
A day in the life of an analyst” Scenario • The staff in a private doctor’s office needs to keep track of the patients that have been referred to external specialists • You have been contacted to meet with the head nurse to identify requirements for a system to track patients and external specialists 22
“A day in the life of an analyst” 8 AM • You interview the head nurse • You prepare a list of questions and take notes on his answers • You ask about the current practice of keeping track of referrals: • • How many staff members are employed by the office? Which staff members are involved in the current practice? What is each of their individual roles? What documentation is used? What problems currently are found with the current practice? What solutions have the staff come up with for those problems? What ideas do they have for a future system to automate referral tracking? 23
“A day in the life of an analyst” 10 AM • You observe the office staff in their daily tasks, focusing on the current method of referral tracking • You obtain copies of the documentation used in referral tracking • You take notes about what you see in the office 24
“A day in the life of an analyst” 12 PM • You meet with two other members of the office staff: one is involved with the referral tracking and the second is not • You ask them how they feel about the current referral tracking process and if they have any ideas on potential solutions • You take notes on their answers 25
“A day in the life of an analyst” 3 PM • You meet with the head nurse again to discuss your observations • The nurse is surprised to find out that a staff member not part of the process is printing out each referral letter and placing them in patient folders • He indicates to you that there needs to be security restrictions on who has access to external physician records • The results of this discussion become the requirements for security and privacy of patient data 26
“A day in the life of an analyst” 4 PM • As you end the day, you begin to organize your notes into different categories of requirements • You now have an understanding of the purpose of referral tracking as well as the roles and tasks required in maintaining external physician referrals • You make a note in your calendar that tomorrow you need to analyze the documentation and begin to create your own document to communicate system requirements 27
Methods to Organize Ideas and Data • Affinity diagrams • Process flow • Sort and display • Depicts the overall ideas from multiple flow of activities sources and the relation between parts of a system including individuals 28
Affinity Diagrams • Affinity diagrams display a grouping of ideas and data. • Steps: • Write down individual ideas on a note card or post-it note • Look for ideas with similar themes • Group the ideas with similar themes together 29
Affinity Diagram: “A Day in the Life” 30
Requirements Engineering • Need requirements to communicate with everyone on team • Different requirements for different aspects of system • Need to focus on the purpose of the system while interpreting the context in which the system will be used by partnering with the users • Creating requirements consists of a process of steps • Includes interviewing medical staff, observing daily routines within the medical work place & analyzing current documentation used by the medical staff • Many methods for process of requirements analysis • Including diagrams and process flows 31
Requirements Engineering Summary • Requirements engineering emphasizes the necessity of understanding the nature of user needs • Different requirement types and methods for eliciting them • Importance of understanding workflow • Method of contextual inquiry • Affinity diagrams as a method to organize ideas and data 32
Requirements Engineering References 1. Holtzblatt, K. , & Jones, S. (1993). Contextual inquiry: A participatory technique for system design. In D. Schuler, & A. Namioka (Eds. ), Participatory Design: Perspectives on Systems Design (pp. 177 -210). Hillsdale, New Jersey: Lawrence Erlbaum Associates. 2. Retrieved on June 21, 2010 from http: //en. wikipedia. org/wiki/Requirement 3. Retrieved on June 21. 2010 from http: //en. wikipedia. org/wiki/Contextual_inquiry Table 1. 1 Table: Preece, J. Rogers, Y. & Sharp, H. (2007) Interaction Design: Beyond Human. Computer Interaction. 2 nd Edition. New York, NY: John Wiley & Sons Images Slide 13: Kaufman, D. R. , Pevzner, J. , Rodriguez, M. , Cimino, J. J. , Ebner, S. , Fields, L. , et al. (2009). Understanding workflow in telehealth video visits: Observations from the IDEATel project. Journal of Biomedical Informatics, 42(4), 581 -592. Slide 15: Kaufman, D. R. , Pevzner, J. , Rodriguez, M. , Cimino, J. J. , Ebner, S. , Fields, L. , et al. (2009). Understanding workflow in telehealth video visits: Observations from the 33 IDEATel project. Journal of Biomedical Informatics, 42(4), 581 -592.
Usability and Human Factors Requirements Engineering This material was developed by Columbia University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number 1 U 24 OC 000003. This material was updated by The University of Texas Health Science Center at Houston under Award Number 90 WT 0006. 34
- Slides: 34