Solution: Object Oriented Software Engineering Assignment # 02

Object Oriented Software Engineering
Assignment # 02
Due Date: 19- 03-2021 Section: Total Marks: 100

Program: BS(SE)
Solution
Table of Contents
REVISION HISTORY................................................................................................................................................II
DOCUMENT APPROVAL........................................................................................................................................II
3. SPECIFIC REQUIREMENTS................................................................................................................................2
3.1 EXTERNAL INTERFACE REQUIREMENTS...............................................................................................................3
3.1.1 User Interfaces.............................................................................................................................................3
3.1.2 Hardware Interfaces....................................................................................................................................3
3.1.3 Software Interfaces.......................................................................................................................................3
3.1.4 Communications Interfaces..........................................................................................................................3
3.2 FUNCTIONAL REQUIREMENTS...............................................................................................................................3
3.2.1 <Functional Requirement or Feature #1>..................................................................................................3
3.2.2 <Functional Requirement or Feature #2>..................................................................................................3
3.3 USE CASES............................................................................................................................................................3
3.3.1 Use Case #1..................................................................................................................................................3
3.3.2 Use Case #2..................................................................................................................................................3
3.4 CLASSES / OBJECTS..............................................................................................................................................3
3.4.1 <Class / Object #1>.....................................................................................................................................3
3.4.2 <Class / Object #2>.....................................................................................................................................3
3.5 NON-FUNCTIONAL REQUIREMENTS......................................................................................................................4
3.5.1 Performance.................................................................................................................................................4
3.5.2 Reliability.....................................................................................................................................................4
3.5.3 Availability...................................................................................................................................................4
3.5.4 Security.........................................................................................................................................................4
3.5.5 Maintainability.............................................................................................................................................4
3.5.6 Portability.....................................................................................................................................................4
3.6 INVERSE REQUIREMENTS......................................................................................................................................4
3.7 DESIGN CONSTRAINTS..........................................................................................................................................4
<Online Pharmacy System>
3.8 LOGICAL DATABASE REQUIREMENTS..................................................................................................................4

3.9 Other Requirements.............................................................................................................................................4
Software Requirements Specification Page ii

3. Specific Requirements
External Interface Requirements
User Interfaces
We aim to provide simple yet interactive interfaces to the all the stakeholders of the
system. This might require the help of a web desginer as we lack skills to achieve the target.
Software Interface
As Java is open source technology so it can run on number of platforms or Operating
systems as:
Windows
Mac OS
Linux
Unix
Hardware interface
No special hardware is required for this web-based application. A standard PC,
smartphone with following processing power is more than enough for the requires operations of
the system.
Minimum 256 MB RAM
Minimum required memory 5 GB
Communications Interfaces
Our software would require a high speed Internet will be required to process systems
different operations, this is also the need of the project as we are required to build a web based
software and that it will use a client-server architecture.
Functional Requirements
We have categorised Functional Requirements of our system in the following three main areas,
the detail of which have been explained in the aforementioned parts of SRS. Their individual
characteristics will be further elaborated in the design phase before they are implemented.
However, system functions are decribed in the form of Use Case Diagram and their description
in the following chapters.
Order Management & Communication
Order Verification and Confirmation
Order Fulfilment
Inventory Control
Stock Monitoring and Storage
Administration
Reporting
Software Requirements Specification Page 3

Analysis
Use Cases

Use Case #1
Use Case ID: 1
Use Case Name: Sign up
Date Created: November 26, 2015
Actors: Customer
Description: Customer needs to be registered to be able to purchase any medicine. A
customer will need to be registered only once. He will provide basic
some basic information like name, NIC number, mailing address, contact
number etc. and set a password for his account. Only one account will be
created against each NIC number.
Preconditions: 1. Customer should have opened the website
2. The customer should have requested for sign up
Post conditions: 1. System must have added the record of the customer in the database
Normal Flow:
Customer System
1. System will prompt the
customer to enter basic
information
2. Customer will enter the basic
information
3. System will verify that the
entered CNIC number is not
in the database
customer to set a new
password and verify
5. The customer will enter a new
password and will re-enter it
6. If both entered passwords
match and satisfy password
requirements then create an
account for the customer
Alternative Flows:
Exceptions:
CNIC Number already registered
Ask the user to login or recover password
Passwords do not match

Ask the user to retype passwords
Password does not satisfy password requirements

Ask the user to modify password as per requirements

