SE Lab File

BTCS-606

EXPERIMENT 1
AIM: STUDY AND USES OF SMARTDRAW TO DRAFT A PROJECT PLAN.
Smart Draw: Smart Draw is a diagram tool used to make flowcharts, organization charts
and mind maps, project charts, and other business visuals. Smart Draw is a mind mapping program
that helps people visualize a wide range of projects for professional and personal use. Mind maps
are drawings that start with a key idea and branch out into subtopics in a clockwise pattern. These
branches can have any number of sub branches, each with its own concept. Smart Draw is a visual
processor used to create flowcharts, organization charts, mind maps, project charts, and other
visuals. Smart Draw is compatible only with Windows operating systems. Since version 7, it uses
Microsoft Fluent User Interface in conjunction with automated panels specific to each type of
diagram. It integrates with Microsoft Word, Excel, PowerPoint and Microsoft Project; it can export
diagrams to common image formats and PDF format. Smart Draw has launched its latest version
with a cloud sharing feature, known as Smart Draw 2013.
Features of Smart Draw
a) Printing: Smart draw allows flexibility when you wish to print out your document. The size
of the area you can draw on is unlimited, making smart draw excellent for posters and plans
and other large documents. When you are ready to print, you can choose to print to just one
sheet of paper, print on a range of pages, print to scale or even print to actual size depending
on your printer.
b) Adding Images: With smart draw you can add images to your project with the insert picture
feature. Built in photo software is included in the smart draw that allows you to import pictures
directly from a camera or any other video source. You can adjust the colour scale and crop
before adding the image to your project.
c) Sharing Documents: You can use the one click exportation tool to open your documents in
Microsoft office, or you can export them as an adobe pdf or in other graphic formats, such as
png, jpeg, bmp, tiff.
d) Live Maps: Captures live Google map data from the internet allowing users to easily
incorporate roads, countries, and zip codes into their project.
e) Auto Save: The auto save feature save your document as you create and modify it. This
prevents data loss, should the power suddenly flicker off.

1635007 Page 1
SE Lab File
BTCS-606

f) Templates: Smart draw comes with 70 kinds of templates. These templates include flow
charts. Bar charts and graphs, website wireframe, and matrix cards. If you do not find a
template that you like, you can create a custom template that works for your project.
g) One Step Charts and Pictures Charts: Charts and graphs can be built without creating a
spreadsheet first. Users can create charts using pictures or images to display data.
h) Automatic Flowcharting: Flowcharts are built using simple commands. Shape are placed
with lines drawn automatically. The flowchart is spaced and aligned automatically as it is
created.
i) Automatic Graphic Design: graphic themes specifying colours lines and type style can be
automatically applies to search project. This features quickly gives your projects unified
professional look.
j) Photos and Images: add photos and images to your document with the standard import copy
and paste commands. You can also import images and photos from your digital camera and
then manipulate them inside smart draw until you have the effect that you want.
k) Shape and Lines: each template comes with a library of shapes and symbols, simply drag
them onto your work board and place them where you want.
l) Integration: Smart draw works well with programs such as Microsoft office, Visio, Microsoft
project, Share point and Power point. Built in software is included in the smart draw that allows
you to import.

SMARTDRAW

1635007 Page 2
SE Lab File
BTCS-606

TOOLS OF SMARTDRAW
1. Flow Charts
A flowchart is a type of diagram that represents an algorithm or process. Showing the steps as
boxes of various kinds and their order by connecting these with arrows. This diagrammatic
representation can give a step by step solution to a given problem. Process operation are
represented in a flowchart, in contrast with data flow diagram, rather they are implied by the
sequencing of operations. Flow chart are used to analyzing designing, documenting or managing
a process or program in various fields. Basic Flowchart diagram looks like.

 Start and end symbols, represented as lozenges, ovals or rounded rectangles, usually containing
the word “Start” or “End”.
 Arrows, show what is called “flow of control” in computer science. An arrow coming from
one symbol and ending at another symbol signifies flow passes to the symbol the arrow points
to.
 Processing steps, represented as rectangles.
 Input/Output, Represented as a parallelogram.
 Conditional, Represented as a diamond. These typically contain a yes/no question or true/false
test. This symbol is unique in that it has two arrows, coming out of it, usually from the bottom
point and right point, one corresponding to yes or True, and one corresponding to no or false.
The arrows should always be labelled.

1635007 Page 3
SE Lab File
BTCS-606

Example of Flowchart
Draw a flowchart to find the sum of first 50 natural numbers.

2. E-R Diagram
Entity Relation diagram represents relationship between the two or more entities or modules. There
are some basic elements through which ER model is represented. The elements are as below: -
 Entities are the things about which information is given.

Entity

 A key attribute is the unique, distinguishing characteristics of the entity. For example, an
employee social security number might be the employees key attribute.

Attribute

 Relationship provides the structure needed to draw information from multiple entities.

