Medigood Case Study: A Business Analysis and System Design Report

This report presents a comprehensive business analysis and system design for the "Medigood" case study, aiming to outline strategies for project accomplishment and identify the optimal development model while fulfilling client requirements. It includes story designs illustrating software functionalities with acceptance criteria, a comparison of Agile and Waterfall methodologies, and a client-friendly report summarizing the project. The work breakdown structure (WBS) analyzes the project timeline, dividing tasks into manageable modules. The "To-Be" diagram represents future system states, while organizational change impacts are assessed through a comparison of "As-Is" and "To-Be" diagrams. Screen designs for patient and specialist registration are provided with associated business rules and design justifications. Application architecture is detailed, illustrating system interfaces. Recommendations focus on enhancing system interactivity and user-friendliness. The report concludes by highlighting the differences, pros, and cons of Agile and Waterfall models, recommending Agile for its flexibility and iterative nature.

Contents
List of figures.........................................................................................................................................1
List of tables..........................................................................................................................................1
Introduction...........................................................................................................................................2
Work Breakdown Structure...................................................................................................................3
“To-be” design – activity diagram..........................................................................................................4
Organisational change...........................................................................................................................5
Screen design........................................................................................................................................7
Acceptance Criteria.............................................................................................................................10
Applications Architecture....................................................................................................................11
Report to Client...................................................................................................................................12
Agile and Waterfall differences...........................................................................................................13
Conclusion...........................................................................................................................................15
References...........................................................................................................................................16
Appendix.............................................................................................................................................17
List of figures
Figure 1 To-Be diagram..........................................................................................................................4
Figure 2 design story for patient’s registration......................................................................................7
Figure 3 design story for Specialists registration...................................................................................8
Figure 4 Application Architecture........................................................................................................11
List of tables
Table 1 work breakdown table..............................................................................................................3
Table 2 differences between To-Be and As-Is diagram..........................................................................5
Table 3 RFT table.................................................................................................................................12
Table 4 Difference between agile and waterfall model.......................................................................13
Table 5 Journal Table...........................................................................................................................17
1

Introduction
This report is prepared for determining the business analysis for “Medigood” case study and aim of
this report to describe the various strategies to accomplish the project and provide the best model
utilized for development this system by fulfilling all the requirements of the client. This report
includes the story designs of this case study which will help to understand the functionalities of this
software with acceptance criteria for those designs. The recommended model for client provides its
pros and cons with distinguishing the differences with other model and prepare a report for the
client to understand the whole summary of this project.
2

Work Breakdown Structure
This structure is used for analyzing the time period required to designed this project using Gantt
chart and divide the work into small modules which will represent by hierarchical decomposition.
The below table is utilized to design hierarchical decomposition for this project (Tausworthe, 1979).
Table 1 work breakdown table
S. NO Task Name Number of Days Start date End date
1. Project 17 days 02/05/18 18/05/18
2. To-Be design 1 day 02/05/18 02/05/18
3. Organisational change 4 days 03/05/18 06/05/18
a. Comparison between As-Is
and To-Be
1 day 03/05/18 03/05/18
b
.
A brief note on Impact on
organization
1 day 04/05/18 04/05/18
c. Recommendations 2 days 05/05/18 06/05/18
4. Screen Design 4 days 07/05/18 10/05/18
a. Design for two stories 2 days 07/05/18 08/05/18
b
.
Identify business rules 1 day 09/05/18 09/05/18
c. Justification of design 1 day 10/05/18 10/05/18
5. Acceptance criteria 1 day 11/05/18 11/05/18
6. Application Architecture 3 days 12/05/18 14/05/18
a. Interfaces of all systems 3 days 12/05/18 14/05/18
7. Report to client 1 day 15/05/18 15/05/18
a. Executive summary 1 day 15/05/18 15/05/18
8. Agile and Waterfall
Differences
2 days 16/05/18 17/05/18
a. Brief for listing differences,
pros, and cons
1 day 16/05/18 16/05/18
b
.
Recommendation Agile 1 day 17/05/18 17/05/18
9. Video 1 day 18/05/18 18/05/18
a. Brief of the report in the
video clip
1 day 18/05/18 18/05/18
3

