Page i of 33

LAB MANUAL OF SRE

SUBMITTED BY ARSHIYA SALEEM
REG NO 2019-BSE-004
BSE 3-A
DEPARTMENT OF SOFTWARE ENGINEERING
SESSION 2019-2023
SUBMITTED TO SIR SHOAIB
SUBMITTED ON DATE 29 -JANUARY-2021
TH

LABS: 1-10

SOFTWARE REQUIREMENT ENGINEERING

 Page ii of 33

LAB NO 01
TASK 1:

Consider in the following grocery list example. Identify requirements error in this list.

1. Milk
2. A loaf of bread
3. Orange juice
4. A box of cereal
5. Butter

Answer:
Requirements errors are:
A dozen egg, rice, milk, vegetables and flour should also be include in the glossary list. Because,
these things are he basic requirements for everyone. Beside it, we can exclude orange juice, loaf
of bread and butter from this list. This is because, not everyone uses these things in their daily
meal. And everyone can buy the above-mentioned glossary even in normal budget excluding
orange juice, loaf of bread and butter.

TASK 2:

Do you find any requirement errors in given statements? If yes:

Identify the type of error and write corrected version of these statements.

🡺 REQ1: On loss of power, the battery backup must support normal operations.
Yes, here is the requirement error because it is not possible for any battery to support normal
operations on the loss of power, as there are many reasons for this but one is, sometimes the
temperature of the room suddenly changes as moisture, hot etc. these environmental changes
affects the battery and battery cannot perform the functions.

🡺 REQ2: The system shall not accept passwords longer than 15 characters.
No, here is no error but this thing can become more useful if we specify that passwords should
include special letters or symbols, it shouldn’t include duplicate letters etc. this thing can make
security more tough and strong.

🡺 REQ3: The system shall have a natural language interface that will understand
commands given in English language.
Yes, here is the error. System can understand only binary language that is not natural and
humans cannot interface through this language. But, humans’ interface with the system through
their natural language and at back end system receive it as binary code. So, it is not possible for
the system to understand natural language of humans.

🡺 REQ4: The replacement control system shall be installed with no disturbance to

production.

SOFTWARE REQUIREMENT ENGINEERING

 Page iii of 33

Yes, here is the error, whenever replacement control system is installed there will be definitely
some disturbance for the production because everything is connected with one another and
depends mostly on one another’s functionality.

🡺 REQ5: The system shall resist concurrent usage by many users

No, there is no error in this statement because if system shall not resist then it can lead to many
ambiguities and speed may be slow.

TASK 3:

A requirement that says “Users should be able to move more quickly between screens” is
not verifiable. Why?
Answer:
The above statement is not verifiable because it is not possible that user move quickly between
the screens. User can operate one screen at a time only, it is not possible for a user to operate
more than one screen at a time. It consumes some time for user to move between multiple
screens.

TASK 4:

What will you end up with when you are asked “to divide 8 in a half”?
Answer:
To divide 8 in a half, we will divide 8 into two halves of 4.

LAB NO 02

TASK 1:
Write down Functional and Non-Functional Requirements of ATM
(Automated teller Machine)?
ANSWER
ATM (AUTOMATED TELLER MACHINE)
An automated teller machine (ATM) is an electronic telecommunications device that enables
customers of financial institutions to perform financial transactions, such as cash withdrawals,
deposits, funds transfers, or account information inquiries, at any time and without the need for
direct interaction with bank staff.
FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS OF ATM:
Functional requirements:
It defines the basic system behavior. It tells the system what to do and how to do.
Non-functional Requirements:
It defines system’s attributes such as security, reliability, performance, maintainability,
scalability, and usability.

SOFTWARE REQUIREMENT ENGINEERING

 Page iv of 33

Functional Requirements Non-Functional Requirements

