srs1 document - WordPress.com

advertisement

ITECH 6101

SRS Software Requirements Specification

ITECH 7602 Project

Trip Guide Team

1

Abstract:

The SRS document contains the details of the team members involved in project successful completion and the client who requested to develop an application. This SRS document enables the contract between the client and team members and also ensures client satisfaction. This document will contain details of the requirements for the application being developed by team. A list of functional and non-functional requirements will be given.

Revision Chart

Version Primary Author(s) Description of Version

Draft v0.1 Ren Zhu, Sadah

Date

Completed

01/09/2013 Initial draft created for distribution and review comments

ITECH 6101 Project SRS

2

Contents

Revision Chart ................................................................................................................................................... 1

1.

Introduction ................................................................................................................................................ 5

1.1.

Purpose of this Document: .......................................................................................................... 7

1.2.

Acronyms and Definitions .......................................................................................................... 7

Acronym .................................................................................................................................................... 7

Meaning ..................................................................................................................................................... 7

1.3.

References ................................................................................................................................... 9

2.

General Overview ...................................................................................................................................... 9

2.1.

User Characteristics .................................................................................................................... 9

2.1.1.

User interface requirements ........................................................................................................ 9

2.1.2.

Ease of Use ................................................................................................................................ 10

2.1.3.

Ease of Learning ....................................................................................................................... 10

2.2.

Functional Requirements Overview .......................................................................................... 10

2.3.

2.4.

Data Requirements Overview ................................................................................................... 10

Constraints, Assumptions, Dependencies, Guidelines .............................................................. 10

2.4.1.

Assumptions / Constraints ........................................................................................................ 11

2.4.2.

Dependencies ............................................................................................................................ 11

2.4.3.

Guidelines ................................................................................................................................. 11

2.5.

User view of Product Use ......................................................................................................... 11

3.

Functional Requirements ......................................................................................................................... 12

3.1 Browse for recommend places through menu ........................................................................................ 12

3.1.1 Description ...................................................................................................................................... 17

3.1.2 Criticality ........................................................................................................................................ 18

3.1.3 Technical Issues .............................................................................................................................. 18

3.1.4 Cost and Schedule ........................................................................................................................... 18

3.1.5 Risks ................................................................................................................................................ 18

3.1.6 Dependencies with other requirements ........................................................................................... 18

3.2 Browse places directly by map: ............................................................................................................. 18

3.2.1 Description ...................................................................................................................................... 22

3.2.2 Criticality ........................................................................................................................................ 22

3.2.3 Technical Issues .............................................................................................................................. 22

ITECH 6101 Project SRS

3

3.2.4 Cost and Schedule ........................................................................................................................... 22

3.2.5 Risks ................................................................................................................................................ 22

3.2.6 Dependencies with other requirements ........................................................................................... 22

3.3 Show Popular Places on welcome screen .............................................................................................. 22

3.3.1 Description ...................................................................................................................................... 23

3.3.2 Criticality ........................................................................................................................................ 24

3.3.3 Technical Issues .............................................................................................................................. 24

3.3.4 Cost and Schedule ........................................................................................................................... 24

3.3.5 Risks ................................................................................................................................................ 24

3.3.6 Dependencies with other requirements ........................................................................................... 24

3.4 Facebook Login ..................................................................................................................................... 24

3.4.1 Description ...................................................................................................................................... 25

3.4.2 Criticality ........................................................................................................................................ 26

3.4.3 Technical Issues .............................................................................................................................. 26

3.4.4 Cost and Schedule ........................................................................................................................... 26

3.4.5 Risks ................................................................................................................................................ 26

3.4.6 Dependencies with other requirements ........................................................................................... 26

3.5 Search places by name or key words ..................................................................................................... 26

3.5.1 Description ...................................................................................................................................... 27

3.5.2 Criticality ........................................................................................................................................ 28

3.5.3 Technical Issues .............................................................................................................................. 28

3.5.4 Cost and Schedule ........................................................................................................................... 28

3.5.5 Risks ................................................................................................................................................ 28

3.5.6 Dependencies with other requirements ........................................................................................... 28

3.6 Location Filter ........................................................................................................................................ 28

3.6.1 Description ...................................................................................................................................... 29

3.6.2 Criticality ........................................................................................................................................ 30

3.6.3 Technical Issues .............................................................................................................................. 30

3.6.4 Cost and Schedule ........................................................................................................................... 30

3.6.5 Risks ................................................................................................................................................ 30

3.6.6 Dependencies with other requirements ........................................................................................... 30

3.7 Directions ............................................................................................................................................... 30

ITECH 6101 Project SRS

4

3.7.1 Description ...................................................................................................................................... 31

3.7.2 Criticality ........................................................................................................................................ 32

3.7.3 Technical Issues .............................................................................................................................. 32

3.7.4 Cost and Schedule ........................................................................................................................... 32

3.7.5 Risks ................................................................................................................................................ 32

