Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

patterson superstore case, Schemes and Mind Maps of Computer Communication Systems

pattersonsuperstorecase pattersonsuperstorecase

Typology: Schemes and Mind Maps

2022/2023

Uploaded on 06/20/2024

unknown user
unknown user 🇻🇳

1 / 92

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CHAPTER 1: PATTERSON SUPERSTORE
This course will introduce many new concepts regarding object-oriented analysis and design. To
make these concepts more relevant and understandable, we will apply the concepts introduced
in each chapter to a fictitious company called Patterson Superstore.
Patterson is a retail chain established in Pittsburgh, PA, in 1985. The chain has expanded
from four stores in the Pittsburgh area to a well-known national presence.
Initially Patterson sold diversified merchandise, including a variety of clothing, toys, house-
wares, sporting goods, and electronics. However, during the 2000s, it expanded its offerings into
groceries and pharmacies and began branding itself as a superstore.
In 2008, Patterson’s extended its pharmacy services by offering free blood pressure and
cholesterol screening and affordable flu shots. From the immediate success of these services,
the VP of the pharmacy division, Max Ross, recognized a growth opportunity and expanded
the pharmacy offerings to include in-store health clinics. Services offered include diagnosis
and treatment of minor illnesses (colds, strep, flu), skin conditions (impetigo, chicken-pox,
shingles), injuries (burns, cuts), and vaccinations (tetanus, HPV). Additionally, wellness
services such as school and sport physicals are available. The in-store medical clinics are staffed
by nurses and physician assistants or nurse practitioners and operate on an appointment or
walk-in basis.
Superstores, such as Patterson, enjoy several advantages over medical centers in offering
these services.
1. Since superstores have multiple types of income streams, delays in Medicaid and
other types of insurance reimbursement are significantly less problematic than for
medical centers that lack several revenue streams.
2. Superstores also enjoy reduced overhead cost while still generating the same copay
revenue collected by medical centers. A copay is still a copay.
3. Patients like the convenience of one-stop shop with a seamless care, diagnosis,
prescription fulfillment process.
4. Personnel costs tend to be lower than medical centers because the clinics are
overseen by a nurse practitioner or physician assistant with nurses providing much
of the care.
Max Ross has identified an additional opportunity related to the health clinic segment.
Currently, Patterson uses a mobile application to facilitate prescription order and refill, notifica-
tion, and auto-refill services. This service is widely used by Patterson’s client base, and Patterson
has leveraged this mobile app to gain an advantage over less technically advanced competitors.
Clients now want to use this technology to access health clinic services. Max Ross wants
to use this opportunity to position Patterson as a leader in the use of technology use for clinic
access. The system that he envisions would enable real-time communication with medical
1
A P P E N D I X
Patterson Superstore
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28
pf29
pf2a
pf2b
pf2c
pf2d
pf2e
pf2f
pf30
pf31
pf32
pf33
pf34
pf35
pf36
pf37
pf38
pf39
pf3a
pf3b
pf3c
pf3d
pf3e
pf3f
pf40
pf41
pf42
pf43
pf44
pf45
pf46
pf47
pf48
pf49
pf4a
pf4b
pf4c
pf4d
pf4e
pf4f
pf50
pf51
pf52
pf53
pf54
pf55
pf56
pf57
pf58
pf59
pf5a
pf5b
pf5c

Partial preview of the text

Download patterson superstore case and more Schemes and Mind Maps Computer Communication Systems in PDF only on Docsity!

CHAPTER 1: PATTERSON SUPERSTORE

This course will introduce many new concepts regarding object-oriented analysis and design. To

make these concepts more relevant and understandable, we will apply the concepts introduced

in each chapter to a fictitious company called Patterson Superstore.

Patterson is a retail chain established in Pittsburgh, PA, in 1985. The chain has expanded

from four stores in the Pittsburgh area to a well-known national presence.

Initially Patterson sold diversified merchandise, including a variety of clothing, toys, house-

wares, sporting goods, and electronics. However, during the 2000s, it expanded its offerings into

groceries and pharmacies and began branding itself as a superstore.

In 2008, Patterson’s extended its pharmacy services by offering free blood pressure and

cholesterol screening and affordable flu shots. From the immediate success of these services,