FR-1 User must have ATM card for NFR-1 The user must enter the valid ATM
functions in ATM. card of bank.
FR-2 The card reader will determine the NFR-2 The card number should be valid.
card number from the card.
FR-3 After entering the card, machine will NFR-3 The user should enter correct
ask the unique pin/password from the pin/password.
user.
FR-4 The user will ask about the language NFR-4 If user forget the password, he will be
that he wants to select for his/her given with 3 attempts only for re-
transaction. entering the password, otherwise
machine should stop working.
FR-5 After selecting language, the menu NFR-5 ATM machine should be secure.
will be displayed on screen.
FR-6 Options will be displayed in the NFR-6 ATM machine shouldn’t mix data of
menu: individuals, it should work properly.
1.withdrawl 2. Deposit 3. Pay Bill
4. Exit
FR-7 User will select one option. NFR-7 ATM should have strong security that
no one can see or take data and
personal info of another person.
FR-8 Whole record of the transaction of the NFR-8 The printer can be opened and refilled
user will be displayed on the screen if with ink and papers.
user wants.
FR-9 The cash dispenser has the ability to NFR-9 ATM should be restart and shutdown,
dispense cash. when needed.
FR- If, user wants to print the record then
10 he can print it.
FR- Printer will see that it should have
11 proper ink and papers otherwise it
will show error.
FR- User’s whole record will be saved at
12 back end of machine.
FR- The user can do more than one
13 function by choosing the options but
one after another.
FR- The user can CANCEL the working
14 anytime. But after performing the
function he cannot cancel it.
FR- User will EXIT after all the working.
15
FR- Machine will eject the card when
16 session is completed.

SOFTWARE REQUIREMENT ENGINEERING

 Page v of 33

Software Requirements
Specification
for

<ATM>
Version 1.0 approved

Prepared by <Arshiya Saleem>

<Department of Software Engineering>

<15th-Oct-2020>

Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

SOFTWARE REQUIREMENT ENGINEERING

 Page vi of 33

Table of Contents
Table of Contents ......................................................................................................................... vi
Revision History ............................................................................... Error! Bookmark not defined.
1. Introduction ..............................................................................................................................6
1.1 Purpose............................................................................................................................................. 6
1.2 Document Conventions .................................................................................................................... 6
1.3 Intended Audience and Reading Suggestions .................................................................................. 6
1.4 Product Scope .................................................................................................................................. 6

2. Overall Description ..................................................................................................................6

2.1 Product Perspective.......................................................................................................................... 6
2.2 Product Functions ......................................................................................................................... 6,7
2.3 User Classes and Characteristics ..................................................................................................... 7
2.4 Operating Environment .................................................................................................................... 7
2.5 Design and Implementation Constraints .......................................................................................... 7
2.6 User Documentation ........................................................................................................................ 7
2.7 Assumptions and Dependencies ................................................................................................... 7,8
3. External Interface Requirements ...........................................................................................8
3.1 User Interfaces ................................................................................................................................. 8
3.2 Hardware Interfaces ......................................................................................................................... 8
3.3 Software Interfaces .......................................................................................................................... 8
3.4 Communications Interfaces ............................................................................................................. 9
4. System Features .......................................................................................................................9
4.1 System Feature 1 .............................................................................................................................. 9
4.2 System Feature 2 (and so on) ...................................................................................................... 9.10
5. Other Nonfunctional Requirements .....................................................................................10
5.1 Performance Requirements ............................................................................................................ 10
5.2 Safety Requirements ...................................................................................................................... 10
5.3 Security Requirements ................................................................................................................... 10
5.4 Software Quality Attributes ........................................................................................................... 10
5.5 Business Rules .......................................................................................................................... 10,11
6. Other Requirements ..............................................................................................................11
7. Appendix A: Glossary............................................................................................................11

SOFTWARE REQUIREMENT ENGINEERING

 Page 7 of 33

1. Introduction
1.1 Purpose

An automated teller machine (ATM) is an electronic banking outlet that allows customers
to complete basic transactions without the aid of a branch representative or teller. Anyone
with a credit card or debit card can access cash at most ATMs. ATMs are convenient,
allowing consumers to perform quick self-service transactions such as deposits, cash
withdrawals, bill payments, and transfers between accounts.

