ABSTRACT

e-PostOffice
In the recent past, Internet and e-mail have revolutionized the world of communications. In its endeavor to make the benefits of e-mail available to everyone and to bridge the digital divide, Department of Posts has introduced ePOST service. Through ePOST, customers can send their messages to any address in India with a combination of electronic transmission and physical delivery through a network of more than 1,55,000 Post Offices. ePOST sends messages as a soft copy through internet and at the destination it will be delivered to the addressee in the form of hard copy. At a cost of Rs. 10 per page of A4 size, e Post provides a cost-effective distributive solution for sending messages across the country, covering urban and rural populace . ePost services are available at 3,340 post offices. Just walk to your ePOST centre at the nearest post office and send ePost message today. Its easy ! Its cost-effective ! For corporate customers, ePOST corporate service that will enable the customers to send ePost from their premises for any destination across the nation. It costs just Rs 6 per ePost message of A4 size. Corporate can design their own templates and send them to multiple addresses through ePost corporate. Just a click and your message will reach the addressee thro ePost. PROJECT MEMBERS: 1)Amit Goyal 2)Ch.N.S.S.Aditya 3)M.Sridar

PRASAD.V.POTLURI SIDDHARTHA INSTITUTE OF TECHNOLOGY, KANURU, VIJAYAWADA

A Mini Project on e-Post

Submitted by AMIT GOYAL (08501A1225) CH.N.S.S.ADITYA (08501A1214) M.SRIDHAR (08501A1246)

BATCH NO: 11 Under the Guidance of

Mr

M. Sundarababu, M.Tech.
ASSITANT PROFESSOR

DEPARTMENT OF INFORMATION TECHNOLOGY

Signature of the Guide

Signature of the Project coordinator

Software Requirements Specification e-POST

Under the Guidance of

Mr. M.Sundarababu M.Tech.

Submitted By G.Amit CH.N.S.S.Aditya M.Sridhar

Table of Contents
1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms and Abbreviations 1.4 References 1.5 Technologies to be used 1.6 Overview Overall Description 2.1 Use-Case Model Survey 2.2 Architecture diagram 2.3 Assumptions and Dependencies Specific Requirements 3.1 Use-Case Reports 3.2 Supplementary Requirements Supporting Information Concerns / Queries / Doubts if any: 5 5 5 5 6 6 6 7 8 13 15 15 15 15 15 Error! Bookmark not defined.

2.

3.

4. 5.

Software Requirements Specification

1.
1.1

Introduction
Purpose

. This document is meant to delineate the features of e-Post Office, so as to serve as a guide to the developers on one hand and a software validation document for the prospective client on the other.
1.2 Scope

Initial functional requirements will be: Secure registration and profile management facilities for Customers After registering the customer enters a page where no. of A4 sheets required for writing the letter can be selected. Once the postal address of the destination is given in the TO field, the entire letter is sent to that address as a hard copy. A sent soft copy will remain with the customer for reference. Regular updates to registered customers of the e-Post about new arrivals. Maintaining database of the customers of different needs. e-Post employees are responsible for internal affairs like processing orders, assure home delivery, getting customer's delivery-time feedback, updating post's status and answering client's queries online. Feedback mechanism, so that customers can give feedback for the service which they have purchased. Also facility rating of individual products by relevant customers. Also feedback can be given on the performance of particular vendors and the entire mall as well. Adequate payment mechanism as available from time to time.

Initial non functional requirements will be: Secure access of confidential data (users details). SSL can be used. 24 X 7 availability Better component design to get better performance at peak time Advertisement space where it will effectively catch the customers attention and as a source of revenue. In addition to the above mentioned points, due to the highly evolving nature of the project, the following are planned to be delivered if deemed necessary: Warehousing within the very ambits of the project More payment gateways. Dynamic price model by which prices can be changed based on demand and supply Dynamic Storefront: Each user will have a web page personalized based on his or her recent activity. Customizable color scheme or skins. Help link on each of the screens. This list is by no means, a final one. The final list will be dictated by implementation constraints, market forces and most importantly, by end user demands for whom this is being built.
1.3 Definitions, Acronyms and Abbreviations

SLA: Service Level Agreement or SLA is a formal written agreement made between two parties, the service provider & the service recipient. It defines the term of engagement the fundamental rules that will govern the relationship. EJB: Enterprise Java Beans. JAVA EE: Java Enterprise Edition 5 is a programming platform part of the Java Platform-for developing and running distributed multi-tier architecture Java applications, based largely on modular software components running on an application server. HTTP: Hypertext Transfer Protocol is a transaction oriented client/server protocol between a web browser & a Web Server. HTTPS: Secure Hypertext Transfer Protocol is a HTTP over SSL (secure socket layer). TCP/IP: Transmission Control Protocol/Internet Protocol, the suite of communication protocols used to connect hosts on the Internet. TCP/IP uses several protocols, the two main ones being TCP and IP.
1.4 References

IEEE SRS Format

1.5 Technologies to be used

Programming languages: JAVA EE: Java Enterprise Edition is a programming platform part of the Java

