Lab Experiment No.

2
Develop requirements specification for a given problem
Objective:
To find the requirement specification (both functional and nonfunctional) of a ATM
MANAGEMENT SYSTEM
Introduction
Purpose
The purpose of this document is to specify the requirements of the ATM management system, outlining
its functionality, performance, and constraints.
Scope
The ATM management system will provide services for users to perform financial transactions, including
withdrawals, deposits, balance inquiries, and fund transfers.

Overall Description

Product Perspective
The ATM system will interface with the bank's core banking system to process transactions and update
account balances. It will also include a user interface for customers to interact with.
Product Features
- User authentication: Users must authenticate themselves via PIN or biometric verification.
- Transaction processing: The system should support cash withdrawals, deposits, balance inquiries, and
fund transfers.
- Cash management: The ATM should manage cash levels, including refills and withdrawals, to ensure
availability.
- Security: The system should implement security measures to protect user data and prevent unauthorized
access.
- User interface: The ATM should provide an intuitive user interface for easy interaction.
Functional Requirements

User Authentication
- The system shall require users to input a valid PIN or provide biometric authentication.
- The system shall lock the user's account after three consecutive failed login attempts.
Transaction Processing
- The system shall support cash withdrawals in denominations of $20, $50, and $100.
- The system shall allow deposits of cash and checks, with real-time validation.
- The system shall provide balance inquiries for checking and savings accounts.
- The system shall support fund transfers between linked accounts.
Cash Management
- The system shall monitor cash levels and request refills when necessary.
- The system shall dispense cash based on available denominations and user preferences.
Security
- The system shall encrypt user data during transmission and storage.
- The system shall implement access controls to restrict unauthorized access to sensitive functions.
- The system shall log all transactions and security events for auditing purposes.
User Interface
- The system shall provide a touchscreen interface with clear instructions for users.
- The system shall display transaction summaries and receipts for user confirmation.

Non-functional Requirements

Performance
- The system shall process transactions within 30 seconds.
- The system shall be available for use 99.9% of the time.
Reliability
- The system shall have a mean time between failures (MTBF) of at least 10,000 hours.
Usability
- The system shall comply with accessibility standards for users with disabilities.
- The system shall provide multilingual support for user interfaces.
External Interface Requirements

User Interfaces
- The system shall include a touchscreen interface with options for different languages.
- The system shall provide audio feedback for visually impaired users.
Hardware Interfaces
- The system shall interface with cash dispensers, receipt printers, and card readers.
Software Interfaces
- The system shall integrate with the bank's core banking system via APIs for transaction processing.
Other Requirements

Regulatory Requirements
- The system shall comply with relevant banking regulations and security standards.
Documentation Requirements
- The system shall include user manuals and technical documentation for maintenance and troubleshooting.

Lab Experiment No.3

 LIBRARY MANAGEMENT SYSTEM

Objective:
To find the requirement specification (both functional and nonfunctional) of a LIBRARY
MANAGEMENT SYSTEM

Introduction

Purpose
The purpose of this document is to define the requirements of the Library Management System (LMS) to
facilitate efficient management of library resources, including books, users, and transactions.
Scope
The LMS will provide functionality for library staff to manage the library catalog, handle user registrations,
loan and return books, generate reports, and maintain system security.

Overall Description

Product Perspective

The LMS will be a standalone system integrated with a database to store and retrieve information about
books, users, transactions, and system settings.
Product Features
- Book Management: Add, edit, and delete books from the library catalog, including metadata such as title,
author, ISBN, and genre.
- User Management: Register, update, and delete user accounts, including personal information and
borrowing privileges.
- Loan Management: Handle book loans, renewals, and returns, with due date management and fine
calculation.
- Reporting: Generate reports on book availability, user activity, overdue books, and system usage statistics.
- Security: Implement user authentication, access control, and data encryption to protect sensitive
information.
Functional Requirements

Book Management
- The system shall allow librarians to add new books to the catalog, including title, author, ISBN, genre, and
quantity.
- The system shall support editing and deleting book records while preserving transaction history.
- The system shall provide search and filter functionalities for users to find books by title, author, or genre.

User Management
- The system shall allow librarians to register new users, including personal information and contact details.
- The system shall support updating user profiles and deleting user accounts, with proper data validation.
- The system shall assign borrowing privileges to users based on predefined rules (e.g., maximum loan
limit, borrowing duration).

Loan Management
- The system shall allow librarians to check out books to users, recording loan details such as due date and
borrower information.
- The system shall support renewing book loans, with restrictions on the number of renewals and overdue
fines.
- The system shall handle book returns, updating inventory status and calculating fines for overdue books.
Reporting
- The system shall generate reports on book availability, including total copies, available copies, and on-
loan copies.
- The system shall provide reports on user activity, including borrowing history, fines, and outstanding
loans.
- The system shall generate overdue book reports and notify librarians and users of overdue items.

Security
- The system shall require librarians to authenticate themselves with a username and password.
- The system shall implement role-based access control, distinguishing between librarian and administrator
roles.
- The system shall encrypt sensitive user data, such as passwords and personal information, during
transmission and storage.
Non-functional Requirements

