Visit Bangladesh SRS

Visit Bangladesh SRS
SPL-2
Software Requirement
Specification and Analysis
Visit Bangladesh
An Android App
Course: SE 505
Submitted by
S.M. Shahriyar (BSSE 0902)

Sudip Kumar Sah (BSSE 1040)
BSSE Session: 2016-2017
Supervised by
Sumon Ahmed
Assistant Professor
Institute of Information Technology

University of Dhaka
Date: 16/03/202
Acknowledgement
We are highly indebted for getting such a wonderful opportunity to prepare the
Software Requirements Specifications report of the project ‘Visit Bangladesh’. We
would like to thank whole-heartedly our supervisor, Sumon Ahmed, Assistant
Professor, Institute of Information Technology, University of Dhaka, our teacher,
Nadia Nahar, Lecturer, for giving us guidelines on preparing this report.
Abstract
A majority of smartphone users use navigation apps. Visit Bangladesh is a daily

life android application for navigation purpose. The application provides both
Bengali and English voice assistance in the course from source to destination. The
user of the android application can not only suit himself but also aid others with
information regarding routes. This documentation illustrates the objective and
overall overview of the Software Requirement Specification of the android
application Visit Bangladesh.
1
Table of Contents
Chapter 1: Introduction 7
1.1 Purpose 7
1.2 Intended Audience 7
1.3 Conclusion 8
Chapter 2: Inception 9
2.1 Introduction 9
2.1.1 Identifying Stakeholders 11
2.1.2 Recognizing Multiple Viewpoints 12
2.1.3 Working towards collaboration 13
2.1.4 Asking the First Questions 15
2.2 Conclusion 15
Chapter 3: Elicitation 16
3.1 Introduction 16
3.2 Eliciting Requirements 16
3.2.1 Collaborative Requirements Gathering 17
3.2.2 Quality Function Deployment 17
3.4.2.1 Normal Requirements 18
3.4.2.2 Expected Requirements 19
3.4.2.3 Exciting requirements 20
3.2.3 Usage scenario 21
Chapter 4: Scenario Based Modeling 25
4.1 Introduction 25
4.2 Use Case Scenario 25
4.3 Use Case Descriptions 26
4.3.1 Authentication 26
2
4.3.2 Browse 28
4.3.3 Navigation 30
4.3.4 Geo-fencing 33
4.4 Use Case Diagrams 37
4.5 Activity Diagrams and Swimlane Diagrams for generated Use Cases 40
Chapter 5: Data Modeling 68
5.1 Data modeling concept 68
5.2 Data objects 68
Chapter 6: Class Based Modeling 78
6.1 Class Based Modeling Concept 78
6.2 General Classification 78
6.3 Selection Criteria 81
6.4 Associate Noun and Verb Identification 82
6.5 Attribute Selection 83
6.6 Methods Identification 84
6.7 Finalizing Classes 85
6.8 Class Cards 86
6.8 UML Diagram 91
Chapter 7: Flow-Oriented Model 92
7.1 Introduction 92
7.2 Data Flow Diagram (DFD) 92
Chapter 8: Behavioral Model 98
8.1 State Diagram 98
8.2 Sequence Diagram 105
3
Table of Figures
Figure 1: Level 0 for Visit Bangladesh............................................................................................32
Figure 2: Level 1 for Visit Bangladesh............................................................................................33
Figure 3: Level 1.1 for Visit Bangladesh.........................................................................................34
Figure 4: Level 1.1.1 for Visit Bangladesh......................................................................................34
Figure 7: Level 1.3.1 for Visit Bangladesh......................................................................................36
Figure 10: Level 1.5.1 for Visit Bangladesh....................................................................................37
Figure 11: Level 1.6 for Visit Bangladesh.......................................................................................38
Figure 12: Activity diagram for Sign In..........................................................................................39
Figure 13: Swimlane diagram for Sign In........................................................................................40
Figure 14: Activity diagram for Register.........................................................................................41
Figure 15: Swimlane diagram for Register......................................................................................42
Figure 16: Activity diagram for Guest User.....................................................................................43
Figure 17: Swimlane diagram for Guest User..................................................................................44
Figure 13: Activity diagram for Browse Map..................................................................................46
Figure 14: Swimlane diagram for Browse Map................................................................................47
Figure 15: Activity diagram for Search Place..................................................................................48
Figure 16: Swimlane diagram for Search Place................................................................................49
Figure 17: Activity diagram for Show Details..................................................................................50
Figure 18: Swimlane diagram for Show Details...............................................................................51
Figure 19: Activity diagram for Set Direction Aid............................................................................52
Figure 20: Swimlane diagram for Set Direction Aid.........................................................................53
Figure 21: Activity diagram for Send Direction Aid.........................................................................54
Figure 22: Swimlane diagram for Send Direction Aid.......................................................................55
Figure 23: Activity diagram for Edit Direction Aid..........................................................................56
Figure 24: Swimlane diagram for Edit Direction Aid........................................................................57
Figure 25: Activity diagram for Update position..............................................................................58
4
Figure 26: Swimlane diagram for Update position............................................................................59
Figure 27: Activity diagram for Set Parental Control........................................................................60
Figure 28: Swimlane diagram for Set Parental Control.....................................................................61
Figure 29: Activity diagram for Edit Parental Control.......................................................................62
Figure 30: Swimlane diagram for Edit Parental Control....................................................................63
Figure 31: Activity diagram for Restrict Area..................................................................................64
Figure 32: Swimlane diagram for Restrict Area...............................................................................65
Figure 33: Activity diagram for Edit Restrict Area...........................................................................66
Figure 34: Swimlane diagram for Edit Restrict Area.........................................................................67
Figure 35: Entity Relationship diagram for E-Shongee.....................................................................72
Figure 36: UML diagram for E-Shongee.........................................................................................91
Figure 37: Level 0 DFD diagram for E-Shongee..............................................................................92
Figure 38: Level 1 DFD diagram for E-Shongee..............................................................................93
Figure 39: Level 2.1 DFD diagram for E-Shongee...........................................................................94
Figure 43: Database Class State Diagram for E-Shongee..................................................................98
Figure 44: Geofence Class State Diagram for E-Shongee..................................................................99
Figure 45: Map Class State Diagram for E-Shongee.......................................................................100
Figure 46: Notification Class State Diagram for E-Shongee............................................................101
Figure 47: Route Class State Diagram for E-Shongee.....................................................................102
Figure 48: System Class State Diagram for E-Shongee...................................................................103
Figure 49: Waypoint Class State Diagram for E-Shongee...............................................................104
Figure 50: Sequence diagram (Sign In).........................................................................................105
Figure 51: Sequence diagram (Sign Up)........................................................................................106
Figure 52: Sequence diagram (Manage Account)...........................................................................107
Figure 53: Sequence diagram (Browse Map).................................................................................108
Figure 54: Sequence diagram (Search Place and Show Details).......................................................109
Figure 55: Sequence diagram (Set Direction Aid)..........................................................................110
Figure 56: Sequence diagram (Edit Direction Aid).........................................................................111
Figure 57: Sequence diagram (Send Direction Aid)........................................................................112
Figure 58: Sequence diagram (Set Parental Control).......................................................................113
Figure 59: Sequence diagram (Edit Parental Control).....................................................................114
Figure 60: Sequence diagram (Restrict Area).................................................................................115
Figure 61: Sequence diagram (Edit Restrict Area)..........................................................................116
5
List of Tables
Table 1: Noun Identification.......................................................................................................... 60
Table 2: Final Data objects............................................................................................................ 61
Table 3: Relational Schema (User).................................................................................................63
Table 4: Relational Schema (Place)................................................................................................63
Table 5: Relational Schema (User Searches Place)...........................................................................64
Table 6: Relational Schema (User Notifies User).............................................................................64
Table 7: Relational Schema (Route)...............................................................................................65
Table 8: Relational Schema (User Follows Route)...........................................................................65
Table 9: Relational Schema (User Shares Route).............................................................................66
Table 10: Relational Schema (Route Contains Waypoints)................................................................67
Table 11: Relational Schema (User creates Geo-fence).....................................................................67
Table 12: Noun of General Classification........................................................................................70
Table 13: Potential Classes............................................................................................................ 71
Table 14: Associate Noun and Verb...............................................................................................72
Table 15: Attribute Selection......................................................................................................... 73
Table 16: Method Identification.....................................................................................................75
Table 17: Class Card (User)........................................................................................................... 76
Table 18: Class Card (System).......................................................................................................77
Table 19: Class Card (Database)....................................................................................................77
Table 20: Class Card (Map)........................................................................................................... 78
Table 21: Class Card (Route).........................................................................................................78
Table 22: Class Card (Waypoint)...................................................................................................79
Table 23: Class Card (Geo-fence)..................................................................................................79
Table 24: Class Card (Notification)................................................................................................80
6
Chapter 1: Introduction
This chapter is a part of Software Project Lab-2(SPL-2), intended to specify the
purpose of this document and the intended audience of it.
1.1 Purpose
This document is the Software Requirements Specification (SRS) for Visit

