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