Relationship

 Attributes are the data we collect about the entities.

1635007 Page 4
SE Lab File
BTCS-606

Example of E-R Diagram

3. Data Flow Diagram

The DFDs show the flow of data values from their courses in objects through the processes that
transform them to their destination in their objects. Values can include input values, output values,
and internal data stores. Control information is shown only in the form of control flows.

1635007 Page 5
SE Lab File
BTCS-606

Tools used in data flow diagram

 External Entity
An external entity is a source or destination of a data flow which is outside the area of study. Only
those entities which originate or receive data are represented on a business process diagram.

 Data store
A data store stores data passively for later access. A data store responds to request to store an
access data. It doesn’t generate any operation. A data store allows values to be accessed in an order
different from the order in which they were generated.

 Data Process
A data process transforms data values.

 Data Flow
A data flow moves data between processes or between processes and data stores. As such, it
represents a data value at some point within a computation and an intermediate value within a

1635007 Page 6
SE Lab File
BTCS-606

computation if the flow is internal to the diagram. This value is not changed. The names of input
and output flows can indicate their roles in the computation or the type of the value they move.

 Control Flow
A control flow is a signal that carries out a command or indicates that something has occurred. A
control flow occurs at a discrete point in time. The arrow indicates the direction of the control
flow. The name of the event is written beside the arrow.

Example of Data Flow Diagram

1635007 Page 7
SE Lab File
BTCS-606

EXPERIMENT 2
AIM: TO CONDUCT A FEASIBILITY STUDY OF A GIVEN PROJECT (LET’S GET
QUIZZICAL).
A feasibility study is a study that establishes whether conditions are right to implement a particular
project. Feasibility studies can be done for many purposes. Feasibility is defined as the practical
extent to which a project can be performed successfully. To evaluate feasibility, a feasibility study
is performed, which determines whether the solution considered to accomplish the requirements
is practical and workable in the software.

A feasibility study is performed by the company when they want to know whether the project is
possible under given circumstances:

 To find out whether the company has enough money for the project?
 To find out whether the product being created will sell?
 To find out whether if the company has enough resources for the project?

The feasibility study is an analysis of possible alternative solutions to a problem & a

recommendation on the best alternative it can decide whether the process can be carried by a new
system more efficiently than the existing one.

STEPS IN FEASIBILITY ANALYSIS

Eight steps involved in the feasibility analysis are:

 Form a project team & appoint a project leader.

 Prepare system flowcharts
 Enumerate potential proposed system.
 Define & identify characteristics of proposed system.
 Determine & evaluate performance & cost effective of each proposed system.
 Weight system performance & cost data.
 Select the best proposed system.
 Prepare & report final project directive to the management.

1635007 Page 8
SE Lab File
BTCS-606

TYPES OF FEASIBILITY

TECHNICAL FEASIBILITY: A study of resource availability that may affect the ability to
achieve an acceptable system. This evaluation determines whether the technology needed for the
proposed system is available or not. This is concerned with specifying equipment & software that
will successfully satisfy the user requirement. The technical needs of the system may include front
end & back end selection an important issue for the development of a project is the selection of
suitable front-end & back-end.

 Thus the company has technological resources to undertake the project?

 Do we possess the necessary technical expertise?
 Are the processes or procedures conductive for the project success?

ECONOMICAL FEASIBILITY: Economic justification is generally the “Bottom line”

consideration for most systems. Economic justification includes a broad range of concerns that
includes cost benefit analysis. In this we weight the cost & the benefits associated with the
candidate system & if suits the basic purpose of the organization. The financial & the economic
questions during the preliminary investigation ae verified to estimate the following:

 Is the project justified i.e. benefits out weight the cost?

 What is the minimum cost to attain system?
 Can the project be completed within the given cost constraints?

OPERATIONAL FEASIBILITY: It is mainly related to human organizations & political

aspects. The points to be considered are: What changes will be brought with the system? What
organization structures are disturbed? What new skills will be required? Do the existing staff
members have these skills? If not, can they be trained in due course of time? The system is
operationally feasible as it very easy for the end users to operate it. It only needs the basic
information about Windows platform.

1635007 Page 9
SE Lab File
BTCS-606

FEASIBILITY STUDY (LET’S GET QUIZZICAL)

After doing the project “Let’s Get Quizzical”, study & analyzing all the existing or required
functionalities of the system, the next task is to do the feasibility study for the project. All projects
are feasible- given unlimited resources & infinite time.
Feasibility study includes consideration of all the possible ways to provide a solution to the given
problem. The proposed solution should satisfy all the user requirements & should be flexible
enough so that future changes can be easily done based on the future upcoming requirements.

A. Economical Feasibility
This is very important aspect to be considered while developing a project. The technology is
decided based on minimum possible cost factor.
 All hardware and software cost has to be borne by the organization.
 Overall it is estimated that the benefits the organization is going to receive from the proposed
system will surely overcome the initial costs and the later on running cost for system.