1.2 Document Conventions

ATM has its own functionalities. All have their equal importance and priorities. In this
document, I followed that every requirement must have to be documented accordingly to their
importance and priorities.

1.3 Intended Audience and Reading Suggestions

This document is meant for the readers so they can easily understand our polices and method to
use our project. The document is intended for, developers, project managers, marketing staff,
users, and testers. It is important for the readers to read the whole document very carefully. In
this document, every section is divided and have the information and knowledge about different
parts of our product.

1.4 Product Scope

An Atm machine has very high scope in this world of technology. In this fast world, it has saved
the time of people by making their common transactions easily by one click. People can attain
the facilities provided by atm anywhere in the world just by one click. It not only saves the times,
rather it has also paved the way for the world to know more about computers and science.

2. Overall Description
2.1 Product Perspective

The ATM is a single functional unit consisting of various subcomponents. This software allows
the user to access their bank accounts remotely through an ATM without any aid of human bank
teller. This software also allows to perform various other functions apart from just accessing his
bank account such as mobile bill clearings etc. The ATM communicates with the bank’s central
server through a dial-up communication link.

SOFTWARE REQUIREMENT ENGINEERING

 Page 8 of 33

2.2 Product Functions

The functions of an ATM are the following:

i. Debit
ii. Credit
iii. Paying bills
iv. Submitting fee
v. Account maintenance
vi. Mobile recharge

2.3 User Classes and Characteristics

There can be 3 different kinds of users that will interact with the system:
i. New user: A new ATM customer. This user has little or no experience with electronic
means. He can use the product by following the instructions on the screen about ATM.
ii. Experienced user: An experienced customer. This will be the user who has used the
product or system more than one time. He can perform his functions faster and more
accurate as he already used the system.
iii. Banker: A bank employee. This user is familiar with the functioning of the ATM. He
knows more about ATM as he uses the system daily and it is his basic routine of work.

2.4 Operating Environment

This system depends upon internet. It will operate in the environment where it should be internet.
Mostly it is with any bank and connected with the specific bank that make easy for the users to
solve all accounts problems side by side.

2.5 Design and Implementation Constraints

The major constraints that the project has are:
i. The ATM must service at most one person at a time.
ii. The number of invalid pin entries attempted must not exceed three.
iii. After three unsuccessful login attempts, the card is seized/blocked and need to be
unlocked by the bank.
iv. The simultaneous access to an account through both, the ATM and the bank is not
supported.

2.6 User Documentation

It is important for the users to know about the functionality of the system. So, for this purpose we
will launch a booklet with every product that will hold overall description of our system.
Different websites will also be created that helps the users, testers, managers and customers to
operate with the system.

SOFTWARE REQUIREMENT ENGINEERING

 Page 9 of 33

2.7 Assumptions and Dependencies

The requirements stated in the SRS could be affected by the following factors:
i. One major dependency that the project might face is the changes that need to be
incorporated with the changes in the bank policies regarding different services. As the
policies changes the system needs to be updated with the same immediately. A delay in
doing the same will result to tremendous loss to the bank.
ii. The project could be largely affected if some amount is withdrawn from the user’s
account from the bank at the same time when someone is accessing that account through
the ATM machine. Such a condition shall be taken care of.
iii. At this stage no quantitative measures are imposed on the software in terms of speed and
memory although it is implied that all functions will be optimized with respect to speed
and memory.

3. External Interface Requirements

3.1 User Interfaces

The interface provided to the user should be a very user-friendly. The interface provided is a
menu driven one and the following screens will be provided:
i. A login screen is provided in the beginning for entering the required username/pin no.
and account number.
ii. An unsuccessful login leads to a reattempt (maximum three) screen for again entering the
same information. The successful login leads to a screen displaying a list of supported
languages from which a user can select anyone.
iii. The screen will show different functions that a user can perform i.e. debit, credit etc.
iv. Then user will choose the function he wants to perform.
v. Another screen will be open regarding selected option by the user.
vi. In case of administrator, a screen will be shown having options to reboot system, shut
down system, block system, disable any service.

