Below are the steps of how my basic clinic management system will flow. Please help to comment.

Clinic Flow Chart:

1. Patient approach the counter (manually)
2. Patient provides IC to the nurse (manually)
3. Nurse searches the patient details (automated)
4. If the patient details is found
4.1 Nurse add the patient to the waiting list (Red Color) (automated)
4.2 The patient visits the doctor (manually)
4.3 The doctor reviews the patient history (automated)
4.4 The doctor prescribes the medication for the patient (manually)
4.5 The nurse records the information (automated)
4.5.1 The waiting list is updated (Yellow Color)
4.6 The patient approach the counter and make payment (manually)
4.7 The nurse provide the patient with the receipt & MC (automated)
4.7.1 The waiting list is updated (Green Color)
5. If the patient detail is not found
5.1 Nurse add new patient record (automated)
5.2 Nurse add the patient to the waiting list (Red Color) (automated)
5.3 The patient visits the doctor (manually)
5.4 The doctor reviews the patient history (automated)
5.5 The doctor prescribes the medication for the patient (manually)
5.6 The nurse records the information (automated)
5.6.1 The waiting list is updated (Yellow Color)
5.7 The patient approach the counter and make payment (manually)
5.8 The nurse provide the patient with the receipt & MC (automated)
5.8.1 The waiting list is updated (Green Color)

Manually: 7 Automated: 9

Your help is kindly appreciated.

Thank You.

My comment is that you are making the all too common mistake of modeling the process before modeling the business.
Build your application upon a process model and it will be obsolete whenever the process or requirements change. Build it upon a data model and you can handle whatever processes the client requests.

Well actually this is part of the business requirement:
1. Identify the Business Problem
2. Modularization (Hierarchical chart)
3. Use case - (diagram, expended, high level) UML

The information I have given "Clinic Flow Chart" is the flow of the business. Some of the steps in the flow can be automated to solve the business problem.

The business' problem is that they don't seem to understand their own business. If they are hiring a consultant with a business requirement like that, then they are as clueless as some of the folks that I've seen trying to teach IT and business analytics courses without ever having worked in an actual business.

Since their requirement is focused on things discussed in textbooks instead of actual business needs, I suspect that whoever drew up the requirements has little or no understanding of the business process and is merely mimicing what they were taught in an introductory class. I'm sure that they mean well, but dealing with a business like that is dangerous to your professional reputation. I would avoid them at any cost, including being willing to simply tell them that they need to hire another consultant because I can't help them.

-PatP

Build it upon a data model and you can handle whatever processes the client requests.

But this will fall under the analysis and design stage right. Then the nerds can pick up the deliverables and make a program out of it.

The "Clinic Flow Chart" is just a personal understanding of how the business is running manually. This data can be collected using interview, observation and so on. Creating a business is a different. But in this case it's about introducing business process automation to an existing clinic that does their work manually.

The business' problem is that they don't seem to understand their own business.

To much of paper usage can be considered a business problem as an example.
Archiving to many patients record in a cabinet can be a business problem.
Searching a patients record in a bulk of files in a cabinet can be a business problem.
Creating duplicate copy of the patients information can be a business problem.
Human error can be a business problem.
.............

...and you will end up with a process-based application that will be a very limited, very crappy design.

so what is your proposal for requirement gathering?.

The UML concept - that is the use of use cases indicate the action to be performed by the user of the system as well as the response from the system as a result of the user action. It is a process and will be done during the requirement gathering stage. Therefore will this make the analysis and design stage:

very limited, very crappy design.

My comment is that you are making the all too common mistake of modeling the process before modeling the business.

Modeling the business?

Business Problem

1. Use lots of paper to keep the patient information.
Need space (Cabinet for filing)

2. Problem in searching the patient records.
Wrong placement of information

3. Human error
Wrong patients detail entered (DOB)
Patient re-registration

4. Doctor’s availability
Schedule (Date & Time)

5. Security problem.
Patients privacy

6. List of patience in the waiting list
Preferential treatment

7. Information Sharing
Communication between clinics

8. Standardization
Documentation (Invoice & MC)

Goals to Achieve

1. Store information into database
It can store million of information
Data is stored in a more organized manner

2. Provide the ability to search the information base on criteria
Use IC number to search patient records

3. Less typing of information
Select information from combo box

4. Provide the schedule
Doctor’s in duty

5. Provide restriction for information access
Provide the username and password

6. Organize patients in a sequential order
First In First Out

7. Provide information sharing
Patient information

8. Provide standard documentation
Document Format

Think Entities (Doctors, Patients, Schedules, Facilities, Treatments...)
Think Attributes (Names, Addresses, Dosages....)
Think Relationships (Nurses belong to Hospitals, Doctors may server multiple facilities, Hospitals have many patients, Patients receive many treatments....)

1) Design a Logical Entity Relationship Diagram to describe the business model.
2) Transform the Logical ERD into a Physical ERD and implement it in a database.
3) Create and application to enable the user to navigate and manage the data in the course of their duties.
This is data-centric development, and is much more robust than starting with Use Cases and Wireframes.

I am using the waterfall model:

1. Business problem & Goals to be achieved
2. Analysis & Design
3. Implement
4. Testing
5. Maintainance

Base my UML reading I found that when we are doing the analysis, we can come up with the use case diagram, expended use case and high level use case. This can be prepared by the business analyst who is probably a highly sociable person. After doing this then we do the design such as class diagram, pseudo code, flow chart and so on to describe the business problem.

Also during the Business problem & Goals to be achieved stage, we can perform modularization of the business problem. Each modules can be represented in the use case diagram under the analysis stage.

Please comment.

This is data-centric development, and is much more robust than starting with Use Cases and Wireframes.

So after creating the ER diagram and implementing it in the database, then I can start with the use case diagram, expended use case and so on?.

That is what I would recommend. If you design your model correctly, it should be able to support all your use cases with little or no modification or enhancement.