Csis.bits-pilani.ac.in Faculty Praveenr SE2013 Srs Example1

8/11/2019 Csis.bits-pilani.ac.in Faculty Praveenr SE2013 Srs Example1

http://slidepdf.com/reader/full/csisbits-pilaniacin-faculty-praveenr-se2013-srs-example1 1/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) [email protected]

K VIJAYANANDA REDDY [email protected]

NEELESH DESHPANDE [email protected]

RAJEEV GAUR [email protected]

ASHISH GANDHI [email protected]

SHILADITYA BOSE [email protected]

GUDA KIRAN KRISHNA [email protected]

ANANTHARAM G [email protected]

SUNIL PAHLAJANI [email protected]



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 Document’s Purpose……………………………………………………..................... 8

1.3 Document’s Scope …………………………………………………………………... 9

1.4 Definitions …………………………………………………………………………... 9

1.5 Acronyms ……………………………………………………………………………. 10

1.6 Document’s 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 …………………………………………………………………………... 182.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 …………………………………………………………………. 354.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 …………………………………………………………………. 384.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 ………………………………………………………………………… 253.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 document’s 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 one—like 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 Neptune’s 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 themarket.

1.2 Document’s 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 Document’s 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 Neptune’s 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 properlyset 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 accordingto user’s criteria.

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

Clustering Collection of mails with the same field properties.

Mail downloading Downloading mails into hard disk and simultaneously deletingthose 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.

JDK Java 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 Document’s 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 thereaders a preview of the document’s 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: [email protected]

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 Practitioner’s 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 andtrained, 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

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.

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 fo llowed 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(Recipient’s 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 intodifferent folders.



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 f ollowing

1. Processor: Intel based 166 MHz2. 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. Afterclear understanding of mail system, Neptune’s 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 sectionof 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 Neptune’s 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 Tokr i 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 ofcharacters.

• 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 showthe 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 user’s 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 areincluded 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 areincluded 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 TransferProtocol 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:

[email protected] .

• 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: [email protected].

• Cc Text field: This is the Email address of the secondary receiver. A secondaryreceiver 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: [email protected].

• 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:

[email protected].

• 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: [email protected] 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: [email protected].

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



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 user’s hard disk.

Downloaded mails:

1. The mails downloaded must be deleted from the user’s account in the server.

4.1.2 Sending E-mails


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


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




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 receivingcopy / copies of the mail.

4.1.3 Attachments:


E-Mail Tokri must allow the user to send attachments while replying to, forwarding

and composing mails.

4.1.3.1Sending Attachments


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


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 tothe 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 inFROM, TO, Cc and SUBJECT fields using classification algorithm.



38

4.1.5.2 Forming Groups


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


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


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

4.1.5.5 Automatic Mail classification


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


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 user’s details for privacy and

security reason.

4.2.3 Portability


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


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 : 1Use 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

User’s 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 user’s 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

Recipient’s 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 (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.



44

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

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


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


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


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

Recipient’s 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.Req.id

GF1

GF2

GF3

FM1

FM2

FM3

FM4

C1

C2

C3

C4

C5

C6

C7

NF1

NF2

NF3

NF4

NF5

GF1

G

F2

GF3

U U

FM1

FM2

FM3

U R

FM4

U

C1

C2

U

C3

U

C4

R

C5

R U

C

6

U

C7

U U

NF1NF2

U

NF3

NF

4NF



5

Csis.bits-pilani.ac.in Faculty Praveenr SE2013 Srs Example1

Documents

Transcript of Csis.bits-pilani.ac.in Faculty Praveenr SE2013 Srs Example1