the VP of the pharmacy division, Max Ross, recognized a growth opportunity and expanded

the pharmacy offerings to include in-store health clinics. Services offered include diagnosis

and treatment of minor illnesses (colds, strep, flu), skin conditions (impetigo, chicken-pox,

shingles), injuries (burns, cuts), and vaccinations (tetanus, HPV). Additionally, wellness

services such as school and sport physicals are available. The in-store medical clinics are staffed

by nurses and physician assistants or nurse practitioners and operate on an appointment or

walk-in basis.

Superstores, such as Patterson, enjoy several advantages over medical centers in offering

these services.

1. Since superstores have multiple types of income streams, delays in Medicaid and

other types of insurance reimbursement are significantly less problematic than for

medical centers that lack several revenue streams.

2. Superstores also enjoy reduced overhead cost while still generating the same copay

revenue collected by medical centers. A copay is still a copay.

3. Patients like the convenience of one-stop shop with a seamless care, diagnosis,

prescription fulfillment process.

4. Personnel costs tend to be lower than medical centers because the clinics are

overseen by a nurse practitioner or physician assistant with nurses providing much

of the care.

Max Ross has identified an additional opportunity related to the health clinic segment.

Currently, Patterson uses a mobile application to facilitate prescription order and refill, notifica-

tion, and auto-refill services. This service is widely used by Patterson’s client base, and Patterson

has leveraged this mobile app to gain an advantage over less technically advanced competitors.

Clients now want to use this technology to access health clinic services. Max Ross wants

to use this opportunity to position Patterson as a leader in the use of technology use for clinic

access. The system that he envisions would enable real-time communication with medical

A P P E N D I X

Patterson Superstore

2 Appendix Patterson Superstore

personnel (audio, video, and text), mobile appointment scheduling, tele-health assessment,

and diagnosis of minor problems through video house calls. In addition, Patterson desires data

analytic and tracking capabilities.

This project would build on existing expertise within the IT department. The IT

department staff designed, developed, and maintains the sophisticated prescription fulfill-

ment system already in place at Patterson and can leverage that experience in creating the

proposed system.

The IT department has enthusiastically moved toward RAD and Object-Oriented

Methodologies and views familiarity with these methodologies as a strategic advantage. This

project would lend itself to such development and thus increase expertise in this area.

Based on the reading above and the criteria for selecting a methodology that you learned in Chapter 1, what methodology would you recommend?

Information Systems projects are approved at Patterson by a steering committee that consists of

high-level division representatives (such as Max) and IT division leaders. There are always many

projects to consider and to prioritize. Max Ross plans to present a systems request that outlines

his idea more fully at the next steering committee meeting. In this document, he will explain the

business need, opportunity, and business value of the proposed system.

One problem that Max envisions is pushback from other segments of the organization who

feel that the medical clinic concept is not part of the Patterson mission. However, the pharmacy

and health clinic area has been the most profitable division for the last two years, and Max

plans to explain how this project would further increase Patterson’s profitability by outlining the

expected financial benefits of the new systems.

How might you address the pushback?

In preparation for this meeting, Max is working with his team to develop high-level require-

ments for the proposed system and is also identifying issues and constraints related to his pro-

posed system.

Requirements:

■ Defined level of service offerings

■ Data analytics and tracking

■ Viewable wait time in real time

■ Walk-in clinic and automated response system for scheduling appointments

■ Referral information for conditions beyond the scope of the clinics service

■ Intuitive Auto response with periodic human monitoring to avoid unhandled clients

■ Video conferencing capability

■ Limited diagnostic capabilities for call-ins

Add to the list of requirements based on what you have read and your experience with medical care.

Problems currently experienced within the clinic that the system should address include:

■ Patients want to be able to schedule treatment but are often required to be evaluated

prior to a treatment appointment being scheduled

4 Appendix Patterson Superstore

CHAPTER 2: PATTERSON SUPERSTORE

In this segment of the Patterson Superstore case, we look more closely at the integrated health

clinic delivery system that Max Ross envisions, which will enable real-time communication and

scheduling for Patterson’s health clinics. In addition, we will examine the completed system

request that Max Ross and his team developed. Finally, we will review the feasibility analysis that

accompanies the request and see how the project is staffed and managed.

Project Identification and Systems Request