B. Technical Feasibility
This included the study of function, performance and constraints that may affect the ability to
achieve an acceptable system.

C. Operational Feasibility
No doubt the proposed system is fully GUI based that is very user friendly and all inputs to be
taken all self-explanatory even to a layman. Besides, a proper training has been conducted to let
know the essence of the system to the users so that they feel comfortable with new system. As far,
study is concerned the clients are comfortable and happy as the system has cut down their loads
and doing.

1635007 Page 10
SE Lab File
BTCS-606

EXPERIMENT 3
AIM: DEVELOP SOFTWARE REQUIREMENTS SPECIFICATION (SRS) FOR A
GIVEN PROBLEM.

A software requirements specification (SRS) is a comprehensive description of the intended

purpose and environment for software under development. The SRS fully describes what the
software will do and how it will be expected to perform. An SRS minimizes the time and effort
required by developers to achieve desired goals and also minimizes the development cost. A good
SRS defines how an application will interact with system hardware, other programs and human
users in a wide variety of real-world situations. Parameters such as operating speed, response
time, availability, portability, maintainability, footprint, security and speed of recovery from
adverse events are evaluated.
The output of the requirements phase of the software development process is Software
Requirements Specification (SRS) (also known as requirements document). This document lays a
foundation for software engineering activities and is created when entire requirements are elicited
and analyzed. SRS is a formal document, which acts as a representation of software that enables
the users to review whether it (SRS) is according to their requirements.
IEEE defines software requirements specification as, 'a document that clearly and precisely
describes each of the essential requirements (functions, performance, design constraints and
quality attributes) of the software and the external interfaces. Each requirement is defined in such
a way that its achievement can be objectively verified by a prescribed method, for example,
inspection, demonstration, analysis or test. Note that requirements specification can be in the form
of a written document, a mathematical model, a collection of graphical models, a prototype, and
so on.
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 important to note that an SRS contains functional and non-
functional 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.

1635007 Page 11
SE Lab File
BTCS-606

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
behaviour necessary to address those problems. Therefore, the SRS should be written 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.
 It serves as the parent document for testing and validation strategies that will be applied to
the requirements for verification.

Software requirements specifications 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:

a) Functionality. What is the software supposed to do?

b) External interfaces. How does the software interact with people, the system’s hardware, other
hardware, and other software?

1635007 Page 12
SE Lab File
BTCS-606

c) Performance. What is the speed, availability, response time, recovery time of various software
functions, etc.?

d) Attributes. What are the portability, correctness, maintainability, security, etc. considerations?

e) 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.?

FEATURES OF SRS DOCUMENT

 Correctness: User review is used to ensure the correctness of requirements stated in the SRS.
SRS is said to be correct if it covers all the requirements that are actually expected from the
system.
 Completeness: Completeness of SRS indicates every sense of completion including the
numbering of all the pages, resolving the to be determined parts to as much extent as possible
as well as covering all the functional and non-functional requirements properly.
 Consistency: Requirements in SRS are said to be consistent if there are no conflicts between
any set of requirements. Examples of conflict include differences in terminologies used at
separate places, logical conflicts like time period of report generation, etc.
 Unambiguousness: An SRS is said to be unambiguous if all the requirements stated have only
1 interpretation. Some of the ways to prevent unambiguousness include the use of modelling
techniques like ER diagrams, proper reviews and buddy checks, etc.
 Ranking for importance and stability: There should a criterion to classify the requirements
as less or more important or more specifically as desirable or essential. An identifier mark can
be used with every requirement to indicate its rank or stability.
 Modifiability: SRS should be made as modifiable as possible and should be capable of easily
accepting changes to the system to some extent (while preserving completeness & consistency)
 Verifiability: An SRS is verifiable if there exists a specific technique to quantifiably measure
the extent to which every requirement is met by the system.
 Traceability: One should be able to trace a requirement to a design component and then to a
code segment in the program. Similarly, one should be able to trace a requirement to the
corresponding test cases.

1635007 Page 13
SE Lab File
BTCS-606

 Design Independence: There should be an option to choose from multiple design alternatives
for the final system. More specifically, the SRS should not include any implementation details.
 Testability: An SRS should be written in such a way that it is easy to generate test cases and
test plans from the document.
 Understandable by the customer: An end user maybe an expert in his/her specific domain
but might not be an expert in computer science. Hence, the use of formal notations and symbols
should be avoided to as much extent as possible. The language should be kept easy and clear.
 Right level of abstraction: If the SRS is written for the requirements phase, the details should
be explained explicitly. Whereas, for a feasibility study, fewer details can be used. Hence, the
level of abstraction varies according to the purpose of the SRS.

A sample of a basic SRS outline

1. Introduction
1.1 Purpose
1.2 Document conventions
1.3 Intended audience
1.4 Additional information
1.5 Contact information/SRS team members
1.6 References
2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies
3. External Interface Requirements
3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces

1635007 Page 14
SE Lab File
BTCS-606

3.4 Communication protocols and interfaces

4. System Features
4.1 System feature A
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B
5. Other Non-functional Requirements
5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation
6. Other Requirements
Appendix A: Terminology/Glossary/Definitions list
Appendix B: To be determined

EXAMPLE: - AIRLINE RESERVATION SYSTEM

SRS DETAILS

1. INTRODUCTION
1.1. PURPOSE
The main purpose of this software is to reduce the manual errors involved in the airline reservation
process and make it convenient for the customers to book the flights as when they require such
that they can utilize this software to make reservations, modify reservations or cancel a particular
reservation.

1.2 SCOPE
The name of the software is “AIRLINE RESERVATION SYSTEM”. This software provides
options for viewing different flights available with different timings for a particular date and
provides customers with the facility to book a ticket, modify or cancel a particular reservation but

1635007 Page 15
SE Lab File
BTCS-606

it does not provide the customers with details of cost of the ticket and it does not allow the customer
to modify a particular part of his reservation and he/she can modify all his details.

1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

ARS-Airline Reservation System
LAN-Local Area Network
GUI-Graphical User Interface
OS-Operating System
RAM-Random Access Memory
MB-Mega Bytes
GB-Giga Bytes
Mbps-Megabits per second
HDD-Hard Disk Drive

1.4 REFERENCES
The books and materials referred during the pre-development stages of the project include
1. Software Engineering-A Practitioner’s Approach by Roger S. Pressman
2. Software Engineering-By James Peters

1.5 OVERVIEW
The rest of the document deals about all the main features of this software each will its purpose
and its main functions. It also gives details about the interface with other products and related
functionality of each product.

2. OVERALL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

The “ARS” software is an independent application. It is a self-contained product. The system
interfaces, user interfaces and hardware interfaces related with this software are defined as follows.
2.1.1 System Interfaces
The client systems should be able to share the data available in the data base through the network
connection.

1635007 Page 16
SE Lab File
BTCS-606

2.1.2 User Interfaces

The screen formats and menu structure should be in such a way that even have users will find it
easy to use. The product must be use-friendly and very inter-active. The functionality provided by
the system like displaying error messages should adapt itself to the different users of the software.
2.1.3 Hardware Interfaces
Nil
2.1.4 Software Interfaces
Name of the language: Visual Basics
2.1.5 Communication Interfaces
There is an LAN used for communication among the different client systems to be used.
2.1.6 Memory Constraints
The system requires disk space of 10 GB & a 256 MB HDD and 64MB RAM for client systems.
2.1.7 Operation
The users can first make a reservation in a particular flight for a particular date and time. The
system provides the customer with a pin code which gives him access to either make any changes
in his reservation or cancel a reservation. These must also be back up of data to enable any easy
recovery from any features.
2.1.8 Site Adaptive Requirements
The “ARS” software is an independent and self-contained product and no modification are
required to adapt to a particular installation.

2.2 PRODUCT FUNCTIONS

The major functions include
• Providing flight details
• Flight bookings for a particular destination, date and time and also providing with a pin code.
• Allowing the customer to modify or cancel his reservation provided the correct pin code is given.
• Displaying a report of the number of people flying in a particular flight.

2.3 USER CHARACTERISTICS

No technical experience is required basic knowledge of handling system is sufficient.

1635007 Page 17
SE Lab File
BTCS-606

2.4 CONSTRAINTS
• Regulatory policies: It is a mandatory that no text book must be left empty or contains insufficient
data.
• Hardware limitations: There must be a 64 MB on board memory
• Control functions: The software must be very user-friendly and display appropriate error
messages.
• Interfaces to other applications: Not applicable.
• Parallel operations: It must support many users simultaneously.
• Reliability requirements: Data redundancy and use of special/blank characters must be avoided.
• Safety/security considerations: The application must be exited always normally.

2.5 ASSUMPTIONS AND DEPENDENCIES

It is assumed that the details of the cost of ticket are already known to the customer. Future changes
like providing different types of flights with different classes like business class, economic class
will allow the customers to benefit from one facility.

2.6 APPORTIONING OF REQUIREMENTS

The necessity of providing options to customer to choose their seat or to choose for economic or
business class can be delayed until future versions of the software are developed.

3. SPECIFIC REQUIREMENTS

3.1 EXTERNAL INTERFACE REQUIREMENTS

3.1.1 User Interfaces
The interface must be easy to understand. The user interface includes
• Screen Formats/Organization: The introductory screen will be the first to be displayed which
will allow the users to choose either of the two options, viewing flight detail or booking a ticket.

• Window Format/Organization: When the user chooses some other option, then the information
pertaining to that choice will be displayed in a new window which ensures multiple windows to
be visible on the screen and the users can switch between them.

• Data Format: The data entered by the users will be alphanumeric.

1635007 Page 18
SE Lab File
BTCS-606