3.2 Hardware Interfaces

Hardware interfaces are those that system should have:

i. Power supply
ii. Monitor screen
iii. Money dispenser
iv. Printer
v. Pages for printers
vi. Ink for paper of printers
vii. Reset button
viii. Card reader

SOFTWARE REQUIREMENT ENGINEERING

 Page 10 of 33

3.3 Software Interfaces

In order to perform various different functions, this software needs to interact with various other
software. So, some are listed below:
i. The transaction management software used to manage the transaction and keep track of
resources shall be BMS version 2.0.
ii. The card management software used to verify pin no and login shall be CMS version 3.0.
Yamaha codecs 367/98 for active speakers.
iii. The database used to keep record of user accounts shall be Oracle version7.0.

3.4 Communications Interfaces

The machine needs to communicate with the main branch for each session for various functions
such as login verification, account access etc. So, the following are the various communication
interface requirements:
i. The system will employ dial-up POS with the central server for low cost communication.
ii. The communication protocol used shall be TCP/IP.
iii. Protocol used for data transfer shall be File Transfer Protocol (FTP)

4. System Features
Following are the features of the system:

System Feature 1 Remote Banking and Account Management

4.1.1 Description and Priority
The system is designed to provide the user with the facility of remote banking and
perform various other functions at an interface without any aid of human bank
teller.
4.1.2 Stimulus/Response Sequences
i. At the start, the user is provided with a log in screen and he is required to enter his
PIN NO. and Account details which are then verified by the machine. In case of an
unsuccessful attempt a user is asked again for his credentials but the maximum
number of attempts given to the user is limited to 3 only, failing which his card is
blocked and need to be unblocked by the bank for any future use.
ii. After a successful log in, the user is presented with a list of language.
iii. After the language selection, the user is directed towards a main page that displays
a set of options/services along with their brief description, enabling the user to
understand their functioning. The user can select any of the listed option and can
continue with the transaction.
iv. At any moment if the user wants to abort the transaction, he is provided with an
option to cancel it.

SOFTWARE REQUIREMENT ENGINEERING

 Page 11 of 33

v. After the user is finished with his work, for security purpose, he is required to log
out and then take his card out of the slot.
Validity Checks
In order to gain access to the system, the user is required to enter his/her correct user
id/pin no and account no failing which his card may be blocked. The user can access only
one account at a time and can enter only one account no. Also, if the user is an
administrator, he is required to enter his login id in order to access and change the
facilities provided by the system.
Sequencing Information
The information about the users and their account should be entered into the database
prior to any of the transactions and the backup be maintained for all account information.
Error Handling/ Response to Abnormal Situations
If any of the above validation/sequencing flow does not hold true, appropriate error
messages will be prompted to the user for doing the needful.

4.2 Receipt Generation

After each transaction user has performed, a receipt is generated that contains all the information
about the transaction.

5. Other Nonfunctional Requirements

5.1 Performance Requirements
Performance requirements of an ATM are:
i. The ATM shall provide customers a 24-hour service.
ii. The card verification time must not exceed 0.8 sec. under normal server workload and 1
sec. under peak server workload.
iii. The pin number verification time must not exceed 0.3 sec. under normal server workload
and 0.5 sec. under peak server workload.
iv. Touch screen and button response time must not exceed 5000ms.
v. Credit card advance time must not exceed 6 sec. under normal traffic and server and peak
traffic and server workload.

5.2 Safety Requirements

Safety requirements of an ATM are:

i. There shall be a security camera installed near the ATM.
ii. There shall be a secured cash vault with a combination locking system.
iii. The product cabinet cover shall be manufactured using Fiber glass for security purposes.

SOFTWARE REQUIREMENT ENGINEERING

 Page 12 of 33

5.3 Security Requirements

Safety requirements of an ATM are:

i. The password shall be 6-14 characters long.
ii. Passwords shall not contain name of customers as they are easy to be hacked.
iii. Passwords can contain digit, hyphen and underscore.
iv. User should be provided with only three attempts for login failing which his card needs to
be blocked.

5.4 Software Quality Attributes

The primary objective is to produce quality software, following guidelines will be used when judging the
quality of the software:
i. Consistency
ii. Test cases

5.5 Business Rules

Business rules are:

i. The Administrator has the authority to fix the rules and regulations and to set or update
the policies as and when required.
ii. In case of loss of the ATM card. The user has to lodge a First Investigation Report (FIR)
and present its one copy to bank officials for card blocking purposes.

6. Other Requirements
None.

7. Appendix A: Glossary
a. ATM An unattended electronic machine in a public place, connected to a data system
and related equipment and activated by a bank customer to obtain cash withdrawals and
other banking services.
b. Dial-Up POS A message format for low cost communications.
c. Internet An interconnected system of networks that connects computers around the
world via the TCP/IP protocol.

SOFTWARE REQUIREMENT ENGINEERING

 Page 13 of 33

LAB NO 04

Task:
Write down the 10 requirements for the order processing module of the Point
of sale and draw interaction matrix.
A POS (Point-Of-Sale) system is a computer system typically used to manage the sales in retail
stores.
Requirements For POS:
1. The system should be in black color only
2. The system should store all the prices of goods
3. The system should store the whole record of customers
4. The system read the barcode, barcode should contain all the information like
manufacturer name, price and quality of good
5. The system should have built-in printer to print the receipt for billing
6. The printer should be changed after 1 year
7. The processor of the system should Deduce stock amount of good
8. The processor of the system should Compute total amount
9. The system should automatically delete the record of customer after 3 months
10. The system should update the amounts of goods stored on barcode automatically

INTERACTION MATRIX
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10
R1 0 0 0 0 0 0 0 0 0 0
R2 0 0 1000 0 0 0 0 0 0 0
R3 0 1000 0 0 0 0 0 0 0 0
R4 0 0 0 0 0 0 0 0 0 1000
R5 0 0 0 0 0 1 0 0 0 0
R6 0 0 0 0 1 0 0 0 0 0
R7 0 0 0 0 0 0 0 1000 0 0
R8 0 0 0 0 0 0 1000 0 0 0
R9 0 0 1 0 0 0 0 0 0 0
R10 0 0 0 1000 0 0 0 0 0 0

LAB NO 05
➢ Task 1:
Patient, software department, mobile phone, school, bus, Rawalpindi express

a. Identify the classes and objects from the list given above.
b. Write at least 3 attributes and 2 operations of each class found in above list.
c. Name the possible class of objects you found in above list.
a.

SOFTWARE REQUIREMENT ENGINEERING

 Page 14 of 33

Classes Objects
Software department Mobile phone
Bus Rawalpindi express
Patient
School

b.
• Software department
Attributes Operations
Department students Find_semesters()
Department teachers no_of_Courses()
Department rooms

• Bus
Attributes Operations
Seat capacity Bus_arrival_timing()
Windows Travel_hours()
Engine

• Patient
Attributes Operations
Name Find_info()
Gender Medical_report()
Age

• School
Attributes Operations
Area Exams()
Classrooms Admission()
Population

c.
Object Name of Class
Rawalpindi express Bus
Mobile phone Electronic appliances

➢ Task 2:

First name, last name ,father name , date of birth, home address, matric marks
,intermediate marks , college name, postal address, age, mother name, eyesight number,
user name, email id ,Facebook id, password, confirm password, security question ,security
code, terms and conditions.

a. From the above list write down the information that you will need to sign up in a
yahoo account.

SOFTWARE REQUIREMENT ENGINEERING

 Page 15 of 33

b. From the list of information you gathered for signup in yahoo account abstract the
information that you will require to login to yahoo account.

a.

• First Name
• Last Name
• Father Name
• Date Of Birth
• Email Id
• Password
• Confirm Password
• Security Question
• Security Code
• Terms And Conditions