At Patterson, potential projects are reviewed during quarterly steering committee meetings

where participants from IT and the major business departments decide which projects to

approve. Approval is based on business need and on how well the project advances the

strategic objectives of the organization. Using the systems request template (Figure 2-1),

Max Ross prepared a system request for the Integrated Health Clinic Delivery System

(Figure 2-A).

The business need is to accommodate clients’ desire to electronically access health clinic

services. Doing so will heighten Patterson’s competitive advantage, improve customer service,

and increase the effectiveness of clinic offerings. Business need does not focus on the tech-

nology itself but instead on business elements, such as customer service, competitiveness, and

efficacy. At this juncture, business requirements are described at a high level of detail. Max’s

vision for the requirements includes:

■ Mobile appointment scheduling

■ Real-time communication with medical personnel (audio, video, and text)

■ Tele-health assessment and diagnosis of minor problems through video house calls

■ Data analytic and tracking capabilities

Business value describes how the requirements will affect the business. Intangible busi-

ness value will come from the increased satisfaction of current clinic customers and the

enhanced recognition of value-added aspects of Patterson’s clinical services. The proliferation

of mobile applications and the growing interest of consumers in having larger and more

convenient roles in their own healthcare further enhance the business value of this project.

Max expects that the system will increase the number of clinic clients by offering convenient

scheduling and service. This increase is projected to subsequently raise prescription and non-

prescription sales due to the upsurge of foot traffic in the clinics and stores. Market research

indicates that customers are seeking convenience in scheduling health appointments and that

there is growing frustration with the requirement of face-to-face visits for routine diagnosis.

Based on current clinic usage and the type of services currently requested, many customers do

not utilize available clinic services due to wait times and scheduling conflicts. Max estimates

that approximately 5 percent of potential service income is currently lost. A more convenient

system could increase existing customer base service income as well as generating new clinic

customers.

Feasibility Analysis

After reviewing the submitted systems request, the steering committee ranked the project

as a high priority. Kelly Herman, a senior systems analyst, was assigned to work with Max

to study the feasibility of the Integrated Health Clinic Delivery System. Kelly had been the

team lead for the prescription order notification and auto refill mobile app project and was

eager to develop further mobile services. Kelly and Max worked closely to develop the fea-

sibility analysis below based on the technical, economic, and organization perspectives of

the project.

Chapter 2: Patterson Superstore 5

Technical Feasibility

Technically, this project carries a low level of risk due to the expertise developed in the previous

mobile application project. The IT department staff designed, developed, and maintains the

sophisticated prescription fulfillment system already in place at Patterson and can leverage that

experience in creating the proposed system. The IT department has enthusiastically moved

toward Rapid Application Development and considers familiarity with these methodologies as a

strategic advantage. This project would lend itself to RAD development and thus is expected to

further increase proficiency in this area. The project size is considered medium risk because the

project team will include fewer than ten people. User involvement will be required for proof of

concept, testing, and requirements determination.

Economic Feasibility

Economic feasibility, based on the cost benefit analysis income shown in Figure 2-B, shows that

this project would significantly add to Patterson’s bottom line. While the development costs

would be a one-time expenditure (with subsequent maintenance), the operating costs would be

incurred at each clinic. However, as Figure 2-B indicates, even allocating total costs including

development to an individual clinic, the clinic would return a profit in the first year (using a

conservative estimate of income in the first year). Estimating a modest increase of 5 percent

per year yields substantial increases in each following year. Intangible costs and benefits include

increased satisfaction of current clinic customers and enhanced recognition of the ease of using

Patterson’s clinical services.

System Request—Integrated Health Clinic Delivery System

Project sponsor: Max Ross, Vice President of Pharmacy Services

Business Need: This project has been initiated to integrate health clinic services by providing real-time electronic communication and scheduling for Patterson Superstore health clinics.

Business Requirements:

  • Mobile appointment scheduling
  • Real-time communication with medical personnel (audio, video, and text)
  • Tele-health assessment and diagnosis of minor problems through video house calls
  • Data analytic and tracking capabilities

