CS15
(Team Number)
Chatbox with Navigation Meetup System
Software Requirements Specification
Document
Under the supervision of: Date:
Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview
2. The Overall Description
2.1 Product Perspective
2.1.1 System Interfaces
2.1.2 Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Communications Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.1.8 Site Adaptation Requirements
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
2.6 Apportioning of Requirements
3. Specific Requirements
3.1 External interfaces
3.2 Functions
3.3 Performance Requirements
3.4 Logical Database Requirements
3.5 Design Constraints
3.5.1 Standards Compliance
3.6 Software System Attributes
3.6.1 Reliability
3.6.2 Availability
3.6.3 Security
3.6.4 Maintainability
3.6.5 Portability
3.7 Organizing the Specific Requirements
3.7.1 System Mode
3.7.2 User Class
3.7.3 Objects
3.7.4 Feature
3.7.5 Stimulus
3.7.6 Response
3.7.7 Functional Hierarchy
3.8 Additional Comment
4. Change Management Process
5. Document Approvals
6. Supporting Information
1. Introduction
A large number of social applications have been launched in India over the last few years to deliver a wide variety of information and communication between users. The concept of communication and different features need to quantified in some way to avoid competition in market. It may be field of social communication and other platforms for raising voice against corruption as well as in entertainment area also.
Our aim is to add additional as well as new feature in the chat applications. In this we want to add an option through which we can get the mid-point location for meetings and hangouts mostly for the formal scenarios. It will be helpful for getting location which is approximately closer to all the people of groups.
It is an additional feature for giving new gems in chat applications as enhancement. As new one is always better than old one. And in today’s world there is regular enhancement in all the curves of life as well as in all the market related to technologies and its features. Hence we will provide rest of the information in other segment of our Software requirements specification Document.
1.1 Purpose
The objective of proposed project is to remove the drawback of the existing system used by various social sites and people at home.The proposed system helps in finding out locations for meeting and hangouts in the both perspective, formal and informal.
1.2 Scope
‘ The objective of proposed project is to remove the drawback of the existing system used by various social sites and people at home.
‘ The proposed system helps in finding out locations for meeting and hangouts in the both perspective, formal and informal.
‘ Easy to provide updates to Students regarding training and placement activities
‘ To increase accuracy and efficiency of the application.
‘ Reduce the paperwork.
1.3 Definition, Acronyms, Abbreviations
HOD Head of Department
APIs Application Programming Interfaces
B.TECH Bachelor of Technology
AKTU Abdul Kalam Technical University
ER Entity Relationship
DFD Data Flow Diagram
1.4 References
1. The JavaTM Tutorials
http://docs.oracle.com/javase/tutorial/
2. Java SE Documentation
http://docs.oracle.com/javase/6/docs/
3. Android Programming: The Big Nerd Ranch Guide, By: Bill Philips and Brian Hardy
4. Android Design Patterns, By: Greg Nudelman
5. Ian Somerville, 2001. Software Engineering. Dorling Kindersley Pvt. Ltd., Delhi.
6. Patrick Naughtn & Herbert Scheldt, 2000. The Complete Reference, Java 2, Fifth Edition.McGraw-Hill.
1.5 Overview
The main aim of this is to analyze, design, build and test chat box with navigation meet up system. The software has been developed as an Interactive and collaborative learning aid.
The application does require any Internet connection. By the application, users can send free message to their friends sitting over anywhere, in any part of the country. Moreover, the application is very easy to use. Messaging is also great for making new friends in a
library or chatting up someone in crowded places, because one can connect with anyone who has a Internet-enabled phone.
.
2. The Overall Description
Till now, we have given brief introduction to Chat Box. The rest of the document aims to
give some details in to system and some constraints of it.
2.1 Product Perspective
There is so much competition in the industries of technology and features provided by the industries .As in that case for maintaining positions in the market one have to enhance their application in each and every edge of the life so that they can tied up their customers and as in software application development ,it’s a rule or we can say the necessity of any software to maintain it in the changing environment according to the ease of customers so our additional feature just give one more facility as well as an easiness in the handheld applications for finding out the locations for any kind of meet ups and gatherings based on both formal and informal.
2.1.1 System Interfaces
2.1.2 Interfaces
User interface
There are three main interfaces that the user will interact with:
‘ Login/SignUp Interface:
The user will SignUp, if he/she is not the registered user and will login otherwise.
The user can also directly login via google.
‘ One to One Chat Interface:
Here One can personality chat with the other person.
.
‘ Meet Up Interfaces:
Search the nearby location to meet.
2.1.3 Hardware Interfaces
‘ PROCESSOR : 32 BIT, Pentium
‘ RAM : 1GB
‘ HARD DISK : 40GB
‘ MONITOR : SVGA Monitor (800 * 600 Resolutions)
‘ CLOCK : 266 MHz
2.1.4 Software Interfaces
‘ OPERATING SYSTEM : Android
‘ FRONT END : J2ME Android Studio
‘ BACKEND : MySQL
2.1.5 Memory Constraints
Memory requirement is 1 GB RAM or more.
2.1.6 Operations
2.2 Product Functions
User will get registered and after login user have to enter username and password.User will search the friend with whom he want to chat if it is not present int the list then the friend will get added to the list .For group chat user have to add friends and for the meetup user have to enter their current location.
1. Login and registration
2. One to one/group chat
3. Meet up location
2.3 User Characteristics
Anyone can use this application. A person who does not have much technical
knowledge can even use this application for chat and meet.
2.4 Constraints
HARDWARE REQUIREMENT:
PROCESSOR : 32 BIT, Pentium
RAM : 1 GB
HARD DISK : 40 GB
MONITOR : SVGA Monitor (800 * 600 RESOLUTIONS)
CLOCK SPEED : 266 MHz
SOFTWARE REQUIREMENT:
OPERATING SYSTEM : Android.
FRONT END : J2ME, Android Studio
BACK END : MySQL Lite
2.5 Assumptions and Dependencies
–N.A.’
2.6 Apportioning of Requirements
–N.A.–
3. Specific Requirements
3.1 External interfaces
N.A
3.2 Functions
A relationship where two entities are participating is called a binary relationship. Cardinaliy is
the number of instance of an entity from a relation that can be associated with the relation.
‘ One-to-one ‘ when only one instance of an entity is associated with the relationship, it is marked as '1:1'. The following diagram has only four instance of each entity should be associated with the relationship. It depicts one-to-one relationship.
‘ One-to-many ‘ When more than one instance of an entity is associated with a relationship, it is marked as '1:N'. The following diagram has only four instance of entity on the left and more than one instance of an entity on the right can be associated with the relationship. It depicts one-to-many relationship.
‘ Many-to-one ‘ when more than one instance of entity is associated with the relationship, it is marked as 'N:1'. The following diagram reflects that more than one instance of an entity on the left and only one instance of an entity on the right can be associated with the relationship. It depicts many-to-one relationship.
‘ Many-to-many ‘ The following diagram reflect that more than one instance of an entity on the left and more than one instance of an entity on the right can be associated with the relationship. It depicts many-to-many relationship.
‘ Participation Constraints
‘ Total Participation ‘ each entity is involved in the relationship. Total participation is represented by double lines.
‘ Partial participation ‘ Not all entities are involved in the relationship. Partial participation is represented by single lines.
Figure 2. E-R diagram
‘ DFD: DATA FLOW DIAGRAM (LEVEL-0)
A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system, modeling its process aspects. A DFD is often used as a preliminary step to create an overview of the system without going into great detail, which can later be elaborated.
‘ ACTIVITY DIAGRAM
An activity is the specification of a parameterized sequence of behaviour . An activity is
shown as a round-cornered rectangle enclosing all the actions, control flows and other
elements that make up the activity.
This Activity Diagram Contains:-
o Actions
An action represents a single step within an activity. Actions are denoted by round-
cornered rectangles.
o Control Flow
A control flow shows the flow of control from one action to the next. Its notation is a line
with an arrowhead.
o Initial Node
An initial or start node is depicted by a large black spot.
o Final Node
There are two types of final node: activity and flow final nodes. The activity final node is
depicted as a circle with a dot inside.
o Objects and Object Flows
An object flow is a path along which objects or data can pass. An object is shown as a
rectangle. An object flow is shown as a connector with an arrowhead denoting the
direction the object is being passed. An object flow must have an object on at least one of
its ends. A shorthand notation for the above diagram would be to use input and output
pins.
o Decision and Merge Nodes
Decision nodes and merge nodes have the same notation: a diamond shape. They can both
be named. The control flows coming away from a decision node will have guard
conditions which will allow control to flow if the guard condition is met. The following
diagram shows use of a decision node and a merge node.
o Fork and Join Nodes-Forks
These joins have the same notation: either a horizontal or vertical bar (the orientation is
dependent on whether the control flow is running left to right or top to bottom). They
indicate the start and end of concurrent threads of control. The following diagram shows
an example of their use.
o Expansion Region
An expansion region is a structured activity region that executes multiple times. Input and
output expansion nodes are drawn as a group of three boxes representing a multiple
selection of items. The keyword "iterative", "parallel" or "stream" is shown in the top left
corner of the region.
o Exception Handlers
Exception Handlers can be modeled on activity diagrams.
o Interruptible Activity Region
An interruptible activity region surrounds a group of actions that can be interrupted. In the
very simple example below, the "Process Order" action will execute until completion,
when it will pass control to the "Close Order" action, unless a "Cancel Request" interrupt
is received, which will pass control to the "Cancel Order" action.
‘ STATE DIAGRAM
o Transition:
An arrow indicating the Object to transition from one state to the other. The actual trigger
event and action causing the transition are written beside the arrow, separated by a slash.
Transitions that occur because the state completed an activity are called triggerless
transitions. If an event has to occur after the completion of some event or action, the event
or action is called the guard condition
o History States:
A flow may require that the object go into a trance, or wait state, and on the occurrence of
a certain event, go back to the state it was in when it went into a wait state’its last active
state.
o Event and Action:
A trigger that causes a transition to occur is called as an event or action. Every transition need
not occur due to the occurrence of an event or action directly related to the state.
o Signal:
When an event causes a message/trigger to be sent to a state, that causes the transition;
then, that message sent by the event is called a signal. Represented as a class with the
<<Signal>> icon above the action/event.
o Final State:
The end of the state diagram is shown by a bull's eye symbol, also called a final state. A final state is
another example of a pseudo state because it does not have any variable or action
‘ FLOW CHART
‘ USE-CASE DIAGRAM
‘ Use case diagram are used to gather a usage requirement of a system. Depending on your requirement you can use that data in different ways. Below are few ways to use them.
‘ To identify functions and how roles interact with them ‘ The primary purpose of use case diagrams.
‘ For a high level view of the system ‘ Especially useful when presenting to managers or stakeholders. You can highlight the roles that interact with the system and the functionality provided by the system without going deep into inner workings of the system.
‘ To identify internal and external factors ‘ This might sound simple but in large complex projects a system can be identified as an external role in another use case.
Use Case Diagram objects
1. Actor
2. Use Case
3. System
4. Package
o Actor
‘ Actor
‘ Actor in a use case diagram is any entity that performs a role in one given system.
This could be a person, organization or an external system and usually drawn like
skeleton shown below.
o Use Case:
‘ A use case represents a function or an action within the system. It’s drawn as an oval and named with the function.
o System:
‘ System is used to define the scope of the use case and drawn as a rectangle. This an optional element but useful when you're visualizing large systems. For example you can create all the use cases and then use the system object to define the scope covered by your project. Or you can even use it to show the different areas covered in different releases.
‘ Screen Shots
‘ One to One
‘ Chat and Meet
3.3 Performance Requirements
The address and pickup time given by the user must be valid so that delivery boy
could receive the scrap items easily and efficiently.
3.4 Logical Database Requirements
For this application, Logical Database is required to store user’s details like pickup
date, time and address.
3.5 Design Constraints
3.5.1 Standards Compliance
There is so much competition in the industries of technology and features provided by the industries .As in that case for maintaining positions in the market one have to enhance their application in each and every edge of the life so that they can tied up their customers and as in software application development ,it’s a rule or we can say the necessity of any software to maintain it in the changing environment according to the ease of customers so our additional feature just give one more facility as well as an easiness in the handheld applications for finding out the locations for any kind of meet ups and gatherings based on both formal and informal.
3.6 Software System Attributes
Different attributes will make the system more compatable:
3.6.1 Reliability : System will be reliable
3.6.2 Availability : System can be use at any time
3.6.3 Security : System is very much secure because only single person that is
admin is using the system, so less chance of frauds.
3.6.4 Maintainability : Once the system is developed it is not needed to be much
maintained.
3.6.5 Portability : System is portable if JDK is installed in the system.
3.7 Organizing the Specific Requirements
–N.A.’
3.8 Additional Comment
–N.A.–
4. Change Management Process
Change can be done as per the requirement of the user. Coding can be done to achieve
any change in the existing application.
5. Document Approvals
Name-Ms. Arti Gautam
Signature
r text in here…