Platform-for developing and running distributed multi-tier architecture Java applications, based largely on modular software components running on an application server. HTML, XML: Hyper Text Markup Language and Extensible markup Language are the predominant markup languages for web pages. It provides a means to describe the structure of text-based information in a document and to supplement that text with interactive forms, embedded images, and other objects. JavaScript: A client side scripting language used to create dynamic web content and user interface. Tools & Development Environment:
Tomcat server 1.6 Overview

The rest of this SRS is organized as follows: Section 2 gives an overall description of the software. It gives what level of proficiency is expected of the user, some general constraints while making the software and some assumptions and dependencies that are assumed. Section 3 gives specific requirements which the software is expected to deliver. Functional requirements are given by use case diagram. Some performance requirements and design constraints are also given. 2.
2.1

Overall Description
Product perspective

e-Post office is aimed towards the customers who want to reach out to the maximum cross-section of customer and common people who can be potential customer. This project envisages bridging the gap between the post offices and common man. e-post office should be user-friendly, quick to learn and a reliable software for the above purpose. e-post office is intended to be a stand-alone product and should not depend on the availability of other software. It should run on Windows based platform.

2.2

Product functions

User: Administrator Functions: The database Administrator is the super user and has complete control over all the activities that can be performed. The application notifies the administrator of all product requests, and the administrator can then approve or reject them. The administrator also manages the list of available product categories. User: Man who uses the online post office Functions: A valid user can choose the no.of pages and stamps required to send his message to the desired one. To proceed with the sending of letters, the user is prompted to login.
2.3 User characteristics

The user should be familiar with the post office related terminology like email, post, stamps and transactions. The user should be familiar with the Internet.
2.4 Constraints

There is no maintainability of back up so availability will get affected. Limited to HTTP/HTTPS. The user have to pay some money to the postoffice bank account such that the user can get sufficient balance for posting. No multilingual support. Use-Case Model Survey:

edit catalog

administrator user registration

login

payment

Given below is an overall picture of the system, as depicted in the above use-case diagrams:

1. Administrator:
 Database Management: Control the database and keep track of all records of users and their details.

 

View all details: View the details of all users and control the whole site. Edit the catalogue: The administrator is also responsible for editing the catalogue.

2. Users:
Login: Users must have a valid login id to enter into the site.

Registration: New users can sign up by creating new ID giving their name, valid username and password, post office details to create a new id.

Selection of items: The users can select the various items required like stamps and no.of pages and can send the letter through an email or by post.

Payment: User can pay the amount of money by giving the card number.

Visitors: Visiting the Site: Can only visit the site without registration.

Sequence Diagram for login:

user login page enter username,password checks for validity checks database

if yes then go to home page otherwise,invalid details

Collobaration Diagram for Login:

1: enter username,password user login page

5: otherwise,invalid details 3: checks 4: if yes then go to home page 2: checks for validity

databas e

Sequence Diagram for registration:

user opens registration form database

enter the fields

press submit

updates the user

registred successfully

Collobaration for registration:

1: opens 2: enter the fields 3: press submit button user registratio n form

5: registred successfully 4: updates the user details

databas e

Sequence Diagram for payment:

user enter card number

credit card

user account

money is deducted

shows the remaining balance

1: enter card number user credit card

3: shows the remaining balance 2: money is deducted

user account

Calloboration diagram for payment

2.5 Architecture diagram

2.6 Class Diagram

user username : String password : String address : String email : Variant phoneno : Integer cardno : Integer cardcode : Integer cardinfo : Variant loginstatus : Boolean register() login() updateinfo() selection() display stamps : Variant pages : Integer account : Integer 1 1 selectionbymail() selectionbypost() display() pagesaccessed()

administrator adm-name : String postoffice-address : String verification() delete() insert() adm-details()

2.7

Assumptions and Dependencies

The details related to the product, customer, payment and service transaction provided manually. Administrator is created in the system already. Roles and tasks are predefined. 3. Specific Requirements [This section of the SRS should contain all the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. When using use-case modeling, these requirements are captured in the use cases and the applicable supplementary specifications. If use-case modeling is not used, the outline for supplementary specifications may be inserted directly into this section.]
Use-Case Reports

3.1

[In use-case modeling, the use cases often define the majority of the functional requirements of the system, along with some non-functional requirements. For each use case in the above use-case model or subset thereof, refer to or enclose the use-case report in this section. Make sure that each requirement is clearly labeled.]
3.2 Supplementary Requirements

[Supplementary Specifications capture requirements that are not included in the use cases. The specific requirements from the Supplementary Specifications which are applicable to this subsystem or feature should be included here, refined to the necessary level of detail to describe this subsystem or feature. These may be captured directly in this document or refer to separate Supplementary Specifications, which may be used as an enclosure at this point. Make sure that each requirement is clearly labeled.] 4. Supporting Information [The supporting information makes the SRS easier to use. It includes: a) Table of contents, b) Index, c) Appendices. These may include use-case storyboards or userinterface prototypes. When appendices are included, the SRS should explicitly state whether or not the appendices are to be considered part of the requirements.