Bangladesh which is the name of our project for SPL-2. It contains detailed
functional, non-functional, and support requirements and establishes a
requirements baseline for development of the android app. The requirements
contained in the SRS are independent, uniquely numbered, and organized by topic.
The SRS serves as the official means of communicating user requirements to the
developer and provides a common reference point for both the developer team and
stakeholder community. The SRS will evolve over time as users and developers
work together to validate, clarify and expand its contents.
1.2 Intended Audience
7
This SRS is intended for several audiences, including the customers, as well as the
project managers, designers, developers, and testers.
● The customer will use this SRS to verify that the developer team has created a
product that is acceptable to the customer.
● The project managers of the developer team will use this SRS to plan milestones
and a delivery date, and ensure that the developing team is on track during
development of the system.
● The designers will use this SRS as a basis for creating the system’s design. The
designers will continually refer back to this SRS to ensure that the system they are
designing will fulfill the customer’s needs.
● The developers will use this SRS as a basis for developing the system’s
functionality. The developers will link the requirements defined in this SRS to the
software they create to ensure that they have created software that will fulfill all of
the customer’s documented requirements.
● The testers will use this SRS to derive test plans and test cases for each
documented requirement. When portions of the software are complete, the testers
will run their tests on that software to ensure that the software fulfills the
requirements documented in this SRS. The testers will again run their tests on the
entire system when it is complete and ensure that all requirements documented in
this SRS have been fulfilled.
8
1.3 Conclusion
This analysis of the audience helped us to focus on the users who will be using our
analysis. This overall document will help each and every person related to this
project to have a better idea about the project.
Chapter 2: Inception
In this chapter, the Inception part of the SRS will be discussed briefly.
9
2.1 Introduction
Inception is the beginning phase of requirements engineering. It defines how does

a software project get started and what is the scope and nature of the problem to be
solved. The goal of the inception phase is to identify concurrence needs and
conflict requirements among the stakeholders of a software project. To establish
the groundwork we have worked with the following factors related to the inception
phases:
➢ Identifying Stakeholders
➢ recognizing multiple viewpoints

➢ Working towards collaboration
➢ Asking the First Questions
10
2.1.1 Identifying Stakeholders
Stakeholder refers to any person or group who will be affected by the system
directly or indirectly. Stakeholders include end-users who interact with the system
and everyone else in an organization that may be affected by its installation. At
inception, a list of people who will contribute input as requirements are elicited.
The initial list will grow as stakeholders are contacted because every stakeholder
will be asked: “whom else do you think I should talk to?”
The following stakeholders were identified for the Visit Bangladesh.
➢ Customer: A customer is an individual or business that purchases or consumes

the goods or services produced by a business. Attracting customers is the primary
goal of most businesses as it is the customer who creates demand for goods or
services. In our case the customer is the end user of the mobile application. The
demands of the end user will be of top most priority for developing the mobile
application.
➢ Software Developer: A software developer is concerned with facets of the