b.

user name

email id

password

➢ Task 3:

Build and decorate a house.

Class house
Attributes Operations
no_of_rooms Estimate_budget()
Bricks No_of_labourers()
no_of_windows Open_door()
Doors Close_door()
Chairs Construction_time()
Tables Material_quality()
no_of_curtains;
Sofa
no_of_bedrooms
Paint_color

➢ Task 4:

Car, Student, tree, mango tree, Patient, Person, BMW, things, Honda, human, City,
Vehicle, non-living things, bike, bicycle,animal, mammal,reptile, horse, amphibian, snake ,
lizard, living things, frog, plants

SOFTWARE REQUIREMENT ENGINEERING

 Page 16 of 33

a. From the above list identify inheritance relationship among the given classes. Hint:
Remember that a super class can be sub class of an other class

a.

Class 1: Plants (Parent class)

Child classes
1.1 mango tree
1.2 tree

Class 2: Vehicle (Parent class)

Child classes
2.1 Car
2.2 BMW
2.3 Honda
2.4 City
2.5 Bicycle
2.6 Bike

Class 3: Human (Parent class)

Child classes
3.1 Patient
3.2 Student
3.3 Person

Class 4: Living things (Parent class)

Child classes
4.1 mammal
4.2 reptile
4.3 horse
4.4 amphibian
4.5 snake
4.6 lizard
4.7 frog
4.8 animals

Class 5: Non-living things (Parent class)

Child classes
5.1 things

SOFTWARE REQUIREMENT ENGINEERING

 Page 17 of 33

LAB NO 06

HOSPITAL MANAGEMENT SYSTEM

CLASS DIAGRAM:

Explanation:
HOSPITAL (parent class):
Attributes Operations
Name Treatment
Address Admit
city Discharge
We have main parent class that is HOSPITAL.
Hospital has an associate and direct associate class that are following:
1. Department
2. Staff
3. Patient (direct association)
4. Ward

Department:
Attributes Operations
department_name no_rooms

SOFTWARE REQUIREMENT ENGINEERING

 Page 18 of 33

add_doctor
assign_rooms

Ward:
Attributes Operations
ward_name register_patient
ward_no patient_care

Ward has its further composition classes that are:

1. Common ward
2. Special ward

• Common ward:

Attributes
no_of_beds
assign_beds

• Special ward:

Attributes
no_of_rooms
payment_per_room

Special ward has its further composite class that is:

Facilities
• Facilities:

Attributes
ac-room
tv
heater
meals

Patient:
Attributes Operations
name payment
age assign_doctor
disease register

Patient has its two aggregate classes that are:

1. New patient
2. Old patient

• New patient:

SOFTWARE REQUIREMENT ENGINEERING

 Page 19 of 33

Attributes
contact

• Old patient:

Attributes
registration_no
check_condition

Staff:
Attributes Operations
name input_info
gender
age

Staff has its further aggregate classes that are:

1. Doctors
2. Nurse

• Doctors:

Attributes Operations
specialization prescription_given
university_name operation
experience test

• Nurse:

Attributes Operations
duty_department drip_insert
id info

LAB NO 07

STUDENT REGISTRATION SYSTEM

Class Diagram:

SOFTWARE REQUIREMENT ENGINEERING

 Page 20 of 33

We have main class STUDENT

Student has an associate class that are:
1. Account
2. Teacher

Account:
Attributes Operations
acc_id create_acc
password

Teacher:
Attributes Operations
name get_info
qualification check_student
course assign_course
gender course_outline
id_no generate_result

Teacher has an aggregate class that is:

1. Teacher_acc

SOFTWARE REQUIREMENT ENGINEERING

 Page 21 of 33

• Teacher_acc:

Attributes Operations
official_email sign_in
data_of_students
course_info

Student’s Aggregate classes:

Student has an aggregate classe that are:
1. Student_acc
2. Graduate
3. Undergraduate

• Student_acc:

Attributes Operations
acc_type show_info
e-mail sign_up

