A SDS

On
ONLINE EVENT MANAGEMENT
Submitted for the partial fulfillment for the award of the degree of

Master of Computer Application

Submitted by:
Project Group ID –MCAL13

Muskan Verma (18389)

Neha Jalan (18389)
Nidhi Goyal (18390)
Richa Tak (18403)

Under the supervision of

Mrs Divya

Banasthali University

Department of Computer Science

Banasthali Vidyapith
Banasthali– 304022
Session: 2019-20
TABLE OF CONTENTS

1. Introduction
1.1 Purpose ……………………………………………………Page No
1.2 Scope………………………………………………………Page No
1.3 Terms, Definitions, Acronyms and Abbreviations………..Page No
1.4 Overview of Document ……..……………………………..Page No

2. System Architectural Design

2.1 High Level Design Overview…………………………….. Page No

2.2) Detailed Description of Components

2.2.1 Structure Chart …………………………………... Page No

2.2.2 Data Flow Diagram………………………………………. Page No

3. Data Design

3.1 Database Description…………………………………Page No

3.2 E-R Diagram…………………………. ………………… Page No

4 User Interface Design

4.1Detailed Description of Components……………………… Page No

4.2 Screen images

5. TYPES OF TESTS (With Implementation)................................................. Page No

6. Appendices

7. References
Note: In Structured Approach
Data flow diagram (DFD) and Structure chart
In Object-Oriented Approach (OO)
Use Case, Use Case diagram, Class diagram, Activity diagram and
Sequence chart.
1. Introduction

The following subsections of the Software Design Specifications (SDS) document should
provide an overview of the entire SDS. The thing to keep in mind as you write this
document is that you are telling what the system must do – so that designers can
ultimately build it. Do not use this document for design!!!

1.1 Purpose

 The SDS shows how the software system will be structured to satisfy the
requirements identified in the SRS.
 It is a translation of requirements into a description of software structure,
software components, interfaces and data necessary for the
implementation phase.
Thus, SDS is the blue print for the implementation activity.

1.2 Scope

The purpose of the website is to provide the user with an interface which can procure
several laptops on the same platform rather than moving to discrepant websites with a
friendly graphical user interface.

 Registration of the admin.

 Registration of the customer.
 Login/logout.
 Admin will upload/delete/update laptops for customers.
 Customers will view/select/buy the laptops.
 Customers can have their product post in their provided address.
Two types of users will be using this application .Users can be Customer, Admin. All the
users will have different access and rights granted by this application.

1.3 Definitions, Acronyms, and Abbreviations.

 Admin- Administrator
 DFD- Data Flow Diagram
 IIS- Internet Information Services
 CSS-Cascaded Style Sheet
 SQL- Structured Query Language
 E-R Diagram- Entity Relationship Diagram
1.4 Overview
The rest of the SDS consists of the following parts:-

 System Architecture Design includes High Level Design, Structure Chart &
DFD.
 Data Design includes Database Description.
 Detailed Description of Components.
 User Interface Designs.
 Testing Strategies.

2. System Architectural Design

This section is the main focus of the high-level conceptual design. The reader should
come away with a good view of exactly how your solution is to be organized.

2.1 High-level Design Overview

Introduce the various components and systems at a high conceptual level.

A Pictorial representation of the system architecture is presented.

User
1-TIER

INTERNET

Web Server

(IIS with ASP.NET 2-TIER

run time)

3-TIER
SQL Server
2.2 Detailed description of components
This section is the main focus of the technical design portion of the SDS, the detailed design.
This section will provide most of the basis for implementing the product.

A detailed description of each software component contained within the architecture is

presented. A description of each major software function along with:

In Structured Approach-

Data flow diagram (DFD) and Structure chart

In Object-Oriented Approach (OO)-

Use Case, Use Case diagram, Activity diagram.

Component and interface description.

A detailed description of the input and output interfaces for the component is presented.

Component n processing detail

A detailed algorithmic description for each component is presented. A diagram showing the flow
of information through the function and the transformation it undergoes is presented:
2.2.1 use case diagram
1.Admin
LOGIN

INSERT

VIEW

DELETE

MODIFY

LOGOUT
2.CUSTOMERS
SEARCH

REGISTER

LOGIN

VIEW

INSERT

MODIFY

LOGOUT

2.2.2. ACTIVITY DIAGRAM

1.Login
HOME PAGE

(ONLINE EVENT MANAGEMENT)

ENTER USER NAME

AND PASSWORD

LOGIN

EVENT DETAILS
 3.New user

HOME PAGE

REGISTER HERE

REGISTRATION FAILED LOGIN