software development process, including the research, design, programming,
maintenance and testing of computer software. She will be responsible for the
outcomes of the software.
11
2.1.2 Recognizing Multiple Viewpoints
Different stakeholders demand different features from the software. To satisfy the
stakeholders, most of these features should be included in the software.
Customers’ viewpoint
● Allow any user to search for various places on the map
● Allow user to find know his/her own current location
● Supply user with appropriate route from source address to destination address
● Edit route information according to will
● Supply audio data for navigation
● Able to send the customized route information to another user
Developer’s viewpoint
● Easy to built
● Error free effective software
● No conflicting requirement
12
● Getting maximum experience from development
2.1.3 Working towards collaboration
While working with different customers, some conflicting and common viewpoints
can be noticed. For this reason, final requirements can be obtained by collaborating
the viewpoints. We followed following steps to merge these requirements:
Identify the common and conflicting requirements
Categorize the requirements
Take priority points for each requirements from customers and on the basis of this
voting prioritize the requirements
Make final decision about the requirements
Common Requirements:
 Android application interfaces

 The application can be accessed from any android device that has internet
access.
 Allow any user to navigate the map
 Allow any user to search for location
13
 Maintain a database for all users and all locations in the system
Conflicting Requirements:
● Strong authentication problem when sign in

● Weather unauthorized user allowed to navigate map
Final Requirements:
● Error free authenticated accessible system

● Android-based interfaces
● Accessible via any android device about Android API version 24
● Allow valid users to login and logout.
● Restrict access to functionality of the system based upon user roles
● Allow registered user to search for places in the application after following
proper login method
● Allow valid users that log in to get route from source to destination
● The server only needs to be installed and maintained on one computer
● Allows valid users to modify the route generated initially
● Maintain a database of all places and all users.
● Allows user to have parental privileges
● Allows user to set restrictions to users to whom they have parental control
● The system should send proper push notifications
Restrict access to functionality of the system based upon user roles. For example,
only users with parental control over other user can set restrictions for places and
not the other way around.
14
2.1.4 Asking the First Questions
We set our first set of context-free questions focuses on the customer, overall
project goals and benefits. The questions are mentioned above. These questions
helped us to identify all customers, measurable benefit of the successful
implementation and possible alternatives to custom software development. Next
set of question helped us to gain a better understanding of problem and allows the
customer to voice his or her perception about the solution. The final set of question
focused on the effectiveness of the communication activity itself.
2.2 Conclusion
Inception phase helped us to establish basic understanding about “E-Shongee” in a

library, identify the people who will be benefited if the application is developed,
define the nature of the android application and establish a preliminary
communication with our users. More studies and communication will help both
side (developer and client) to understand the future prospect of the project.
Chapter 3: Elicitation
15
This chapter specifies the Elicitation phase.
3.1 Introduction
Requirements Elicitation is a part of requirements engineering that is the practice

of gathering requirements from the users, customers and other stakeholders. Many
difficulties were faced, like understanding the problems, making questions for the
stakeholders, limited communication with the stakeholders due to a short amount
of time and volatility. Though it is not easy to gather requirements within a very
short time, these problems have been surpassed in an organized and systematic
manner.
3.2 Eliciting Requirements
The main task of this phase is to combine the elements of problem solving,
elaboration, negotiation and specification. The collaborative working approach of
the stakeholders is required to elicit the requirements. The following tasks were
done for eliciting requirements:
1. Collaborative Requirements Gathering

2. Quality Function Deployment
3. Usage Scenarios
4. Elicitation work products
16
3.2.1 Collaborative Requirements Gathering
Many different approaches to collaborative requirements gathering have been

proposed. Each makes use of a slightly different scenario. We completed following
steps to do it.
● The meetings were conducted with a few customers, questioned about their
requirements and expectations from E-Shongee
● The customers were asked which requirements should be added to the
application
● At last we selected our final requirements from the discussions
3.2.2 Quality Function Deployment
Quality Function Deployment (QFD) is a technique that translates the needs of the
customer into technical requirements for software. It concentrates on maximizing
customer satisfaction from the Software engineering process. With respect to our
project the following requirements are identified by a QFD.
17
3.4.2.1 Normal Requirements
The normal requirements are generally the objectives and goals that are stated for a
product or system during meetings with the customer. The presence of these
requirements fulfills customers’ satisfaction. These are the normal requirements for
the project.
 Android application
 Accessible via the Internet.
 Allow any user to search for places.
 Allow Administrators to check user information(not personal)
 Allow valid users to login and logout
 Restrict access to functionality of the system based upon user roles
 Allow valid users that log in to navigate the map
 Getting information about preferred locations and search strings
 The server only needs to be maintained on one computer.
 User manual and guidelines
 Storing information regarding favorite places
 Storing profit records for autosuggestions
 Using limited budget for making the software
 Keeping track of restricted areas
 Storing accurate records of transactions
 Identifying restricted locations
 Contacting users in times of danger
 Calculating distance between source and destination
18
3.4.2.2 Expected Requirements
These requirements are intrinsic to the product or system and may be so

elementary that the customer does not explicitly state them. Their absence will be a
cause for significant dissatisfaction. Below the expected requirements for our
project are briefly described.
 Error free software

 Strong authentication system
 User friendly
 Effective system
 No ambiguous feature
 Data backup
 Allow administrators to change data for the user
 The system shall automatically check the location availability
 The system shall allow the user to login based upon an assigned phone
number
 Search locations based on search text
 Share navigation information to other users
 Restrict user from entering/ leaving marked area
19
3.4.2.3 Exciting requirements
These requirements are for features that go beyond the customer's expectations and
prove to be very satisfying when present
 The user interface should provide appropriate error messages for invalid
input as well as tool-tips and guidelines
 The user interface should follow standard android application interface
practices such as navigation bars search panels etc.
 Offer log in with mobile phone number after sending verification code to
number
 Confirming parental supervision by generating code
 Autosuggestion of places based on country
 Change view of map
 Change mode of navigation
 Add audio based aid in routing
 Send navigation route to other users after establishing proper connection\
 Users can modify the route and shared routes will be updated after
confirming modification
 System sends notification to users informing current situation of friends and
family
 Alerts user when getting closer to destination
20
3.2.3 Usage scenario
Authentication
Sign Up:
In the android application, there is an authentication part, where it allows the