• End Messages: When there are some exceptions raising error like entering invalid details, then
error messages will be displayed prompting the users to re-enter the details.

3.1.2 Hardware Interfaces

The system must basically support certain input and output devices. Their descriptions are as
follows.
Name of Item Description of Purpose Source of
Input/Description of
output
Key board To accept data from user like Source of Input
pin code, personal details,
flight details.
Printer To print the bookings mode Destination of Output
E.g.: Destination chosen
with date and timings

3.1.3 Software Interfaces

Not applicable since the product under considerations is an independent one.

3.1.4 Communication Interfaces

Every client system connected through LAN establishes a communication only with the server and
not with any client system. An LAN of 10 Mbps is used.

3.2 SOFTWARE PRODUCT FEATURES

3.2.1 FEATURE 1
The ability of the software is to provide the details of the flights available and allow the customers
to choose a particular destination and make reservation.
3.2.1.1 Purpose
The purpose of this is to enable the users to view the different flights available so as to make it
convenient for him to make a reservation.
3.2.1.2 Stimulus/Response
Once the user chooses the particular option, the web pages corresponding to that are to be displayed

1635007 Page 19
SE Lab File
BTCS-606

on the screen i.e., it will display the different flights available to their respective destinations and
allow the customer to book a ticket.
3.2.1.3 Associated Functional Requirements
3.2.1.3.1 Functional Requirements
Once the user makes a reservation, he must be provided with a pin code.
3.2.1.3.1.1 Introduction
The user must be provided with the required information within10 seconds.
3.2.1.3.1.2 Inputs
The user must enter the destination with date and timings and must make reservation by giving his
personal details like name, address, age, gender, nationality.
3.2.1.3.1.3 Processing
Recognizing the correct details are entered that a message is displayed confirming his reservation
and displays the pin code

3..2.2 FEATURE 2
The software allows the user to modify an already existing reservation made by the customer if in
case there are any changes that are to be modified in the reservations of the ticket.
3.2.2.1 Purpose
The purpose is to allow the customer to make any changes in his personal details or flight booking
details.
3.2.2.2 Stimulus/Response
Once the user requests for changing his reservation, it must be displayed on the screen prompting
the customer to enter his pin code.
3.2.2.3 Associated Functionality Requirements
3.2.2.3.1 Functional Requirements
If the pin code provided by the customer does not match, then would notify the person by
displaying error messages.
3.2.2.3.1.1 Introduction
The system will allow the customer to modify his reservation provided correct pin code has been
entered by him.

1635007 Page 20
SE Lab File
BTCS-606

3.2.2.3.1.2 Input
The user should enter his pin code which gives him access to modify his reservation.
3.2.2.3.1.3 Processing
The pin code is processed and checked for his validity. If it is correct then the user can modify his
reservation else an error message will be displayed asking the user to enter the correct pin code
number.
3.2.2.3.1.4 Output
Given the correct pin code, the user can now modify his reservation. A new pin code will be
generated for the customers.

3.2.3 FEATURE 3
The software allows the user to cancel an already existing reservation made by the customer who
has booked the ticket.
3.2.3.1 Purpose
The purpose is to allow the customer to cancel his reservation if not required.
3.2.3.1 Stimulus/Response
Once the user requests for canceling his reservation, it must be displayed on the screen prompting
the customer to enter his pin code.
3.2.3.3 Associated Functional Requirements
3.2.3.3.1 Functional Requirements
If the pin code provided by the customer does not match, then it would notify the person by
displaying error messages.
3.2.3.3.1.1 Introduction
The system will allow the customer to cancel his reservation provided correct pin code has been
entered by the customer.
3.2.3.3.1.2 Input
The user should enter his pin code which gives him access to cancel his reservation.
3.2.3.3.1.3 Processing
The pin code is processed and checked for its validity. If it is correct, then the user can cancel his
reservation else an error message will be displayed asking the user to enter the correct pin code
number.

1635007 Page 21
SE Lab File
BTCS-606

3.2.3.3.1.4 Output
Given the correct pin code, the user can now cancel his reservation

3.2.4 FEATURE 4
The software must also give a report on the number of reservations made for a particular flight.
3.2.4.1 Purpose
The purpose is to enable the administrator to view the number of people in a particular flight.
3.2.4.2 Stimulus/Response
Once the user requests for this option, all the details of the customers who have made reservation
will be displayed.
3.2.4.3 Associated Functional Requirements
3.2.4.3.1 Functional Requirements
If no reservations are made, then a message is displayed that no bookings have been made.
3.2.4.3.1.1 Introduction
The system will allow the administrator to view all the details of the customer who have made
reservations.
3.2.4.3.1.2 Input
The administrator must enter the password so that access is given only to him to view the details
of all the customers.
3.2.4.3.1.3 Processing
The password is processed and checked for its validity. If it is not correct, then the administrator
is asked to enter the correct password.
3.2.4.3.1.4 Output
Given the correct password, the administrator can view all the details of customers with date and
time of their bookings made.

