Software Requirements Specification

Software Requirements
Specification

Intra Mailing System

Arpit Pathak
Nidhi Deshmukh
Rutuja Ghate
Sanket Gupta

M.I.T.S
Page 1 of 17
Software Requirements Specification

Table of Contents
Table of Contents...........................................................................................................................2
1. Introduction..............................................................................................................................3
1.1 Purpose.......................................................................................................................................3
1.2 Document Conventions..............................................................................................................3
1.3 Intended Audience and Reading Suggestions.............................................................................3
2. Project Scope............................................................................................................................4
3. Overall Description..................................................................................................................5
3.1 Product Perspective....................................................................................................................5
3.2 Product Features.........................................................................................................................6
3.3 User Classes and Characteristics................................................................................................6
3.4 Operating Environment..............................................................................................................6
3.5 Design and Implementation Constraints.....................................................................................6
3.6 Assumptions and Dependencies.................................................................................................7
4. System Designing.....................................................................................................................8
4.1 Authentication............................................................................................................................8
4.1.1 Description and priority.........................................................................................................8
4.1.2 Functional Requirements........................................................................................................8
5. External Interface Requirements...........................................................................................9
5.1 User Interfaces............................................................................................................................9
5.2 Hardware Interfaces...................................................................................................................9
5.3 Software Interfaces.....................................................................................................................9
6. Other Nonfunctional Requirements.....................................................................................10
6.1 Performance Requirements.......................................................................................................10
6.2 Security Requirements..............................................................................................................11
6.3 Software Quality Attributes......................................................................................................11
7. Other Requirements..............................................................................................................11
Appendix A: Glossary..................................................................................................................11
Appendix B: Analysis Models.....................................................................................................12
Appendix C: Issues List...............................................................................................................13

M.I.T.S
Page 2 of 17
Software Requirements Specification

1. Introduction

1.1 Purpose

This document is intended for understanding the definition of requirements that are necessary for
the development of the intra mailing system.
This document act as basis for:
Common understanding between the two audiences regarding Specifications of the
intra mailing system project.
Needs to be satisfied in the architectural and detailed design of the intra mailing
system
Project.
Needs to be satisfied in the verification, validation and acceptance testing for the intra
mailing project.

1.2 Document Conventions

The format of this SRS is simple. bold face and indentation is used on general topics and specific
points of interest. The remainder of document will be written using the standard font, New Times
Roman.

1.3 Intended Audience and Reading Suggestions

This document is intended to be read by the developer team, project managers HCL group
Members, user SBIT.This is technical document and terms should be understood by the customer.

This SRS is designed for the persons present in this whole project so that they come to know about
project and what to change in the project in future if want, such as

Developers: As different modules of a project are developed by different members

of a team. So to have knowledge of other modules of the project SRS are designed. So that
an individual member of a team come to know about the whole modules of the project.

Project Managers: Members who are going to manage this project must know about the
project that’s why this SRS is designed. So that the members can manage the
project according to its design.

M.I.T.S
Page 3 of 17
Software Requirements Specification

Marketing Staff: What the developed software/project can do, what was its need, how it can
be helpful to the users all this information’s are provided to the marketing staff through this
SRS. Through that a good marketing can be provided to the project and its marketing price
will be good.

Users: Through this SRS the user come to know about the benefits of the project and how to
gain full performance from the project.

Testers: The different tests through which the software/project must undergo are described
in SRS.

Documentation writers: Different modules are designed by different members, so the

different logics are gathered together to develop a software/project. In that case entry of a
new member in the project will make him confused so through documentation one
can understand the logic behind that. So this document is intended for the
documentation writers also.

2. Project Scope

This document outlines the required functions that intra mailing system software is required
to perform. This document presents the detailed specification of each requirement and
these requirements are categorized by users and identified after careful analysis and requirements
gathering from the client. This document will not describe design decisions unless explicitly stated
by the client. This document will only describe what functionalities the system is required to
provide.