user to access the system. Users of this system are the mass people. To access
the system, a user requires an account and for that he/she must fill up a form.
Users have to give first name, last name, email id, address, and phone number.
No user name can contain any number, punctuation mark or any special
character and the length of the name should be between 2 characters and 30
characters. There will be duplicity and validity (syntax) checking for email and
mobile number. If all the information is correct, user will be sent a verification
code to his/her phone number. The process will require the phone number at
first. Later a verification code and the user has to insert the code in appropriate
field within 60 seconds. If the phone number is new to the system then a form
will show up asking for further personal information such as name, email,
home location etc. Each user will have a unique user_id.
Sign in:
If any user has an account, he/she can sign in to the system. To sign in, user
has to give his/her mobile number and enter the verification code that will be
sent to the number. The mobile number and code will be verified. If the
verification is successful, the user can sign in to the system successfully. If the
code/number is wrong, there is a retry option.
21
Sign Out:
User has an option to log out from the system. The phone number associated
with the user will be displayed on the login application interface.
Manage Account:
Any user can change their information. To change information, he/she has to sign in then change
information. He/she has to confirm the changes and the changes will be confirmed.
Browse
Browse Map:
When the user logs in to the android application then a map will be loaded. If location and gps
permissions are not enabled then the application would require user approval for gps services.
The current location of the user will be displayed on the map and the user can swipe the map to
view adjacent places. The user can zoom on/zoom out the map to provide more detail about the
area.
Search Place:
There must be a search bar to search for locations with the name of the places and the data will
be retrieved from the database of place having a unique place_id. The location could be a
specific shop or an area. The search panel will provide auto suggestions of places in Bangladesh.
The system will keep a cache of user’s choice ad make a list of recommended from previous
searches. If user wants to see, system can show a list of recommended location for him/her. After
the search has been completed and a place is selected, the camera will move to the specified
place.
Place Detail:
If the user selects a specific place and wants to know details about the place then the system
will provide with information about the place such as place-type, latitude, longitude etc.
22
Navigation
Update Position:
When a user changes his/her location then it is tracked by the gps system of the android device
and the application gets notified about the change in position. The marker of current location is
also changed based on the actual location of the user. There must be internet availability for the
gps system to track the user. This procedure is also applicable during navigation from source to
destination. If direction is set by other user then after getting close to the destination, the sender
will get informed continuously with approximate time for arrival.
Set Direction Aid:
When the user selects a destination address and wishes to get directions to the address, then a
route will be generated from the user’s current location to that specified destination. The routing
information made by the user will be stored in the database with a route_id. The user can also
change the source address and then generate the route for the selected source and destination
address. The users can also modify the way points in the route by selecting a specific waypoint
and can also add multimedia such as audio aid for a specific waypoint.
Send Direction Aid:
After setting the direction aid, the user can send the navigation aid to other users via phone
number. This route with multimedia aid will be shown in the receiving side if the user wishes to
accept the coming routing information.
Edit Direction Aid:
Once the direction is obtained from source to destination, it can be modified using voice aided
information. Even after the data is sent to other users it can be modified by the user who made
the direction aid. One the modification of navigation information is completed, the user will
confirm the change and the change will be updated to other users who are concerned. And the
receiving side will be notified about the change.
23
Geo-fencing
Set Parental Control:
A user can set restriction in areas to visit to other users only after following some procedures.
After a user sends request for parental control using phone number of other users. Then a
confirmation code generated by other user will be required for the confirmation of the process.
The code generated will be unique for each user. The user can have parental control over various
users. Appropriate notification will be sent to each of the users with a notification_id.
Edit Parental Control:
A user can modify the list of parents i.e. can remove or add new users to allow restriction and
monitoring. Information of user will be sent to the listed users accordingly. If a user wishes to
remove a user as parent, then notification will be send to the other user. This process will be
completely effective only after confirming the actions.
Restrict Area:
A user can set restriction in areas to visit to other users if and only if the user has parental
control over the intended user. The user can set the restriction area in two ways-
1. Placing markers to draw polygon
2. Selecting center and radius on the map to draw circle
The restriction can work in both ways which will be determined by the parent user. One of the
ways would be determining the inner fence and the other would be the outer fence. If the user
enters/leaves the restricted area then the parental user responsible for that particular restriction
will be alarmed. The fence will have a geofence_id for each.
Edit Restrictions:
A user can see the restrictions set by other users. First the user can see all the restrictions set
by various users in the map. On the hand, the user can select specific parental user and see the
restrictions set by that user on the map. He/she can also request for a restriction to be removed to
the parental users and thus appropriate notifications will be sent. If the parent agrees then that
particular restriction will no longer be valid and will not be valid to the user.
24
Chapter 4: Scenario Based Modeling
4.1 Introduction
In this model the system is described from the user’s point of view. As this is the
first model, it serves as input for creation of other modeling elements.
4.2 Use Case Scenario
Level 0 Level 1 Level 2 Level 3
Log In Reset Password
Register
Authentication
Guest User
Images of tourist places
Browse Name and Facts of places
Route to tourist places
Comments and Reviews
Add image
Update
Add new places Add details
Visit Bangladesh
Add comments
Add route
Search by State/Division
Search Search by names of places
Change profile
picture
Settings Edit Account
Reset Username
Emergency
Add contact
Contact
Send notification
25
4.3 Use Case Descriptions
4.3.1 Authentication
4.3.1.1 Register
Use Case: Register

Primary Actor: User, Guest User, Admin
Goal in context: To create an account
Preconditions:
1. System has been designed for Sign up
2. System has interface for Sign
up
Triggers: Customer has to sign up
Scenario:
1. Run app and sign up
2. Provided phone number
3. Check availability of phone number
4. Verify information
5. Send verification code
6. Match input verification code
7. Provide required information
Exception:
1. Same phone number
2. Mismatched verification code
3. Time limit exceeded
4.3.1.2 Log In
Use Case: Log In
26
Primary Actor: User, Admin
Goal in context: To enter the system
Preconditions:
1. System has been designed for login
2. System has interface for login
Scenario:
1. Visit page and login
2. Provide the required information
3. Proceed to App Interface
Exception:
1. Unrecognized phone number
2. Wrong verification code
4.3.1.3 Guest User