3.3 PERFORMANCE REQUIREMENTS

• At any instant, a maximum of four nodes or users will be given access simultaneously.
• Since the program handles multiple users, if more than one person attempts to same date to the
files stored in the data base, the program will lock the data file using a 2-phase commit protocol to
prevent simultaneous access.

1635007 Page 22
SE Lab File
BTCS-606

3.4 DESIGN CONSTRAINTS

• Requires 256 MB on-board memory.
• Based completely on Windows functionality platform.
• The software should be portable and must be inaccessible to unauthorized users.

3.5 SOFTWARE SYSTEM ATTRIBUTES

3.5.2 Reliability
The factors needed to establish the software expected reliability are
• The user inputs should be valid and within the given range.
• Normal termination of the program.
3.5.2 Availability
The factors guarantee the software’s availability includes proper termination and correct input
details. Also the resources used for the project development are Microsoft Certified which speaks
of its high quality standards.
3.5.3 Security
• It must be ensured that access will be provided to the authorized persons through user ID and
password.
• Network security will be provided by the use of firewalls.
• Checks can be performed at regular intervals to ensure data integrity.
3.5.4 Maintainability
The software will be developed by implementing the concept of modularity which in turn reduces
the complexity involved in maintaining it. The administrator should have a sound technical
knowledge about maintaining the software and further enhancements will be undertaken by the
developer.
3.5.5 Portability
The application is portable which ensures its adaptability for use on different computer terminals
with different operating systems and standards.

3.6 LOGICAL DATABASE REQUIREMENTS

The system requires the use of text files to maintain the customer’s personal details and his booking
details. An entity must be used to specify the various departments and the seats available in them.

1635007 Page 23
SE Lab File
BTCS-606

This information will be used frequently by the authorities for verification.

3.7 OTHER REQUIREMENTS

Nil
4. CONCLUSION
This SRS document is used to give details regarding airline reservation system. In this all
functional & non-functional requirements are specified in order to get clear cut idea to develop a
project.

1635007 Page 24
SE Lab File
BTCS-606

EXPERIMENT 4
AIM: DFD MODEL FOR LIBRARY MANAGEMENT SYSTEM IN SMARTDRAW.

DFD: A Data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system, modelling its process aspects. A DFD is often used as a preliminary step to
create an overview of the system without going into great detail, which can later be elaborated.
The DFD also provides information about the outputs and inputs of each entity and the process
itself. A data-flow diagram has no control flow, there are no decision rules and no loops.

DFDs are one of the three essential components of the structured-systems analysis and design
method (SSADM). A DFD is process centric and depicts 4 main components.
1. Processes (circle)
2. External Entities (rectangle)
3. Data Stores (two horizontals, parallel lines or sometimes and ellipse)
4. Data Flows (curved or straight line with arrowhead indicating flow direction)

Each DFD may show a number of processes with data flowing into and out of each process. If
there is a need to show more detail within a particular process, the process is decomposed into a
number of smaller processes in a lower level DFD. In this way, the Content Diagram or Context-
Level DFD is labeled a “Level-0 DFD” while the next level of decomposition is labeled a “Level-
1 DFD”, the next is labeled a “Level-2 DFD”, and so on.

Context Level DFD’s

A context level DFD is the most basic form of DFD. It aims to show how the entire system works
at a glance. It provides no information about the timing, sequencing, or synchronization of
processes such as which processes occur in sequence or in parallel. There is only one process in
the system and all the data flows either into or out of this process. Context level DFD’s
demonstrates the interactions between the process and external entities. They do not contain Data
Stores.
When drawing Context Level DFD’s, first identify the process, all the external entities and all the
data flows. It also must state any assumptions made about the system. It is advised that to draw the

1635007 Page 25
SE Lab File
BTCS-606

process in the middle of the page. We then draw our external entities in the corners and finally
connect our entities to our process with the data flows

Level 1 DFD’s

Level 1 DFD’s aim to give an overview of the full system. They look at the system in more detail.
Major processes are broken down into sub-processes. Level 1 DFD’s also identifies data stores
that are used by the major processes.
When constructing a Level 1 DFD, start by examining the Context Level DFD. Break up the single
process into its sub-processes. Then pick out the data stores from the text we are given and include
them in our DFD. Like the Context Level DFD’s, all entities, data stores and processes must be
labelled. It also must state any assumptions made from the text.

Level 2 DFD’s

Level 2 DFD’s offers a more detailed look at the processes that make up an information system
than a level 1 DFD does. It can be used to plan or record the specific makeup of a system.

DFD FOR LIBRARY MANAGEMENT SYSTEM

Steps for Making the DFD:

1. Identify External Entities- Student, Librarian, Books

2. Identify Data Flows- Book return/issue request, issued book, return, issued, manage, student
record info, issued book record, update issue book record, return book record, student id, update
ticket record, update fine record.

