This document outlines the requirements for a live chat application. It discusses the purpose, scope, features and functions of the chat app. The app allows users to chat in real-time and provides features such as customizable welcome messages, file sharing, and group chat. It also specifies the user requirements, interfaces, design constraints, usage scenarios and UML diagrams for the app. The goal is to develop an easy to use messaging solution that enables seamless communication between users.

1. Live Chat
Madhuri Jugalkishor Pallod
April 12, 2019
(2018MIT006)
1

2. CONTENTS CONTENTS
Contents
1 Introduction 4
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Intended Audience and Reading Suggestions . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Objective of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Overall Description 5
2.1 Product Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Product Function: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Characteristics: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Operating Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5 Design and Implementation Constraints: . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.6 User Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.7 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 System features 7
3.1 Meetings: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 User Requirements (functional requirement & Non functional requiment) 8
4.1 Functional requirement: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Non Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5 External Interface Requirements 9
5.1 User Interfaces : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2 Hardware Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3 Software Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Implementation: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6 Other Nonfunctional Requirements 11
6.1 Performance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2 Safety Requirements: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7 Usage scenarios 12
7.1 Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2 Use-Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2.1 Authentication System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2.2 Contacts Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2.3 Chat Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2.4 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2.5 Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8 Some charasteristics 15
9 UML Diagrams 17
9.1 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.3 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.4 State chart Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.5 ER Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.6 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.7 Component diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2

3. LIST OF FIGURES LIST OF FIGURES
List of Figures
1 Use Case Table of Chat Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Use case digram for Authentication system . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Use case digram for contacts form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 use case diagram for chat form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 use case diagram for maintainance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6 use case diagram for monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8 Activity diagram of live chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10 State chart diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11 ER diagram of live chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13 component diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3

4. 1 INTRODUCTION
Chapter 1
1 Introduction
1.1 Purpose
The Live Chat Application provided by Odoo made communication processes easy. Communication is
a mean for people to exchange messages. It has started since the beginning of human creation. Distant
communication began as early as 1800 century with the introduction of television, telegraph and then tele-
phony. Interestingly enough, telephone communication stands out as the fastest growing technology, from
_xed line to mobile wireless, from voice call to data transfer. The emergence of computer network and
telecommunication technologies bears the same objective that is to allow people to communicate. All this
while, much efforts has been drawn towards consolidating the device into one and therefore indiscriminate
the services. Chatting is a method of using technology to bring people and ideas together despite of the
geograph- ical barriers. The technology has been available for years but the acceptance it was quit recent.
Our project is an example of a chat server. It is made up of applications the client application which runs
on the users mobile and server application which runs on any pc on the network. To start chatting our client
should get connected to server where they can do Group and private chatting.
1.2 Document Conventions
Font style used in this document is Times New Roman. The font size is 12 for description of each title or
topic while sub -titles are in bold letters with font size 14. Headings or main titles having font size 18 with
bold letters.Paragraph settings are justified and line spacing is 1.5.
1.3 Intended Audience and Reading Suggestions
This SRS document contains use case diagram and description about all usecase have been included in this
document. It also gives the functional and nonfunctional requirement.Product features,System features are
also specified.
1.4 Project Scope
This project is to create a chat application with a server and users to enable the users to chat with each
others. To develop an instant messaging solution to enable users to seamlessly com- municate with each
other. The project should be very easy to use enabling even a novice person to use it.
1.5 Objective of Project
1. Broadcasting Chat Server Application is going to be a text communi- cation software, it will be able to
communicate between two computers using point to point communication.
2. The limitation of Live Chat is it does not support audio conversations. To overcome this limitation
we are concurrently working on developing better technologies.
3. Companies would like to have a communication software wherein they can communicate instantly
within their organization.
4. The fact that the software uses an internal network setup within the organization makes it very secure
from outside attacks
4

