SOFTWARE ENGINEERING LAB FILE

SUBMITTED TO: SUBMITTED BY:

Ms. Anjum Vishal Rathi

Assistant Professor 2K17/CO/378

CO-V/A5
 INDEX
Sr.
NAME OF EXPERIMENT DATE SIGN REMARKS
No.
 EXPERIMENT – 1
AIM: To prepare problem statement for Automatic Teller System

REQUIREMENTS:

[A] Hardware Configuration:

1. Processor :- Intel Pentium 4 or Later or Compatible
2. Hard Disk :- 410GB or more
3. RAM :- 1GB or more
4. Printer :- Any
5. Monitor :- SVGA Color Monitor (Touch Screen or Simple)
6. Pointing Device :- Touch Pad or Keys

[B] Software Configuration:

1. Operating System :- Microsoft Windows XP or Later or Equivalent

2. Front End :- Visual Basic 6.0
3. Back End :- Oracle 8i

THEORY:
A problem statement is a concise description of an issue to be addressed or a condition to be
improved upon. It identifies the gap between the current (problem) state and desired (goal) state of a
process or product.

PROBLEM STATEMENT:
The ATM System is the project which is used to access their bank accounts in order to make cash
withdrawals. Whenever the user need to make cash withdraws, they can enter their PIN number
(personal identification number) and it will display the amount to be withdrawn in the form of
50’s,100’s and 500’s. Once their withdrawn was successful, the amount will be debited in their
account. The ATM will service one customer at a time. A customer will be required to enter ATM
Card number, personal identification number (PIN) – both of which will be sent to the database for
validation as part of each transaction. The ATM will communicate each transaction to the database
and obtain verification that it was allowed by the database. In the case of a cash withdrawal, a second
message will be sent after the transaction has been physically completed (cash dispensed or envelope
accepted). If the database determines that the customer’s PIN is invalid, the customer will be
required to re-enter the PIN before a transaction can proceed. If a transaction fails for any reason
other than an invalid PIN, the ATM will display an explanation of the problem, and will then ask the
customer whether he/she wants to do another transaction. The ATM will provide the customer with a
printed receipt for each successful transaction, showing the date, time, machine location, type of
transaction, account(s), amount, and ending and available balance(s) of the affected account (“to”
account for transfers).

CONCLUSION:
The problem statement of project “Automatic Teller System” has been prepared and the Software and
Hardware Requirements specified.
 EXPERIMENT – 2
AIM: Understanding SRS (Software Requirements Specification) for Automatic Teller System

REQUIREMENTS:

[A] Hardware Configuration:

1. Processor :- Intel Pentium 4 or Later or Compatible
2. Hard Disk :- 410GB or more
3. RAM :- 1GB or more
4. Printer :- Any
5. Monitor :- SVGA Color Monitor (Touch Screen or Simple)
6. Pointing Device :- Touch Pad or Keys

[B] Software Configuration:

1. Operating System :- Microsoft Windows XP or Later or Equivalent

2. Front End :- Visual Basic 6.0
3. Back End :- Oracle 8i

THEORY:

A software requirements specification (SRS) is a description of a software system to be developed.

It is modeled after business requirements specification (CONOPS), also known as a stakeholder
requirements specification (StRS). The software requirements specification lays out functional and
non-functional requirements, and it may include a set of use cases that describe user interactions that
the software must provide to the user for perfect interaction.
SRS establishes the basis for an agreement between customers and contractors or suppliers on how
the software product should function. SRS is a rigorous assessment of requirements before the more
specific system design stages, and its goal is to reduce later redesign. It should provide a realistic
basis for estimating product costs, risks, and schedules. Used appropriately, SRS can help prevent
software project failure.
The SRS document lists sufficient and necessary requirements for the project development. To
derive the requirements, the developer needs to have clear and thorough understanding of the
products under development. This is achieved through detailed and continuous communications with
the project team and customer throughout the software development process.

CONCLUSION:
The concept of SRS has been understood and SRS for library management system has been made.
 EXPERIMENT – 3
AIM: To draw a sample ENTITY RELATIONSHIP DIAGRAM for Automatic Teller System

THEORY:

ER-modeling is a data modeling method used in software engineering to produce a conceptual data
model of an information system. Diagrams created using this ER-modeling method are called Entity-
Relationship Diagrams or ER diagrams or ERDs.

Purpose of ER diagram
1. The database analyst gains a better understanding of the data to be contained in the database
through the step of constructing the ERD.
2. The ERD serves as a documentation tool.
3. Finally, the ERD is used to connect the logical structure of the database to users. In
particular, the ERD effectively communicates the logic of the database to users.

ENTITY RELATIONSHIP DIAGRAM:

CONCLUSION:
The concept of ER diagram has been understood and ER diagram for Automatic Teller System has
been drawn.
 EXPERIMENT – 4
AIM: To draw a sample DATA FLOW DIAGRAM for Automatic Teller System

THEORY:

DFD graphically representing the functions, or processes, which capture, manipulate, store, and
distribute data between a system and its environment and between components of a system. The
visual representation makes it a good communication tool between User and System designer.
Structure of DFD allows starting from a broad overview and expand it to a hierarchy of detailed
diagrams. DFD has often been used due to the following reasons:

• Logical information flow of the system

• Determination of physical system construction requirements
• Simplicity of notation
• Establishment of manual and automated systems requirements

DATA FLOW DIAGRAM:

CONCLUSION:
The concept of ER diagram has been understood and DATA FLOW diagram for Automatic Teller
System has been drawn.
 EXPERIMENT – 5
AIM: To draw a sample USE-CASE DIAGRAM for Automatic Teller System
THEORY:
A Use Case consists of use cases, persons, or various things that are invoking the features called as
actors and the elements that are responsible for implementing the use cases. Use case diagrams
capture the dynamic behaviour of a live system. It models how an external entity interacts with the
system to make it work. Use case diagrams are responsible for visualizing the external things that
interact with the part of the system.

Use-case diagram notations

Following are the common notations used in a use case diagram:

Use-case:
Use cases are used to represent high-level functionalities and how the user
will handle the system. A use case represents a distinct functionality of a
system, a component, a package, or a class. It is denoted by an oval shape
with the name of a use case written inside the oval shape. The notation of a
use case in UML is given below:

Actor:
It is used inside use case diagrams. The actor is an entity that interacts with the
system. A user is the best example of an actor. An actor is an entity that
initiates the use case from outside the scope of a use case. It can be any
element that can trigger an interaction with the use case. One actor can be
associated with multiple use cases in the system. The actor notation in UML is
given below.
USE-CASE TABLE:

USE-CASE DIAGRAM:

CONCLUSION:
The concept of USE-CASE diagram has been understood and USE-CASE diagram for Automatic
Teller System has been drawn.