Vous êtes sur la page 1sur 51

1

IEEE Std 830-1998



(Revision of IEEE Std 830-1993)




Software Requirements Specification


E-Mail Tokri


October 5, 2004

$Revision 2.0$









C


2







Maintained by: NEPTUNE TEAM MEMBERS

Names Mail-Id

KAMLESH HALDER (TL) h2003453@bits-pilani.ac.in
K VIJ AYANANDA REDDY h2003445@bits-pilani.ac.in
NEELESH DESHPANDE h2003447@bits-pilani.ac.in
RAJ EEV GAUR h2003448@bits-pilani.ac.in
ASHISH GANDHI h2003449@bits-pilani.ac.in
SHILADITYA BOSE h2003450@bits-pilani.ac.in
GUDA KIRAN KRISHNA h2003451@bits-pilani.ac.in
ANANTHARAM G h2003452@bits-pilani.ac.in
SUNIL PAHLAJ ANI h2003454@bits-pilani.ac.in






3

ABSTRACT

This document describes the functional and non-functional requirements and
preliminary analysis of E-Mail Tokri project. It is aimed to provide a brief description of
the project and to provide as a reference for both the Client and The Neptune Team.


Software requirement specification (SRS)
A document describing the requirements of a software system from the user's point
of view.
An SRS document specifies:
The required behavior of a system in terms of input data, required processing,
output data, operational scenarios and interfaces and
The attributes of a system including performance, security, maintainability,
reliability, availability and safety requirements and design constraints.
Alias: user requirement specification, functional specification




4
Contents

1 Introduction 8
1.1 Introduction .. 8
1.2 Documents Purpose..................... 8
1.3 Documents Scope ... 9
1.4 Definitions ... 9
1.5 Acronyms . 10
1.6 Documents Overview . 11
1.7 Client Contact Details ..................... 12
1.8 References 12

2 Overall Description 13
2.1 Overview of Current System ... 13
2.2 Product Perspective . 14
2.3 Project Scope ... 14
2.4 Product Functions. 14
2.5 User Characteristics . 17
2.6 Constraints ... 18
2.7 Assumptions and Dependencies .. 19

3 User Interface Requirement 20
3.1 E-Mail Tokri user Login panel 20
3.2 E-Mail new user sign-up panel 21
3.3 Main E-Mail Tokri panel ... 22
3.4 File menu . 24
3.5 Action Menu . 25
3.6 My Mail Menu .. 26
3.7 Configuration Panel .. 27
3.8 Compose Mail panel . 29
3.9 Mail Reply Panel .. 30
3.10 Forward Mail Panel 32

4 Specific Requirements 33
4.1 General Functionality Requirement.. 34
4.1.1 Download E-Mails 34
4.1.2 Sending E-Mails 34
4.1.2.1 Compose E-Mail . 35
4.1.2.2 Reply To Received E-Mail . 35
4.1.2.3 Forward E-Mail .. 35


5
4.1.3 Attachments .. 36
4.1.3.1 Sending Attachments .. 36
4.1.3.2 Downloading Attachments . 36
4.1.4 File Management ... 37
4.1.4.1 Sign-In .... 37
4.1.4.2 Sign-up 37
4.1.4.3 Display user specific mails.. 37
4.1.4.4 Store Mails corresponding to a user ... 37
4.1.5 Mail Classification . 37
4.1.5.1 Finding Similarities 37
4.1.5.2 Forming Groups . 38
4.1.5.3 Creating Mail Groups .. 38
4.1.5.4 Non Similar Mails to Inbox 38
4.1.5.5 Automatic Mail Classification 38
4.1.5.6 Re-Classification ... 38
4.1.5.6.1 User acceptance for new group after reclassification .. 38
4.2 Non-Functional Requirements . 39
4.2.1 Checking ... 39
4.2.2 Security . 39
4.2.3 Portability . 39
4.2.4 Maintainability .. 39
4.2.5 Performance .. 39

5 Design Constraint 40
5.1 System Side ... 40
5.1.1 Hardware Constraints 40
5.1.2 Software Constraints . 40

6 Product Acceptance Criteria 41

Appendix A 42

Appendix B 50


6

List of Tables

1 Definition 9
2 Acronyms .... 10


7

List of Figures