“To-be” design – activity diagram
The To-Be diagram is utilized for representing future states of the project which consist of the
process, organization culture, and required capabilities utilized in the proposed system to fulfill the
requirements of the project. The below diagram is designed for understanding the system future
aspects and how it’ll work for the organization.
Figure 1 To-Be diagram
4

Organisational change
The below table is prepared for describing the differences between As-Is and To-Be diagram for this
system in which business strategies are used for organization growth and determines differences
through these diagrams utilized for this system fulfillment.
Table 2 differences between To-Be and As-Is diagram
S. No As-Is Diagram To-Be diagram
1. This diagram discussed only the current
working system fields.
These diagrams determine the future
aspects of the system.
2. It didn’t discuss registering with the system. It provides the registering options or logs
in option for the system.
3. These diagrams do not provide appropriate
steps for booking an appointment.
These diagrams show all the steps taken
for a book an appointment.
4. These diagrams didn’t show any payment
related methods.
These diagrams show payment option
for treatment through an insurance
company.
5. These diagrams discuss the main components
of the system as Specialist and Patient.
These diagrams also determine main
components of the system with their
use.
6. This diagram didn’t provide working of system
management.
These diagrams provide working of
system management.
7. These diagrams explain only outer
functionalities of this system.
These diagrams show internal and
external functionalities of the system.
8. This diagram does not determine the
availability of medical specialist of the system.
This diagram also shows the availability
of medical specialist and appointment
confirmation of this system.
A brief note for impact on organization change
The business analysis has been carried out and diagram for To-Be is utilized for this process which
helps in to improvise the functionalities of this system. There are some impacts on organization
change as follows:
1. As this system change the aspect of appointment which was taken by stand in a queue and
now it is resolved by providing online appointment option of booking for patients who meet
the conditions of this system.
2. This system provides a register option for managing the traffic and give confirmation of the
appointment.
3. This system utilized for medical assistance which provides financial help for medical
treatment to old aged peoples and some others also but should meet the conditions of this
system for payment taken from the insurance company.
4. Old age patients can utilize this platform for their treatment.
5. This system manages the availability of medical specialists and provides appointments easily
on the basis of treatment.
5

6. This system provides the opportunity for bonus or claim the payment from the insurance
company for family doctors and medical specialist too.
Recommendations
The impacts for the management are huge and some new processes or plans provided by the system
organization to diminish the impacts as follows:
1. “Medigood” organization develop their system more interactive and user-friendly.
2. The system will update the newly added specialist to the organization for appointing to
patients.
3. This system diminishes the standard of pen-paper work and stands in a long queue for a
book an appointment.
4. This system will help in providing specialist at a particular time and need not wait for
treatment.
6

Screen design
The design of this system screen is designed for understanding the aspects of the organisation,
interface design, and provide clear-cut interaction for patients and medical specialist to register with
the system (Comber & Maltby, 1995).
The two stories designed in this report based on this system are as:
1. Patient Registration
This story is the main part of this system for utilization of organization which helps in
medical treatment to old aged peoples, indigenous ones and who are suffering from chronic
diseases. The below design represents web form for patients registration by filling all the
required fields to schedule an appointment on the basis of availability of specialists by
submitting the form.
Figure 2 design story for patient’s registration
7

2. Medical Specialist Registration
This story design is developed for specialists to register with this system for providing
medical assistance to patients who are in need of taking appointments and give treatment
for their disease. The below story consist a web form for registration with the organization
for future medical assistance to registered patients or recommended by family doctors.
Figure 3 design story for Specialists registration
Business Rules
The business rules based on above stories are introduced for organization growth and for getting
know the usefulness of this project which is as follows:
1. The above stories utilized for registering with the organization and it’ll help to determine the
growth of the organization by analyzing the number of registrations for particularly patients
and medical specialists.
8

2. The above designs provide a platform to grow business and help in to make a successful
strategy which will help in growing our organization.
3. The above stories will help to check the actions getting done on the above designs which will
help to recognize the constraints or conditions for the business rule.
4. The above designs provide conditions for making decisions and try to prove it successful for
business (Morgan, 2002).
Design justification
The justification is required for developed designs for the business or organization to provide its use
and some exceptions if any which will help to recognize the benefits of these things as follows:
1. The reason for designing the above stories is to provide an interactive platform which should
be user-friendly.
2. Another reason behind this they consist of all required fields which can utilize for a book an
appointment without any cause.
3. The above design for medical specialist has 1 field which might be most useful while
appointing a specialist to the patient on the basis of the category of treatment
recommended by a family doctor.
4. The above design platform will help in to provide online access to book an appointment
rather than stand in a queue to taking an appointment and wait for number (Gamma, 1995).
9

