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
- 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
- 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
- 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
- Table of Contents
- Executive Summary (To be completed once everything else is done)
- System Request (Figure 2-A)
- Economic Feasibility (Figure 2-B)
- Evolutionary Work Breakdown Structure (Figure 2-E)
- Requirements Definition (Figures 3-A and 3-B)
- Functional Model: To be completed in the future (see Chapter 4).
- Structural Models: To be completed in the future (see Chapter 5).
- Behavioral Model: To be completed in the future (see Chapter 6).
- 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
- 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
