Business Analysis Report for Medigood: A System for Medical Assistance

This report presents a comprehensive business analysis for the "Medigood" case study, focusing on developing a system for medical assistance. It outlines the project's requirements, analyzes the "To-Be" design, explores organizational change implications, and presents screen designs with acceptance criteria. The report also compares Agile and Waterfall methodologies, recommending the most suitable approach for the project. Finally, it provides a report to the client, including an executive summary and a recommendation for a preferred supplier.

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

Agile and Waterfall differences
There are two models which are utilized for the development of software through their particular
process method (Palmquist, Lapham, Garcia-Miller, Chick & Ozkaya, 2013).
The below table distinguishes the agile and waterfall as:
Table 4 Difference between agile and waterfall model
S. No Agile Waterfall
1. It helps to determine or analyze the
process through clients.
It determines the software on their own by
following steps of development life cycle.
2. The team of this model are self-
motivated and organized which will
provide better results in the development
of software.
This model team is divided on each phase for
the development of software which will cause
in the time period and in the better result of
developed software.
3. The developed software for the system is
of the best quality and easily
understandable assured by an agile team.
This model results and its process are well
documented but not satisfactory due to lack
of interaction with users.
4. This model process for software
development is completely based on
incremental which will help to analyze
completed work and incomplete.
This model help in to manage the
dependencies as its process are divided
between various departments.
5. It’ll diminish the risk factors as it checks
the work done through client’s reviews.
It helps in to deliver the developed software
faster than agile.
6. This model evolved the users of this
software continuously at every stage to
determining any cause.
This model can be adapted easily by any
teams.
Pros of Agile:
 This process for developing software is more flexible by analyzing the business rules at every
stage.
 This model follows an iterative process because it verifies each stage more than once.
 This model test the every completed phase by taking feedbacks from users.
 This model prepare team requirements during a project development for diminishes the
errors.
Cons of Agile:
 It is not useful for small projects as it requires more fund.
 This model need of an expert to provide guidelines to meet with the client requirements.
 This model requires more cost than the others as it equips an expert to provide the final
software.
 This model needs guidance every time otherwise it’ll go off track and doesn’t meet the
requirements of the client (Ambler, 2002).
Pros of Waterfall:
13

 This model divides the development process of software into various stages.
 This model works on the sequential methodology to develop the software.
 In this model, first, build stage comes then testing phase for developing the software.
 This model reduces the risks as it already made the agreement for a fixed amount.
Cons of Waterfall:
 This model can’t be utilized for the large project.
 It might be less effective if all requirements don’t clear at first level.
 This model tests the project after completion done.
 As this model divides the process into phases so back step might not be possible or very easy
(Petersen, Wohlin & Baca, 2009).
Recommendation to Client
On observing all the aspects of the whole project and study the business rules for this software, I
recommend the Agile Model for the client to utilized for the development of software to fulfill all the
requirements and get a fully functional software which will use for grow their organization by taking
registrations of patients and medical specialists more. As the pros and cons of the agile model are
much better than waterfall and it evolves the user or client of this software at every phase to
determine the drawbacks or errors and not fulfilling all the requirements. This model is better to
utilized for developing a software for their organization.
14

Conclusion
This report concludes that all the information utilized for business analysis for developing software
to accomplish this project for “Medigood”. This report determines all methodology used for making
this software fully functional through comparing models with their cons and pros and choose the
best one to meet the requirements of the client. The report consists of the report for a client in
which executive summary of the whole project is provided and To-Be diagram is designed for
understanding the future working model of this system as it gives an idea on the basis of To-Be
diagram.
15

References
 Ambler, S.W., (2002). Agile modeling. Effective Practices for Extreme Programming and the Unified
Process. Wiley & Sons, New York.
 Province, W.C., (2015). REQUEST FOR TENDER.
 Tausworthe, R.C., (1979). The work breakdown structure in software project management. Journal of
Systems and Software, 1, pp.181-186.
 Ermer, J. and Ploss, H.J., (2005). Validation in pharmaceutical analysis: Part II: central importance of
precision to establish acceptance criteria and for verifying and improving the quality of analytical
data. Journal of pharmaceutical and biomedical analysis, 37(5), pp.859-870.
 Palmquist, S., Lapham, M.A., Garcia-Miller, S., Chick, T.A. and Ozkaya, I., (2013). Parallel worlds: Agile
and waterfall differences and similarities.
 Wieringa, R.J., Blanken, H.M., Fokkinga, M.M. and Grefen, P.W., (2003), June. Aligning application
architecture to the business context. In International Conference on Advanced Information Systems
Engineering (pp. 209-225). Springer, Berlin, Heidelberg.
 Comber, T. and Maltby, J.R., (1995). Evaluating usability of screen designs with layout
complexity. School of Commerce and Management Papers, p.1.
 Petersen, K., Wohlin, C. and Baca, D.,(2009), June. The waterfall model in large-scale development.
In International Conference on Product-Focused Software Process Improvement (pp. 386-400).
Springer, Berlin, Heidelberg.
 Morgan, T., (2002). Business rules and information systems: aligning IT with business goals. Addison-
Wesley Professional.
 Gamma, E., (1995). Design patterns: elements of reusable object-oriented software. Pearson Education
India.
16

Appendix
Project Journal
Table 5 Journal Table
S.NO Date Activity Explanation Duration Status
1 29/04/2018 Read the
assignment brief
Read brief and
understand.
1 day Completed
2 30/04/2018 Find out the
requirements
Analyze the project
requirements.
2 days Completed
3 02/05/2018 Analysis of work
breakdown
structure
Identify the project for
completion.
1 day Completed
4 02/05/2018 To-Be diagram To-Be diagram
designing.
1 day Completed
5 03/05/18 Organizational
Change
Compare As-Is and To-Be
diagram, briefing note,
recommendations for
managing.
4 days Completed
6 07/05/18 Screen design Design screens of the
project for understanding
the behavior and identify
business rules with the
justification of designs.
4 days Completed
7 11/05/18 Acceptance
Criteria
Criteria for accepting
designing provided.
1 day Completed
8 12/05/18 Application
architecture
Architecture prepared for
this project.
3 days Completed
9 15/05/18 Report to Client Prepare an executive
summary report to the
client for choosing a best
supplier and recommend a
preferred supplier.
1 day Completed
9 16/05/18 Agile and
waterfall
differences
Prepare a table for
differences, jot down pros
and cons of these models.
2 days Completed
10 18/05/18 Video Video making 1 day Completed
17