3. Overall Description
This section gives overview of current systems available in the market and
the product perspective of our intra mailing system when released into market.
3.1 Product Perspective:
This product is aimed at employees, students and every type of users. Whenever there is
limited space allowed on mail server, user can download mails on to hard disk and they will be
deleted from the mail server, which removes burden on Mail server. The project’s purpose is to
classify the mails into different clusters according to user’s criteria. At the end of the project, the
system will have its codes and functionalities reviewed, its mail management system and user
interface improved.
M.I.T.S
Page 4 of 17
Software Requirements Specification

Product Features

This system allows you to send Email messages, Work Order documents, Credit
Slips, Receivable Statements, and Purchase Orders - directly from within the software
- to any contact with an email address. Or you may simply type in an email address if
one is not recorded on a contact card.
The intra mailing system allows you to attach any number of computer files to an
email message, just as you can with most other email programs.
The most common use of this in the software will be to email exported reports. (The
software limits the total size of attached files to 5 MB.)
One can use the software's unique Preview tool to see how your message will look when the
recipient opens it in his email program.
The software errors and support requests may be sent directly to Customer Support
via email.
The software allows all workstations in one business Location to share one email account.

3.2 User Classes and Characteristics

This APPLICATION can be used by any user. There is no need of installation and one can use it on the basis
of WORLD WIDE WEB (WWW)..

3.3 Operating Environment

Hardware Platform: PROCESSOR: Intel Pentium IV

RAM: 256MB
HARDDISK: 40GB
LAN: High Speed up to 10 mbps

.
Software Components: PLATFORM : Windows
THE OPERATING SYSTEM : Windows XP Professional

FRAMEWORK : Framework 3.5

FRONT-END TOOL : JAVA NET BEANS
BACK-END TOOL : SQL SERVER

Design and Implementation Constraints

The items or options that will limit the options available to the developers are as follows:

M.I.T.S
Page 5 of 17
Software Requirements Specification

This software product supports user level security to access mails. There are two levels of
Authentication used in INTRA MAILING SYSTEM software.
At the first level of authentication user has to give his/her login and password so that he/she
will be able to access his/her set of mails on the hard disk, as it provides services to multiple
users.
At the second level of authentication, user has to give authentication details about the mail
account/accounts so that intra mailing system software access and downloads the mails from
the server using these authentication tokens.
This second level of authentication needs to be given for the first time, whenever user has
logged in as a new user or when ever new mail account is created on different Mail servers.
Where as first level of authentication needs to be given every time user uses INTRA
MAILING SYSTEM product, as it provides services to multiple users at the same time.

Design constraints on some of the files of the application are:

Algorithm constraint
The number of parameters used in the algorithm for classification is fixed. After
clear understanding of mail system, Neptune’s have come up with four such parameters.
Namely

A. Subject
B. From
C. To
D. Cc.

3.4 Assumptions and Dependencies

This project assumes that all the users have at least one valid email account.
This project assumes that the Users will enter valid authentication details to access mails.
This project assumes that the system is connected to network.

4. System Designing

M.I.T.S
Page 6 of 17
Software Requirements Specification
The designing of the project is done with the text based graphics which causes creation of
curses windows. User simply use mouse to control the basic functioning of project up to his/her
convenience.

M.I.T.S
Page 7 of 17
Software Requirements Specification

4.1 Authentication

4.1.1 Description and priority

This feature will give the user a secure and simple login making use of USER and PASS
commands. This will ensure whether the intend user can perform the task of file transfer or not.

4.1.2 Functional Requirements

The database must be in a workable state.
There should be secure password provided to each user or client
It should be easy for the no-vice user.
There should be proper interconnectivity between the files to allow communication.
Different commands for different functions will ensure reliability.

The most important thing is that the username for the administrator is fixed and the password
could be changed in future and must b of at least 6 character.

5. External Interface Requirements

5.1 User Interfaces

The intra mailing system has a simple User Interface which has the following components :-

1. User sign-in panel

For the user to login to access his/her set of mails on the hard disk, as the intra mailing system
provides services to multiple users.

2. New user Sign-up panel

To add a new user to the system.