Use Case #2
Use Case ID: 2
Use Case Name: Login
Actors: Customer
Description: Customer needs to be logged in before purchasing any medicine. The
customer will need to add the CNIC number and password to login
2. The customer should have requested for login
Post conditions: 1. The customer should be logged in
Normal Flow:
Customer System
customer to enter CNIC
number and password
2. Customer will enter his CNIC
number and password
3. System will authenticate the
user
4. System will display a
welcome message to the
customer
Alternative Flows:
Exceptions: 2.1 User not authenticated
Ask the user to re-enter CNIC number and password
Use Case #3
Use Case ID: 3
Use Case Name: Search medicine
Actors: Customer
Description: Customer will be able to search any medicine by entering medicine name
or medicine’s formula
Preconditions: 1.Customer should have opened the website
Post conditions: 1. System must be displaying full list of medicines that match the
customer’s search
Normal Flow:
Customer System
customer to enter medicine’s

name or formula
2. Customer will enter the either
the name or formula of the
required medicine
3. System will fetch the record
of the medicine from the
database and check if stock is
available
4. System will display the record
to the customer
Alternative Flows: 3.1 User wants to search multiple medicines
Return to step 2.
Exceptions: 3.2 No medicines found

Inform the user that record is found and ask the user to recheck the
spellings
Use Case #4
Use Case ID: 4
Use Case Name: Place Order
Actors: Customer
Description: Customer should be able to place the order of the medicine by searching
the medicine and entering the required quantity and potency.
2. Customer should be logged in to the system
3. Customer should have asked to place an order
Post conditions: 1. System should have decremented the stock value
Normal Flow:
Customer System
customer to enter name or
formula of the medicine
2. Customer will enter either name
or formula of the medicine
3. System will fetch the record of

the medicine from the database
and check if stock is available
4. System will display the record to

the customer and prompt for
quantity and potency

5. The customer will enter

required quantity and potency
6. System will update the
database by decrementing the
stock
Alternative Flows: 4.1 User wants to place order for multiple medicines
Return to step 2.
Exceptions: 4.2 No medicines found

Inform the user that record is found and ask the user to recheck the
spellings
Use Case #5
Use Case ID: 5
Use Case Name: Login (Non customer)
Actors: Admin / Cashier / Stock maintainer / Owner
Description: For all the administrative staff and the owner, it should be necessary to
first login to the system to perform any operations. The user will enter
user name, password and one of the user types i.e. cashier, stock
maintainer, admin and owner.
Preconditions: 1. User should have opened the pharmacy system
2. User should have asked to login to the system
Post conditions: 1. The user should be logged in
Normal Flow:
Admin / Cashier / Stock System
maintainer / Owner
1. System will prompt the user to
enter user name, password
and user type
2. User will enter his user name,
password and user type
3. System will authenticate the
user
4. System will display the home
screen according to the user
role
Alternative Flows:
Exceptions: 5.1 User not authenticated
Ask the user to re-enter name and password or to change the user
type

Use Case #6
Use Case ID: 6
Use Case Name: Create new invoice
Actors: Admin / Cashier
Description: Admin and cashier should be able to enter new invoice record. An
invoice record consists of invoice ID, customer information, medicine
information and order details including quantity, amount etc.
2. User should be logged into the system
3. User should have requested to enter new invoice record
Post conditions: 1. Stock values must be updated
Normal Flow:
Admin / Cashier System
enter invoice details
2. User will enter invoice details
3. System will verify the details
and if it was a direct purchase
then update the stock values
accordingly
Alternative Flows: 6.1 User wants to enter record of multiple invoices
Return to step 2.
Exceptions: 6.2 Customer refused to take order on delivery

Increase the stock value accordingly and update the reason in
customer’s record.
Use Case #7
Use Case ID: 7
Use Case Name: View invoice
Description: Admin and cashier should be able to view invoice records. The invoice
record will consist of customer information, medicine information and
order details including quantity, amount etc. User should be able to
search on the basis of invoice number, medicine name customer name, or
search all invoices.
3. User should have requested to view invoice details
Post conditions: 1. The user should be displayed the invoice records according to search

criteria
Normal Flow:
select a search criteria i.e.
invoice number, medicine
name, customer name or
search all invoices
2. User will select a search
criteria
enter details as per the
selected search criteria
4. User will enter the details
5. System will fetch the details
of the selected records and
will show to the user
Alternative Flows:
User wants to search on the basis of multiple criteria
Return to step 2.
User wants to search multiple invoices

Return to step 4.
Exceptions:
Use Case #8
Use Case ID: 8
Use Case Name: Update invoice
Description: Admin and cashier should be able to update invoice records. The invoice
record will be first searched as explained in Use Case #7 and then the
user will have option to update the information.
3. User should have requested to update invoice details
Post conditions: 1. The respective information must have been updated
Normal Flow:
update the information
2. User will update the

