Mahatma Gandhi Mission’s

College of Engineering & Technology

A-09, Sector 62, NOIDA

Subject:- Software Engineering Lab (KCS-661)

Name: Anurag Kumar Roll no:1809510016

Year: IIIrd

Semester: 6th Branch: CSE

Academic Year: 2020-21
 LIST OF EXPERIMENTS
S.No. TITLE PAGE Date Grade

1 Prepare a SRS document in line with the IEEE recommended 3-9

standards.
2 Draw the use case diagram and specify the role of each of the 10
actors. Also state the precondition, post condition and function of
each use case.
3 Draw the activity diagram. 11
4 Identify the classes. Classify them as weak and strong classes and 13
draw the class diagram.
5 Draw the sequence diagram for any two scenarios. 14
6 Draw the collaboration diagram. 15

7 Draw the state chart diagram. 16

8 Draw the component diagram. 17

9 Draw the deployment diagram. 18

Certified that Mr Anurag Kumar of class TT-CS .

Roll No. 1809510016 has performed above experiments satisfactory within the
institute for the year 2020-21
Date 28/07/2021 .

Head of Dept. Lecturer Principal

1
 Experiment -1

Aim: Prepare the SRS document in line with the IEEE recommended
standards.

Theory Concepts: A software requirements specification (SRS) is a

description of a software system to be developed. It lays out functional
and non-functional requirements, and may include a set of use cases that
describe user interactions that the software must provide.
Software requirements specification establishes the basis for an agreement
between customers and contractors or suppliers (in market-driven
projects, these roles may be played by the marketing and development
divisions) on what the software product is to do as well as what it is not
expected to do. Software requirements specification permits a rigorous
assessment of requirements before design can begin and reduces later
redesign. It should also provide a realistic basis for estimating product
costs, risks, and schedules.
The software requirements specification document enlists enough and
necessary requirements that are required for the project development. To
derive the requirements we need to have clear and thorough
understanding of the products to be developed or being developed. This is
achieved and refined with detailed and continuous communications with
the project team and customer till the completion of the software.

3
Implementation:

SRS of E- Vaccination- System

Purpose:-
Peoples are at increased risk for Corona virus diseases because their immune
systems have not yet built up the necessary defenses to fight serious infections and
diseases. As a result, diseases like whooping cough or pneumococcal disease can be
very serious and even deadly for individuals. Vaccinations start early in life to
protect individuals before they are exposed to these diseases. The proposed system
of e Vaccination system provide proper schedule of individual vaccine time interval
for the parents. People can search near by Vaccination-center and make a
appointment. The system implemented as android app.

In the existing system, Vaccines are provided by various aspects such as by

attending school manually and there is a chance that some of the people’s may miss
the opportunity of getting vaccinated due to some mandatory reasons. Which leads
to loss of life or gets affected by Corona Virus ? This is a time delay process to wait
for each and every one all over the places

SCOPE

We can change this manual system into e-vaccination system by collecting the info
of infants, registered under website so that those who didn’t took vaccination can
avail one more opportunity to save the life of their children . By this system a lot of
man-hours can be saved and it is efficient too.

OBJECTIVE

This study lays out a frame work for a new system to be developed and brought
to the market for maximum use and to create an avenue through the web where
users can log on to the sever and make a selection of whatever goods or food
they like and subsequently pay via the internet.
4
The following are the objectives this would bring:

• This Software Requirements Specification (SRS)is the requirements work

product that formally specifies E-Vaccination Management System .
• It includes the results of both business analysis and systems analysis efforts
various techniques were used to elicit the requirements and we have identified
your needs, analyzed and refined them.
• The objective of this document therefore is to formally describe the system’s
high level requirements including functional requirements, non-functional
requirements and business rules and constraints. The detail structure of this
document is organized as follows:

• Section 2 of this document provides an overview of the business domain that

the proposed E-Vaccination Management System will support.

OVERVIEW

The remaining sections of this document provide a general description,

including characteristics of the users of this project, the product's hardware,
and the functional and data requirements of the product. General description of
the project is discussed in section 2 of this document. Section 3 gives the
functional requirements, data requirements and constraints and assumptions
made while designing the E-Store. It also gives the user viewpoint of product.
Section 3 also gives the specific requirements of the product. Section 3 also
discusses the external interface requirements and gives detailed description of
functional requirements. Section 4 is for supporting information.

5
 REFERENCES

Some of the references used for preparing the vision document include:

1. IEEE document for Software RequirementsSpecifications

2. Wikipedia

FUNCTIONAL REQUIREMENTS

Login and registration: If User is a New User, then He/she can register on
the System. For registration user needs to fill the registration form (First Name,
Last Name, Email Id, Aadhar Card_number, Mobile Number, Password,
Security Questions) after this System send OTP and Verification Mail to
register Mobile number and Email Id to activate the account.

After successfully registration User can login into the system by registered
Mobile number and password OR Registered Email Id and Password.

Search: Search is the function from that user can search Vaccination Center
around him/her . User need to write pincode or whole address to show
vaccination centers services according to that address.

Vaccination Availability:-

The admin shall generate reports on vaccine availability about the following
information: vaccine name, vaccine slots, occupied/unoccupied

Certificate Generation