• Graduate:

Attributes Operations
major_program check_info
graduate_gpa select_course
register_student
• Undergraduate:

Attributes Operations
major getinput
inter_marks register

Student’s Composite Classes:

Student has composite classes that are:
1. Course
2. Register Course

• Course:

Attributes Operations
code create_course
name select_course
credit_hrs
instructor
venue

SOFTWARE REQUIREMENT ENGINEERING

 Page 22 of 33

lab

• Register Course:

Attributes Operations
exam_id register
acc_id drop_course
course_code

ONE-TO-ONE RELATIONSHIPS:
Following has one-to-one relationships:
1. Student and Student_acc because one student can have only unique account
2. Teacher and Teacher-acc because one teacher can have only unique account

ONE-TO-MANY RELATIONSHIPS:
Following has one-to-many relationships:
1. Student and Teacher because many students can have many teachers
2. Student and Register Course because many students can register many courses
3. Student and Course because many students can have many courses
4. Course and Register Course because many courses can be registered

SOFTWARE REQUIREMENT ENGINEERING

 Page 23 of 33

LAB NO 08

Task 01:
Generalization:

Order Management System

In this use case diagram, an order registry clerk is an actor that can use all the use cases.
We have the following use cases:
1. Check customer ID
2. Check the order
3. Error message (if product not available)
4. Confirm order (if available)
5. Issue payment slip
6. Send confirmation message
7. Order placed
In this diagram, we have GENERALIZATION relationship between the following:
1. Check the order and error message because error message depends on check the order, it
will give error by checking that product is available or not
2. Check the order and confirm order because it will confirm only if product is available

SOFTWARE REQUIREMENT ENGINEERING

 Page 24 of 33

3. Issue payment slip and confirm order because payment slip depends on confirm order, it
will generate payment slip only when customer confirms an order
4. Send confirmation message and issue payment slip, because it will send confirmation
message when payment is done
5. Send confirmation message and order placed, because once message is received it means
order is placed

Task 02:
Include and Extend Relationships:

Online Flight Booking System

In this use case diagram, passenger is an actor that can access all the use cases. We have the
following use cases:
1. Login
2. Choose place
3. Check availability
4. Select airline
5. Choose class for seat
6. Economy
7. Business
8. Check timings of flight
9. Reserve seat
10. Payment

SOFTWARE REQUIREMENT ENGINEERING

 Page 25 of 33

11. Debit card

12. Account
In this diagram, we have EXTEND relationship between the following:
1. Choose class for seat has an extend relationship with economy and business, it is because
class for seats has its extensions that is economy class and business class that can passenger
choose
2. Payment has an extend relationship with debit card and account, it is because payment
can be done by two extensions or types that is debit card of passenger and bank account of
passenger
In this diagram, we have INCLUDE relationship between the following:
1. Check timings of flight has an include relationship with reserve flight because both have
common feature that if passenger like the timing then he will reserve the flight

Task 03:

Online DVD Buying System

In this use case diagram, we have following actors:
1. Administrator

SOFTWARE REQUIREMENT ENGINEERING

 Page 26 of 33

2. Delivery agent
3. Customer

Administrator:
He can access the following use cases:
1. Add DVD
2. Update inventory

Delivery Agent:
He can access the following use cases:
1. Check order
2. Change status of order

Customer:
He can access the following use cases:
1. Login
2. Search DVD by category
3. Add DVD to cart
4. Check shopping cart
5. Review contents of cart
6. Remove DVD from cart

INCLUDE AND EXTEND RELATIONSHIPS:

1. We have an extend relationship between search DVD by category and games, songs,
films. It is because search DVD by category has its further extensions that customer can choose
2. We have an include relationship between check shopping cart and review contents of cart
3. We have an include relationship between add DVD and update inventory because when
admin add DVD then it will also update the inventory of DVD

SOFTWARE REQUIREMENT ENGINEERING

 Page 27 of 33

LAB NO 09

