EXCERCISE NO.

10

Aim: Understanding an SRS.

Theory:

An SRS is basically an organization's understanding (in writing) of a customer or

potential client's system requirements and dependencies at a particular point in time
(usually) prior to any actual design or development work. It's a two-way insurance policy
that assures that both the client and the organization understand the other's requirements
from that perspective at a given point in time.

The SRS document itself states in precise and explicit language those functions and
capabilities a software system (i.e., a software application, an eCommerce Web site, and
so on) must provide, as well as states any required constraints by which the system must
abide. The SRS also functions as a blueprint for completing a project with as little cost
growth as possible. The SRS is often referred to as the "parent" document because all
subsequent project management documents, such as design specifications, statements of
work, software architecture specifications, testing and validation plans, and
documentation plans, are related to it.

It's important to note that an SRS contains functional and nonfunctional requirements
only; it doesn't offer design suggestions, possible solutions to technology or business
issues, or any other information other than what the development team understands the
customer's system requirements to be.

A well-designed, well-written SRS accomplishes four major goals:

• It provides feedback to the customer. An SRS is the customer's assurance that

the development organization understands the issues or problems to be solved
and the software behavior necessary to address those problems. Therefore, the
SRS should bewritten in natural language (versus a formal language, explained
later in this article), in an unambiguous manner that may also include charts,
tables, data flow diagrams, decision tables, and so on.
• It decomposes the problem into component parts. The simple act of writing
down software requirements in a well-designed format organizes information,
places borders around the problem, solidifies ideas, and helps break down the
problem into its component parts in an orderly fashion.
• It serves as an input to the design specification. As mentioned previously, the
SRS serves as the parent document to subsequent documents, such as the
software design specification and statement of work. Therefore, the SRS must
contain sufficient detail in the functional system requirements so that a design
solution can be devised.
 • It serves as a product validation check. The SRS also serves as the parent
document for testing and validation strategies that will be applied to the
requirements for verification.
• SRSs are typically developed during the first stages of "Requirements
Development," which is the initial product development phase in which information
is gathered about what requirements are needed--and not. This information-gathering
stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a
return-on-investment (ROI) analysis or needs analysis of the customer or client's
current business environment. The actual specification, then, is written after the
requirements have been gathered and analyzed.

SRS should address the following

The basic issues that the SRS shall address are the following:

• Functionality. What is the software supposed to do?

• External interfaces. How does the software interact with people, the
system’s hardware, other hardware, and other software?
• Performance. What is the speed, availability, response time, recovery time of
various software functions, etc.?
• Attributes. What are the portability, correctness, maintainability,
security, etc. considerations?
• Design constraints imposed on an implementation. Are there any required
standards in effect, implementation language, policies for database integrity,
resource limits, operating environment(s) etc.?

Characteristics of a good SRS

Correct - This is like motherhood and apple pie. Of course you want the specification to
be correct. No one writes a specification that they know is incorrect. We like to say -
"Correct and Ever Correcting." The discipline is keeping the specification up to date when
you find things that are not correct.

Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein
has only one interpretation. Again, easier said than done. Spending time on this area prior
to releasing the SRS can be a waste of time. But as you find ambiguities - fix them.

Complete - A simple judge of this is that is should be all that is needed by the software
designers to create the software.

Consistent - The SRS should be consistent within itself and consistent to its reference
documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in
another.
 Ranked for Importance - Very often a new system has requirements that are really
marketing wish lists. Some may not be achievable. It is useful provide this information in the
SRS.

Verifiable - Don't put in requirements like - "It should provide the user a fast response."
Another of my favorites is - "The system should never crash." Instead, provide a
quantitative requirement like: "Every key stroke should provide a user response within
100 milliseconds."

Modifiable - Having the same requirement in more than one place may not be wrong -
but tends to make the document not maintainable.

Traceable - Often, this is not important in a non-politicized environment. However, in

most organizations, it is sometimes useful to connect the requirements in the SRS to a
higher level document. Why do we need this requirement?

Functional Requirements for an ATM System

The ATM system is designed to provide users with easy access to their bank accounts for performing various
financial transactions. Below are the detailed functional requirements for the ATM system.