1 E-Mail Tokri Network Diagram .. 13
2 Mail Classification .. 16
3.1 User Login Panel .. 20
3.2 New User Sign-up panel ... 21
3.3 Main Panel 22
3.4 File Menu . . 24
3.5 Actions Menu 25
3.6 My Mail Menu .. 26
3.7 Configuration Panel .. 27
3.8 Compose Mail Panel . 29
3.9 Mail Reply Panel .. 30
3.10 Forward Mail Panel 32



8
1 Introduction:

This section gives a detailed introduction of E-Mail Tokri and a brief description of
document purpose and documents scope

1.1 Introduction

E-Mail Tokri is an automatic mail classification tool. Once properly set up and
trained, it will scan all e-mails as they arrive and classify it based on your training. You
can give it a simple job, like separating out junk e-mail, or a complicated onelike filing
mail into a dozen folders .E-Mail Tokri download mails from the Mail server and
promises to increase ease of dynamically classifying the mails into different clusters
according to users criteria. Think of it as a personal assistant for your inbox.

This product is outcome of Software Engineering course project by Neptunes team.
Hence your contribution of valuable comments and suggestions are most welcome, so
that we can improve on present version and release next version of the product into the
market.

1.2 Documents Purpose

This document is intended for understanding the definition of requirements that are
necessary for the development of the E-Mail Tokri.

This document act as basis for:

Common understanding between the two audiences regarding
Specifications of the E-Mail Tokri project.

Needs to be satisfied in the architectural and detailed design of the E-Mail
Tokri Project.

Needs to be satisfied in the verification, validation and acceptance testing
for the E-Mail Tokri project.



9
1.3 Documents Scope

This document outlines the required functions that E-Mail Tokri software is required
to perform. This document presents the detailed specification of each requirement and
these requirements are categorized by users and identified by the Neptunes 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. Implementation details will be
described in the SDD document.

1.4 Definitions

This section lists all definitions used through out this document.


E-Mail Tokri E-Mail Tokri is an automatic mail classification tool. Once properly
set up and trained, it will scan all e-mails as they arrive and classify
it based on users training.

Classifier Dynamically classifying the mails into different clusters according
to users criteria.

Mail Group Group wise Mail Distribution Grouping the similar class of mails
into one folder.

Clustering Collection of mails with the same field properties.

Mail downloading Downloading mails into hard disk and simultaneously deleting
those mails from mail server database.


Table 1: Definitions







10
1.5 Acronyms

This section lists all acronyms used through out this document.

.
SRS Software Requirement Specification

SDD Software Design Details.

J DK J ava Development Kit

CVS Concurrent Version System

UML Unified Modeling Language

UI User Interface

MVM Microsoft Virtual Machine

MD5 Message Digest 5

SMTP Simple Mail Transfer Protocol

POP3 Post Office Protocol


Table 2: Acronyms


11
1.6 Documents Overview

This document has 6 sections:

1. Introduction

This section of the document contains a brief summary of the product to be
developed. This section includes the purpose and audience of this document, the project
scope, list all the definitions and acronyms used in this document. Generally, it gives the
readers a preview of the documents contents.

2. Overall Description

This section of the document describes the high-level overview of the product, its
environment, anticipated users and all known assumptions and dependencies.

3. User Interface Requirements

This section describes the basic user interface in the E-Mail Tokri. Further details of
the UI of the system such as the tables and layout will be described in the SDD.

4. Specific Requirements

This section of the document describes all requirements comprehensively.
This section includes:
(a) Functional Requirements
(b) Non-functional Requirements

5. Design Constraints

This section of the document will list all the minimum software and hardware
constraints needed to implement the system.

6. Product Acceptance Criteria

This section of the document outlines the crucial criteria that needs to be implemented
before the product can be considered finished by the client.




12
1.7 Client Contact Details

The client for this project is:
Name: Vijaya Ganesh Varadarajan
Email: vganesh@prithvi.bits-pilani.ac.in

1.8 References

Ian Sommerville., Software Engineering :6th Edition ,Pearson Education.
IEEE Standard 830-1993, "IEEE Recommended Practice for Software
Requirements Specifications"
Phillips, D.: The Software Project Manager's Handbook, IEEE Computer Society,
2000
Pressman, Roger S., software Engineering: A Practitioners Approach_,4th Ed,
McGraw-Hill.






















13
2 Overall Description: C