TASK 01:
Model a computer as a class and a touchpad as its interface. List the
operations of the touchpad. Also, show some of the operations in the computer
that you access via the touchpad.
Solution:

Touchpad is the interface of computer. Human beings interact with the computer via touchpad.
They can give input through touchpad to the computer. Touchpad performs the following
functions such as:
1. Clicking
2. Dragging
3. Pointing
4. Zooming
5. Light up the screen
6. Editing
7. Move the pointer
8. Select text
9. Erase text
10. Replace text
11. Movement (rightwards, backwards, forward and leftwards) etc.
Similarly, the computer performs different functions through touchpad such as:

SOFTWARE REQUIREMENT ENGINEERING

 Page 28 of 33

1. Open document
2. Close document
3. Select files
4. Scrolling
5. Shut down
6. Input etc.

TASK 02:
To attend seminar student has to get registered for the seminar. Only students
having more than 75% marks in last result can be registered for seminar. For
registration student has to submit their mark sheet and certificate of any
seminar attended before with registration form, to maintain record. On the
bases of student history students are selected to attend the seminar. In
seminar there can be maximum 5 instructors. Draw class diagram.
Solution:

In this use case diagram, we have two actors:

1. Student
2. Registrar
Both these actors will involve in the system and can access their specific use cases.
• Student:

SOFTWARE REQUIREMENT ENGINEERING

 Page 29 of 33

Student can access the following use cases:

1. Sign in/sign up
2. Enter name
3. Enter class
4. Enter percentage
5. Attach documents
6. Register

• Registrar:
Registrar can access the following use cases:
1. Enter percentage
2. Attach documents
3. Registration successful
4. Select student
Registrar will check lout the history of student i.e. his/her percentage and valid documents and
then select the student to attend the webinar according to the result and history.

TASK 03:
In a book store a customer can buy book if he has no previous payable dues. A
customer can select book from book list and then can ask salesperson to show
book. Each salesperson gets 10% of total sale he made in a day. When receipt
is created for customer database keep record of salesperson who did this sale
so that at the end of day each salesperson can get his sales-salary.
Solution:

SOFTWARE REQUIREMENT ENGINEERING

 Page 30 of 33

In this use case diagram, we have three main actors:

1. Sales person
2. Customer
3. Database
All of the three actors can access their specific use cases in order to interact with the system.

• Salesperson:
Salesperson can access the following use cases:
1. Show booklist
2. Any payable due?

• Customer:
Customer can access the following use cases:
1. Show booklist
2. Select book

SOFTWARE REQUIREMENT ENGINEERING

 Page 31 of 33

3. Any payable due?

4. Payment method
5. Customer info
6. Bill
7. Buy

• Database:
Database is an actor that will keep the record of every customer who buy the book and at the end
of sale it will give the 10% from the price of every book that will sell out. Database can access
the following use cases:
1. Payment method
2. Customer info
3. Bill

➢ Customer can only buy the book when he has no previous payables
➢ Salesperson will get the 10% from the price of every book that will sell
➢ Database will maintain all the record of every customer and will manage the whole sale
and sales person’s bonus

SOFTWARE REQUIREMENT ENGINEERING

 Page 32 of 33

LAB NO. 10

TASK:
Make a class diagram of online shopping store and make a shopping for you
favorite shoes.
Your diagram must include all steps of shopping from site access to successful
order.
ONLINE SHOPPING STORE
CLASS DIAGRAM:

• Web user can login to the online shopping app through his id or email. If he has
no account then he can make it on the app. After login, he will verify and check the
products which he wants to buy. After selecting the product, he will order it through
his account.
• Account owns customer orders. Customer may have no orders. Customer
orders are sorted and unique. Each order could refer to several payments. Every
payment has unique id and is related to exactly one account.

SOFTWARE REQUIREMENT ENGINEERING

 Page 33 of 33

• User will get notification when his ordered is confirmed.

• After all the above process, user will get the order state about the product that
he has ordered i.e., shipped, delivered or closed.

THE END

SOFTWARE REQUIREMENT ENGINEERING