1. User Authentication

• Card Reading:
• The system shall prompt users to insert their ATM/debit card into the card reader.
• The system shall read data from the card, such as account number and card details, for
authentication.
• PIN Verification:
• The system shall prompt users to enter their Personal Identification Number (PIN).
• The system shall validate the entered PIN against the user’s registered PIN stored in the bank’s
database.
• Multi-Factor Authentication (optional):
• The system may optionally support additional security measures, such as OTP (One Time
Password) sent via SMS for higher security during transactions.

2. Cash Withdrawal

• Account Verification:
• The system shall verify that the user has sufficient funds before allowing any withdrawal.
• Denomination Selection:
• The system shall allow users to choose from available withdrawal amounts (e.g., 500, 1000, 2000
INR).
 • The system shall allow users to specify custom amounts (in multiples of the available
denomination).
• Transaction Processing:
• The system shall debit the user’s account by the requested amount upon successful withdrawal.
• Cash Dispensing:
• The system shall physically dispense the requested amount in cash after transaction approval.

3. Balance Inquiry

• Account Summary:
• The system shall allow users to check the available balance in their account after authentication.
• The system shall display the balance on the ATM screen and provide an option to print a receipt.
• Mini Statement:
• The system shall provide an option to view a mini statement, listing recent transactions (e.g., last
10 transactions).
• The system shall allow users to print the mini statement if desired.

4. Funds Transfer

• Account Selection:
• The system shall allow users to transfer funds between their own accounts or to other accounts
within the same bank.
• Verification:
• The system shall validate the destination account and ensure that the source account has sufficient
balance.
• Transfer Limits:
• The system shall impose daily transfer limits based on user account settings (as specified by the
bank).

5. Account Settings Management

• PIN Change:
• The system shall allow users to change their ATM PIN by authenticating with their old PIN first.
• Personal Information Update:
• The system shall allow users to update personal information such as phone numbers or email
addresses (with bank approval).

6. Transaction Receipt

• Receipt Printing:
• The system shall print a transaction receipt after every successful transaction (withdrawal, balance
inquiry, funds transfer).
• The receipt shall include details such as transaction type, date, time, and amount.
• Digital Receipts (optional):
• The system may offer an option to send digital receipts via email or SMS.
 7. Error Handling and Alerts

• Card Retention:
• The system shall retain the ATM card if the user enters an incorrect PIN more than three times.
• Out of Service:
• The system shall display appropriate error messages, such as "Out of Service" when the ATM is
not functioning or "Insufficient Funds" for failed transactions.
• Cash Shortage Alert:
• The system shall notify users if the ATM does not have sufficient cash for a requested withdrawal.

8. Session Management

• Timeout:
• The system shall automatically end the session after 30 seconds of inactivity to prevent
unauthorized access.
• Logout:
• The system shall ensure the user is logged out after completing a transaction or if the user
manually selects to log out.

Software Requirements for ATM System

• Operating System: Windows, Linux-based OS suitable for ATM hardware.

• Programming Languages: C, C++, Java, Python, HTML, JavaScript.
• Database: MS SQL Server, MySQL, or any RDBMS for storing account data.
• Network Protocols: SSL/TLS for secure data transmission between the ATM and bank’s servers.
• Development Tools: Integrated Development Environment (IDE), compilers, and debuggers.

Hardware Requirements for ATM System

• Processor: Intel Core i3 or higher for efficient processing of transactions and data.
• Memory (RAM): 4 GB or more for fast data processing and to accommodate the software system's
multitasking needs.
• Storage (Hard Disk): 40 GB or higher for data storage (logs, transactions, software updates).
• Card Reader: Magnetic and chip reader for ATM/debit card processing.
• Cash Dispenser: Mechanism for securely dispensing cash.
• Touchscreen: User interface for input and interaction.
• Receipt Printer: For printing transaction receipts.

Non-Functional Requirements for ATM System

Usability Requirements

• Simple Interface:
• The ATM interface should be simple, intuitive, and support multiple languages for diverse users.
• The system should use large buttons and clear text to accommodate visually impaired users.

Security Requirements
 • Secure Database:
• The database should be encrypted to prevent unauthorized access.
• The system should use encryption (AES or RSA) to securely transmit sensitive information such
as PINs.
• Access Control:
• Different access levels should be defined for users, administrators, and technicians.
• Admin users should have the ability to configure the system and access advanced features.
• Anti-Tampering:
• The system should include hardware and software-based anti-tampering measures to protect user
data and prevent fraud.

Performance Requirements

• Transaction Speed:
• Transactions should be processed within 5 seconds (excluding network delays).
• System Availability:
• The system should be available 24/7 with minimal downtime (scheduled maintenance).

Error Requirements

• Error Handling:
• The system should handle expected errors (e.g., card errors, network issues) gracefully and
provide appropriate feedback to the user.
• Data Integrity:
• The system should ensure that transaction data is not lost or corrupted during processing.

Coding or Implementation of ATM System

During the implementation phase, developers will begin coding the ATM system using the selected
programming languages and frameworks. They will follow the defined design protocols and security standards
to ensure a robust, secure, and efficient system. Development tools such as compilers, interpreters, and
debuggers will be used for the coding process.
(B) Hospital Management System SRS :

Functional Requirements

Functional requirements for a Hospital Management System (HMS) typically include a wide range of features
and capabilities to ensure efficient operations and effective patient care. Here are some common functional
requirements for an HMS:

1.Patient Management:
•Registration: Ability to register new patients, including capturing personal and medical information.
•Appointment Scheduling: Allow patients to schedule appointments with doctors or departments.
•Admission/Discharge: Manage the admission and discharge process for patients.
2.Staff Management:
•User Authentication: Secure login for staff members with different access levels (admin, doctors, nurses,
etc.).
•Staff Roster: Manage staff schedules, including doctors, nurses, and administrative personnel.
3.Medical Records Management:
•Electronic Health Records (EHR): Store and manage patient medical history, diagnoses, treatments, and
test results.
•Medical Imaging: Integration with systems for storing and viewing medical images such as X-rays, MRIs,
and CT scans.
4.Billing and Insurance:
•Billing: Generate bills for services rendered, including consultation fees, procedures, medications, and
room charges.
•Insurance Claims: Manage insurance information and submit claims to insurance providers.
5.Pharmacy Management:
•Medicine Inventory: Track medication stock levels and manage inventory.
•Prescription Management: Record prescriptions, dispense medications, and manage refill requests.
6.Laboratory Management:
•Test Orders: Accept requests for laboratory tests from doctors.
•Test Results: Record and provide access to test results for medical staff.
Software Requirements:
 •Operating System: Windows 7, 8, 9, 10 .
•Language: Html , Css , Javascript , Php , sql
•Database: MS SQL Server (back end)
Hardware Requirements:

•Processor: Intel core i3 or above for a stable experience and fast retrieval of data.
•Hard Disk: 40GB and above
•RAM: 256 MB or more, recommended 2 GB for fast reading and writing capabilities which will result in
better performance time.

Non Functional Requirements

Usability Requirements:

•Our user interface should be interactive simple and easy to understand . The system should prompt for the
user and administrator to login to the application for proper input criteria.
•Hospital Management System shall handle expected and non – expected errors in ways that prevent loss in
information and long downtime period.
Security Requirements:

•System should use secured Database.

•Normal users can just read information but they cannot edit or modify anything except their personal and
some other information.
•System will have different types of users and every user has access constraints.
•Proper user authentication should be provided.
•No one should be able to hack users password .
•There should be separate accounts for admin and members such that no member can access the database and
only admin has the rights to update the database.
Performance Requirements:

•The system shall accommodate high number of booking and users without any fault.
•Responses to view information shall take no longer than 5 seconds to appear on the screen.
Error Requirements:

HMS product shall handle expected and non-expected errors in ways that prevent loss in information and long
downtime period.
Coding or Implementation of Hospital Mangement System

At this stage, the fundamental development of the product starts. For this, developers use a specific
programming code as per the design. Hence, it is important for the coders to follow the protocols set by the
association. Conventional programming tools like compilers, interpreters, debuggers, etc. are also put into use at
this stage.