3. Identify Sub Processes- Manages Student Record, manages issue book record, manages return
book record, issue or return book record, issue or return book, manage student identification
record, manage student fine record, manage student book ticket record, update student record.

4. Identify Data Stores- Student record, issued book record, return book record, student
identification record, student ticket record, student fine record.

1635007 Page 26
SE Lab File
BTCS-606

Context Level DFD

Level 1 DFD

1635007 Page 27
SE Lab File
BTCS-606

Level 2 DFD

1635007 Page 28
SE Lab File
BTCS-606

EXPERIMENT 5
AIM: DFD MODEL FOR UNIVERSITY MANAGEMENT SYSTEM.

Steps for Making the DFD:

1. Identify External Entities- Student, Professor, College

2. Identify Data Flows- Registration for Admission, Confirmation Letter, Lectures &
assignments, course roster, student info, student info, fee info, pays, fee receipt, class info, check
exam, exam result, conduct, college assignment, exam result info, college info, available course,
available, show enrolled course.

3. Identify Sub Processes- Student register, fees management, lectures & assignments,
examination & result, college management, verify availability of course, enroll student.

4. Identify Data Stores- Student info, fee record, class record, exam result record, college record,
course table.

Context Level DFD

1635007 Page 29
SE Lab File
BTCS-606

Level 1 DFD

Level 2 DFD

1635007 Page 30
SE Lab File
BTCS-606

EXPERIMENT 6
AIM: DFD MODEL FOR AIRLINE MANAGEMENT SYSTEM.

Steps for Making the DFD:

1. Identify External Entities- User, Flight, Airline Bookings.

2. Identify Data Flows- User login, Acknowledgement, Schedule, check for availability,
Booking/Cancel Booking, user data, user information, flight information, booked flight, cancel
booking, flight detail, update flight record, select flight, payment details.

3. Identify Sub Processes- Enter user information, booking for flight, Verify Flight information,
cancel airline booking, update airline booking record, search flights, select flights, input user
details, make payment.

4. Identify Data Stores- User Information record, Flight record, Update booking record.

Context level DFD

1635007 Page 31
SE Lab File
BTCS-606

Level 1 DFD

Level 2 DFD

1635007 Page 32
SE Lab File
BTCS-606

EXPERIMENT 7
AIM: UML DIAGRAM FOR GIVEN SYSTEM.

Unified Modeling Language (UML) is a general purpose modelling language. The main aim of
UML is to define a standard way to visualize the way a system has been designed. It is quite similar
to blueprints used in other fields of engineering. UML is not a programming language; it is rather
a visual language. We use UML diagrams to portray the behaviour and structure of a system. UML
helps software engineers, businessmen and system architects with modelling, design and analysis.
The Object Management Group (OMG) adopted Unified Modelling Language as a standard in
1997. It’s been managed by OMG ever since. International Organization for Standardization (ISO)
published UML as an approved standard in 2005.

UML Diagram Types

1. Use Case Diagram

Use case diagrams give a graphic overview of the actors involved in a system, different functions
needed by those actors and how these different functions interact.

2. Class Diagram

Class diagrams are the main building block of any object-oriented solution. It shows the classes in
a system, attributes, and operations of each class and the relationship between each class. In most
modeling tools, a class has three parts. Name at the top, attributes in the middle and operations or
methods at the bottom. In a large system with many related classes, classes are grouped together
to create class diagrams. Different relationships between classes are shown by different types of
arrows.

3. Object Diagram

Object Diagrams, sometimes referred to as Instance diagrams are very similar to class diagrams.
Like class diagrams, they also show the relationship between objects but they use real world
examples. They show how a system will look like at a given time. Because there is data available
in the objects, they are used to explain complex relationships between objects.

1635007 Page 33
SE Lab File
BTCS-606

4. Sequence Diagram

Sequence diagrams in UML show how objects interact with each other and the order those
interactions occur. It’s important to note that they show the interactions for a particular scenario.
The processes are represented vertically and interactions are shown as arrows.

5. Collaboration Diagram

Collaboration diagrams are used to show how objects interact to perform the behavior of a
particular use case, or a part of a use case. Along with sequence diagrams, collaboration is used
by designers to define and clarify the roles of the objects that perform a particular flow of events
of a use case.

6. Activity Diagram

Activity diagrams represent workflows in a graphical way. They can be used to describe the
business workflow or the operational workflow of any component in a system.

7. State Chart Diagram

A State chart diagram describes a state machine. State machine can be defined as a machine which
defines different states of an object and these states are controlled by external or internal events.
The most important purpose of State chart diagram is to model lifetime of an object from creation
to termination.

8. Component Diagram

A component diagram displays the structural relationship of components of a software system.

These are mostly used when working with complex systems with many components. Components
communicate with each other using interfaces. The interfaces are linked using connectors.

9. Deployment Diagram