This section gives overview of current systems available in the market and the
product perspective of the E-Mail Tokri when released into market.

2.1 Overview of Current System

E-Mail Tokri is an automatic mail classification tool. Once properly set up and
trained, it will scan all e-mails as they arrive and classify it based on your training. The
current system provides functions of E-mail management users. Below is the diagram of
the E-Mail Tokri we are developing.

Figure 1: E-Mail Tokri Network Diagram



14

One powerful software available to the customer today is Outlook Express. In the
Internet domain it enables user to download mails from the Mail server; this standards
based model reduces burden on server by using POP3 protocol and deleting the mails
from the mail server after it downloads mails on to the hard disk .The main drawback of
this product is it lacks in dynamic mail classification.

The main purpose of E-Mail Tokri is to overcome the drawback of above system and
provide simple interface to user which uses POP3 protocol to download mails from the
Mail server and promises to increase ease by dynamically classifying the mails into
different clusters according to similarity factor among the mails. Like, the user will be
able to classify Spam mails into one folder from the set of mails receive or a complicated
job like filing mail into a dozen of folders, clustering the mails into one folder, which are
having same similarity factor. Where the similarity factor is a non static statistical value
calculated on the basis of fields considered for classification.

2.2 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
projects purpose is to classify the mails into different clusters according to users
criteria. At the end of the project, the system will have its codes and functionalities
reviewed, its mail management system and user interface improved.
2.3 Project Scope

The project will mainly focus on the Mail classification versions.

2.4 Product Functions
E-Mail Tokri System

E-Mail Tokri system can be broadly classified into 4 different parts




15

2.4.1 Mail System (Sending & Receiving Mails)
The Mail system is used for sending and receiving mails to and
from the mail server. Like the steps followed to send a mail are
1. User gives compose command
2. Types subject.
3. Types contents.
4. Specifies recipients.
5. Give Send command.
6. If(Recipients Mail Server receives mail successfully ) mail sent else report
problem .

2.4.2 User Interface

E-Mail Tokri 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 E-
Mail Tokri 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
Forward the received mails.
Delete the mails.
To read Next mail.
To read the Previous mail.


16

4. Composing mail panel.

Composing mail panel helps user to compose mails and send the mails .
2.4.3 Mail Classification System

Figure 2. Mail Classification System

The main function of mail classification system is to classify the mails of user inbox
into different clusters depending on the similarity. From the above diagram we see that
user1 inbox mails are classified into different folders after user gives classify command.
All most all the inbox mails having similar fields are clustered together and different
folder like BITS, Movies, Intel, Tom are created containing one clusters each and the
remaining mails which are not clustered are left in inbox only. The classification
algorithm considers the main four fields (to, from, subject, Cc) to classify the mails into
different folders.



17
2.4.4 File Management System

The main functions of the file management system can be broadly classified into 4
parts.

1. Storing authentication details of the user and providing security to users

File is maintained to store logins and passwords of different users using MD5
algorithm. As E-Mail Tokri provides services to multiple users, authentication regarding
the login has to be maintained so that users will not able to access other users mails. This
is the minimum security that the user is guaranteed.

2. Creation of Directories based on users

For each user a directory is created .When user gives download command all the
mails from the mail server are stored into users directory.

3 Storing group wise mail.

When user gives classification command the mails are grouped and stored into
different folders corresponding to various groups.

4 Storing the authentication details of users mail accounts.

A file is maintained in users directory regarding the users Mail server configuration
details to access his/her account on the Mail server.

2.5 User Characteristics

The users of E-Mail Tokri are:

All the users can use this product; there is no specific user hierarchy level to access it.
This software product supports user level security to access mails. There are two levels of
authentication used in E-Mail Tokri 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 E-Mail Tokri
provides services to multiple users.


18

At the second level of authentication, user has to give authentication details about the
mail account/accounts so that E-Mail Tokri 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 E-
Mail Tokri product, as E-Mail Tokri provides services to multiple users at the same time.

2.6 Constraints

2.6.1 Hardware Constraints

Minimum hardware requirements for E-Mail Tokri to function properly are the following

1. Processor: Intel based 166 MHz
2. RAM: 128 MB
3. Hard-disk space: 4 Gb
4. Networking: Ethernet 10/100.
5. GUI support needed.

2.6.2 Software Constraints

E-Mail Tokri is targeted towards the following platforms:

1. Operating System: Windows or *NIX.
2. Interpreter: MVM

2.6.3 Algorithm constraint

The number of parameters used in the algorithm for classification is fixed. After
clear understanding of mail system, Neptunes have come up with four such


19
parameters. Namely

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

Using fixed number of words, a minimal dictionary based method for token
matching for classification is used.

Format to be followed for subject field of the mail is fixed. Only the first section
of the subject field is considered during classification. It would lead to easier
classification.
Ex:- Business:01-Rams. Only the Business field of the string will be considered.

Algorithm does not support user based criteria for classification.
.

2.7 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.

















20
3.User Interface Requirement: C

This section describes some of the major user interface in the Neptunes E-Mail
Tokri. A further detail of the UI of the system such as the tables and CSS layout will be
described in the SDD.
3.1E-mail Tokri User Login Panel


Figure 3.1: User Login Panel
The diagram represents the user login panel of E-Mail Tokri. Major things on the
user login panel are:

Label of the software and logo: The first panel of the software identifies the
software name and logo.

User name Text Field: A text field is there for entering the Username required for
the login into the software.



21
Password Text Field: A text field is there for entering the Password required for
the login into the software. The password is into a hidden form from the user i.e.
only stars appear instead of characters.

Sign-In Button: To Log into the software.

Sign-Up Button: If the user is new he can sign up and have his/her password
registered with the software. This button will take user to a new User Sign Up
panel.
3.2E-mail Tokri New User Sign-Up Panel



Figure 3.2: New User Sign-Up Panel
The diagram represents the user login panel of E-Mail Tokri. Major things on the
user login panel are:

Label of the software and logo: This identifies the software name and logo.


22

User name Text Field: A text field is there for entering the Username required
for the login into the software.

Password Text Field: A text field is there for entering the Password required for
the login into the software. The password is into a hidden form from the user i.e.
only stars appear instead of characters.

Re-Enter Password Text Field: Another text field for entering the Password
required for the login into the software. This should be same as the Password.
The password is into a hidden form from the user i.e. only stars appear instead of
characters.

Sign Up Button: If user presses this button, he/she will be registered. This button
will take user to the main panel of the software.
3.3Main E-mail Tokri Panel


Figure 3.3: Main Panel


23

The diagram represents the main panel of E-Mail Tokri. Major things that can be
found on the main panel are:

Menu bar consist of File, Action and My Mail Menus. These menus will be
described in the subsequent interfaces.

My Folder Panel. This folder describes all the user-defined folders including
the default Inbox. The folders will contain all the classified mails clustered
together excluding Inbox which contain all the default mails downloaded from
mail server.

My Mail Panel. This Panel consist of the following components:

o Classification Button: This button provides the functionality of
classifying mails. More details of this component is given in the
subsequent panels.

o Reply Button: The button provides the functionality of replying an email.
Whenever clicked it will pop up the mail selected from the Email list
table and display the Mail Reply Panel. The detail of Mail Reply Panel is
given in 3.9.

o Forward Button: The button provides the functionality of forwarding an
email. Whenever clicked it will pop up the mail selected from the Email
list table and display the Forward Mail Panel. The detail of Forward Mail
Panel is given in 3.10.

o Next Button: The button provides the functionality of moving from one
mail to the next immediate mail. If the mail is the last one it will show
the first mail from Email list table.

o Previous Button: The button provides the functionality of moving from
one mail to the previous immediate mail. If the mail is the first one it will
show the first mail only from Email list table.

o Delete Button: The button provides the functionality of deleting the mail
as selected in the Email list table. If no mail is selected the deletion will
not be performed. After deletion, the next subsequent mail is selected and
displayed in Body panel.



24
o Email List table: This list will display all the mails from the selected
folder from My Folder Panel. By default, it will show the mails from
Inbox. The list is single item selected i.e. only mail can be selected for
viewing. The list has a scroll bar to scroll up and down the mails.

Body Panel. This Panel consists of only one component display area to display
the mail as selected from the Email List table as described as above. The display
area has horizontal and vertical scrollbars that is enabled only if required by the
display editor.


3.4 File Menu




Figure 3.4: File Menu



25
The diagram represents the File Menu of E-Mail Tokri. The submenus that are
included in the menu and their functionality are as follows:

My Settings Menu: This menu will pop up a Configuration Panel for all the
configuration settings for E-Mail Tokri. The configuration is used for all the
connection management of the users mail management system.

Close Men: This menu will close down the E-Mail Tokri application.

3.5 Actions Menu.



Figure 3.5: Actions Menu

The diagram represents the Actions Menu of E-Mail Tokri. The submenus that are
included in the menu and their functionality are as follows:



26
Download Mails Menu: The menu is used for initiating contact with the user
mail server and downloads all the mails from server to the hard disk. The
application makes use of the configuration details as provided by the user in the
configuration Panel.

Compose Mail Menu: This menu will pop up a Compose Mail Panel for
composing mails. The details of the panel will be described later.


3.6 My Mail Menu



Figure 3.6: My Mail Menu

The diagram represents the Actions Menu of E-Mail Tokri. The submenus that are
included in the menu and their functionality are as follows:



27
Reply Menu: The function of this menu is same as the Reply Button component
as described in the My Mail Panel Reply Button (3.3).

Forward Menu: The function of this menu is same as the Forward Button
component as described in the My Mail Panel Forward Button (3.3).

Next Menu: The function of this menu is same as the Next Button component as
described in the My Mail Panel Next Button (3.3).

Previous Menu: The function of this menu is same as the Previous Button
component as described in the My Mail Panel Previous Button (3.3).

Delete Menu: The function of this menu is same as the Delete Button component
as described in the My Mail Panel Delete Button (3.3).
3.7 Configuration Panel


Figure 3.7: Configuration Panel


28
The diagram represents the Configuration Panel of E-Mail Tokri. The following are
the details of the configuration Panel:

POP Server Text field: User has to provide the mail POP3 server address. The
address should be in proper format. The format can be standard IP address of
mail server or the standard server domain name. POP3 is Post Office Protocol
used for downloading mails from server to the user hard disk.

SMTP Server Text field: User has to provide the mail SMTP server address. The
address should be in proper format. The format can be standard IP address of
mail server or the standard server domain name. SMTP is Simple Mail Transfer
Protocol for sending mails. The POP3 address and SMTP address can be same.

Username Text field: User has to provide the username for accessing mail server.
Username is used while downloading mails.

Password Text field: User has to provide the password for accessing mail server.
Its use is same as that of Username.

Reply Address: User can provide the reply address of himself. The Reply
Address is used for Mail Reply Panel and Forward Mail Panel. The details of the
respective panels are given further below panels.

OK Button: The button component provides the functionality to update the
changes filled by the user. The configurations are subsequently updated and the
Configuration Panel is closed.

CANCEL Button: Configuration Panel is closed without any modification of the
configuration details.














29
3.8Compose Mail Panel.


Figure 3.8: Compose Mail Panel

The diagram represents the Compose Mail Panel of E-Mail Tokri. The following are
the details of the Compose Mail Panel:

To Text field: This is the Email address of the receiver. User has to give only one
email address here. The email address should be in proper format. For example:
h1975243@prithvi.bits-pilani.ac.in.

From Text field: This is the Email address of the sender. User has to give only
one email address here. The email address should be in proper format. For
example: h1975243@prithvi.bits-pilani.ac.in.

Cc Text field: This is the Email address of the secondary receiver. A secondary
receiver is the receiver who will get a carbon copy of the mail. User has to


30
supply only one email address here. The email address should be in proper
format. For example: h1975243@prithvi.bits-pilani.ac.in.
Subject Text field: User can specify any subject matter here.

Body: The body provides the editor to compose the mail message. No cut paste
commands are provided and the user is able to type all simple types of messages.

SEND Button: The button component provides the functionality to send the
message to the respective To Receiver and Cc Receiver. The Compose Mail
Panel is subsequently closed.

3.9 Mail Reply Panel



Figure 3.9: Mail Reply Panel




31
The diagram represents the Mail Reply Panel of E-Mail Tokri. The following are the
details of the Mail Reply Panel:

To Text field: This is the Email address of the receiver. The Email address is the
same as the FROM Email address from the mail selected from Email List table.
The email address should be in proper format. For example:
h1975243@prithvi.bits-pilani.ac.in.

From Text field: This is the Email address of the sender. By default, the Reply
Address is set to as provided by the user in the Configuration Panel. The email
address should be in proper format. For example: h1975243@prithvi.bits-
pilani.ac.in.