The admin shall generate certificate on beneficiary about the following

information:
Beneficiary’s Aadhar card number , beneficiary’s name, vaccine name, vaccine
date and the doctor’s name which was assigned.

6
Logout: User can remove from the system by clicking Logout.

Notifications: Notification send to user for reminder, Appointment confirmation or a

last date for vaccination.

7
INTERFACES REQUIREMENTS:

USER INTERFACE

Keyboard and mouse

HARDWARE INTERFACE

For the hardware requirements the SRS specifies the logical characteristics of
each interface b/w the software product and the hardware components. It
specifies the hardware requirements like memory restrictions, cache size, the
processor, RAM size etc... those are required for the software to run.
Minimum Hardware Requirements
Processor Pentium III
Hard disk drive 40 GB
RAM 128 MB
Cache 512 kb

Preferred Hardware Requirements

Processor Pentium IV
Hard disk drive 80 GB
RAM 256 MB
Cache 512 kb

SOFTWARE INTERFACE

Any window based operating system with DOS support are primary
requirements for software development. Windows XP, FrontPage and dumps
are required. The systems must be connected via LAN and connection to
internet is mandatory.

8
Nonfunctional Requirements

Functional requirements define what a system is supposed to do and non-

functional requirements define how a system is supposed to be. A non-
functional requirement is often called Quality attributes of a system. They
specify criteria that judge the operation of a system, rather than specific
behaviors, for example: “Modified data in a database should

be updated for all users accessing it within 2 seconds.”

Some typical non-functional requirements are:

➢ Security: It is important to specify the level of security that should be met.

➢ Privacy: Meeting basic requirements for GDPR.
➢ Scalability and performance: Ensuring that the system can scale to meet
expected traffic and order volume at normal and peak times.
➢ Speed of web services: Defining how long web services will take to provide
a response.
➢ Accessibility: Ensuring that the platform meets the basic accessibility
standards throughout.
➢Documentation: Ensuring that the platform is sufficiently documented.
➢ Quality: Even the best e-commerce platforms can be used badly so you
should insist that code is developed to a good quality standard.
➢ Extensibility: Ensuring that the platform is extended in such a way to make
future development feasible.
➢ Data integrity and retention: Defining how long data should be stored and
how the integrity of data is maintained.
➢ Testing Page: Defining how unit testing will be built into the solution.
➢ Compatibility: Ensuring that the platform can be easily integrated
with 3rd party systems.
➢ Search: Defining how quickly the system will return search results.
➢Availability: Defining the agreed uptime of the platform under normal
conditions.
➢ Infrastructure: Defining the infrastructure performance thresholds (CPU
and memory usage).

9
Conclusion
This SRS document is used to give details regarding E-vaccination
Management System. In this all the functional and non-functional
requirements are specified in order to get a clear cut idea to develop a project.

Output / Conclusion: SRS is developed as per requirements

10
 Experiment -2

Aim : 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.

To model a system, the most important aspect is to capture the dynamic

behavior. Dynamic behavior means the behavior of the system when it is
running/operating.
Only static behavior is not sufficient to model a system rather dynamic behavior
is more important than static behavior. Now as we have to discuss that the use
case diagram is dynamic in nature, there should be some internal or external
factors for making the interaction.

10
 Experiment -3

Aim: Draw the activity diagram.

Activity diagram is basically a flowchart to represent the flow from one activity
to another activity. The activity can be described as an operation of the system.
The control flow is drawn from one operation to another. This flow can be
sequential, branched, or concurrent. Activity diagrams deal with all type of flow
control by using different elements such as fork, join, etc.

11
 Experiment -4

Aim : Identify the classes. Classify them as weak and strong classes and
draw the class diagram.

Class diagram is a static diagram. It represents the static view of an application.

Class diagram is not only used for visualizing, describing, and documenting
different aspects of a system but also for constructing executable code of the
software application.
Class diagram describes the attributes and operations of a class and also the
constraints imposed on the system. The class diagrams are widely used in the
modeling of object oriented systems because they are the only UML diagrams,
which can be mapped directly with object-oriented languages.

12
 Experiment-5

Aim : Draw the sequence diagram for any two scenarios.

Sequence diagrams describe interactions among classes in terms of an exchange

of messages over time. They’re also called event diagrams. A sequence diagram
is a good way to visualize and validate various runtime scenarios. These can
help to predict how a system will behave and to discover responsibilities a class
may need to have in the process of modeling a new system.

13
 Experiment 6

Aim: Draw the collaboration diagram.

14
 Experiment-7

Aim : Draw the state chart diagram.

16
 Experiment-8

Aim: Draw the component diagram.

Component diagrams are different in terms of nature and behavior. Component

diagrams are used to model the physical aspects of a system. Now the question
is, what are these physical aspects? Physical aspects are the elements such as
executables, libraries, files, documents, etc. which reside in a node.

Component diagrams are used to visualize the organization and relationships

among components in a system. These diagrams are also used to make
executable systems.

17
 Experiment-9

Aim: Draw the deployment diagram.

Deployment diagrams are used to visualize the topology of the physical

components of a system, where the software components are deployed.

Deployment diagrams are used to describe the static deployment view of a

system. Deployment diagrams consist of nodes and their relationships.

18