3. Main panel
The main panel provides access point to the following services
Classifying the inbox mails

Reply the received mails

M.I.T.S
Page 8 of 17
Software Requirements Specification

Forward the received mails.

Delete the mails.

M.I.T.S
Page 9 of 17
Software Requirements Specification

To read Next mail.

To read the Previous
mail.

4. Composing mail panel.

Composing mail panel helps user to compose mails and send the mails .

5.2 Hardware Interfaces

In the hardware interface there is description of mouse implementation and keypad

implementation:

Mouse Implementation: When the user selects the SIGN_UP or SIGN_IN selection he/she has to
perform all the selection through the mouse. In this the concept of mouse is introduced.

Keypad Implementation: When the user selects the any of the option he/she has to perform all the
operation through pressing key described in it present on the keyboard.

These are the hardware interfaces which the user must know while performing the request.

5.3 Software Interfaces

Database: In this the record is stored in Mysql database. There are basically 1database and
that one database is containing the record of all users..

Operating System: This project will work on WINDOWS XP/7/VISTA.

Header Files Used: The header files used are described below:

All these are included in the software interface.

import java.sql.*; //FOR DATABASE
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.Statement;
import java.sql.PreparedStatement;

6. Other Nonfunctional Requirements

M.I.T.S
Page 10 of 17
Software Requirements Specification

6.1 Performance Requirements

The intra mailing system should be able to support multiple users at a time.
6.2 Security Requirements

The intra mailing system does not allow users to view other user’s details for privacy
and security reason.

6.3 Software Quality Attributes

This application can be used in all sectors where the file transfer is an important task to be
performed.some of its quality attribute includes:-

1. Checking:- Authentication Checking: With this checking, the system will not
allow
Unauthorized user to perform functionalities that he/she does not allowed to do.

2. Portability: - The intra mailing system must be portable between Microsoft Windows and
Linux. Both intranet and internet version of the intra mailing system should be portable.

3. Maintainability:- The intra mailing system should be modular. Specifically, file

contents should be easy to maintain as the contents of the database change often.

4. Performance:- The intra mailing system should be able to support multiple users at a time.

7. Other Requirements
The other requirement related to this SRS is not needed. The different appendixes are given. In case of
more knowledge related to this SRS one can concern with these Appendixes.

Appendix A: Glossary
The definition of the words that are frequently used in this SRS is as follows:
Client – one who uses the project

Database- In which data is stored

DFD- Data Flow Diagram

M.I.T.S
Page 11 of 17
Software Requirements Specification

Mysql- A basic database already present in many s/w.

Hardware- That can be touch

Interface- through which client send request

Server- that serves request

Software- That can be seen not touch

Appendix B: Analysis Models

a) Use Case ID : 1
Use Case Name : Download emails

1. DESCRIPTION
This use case describes the process of downloading the emails from the server.

2. ACTORS
2.1 Primary Actor - User.
2.2 Secondary Actors - User’s mail server.

3. USE CASE DIAGRAM

M.I.T.S
Page 12 of 17
Software Requirements Specification

4. STEPS

4.1 User provides username and password to download mails from server.
4.2 If username or password wrong system reports error.
4.3 User gives Check Mail command
4.4 System copies Mails from server to user’s hard disk.
4.5 System deletes mails from server.

b) Use Case ID : 2
Use Case Name : Sending emails

1. DESCRIPTION
This use case describes the process of sending emails.

2. ACTORS
2.1 Primary Actors - User.
2.2 Secondary Actors - Recipient’s mail server.

3. USE CASE DIAGRAM

M.I.T.S
Page 13 of 17
Software Requirements Specification

4. STEPS

4.1 If user gives Compose mail command.

4.1.1 User gives compose command
4.1.2 Types subject.
4.1.3 Types contents.
4.1.4 Specifies recipients.
4.1.5 Gives send command.
4.1.6 If (Recipient’s Mail Server receives mail successfully)
mail sent else report problem

4.2 If user gives reply command

