Index

S. Objective Page Date Sign.

No. No.

1. Prepare a SRS document in line with the

IEEE recommended standards.

2. Draw the use case diagram and specify the

role of each of the actors. Also state the
precondition, post condition and function of
each use case.

3. Draw the activity diagram.

4. Identify the classes. Classify them as weak

and strong classes and draw the class
diagram.

6. Draw the sequence diagram for any two

scenarios.
 Objective: Prepare a SRS document in line with the IEEE recommended
standards.

Introduction
The software ATMS is to be developed for Automated Teller Machines (ATM). An ATM is
computerized telecommunications device that provides a financial institution’s customers a secure
method of performing financial transactions, in a public space without the need for a human bank
teller. Through ATMS, customers interact with a user-friendly interface that enables them to access
their bank accounts and perform various transactions.
Purpose
This SRS defines External Interface, Performance and Software System Attributes requirements
of ATMS. This document is intended for the customer and developer (designer, tester and
maintainers). The reader is assumed to have a basic knowledge of banking accounts and accounts
services.
Document Conventions
 Account: An account at a bank against which a transaction can be applied. User get a
unique account number after the registration. User can use this account number for login
to the ATMS.
 PIN (Personal Identification Number): Is a 4-digit number that created by the user during
registration. At the time of login PIN can be used to authenticate the user to the ATMS.
 Password: At the time of registration the user has to create a password so that he can use
that for changing his PIN later.
Scope
The software supports a computerized banking system. The system enables customers to complete
simple bank account service via an ATM. An ATM session consists of authenticating a user (i.e.
proving the user’s identity) based on an account number and personal identification number (PIN),
followed by creating and executing financial transactions. To authenticate a user and perform
transactions, the ATM must interact with the bank’s account information database. For each bank
account, the database stores an account number, customer’s name, date-of-birth, mobile number,
PIN, a balance indicating the amount of money in the account and a password for changing the
PIN. ATM users should be able to view their account balance, withdraw cash (i.e. take money out
of an account) and deposit funds (i.e. place money into an account).

Overall Description
Product Perspective
This ATM’s software is to run on a new ATM hardware that a local bank wants to install for its
customers. This product will be developed from an existing system of the same local bank or from
another bank that has similar characteristics of this local bank. The system will be designed in such
a way that the user will access and use the ATM and then accesses the banking system, which
updates, configures and accesses the details and data of the user from his/her database. The system
will also accommodate an operator who will load money in the ATM machine, validate deposits
made by a customer, and make sure the system hardware is always on and on power.
Product Functions
The functions of the system are:
 Registration: This is used to register new user by creating a bank account.
 Login: This is used to verify the authentication of the user. The user types their allotted
account number and pin as input. The system then verifies whether their account number
and pin stored on the data base matches or not, if it matches then it allows the user to use
the system or else it asks the user to try again.
 View Balance: This use case is used to check the account balance. After every transaction
the balance in the user’s account is updated.
 Withdraw Cash: This use case facilitates the user to withdraw balance. After every
transaction the balance in the user’s account is updated.
 Deposit Money: This use case is used to execute the deposit transaction by the user.
 Logout: This enables the user to logout from the system.
 Change PIN: This enables the user to change or update their PIN.
 Exit: This enables the user to exit from the system and to enable a new user to access the
system.

External Interface Requirements

User Interfaces
Upon first approaching the ATM, the user should experience the following sequence of events:
1. The screen displays a welcome screen with login option.

2. The login option prompts the user to enter an account number. The user enters an account
number, using the keypad.
3. The screen prompts the user to enter the PIN associated with the specified account number.
The user enters a 4-digit PIN, using the keypad.
 4. If the user enters a valid account number and the correct PIN for that account, the screen
displays main menu.

5. If the user enters 2 to make a withdrawal the screen displays the menu in figure below.

Hardware Interfaces
 A screen that displays messages to the user.
 A keypad that receives numeric input from the user.
 A cash dispenser that dispenses cash to the user.
 A deposit slot that receives deposit envelopes from the user.
Software Interfaces
Software requirements at the end user are:
1. Operating Systems
 Windows 7, 10 or Linux etc.
 2. Languages supported
 Java or C++
3. Database
 File Handling