Performance
- The system shall respond to user queries and transactions within 3 seconds under normal load conditions.
- The system shall be capable of handling concurrent users, with a minimum capacity of 100 simultaneous
connections.

Reliability
- The system shall have a mean time between failures (MTBF) of at least 1000 hours.
- The system shall automatically back up data daily to prevent data loss in case of system failure.

Usability
- The system shall provide an intuitive user interface with clear navigation and descriptive error messages.
- The system shall support multiple languages to accommodate users from diverse backgrounds.
External Interface Requirements

User Interfaces
- The system shall include a web-based interface accessible via standard web browsers.
- The system shall provide a mobile-friendly interface for users to access library services on smart phones
and tablets.

Hardware Interfaces
- The system shall be compatible with common hardware components such as barcode scanners and receipt
printers.

Software Interfaces
- The system shall integrate with external databases for book metadata and user authentication.

Other Requirements
Regulatory Requirements
- The system shall comply with data protection regulations, such as GDPR, regarding the handling of user
data.

Documentation Requirements
- The system shall include user manuals for librarians and administrators, as well as technical
documentation for maintenance and troubleshooting.

Experiment No. 4
 AIM OF THE EXPERIMENT:
Develop DFD model (level-0, level-1 DFD and Data dictionary) of the project.

OVERALL DESCRIPTION :

Data analysis attempts to answer four specific questions:

 What processes make up a system?

 What data are used in each process?

 What data are stored?

 What data enter and leave the system?

Data drive business activities and can trigger events (e.g. new sales order data) or be processed to
provide information about the activity. Data flow analysis, as the name suggests, follows the flow
of data through business processes and determines how organisation objectives are accomplished.

Physical and Logical DFDs

There are two types of data flow diagrams, namely physical data flow diagrams and logical data
flow diagrams and it is important to distinguish clearly between the two:

Physical Data Flow Diagrams

An implementation-dependent view of the current system, showing what tasks are carried
out and how they are performed. Physical characteristics can include:

Names of people

Form and document names or numbers

Master and transaction files

Equipment and devices used

Logical Data Flow Diagrams

An implementation-independent view of the a system, focusing on the flow of data between

processes without regard for the specific devices, storage locations or people in the system. The
physical characteristics listed above for physical data flow diagrams will not be specified.
 ORDERS

CUSTOMERS

INVOICES

Fig. A typical DFD

Data Flow Diagram (DFD)

The DFD (also known as a bubble chart) is a hierarchical graphical model of a system that shows
the different processing activities or functions that the system performs and the data interchange among
these functions. Each function is considered as a processing station (or process) that consumes some input
data and produces some output data. The system is represented in terms of the input data to the system,
various processing carried out on these data, and the output data generated by the system. A DFD model
uses a very limited number of primitive symbols [as shown in fig. 5.1(a)] to represent the functions
performed by a system and the data flow among these functions.

Importance of DFDs in a good software design

The main reason why the DFD technique is so popular is probably because of the fact
that DFD is a very simple formalism – it is simple to understand and use. Starting with a set of
high-level functions that a system performs, a DFD model hierarchically represents various sub-
functions. In fact, any hierarchical model is simple to understand. Human mind is such that it can
easily understand any hierarchical model of a system – because in a hierarchical model, starting
with a very simple and abstract model of a system, different details of the system are slowly
introduced through different hierarchies..

Data dictionary
A data dictionary lists all data items appearing in the DFD model of a system. The data
items listed include all data flows and the contents of all data stores appearing on the
DFDs in the DFD model of a system. A data dictionary lists the purpose of all data items
and the definition of all composite data items in terms of their component data items. For
example, a data dictionary entry may represent that the data grossPay consists of the
components regularPay and overtimePay.
 Lab Experiment No.5

Develop Structured design for the DFD model developed.

A DFD model of a system graphically depicts the transformation of the data input to the
system to the final result through a hierarchy of levels. A DFD starts with the most
abstract definition of the system (lowest level) and at each higher level
DFD, more details are successively introduced. To develop a higher-level DFD model,
processes are decomposed input data to these functions and the data output by these
functions and represent them appropriately in the diagram.

Decomposition:-
Each bubble in the DFD represents a function performed by the system. The bubbles are
decomposed into sub-functions at the successive levels of the DFD.

Example:-
A supermarket needs to develop the following software to encourage regular customers. For this,
the customer needs to supply his/her residence address, telephone number, and the driving license
number. Each customer who registers for this scheme is assigned a unique customer number (CN)
by the computer. A customer can present his CN to the check out staff when he makes any
purchase. In this case, the value of his purchase is credited against his CN. At the end of each year,
the supermarket intends to award surprise gifts to 10 customers who make the highest total
purchase over the year. Also, it intends to award a 22 caret gold coin to every customer whose
purchase exceeded Rs.10,000. The entries against the CN are the reset on the day of every
year after the prize winners’ lists are generated.