Business Value: We expect this integrated health clinic delivery system to lead to improved customer satisfaction and increased brand recognition due to its first mover advantage and increased convenience for clinic clients. Implementation of this system is also expected to boost in-pharmacy sales due to increased foot traffic in stores. Conservative estimates of tangible value to the company per clinic include:

  • $375,000 (75 percent of $500,000) in clinic services from new customers
  • $750,000 (75 percent of $1,000,000) in clinic services from existing customers
  • $50,000 in pharmacy sales from increase foot traffic in stores

Special Issues or Constraints:

  • The Pharmacy Department views this as a strategic system that will add value to the current business model and will also provide customers with increased convenience and satisfaction.
  • In order to gain first mover advantage, the system should be implemented in phases with the appointment scheduling piece in place within six months from the approval date.
  • Increased staffing will be needed to operate the new system from both the technical and business operations aspect.

FIGURE 2-A Systems Request

Chapter 2: Patterson Superstore 7

sequentially. Phased development-based methodologies quickly put a useful system into the

hands of the users. Because users begin to work with the system sooner, they are more likely to

identify important additional requirements sooner than with structured design. The time boxing

technique was chosen in conjunction with phased development to control scope and scheduling.

Time boxing steps include:

1. Set the date for system delivery.

2. Prioritize the functionality that needs to be included in the system.

3. Build the core of the system (the functionality ranked as most important).

4. Postpone functionality that cannot be provided within the time frame.

5. Deliver the system with core functionality.

6. Repeat steps 3 through 5 to add refinements and enhancements.

Since the appointment scheduling portion of the system needs to be in place within six

months from the approval date, the version 1 system delivery time is set. While the appointment

scheduling portion of the project is only one of the requirements, it is the most requested from

customers. Delivery of this phase to the clinic clients should increase satisfaction and conveni-

ence for customers and prepare them for subsequent versions of the envisioned system.

In the upcoming analysis phase, the overall system concept will be further defined and the

team will categorize the requirements into a series of versions.

Project Effort Estimation

One of Ruby’s project management duties was to estimate the project’s effort and schedule. Using

the Use Case Point Worksheet (see Figure 2-15), Ruby estimated the effort to create the new

system using the following steps.

1. Ruby and Max identified the business processes that the system would support and

the users who would interact with the system. Then they sorted different user types

into actors and arranged the business processes into use cases. The next step was

to classify each actor and use case as being simple, average, or complex. In the case

of the actors, the existing Pharmacy System had a well-defined API. As such it was

classified as a simple actor. Three average actors include interaction with the web,

mobile, and patient database. The Customer, Medical Staff, and Clinic Staff actors

were classified as being complex. This gave an Unadjusted Actor Weight Total Value

of 14.

2. Alec and Margaret classified each use case based on the number of transactions the

use case had to handle. For the Mobile Appointment Scheduling (Version 1), there

was one simple use case (Confirm Appointment), one average use case (Determine

Suitability), and one complex use case (Make Appointment). Based on these, a value

of 30 to the Unadjusted Use Case Weight Total was computed.

3. Ruby computed a value of 44 for the Unadjusted Use Case Points.

4. She rated each of the technical complexity factors, rated each of the environmental

factors, and computed the values for TCF and EF.

5. Using the Unadjusted Use Case Points and the TCF and EF values, Ruby calculated a

value of 52.73 for Adjusted Use Case Points.

6. Based on the decision rule for determining whether to use 20 or 28 as the value of

the person hours multiplier, Ruby used 20. Using these figures, Ruby estimated the

effort for the project to be 1,054.6 person hours. This equates to about 6.59 person

months (1,318.2/160). In other words, it would take a single person working full time

about 6½ months to complete the project.

8 Appendix Patterson Superstore

Unadjusted Actor Weighting Table:

Actor Type Description Weighting Factor Number Result

Simple External System with well-defined API 1 1 1 Average External System using a protocol-based 2 2 4 interface, (e.g., HTTP, TCT/IP, or a database) Complex Human 3 3 9 Unadjusted Actor Weight Total (UAW) 14 Unadjusted Use Case Weighting Table:

Use Case Type Description Weighting Factor Number Result

Simple 1–3 transactions 5 1 5 Average 4–7 transactions 10 1 10 Complex >7 transactions 15 1 15 Unadjusted Use Case Weight Total (UUCW) 30

Unadjusted use case points (UUCP) 5 UAW 1 UUCW 44 5 14 1 30 Technical Complexity Factors:

Factor Number Description Weight Assigned Value (0–5) Weighted Value Notes

T1 Distributed system 1.0 5 5. T2 Response time or throughput 1.0 5 5. performance objectives T3 End-user online efficiency 1.0 5 5. T4 Complex internal processing 1.0 3 3. T5 Reusability of code 1.0 3 3. T6 Easy to install 0.5 3 1. T7 Ease of use 0.5 5 2. T8 Portability 2.0 4 8. T9 Ease of change 1.0 3 3. T10 Concurrency 1.0 3 3. T11 Special security objectives included 1.0 5 5. T12 Direct access for third parties 1.0 5 5. T13 Special User training required 1.0 3 3. Technical Factor Value (TFactor) 52.

Technical complexity factor (TCF) 5 0.6 1 (0.01 * TFactor) 1.12 5 0.6 1 (0.01 * 52) Environmental Factors:

Factor Number Description Weight Assigned Value (0–5) Weighted Value Notes

E1 Familiarity with system 1.5 2 3. development process being used E2 Application experience 0.5 2 1. E3 Object-oriented experience 1.0 2 2. E4 Lead analyst capability 0.5 2 1. E5 Motivation 1.0 3 3. E6 Requirements stability 2.0 2 4. E7 Part time staff –1.0 0 0. E8 Difficulty of programming language –1.0 2 –3. Environmental Factor Value (EFactor) 11.

Environmental factor (EF) 5 1.4 1 (–0.03 (^) * EFactor) 1.07 5 1.4 1 (–.03 * 11) Adjusted use case points (UCP) 5 UUCP *TCF *ECF 52.73 5 44 * 1.12 * 1. Person hours multiplier (PHM) PHM 5 20 Person hours 5 UPC * PHM 1,054.6 5 52.73 * 20

FIGURE 2- C Project Effort Estimation Version 1 of the Integrated Health Clinic Delivery System

10 Appendix Patterson Superstore

I. Business Modeling a. Inception

1. Understand current business situation 2. Uncover business process problems 3. Identify potential projects b. Elaboration c. Construction d. Transition e. Production II. Requirements a. Inception 1. Identify appropriate requirements analysis technique 2. Identify appropriate requirements gathering techniques 3. Identify functional and nonfunctional requirements II.a.1, II.a. 4. Analyze current systems II.a.1, II.a. 5. Create requirements definition II.a.3, II.a. A. Determine requirements to track B. Compile requirements as they are elicited II.a.5.A C. Review requirements with sponsor II.a.5.B b. Elaboration c. Construction d. Transition e. Production III. Analysis a. Inception 1. Identify business processes 2. Identify use cases III.a.I b. Elaboration c. Construction d. Transition e. Production IV. Design a. Inception 1. Identify potential classes III.a b. Elaboration c. Construction d. Transition e. Production V. Implementation a. Inception b. Elaboration c. Construction d. Transition e. Production VI. Test a. Inception b. Elaboration

Duration Dependency

(Continued)

FIGURE 2-E Work-

plan for Version 1

of the Integrated

Health Clinic

Delivery System

Chapter 2: Patterson Superstore 11

c. Construction d. Transition e. Production VII. Deployment a. Inception b. Elaboration c. Construction d. Transition e. Production

VIII. Configuration and change management

a. Inception

1. Identify necessary access controls for developed artifacts 2. Identify version control mechanisms for developed artifacts b. Elaboration c. Construction d. Transition e. Production IX. Project management a. Inception 1. Create workplan for the inception phase 2. Create system request 3. Perform feasibility analysis IX.a. A. Perform technical feasibility analysis B. Perform economic feasibility analysis C. Perform organizational feasibility analysis 4. Identify project size IX.a. 5. Identify staffing requirements IX.a. 6. Compute cost estimate IX.a. 7. Create workplan for first iteration of the elaboration phase IX.a. 8. Assess inception phase I.a, II.a, III.a IV.a, V.a, VI.a VII.a, VIII.a, IX.a, X.a, XI.a XII.a b. Elaboration c. Construction d. Transition e. Production X. Environment a. Inception 1. Acquire and install CASE tool 2. Acquire and install programming environment 3. Acquire and install configuration and change management tools 4. Acquire and install project management tools b. Elaboration