System Features
 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.
 At any moment if the user wants to abort the transaction, he is provided with an option to
cancel it.
 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.
 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
 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.
 Objective: Draw the use case diagram and specify the role of each of the
actors. Also state the precondition, post condition and function of each use
case.

A use case diagram is a diagram that shows the relationships among actors and use cases within a
system.
Use case diagrams are often used to:
 Provide an overview of all or part of the usage requirements for a system or organization
in the form of an essential model or a business model.
 Communicate the scope of a development project.
 Model your analysis of your usage requirements in the form of a system use case model.
Use case models should be developed from the point of view of your project stakeholders and not
from the (often technical) point of view of developers.
There are guidelines for:

Use Cases
A use case describes a sequence of actions that provide a measurable value to an actor. A use case
is drawn as a horizontal ellipse on a UML use case diagram.
1. Use case names begin with a strong verb.
2. Name use cases using domain terminology.
3. Place your primary use cases in the top-left corner of the diagram.
4. Imply timing considerations by stacking use cases.

Actors
An actor is a person, organization, or external system that plays a role in one or more interactions
with your system (actors are typically drawn as stick figures on UML use case diagrams).
1. Place your primary actors in the top-left corner of the diagram.
2. Draw actors to the outside of a use case diagram.
3. Name actors with singular, business-relevant nouns.
4. Associate each actor with one or more use cases.
5. Actors model roles, not positions.
6. Use <<system>> to indicate system actors.
7. Actors don’t interact with one another.
8. Introduce an actor called “Time” to initiate scheduled events.

Relationships
There are several types of relationships that may appear on a use case diagram:
  An association between an actor and a use case.
 An association between two use cases.
 A generalization between two actors.
 A generalization between two use cases.
Associations are depicted as lines connecting two modelling elements with an optional open-
headed arrowhead on one end of the line indicating the direction of the initial invocation of the
relationship. Generalizations are depicted as a close-headed arrow with the arrow pointing towards
the more general modelling element.
1. Indicate an association between actor and use case if the actor appears within the use case
logic.
2. Avoid arrowheads on actor-use case relationships.
3. Apply <<include>> when you know exactly when to invoke the use case.
4. Apply <<extend>> when a use case may be invoked across several use case steps.
5. Introduce <<extend>> associations sparingly.
6. Generalize use cases when a single condition results in significantly new business logic.
7. Do not apply <<uses>>, <<includes>>, or <<extends>>
8. Avoid more than two levels of use case associations.
9. Place an included use case to the right of the invoking use case.
10. Place an extending use case below the parent use case.
11. Apply the “Is Like” rule to use case generalization.
12. Place an inheriting use case below the base use case.
13. Apply the “Is Like” rule to actor inheritance.
14. Place an inheriting actor below the parent actor.

System Boundary Boxes

The rectangle around the use cases is called the system boundary box and as the name suggests it
indicates the scope of your system – the use cases inside the rectangle represent the functionality
that you intend to implement.
1. Indicate release scope with a system boundary box.
2. Avoid meaningless system boundary boxes.
Use Case Diagram for ATM System

Use Cases Function Pre-condition Post-condition

Registration To register a new None None
user into the system.
Login To authenticate a User Must have an The user logged out from
registered user. account in bank and a the system.
PIN to authenticate.
Change PIN To change or update User must have his User PIN must be updated
the PIN account number and in the database.
password of his account.
View To view account User must have to login None
Balance balance. and authenticate first.
Withdraw To withdraw cash. User must have to login User balance must be
and authenticate first. updated in the database.
Deposit To deposit money. User must have to login User balance must be
and authenticate first. updated in the database.
 Objective: Draw the activity diagram.

Activity Diagram
Activity diagram is basically a flow chart to represent the flow from one activity to another activity.
The activity can be described as an operation of the system. This flow can be sequential, branched
or concurrent. The activity diagram is sometimes considered as the flowchart. Although the
diagrams look like a flowchart, they are not.

Purpose
Activity diagrams are not only used for visualizing dynamic nature of a system but they are also
used to construct the executable system by using forward and reverse engineering techniques. It
does not show any message flow from one activity to another.

Component of Activity Diagram