A deployment diagram shows the hardware of your system and the software in that hardware.
Deployment diagrams are useful when your software solution is deployed across multiple
machines with each having a unique configuration.

1635007 Page 34
SE Lab File
BTCS-606

EXAMPLE: ATM SYSTEM

1. Use case diagram

2. Class diagram

1635007 Page 35
SE Lab File
BTCS-606

3. Sequence diagram

4. Collaboration diagram

1635007 Page 36
SE Lab File
BTCS-606

5. State chart diagram

6. Activity diagram

1635007 Page 37
SE Lab File
BTCS-606

7. Component diagram

8. Deployment diagram

1635007 Page 38
SE Lab File
BTCS-606

EXPERIMENT 8
AIM: TRACKING & MONITORING THE PROGRESS OF SOFTWARE PROJECT IN
OPEN PROJECT (GANTT CHART).

THEORY:

A Gantt chart, commonly used in project management, is one of the most popular & useful ways
of showing activities displayed against time. On the left of the chart is a list of the activities &
along the top is suitable time scale. Each activity is represented by a bar, the position & length of
the bar reflects the start date, duration & end date of the activity. This allows you to see at a glance.

 What the various activities are.

 When each activity begins & end.
 How long each activity is scheduled to last.
 Where activities overlap with other activities, & by how much
 The start & end date of the whole project

STEP 1:

Gantt Chart

1635007 Page 39
SE Lab File
BTCS-606

STEP 2: Network Chart

A project network is a graph (flow chart) depicting the sequence in which a project’s terminal
elements are to be completed by showing terminal elements & their dependencies.

STEP 3: WBS (Work Breakdown Structure)

The WBS shows the “part-whole” relations. In contrast, the project network shows the “before-
after” relations.
The condition for a valid project network is that it doesn’t contain any circular references.

1635007 Page 40
SE Lab File
BTCS-606

STEP 4: REPORT

The report of project generated for the progress of the project is represented in the following:

1635007 Page 41
SE Lab File
BTCS-606

EXPERIMENT 9
AIM: TESTING OF A WEBSITE.

“MYNTRA” is a popular online shopping website that provides a platform for purchasing
products. The products are displayed in photographs along with the summary & any user can
browse for desired products and can buy them.

Operating System: The operating systems used are Windows 7,8,10.

1635007 Page 42
SE Lab File
BTCS-606

TEST CASE 1: Text box & an E-mail should contain ‘@’ &’.’ & it should be a valid e-mail Id,
otherwise it will give an error message.

TEST CASE 2: Text box & a password field should contain more than 6 characters, otherwise it
will give an error message and a password should be in the encrypted format otherwise it will
again give an error message.

1635007 Page 43
SE Lab File
BTCS-606

TEST CASE 3: It is a mandatory field to choose gender if not error message is displayed.

TEST CASE 4: The ‘Mobile no.’ field is mandatory for password & must have an input of 10
digits otherwise it will give an error.

1635007 Page 44
SE Lab File
BTCS-606

EXPERIMENT 10
AIM: TO IDENTIFY THE USAGE OF REGRESSION TESTING.

Regression testing is a testing that is done to verify that a code change in the software does not
impact the existing functionality of the product. This testing makes sure that the product works
fine as previously with the newly added functionality or any change in the existing feature or once
the bug fix is done. Previously executed test cases are re-executed in order to verify the impact of
change.
Regression Testing is a Software Testing type in which test cases are re-executed in order to check
whether the previous functionality of the application is working fine and the new changes have not
introduced any new bugs. This test can be performed on a new build when there is a significant
change in the original functionality that too even in a single bug fix. Regression means retesting
the unchanged parts of the application.

Background: Enhancements are introduction of new features to the software & might be released
in different versions. Whenever a version is released, regression testing should be done on the
system to ensure that the existing features have not been disturbed.

Problem Description: Consider the scenario of development of software for Travel Management
System(TMS). TMS has been developed by Infosys & released to its Customer Advance Travel
Solutions Ltd. (ATSL). Integration testing, system testing, acceptance testing was carried out
before releasing the final build to the customer. However, as per the customer feedback during the
first month of usage of the software, some minor changes are required in the Enquiry Module of
the TMS. The customer has approached Infosys with the minor changes for upgrading the
software. The development team of Infosys has incorporated. Those changes, & delivered the
software to testing team to test the upgraded software. Which among the following statement is
true?
1. Since minor changes are there, integration of the Enquiry Module & quick system testing on
Enquiry module should be done.
2. The incorporation of minor changes would have introduced new bugs into other modules, so
regression testing should be carried out.

1635007 Page 45
SE Lab File
BTCS-606

3. Since the acceptance testing is already carried out, it is enough if the team performs samity
testing on the Enquire module.
4. No need of testing any module.

Statement:
The incorporation of minor changes would have introduced new bugs into other modules. So
regression testing should be carried out.
Summary: Identified the relevant type of testing needed.

1635007 Page 46