Duration Dependency

(Continued)

Chapter 3: Patterson Superstore 13

CHAPTER 3: PATTERSON SUPERSTORE

The Integrated Health Clinic Delivery System will enable mobile appointment scheduling,

real-time communication with medical personnel (audio, video, and text), and facilitate cli-

ents’ desire to electronically access health clinic services. The system will be developed using

the phase development methodology and will begin with the mobile appointment portion of

the project.

Determining the system’s requirements is the most important activity in the systems

development process. A requirement is WHAT the system must do or WHAT characteristics

it must have. If the requirements are not fully or correctly defined, the system developed is

unlikely to meet the needs of the user. In other words, if the requirements are wrong, the

system will be wrong. Max defined the requirements in the systems request, at a very high

level of detail:

■ Mobile appointment scheduling

■ Real-time communication with medical personnel (audio, video, and text)

■ Tele-health assessment and diagnosis of minor problems through video house calls

■ Data analytic and tracking capabilities

As the team moves into requirements determination, the high-level requirements will be

expanded and refined. Requirements are either functional (WHAT the system must do) or

nonfunctional (HOW the system will behave). Functional requirements answer the question of

WHAT processing the system must perform or WHAT information the system must contain.

Nonfunctional requirements refer to the behavioral properties of a system and will be explored

in depth during the design phase (when the focus is on HOW the system will operate) but must

be considered from a high-level viewpoint during analysis. Creating a requirements definition

is an ongoing process of collecting information from users, analyzing the information collected,

identifying the appropriate business requirements, and adding them to the requirements defini-

tion report. While requirements definition is an iterative process, it must be carefully managed

to ensure that the evolving requirements fit the defined scope of the project. Scope creep has

caused many projects to fail because the requirements grow to the point that the project is never

finished. Ruby and Max are well aware that the scope of this project must be controlled. Their

plan is to retain requirements beyond the scope of the project in a requirements list that can be

addressed in the future versions.

Requirements Analysis Techniques

The envisioned system will improve the existing health clinic model by utilizing technology

to improve the efficiency and effectiveness of clinic operations. Moderate change will be

made to the way the clinic operates but the processes in place in the physical setting will

see little disruption. For this reason, the team needs to understand the current system but

will mainly focus on how to improve business processes. Some techniques that the team

chose to use are technology analysis, informal benchmarking, and duration analysis. Max

suggested that they plan joint application development (JAD) sessions with clinic managers,

front-line employees of the clinics (who take calls, receive complaints, and handle delays),

and with IT members who were involved with the prescription fulfillment rollout. Together

this group could explore current processes and problems, and brainstorm technical solu-

tions. To encourage all participants to freely share ideas, Ruby decided to run the session

as an e-JAD session utilizing the existing laptops and installed software in the Training/

JAD room. Sarah suggested that the team also schedule JAD sessions with technically savvy

clients currently using the clinic to gain an understanding of the userexperience and how

it might be improved.

14 Appendix Patterson Superstore

Ruby and Max conducted the internal e-JAD sessions over a three-day period. Ruby

used technology analysis to uncover available mobile and video technologies for the group

to consider. The first day’s session yielded a brainstormed list of how the health clinics might

use these technologies. Based on the potential for adding business and fit with the objectives

of the proposed system, Ruby categorized the ideas into three groupings: definite, possible,

and unlikely. On the second day, Max projected websites and promotional materials that

tele-healthcare providers and competing businesses currently use. While the sites were not

very specific with what they showed, the JAD participants were able to use the information

to begin a list of suggested business requirements for the project team. The third day’s session

did not go as well as the other two sessions. Ruby used duration analysis and attempted to

introduce the activity elimination technique. Because employees became defensive and terri-

torial regarding the speed and importance of their work, she quickly took a different tack and

instead used the remaining time to continue brainstorming on the use of technology and to

further develop business and high-level technical requirements.

Ruby and Sarah, the business analyst, conducted a one-day JAD session with exist-

ing clients from the busiest clinic. To encourage participation, they provided breakfast,

lunch, and a superstore gift card to participants. Ruby started the session by stating that

Patterson Superstore had listened to customers and was developing an Integrated Health

Clinic Delivery System. When Ruby outlined the proposed features, the group became