4.2.1 Edits subject.
4.2.2 Edits contents.
4.2.3 Adds recipients.
4.2.4 Give send command.
4.2.5 If (Recipient’s Mail Server receives mail successfully )
mail sent
else report problem

4.3 If user gives forward command

4.3.1 Edits subject.
4.3.2 Edits contents.
4.3.3 Specifies recipients.
4.3.4 Give send command.
4.3.5 If(Recipient’s Mail Server receives mail successfully )
mail sent
else report problem

c) Use Case ID : 3
Use Case Name : Attachments

M.I.T.S
Page 14 of 17
Software Requirements Specification

1. DESCRIPTION
This use case describes the process of sending and receiving the attachments from
an email.

2. ACTORS
a. Primary Actors - User.
b. Secondary Actors - NA.

3. USE CASE DIAGRAM

4. STEPS

4.1. Sending Attachments.

4.1.1 System must allow user to search the file to attach.
4.1.2 Intra mailing system should display the list of files on user’s machine.
4.1.3 System must allow user select the file to attach.
4.1.4 Attached file also sent with the mail.

4.2 Downloading Attachments.

4.2.1 System must allow user to download attachment to his machine.
4.2.2 Intra mailing system must allow user to save attachment to desired path in his machine.

d) Use Case ID : 4
Use Case Name: Mail Classification System

M.I.T.S
Page 15 of 17
Software Requirements Specification

1. DESCRIPTION:
Classify emails based on similarities. Store similar mails in a separate folder. Mails not belonging
to any group are left in common folder inbox.

2. ACTORS:
a. Primary Actor: User
b. Secondary Actor: NA

3. USE CASE DIAGRAM:

4. STEPS:

1. User gives classify command

2. Classification algorithm applied to all mails.
3. Groups suggested to users.
4. Similar mails moved to a common folder.
5. Mails not falling in any group left in common folder called inbox.

e) Use Case ID : 5
Use Case Name : Sign In

1. DESCRIPTION
This use case describes how a registered user can sign in to the system.

2. ACTORS
2.1 Primary Actors - User.
2.2 Secondary Actors - N/A

3. USE CASE DIAGRAM

M.I.T.S
Page 16 of 17
Software Requirements Specification

4. STEPS

4.1 System must ask username and password of a user.

4.2 System must verify the right combination of username and password.
4.3 System should report Sign-In problem if verification fails.
4.4 On successful Sign-In system should allow user access to his / her mails.

f) Use Case ID : 6
Use Case Name : Sign Up

1. DESCRIPTION
This use case describes the how an unregistered user can sign up to the system.

2. ACTORS
2.1. Primary Actors - User.
2.2. Secondary Actors - N/A

3. USE CASE DIAGRAM

4. STEPS

M.I.T.S
Page 17 of 17
Software Requirements Specification

4.1 The system must ask the username and password (in duplicate) from a new user.
4.2 The system must save the combination of username and password of the new user.
4.3 System should Sign-In the new user.

g) Use Case ID : 7
Use Case Name : Display Emails

1. DESCRIPTION
This use case describes the process of displaying the mails of an user when he signs in .

2. ACTORS
2.1. Primary Actors - User.
2.2. Secondary Actors-N/A

3. USE CASE DIAGRAM

4. STEPS

4.1 System must display the mails of a particular folder selected by the user.

h) Use Case ID : 8
Use Case Name : Store Emails

1. DESCRIPTION
This use case describes the process of storing the mails of user in a directory specific
to the user.

2. ACTORS
2.1 Primary Actors - User.
2.2. Secondary Actors - Recipient’s mail server.

M.I.T.S
Page 18 of 17
Software Requirements Specification

3. USE CASE DIAGRAM

4. STEPS

4.1 System must store the mails of each user separately .

4.2 System must store mails part of a group in the folder corresponding to the group.

Appendix C: Issues List

The issue on which the work is remaining is as follows:

Security concept
Add the keypad functioning also in the user interface
Performance should be increased.
These three are main and there are some more concepts on which work is pending not described
here.

M.I.T.S
Page 19 of 17