Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Viewers also liked (17)
Similar to Hi600 u03_inst_slides
Similar to Hi600 u03_inst_slides (20)
More from ljmcneill33
More from ljmcneill33 (20)
Recently uploaded
Recently uploaded (20)
Hi600 u03_inst_slides
- 1. HI-600: Analysis and Design of Health Information Systems Analysis: Part I Determination of Requirements
- 2. Introduction to Analysis Phase • Planning deliverables: system request, feasibility analysis, and project plan • The Analysis Phase • Requirements (Chapter 3) – Requirement determination – Requirement elicitation techniques – Requirement analysis strategies • Use Cases (Chapter 4) – Process Models (Chapter 5) – Data Model (Chapter 6) System Proposal
- 3. REQUIREMENTS DETERMINATION • A requirement: a statement of • what the system must do or • what characteristics it needs to have • Requirements describe • what the business needs (business requirements) • what the users need to do (user requirements) • what the software should do (functional requirements) • characteristics the system should have (non-functional requirements), and • how the system should be built (system requirements)
- 4. Two Aspects of Functional Requirements • Process Oriented • A process the system must perform • Ex: The system must allow physicians order medications that are currently available • Illustrated by Process Model (Chapter 5) • Information Oriented • Information the system must contain • Ex: The system must contain real-time list of available medications • Illustrated by Data Model (Chapter 6)
- 5. Aspects of Nonfunctional Requirements Illustrated by Architecture Design (Chapter 8) • Operational • Physical and technical operating environment • Ex: compatible with iOS and Android • Performance • Speed, capacity, reliability needs • Ex: should be able to handle 500 simultaneous connections • Security • Access restrictions, necessary safeguards • Ex: only pharm managers can approve orders • Cultural and political • Issues that will affect final system • Ex: HIPAA
- 6. Requirements Definition Statement • Enumerated list of the functional and non-functional requirements as an outline. • Each requirement is clearly defined and grouped into task sets (easy to track). • Order of the requirements sometimes indicate priority. • Provides a clear vision of what the system must do. • Manages user expectations (What you see is what you will get, “speak now or forever hold…”)
- 7. Requirements Elicitation Techniques • Interviews • Joint Application Development (JAD) • All teams working together to collect information • Questionnaires • Document Analysis • Look at existing system documentation or paper based workflow to understand it and improve it • Observation • Observe workflow, note improvements and deficiencies, what works well?
- 8. Interviews: Basic Steps • Selecting Interviewees • Designing Interview Questions • Preparing for the Interview • Conducting the Interview • Post-Interview Follow-up
- 9. Joint Application Development (JAD) • Selecting Participants • Designing the JAD Session • Preparing for the JAD Session • Conducting the JAD Session • Post-JAD Follow-up
- 10. Questionnaires • A questionnaire is a set of written questions for obtaining information from individuals. • Selecting participants - using a sample of people who are representative of the entire group. • Designing the questionnaire – following good practice guidelines. • Administering the questionnaire – improving the response rates: explain the purpose clearly. • Questionnaire follow-up – developing a report.
- 11. Document Analysis • Document analysis is used to understand the as-is system. • Very common in healthcare as majority of the systems are developed to replace paper based workflow. • Forms, reports, policy manuals, organization charts describe the formal system that the organization uses. • The “real” or informal system differs from the formal one, and reveals what needs to be changed. • Also, analysis of previous system development documentation: currency should be considered.
- 12. Observation • Observation – the act of watching processes being performed. • It is a powerful tool to gain insight into the as-is system, and to check the validity of information gathered from other sources. • Nonetheless, people tend to be extremely careful in their behaviors when they are being watched.
- 14. Requirements Analysis Strategies • Problem Analysis • Identify existing limitations, bottlenecks, inadequacies, inefficiencies with the as-is system • Ask users how to solve them • Users buy in to the process • Root Cause Analysis • Explains the current problems, focusing on the root- cause instead of the symptom • Must dig deep enough, beyond subjective / superficial • Does not entertain or explore solutions
- 15. Requirements Analysis Strategies • Duration Analysis • Decomposes business process into series of steps • Times each step (hence, duration) • Compares aggregate times of all steps to overall process duration • Looks for discrepancies / process fragmentation • Looks for opportunities to integrate, parallelize and improve
- 16. Requirements Analysis Strategies • Activity Based Costing • Similar to duration analysis when breaking steps down, but look at direct and indirect costs, instead of time • Looks at the labor and materials that are necessary • Overlap that with the Duration Analysis • Informal Benchmarking (comparing with competitors) • Looking at industry metrics of best practices • Observing and determining your own metrics • “Calling Around”: How others are doing it
- 17. Requirements Analysis Strategies • Outcome Analysis (from the customer’s perspective) • Think about what the product could enable the customer to do. • Technology Analysis • Find if ta problem for the product • Look at what is available in the industry • Determine hat technology could be used to improve • Activity Elimination • Cut out the unnecessary activities • Cut waste • “Right Sizing” • Consequences
- 18. SUMMARY • Analysis focuses on capturing the business requirements for the system • Requirement Determination is the part of analysis in which the project team turns the business requirements stated in the system request into a precise list of requirements. • Five Requirements Elicitation Techniques can be used to elicit business requirements. • Requirements Analysis Strategies are useful for analysts to help the business users think critically about the new system requirements.
Editor's Notes
- Welcome to the third week of Analysis and Design of Health Information Systems. We have completed covering the concepts involved with the planning phase of the Systems Development Life Cycle and This week, we start discussing concepts related to the Analysis Phase of the SDLC, which is determining WHAT the new system should do. In the first part of the analysis phase. we start with the determination of system requirements
- Lets us start with an overview of what topics will be involved with the Analysis Phase: The phrase analysis refers to breaking a whole into its parts with the intent of understanding the parts’ nature, functions, and interrelationships. So, that is what we will be doing at this phase. We will try to understand the new system’s requirements by finding out what smaller components of the system are supposed to do. Of course, the key inputs into the analysis phase are the planning phase deliverables. In the analysis phase these deliverables are further detailed and analyzed. * The basic process of analysis involves three steps: Understand the existing situation (the as-is system) Identify improvements to the as-is system, which is not necessarily an electronic system Define the requirements for the new and improved system (the to-be system). It is very important for the system analyst to be very critical in his or her thinking to be able to determine the true causes of problems in the existing system. The users will often just state the problem and ask for a fix, but the analyst should apply his or her knowledge of information systems and business to understand the current workflow / tools / systems entirely. * Determination of the requirements for the new system would require solid understanding of the as-is system and clearly identified improvements. Today we will cover concepts involved with the process of determining the functional and non-functional requirements for a new system. Next week, we will cover the use cases based on these requirements. Use cases are the tools that show step-by-step instructions of what a user needs to do to complete a task. Then based on the use cases, we will discuss how to create process models (if the use case we are dealing with is process oriented) or data models (if the use case we are dealing with is information oriented) * The deliverable at the end of the analysis phase is called “system proposal”. System proposal is combination of requirements definition statement, use cases, process and data models, along with a revised feasibility analysis and project work plan. The system proposal is then presented to the approval committee in the form of a system walk-through to explain the system in moderate detail. Then, the deliverables from the analysis phase will be the first step in the design of the new system. * So, today, we are focusing on determining the requirements….
- In a nutshell, requirements determination is performed to understand requirements by transforming high-level statement of business requirements of the system request into a more detailed and precise list of what the new system must do to provide the needed value to the business. Obviously, both business and IT perspectives are needed, therefore the most effective approach is to have both businesspeople and analysts working together to determine requirements. Basic definition of a requirement is something the system must do or something the system needs to have. the requirements can be categorized into several categories based on what they describe : business requirements describe what the business needs: Business requirements are first described in system request in the planning phase, listing the reasons for proposing such a system. Ex: Improving patient safety and quality of care user requirements describe what the users of the system need to do: In the analysis phase business requirements are detailed into what the users need to do to with the system to fulfill the business requirements. Understanding user tasks helps reveal ways that the new system can support those tasks. Ex: Ordering and verifying delivery of medications electronically. functional requirements describe what the software should do to fulfill the user requirements. It could describe either a process that the system performs or information that it provides. Ex: Navigate to patient, input order, execute order; later provide list of ordered meds and verify administration of a certain med non-functional requirements describe behaviors the system should have. It could include performance or usability characteristics. Ex: portable compatible, web based, etc. system requirements describe how the system should be built: System requirements are used in the design phase and intended for the developers.
- At the beginning of the analysis phase, the first deliverable is a requirements definition statement. This document is not as detailed and comprehensive as the system proposal, but a good outline consisting of an enumerated list of functional and non-functional requirements. The requirements are grouped into task sets to easily track them. The order of requirements may also indicate their priorities. The requirements definition statement provides a brief and clear vision of what the system is expected to do. And most importantly, it is a great tool to manage user expectations, helps avoid scope creep.
- We talked about the concept of requirements and the requirements definition statement; now let’s talk about how we discover requirements. We will follow the textbook and study five most common techniques to collect requirements. Throughout the SDLC one of the most important tasks of the systems analyst is to build political support for the project and to establish trust between the project team and the users. Therefore, it is very important for the analyst to be very careful about whom to include, or sometimes more importantly, whom not to exclude in the requirements discovery process. It is also important to make respectful use of people’s time Let us now examine these five requirements collection techniques starting with the most common one.
- Interview is the most important and most used fact-finding technique, Where the systems analysts collect information from individuals or groups face to face The first step of an interview is Selecting Interviewees: Formal or informal interview schedule that includes people at different levels of the organization: Managers, Users, Other key stakeholders. Managers: to get broad understanding in early project stages Staff can provide details and specifics later. People are included based on what they can provide on the questions that the analyst needs more information However, political issues are important as well – so, it may be necessary to interview influential people, even if they are not too knowledgeable As the process continues, the list of interviewees may grow Let us now go through some concepts regarding Designing Interview Questions: - Close-Ended Question; require specific answer, similar to multiple choice (ex: “on average how many medications are ordered per patient per day in your unit?”, instead of “do you order a lot of medications?”) - Open-Ended Questions; leave room for elaboration, uncover unidentified problems (ex: “how do you think about the proposed workflow?) - Probing Questions; follow-up questions to expand on or clarify the topic (ex: “Can you give a specific example?) Level of details should be based on the position of the interviewee These types of questions are used in different interview structures: - Unstructured interview: for a broad and roughly defined set of information using open-ended questions, usually to understand the as-is system at the beginning - Structured interview: for very specific information using close-ended questions, usually after the analyst has a better understanding of the system - Top-down vs. bottom-up interview; broad to specific (more common) or specific to broad (later in the process, already has the general sense of the project, need specific information, but also relates to management issues) Preparing: Prepare a general interview plan Confirm areas of knowledge Set priorities in case of time shortage Prepare the interviewee Schedule Inform of reason for interview Inform of areas of discussion Conducting: Appear to be professional and unbiased, build trust so that you get the whole picture not only what you want to hear. Record all information; note taking as much detail as possible Be sure you understand the issues that are discussed and ask questions when you don’t. Frequently summarize to increase understanding. Separate facts from opinions. Try to quantify the answers. Give interviewee time to ask questions, and brief explain what will happen next. Be aware of non-verbal cues (body-language) Use time wisely Post-interview follow-up: After the interview, the analysts needs to prepare an interview report, including interview notes in a useful format The report is sent to interviewee as soon as possible with a request to read it and inform the analyst of clarification and updates.
- Joint Application Development (JAD) is an information gathering technique that allows the project team, users, and management to work together to identify requirements for the system. It is similar to doing all interviews at once. It is an extensive, structured group process It can reduce scope creep by 50%, It is a structured process in which 10 to 20 users meet under the direction of a facilitator, who is skilled in JAD techniques. Facilitator is an expert in guiding JAD sessions, but may not be an expert on the topic of discussion. Disadvantage: group psychology; not wanting to challenge opinions, only a few dominating conversation. But facilitator is there to overcome. e-JAD enables anonymous surveys and voting, much shorter sessions e-JAD requires facilitator and software Selecting JAD participants in the same basic way as selecting interview participants. Facilitator Expert in JAD and e-JAD techniques In many cases, the JAD facilitator is a consultant external to the organization. Designing JAD session JAD sessions can run from a half day to several weeks depending upon the size and scope of the project. The goal is to create the first analysis deliverable: the requirements definition statement Most JAD sessions are designed to collect specific information from users in a much more structured manner than interviews Preparing JAD session Since, this is a one-time opportunity, the success depends upon a careful plan JAD sessions are usually scheduled at a comfortable off-site location Conducting JAD session Most JAD sessions follow formal agenda and ground rules. The JAD facilitator performs three key functions: Keep session on track, following the agenda. Help the group understand the technical terms and jargon. Record group’s input on a public display area. The facilitator must remain neutral at all time and help the group through the process. Post-JAD follow-up Post-session report is prepared and circulated among session attendees The report should be completed approximately a week to two after the JAD session
- Questionnaires are used to gather information from larger groups Mass produced and distributed. Respondents complete the questionnaire on their own time May include two types of questions: Fixed-format questions Similar to a multiple choice exam question Must be able to anticipate potential answers to questions Easy to tabulate results Free-format questions Like an essay question – open-ended Response is unpredictable Harder to tabulate results Disadvantage: low response rates
- used to understand the as-is system Very common in healthcare as a large percentage of health information systems are still developed to replace a paper based workflow. Provides information about the formal system, but analyst needs to be careful to know that it may not describe the real workflow
- Each of these requirements gathering techniques have strengths and weaknesses. Usually a successful requirements gathering utilizes a combination of these techniques. Depth of information: richness and detail of information; just facts and opinions vs the reasoning behind them Breadth of information: range of information. JAD and interviews are very specific Integration of information: integrating potentially conflicting information. JAD does great! User involvement: amount of effort the users of the new system devote to the analysis phase. Cost: one thing interesting about JAD sessions; it costs a lot initially, however on the long run, it costs less due to less number of meetings
- While performing requirements gathering techniques, there are a few strategies a system analyst can use to encourage users to think critically to get the most benefit from the requirements gathering process. The most commonly used one of such strategies is the Problem Analysis (slide) This type of improvements often is very effective at improving a system’s efficiency or ease of use; however, it provides minor improvements in business value. Root cause analysis focuses on problems first rather than solutions. If the problem is not sufficiently understood, the solution will be ineffective. (What was our problem again!) Improvements from problem and root cause analyses tend to be small and incremental
- The next three analysis strategies we will look at identify moderate efficiency and effectiveness improvements to the existing systems Duration analysis requires a detailed examination of amount of time it takes to perform each process in the as-is system. Then it compares the total time to complete basic steps and the total time for the overall process – a significant difference indicates that there are discrepancies or the process is badly fragmented. Then it tries to find improvements by integrating or paralyzing tasks.
- Activity-based costing is similar to duration analysis, but it looks at cost instead of time The analysts identify most costly steps and focus improvement efforts on them. Benchmarking refers to studying how other organizations perform a business process. Informal benchmarking is common for “customer-facing” processes. In healthcare, there is a lot of work on benchmarking quality outcomes The analysts visit other organizations as customers to watch how the business process is performed.
- The last three requirement analysis strategies we will look at are for redesigning the entire business process, where the existing system is abandoned Outcome analysis focuses on understanding fundamental outcomes that provide value to customers. Think what the organization could enable the customer to do Technology analysis involves two steps: The analysts and managers list important and interesting technologies. Then, the group identifies how each and every technology might be applied to the business and how the business would benefit. In activity elimination, the analysts and managers work together to identify how the organization could eliminate each activity in the business process, how the function could operate without that activity and what effects are likely to occur. This would be done for all activities, even if it seems illogical. Activity elimination is a brainstorming technique that helps to overcome “but we’ve always done it that way” limitations on thinking Each of the requirement analysis strategies we discussed has its own purpose. So, no one strategy is inherently better that the others and the requirement analysis strategy should be chosen to based on how it fits the nature of the project.
- With that we conclude the first week of the analysis phase. Next week, we will move into Use Case Analysis. We will use the requirements definition statement and express them more formally using Use Cases. This is a step toward formalizing the system to the point that it is easy to communicate what needs to be developed by the programmers.