Use Case: Guest User
Primary Actor: Guest User
Goal in context: One can only view different places
Preconditions:
1. System has been designed for Guest user
2. This type of user cannot access all section of app
3. This type of user do not need to login
Scenario:
1. Can view tourist places
Exception:
1. User not logged in
27
4.3.2 Browse
4.3.2.1 Images of Tourist places

Use Case: Browse images
Primary Actor: User, Guest User
Goal in context: To browse the images of visiting places
Preconditions:
1. System has been designed for viewing images of places
2. System has interface for browsing
3. Has list of images
Triggers: Customer wants to view images of visiting places
Scenario:
1. Complete Login/Guest User
2. Provide route
3. Load images based on places
Exception:
1. Collection of images
4.3.2.2 Name and Facts of places

Use Case: getting idea about visiting places of Bangladesh and their interesting
facts
Goal in context: getting knowledge of historical and tourist places
Preconditions:
1. System has been designed for making tourist to convey knowledge
2. System has interface for names and facts of places
Triggers: Customer will come to know interesting facts
28
Scenario:
1. View interesting information
Exception:
1. Invalid facts
4.3.2.3 Route
Use Case: Way to reach destination
Primary Actor: User
Goal in context: To collect overview of a specific place
Preconditions:
1. System has been designed for viewing the route to tourist place
Scenario:
1. Users have to navigate to a place
Exception:
1. Place not selected properly
4.3.3 Update
4.3.3.1 Add new places
Use Case: Update Places

Primary Actor: User
Goal in context: Enable local people to add exciting places in their locality
Preconditions:
29
1. System has been designed for making application working on large scale
2. System has interface for adding new places
Triggers: User has chance to place valuable facts to world
Scenario:
1. Approved user can directly add new place
Exception: Some user may not interested
4.3.3.1.1 Add Images

4.3.3.1.2 Add Details
4.3.3.1.3 Add Comments
4.3.3.2 Add new route

Use Case: Set Direction to reach destination
Primary Actor: User
Goal in context: To set route support
Preconditions:
1. System has been designed for finding routes
2. System has interface for showing routes
Triggers: User has to click the add directions button
Scenario:
1. Press the add directions button
2. Define mode of navigation like driving, walking, etc.
Exception:
1. Source/destination not found
2. Direction not available
4.3.4 Search
30
4.3.4.1 Search by Division/State
Use Case: Set User control

Goal in context: To perform search for different states
Preconditions:
1. System has been designed for easy search
Triggers: Customer wants to perform search
Scenario:
1. User can enter state name on navigation pane
Exception:
1. Invalid state name
4.3.4.2 Search by place

Use Case: Set user to get information
Goal in context: To make faster search to specific places
Preconditions:
1. System has been designed for modifying search operation
Triggers: Customer wants to modify search option
Scenario:
1. User can enter place name on navigation pane
Exception:
2. Invalid and unfamiliar place name
31
4.3.5 Setting
4.3.5.1 Edit Account
4.3.5.1.1 Change profile images
4.3.5.1.2 Reset Username/password
4.3.6 Emergency contact

4.3.6.1 Add contacts
4.3.6.2 Send notification
4.4 Use Case Diagrams
Figure 1: Level 0 for Visit Bangladesh
32
Figure 2: Level 1 for Visit Bangladesh
33
Figure 3: Level 1.1 for Visit Bangladesh
Figure 4: Level 1.1.1 for Visit Bangladesh
34
35
36
37
38
4.5 Activity Diagrams and Swimlane Diagrams
4.5.1 Use Case 1: Log In

Activity Diagram:
Figure 12: Activity diagram for Log In
39
Swimlane Diagram:
Figure 13: Swimlane diagram for Log In
40
4.5.2 Use Case 2: Register
Activity Diagram:
41
Figure 14: Activity diagram for Register
Swimlane Diagram:
42
Figure 15: Swimlane diagram for Register
43
4.5.3 Use Case 3: Guest User
Activity Diagram:
Figure 16: Activity diagram for Guest User
44
Swimlane Diagram:
Figure 17: Swimlane diagram for Guest User
45
4.5.4 Use Case 4: Browse
Activity Diagram:
Figure 18: Activity diagram for Browse
46
Swimlane Diagram:
Figure 19: Swimlane diagram for Browse
47
4.5.5 Use Case 5: Update
Activity Diagram:
Figure 20: Activity diagram for Update
48
Swimlane Diagram:
Figure 21: Swimlane diagram for Update
49
4.5.6 Use Case 6: Search
Activity Diagram:
Figure 22: Activity diagram for Search
50
Swimlane Diagram:
Figure 23: Swimlane diagram for Search
51
4.5.7 Use Case 7: Setting
Activity Diagram:
Figure 24: Activity diagram for Setting
52
Swimlane Diagram:
Figure 25: Swimlane diagram for Setting

53
4.5.8 Use Case 8: Emergency contact
Activity Diagram:
Figure 26: Activity diagram for Emergency contact
54
Swimlane Diagram:
Figure 27: Swimlane diagram for Emergency contact
55
Chapter 5: Data Modeling
5.1 Data modeling concept
If software requirements include the necessity to create, extend or interact with a database or
complex data structures need to be constructed and manipulated, then the software team
chooses to create data models as part of overall requirements modeling. The entity-
relationship diagram (ERD) defines all data objects that are processed within the system, the
relationships between the data objects and the information about how the data objects are
entered, stored, transformed and produced within the system.
5.2 Data objects
A data object is a representation of composite information that must be understood by the

software. Here, composite information means an information that has a number of different
properties or attributes. A data object can be an external entity, a thing, an occurrence, a role, an
organizational unit, a place or a structure.
Noun Identification
● All nouns in the scenario were identified