every excited. She explained that systems development was a lengthy process and that this

project would be completed in phases with the mobile appointment scheduling coming

first. Sarah then explained the importance of the user in developing the requirements for

the system. Brainstorming occupied most of the morning session with ideas again sorted

into definite, possible, and unlikely. One problem voiced about the current clinic that

the system would address is that patients want to be able to schedule treatment but are

often required to be evaluated prior to a treatment appointment being scheduled. During

lunch, Ruby noticed that the participants had begun complaining about wait times and

other problems with the current operation of the clinic. As soon as lunch was over, Ruby

introduced the concepts of duration analysis and fairly successfully turned the complaints

into an analysis of how long current processes took (from the customer’s perspective).

She decided not to use activity elimination because the clients lacked knowledge of the

clinics’ internal processes. Instead she used the results of the duration analysis to solicit

suggestions for reducing activities that the clients experienced themselves (again being

cognizant of internal processes). This would be useful information to share with develop-

ment team as well as with the clinic managers.

Requirements Gathering Techniques

In addition to providing information and ideas, the JAD sessions established trust and rap-

port with the stakeholders. Realizing that they needed a deeper understanding of the existing

processes, the team used document analysis, interview, and observation techniques to gather

further information. First, Kelly, the systems analyst, collected existing reports (e.g., appointment

schedules, input forms, diagnosis reference materials) and system documentation (functional,

structural, and behavioral models) that shed light on the as-is system. In this way, Kelly was

able to better understand the clinic processes and systems. When questions arose, Kelly

conducted short interviews with the individual who provided clarification. Next, Kelly inter-

viewed the senior analysts for the prescription fulfillment system to better understand the

lessons learned from that project. Kelly asked if there were integration issues that she would

need to address and also asked for input for the new system. Ruby interviewed the vendor of

the Cloud platform that Patterson was using and spoke at length with the Patterson IT individual

currently supporting the fulfillment system. Both provided information about the existing

16 Appendix Patterson Superstore

Functional Requirements

  1. Schedule appointment 1.1 Client requests to be seen by the clinic 1.2 The system displays the defined service offerings list 1.3 Client either chooses a defined service offering from the list or requests that a service need survey be completed so that the system can determine whether the service needed falls within the scope of the clinic’s capabilities 1.4 Referral information will be listed for conditions beyond the scope of the clinic’s service 1.4.1 Compare and evaluate referral need against referral list 1.4.2 Display appropriate referrals 1.5 Appointment information will be listed for conditions that fall within the scope of the clinic’s services 1.5.1 Current real-time availability will be displayed with wait time listed 1.5.2 Clients can choose appointment time for the current day or make an appointment in advance 1.5.3 The calendar will be updated to reflect scheduled appointment 1.5.4 Confirmation will be sent to client
  2. Communicate real time 2.1 Client can request real-time meeting with caregiver 2.2 Client indicates available time and technology preference 2.3 Caregiver responds with duration and availability 2.4 Session scheduled with clients, caregivers
  3. Assess via tele-health 3.1 Client answers question matrix to determine suitability for tele-health assessment 3.2 Limited diagnosis developed based on matrix answers from client 3.3 Diagnosis info reviewed by caregiver 3.4 Diagnosis info given to client if the problem is minor and diagnosis info is conclusive 3.5 Or Video-conference scheduled 3.6 Video conference held with diagnosis, follow-up, or referral

FIGURE 3-B Functional Requirements

Outline of the Systems Proposal for the Integrated Health Clinic Delivery System

  1. Table of Contents
  2. Executive Summary (To be completed once everything else is done)
  3. System Request (Figure 2-A)
  4. Economic Feasibility (Figure 2-B)
  5. Evolutionary Work Breakdown Structure (Figure 2-E)
  6. Requirements Definition (Figures 3-A and 3-B)
  7. Functional Model: To be completed in the future (see Chapter 4).
  8. Structural Models: To be completed in the future (see Chapter 5).
  9. Behavioral Model: To be completed in the future (see Chapter 6).
  10. Appendices A. Staffing Plan (2-D)

FIGURE 3-C Systems Proposal Outline

Chapter 4: Patterson Superstore Case 17

CHAPTER 4: PATTERSON SUPERSTORE CASE