5. 2 OVERALL DESCRIPTION
Chapter 2
2 Overall Description
2.1 Product Perspective
The chatt process solution provided by Odoo allows the Live chat.
2.2 Product Function:
Live chat application developed by Odoo has following features :
1. Personalize window behaviour : Define how the Live Chat button appears. Decide if you want the
chat to open automatically and after how long.
2. Create custom welcome messages: Configure automatic welcome messages for each channel and
personalize the button’s layout.
3. Answer from everywhere: Live chat is accessible from within any module, in the front-end and back-
end, to keep track of every conversation.
4. Use fun smileys :Add a personalized human touch to your communication with fun smileys .
5. Create canned responses : Create shortcuts to use pre-written template answers for common ques-
tions.
6. Chat in groups :Add multiple users to a conversation to make a group chat.
The user interacts with the tool using GUI. The GUI Operates in two forms, Contacts Forms and Chat
forms. The contacts forms contains list of all friend and the Chat form will be used to chat with friends.
2.3 Characteristics:
There is always a room for improvements in any apps. Right now we arejust dealing with text commu-
nication. There are several android apps which serve similar purpose as this project, but these apps were
rather di_cult to use and provide confusing interfaces. A positive first impression is essential in human
relationship as well as in human computer interaction. This project hopes to develop a chat service Android
app with high quality user interface. In future we may be extended to include features such as:
1. File Transfer
2. Voice Message
3. Video Message
4. Audio Call
5. Video Call
6. Group Call
2.4 Operating Environment
The software is supposed to be provided with enough memory to store the data. This software can be run
on any system like XP, Windows7, windows, etc. Website of the organization created by Odoo software can
be accessed from any browser like Google Chrome, Mozilla Firefox etc. by the applicant.
2.5 Design and Implementation Constraints:
All the data of applicant and resumes, CV’S and attachments are stored in database. Data from the database
can be access, retrieve or update .Languages used will help formaintaining database. For accessing or
viewing any table the data is fetched directly from the database. It makes the use of xml, Python, Javascript.
.
5

6. 2.6 User Documentation 2 OVERALL DESCRIPTION
2.6 User Documentation
Along with this project the documentation is provided to the users which will explains the user how to
handle the software on the system. On the demand of users when a new user first time accesses the system
the training videos or detail explanation of each component is provided to users. It must provide informa-
tion about the database and various backend componants. The system should provide a help system that
describes and illustrates all system functions.
2.7 Assumptions and Dependencies
This application is developed on the basis of candidate must know communication.
• Every user should be comfortable working with computer and net browsing.
• User must have comfortable knowledge of English language.
6

7. 3 SYSTEM FEATURES
Chapter 3
3 System features
3.1 Meetings:
The test team will meet once in every weeks to evaluate the progress and identify all problems and conduct
a solution. Test team will also meet with development team to merge their ideas about testing and quality
of our web-site
Addtional mettings can be called as required for emergency situation..
Save a lot of time & effort Optimize processing time .
User friendly system Chat online with customers and website visitors in real time.
No need for a special chat server, everything is done through your website.
Provide your visitors with information in a fast and simple way - direct chat with customers on your
website has never been easier!
7

8. 4 USER REQUIREMENTS (FUNCTIONAL REQUIREMENT & NON FUNCTIONAL
REQUIMENT)
Chapter 4
4 User Requirements (functional requirement & Non functional re-
quiment)
4.1 Functional requirement:
1. User Registration: User must be able to register for the application through a valid phone number.
On installing the application, user must be prompted to reg- ister their phone number. If user skips
this step, application should close. The users phone number will be the unique identi_er of his/her
account on Chat Application.
2. Adding New Contacts : The application should detect all contacts from the users phone book. If any
of the contacts have user accounts with Chat Application, those contacts must automatically be added
to the users contact list on Chat Application. If any of the contacts have not yet registered on Chat
Application, user should be provided with an invite option that sends those contacts a regular text
message asking them to join Chat Appli- cation along with a link to the Chat Application on Google
Playstore.
3. Send Message: User should be able to send instant message to any contact on his/her Chat Applica-
tion contact list. User should be noti_ed when message is successfully delivered to the recipient by
displaying a tick sign next to the message sent.
4. Broadcast Message: User should be able to create groups of contacts. User should be able to broad-
cast messages to these groups.
5. Message Status: User must be able to get information on whether the message sent has been read by
the intended recipient. If recipient reads the message, 2ticks must appear next to the message read.
4.2 Non Functional Requirements
1. Privacy: Messages shared between users should be encrypted to maintain privacy.
2. Robustness: In case users device crashes, a backup of their chat history must be stored on remote
database servers to enable recoverability.
3. Performance: Application must be lightweight and must send messages instantly. ticks must appear
next to the message read.
8