Acceptance Criteria
These are the conditions of business which set a boundaries or parameters which fulfil the
requirements of customers for determine the designs which are made by user for acceptance and
utilization and the acceptance criteria is provided after story is completed and working as expected
like real functionalities, basically it provides a conditions for satisfaction through design (Ermer &
Ploss, 2005).
Acceptance criteria for Patient Appointment story design 1 as:
1. Make a label and text area for first name, last name, address, age, and contact.
2. Provide a label for toolbar of appointment to know the design developed for this.
3. The last name, first name, the phone should contain last name, first name, and phone in
respective fields for patients.
4. The address field includes first line address and second line address and the address
provided in the respective fields which follows the basic rule for entering the address in first
and second line.
5. The date and time can be selected through date picker and input time in the respective
fields.
6. The design has an option for submitting which will save the data in the system database for
further confirming the appointment.
Acceptance criteria for Specialist Register story design as follows:
1. Create a text area with the label for first name, last name, designation, and phone.
2. Provide a label for toolbar of the specialist register to know the design developed for this.
3. The last name, first name, the phone should contain last name, first name, designation, and
phone in respective fields for medical specialists.
4. The email label with text area includes the email address with some condition of validating
address type store in the database for contact purpose.
5. The address field includes first line address and second line address and the address
provided in the respective fields which follows the basic rule for entering the address in the
first and second line of a medical specialist.
6. The one extra label for a specialist with its text area is also provided for getting know the
specialist field in particular region provided by a medical specialist while registering.
7. The design has an option for submitting and reset all fields which will save and erase all the
data from the portal which will further save the information in the system database for
future use.
10

Applications Architecture
The application architecture for an organization designed to analysis business skills and their aspects
for determines the interfaces of the system and observe the functionalities at client side as well as
their connections with the system interface.
Figure 4 Application Architecture
In the above architecture, diagram represents the system developed related to medical assistance in
which patient and specialist register with the system for utilizing the functionalities of this business
which will be analyzed by registrations and their data will be stored in the database with
synchronizing automatically. The “Medigood” is an organization which provides financial help for
patients who are above age 65. Suffer from chronic disease and indigenous. They communicate with
reference to their family doctors and medical specialist to provide medical assistance. The
organization provides a bonus for family doctors and medical specialist for providing treatments for
those who are in need by registering with the system which helps to book an appointment
(Wieringa, Blanken, Fokkinga & Grefen, 2003).
11

Report to Client
In this part, determining various specifications and its purpose or outcomes on the basis of Request
for Tenders for this system project. The below table defining specifications and its purpose utilizing
in this system for analyzing the business growth (Province, 2015).
Table 3 RFT table
Points to Cover RFT(Request for Tender)
Determines Specifications of software as providing
registering with the organisation, joined with
the organization, making connections,
provide a bonus, help in providing treatment,
appointment scheduling, many more.
Purpose/Outcomes Purpose of specifications as it provides
services to old age patients, indigenous,
suffer from chronic disease, confirmation of
appointments, provide medical assistance,
financial help in treatment, register the
medical specialist, patients, many more.
Executive Summary
The report is prepared to the client for choosing the tender or supplier for a solution for this project
who fulfills the business rules and requirements of the organisation. The processes required for this
project is prepared by tender or supplier i.e., developer undertakes the requirement of client and
composed in a software which follows the functionalities provided by the client. The team of
developing software analyze the requirements and apply model strategies in which developer who
apply better strategy to develop this software will get the contract. There is a various processes such
as analyzing the software, it's working, validation, testing, and implementation as per their needs
and these processes who apply much better selected as the supplier.
I recommend a better or preferred supplier who provides software by utilizing the best model
strategy to develop a fully functional software which fulfills all requirements and on every stage
before deploy take the client feedbacks/reviews to accomplish the final screen.
12