# Noun P/S Attributes
1 Android S
2 Application S
3 Authentication P
4 User P
5 System P
6 People S
56
7 Account P
8 Form S
9 First name S 4
10 Last name S 4
11 Email-id S 4
12 Address S 4
13 Phone number S 3,4
14 Message S 8,9,10,12,13,45
15 Length S 8,9,10,12,13,45
16 Database P
17 Information S
18 Verification code S 3,4
19 Location S 4,25,44
20 Interface S
21 Map P
22 GPS S 21
23 Services S
24 Detail S 25,39
25 Place P
26 Shop P
27 Area S 25,44
28 Cache S
29 Latitude S 25,44,39
30 Longitude S 25,44,39
31 Navigation P
32 Mode S 36,37
33 Marker S
57
34 Source S 36,37
35 Destination S 36,37
36 Direction P
37 Route P
38 Point S 39, 44
39 Waypoint P
40 Multimedia S 36, 39
41 Audio S 36
42 Sender S 45
43 Receiver S 45
44 Geo-fence P
45 Notification P
46 User_id S 4
47 Place_id S 25
48 Geofence_id S 44
49 Notification_id S 45
50 Route_id S 37
51 Distance S 37
52 Polygon S 36,37,44
53 Radius S 44
54 Center S 44
55 Parent S 4
56 Children S 4
Table 1: Noun Identification
58
Potential Data Objects:
● User: 9-13, 18-19, 46, 55-56

● Place: 19, 24, 27, 29, 30, 47
● Address: 14,15
● Route: 32, 34, 35, 39, 40, 50-52
● Polygon: 38
● Geo-fence: 19, 27, 29-30, 38, 48, 52-54
● Multimedia: 41
● Waypoint: 29-30, 40
Analysis for finalizing Data objects
● Address, polygon, multimedia are attributes of other data object. So they are not
considerable
● All other data objects can be used as data objects as they have enough importance in the
system.
Final Data objects
1 User: U_id, first name, last name, email, address, phone number, parent, children
2 Place: P_id, location, detail, latitude, longitude
3 Route: R_id, source, destination, mode, polygon, distance
4 Waypoint: R_id, latitude, longitude, multimedia
5 Geo-fence: G_id, area, latitude, longitude, polygon, radius

Table 2: Final Data objects
Entity Relationship Diagram
59
Figure 28: Entity Relationship diagram for E-Shongee
Relational Schema
60
User
Attribute Type Size
U_id NUMBER
Location VARCHAR2 80
Name VARCHAR2 50
Email VARCHAR2 50
Address VARCHAR2 80
Phone number VARCHAR2 14

Table 3: Relational Schema (User)
Place
Attribute Type Size
P_id NUMBER
Detail VARCHAR2 80
Latitude NUMBER
Longitude NUMBER
Table 4: Relational Schema (Place)
User Searches Place

Attribute Type Size
61
U_id NUMBER
Name VARCHAR2 50
Email VARCHAR2 50
Address VARCHAR2 80
P_id NUMBER
Frequency NUMBER
Detail VARCHAR2 80
Latitude NUMBER
Longitude NUMBER
Table 5: Relational Schema (User Searches Place)
User Notifies User

Attribute Type Size
Sender_id NUMBER
Receiver_id
Name VARCHAR2 50
Email VARCHAR2 50
Address VARCHAR2 80
Table 6: Relational Schema (User Notifies User)
Route
Attribute Type Size
62
R_id NUMBER
Source VARCHAR2 80
Destination VARCHAR2 80
Mode VARCHAR2 80
Polygon VARCHAR2 80
Distance NUMBER
Table 7: Relational Schema (Route)
User follows Route

Attribute Type Size
User_id NUMBER
Name VARCHAR2 50
Email VARCHAR2 50
Address VARCHAR2 80
R_id NUMBER
Source VARCHAR2 80
Mode VARCHAR2 80
Polygon VARCHAR2 80
Distance NUMBER
Table 8: Relational Schema (User Follows Route)
User Shares Route

Attribute Type Size
Sender_id NUMBER
63
Receiver_id NUMBER
Name VARCHAR2 50
Email VARCHAR2 50
Address VARCHAR2 80
R_id NUMBER
Source VARCHAR2 80
Mode VARCHAR2 80
Polygon VARCHAR2 80
Distance NUMBER
Table 9: Relational Schema (User Shares Route)
Route Contains Waypoint

Attribute Type Size
R_id NUMBER
W_id NUMBER
Latitude NUMBER
Longitude NUMBER
Multimedia VARCHAR2 80
Source VARCHAR2 80
Mode VARCHAR2 80
Polygon VARCHAR2 80
Distance NUMBER
Table 10: Relational Schema (Route Contains Waypoints)
64
User creates Geo-fence
Attribute Type Size
G_id NUMBER
Area NUMBER
Polygon VARCHAR2 80
Radius NUMBER
Latitude NUMBER
Longitude NUMBER
Parent_id NUMBER
Child_id NUMBER
Name VARCHAR2 50
Email VARCHAR2 50
Address VARCHAR2 80