Cc Text field: This is the Email address of the secondary receiver. A secondary
receiver is the receiver who will get a carbon copy of the mail. User has to
supply only one email address here. The email address should be in proper
format. For example: h1975243@prithvi.bits-pilani.ac.in.

Subject Text field: Subject field is set to the subject of the message selected for
Reply from Email List table. Essentially the subject field is added with a clause
RE: so as to mark it a reply message.

Body: The body provides the editor to compose the mail message. It already
consist of the message as sent by the receiver. No cut paste commands are
provided and the user is able to type all simple types of messages.

SEND Button: The button component provides the functionality to send the
message to the respective To Receiver and Cc Receiver. The Mail Reply Panel is
subsequently closed.














32
3.10 Forward Mail Panel


Figure 3.10: Forward Mail Panel

The diagram represents the Forward Mail Panel of E-Mail Tokri. The details of the
Forward Mail Panel are same as to Mail Reply Panel as described above. The only field
that has some change is described as:

Subject Text field: Subject field is set to the subject of the message selected for
Forward from Email List table. Essentially the subject field is added with a
clause FWD: to mark it as a forwarded message.





33
4 Specific Requirements: C
The following format will be used when presenting each requirement:

Requirement ID/Priority: A unique identifier that separate each requirement to aid
testing and traceability. It contains three parts, and they are:

A character that identifies the requirement to which level of user does it assigned
to.

A number that identifies the requirement order within that user level

A dot placed between the two identifiers to separate the two.

Example: R.1 denotes Registered user level and requirement number one. (A requirement
priority level that indicates which requirement is more important to be implemented than
the others.)

Priority field format explanation:

1. Mandatory: Mandatory means that it is a core requirement which has to be
implemented in order to consider the system satisfactorily completed. This then
implies that if you do not meet all the mandatory requirements, the system will not
be considered satisfactory by the client.

2. Highly desirable: Highly desirable means the requirement is highly desirable to be
implemented in the E-Mail Tokri. This requirement is part of the non-core
requirements which will not affect the acceptance of the final product by the client
if not meet.

3. If Time permits: Implement if time permits means the requirement will be
implemented after implementing mandatory and highly desirable requirements, and
only if the developer has the time to implement it. This requirement is part of the
non-core requirements which will not affect the acceptance of the final product by
the client. It adds value to the product.

The non-core requirements have priority level amongst themselves to determine their
importance level (this applies to both highly desirable and implemented if time permits).
This is determined by the requirement number, as the requirement with smaller
requirement number will have higher requirement number in implementation than those
with higher requirement number.


34
E.g. Requirement priority: highly desirable (2) will have higher priority of
implementation than requirement with priority: highly desirable (4).

It is possible for some non-core requirements to have the same priority level in the
same category. In this case, those requirement must be implemented if either one of them
is implemented.

4.1General Functionality Requirement

Use cases refer Appendix A

4.1.1 Download E-mails
Requirement ID/Priority: GF.1 / Mandatory

Downloading mails:

1. E-Mail Tokri must provide the facility of downloading mails from the server.

2. The mails are downloaded from the server and are stored on the users hard disk.

Downloaded mails:

1. The mails downloaded must be deleted from the users account in the server.

4.1.2 Sending E-mails
Requirement ID/Priority: GF.2 / Mandatory

E-Mail Tokri must allow the user to perform the following send mail tasks:

1.Compose mails.

2.Replying receive mails.

3.Forward mails.


35



4.1.2.1 Compose E-mails

Requirement ID/Priority: GF.2.1 / Mandatory

1. E-Mail Tokri must allow the user to enter the text of the mail.

2. E-Mail Tokri must allow the user to specify recipient / recipients of the mails.

3. E-Mail Tokri allows the user to specify recipient / recipients for receiving copy /
copies of the mail.


4.1.2.2 Reply to Received E-mails

Requirement ID/Priority: GF.2.2 / Mandatory

1. E-Mail Tokri must display the text of the mail being replied to.

2. E-Mail Tokri must allow the user to edit the text of the mail being replied to.

3. E-Mail Tokri must display the subject of the mail being replied to with a RE:
added in the beginning of the subject line.

4 E-Mail Tokri must display the email id of the sender of the mail being replied
to, as the default recipient.

5 E-Mail Tokri must allow the user to add recipients.