3.7.6 Dependencies with other requirements ........................................................................................... 32

3.8 Description of data relevant to system as appropriate ........................................................................... 32

3.8.1 Introduction ......................................................................................................................................... 32

If you use the SDK, you must comply with the Terms of Use and to ensure that your application complies with applicable laws. Note that when using the SDK, your name and version, the authentication information and an anonymous identifier cross-application automatically sent to every request.

.............. 33

3.8.2 Audience ............................................................................................................................................. 33

This documentation is designed for people with iOS development and concepts of object-oriented programming. You should also be familiar with Google Maps from the point of view of the user.

....... 33

3.8.3 Google Maps Mobile SDK for Business ......................................................................................... 33

3.8.4 Attribution Requirements .................................................................................................................... 33

3.8.5 Supported Platforms ............................................................................................................................ 33

The Google Maps SDK supports iOS 6.0 and higher. Applications that use the Google Maps URL scheme, require that the target device has installed for iOS Google Maps.

............................................................... 34

3.8.6 Getting the Google Maps SDK for iOS .............................................................................................. 34

The Google Maps SDK for iOS is available as a zip file contains a static picture distributed. After downloading the SDK, you must get an API key before you can add a tab to the application.

.................. 34

3.8.7 The Google Maps API Key ................................................................................................................. 34

Using an API key, you can use the maps to monitor the use APIs, and ensures that Google may contact you about your application, if necessary. The key is free, you can use it with any of your applications that use the Google Maps API call, and supports an unlimited number of users. You can get an API key for Google Maps API Console from your bundle identifier of the application. Once you have the key, add it as described in the following section to your AppDelegate.

.......................................................... 34

3.8.8 Obtaining an API Key ..................................................................................................................... 34

3.8.9 Adding the Google Maps SDK for iOS to your project ...................................................................... 34

3.8.10 Upgrade from an earlier version .................................................................................................. 35

3.8.11 Add a Map ........................................................................................................................................ 35

3.8.12 Street View Panoramas ..................................................................................................................... 36

4.

Non-Functional Requirements ................................................................................................................. 37

ITECH 6101 Project SRS

5

4.1 Application Theme ................................................................................................................................. 37

4.2 Easy to Use ............................................................................................................................................ 37

4.3 Language ................................................................................................................................................ 37

4.4 Network ................................................................................................................................................. 37

4.5 Data Requirements ................................................................................................................................. 37

4.6 Quality Attributes / Requirements ......................................................................................................... 38

4.6.1 Security ........................................................................................................................................... 38

There are no security issues regarding content such as database content. Without the working project files no one would be able to get to the data contained. There are no “user” or “admin” rights or issues to consider for this application. All the data contained within the application is to be freely distributed amongst the general population and there is no confidential information to hide or encrypt. Of course the source files for the application will not be distributed to the general public and will only be alterable by the developer.

...................................................................................................................................... 38

4.6.2 Reliability ........................................................................................................................................ 38

4.6.3 Maintainability ................................................................................................................................ 38

4.6.4 Other Requirements ........................................................................................................................ 38

5 Operational Scenarios ................................................................................................................................... 38

5.1 Flow of Operations ............................................................................................................................ 38

5.2 Use case scenarios .............................................................................................................................. 39

6 Appendices .................................................................................................................................................... 41

6.1 Entity Relationship Diagrams ............................................................................................................ 41

6.2 Acceptance Criteria ............................................................................................................................ 42

6.3 Declaration: ........................................................................................................................................ 44

6.4 References .......................................................................................................................................... 45

1.

Introduction

Team member

Team members: E-mail id Student id

Rajashekar donthi rajashekardonthi@gmail.com

ubs 30106226

ITECH 6101 Project SRS

6

Nalla Divya nalladivyareddy87@gmail.com

ubs30107395

Ren Zhu rzhu1140@gmail.com

ubs30115339

Raja kandasamy Rajapaj@gmail.com

ubs30102984

Sadah Suliman slmsm_sm@yahoo.com

ubs30086830

Scope:

In this modern, fast moving and insecure world, it is a basic necessity to be aware of one’s safety.

Maximum problems occur when a people traveling to a new place. We are developing an application in which it guides the people in traveling, accommodation, and for visiting beautiful locations. The application is a very unique product that has been introduced to the travel information market, though there are some similar application, ours has some unique focuses and functions.

The aim of the project it to develop a simple online digital tour guide on Sydney city for the iOS mobile device. This is user friendly and helps the user with all their requirements on a single application. This project is to be developed with the programming language “objective c”.