Table 11: Relational Schema (User creates Geo-fence)
Chapter 6: Class Based Modeling
6.1 Class Based Modeling Concept
65
Class-based modeling represents the objects that the system will manipulate, the operations that will
applied to the objects, relationships between the objects and the collaborations that occur between
the classes that are defined.
6.2 General Classification
To identify the potential classes, nouns were selected from the solution space of the story. These
were then characterized in seven general classifications. The seven general characteristics are as
follows:
1. External entities
2. Things
3. Events
4. Roles
5. Organizational units
6. Places
7. Structures
Following are the specifications of the nouns according to the general classifications.
# Noun GC
1 Android 2
2 Application 2
3 Authentication 3
4 User 1,2,4
5 System 2,4,7
6 People 1,2
7 Account 2
8 Form
66
9 First name
10 Last name
11 Email-id
12 Address
13 Phone number
14 Character
15 Length
16 Database 2,4,7
17 Information 2
18 Verification code 4
19 Location 2,6
20 Interface 2
21 Map 1,2,7
22 GPS 2
23 Services 3
24 Detail
25 Place 1,6
26 Shop 6
27 Area
28 Cache
29 Latitude 2
30 Longitude 2
31 Navigation 3
32 Position
33 Marker
34 Source 6
35 Destination 6
67
36 Direction 2,6,7
37 Route 2,4
38 Point 2
39 Waypoint 2,6
40 Multimedia 4
41 Audio
42 Sender 2,4
43 Receiver 2,4
44 Geo-fence 2,3,4
45 Notification 2,4
46 User_id
47 Place_id
48 Notification_id
49 Geofence_id
50 Route_id
51 Process 4
52 Polygon
53 Radius
54 Circle
55 Parent 4
56 Children 4
Table 12: Noun of General Classification
6.3 Selection Criteria
The potential classes were then selected as classes by six Selection Criteria. A potential class becomes
a class when it fulfills all six characteristics.
1. Retained Information
2. Needed Services
68
3. Multiple Attributes
4. Common attributes
5. Common operations
6. Essential requirements
# Noun AC
1 Authentication 1,6
2 User 1,2,3,4,5
3 System 1,2,3,5,6
4 People 3,4
5 Database 1,2,5,6
6 Location 1,3
7 Map 1,2,3,5
8 Place 1,3
9 Shop 1
10 Navigation 2,6
11 Direction 1,4
12 Route 1,2,4,5,6
13 Waypoint 1,2,3,6
14 Multimedia 1
15 Geo-fence 1,2,3,4,6
16 Notification 1,2,4,6
Table 13: Potential Classes
6.4 Associate Noun and Verb Identification
The nouns and the verbs associated with the potential classes are identified to find out the
attributes and methods of each class.
69
# Potential Class Noun Verb
1 User Full name, phone Updating user information(full name, address,

number, email,home phone number, email, set parental control
address, profile picture,
parents, children
2 System Database, users, Sign up, sign in, log out, update database, load
waypoints, map map, store waypoints, search place, generate
route, create geo-fence for users
3 Database Table name, status, key Insert, update, delete, access, store data
4 Map Api key, location, Browse map, get location information, show
marker, waypoints, user position, load place data, draw polygon,
polygon, geo-fence remove polygon, edit polygon, show restriction
5 Route Waypoints, source, Load waypoints, track user, play multimedia on

destination, mode, user arrival of waypoint, edit route
position
6 Waypoint Latitude, longitude, Store multimedia, show place detail

detail, type, multimedia
7 Geo-fence Type, polygon, center, Create geo-fence, edit points

points
8 Notification Id, sender, receiver Send notification, parse notification

Table 14: Associate Noun and Verb
6.5 Attribute Selection
# Potential Class Noun
1 User Full name

phone number
Email
home address
profile picture
parents
children
2 System Database
users
70
Waypoints
map
3 Database Table name

Status
key
4 Map Location
Marker
Polygon
geo-fence
5 Route Waypoints
Source
Destination
Mode
6 Waypoint Latitude
Longitude
Detail
Type
multimedia
7 Geo-fence Type
Polygon
Center
points
8 Notification Sender
receiver
Table 15: Attribute Selection
6.6 Methods Identification
# Potential Class Methods
1 User ● getName()
● setName()
● getProfilePicture()
● setProfilePicture()
● getAddress()
● setAddress()
● getParent()
● setParent()
71
● getChildren()
● setChildren()
2 System ● initializeDatabase()
● initializeMap()
● validateCode()
● signUp()
● signIn()
● signOut()
● addParent()
● removeParent()
● addChild()
● removeChild()
● searchPlace()
● addRoute()
● removeRoute()
● modifyRoute()
● addGeofence()
● removeGeofence()
● modifyGeofence()
● sendNotification()
3 Database ● insert()
● delete()
● update()
● search()
4 Map ● loadMap()
● getUserPositiion()
● setUserPosition()
● getMarkers()
● setMarkers()
● drawPolygon()
● editPolygon()
● removePolygon()
● getPlaceData()
● getRoute()
● setRoute()
● getRestrictions()
● setRestrictions()
● showRestrictions()
● changeView()
5 Route ● getSource()
● setSource()
● getDestination()
● setDestination()
● getMode()
● setMode()
● getWaypoints()
72
● setWaypoints()
6 Waypoint ● getLatitude()
● setLatitude()
● getLongitude()
● setLongitude()
● getDetail()
● setDescription()
● getMultimedia()
● setMultimedia()
● modifyMultimedia()
7 Geo-fencing ● getType()
● setType()
● getPoints()
● setPoints()
● getPolygon()
● setPolygon()
● getCenter()
8 Notification ● generateMessage()
● parseMessage()
Table 16: Method Identification
6.7 Finalizing Classes
To identify the final classes, it was required to check if there can be any hierarchies, merges,
additional attributes, methods or classes. These identifications are given below:
1. No separate class for parent and child is required as the functionalities are similar and
the difference can be compared using a tag. Thus separating the two as subclasses of
user class is unnecessary.
2. Since places and waypoints indicated related attributes and methods in potential
classes, they were merged as waypoints. The same is done for directions and routes
and merged as route.
3. No authentication class is required as system can monitor the functionalities with the
cooperation of the database class.
73
6.8 Class Cards
User
Attributes Methods
● Full name ● getName()

● Phone number ● setName()
● Email ● getProfilePicture()
● Home address ● setProfilePicture()
● Profile picture ● getAddress()
● Parents ● setAddress()
● Children ● getParent()
● setParent()
● getChildren()
● setChildren()
Responsibility Collaborator
● Updating user information(full name, address, ● System

phone number, email
● Set parental control
Table 17: Class Card (User)
System
Attributes Methods
● Database ● initializeDatabase()
● User ● initializeMap()
● Route ● validateCode()
● Map ● signUp()
● Polygon ● signIn()
● signOut()
● addParent()
● removeParent()
● addChild()
● removeChild()
● searchPlace()
● addRoute()
● removeRoute()
● modifyRoute()
● addGeofence()
● removeGeofence()
● modifyGeofence()
74
● Sign up ● User
● Sign in ● Database
● Log out ● Map
● Update database
● Search place
● Generate route
● Create geo-fence for users
Table 18: Class Card (System)
Database
Attributes Methods
● Table name ● insert()

● Status ● delete()
● Query ● update()
● search()
● Insert data ● System

● Update data
● Delete data
Table 19: Class Card (Database)
Map
Attributes Methods
● Location ● loadMap()
● Markers ● getUserPositiion()
● Polygon ● setUserPosition()
● Geo-fence ● getMarkers()
● Route ● setMarkers()
● drawPolygon()
● editPolygon()
● removePolygon()
● getPlaceData()
● getRoute()
● setRoute()
● getRestrictions()
● setRestrictions()
● showRestrictions()
75
● changeView()
● Browse map ● System

● Get location information ● Geo-fence
● Track user ● Route
● Show user position
● Load place data
● Handle polygons
● Show restrictions
Table 20: Class Card (Map)
Route
Attributes Methods
● Source ● getSource()
● Destination ● setSource()
● Waypoints ● getDestination()
● Mode ● setDestination()
● getMode()
● setMode()
● getWaypoints()
● setWaypoints()
Responsibililty Collaborator
● Load waypoinits ● Map

● Store waypoints from source to destination ● Waypoint
● Store route information
Table 21: Class Card (Route)
Waypoint
Attributes Methods
● Latitude ● getLatitude()
● Longitude ● setLatitude()
● Detail ● getLongitude()
● Multimedia ● setLongitude()
● getDetail()
● setDescription()
● getMultimedia()
● setMultimedia()
● modifyMultimedia()
76
● Store multimedia ● Route
● Show place detail
Table 22: Class Card (Waypoint)
Geo-fence
Attributes Methods
● Type ● getType()
● Points ● setType()
● Polygon ● getPoints()
● Center ● setPoints()
● getPolygon()
● setPolygon()
● getCenter()
● Create geo-fence ● Map

● Modify fence
Table 23: Class Card (Geo-fence)
Notification
Attributes Methods
● Sender ● getMessage()
● Receiver ● setMessage()
● Message ● getSender()
● setSender()
● getReceiver()
● setReceiver()
● parseMessage()
● Send notification ● System

● Parse notification ●
Table 24: Class Card (Notification)
77
6.8 UML Diagram
78
Figure 29: UML diagram for E-Shongee
Chapter 7: Flow-Oriented Model

This chapter focuses on the flow oriented modeling.
79
7.1 Introduction
Although data flow-oriented modeling is perceived as an outdated technique by some software

engineers, it continues to be one of the most widely used requirements analysis notations in use
today. It provides additional insight into system requirements and flow.
7.2 Data Flow Diagram (DFD)
The DFD takes an input-process-output view of a system. In the figures, data objects are represented
by labeled arrows and transformations are represented by circles.
Figure 30: Level 0 DFD diagram for E-Shongee
80
Figure 31: Level 1 DFD diagram for E-Shongee
81
Figure 32: Level 2.1 DFD diagram for E-Shongee
82
83
84
85
Chapter 8: Behavioral Model
The behavioral model indicates how software will respond to external events.
8.1 State Diagram
State diagram represents active states for each class the events (triggers).
Figure 36: Database Class State Diagram for E-Shongee
86
Figure 37: Geofence Class State Diagram for E-Shongee
87
Figure 38: Map Class State Diagram for E-Shongee
88
Figure 39: Notification Class State Diagram for E-Shongee
89
Figure 40: Route Class State Diagram for E-Shongee
90
Figure 41: System Class State Diagram for E-Shongee
91
Figure 42: Waypoint Class State Diagram for E-Shongee
8.2 Sequence Diagram
Sequence diagram indicates how events cause transitions from object to object.
92
Figure 43: Sequence diagram (Sign In)
93
Figure 44: Sequence diagram (Sign Up)
94
Figure 45: Sequence diagram (Manage Account)
95
Figure 46: Sequence diagram (Browse Map)
96
Figure 47: Sequence diagram (Search Place and Show Details)
97
Figure 48: Sequence diagram (Set Direction Aid)
98
Figure 49: Sequence diagram (Edit Direction Aid)
99
Figure 50: Sequence diagram (Send Direction Aid)
100
Figure 51: Sequence diagram (Set Parental Control)
101
Figure 52: Sequence diagram (Edit Parental Control)
102
Figure 53: Sequence diagram (Restrict Area)
103
Figure 54: Sequence diagram (Edit Restrict Area)
104

Visit Bangladesh SRS

Uploaded by

Copyright:

Available Formats

You might also like

Visit Bangladesh SRS

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Visit Bangladesh SRS

Uploaded by

Copyright:

Available Formats

Visit Bangladesh SRS

S.M. Shahriyar (BSSE 0902)

Institute of Information Technology

A majority of smartphone users use navigation apps. Visit Bangladesh is a daily

This document is the Software Requirements Specification (SRS) for Visit

1.2 Intended Audience

Inception is the beginning phase of requirements engineering. It defines how does

➢ recognizing multiple viewpoints

➢ Asking the First Questions

The following stakeholders were identified for the Visit Bangladesh.

➢ Customer: A customer is an individual or business that purchases or consumes

➢ Software Developer: A software developer is concerned with facets of the

● Allow any user to search for various places on the map

● Allow user to find know his/her own current location

● Edit route information according to will

● Supply audio data for navigation

● Able to send the customized route information to another user

● Error free effective software

2.1.3 Working towards collaboration

Identify the common and conflicting requirements

Categorize the requirements

Make final decision about the requirements

 Android application interfaces

● Strong authentication problem when sign in

● Error free authenticated accessible system

Inception phase helped us to establish basic understanding about “E-Shongee” in a

Requirements Elicitation is a part of requirements engineering that is the practice

3.2 Eliciting Requirements

1. Collaborative Requirements Gathering

Many different approaches to collaborative requirements gathering have been

3.2.2 Quality Function Deployment

These requirements are intrinsic to the product or system and may be so

 Error free software

In the android application, there is an authentication part, where it allows the

Set Direction Aid:

Send Direction Aid:

Edit Direction Aid:

Set Parental Control:

Edit Parental Control:

4.2 Use Case Scenario

Level 0 Level 1 Level 2 Level 3

Log In Reset Password

Images of tourist places

Browse Name and Facts of places

Route to tourist places

Comments and Reviews

Search Search by names of places

Use Case: Register

Triggers: Customer has to sign up

Goal in context: To enter the system

4.3.1.3 Guest User

Primary Actor: Guest User

Goal in context: One can only view different places

4.3.2.1 Images of Tourist places

Primary Actor: User, Guest User

Goal in context: To browse the images of visiting places

Triggers: Customer wants to view images of visiting places