6 E-Mail Tokri allows the user to specify recipient / recipients for receiving copy /
copies of the mail.
4.1.2.3 Forward E-mails

Requirement ID/Priority: GF.2.3 / Mandatory


36

1. E-Mail Tokri must display the text of the mail being forwarded.

2. E-Mail Tokri must allow the user to edit the text of the mail being forwarded.

3. System must display the subject of the mail being forwarded with a FWD:
added to the beginning of the subject line.

4. E-Mail Tokri must allow the user to specify recipients.

5. E-Mail Tokri allows the user to specify recipient / recipients for receiving
copy / copies of the mail.
4.1.3 Attachments:

Requirement ID/Priority: GF.3 / Mandatory
E-Mail Tokri must allow the user to send attachments while replying to, forwarding
and composing mails.

4.1.3.1Sending Attachments

Requirement ID/Priority: GF.3.1 / Mandatory

1. System must allow user to browse his machine to search file to attach.

2 E-Mail Tokri must display the files on hard disk in a File Dialog Box.
a. System must allow user to select a file to attach.
b. System must allow user to send the mail with attachment.
4.1.3.2 Download Attachments

Requirement ID/Priority: GF.3.2 / Mandatory

1. System must download the attachment along with a mail, if the mail has an
attached file with it.
2. System must let the user save the attachment to his/her desired location on
his/her machine.


37
4.1.4 File Management
4.1.4.1 Sign In

Requirement ID/Priority: FM.1 / Mandatory

E-Mail Tokri must allow registered user to sign in into the system after providing
the right combination of E-Mail Tokri username and password specified.

4.1.4.2 Sign Up

Requirement ID/Priority: FM.2/ Mandatory

E-Mail Tokri must allow an unregistered user to sign up.

4.1.4.3 Display user specific mails

Requirement ID/Priority: FM.3 / Mandatory

E-Mail Tokri must display the mails of the user when he signs in.
4.1.4.4 Store mails corresponding to a user
Requirement ID/Priority: FM4 / Mandatory

E-Mail Tokri must store the mails of user into the directory specifically allocated to
the user by the E-Mail Tokri.

4.1.5 Mail Classification
4.1.5.1 Finding Similarities

Requirement ID/Priority: C.1 / Mandatory

E-Mail Tokri will find out the similarity between two mails based on entries in
FROM, TO, Cc and SUBJ ECT fields using classification algorithm.


38
4.1.5.2 Forming Groups

Requirement ID/Priority: C.2 / Mandatory

Based on similarity between mails, system will form proposed groups of mails and
suggest the groups to the user.
4.1.5.3 Creating Mail Groups

Requirement ID/Priority: C.3 /Mandatory

System must move the mails of a group to a different directory based on
acceptance of the group by the user.
4.1.5.4 Non similar Mails to Inbox

Requirement ID/Priority: C.4 / Mandatory

If a mail is not part of any group system must leave the mail in Inbox.
4.1.5.5 Automatic Mail classification

Requirement ID/Priority: C.5 / Mandatory

If a newly arrived mail is found to be part of any existing group then system must
move the mail to the directory corresponding to the group.
4.1.5.6 Re-Classification

Requirement ID/Priority: C.6 /Mandatory

E-Mail Tokri must allow user to perform re-classification of mails. All the mails
which were previously part of a group will also be considered for re-classification.

4.1.5.6.1 Suggestion for new group after Re-classification

Requirement ID/Priority: C.6.1 / Mandatory

System must suggest new groups to the user after reclassification.


39
4.2 Non-Functional Requirements
This section details the non-functional requirements required by the proposed system
in order to function properly.
4.2.1 Checking

Requirement ID/Priority: NF.1/ Mandatory

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

Requirement ID/Priority: NF.2 / Mandatory

E-Mail Tokri does not allow users to view other users details for privacy and
security reason.
4.2.3 Portability

Requirement ID/Priority: NF.3/ Mandatory

E-Mail Tokri must be portable between Microsoft Windows and Linux. Both
intranet and internet version of E-Mail Tokri should be portable.
4.2.4 Maintainability

Requirement ID/Priority: NF.4/ Mandatory

E-Mail Tokri should be modular. Specifically, file contents should be easy to
maintain as the contents of the database change often.
4.2.5 Performance

Requirement ID/Priority: NF5 (Mandatory)