information
3. System will reflect the
changes in the database
Alternative Flows:
Exceptions: 8.1 User cancels the updating process
Take the user to home screen and do not perform any changes in the
database record
Use Case #9
Use Case ID: 9
Use Case Name: Delete invoice
Description: Admin and cashier should be able to delete invoice records. The invoice
record will be first searched as explained in Use Case #7 and then the
user will have option to delete the invoice
3. User should have requested to delete invoice
Normal Flow:
1. System will prompt the user if
he is sure to delete the record
2. User will confirm the deletion
3. System will delete the records
from the database
Alternative Flows:
Exceptions: 9.1 User cancels the deleting process
database record
Use Case #10

Use Case ID: 10
Use Case Name: Insert new doctor
Description: Admin and cashier should be able to enter new doctor’s record. A
doctor’s record consists of doctor ID, doctor name, specialization etc.


3. User should have requested to enter new doctor’s record
Post conditions: 1. New record of doctor must be added
Normal Flow:
enter doctor’s details
2. User will enter doctor’s
details
and if the doctor does not
already exist then add the
record of the doctor in the
database
Alternative Flows: 10.1 User wants to enter record of multiple doctors
Return to step 2.
Exceptions:
Use Case #11

Use Case ID: 11
Use Case Name: View doctor
Description: Admin and cashier should be able to enter new doctor’s record. A
doctor’s record consists of doctor ID, doctor name, specialization etc.
3. User should have requested to view doctor’s details
Post conditions: 1. The user should be displayed the doctor’s information according to
search criteria
Normal Flow:
doctor’s ID, doctor’s name or all
search doctors
2. User will select a search criteria

enter details as per the selected
search criteria


Alternative Flows:
Return to step 2.
User wants to search multiple doctors

Return to step 4.
Exceptions:
Use Case #12

Use Case ID: 12
Use Case Name: Update doctor
Description: Admin and cashier should be able to update doctor’s records. The
doctor’s record will be first searched as explained in Use Case #11 and
then the user will have option to update the information.
3. User should have requested to update doctor’s details
Normal Flow:
information
Alternative Flows:
database record
Use Case #13

Use Case ID: 13

Use Case Name: Delete doctor

Actors: Admin
Description: Admin should be able to delete doctor’s records. The invoice record will
be first searched as explained in Use Case #11 and then the admin will
have option to delete the doctor’s record
Preconditions: 1. Admin should have opened the pharmacy system
2. Admin should be logged into the system
3. Admin should have requested to delete doctor’s record
Normal Flow:
Admin System
1. System will prompt the admin
if he is sure to delete the
record
from the database
Alternative Flows:
Take the admin to home screen and do not perform any changes in
the database record
Use Case #14

Use Case ID: 14
Use Case Name: Insert new medicine
Actors: Admin / Stock Maintainer
Description: Admin and stock maintainer should be able to enter new medicine’s
record. A medicine’s record consists of medicine ID, medicine name,
potency, formula and price etc.
3. User should have requested to enter new medicine’s record
Post conditions: 1. medicine’s record must be updated
Normal Flow:
Admin / Stock Maintainer System
enter medicine’s details
2. User will enter medicine’s

details
and check if the medicine is
not already entered in the
database
4. System will add the medicine
record in the database
Alternative Flows: 14.1 User wants to enter record of multiple medicines
Return to step 2.
Exceptions: 14.2 Medicine already present in the database

Inform the user that the medicine is already present in the database
Use Case #15

Use Case ID: 15
Use Case Name: Search medicines
Description: Admin and stock maintainer should be able to search medicine’s records.
The medicine’s record will consist of medicine ID, medicine name,
potency, formula, price, expiry date and available quantity etc.
3. User should have requested to view medicine’s details
Post conditions: 1. The user should be displayed the medicine’s records according to
search criteria
Normal Flow:
medicine’s number, medicine
name, medicine’s formula,
price, expiry date and
available quantity etc.
2. User will select a search
criteria
enter details as per the
selected search criteria

Alternative Flows:
Return to step 2.
User wants to search multiple medicines

Return to step 4.
Exceptions:
Use Case #16

Use Case ID: 16
Use Case Name: Update medicine
Description: Admin and stock maintainer should be able to update invoice records.
The invoice record will be first searched as explained in Use Case #15
and then the user will have option to update the information.
3. User should have requested to update medicine’s details
Normal Flow:
information
Alternative Flows:
database record
Use Case #17

Use Case ID: 17
Use Case Name: Delete medicine
Description: Admin and stock maintainer should be able to delete medicine’s records.

The medicine’s record will be first searched as explained in Use Case

#15 and then the user will have option to delete the medicine’s record
3. User should have requested to delete the medicine’s record
Normal Flow:
1. System will prompt the user if
he is sure to delete the record
from the database
Alternative Flows:
database record
Use Case #18