In detail ,the project is to develop a dedicated iOS application for the Sydney city particularly on the happening events, traditional places to visit. This makes the user to explore the culture of Sydney`s history. For using this application, the user can access in locations, navigations, event happening places, special occasions, museums, etc. All the information like weather forecast, live traffic is updated to the user to which place they are heading too.

Objective:

The main objective of this project is tracking the location of the visitor and guiding the person in traveling and accommodating around the Sydney. The aim of the project it to develop a simple online digital tour guide on Sydney city for the iOS mobile device. This is user friendly and helps the user with all their requirements on a single application.

Client:

Client can be contacted through an email or by person project supervisor at MIT, university of

Balart campus for further help regarding project.

Acceptance criteria:

Acceptance criteria will enables and ensure the project requirements (functional and non- functional) are clear and correct according to client requirements. The acceptance criteria measure the success of the project.

ITECH 6101 Project SRS

7

Client signoff:

To,

Team members

I(client), declares here according to my keen knowledge that project has been developed according my requirements and specifications.

Thanking you

Yours sincerely

Client

1.1.

Purpose of this Document:

The main purpose of this document is to outline the functional and performance requirements of the online system management backstage. This is not a document-oriented design, the design is in

Software Design Description (SDD) are described. And also the further details can be found in the

SPMP(Software Project Management Plan).

This task will be accomplished by setting out the functional and non-functional requirements of the proposed system, showing the user interfaces and explaining the documentation requirements.

The SRS serves as a contract between the Client and the project team, once completed it will be reviewed by both parties and then signed-off as being official and binding. Any future changes to the SRS must be discussed and agreed upon together by both the project team and the Client.

1.2.

Acronyms and Definitions

Any acronyms referenced in this document will be listed below:

Acronym

Api

Objective c

SDD

SPMP

SRS

Meaning

Application programming interface

Programming language for the ios app development

Software Design Description

Software Project Management Plan

Software Requirement Specification

ITECH 6101 Project SRS

WBS

GUI

IEEE

OS

IOS

QA

8

Work Breakdown Structure

Graphical User Interface

Institute of Electrical and Electronics Engineers

Operating System

Apple Operation System

Quality Assurance

ITECH 6101 Project SRS

9

1.3.

References

The following documents are referenced to produce this document:

DOCUMENT

NAME

LOCATION VERSION AUTHOR

SADD

Team Website 1.0

SPMP Team Website 1.0

Development

Team

Development

Team

External References:

1. IEEE Standard for Software Requirements Specifications (Std 830-1998)

2. Sample SRS from UB-Online.

3 Other links will be listed in the appendix(6.4)

2.

General Overview

This project is to develop a iOS application on exploring the city Sydney, Australia. This helps its users to explore the classical and traditional places of the city and its surrounding along with the current happening and the artistic occasions in the city. It will update the events on the season basis.

This application will also help the users to deliver a tour plan accordingly on their current locations.

It also navigate the user to their destination comfortably.

2.1.

User Characteristics

2.1.1.

User interface requirements

The user interface must conform to the usability and ease of learning of these conditions, so it must be clean, easy to find with all the information. Validation will be in all fields that require it, used, and context-sensitive help is being implemented to provide support for the user. Product Style

Requirements

There is no requirement for the style of the system. The components and the size of fonts, screen layout, and other features will be decided at the design stage, as the research team what will be the design more user-friendly and accessible to the end user. Customer is important for this, because that is all it is not easy for someone who is not familiar with the system to select.

ITECH 6101 Project SRS

10

2.1.2.

Ease of Use

This application takes advantage of standardized menu structures, which are not only easy to use because of their intuitiveness but also extremely easy for the user to cognitively use and understand.

2.1.3.

Ease of Learning

The system should be intuitive to use, so that the volunteers familiar with the current paperbased system can easily adapt to ios version. This will be achieved as far as possible, duplicating the current paper-based system. The ideal scenario is that any user with basic computer and features of the Web browser, and is familiar with the current paper-based system will be able to use the system without training

2.2.

Functional Requirements Overview

The application allows volunteers to search and find out the popular locations or attractions.

The system will allow users to:

Search places

Search via browsing map

Login to facebook account to give comment

View recommended restaurant

View recommended hotel

View recommended attractions

View recommended shopping locations

View recommended itineraries

Use filter to let user select recommends

Show the location on map

Give the direction information for the location

Automatically update the review of the attractions

Functional requirements are documented in further detail in - Functional Requirements

2.3.

Data Requirements Overview

The system saves all the section, competition and profit for the discipline of data recovery from users. It 'also possible to save the system configuration to enable the user pages. All historical data is also stored so that they are accessible, but also to see how the historical data.

2.4.

Constraints, Assumptions, Dependencies, Guidelines

ITECH 6101 Project SRS

11

2.4.1.

Assumptions / Constraints

The resolutions of IOS mobile device is listed below iPhone3 320x480 163 ppi iPhone4 640

×

960 326 ppi iPhone4S 640

×

960 326 ppi iPhone5 640

×

1136 326 ppi iPad 1024x768 132 ppi iPad2 1024x768 132 ppi iPad ( 3gen ) 2048x1536 264 ppi iPad ( 4gen ) 2048x1536 264 ppi iPad mini 1024x768 163 ppi

Our project will focus on the iphone first, and as the most popular iphone on the market is iphone 4/4s, our project will focus on the 640X960 resolution. This means that the images will be very small in size and in some cases

2.4.2.

Dependencies

The system depends on the leaders with accurate data. If the data in the Guide inaccurate, manual updates are considered necessary by the administrator or any other form of import.

2.4.3.

Guidelines

There are no guidelines at this stage.

2.5.

User view of Product Use

From the user point of view, we will try as much as possible, give the user the best recommendation of all the interesting places in the city.

The system stores information about events, competitors and sections, as well as their results.

2.6 Reference to industry white paper: http://www.digitaltrends.com/mobile/ios6-mountain-lion-force-apple-away-from-google/

ITECH 6101 Project SRS

12

3.

Functional Requirements

The below sections outline the specific requirements of the system.

3.1 Browse for recommend places through menu

Function ID: F1

One of the basic function is to let user browse recommend places through menu.

ITECH 6101 Project SRS

13

ITECH 6101 Project SRS

Figure 1

14

ITECH 6101 Project SRS

Figure 2

15

ITECH 6101 Project SRS

Figure 3

16

ITECH 6101 Project SRS

Figure 4

17

Figure 5

3.1.1 Description

This function is made for letting user find out the recommend places in a very quick way. For example, User could see many categorizes of different places, restaurant, hotels, attractions, itineraries, shopping those category in the main menu(Figure 1). Then they can select either one of

ITECH 6101 Project SRS

18 these go the filter (Figure 2). In the filter screen, they can choose some attributes for the places, like the distance or the prices amount they are looking for. Then they can go and get a list of the locations (Figure 3). In the list, the places will come with its name , distances information and simple price information. If user want to check the detail of any of the places, they can tap and go to the detail page(Figure 4), The page will give all the details about it. Additionally, User can go to map view of the place(Figure 5) to directly find out the location.

3.1.2 Criticality

This function is very important to the application; it’s the basic foundation of the trip guide application. This is a critical function, as most users will know the category of what they want, and the easiest way to find this information is simply by navigating by menu, not by location as the other search allows.

3.1.3 Technical Issues

In order to design this function, we must log all the data into correct form, which require a welldesigned database. Then we can input the filter function for searching. One of the hardest part is to find out the location distance based on user’s current location, for doing this, we will use the api supported by google map api. Which will give us the distance of the places and the suggested way to go there.

3.1.4 Cost and Schedule

Develop team has no cost associated with this requirement. Schedule will also be unaffected. But this function will be implemented in the early stage of the project to give time to later test.

3.1.5 Risks

Develop has no risks associated with this requirement, unless we run out of time to produce the indicated feature. However we intend to follow our schedule outlined in the Gantt in the SPMP document to reduce the probability of failure. As this is the highest ranked function it will be our main priority and we fully expect to meet this functional objective; otherwise we will consider the project a failure.

3.1.6 Dependencies with other requirements

This functional requirement does not depend on any other.

3.2 Browse places directly by map:

Function ID: F2

ITECH 6101 Project SRS

19

ITECH 6101 Project SRS

Figure 2.1

20

ITECH 6101 Project SRS

Figure 2.2

21

ITECH 6101 Project SRS

Figure 2.3

22

3.2.1 Description

This function is made for letting user find out the recommend places in a map view. For example, after the welcome screen, user can see the map menu on the main menu(Figure 2.1). If they tap the map button, it will display the map with some recommend places labled out on the map. (Figue 2.2)

Then they can select either one of these and check the detail of any of the places, they can tap and go to the detail page(Figure 2.3), The page will give all the details about it. Additionally, User can go to map view of the place(Figure 5) to directly find out the location. Which is same as last function,

3.2.2 Criticality

This function is very important to the application; it’s one of the basic foundation of the trip guide application. This is a critical function, as most users don’t need to know the category of what they want, and the easiest way to find this information is simply by navigating by map, not by map.

3.2.3 Technical Issues

In order to design this function, we must log all the data into correct form, which require a welldesigned database. Then we can input the filter function for searching. One of the hardest part is to find out the location distance based on user’s current location, for doing this, we will use the api supported by google map api. Which will give us the distance of the places and the suggested way to go there.

3.2.4 Cost and Schedule

Develop team has no cost associated with this requirement. Schedule will also be unaffected. But this function will be implemented in the early stage of the project to give time to later test.

3.2.5 Risks

Develop has no risks associated with this requirement, unless we run out of time to produce the indicated feature. However we intend to follow our schedule outlined in the Gantt in the SPMP document to reduce the probability of failure. As this is the highest ranked function it will be our main priority and we fully expect to meet this functional objective; otherwise we will consider the project a failure.

3.2.6 Dependencies with other requirements

This functional requirement does not depend on any other.

3.3 Show Popular Places on welcome screen

Function ID: F3

ITECH 6101 Project SRS

23

3.3.1 Description

This function is made for letting user to quickly go to most popular places we recommended in the moments. It should keep updating with time. For example, if it’s around April, then the eastershow will replace some normal classic attraction on the welcome screen. After tapping on the icon, user will go to the detail page to view the details.

ITECH 6101 Project SRS

24

3.3.2 Criticality

This function is optional. But it is recommended to be implemented, it could really help user to quickly locate the popular places, and it is also good in adding intuitiveness for the application.

3.3.3 Technical Issues

It got the same technical issues as the direction one and the menu function requirement.

3.3.4 Cost and Schedule

Develop team has no cost associated with this requirement. Schedule will also be unaffected. But this function will be implemented in the early stage of the project to give time to later test.

3.3.5 Risks

Develop has no risks associated with this requirement, unless we run out of time to produce the indicated feature. However we intend to follow our schedule outlined in the Gantt in the SPMP document to reduce the probability of failure.

3.3.6 Dependencies with other requirements

This functional requirement depend on the directional function.

3.4 Facebook Login

Function ID: F4

ITECH 6101 Project SRS

25

3.4.1 Description

This function is made for letting user to login to Facebook account so that they can leave comment on the attraction easily. The comment will come on their timeline with picture and link to the attraction.

ITECH 6101 Project SRS

26

3.4.2 Criticality

This function is optional. But it is recommended to be implemented, it could really help user to quickly locate the popular places, and it is also good in adding intuitiveness for the application.

3.4.3 Technical Issues

It needs the development to implement the facebook api in the application. Normally the procedure will be: ask user to give authentication permission to our application and login to their own facebook account, and then the application will has the right to publish the comment on user’s facebook timeline.

3.4.4 Cost and Schedule

Develop team has no cost associated with this requirement. Schedule will also be unaffected. But this function will be implemented in the early stage of the project to give time to later test.

3.4.5 Risks

Develop team has no risks associated with this requirement, unless we run out of time to produce the indicated feature. However we intend to follow our schedule outlined in the Gantt in the SPMP document to reduce the probability of failure.

3.4.6 Dependencies with other requirements

This functional requirement depend on the directional function.

3.5 Search places by name or key words

Function ID: F5

ITECH 6101 Project SRS

27

3.5.1 Description

This function is made for letting user find out the places by putting some key wards. For example,

In the main menu, if user tap the search icon, then the application will go the search page, user can type some key words, and the application will return a list of places. Then the procedure will be same as the last half part of the menu function, user can select the places and go check the detail or direction information.

ITECH 6101 Project SRS

28

3.5.2 Criticality

This function is very important to the application; it’s one of the basic foundations of the trip guide application. This is a critical function, as most users will know the keyword of what they want, and the easiest way to find this information is simply by putting the keyword.

3.5.3 Technical Issues

In order to design this function, we must log all the data into correct form, which require a welldesigned database. One of the hardest part is to do the search and match keywords.

3.5.4 Cost and Schedule

Develop team has no cost associated with this requirement. Schedule will also be unaffected. But this function will be implemented in the early stage of the project to give time to later test.

3.5.5 Risks

Develop team has no risks associated with this requirement, unless we run out of time to produce the indicated feature. However we intend to follow our schedule outlined in the Gantt in the SPMP document to reduce the probability of failure. As this is the highest ranked function it will be our main priority and we fully expect to meet this functional objective; otherwise we will consider the project a failure.

3.5.6 Dependencies with other requirements

This functional requirement does not depend on any other.

3.6 Location Filter

Function ID: F6

ITECH 6101 Project SRS

29

3.6.1 Description

This function is made for letting user select the filter for search all the places by thresholding some places user don’t want. For example, for restaurant, use may just want to find fine dining place without cheap prices, so they can set the filter to get the results they want.

ITECH 6101 Project SRS

30

3.6.2 Criticality

This function is very important to the application; it’s one of the basic foundations of the trip gide application. This is a critical function, as most users will know the keyword of what they want, and the easiest way to find this information is simply by putting the keyword.

3.6.3 Technical Issues

In order to design this function, we must log all the data into correct form, which require a welldesigned database. One of the hardest part is to do the search and match keywords.

3.6.4 Cost and Schedule

Develop team has no cost associated with this requirement. Schedule will also be unaffected. But this function will be implemented in the early stage of the project to give time to later test.

3.6.5 Risks

Development team has no risks associated with this requirement, unless we run out of time to produce the indicated feature. However we intend to follow our schedule outlined in the Gantt in the SPMP document to reduce the probability of failure. As this is the highest ranked function it will be our main priority and we fully expect to meet this functional objective; otherwise we will consider the project a failure.

3.6.6 Dependencies with other requirements

This functional requirement does not depend on any other.

3.7 Directions

Function ID:F7

ITECH 6101 Project SRS

31

3.7.1 Description

This function is made for showing user how to get to the places they choose. In detail, after user choose the places, it will go to map and show some routes to the places with information about the traffic.

ITECH 6101 Project SRS

32

3.7.2 Criticality

This function is very important to the application; it’s one of the basic foundations of the trip guide application. This is a critical function, by using this, user can easily find the way to the places they want.

3.7.3 Technical Issues

In order to design this function, we will use google map api. The Google API is the most helpful data for the application that are about to be developed by our team. This helps the application to acquire the required information’s like

 Weather

Location services

Map directions

Recent searches

Related search results

Favourite places

3.7.4 Cost and Schedule

Develop team has no cost associated with this requirement. Schedule will also be unaffected. But this function will be implemented in the early stage of the project to give time to later test.

3.7.5 Risks

Development team has no risks associated with this requirement, unless we run out of time to produce the indicated feature. However we intend to follow our schedule outlined in the Gantt in the SPMP document to reduce the probability of failure. As this is the highest ranked function it will be our main priority and we fully expect to meet this functional objective; otherwise we will consider the project a failure.

3.7.6 Dependencies with other requirements

This functional requirement does not depend on any other.

3.8 Description of data relevant to system as appropriate

3.8.1 Introduction

With Google Maps SDK for iOS, you can map based on data from Google Maps to your application. The SDK automatically controls access to the server of Google Maps, the map display,

ITECH 6101 Project SRS

33 and respond to user gestures, such as click and drag. You can also markers, polylines, and overlays of land and info windows to the card. These objects provide additional information for map positions and allow users to interact with the map.

If you use the SDK, you must comply with the Terms of Use and to ensure that your application complies with applicable laws. Note that when using the SDK, your name and version, the authentication information and an anonymous identifier cross-application automatically sent to every request.

3.8.2 Audience

This documentation is designed for people with iOS development and concepts of object-oriented programming. You should also be familiar with Google Maps from the point of view of the user.

3.8.3 Google Maps Mobile SDK for Business

The Google Maps Mobile SDK for Business license provides enhanced capabilities for both the

Google Maps SDK for iOS and the Google Maps Android API. If you have purchased a Google

Maps Mobile SDK for Business license, please refer to the Google Maps API for Business documentation for additional, supplementary information.

3.8.4 Attribution Requirements

If you use the Google Maps SDK for iOS application, you must include the text assignment as part of a section of legal information in the application. Includes legal information, such as a menu item or as part of an "About" menu item is recommended.

You can get the attribution text by creating a call to [GMSServices openSourceLicenseInfo]. openSourceLicenseInfo].

3.8.5 Supported Platforms

The development of an application that uses the Google Maps SDK for iOS requires the following

Xcode 4.5 or later. iOS SDK 6.0 or later.

ITECH 6101 Project SRS

34

The Google Maps SDK supports iOS 6.0 and higher. Applications that use the Google Maps URL scheme, require that the target device has installed for iOS Google Maps.

3.8.6 Getting the Google Maps SDK for iOS

The Google Maps SDK for iOS is available as a zip file contains a static picture distributed. After downloading the SDK, you must get an API key before you can add a tab to the application.

3.8.7 The Google Maps API Key

Using an API key, you can use the maps to monitor the use APIs, and ensures that Google may contact you about your application, if necessary. The key is free, you can use it with any of your applications that use the Google Maps API call, and supports an unlimited number of users. You can get an API key for Google Maps API Console from your bundle identifier of the application.

Once you have the key, add it as described in the following section to your AppDelegate.

3.8.8 Obtaining an API Key

A key for your app in the Google APIs Console can be obtained by.

1.

Create API project in Google APIs Console.

2.

Select the Services pane in your API project, enable the Google Maps SDK for iOS . This displays Google Maps Terms of Service.

3.

Select API Access pane in the console, and click the Create new iOS key .

4.

Enter one or more of the bundle identifiers as listed in your application's .plist file, such as com.example.myapp.

5.

Click Create .

6.

In the API Access page, locate section Key for iOS apps (with bundle identifiers) and then note or copy the 40-character API key .

You should repeat this process for each of the new application.

3.8.9 Adding the Google Maps SDK for iOS to your project

The Google Maps SDK for iOS is packaged as a static picture, with a package of resources provided. Before you can add a map to your application, you need the frame to the project and configure the build settings in Xcode. These instructions assume an installation for a new project. If you are working with an existing project, you might not need to follow the procedure exactly as described.

1.

Launch the Xcode and either open an existing project, or create new project. o If you are new to iOS, create a Single View Application , and then disable Use

Storyboards but ensure that the Use Automatic Reference Counting is on.

2.

Drag the GoogleMaps.framework bundle to Frameworks group of your project. When provoked, select Copy items into destination group's folder .

3.

Right-click GoogleMaps.framework in your project, and then select Show In Finder .

ITECH 6101 Project SRS

35

4.

Drag the GoogleMaps.bundle from Resources folder to your project. We recommend putting it in the Frameworks group. When prompted, ensure Copy items into target group’s folder are not selected.

5.

Select your project from Project Navigator, and then choose your application's target.

6.

Open the Build Phases tab, and in Link Binary with Libraries , add the subsequent frameworks: o o o o o o o o o o o

AVFoundation.framework

CoreData.framework

CoreLocation.framework

CoreText.framework

GLKit.framework

ImageIO.framework libc++.dylib libicucore.dylib libz.dylib

OpenGLES.framework

QuartzCore.framework o SystemConfiguration.framework

7.

Choose your project, rather than the specific target, and then open the Build Settings tab. o In Other Linker Flags section, add -ObjC. If these settings are not visible, change the filter in Build Settings bar from Basic to All .

8.

Finally, add your API key to your AppDelegate. o #import <GoogleMaps/GoogleMaps.h> o Add following to your application:didFinishLaunchingWithOptions: method, replacing API_KEY with your API key.

[GMSServices provideAPIKey:@"API_KEY"];

3.8.10 Upgrade from an earlier version

To upgrade an existing project to the most new version of the SDK, do the subsequent:

1.

In the Project Navigator, replace previous framework with the most recent framework.

2.

It is optional to make any necessary changes as a result of the upgrade. Necessary changes will be described in the release notes.

3.

Project can be cleaned and rebuilt by selecting: Product > Clean and then Product > Build .

3.8.11 Add a Map

After you add the SDK to your project and give you the keys, you can try a card for your application. The following code shows how to add a simple map to an existing view controller. If you are a new app on iOS, follow the installation instructions above, and create a new view single application; disable Terms of Use storyboard but allows you to use automatic reference counting

(ARC).

Now, add or update a view controller to create some standard methods in your application and initialize an instance GMSMapView.

ITECH 6101 Project SRS

36

#import "YourViewController.h"

#import <GoogleMaps/GoogleMaps.h>

@implementation YourViewController {

GMSMapView *mapView_;

}

// You don't need to modify the default initWithNibName:bundle: method.

- (void)loadView {

// Create a GMSCameraPosition that tells the map to display the

// coordinate -33.86,151.20 at zoom level 6.

GMSCameraPosition *camera = [GMSCameraPosition cameraWithLatitude:-33.86

longitude:151.20

zoom:6];

mapView_ = [GMSMapView mapWithFrame:CGRectZero camera:camera];

mapView_.myLocationEnabled = YES;

self.view = mapView_;

// Creates a marker in the center of the map.

GMSMarker *marker = [[GMSMarker alloc] init];

marker.position = CLLocationCoordinate2DMake(-33.86, 151.20);

marker.title = @"Sydney";

marker.snippet = @"Australia";

marker.map = mapView_;

}

@end

3.8.12 Street View Panoramas

Each view Street View is an image or group of images, which provides a full 360-degree view of a single location. The images correspond to the projection (Plate Carree) that contains vertical

(downward from upward) 360 degree horizontal view (for a complete wrap-around) and 180 degrees. The 360 degree panoramic resultant defines a projection on a sphere wrapped with the image of the two-dimensional surface of this sphere.

Street View panoramas are visible to the object GMSPanoramaView. This object provides a viewer that will make the scene as a sphere, with a camera in the middle. You can programmatically control the orientation of the camera, as well as setting various properties of the viewer.

REF: https://developers.google.com/maps/documentation/ios/start

ITECH 6101 Project SRS

37

4.

Non-Functional Requirements

4.1 Application Theme

The application will use Red(RGB: 212, 75,39) Green(RGB: 23,97,125), Orange(RGB:

247,146,30) as the theme, try to give user a feeling of energy but also with class

4.2 Easy to Use

A requirement of the system is that it is easy to use. The application should let 1 st time user can use it very smoothly, with all the intuitive icon and menu.

4.3 Language

The application will be written in Australian English.

4.4 Network

The application will run over a wireless network, which is supplied by the client.

4.5 Data Requirements

Because the purpose of this application is to store and distribute information, which must store a large amount of data. Below are the data that must be stored by the application.

Location: The location for the event will be stored in the application: e.g. Her Majesties Theatre:

Id

Name

Address

Popularity

Price

Comments

Information on application settings, display settings, etc. are also saved. These data will be documented in the SDD. Also refer to section 4.3 for the ER diagram.

ITECH 6101 Project SRS

38

4.6 Quality Attributes / Requirements

4.6.1 Security

There are no security issues regarding content such as database content. Without the working project files no one would be able to get to the data contained. There are no “user” or “admin” rights or issues to consider for this application. All the data contained within the application is to be freely distributed amongst the general population and there is no confidential information to hide or encrypt. Of course the source files for the application will not be distributed to the general public and will only be alterable by the developer.

4.6.2 Reliability

The reliability of the demo-version of the application will be guaranteed because of the fact that all data is hard-coded. As the program will never access a online database the application will always function as intended and the correct screens will be displayed. If a database is implemented in the future then the associated integration will have to be stringently tested..

4.6.3 Maintainability

To maintain this application there would have to be a new build of the project from where it was previously left. However, rebuilding and updating the project would not be a difficult task with the working files as one golf course would be used as a template to build more. For the full version of this application having a database present would greatly enhance the maintainability.

4.6.4 Other Requirements

There are no other requirements at this time. Any additional requirements will change request form to be raised and follow the procedure described in the document change control process.

5 Operational Scenarios

5.1 Flow of Operations

The following diagram represents the flow through the entire application.

ITECH 6101 Project SRS

39

5.2 Use case scenarios

5.2.1 View main Menu

1 User start the application

2 Wait for the welcome disappear

3 View main Menu

5.2.2 Browse by menu

1 User start the application

2 Wait for the welcome disappear

3 View main Menu

4 Select categories

5 Set filters

6 View list

ITECH 6101 Project SRS

7 View detail

8 Find direction

5.2.3 Browse by map

1 User start the application

2 Wait for the welcome disappear

3 View main Menu

4 Select map

5 View map with all places neayby

6 View detail

7 Find direction

5.2.4 Browse by search

1 User start the application

2 Wait for the welcome disappear

3 View main Menu

4 Select search

5 type search

6 View list

7 View detail

8 Find direction

5.2.5 Set filter

1 User start the application

2 Wait for the welcome disappear

3 View main Menu

4 Select categories

5 Set filters

5.2.6 Login Facebook

1 User start the application

2 Wait for the welcome disappear

3 View main Menu

4 Select Facebook Icon

5 Login

6 Leave Comment for palces

ITECH 6101 Project SRS

40

41

5.2.7 Find directions

…(omitted selection process)

1 View detail

2 Find direction

5.2.8 View popular places from welcome screen

1 User start the application

2 Choose popular places by tapping the pictures on the welcome screen

6 Appendices

6.1 Entity Relationship Diagrams

This part will added later.

ITECH 6101 Project SRS

42

6.2 Acceptance Criteria

The requirements agreed to by the customer business requirements (functional and non-functional) must be clear and this will be ensured by the acceptance criteria. The project’s success is measured by them as they are also considered the metrics. Identification and document acceptance criteria and related metrics is the goal of this section for every customer business functional and non-functional requirement

6.2.1 Acceptance criteria – Functional Requirements

FUNCTIONAL

REQUIREMENT

#

Functional

Requirement 1

Functional

Requirement 2

Functional

Requirement 3

Functional

Requirement 4

Functional

Requirement 5

Functional

Requirement 6

Functional

Requirement 7

REQUIREMENT

Location filter

Direction

Browse for recommend places through menu

Browse places directly by map

Show Popular places on welcome screen

Facebook login

Search places by name or key words

.

ACCEPTANCE

CRITERIA AND

ASSOCIATED METRICS

6.2.2 Acceptance Criteria – Non-Functional Requirements

BUSINESS NON-

FUNCTIONAL

REQUIREMENT

ID

Non-Functional

Requirement 1

REQUIREMENT

Application Theme

Non-Functional

Requirement 2

Easy to Use

Non-Functional Language

ACCEPTANCE

CRITERIA AND

ASSOCIATED METRICS

.

ITECH 6101 Project SRS

43

Requirement 3

Non-Functional

Requirement 4

Non-Functional

Requirement 5

Non-Functional

Requirement 6

Network

Date Requirements

Quality Attributes/ Requirements

ITECH 6101 Project SRS

44

6.3 Declaration:

I have read and understood the project requirements. I hereby agree to the terms of the document.

NAME SIGNATURE DATE SIGNED

Sadah Suliman

Divya Nalla

Raja Kandasamy

Rajashekar Donti

Ren Zhu

------/---------/------

------/---------/------

------/---------/------

------/---------/------

------/---------/------

ITECH 6101 Project SRS

45

6.4 References

IEEE website http://www.ieee.com/portal/site/mainsite/menuitem.e0007c26eb2a454de38570e85bac26c8/i ndex.jsp?&pName=home

John W. Satzinger, Robert B. Jackson, Stephen D. Burd (2004). System Analysis and Design in a

Changing World (3 rd

ed.), Thomson Cource Technology, Boston, Massachusetts, USA.

Ludwig Consulting (2008).

Templates and Guidance. R etrieved June 6, 2008, from http://www.jiludwig.com/Template_Guidance.html

Oregon Government (2008).

Requirements Specification Template.

RetreivedJune 6, 2008, from http://developer.apple.com/library/ios/documentation/WindowsViews/Conceptual/CollectionViewP

GforIO

Schwalbe, K. (2006). Information technology project management, (4th Ed.). Cambridge, MA:

Course Technology.

Stephen Cooper (2008).

Software Requirements Specification.

Retrieved June 6, 2008, from https://developer.apple.com/library/ios/DOCUMENTATION/Cocoa/Conceptual/CocoaFundamenta ls/AddingBehaviortoaCocoaProgram/AddingBehaviorCocoa.html#//apple_ref/doc/uid/TP40002974

-CH5-SW1

ITECH 6101 Project SRS

Download