9. 5 EXTERNAL INTERFACE REQUIREMENTS
Chapter 5
5 External Interface Requirements
5.1 User Interfaces :
The System shall provide a help link from each displayed web page to explain how to use that page.
Software should provide easy way to communicate and display that live chat on website.
Software should provide easy way to group chat, broadcast chat etc.
System should give notification for arrival of each message.
Software must provide a way to customize the website.
System should display the total number of messages received on portal.
User interface should provide the reports for the comparison of application from different applicant.
5.2 Hardware Interfaces
• Operating system: Linux, Windows, UNIX, MAC OS X.
• RAM: 256 Mb or more
• Hard drive: 10 GB or more
• Internet or LAN Connections
5.3 Software Interfaces
1. Client or applicant on internet: Web Browser, Operating System (Linux, Windows, Unix , android
etc.)
2. Web Server: WAS
3. Data Base Server: DB2, Operating System Embarcadero ER Studio, MySQL ..Software interfaces
(to OS, DBMS, and other Software) Use a specific application packages.
4. Software development methodologies: Agile, Scrum, Kamban, Scrum-ban, RUP, DSDM, etc.
5.4 Implementation:
1. Programming languages: Java, PHP
2. Technologies, libraries and frameworks: Java: JEE/J2EE, Java 2D, JSP, Apache Wicket, JMS, Swing,
Spring, Struts, Hibernate, JPA, JSF, EJB, Java Security, Velocity, JMF, PAM, i18n, Apache ; Com-
monly, GWT, JXL, JAccess, SiteMesh,Oracle Portal.
3. PHP: CodeIgniter, CakePHP, Zend, Yii, Kohana, WordPress, Joomla, Dru- pal, MODX, Magento,
Prestashop, IPBoard, Smarty .
4. Mobile: PhoneGap, iPhone SDK, Android SDK, JQuery Mobile, Flash Lite, J2ME, Symbian, XMPP,
SMS, WAP .
5. Web technologies: JSON,XHTML, HTML5, XML, XSL, XSL-FO, XSLT, CSS, XPath, XQuery,
SAX, DOM, StAX, Xerces, Flash, Flex, Oauth, Om- niauth, TinyMCE, Plupload, Retina.js, Flexpa-
per Adaptive UI, JW Player, Highcharts, Modemizr, BjQS
6. Content Management Systems: Stellent
7. Messaging Middleware: ActiveMQ, IBM MQ Series, Fiorano, MQSonic, TIBCO rendezvous IDE:
Intelij IDE,Android Studio.
8. Networking protocols and data security: TCP/IP, HTTP/HTTPS, SMS, SMPP, MMS, MD5, POP3,
SMTP, FTP, TFTP, etc.
9

10. 5.4 Implementation: 5 EXTERNAL INTERFACE REQUIREMENTS
9. Databases: Oracle, MS SQL Server, MySQL, Derby, PostgreSQL, Lucene/SOLR, LDAP (Oracle In-
ternet Directory, OpenLDAP, MS Active Directory), H2, Find- Link, MongoDB, Exaled CloudView,
etc.
10. Application and web servers: Apache Tomcat, JBoss AS, Jetty, IBMWebShere, Oracle Application
Server, WebLogic, Windows Server IIS, Nginx, NetWeaver .
11. Web and graphic design: Adobe Photoshop,Illustrator, Flash, DreamWeaver , argoUML.
10