Use Case ID: 18
Use Case Name: Generate Report
Actors: Admin
Description: Admin should be able to generate different kind of reports including
daily sales report, stock report with respect to pharmaceutical company
and stock report with respect to expiry etc.
Preconditions: 1. Admin should have opened the pharmacy system
2. Admin should be logged into the system
3. Admin should have requested to generate report
Post conditions: 1. The respective report should be generated and sent to the owner
Normal Flow:
Admin System
1. System will prompt the admin
to select the type of the report
2. Admin will select the type of
the report
3. System will generate report
for the specified type and will
send to the owner
Alternative Flows:

Exceptions: 18.1 User cancels the report generation process

Take the user to home screen.
Use Case #19

Use Case ID: 19
Use Case Name: View Report
Actors: Owner
Description: Owner should be able to view reports generated and sent by the admin.
The reports include daily sales report, stock report with respect to
pharmaceutical company and stock report with respect to expiry etc.
Preconditions: 1. Owner should have opened the pharmacy system
2. Owner should be logged into the system
3. Owner should have requested to view the report
Post conditions: 1. The respective report must have been displayed to the owner
Normal Flow:
Owner System
1. System will prompt the owner
to select the type of the report
2. Owner will select a type of
report
3. System will display the report
of the specified type
Alternative Flows:
Exceptions:
Classes
At this point in time, we have only identified a few of the following general
classes that may change when at the time of design and/or implementation phase.
Medicine
Customer
Pharmaceutical Company
User (Manager, Data Entry
Operator) Invoice)
Report
Non-Functional Requirements
Performance
Since we have suggested client-server architecture for this system, we will
ensure that response to client’s request are as efficent as possible using available

techniques. However, the constraint of Internet speed may affect our efforts that
cannot be ignored.
Reliability
Reliability of a system is concerned with how accurate and efficient your
system is in performing any kind of task. Our proposed system is truly reliable in terms
of account management.
Flexibility
The system will provide flexibility so that when external change occurs it will
make no effect on the software. The software will run similar in any case.
Security
Security is one of the key issues in measuring the performance of any system.
Our application is fully secure from unauthorized access. Only those users can access
the applications that will have an account to this application. All the accounts are
secured using encryption techniques and saved in database and end-user is not allowed
to view the database created and managed by the developers.
Quick response
The primary purpose of our web-based application is to facilitate the users for
communication as fast as possible. Response time is not just related with the
communication it also refers to, how fast and accurate your application is to response
to the end users.
Portability
Our system is a web-based application that can be operated on different
platoforms requiring only Java and Internet connection. However, the project may
further be extended to develop dedicated applications for certain platforms. An
example of it may be to develop a web application using PhoneGap that will easily port
the application to run on any platform using its browser.
1. Change Management Process

As we are pursuing this project for our course of Object Oriented Analysis and Design
to understand of what the Object Orientated Design process involves and how to
develop software systems using Java (J2EE & Netbeans IDE), we don’t aim to revise
our SRS in future.

Solution: Object Oriented Software Engineering Assignment # 02

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Solution: Object Oriented Software Engineering Assignment # 02

Uploaded by

Copyright:

Available Formats

Object Oriented Software Engineering

Due Date: 19- 03-2021 Section: Total Marks: 100

3.8 LOGICAL DATABASE REQUIREMENTS..................................................................................................................4

Software Requirements Specification Page ii

Software Requirements Specification Page 3

Software Requirements Specification Page 4

Passwords do not match

Password does not satisfy password requirements

Software Requirements Specification Page 5

Software Requirements Specification Page 6

Exceptions: 3.2 No medicines found

3. System will fetch the record of

4. System will display the record to

Software Requirements Specification Page 7

5. The customer will enter

Exceptions: 4.2 No medicines found

Software Requirements Specification Page 8

Exceptions: 6.2 Customer refused to take order on delivery

Software Requirements Specification Page 9

User wants to search multiple invoices

Software Requirements Specification Page 10

Use Case #10

Software Requirements Specification Page 11

Preconditions: 1. User should have opened the pharmacy system

Use Case #11

3. System will prompt the user to

Software Requirements Specification Page 12

4. User will enter the details

User wants to search multiple doctors

Use Case #12

Use Case #13

Software Requirements Specification Page 13

Use Case Name: Delete doctor

Use Case #14

Software Requirements Specification Page 14

Exceptions: 14.2 Medicine already present in the database

Use Case #15

Software Requirements Specification Page 15

User wants to search multiple medicines

Use Case #16

Use Case #17

Software Requirements Specification Page 16

The medicine’s record will be first searched as explained in Use Case

Use Case #18

Software Requirements Specification Page 17

Exceptions: 18.1 User cancels the report generation process

Use Case #19

Software Requirements Specification Page 1

1. Change Management Process

Software Requirements Specification Page 2

You might also like