Business and User Requirements Document Draft (Course Project Part 1) THIS a POWER POINT not a Paper. PROJECT TIP: This project has many parts to it and you will want to be sure you address all of

Week 3 Project-Written, Rubric, & Lesson Content

Business and User Requirements Document Draft (Course Project Part 1)

THIS a POWER POINT not a Paper.

PROJECT TIP:  This project has many parts to it and you will want to be sure you address all of the pieces to get full points once you are completely done.  To do this, it will be helpful to place each part of the project under a specific heading. See the RUBRIC below, as it gives you very specific instructions on what to do for each part, including what to name the heading, and this will help you set up your project correctly for success.

To prepare for a huge EHRS implementation, a facility must first understand who the EHRS will serve, where information that flows into the system comes from and who the primary users of the system will be after it is deployed at the facility. Part 1 of the Course Project will complete each of these to support the facility executive team as they assemble an EHRS development team.

Review the course project description on the Module 01 Course Project – Introduction page in order to understand the overall needs of the organization and the specific business processes that the project will address. In response to the needs of the organization, prepare a professional PowerPoint Presentation for the Executive Committee which will evaluate data needs for the organization so that an EHRS Development Team can be assembled. Refer to the Good Apples Group Case document in Module 1 and pay particular attention to 1) Clinical Decision Making and 2) Target Organizational Units found in that document.

Your PowerPoint must include at least one slide to present each bulleted item below to the facility executive team. Be sure to logically title each slide in your presentation.

1. List the primary sources/areas/departments within the organization which can be used to identify and gather user requirements. Show your understanding of the departments that are in a typical hospital; be specific and include a variety.

2. List and briefly explain what departments that will be most impacted by an EHR system implementation and remember to include the Information Systems Department.

3. List the methods that you would use to develop a comprehensive list of user requirements for the project. (Conduct research on the web or in our library on effectively using information gathering techniques such as structured interviews, focus groups, and surveys, in order to effectively address this section.)

4. List at least 6 requirements that must be met in order for this project to address the needs expressed in the Good Apples Case document found in the project overview. Requirements should be specific to an EHR system development. Remember that a requirement is not the same as a general "goal."

5. Finally, make an EHRS Development Team Membership recommendation. List each proposed member by title and remember to include the Director of Information Systems Department.

Note that these requirements must focus on the needs of the facility and of the people who will be using the project as an alternative means of performing business processes they already perform.
Your PowerPoint should be approximately 5-8 slides in length. The final slide should be used as your resource page. Be sure to credit any resources used in the preparation of this submission.

Submit your completed assignment by following the directions linked below. Please check the Course Calendar for specific due dates.

Save your assignment as a Microsoft Word document.

Rubric

Module 03 Course Project - Business and User Requirements 

Lesson Content

Module 01 Course Project – Introduction

Project Overview

Throughout the course you will build a plan for delivering an EHRS system to a healthcare facility. This plan will cover several of the phases of the project lifecycle, from establishing business requirements to planning what will be required to support and maintain the system once it is up and running.

In order to complete this project, click on the link below to review and print the Good Apples Group Case. This document describes the Good Apples Group facility, the way they do business, and the need they have for an EHRS. Each component of the project is based on the needs of the Good Apples Group. You will be building a plan for delivering an EHRS system to Good Apples Group.

• Good Apples Group Case

• If the above link will not open, please copy and paste the link below into a browser:

https://content.learntoday.info/Learn/HI300_Spring_14/site/Media/Good%20Apples%20Group%20Case.doc

Due Date

Your final project is due in Module 10. There are individual assignments along the way. The module they are due is noted in the timeline below.

Time Line

Requirements

Your final paper must 10 - 20 pages long. It should demonstrate an understanding of the problem expressed in the Good Apples Group case, and should present valid, accurate recommendations in each section. The final paper should incorporate feedback from your instructor on all the individual assignments, and should be free of grammatical or spelling errors.

The final paper will consist of:

• Cover Page

• Business and User Requirements Section

• EHR Project Plan Section

• Data Retention Plan Section

• Support and Maintenance Requirements Section

Evaluation

Each assignment leading up to the final assignment is evaluated and graded independently. Your instructor will provide specific grading criteria for each step of the project prior to its due date.

Requirements Gathering

What Is a Requirement?

A requirement is a description of what the product or service being created must do or what characteristics it needs to have. During the early phases of a project, requirements are written by business analysts in terms of how the project must benefit the organization and are typically non-technical. For example, such a business requirement might be "the project must manage appointment scheduling."  Such a statement could describe a well designed notebook as easily as a software product, and this business-centric type of requirement is important to ensure that the initial requirements of a project focus on the needs of the users, and do not bias the project towards any specific solution. Later in the project, business requirements become more technical in order to describe how the system will actually work.