11. 6 OTHER NONFUNCTIONAL REQUIREMENTS
Chapter 6
6 Other Nonfunctional Requirements
6.1 Performance Requirements
• The information page and attachments should be able to be downloaded within a minute.
• The system shall respond to the member in not less than two seconds from the time of the request
submission.
• The system shall be allowed to take more time when doing large file sending.
• The login specification should be identified within seconds and notify at that time only.
• The load time for user interface screens shall take no longer than two seconds.
6.2 Safety Requirements:
System should not result into the damage or loss of the stored data. Each application and it’sattachments
related to particular communication should be placed at one place. Software product should have antivirus
facility.
6.3 Security Requirements
Software is very deeply required with the security because the software stores all the important information
of the users. Security for stored data should be provided. Security for user accessed should be provided by
giving some login action like user name and password. It should prevent from unauthorized access to the
applicant’s application. The main security requirement is the validation used. Without proper validation
the system does not allow to enter that value into database. All the required validation controls are kept
controls are kept to keep the system secure.
Software Quality Attributes:
• Adaptability : The software should be adaptable for all latest operating systems.
• Availability : The system is available 100% for the user and is used 24 hours a day.
• Correctness: All the data stored should be correct. Free from error, accurate .System should not allow
incorrect and incomplete data to be entered.
• Flexibility : Flexibility means further changes in the software should be accepted.
• Portability : Product must be portable from one system to another system.
• Maintainability: Software must maintain all data properly without any ambiguity, loss with back-up
files.
• Reliability: The system has to be very reliable due to the importance of data and damages incorrect
or incomplete data can do.
11

12. 7 USAGE SCENARIOS
Chapter 7
7 Usage scenarios
7.1 Use-Cases
Figure 1: Use Case Table of Chat Application
7.2 Use-Case Diagram
7.2.1 Authentication System
Figure 2: Use case digram for Authentication system
12

13. 7.2 Use-Case Diagram 7 USAGE SCENARIOS
7.2.2 Contacts Form
Figure 3: Use case digram for contacts form
7.2.3 Chat Form
Figure 4: use case diagram for chat form
7.2.4 Maintenance
Figure 5: use case diagram for maintainance
13

14. 7.2 Use-Case Diagram 7 USAGE SCENARIOS
7.2.5 Monitor
Figure 6: use case diagram for monitor
14

15. 8 SOME CHARASTERISTICS
Chapter 8
8 Some charasteristics
Do it live!
Chat online with customers and website visitors in real time. No need for a special chat server, everything
is done through your website. Provide your visitors with information in a fast and simple way - direct chat
with customers on your website has never been easier!
Select your audience Provide direct chat to a specified target
Filter your audience by country and provide better customer service by engaging with your customers and
website visitors using the right language and tone.
Accessible from anywhere, Chat from within any module
Keep conversation with your customers in Odoo to allow multitasking when looking for important infor-
mation in the backend. Access all information the same time the conversation window is open so you can
give accurate and precise answers.
15

16. 8 SOME CHARASTERISTICS
Improve your level of service, Make sure to keep customers satisfied
Gather customer feedback to improve the quality of your service with a simple rating tool for live chat
sessions. Customers simply have to rate the conversation after their questions have been answered.
Answer more quickly with templates, Use pre-written answers to be faster
Spend less time on frequent questions by inserting pre-written answers using simple keyboard shortcuts.
Customize answers and add as many shortcuts as you like.
16

17. 9 UML DIAGRAMS
Chapter 9
9 UML Diagrams
9.1 Class Diagram
Figure 7: Class Diagram
9.2 Activity Diagram
Figure 8: Activity diagram of live chat
17

18. 9.3 Sequence Diagram 9 UML DIAGRAMS
9.3 Sequence Diagram
Figure 9: Sequence Diagram
9.4 State chart Diagram
Figure 10: State chart diagram
18

19. 9.5 ER Diagram 9 UML DIAGRAMS
9.5 ER Diagram
Figure 11: ER diagram of live chat
9.6 Deployment Diagram
Figure 12: Deployment Diagram
19

20. 9.7 Component diagram 9 UML DIAGRAMS
9.7 Component diagram
Figure 13: component diagram
20