While the Integrated Health Clinic Delivery System will be analyzed, designed, developed,

and implemented in phases, Ruby wanted to also maintain a big picture perspective of the

project. Therefore, as a first step toward developing a model of the functional requirements

for the system, Ruby directed Sarah, the business analyst, to capture thehigh-level business

processes in a use case diagram. Doing so provided a straightforward way to view the main

functions of the entire system and also depict the interactions between the business processes

and the systems environment. Figure 4-A shows a use case diagram of the three high-level use

cases (that correspond to the three versions to be developed) for the envisioned Integrated

Health Clinic Delivery System.

Integrated Health Clinic Delivery System


Client

Admin Staff

Medical Staff

Schedule Appointment

Assess via Tele-Health

Communicate Real Time

Mobile Prescription Fulfillment System

<>

Existing Health Clinic System

<>

FIGURE 4-A Use Case Diagram for the Integrated Health Clinic Delivery System

To further develop a high-level perspective of the Integrated Health Clinic Delivery System,

three overview use cases were developed. These overview use cases will help the analysts and

user agree on the requirements from a high-level perspective. For this reason, the three over-

view essential use cases shown below document the information known from the use case

diagram. As more information is learned about the use cases, the use case descriptions will be

converted from overview to detailed use case descriptions.

The use case diagram (Figure 4-A) showed the business processes and system environ-

ment; the overview essential use cases (Figures 4-B, 4-C, 4-D) modeled the high-level pro-

cesses for the overall system. Given the six-month time frame for delivery of the first phase,

Chapter 4: Patterson Superstore Case 19

  1. Schedule appointment 1.1 Client requests to be seen by the clinic 1.2 The system displays the defined service offerings list 1.3 Client either chooses a defined service offering from the list or requests that a triage questionnaire be completed so that the systems can determine whether the service needed falls within the scope of the clinic’s capabilities 1.4 Referral information will be listed for conditions beyond the scope of the clinic’s service 1.4.1 Compare and evaluate referral need against referral list 1.4.2 Display appropriate referrals

Ruby directed the team to get started by closely studying the business processes for Schedule

Appointment and to again review the functional and nonfunctional requirements (Figures

3-A and 3-B). Once the team was comfortable with their understanding of the requirements

for Schedule Appointment, they began the modeling process for Version 1 by drawing an

activity diagram for the use case.

Business Process Modeling with Activity Diagrams

While developing the activity diagram for the Schedule Appointment process, the team iden-

tified two additional activities needed in the process: comparing the referral need with the list

of available referrals and subsequently displaying the appropriate referral information. Figure

4-E shows the updated functional requirements and the activity diagram for the Schedule

Appointment use case.

(Continued)

FIGURE 4-D Overview Use Case Description for the Assess via Tele-Health Use Case

Use Case Name: Assess via Tele-Health ID: 3 Importance Level: High

Primary Actor: Health Clinic Client Use Case Type: Overview, Essential

Stakeholders and Interests: Client requests tele-health assessment Existing Health Clinic System Service provides information about tele-health clinic services and appointment availability Medical Staff provides tele-health assessment and diagnosis based on schedule availability Administrative Staff confirms appointments

Brief Description: This use case describes how an appointment is scheduled electronically

Trigger: Health Clinic Client requests tele-health assessment Type: External

Relationships: Association: Client, Medical Staff, Existing Health Clinic System, Mobile Prescription Fulfillment System Include: Extend: Generalization:

Normal Flow of Events:

SubFlows:

Alternate/Exceptional Flow:

20 Appendix Patterson Superstore

Calendar

Complete Service Need Survey Questions

Display Wait Times and Availability

Choose Appointment Compare/Evaluate Referral Need

Update Calendar

List Referral Information

Display Appropriate Referral

Send Confirmation

Display Clinic Services

[Beyond Service Code] [Within Service Scope]

[Chose Service]

FIGURE 4-E Functional Requirements and Activity Diagram for the Schedule Appointment Use Case

1.5 Appointment information will be listed for conditions that fall within the scope of the clinic’s services 1.5.1 Current real-time availability will be displayed with wait time listed 1.5.2 Clients can choose appointment time for the current day or make an appointment in advance 1.5.3 The calendar will be updated to reflect scheduled appointment 1.5.4 Confirmation will be sent to client