Requirements Analysis

The basic process of analyzing an organization to determine requirements involves three steps:

• Understand the existing situation (the as-is system)

• Identify improvements

• Define requirements for the new system (the to-be system)

To move the users "from here to there," an analyst needs strong critical thinking skills and should not be swayed by previous product experiences or recommendations of solutions that have worked in other organizations.

As an example, consider a project where a user expresses a requirement that the new system must "eliminate overlapping patient appointments." While this might be a worthy goal, the analyst needs to think about it critically. The analyst could first have the users think about circumstances leading to overlaps (two people adding appointments simultaneously to the schedule), and then describe the issues that lead to these circumstances (lack of communication, duplicate scheduling tools). By focusing on these issues, the team is in a better position to develop new business processes that address these concerns. We should note that requirements analysis techniques and requirements gathering techniques go hand in hand. Analysts need to use requirements-gathering techniques to collect information; requirements analysis techniques drive the kind of information that is gathered and how it is ultimately analyzed.

Requirements Gathering Techniques

Requirements gathering can and should be conducted using a number of different techniques. A fact many analysts must contend with is that some information presented by end users may be unreliable, but an even greater problem is the fact that not every expressed need can be addressed in the current project. Using several approaches and involving a wide range of people helps to balance the information gathered to thoroughly inform the requirements gathering process.

Common techniques include:

• Direct interviews

• Group discussions

• Focus groups

• Questionnaires / Surveys

• Direct observation

• Document reviews

Requirements Gathering in Practice

An important consideration before getting to work on gathering requirements is that an analyst should acknowledge the importance of building political support for the project and establishing trust between the project team and the end users of the system. This process may be time consuming and require everyone in the organization to participate, but it should not disrupt the operations of the organization and should be conducted in a way that is convenient and sensible to those helping out.

The analyst should be careful when determining who is included in the requirements-gathering process. The choice to include (or exclude) someone is significant; involving someone in the process implies that the analyst views that person as an important resource and values his or her opinions. You must include all of the key stakeholders (the people who can affect the system or who will be affected by the system). This might include managers, employees, staff members, and even some patients. Also, be sensitive to the fact that some people may have significant influence within the organization even if they do not rank high in the formal organizational hierarchy. If you do not involve a key person, that individual may feel slighted, causing problems during implementation (e.g., saying "I could have told them this might happen, but they didn’t ask me!").

Finally, do everything possible to respect the time commitment that you are asking the participants to make. The best way to do this is to be fully prepared and to make good use of all the types of requirements-gathering techniques. Although, as we will see, interviewing is the most commonly used technique, other indirect methods may help the analyst develop a basic understanding of the business domain so that the direct techniques are more productive. In general, a useful strategy for the analyst to employ is to begin requirements gathering by interviewing senior managers to gain an understanding of the project and get the "big picture." These preliminary interviews can then be followed by document analysis and, possibly, observation of business processes to learn more about the business domain, the vocabulary, and the as-is system. More interviews may then follow to gather the rest of the information needed to understand the as-is system.

Requirement Writing Format

Requirements used in the delivery of IT projects must be written in such a way as to make it perfectly clear what the end product must do. For this reason it is important to remove ambiguity and focus on concrete, observable criteria.

Requirements can be grouped into three categories: business, user, and technical:

Business Requirements

A business requirement is an objective of the project that most closely resembles an existing business process. Business requirements are technology-neutral, meaning that they are written in such a way as to not specify what method will be used to meet the objective. As a matter of fact, a good measure of the usefulness of a business requirement is if it could be argued that a wholly non-electronic solution could satisfy the requirement. An example of a business requirement for an ADT (Admission, Discharge, Transfer) system might read:

The solution should gather and retain all data from patients from pre-admission through their discharge from the facility.

User Requirements

A user requirement describes functionality from the perspective of those people who will be using the project regularly. These should also be technology-neutral, generally speaking, although they are often written to address very specific needs. For the ADT system a user requirement could be:

The solution must permit digitally scanning insurance cards at admission in order to initiate patient record entry.

Technical Requirements

Technical requirements are often the most specific of the requirements needed to build a project, and should provide as specific a blueprint as possible for the developers. Business analysis specialists and the developers themselves are often engaged to write these requirements so that they clearly describe what needs to be built. An example of a technical requirement for the ADT system could be:

The solution must be compatible with input from Medicscan card scanners model 800N, 900, 3000DN.

Many of the requirements in these three categories may overlap, since they may be used by different members of the project team. All of them must be prepared prior to developing the solution, however, since as a body these requirements represent what is essentially a contract for completing the project. Requirements are therefore used not only for planning the exact time and resources needed to build the project, but may also be used to hold the project team accountable for their work once the project is delivered.