1. Initial node: The black filled circle is the starting point of the diagram.
2. Final node: The black filled circle with a border is the ending point. It looks like a selected
radio button. An activity diagram can have zero or more activity final state.
3. Action/Activity: The rounded rectangle represents activities that occur. It usually has a
short description of the activity they represent. An activity is not necessarily a program; it
may be a manual thing also.
4. Control Flow: A solid line with an arrow represent the direction flow of the activities. The
arrow points in the direction of progressing activities.
5. Fork: A black bar (horizontal/vertical) with one flow going into it and several leaving it.
This denotes the beginning of parallel activities.
 6. Join: A block bar with several flows entering it and one leaving it, this denotes the end of
parallel activities.
7. Merge: A diamond with several flows entering and one leaving. The implication is that all
incoming flow to reach this point until processing continues.
8. Decision: A diamond with one flow entering and two paths leaving. The flow leaving
includes conditions as yes/no state.
9. Flow final: The circle with X through it. This indicates that process stop at this point.
10. Accept Event Action: Accept Event Action is an action that waits for the occurrence of
an event meeting specified condition.
11. Send Signal Action: Send signal action is an action that creates a signal instance from its
inputs, and transmits it to the target object, where it may cause the firing of a state machine
transition or the execution of an activity.
12. Swim lanes: A partition in activity diagram called swim lane, which are used to represent
or group actions carried out by different actors in a single thread. This swim lane may be
horizontal or vertical.

How to draw activity diagram?

To draw an activity diagram, follow these steps:

1. Identify the actors and their roles in the system or process.

2. Identify the activities or actions that need to be modelled.
3. Identify the start and end points of the activity diagram.
4. Create a swim lane for each actor or role involved in the process.
5. Draw the initial activity node, which represents the start of the process.
6. Draw the various activity nodes to represent the activities or actions involved in the
process. These can be represented as rectangles.
7. Connect the activity nodes with arrows to indicate the flow of activities or actions. Use
control flow arrows to indicate the logical order of activities or actions.
8. Use decision nodes (diamonds) to indicate branching or decision points in the process.
9. Use merge nodes (diamonds with multiple incoming arrows) to indicate points where
multiple paths converge.
10. Add annotations and notes to the diagram as needed to clarify any ambiguities or provide
additional information.

Guidelines for activity diagrams

Guidelines for activity diagrams:

1. Identify the scope and purpose of the diagram: Before starting to draw the diagram, it's
important to understand the purpose it serves and what part of the system or process it will
represent.
2. Use appropriate symbols: Activity diagrams use various symbols to represent actions,
decisions, start and end points, and other elements. It's important to use the appropriate
symbol for each element to convey the correct meaning.
3. Keep it simple: Activity diagrams should be easy to understand and follow. Avoid using
too many symbols or creating overly complex diagrams that could confuse the reader.
4. Use meaningful labels: Labels for each element in the diagram should be clear and
descriptive. This will help the reader understand the flow of activities and actions more
easily.
5. Follow a consistent flow: The flow of the activities and actions should be consistent and
logical. Avoid creating loops or branching paths that could be confusing to follow.
6. Validate the diagram: Once you have created the diagram, validate it to ensure that it
accurately represents the system or process it is intended to model. Check for errors,
inconsistencies, and ambiguities.
Activity Diagram for ATM Withdrawal Activity
 Objective: Identify the classes. Classify them as weak and strong classes and
draw the class diagram.

Class Diagram
In software engineering, a class diagram in the Unified Modelling Language (UML) is a type of
static structure diagram that describes the structure of a system by showing the system's classes,
their attributes, operations (or methods), and the relationships among objects.
The main purpose of class diagrams is to build a static view of an application. It is the only diagram
that is widely used for construction, and it can be mapped with object-oriented languages.
Following are the purpose of class diagrams given below:
1. It analyses and designs a static view of an application.
2. It describes the major responsibilities of a system.
3. It is a base for component and deployment diagrams.
4. It incorporates forward and reverse engineering.

Basic Class Diagram Symbols and Notations

Classes
Classes represent an abstraction of entities with common characteristics. Associations represent
the relationships between classes.
 Illustrate classes with rectangles divided into compartments.
 Place the name of the class in the first partition (cantered, bolded, and capitalized).
 List the attributes in the second partition (left-aligned, not bolded, and lowercase).
 And write operations into the third.
 Responsibility is a contract which the class must conform.
 Static attributes or operations should be underlined.