E-Mail Tokri should be able to support multiple users at a time.





40
5 Design Constraints: C
5.1 System Side

5.1.1 Hardware Constraints

Users system should have the following requirements in order to E-Mail Tokri to
function properly.

1. Processor: Intel based 166 MHz
2. RAM: 128 MB
3. Hard-disk space: 4 Gb
4. Networking: Ethernet 10/100

5.1.2 Software Constraints

The software is expected to be installed on the following platforms:

1. Operating System: Windows or *INUX,
2. Interpreter: MVM

6 Product Acceptance Criteria: C

This section details the criteria that needs to be completed by the proposed
system in order to be accepted by the Client as succession.

1. The proposed system must implement all requirements in section that are Mandatory.

2. The proposed system must implement all non-functional requirements defined in
section.

3. The Developer should provide the Client the following documents along with the
proposed system.

This document (Software Requirement Specification - SRS)


41
Software Design Document (SDD)
Test Plan
User Documentation


























Appendix A: C

Use Case ID : 1
Use Case Name : Download emails

Functional Requirement ID : GF.1


1. DESCRIPTION

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


42


2. ACTORS

2.1 Primary Actors
User.
2.2 Secondary Actors
Users mail server.

3. USE CASE DIAGRAM


4. STEPS

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

Use Case ID : 2
Use Case Name : Sending emails

Functional Requirement ID : GF.2,GF.2.1,GF.2.2,GF.2.3


1. DESCRIPTION


43

This use case describes the process of sending emails.


2. ACTORS

2.1 Primary Actors
User.
2.2 Secondary Actors
Recipients mail server.

3. USE CASE DIAGRAM


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 (Recipients 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 (Recipients Mail Server receives mail successfully )
mail sent
else report problem

4.3 If user gives forward command
4.3.1 Edits subject.


44
4.3.2 Edits contents.
4.3.3 Specifies recipients.
4.3.4 Give send command.
4.3.5 If(Recipients Mail Server receives mail successfully )
mail sent
else report problem




Use Case ID : 3
Use Case Name : Attachments

Functional Requirement ID : GF.3,GF3.1,GF.3.2


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



45

4. STEPS

4.1. Sending Attachments.

4.1.1 System must allow user to search the file to attach.

4.1.2 E-Mail Tokri should display the list of files on users 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 E-Mail Tokri must allow user to save attachment to desired path in his
machine.




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



46
Functional Requirement ID : C.1,C.2,C.3,C.4,C.5,C.6,C.6.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.



Use Case ID : 5
Use Case Name : Sign In

Functional Requirement ID : FM.1

3. DESCRIPTION

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


4. ACTORS

4.1 Primary Actors
User.
4.2 Secondary Actors
N/A


47

3. USE CASE DIAGRAM


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.


Use Case ID : 6
Use Case Name : Sign Up

Functional Requirement ID : FM.2

1. DESCRIPTION

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


2. ACTORS

a. Primary Actors
User.
b. Secondary Actors
N/A
3. USE CASE DIAGRAM



4. STEPS


48
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.




Use Case ID : 7
Use Case Name : Display Emails

Functional Requirement ID : FM.3

1. DESCRIPTION

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


2. ACTORS

a. Primary Actors
User.
b. 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.



Use Case ID : 8
Use Case Name : Store Emails

Functional Requirement ID : FM.4

1. DESCRIPTION


49

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

2. ACTORS

a. Primary Actors
User.
b. Secondary Actors
Recipients mail server.

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.





















50
Appendix B: C
Tractability Matrix U in the row/column intersection illustrates that the requirement in the row uses the
facilities specified in the requirement named in the column. R means that there is some other weaker
relationship between the requirements.
R
e
q.
id
G
F
1
G
F
2
G
F
3
F
M
1
F
M
2
F
M
3
F
M
4
C
1
C
2
C
3
C
4
C
5
C
6
C
7
N
F
1
N
F
2
N
F
3
N
F
4
N
F
5
G
F
1

G
F
2

G
F
3
U U
F
M
1

F
M
2

F
M
3
U R
F
M
4
U
C
1

C
2
U
C
3
U
C
4
R
C
5
R U
C
6
U
C
7
U U
N
F
1

N
F
2
U
N
F
3

N
F
4

N
F



51
5

Vous aimerez peut-être aussi