EVENT DETAILS

4.ADMIN HOME PAGE

LOGIN AS
ADMIN

LOGIN INSERT VIEW DELETE MODIFY LOGOUT

END
3 Data design
This subsection will make clear the interrelationships and dependencies between
modules/layers/components. Structure charts can be useful here. Another good idea is to use a
simple finite state machine that demonstrates the operation of the product you are designing.
There should always be explanatory text to help the reader understand any charts.

3.1 Database description

Database(s) created as part of the application is (are) described. E-R Model should clearly
specify the data entities and relationship between them. After normalization, each table must be
described with purpose, methods using it, all its fields description, their data type, and integrity
constraints.

3.2 E-R Diagram

3.3 Database
A description of all data structures including internal, global, and temporary data structures.

Temporary data structure

Files created for interim use are described.

USER TABLE

Purpose: This table is used for storing all details related to user.

Field Type Description Constraints

User_id number Id representing a NOT NULL

user.

Name Varchar(40) Name of the user

E-mail id Varchar(10) E-mail id of the

user.

Address Varchar(30) Address of the

user.

Username Varchar(50) Username of the

user for accessing
his account.

Password Varchar(30) Password of the

user’s account.

Primary key: User_id

EVENT TABLE
PURPOSE: This table provides details regarding the events.

Field Type Description Constraints

E_id number Id representing a NOT NULL

event.

E_Name Varchar(40) Name of the

event.

E_Price Varchar(10) Price of the event.

E_Model Varchar(30) Model of the

event.

Primary key: E_id

Payment Table

PURPOSE: This table provides details regarding the payment of the laptops by customers.

Field Type Description Constraints

Pay_id number Id representing a NOT NULL

event whose
payment is done.

Amount Varchar(40) Amount paid by

user.

Pay _type Varchar(10) Type of the

payment done by
the user.
Primary key: Pay_id

4 User Interface Design

A description of the user interface design of the software is presented.

4.1 Description of the user interface

A detailed description of user interface including screen images or prototype is presented.

4.2 Screen images

Representation of the interface form from the user's point of view.

For Example –
Log in image

5. TYPES OF TESTS (With Implementation)

Unit Tests
Unit tests are most commonly done by developers on their own machines or on a common server
that is very volatile. It is not necessary that the unit test machines be the same platform and
operating system as the target deployment environment, but the movement from the unit test
environment to other testing environments should not require material code changes by
developers. A plan for one machine per developer plus one small server should be included in
the overall system architecture.

System Tests
The system test environment allows multiple modules to be connected together and executed as
in a typical use-case scenario. The choice as to whether this is done on a separate machine from
unit testing is up to the implementation and test team. If the target deployment environment is
different from the unit test environment, the system test environment should contain a machine
that matches the target environment. Although the system test machine need not match the size
of the deployment box, it should have the same platform and operating system. A good rule of
thumb is to prepare to add one more box for system tests of a smaller size, but the same
operating system as the target environment. Again, this will be a relatively volatile environment,
so it should not be viewed as a place to do industrial-strength testing by a large team.
Integration or Regression Tests
To perform integration and regression tests, it is advisable to have a separate environment that is
similar to the target environment. Generally, one server will be enough at this point. However,
the contents of this server should be strictly controlled. Either the test coordinator or his or her
designate should make all software changes to this environment. Stability and auditability are
essential to ensuring the accuracy of test results. Plan for at least one more servers at this stage in
testing.

Stress Tests
Stress tests should be done in an environment identical to the target hosting environment. In the

first development cycle, this can be done in the production site, before the cutover to production.

For subsequent development cycles, a separate environment will have to be maintained for stress

testing.

Plan to replicate the deployment environment as part of the test bed for at least the second
development cycle of the site. It has also been observed that the most common problem after
performance in a high stress environment is database deadlock due to improper programming.

Deadlocks are typically difficult to detect and fix and may not show up until the site is highly
stressed in production. So it is important that these conditions be stringently tested during the

stress test phase.

Acceptance Tests and Staging

Acceptance tests are generally performed in the same environment as the stress tests, so
additional hardware is not needed to support this phase of testing. Again, during the initial
development cycle, the production environment can be used to perform both acceptance testing
and staging, but a new environment should be created for subsequent development cycles.

6. Appendices

7. References
In this subsection:

(1) Provide a complete list of all documents referenced elsewhere in the SRS
(2) Identify each document by title, report number (if applicable), date, and publishing
organization
(3) Specify the sources from which the references can be obtained.

This information can be provided by reference to an appendix or to another document. If your

application uses specific protocols or RFC’s, then reference them here so designers know where
to find them.