Active Classes
Active classes initiate and control the flow of activity, while passive classes store data and serve
other classes. Illustrate active classes with a thicker border.

Visibility
Use visibility markers to signify who can access the information contained within a class.

 Private visibility, denoted with a - sign, hides information from anything outside the class
partition.
 Public visibility, denoted with a + sign, allows all other classes to view the marked
information.
 Protected visibility, denoted with a # sign, allows child classes to access information they
inherited from a parent class

Associations
Associations represent static relationships between classes.
 Place association names above, on, or below the association line.
 Use a filled arrow to indicate the direction of the relationship.
 Place roles near the end of an association. Roles represent the way the two classes see each
other.
Dependency:
Exists between two classes if the changes to the definition of one may cause changes to the other
(but not the other way around).

Multiplicity (Cardinality)
Place multiplicity notations near the ends of an association. These symbols indicate the number of
instances of one class linked to one instance of the other class. For example, one company will
have one or more employees, but each employee works for just one company.
Composition and Aggregation
Composition is a special type of aggregation that denotes a strong ownership between Class A,
the whole, and Class B, its part. It portrays the dependency between the parent and its child, which
means if one part is deleted, then the other part also gets discarded. Illustrate composition with a
filled diamond.

An aggregation is a subset of association, which represents has a relationship. It is more specific

then association. It defines a part-whole or part-of relationship. In this kind of relationship, the
child class can exist independently of its parent class. Use a hollow diamond to represent a simple
aggregation relationship, in which the "whole" class plays a more important role than the "part"
class, but the two classes are not dependent on each other.

The diamond ends in both composition and aggregation relationships point toward the "whole"
class (i.e., the aggregation).

Generalization
Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship
between two classes where one class is a specialized version of another. For example, Honda is a
type of car. So the class Honda would have a generalization relationship with the class car.
How to draw a Class Diagram?
To draw a class diagram, follow these steps:

1. Identify the classes: Identify the classes that are involved in the system. Each class should
have a unique name that reflects its responsibilities in the system.
2. Identify the attributes: For each class, identify its attributes, which are the data fields that
define the properties of the class. Attributes can be private, public, or protected.
3. Identify the methods: For each class, identify its methods, which are the operations or
functions that can be performed on the class. Methods can be public, private, or protected.
4. Identify the relationships: Identify the relationships between the classes. Relationships
can be association, inheritance, aggregation, or composition.
5. Draw the class diagram: Using a UML class diagram editor, draw the classes and their
attributes and methods. Connect the classes with the relationships using the appropriate
symbols.
6. Add additional information: Add any additional information that is relevant to the
system, such as interfaces, packages, or stereotypes.
7. Validate the class diagram: Review the class diagram to ensure that it accurately reflects
the system's structure and behaviour. Make any necessary adjustments.
 Objective: Draw the sequence diagram for any two scenarios.

Sequence Diagram is an interaction diagram that details how operations are carried out, what
messages are sent and when. Sequence diagrams are organized according to time. The time
progresses as you go down the page. The objects involved in the operation are listed from left to
right according to when they take part in the message sequence.

Components of a Sequence Diagram

Actor:
Anyone who is going to use our system is actor.

Lifeline
An individual participant in the sequence diagram is represented by a lifeline. It is positioned at
the top of the diagram.

Activations
A thin rectangle box on a lifeline represents the time needed for an object to complete a task.
Message
A message defines a particular communication between Lifelines of an interaction which means
showing how the objects interact with each other by sending and receiving messages.
1. Synchronous Messages: Represented by a solid line with a solid arrowhead. This symbol
is used when a sender must wait for a response to a message before it continues.

2. Asynchronous Messages: An asynchronous message does not wait for a response from
the receiver before the sender continues.

3. Return Message: A return message is used to indicate that the message receiver is done
processing the message and is returning control over to the message caller.

4. Reflexive message: When an object sends a message to itself, it is called a reflexive

message. It is indicated with a message arrow that starts and ends at the same lifeline as
shown in the example below.

5. Guards: To model conditions, like if condition in programming, we use guards in sequence

diagrams.