User Demand Analysis

Project name: Campus Life Service System

Requirements Specification Sheet

Directory

1. Overview ......................................................................................................................... ................... 6

1.1 Purpose ......................................................................................................................... ......................................................... 6

1.2 Range ......................................................................................................................... ......................................................... 6

1.3 Definitions, acronyms and abbreviations ......................................................................................................................... ......... 6

1.4 References ......................................................................................................................... ................................................ 7

2. System description ......................................................................................................................... ............ 7

2.1 Background of the product ......................................................................................................................... ............................................ 7

2.2 Features of the product ......................................................................................................................... ............................................ 7

2.3 User Classes and features ......................................................................................................................... ........................................ 7

2.4 Operating Environment ......................................................................................................................... ................................................ 7

2.5 Design and implementation limitations ....... ............................. ..... ..... ..... ..... ..... ............... ......... ........................................ 8

2.6 Assumptions and dependencies ......................................................................................................................... ............................................ 8

2.7 Other conditions and restrictions ......................................................................................................................... ................................... 8

3. Business Process ......................................................................................................................... ............ 8

4. Function description ......................................................................................................................... ............ 8

5. Data description ......................................................................................................................... ............ 9

5.1 Data sources and streaming diagrams ......................................................................................................................... ........................... 9

5.2 Database Description ......................................................................................................................... ............................................ 9

6. Data description ......................................................................................................................... ............ 9

6.1 Data accuracy ......................................................................................................................... ............................................ 9

6.2 Time Characteristics ......................................................................................................................... ................................................ 9

6.3 Adaptability ......................................................................................................................... ..................................................... 9

7. Security ......................................................................................................................... ............... 9

7.1 Safety Facility Requirements ......................................................................................................................... ........................................ 9

7.2 Security Requirements ......................................................................................................................... .......................................... 10

8. Operating Interface Requirements ......................................................................................................................... ... 10

8.1 User Interface ......................................................................................................................... .............................................. 10

8.2 Hardware Interface ......................................................................................................................... .............................................. 10

8.3 Software interface ......................................................................................................................... .............................................. 11

8.4 Communication Interface ......................................................................................................................... .............................................. 11

9. Other requirements ......................................................................................................................... .......... 11

10. Acceptance criteria ......................................................................................................................... ....... 11

10.1 Software Quality ......................................................................................................................... ......................................... 11

10.2 User Documentation ......................................................................................................................... ......................................... 11

1. Overview 1.1 Purpose

1. through this project to improve their ability to independently develop projects;

2. test the ability to bmob the platform;

3. integrate all kinds of resources of lake workers and serve the students ' necessities and study in the university;

1.2 Range

Suitable for use in various universities.

1.3 Definitions, acronyms and abbreviations

1 , Filename/fileurl: Indicates the file name/file server address that was obtained after the upload (bulk upload) was successful.

2 , Effecttime: Indicates the valid duration of the URL request, in seconds, and the URL request is invalidated once the valid length is exceeded.

3 , FileName: file name (with suffix), the file name is unique, the developer needs to record the name of the file to facilitate subsequent download of the file.

4 , URL: File server address (if you are uploading a file of a picture type, this URL address is not viewable directly in the browser (a 404 error will occur) and needs to be URL 签名 get a truly accessible URL address).

1.4 References

2. System Description 2.1 product background

In order to meet the students in the university's various life and learning purposes. Better service with the students.

2.2 Features of the product

The Bmob platform provides a complete back-end solution for your mobile applications, and we offer a lightweight SDK development package that allows developers to use the services provided by the Bmob platform in minimal configuration and in the simplest way, thereby completely eliminating the developers writing server code and maintaining server operations.

2.3 User Classes and features

College student groups.

2.4 Operating Environment

Once registered with the Bmob platform, each account can create multiple applications, each of which has its own application ID, after which all applications are bmobsdk with their IDs. Even if there is only one application, it can be tested and produced in different versions.

3. Business Process 3.1 adding data

Adding data is very simple, and any Bmobobject object has save methods that can be used to save the contents of the current object to the server. For example, you now want to save a record of a game score, you can do this:

The data query is likely to be used frequently by every application, and the Bmobquery class is provided in Bmobsdk, which provides a variety of methods to implement different conditions of the query, and its use is very simple and convenient.

3.1.1 Querying all data

Querying all the data in a data table is a very simple query operation, for example: querying information for all people.

3.1.2 Querying single Data

When we know the objectid of a piece of data, we can get a single data object directly based on Objectid. For example: query a203eba875 the person information for Objectid.

3.1.3 Conditional Query

Queries based on different conditions are very common during the use of queries, and Bmobquery also supports queries of different conditions.

For example, you can use a method if you want to filter out the value of a particular key addWhereNotEqualTo . For example, you need to query playername not equal to "Barbie" data can be written like this:

3.1.4 Paging Query

Sometimes, you can use setLimit methods to limit the number of data bars in a query's results to page by how many of the data you want to query can be displayed as a single page in case of more data. By default, the value of limit is 10, the maximum valid setting is 1000 (the value set is more than 1000, or 1000 is considered).

3.1.5 Complex Queries 3.1.5.1 Compounding and querying (and)

Some queries require the use of composite "and" query criteria, such as: you want to query the person table in the age of 6-29 years and the name of "Y" or "e" end of people, then you can use and query, the sample code is as follows:

3.1.6 Cache Queries

A cached query typically caches the results of a query on disk. When a user's device is offline, it can be displayed by fetching data from the cache. Or when the application interface has just started, and the data obtained from the network has not yet obtained the result, the cache data is used to display it first. This allows the user to avoid tedious waits after a button is pressed. The default query operation is not cache enabled, and developers can use the Setcachepolicy method to enable caching. For example: Take the data from the cache preferentially, and then fetch the data from the network if the acquisition fails.

4. Function description

An Android-based mobile app designed to integrate the resources of universities,

such as part-time, hotel, restaurant, study, KTV, car rental, travel, etc.

Through the campus Student service management system to establish a more comprehensive college life Circle.

5. Data description 5.1.1 Data Structure Design

Create an app in the background of the Bmob developer (don't know how to create an app and add a data sheet to a development friend please step into the Quick Start Guide to see the relevant tutorial), add two tables, respectively, feedback (User feedback information table, Store user-submitted feedback) and installation (device installation table that stores information about devices that need to receive push messages). The following is a detailed description of the data structures of the two tables (omit the description of common default fields Objectid, Createat, Updateat)

Feedback table

Field name	Type	Describe
Contact	String	User's contact information
DeviceType	String	The system field, which is a required field, must be set to "ios" or "Android" and cannot be changed since the object was generated.

Installation table

Field name	Type	Describe
Installationid	String	The System field is a Bmob-generated string flag, and if DeviceType is Android, it is a required field and optional if it is iOS. It cannot be changed as long as the object is generated, and is not repeatable for an app
Devicetoken	String	The system field, which is an Apple-generated string flag, is required for devices that are devicetype on iOS, and cannot be changed from the start of object generation, and is not repeatable for an app
Badge	Number	System field, which represents the latest known app for iOS devices badge
TimeZone	String	System field, which represents the system time zone for this device installed
Channels	Array	A system field that represents the list of subscribed channels for this installation object
Appidentifiter	String	Bundle identifier for iOS apps
Isdeveloper	Boolean	Whether it is a developer (or, if so, to receive push messages)

5.2 Database Description

6. Data Description Modification Data

Updating an object is also very simple. For example, change the game score Objectid in the Gamescore table 0c6db13c to 77.

Delete data

Deletes an object from the server. For example, delete the data that is objectid in the Gamescore table dd8e6aff28 .

Array

For array-type data, BMOBSDK provides 3 operations to atomically change an array field: Add , AddAll adds some specified object (wrapped in an array) after an array field Addunique , the Addallunique will only be added to the array if there are no such objects in the original array field, the position of the inserted array is not fixed removeall all objects in the specified array are removed from the value of an array field

adding array Data

Adding data to an array type field in a data object can be added using the following methods:

Updating array data

For example, hobby (hobby) is an array type field, so we can add some hobbies in the hobby field, only if the Hobby field does not include these hobbies:

Querying array Data

For cases where the field type is an array, you can look for an object in the field that contains XXX:

7. Security

Data security is the most important part of software system, in order to better protect the security of application data, BMOB provides the transmission plane, application level, table level, ACL (Access control list), role management (roles) at the software architecture level. Release hierarchy, such as different granularity of permission control, to ensure the security of user data.

Transmission plane

The Bmob SDK encrypts the data, uses the one-time requestId timestamp ApplicationKey symmetric encryption algorithm of + + and the service-side active defense technology to ensure that the data can not be analyzed and destroyed by the Fiddler, Wireshark and other grasping tools in the transmission process.

Application Hierarchy

When you create an app, Bmob automatically assigns three keys to each app, Application key, REST API key, Master key (these keys can be found in the app key for the app in the developer backend).

Application Key Application key: The credentials for the request, data, etc., primarily for SDK development testing and publishing, such as Ios/android/unity/cocos2d-x.

REST API Key: A credential that is used to request data when the Restapi interface is developed for testing and publishing.

Master key: Super Privilege key, used internally by developers, using this key to request data, tables, objects, ACLs and other levels of permissions do not work ( please keep Master Key, do not divulge ).

Table Hierarchy

Bmob You can set this table to read-only or use ACL permissions in table Rights Management (Setup method: Login to Developer background, select an app, data browsing, select a table that requires permissions, click "More", click "Permissions Settings", for example).

8. Operating Interface Requirements

Establish a large information platform to provide students with first-hand information on campus

9. Other requirements 9.1.1 Create a User object

Create user objects as follows:

Bmobuser user = new Bmobuser ();

9.1.2 Registered Users

Your application may require users to register. The following code is a typical registration process:

9.1.3 logged in user

Once the user has registered successfully, you need to have them later be able to log in to their account using the registered user name to use the app. To do this, you can use the login method of the Bmobuser class.

9.1.4 Get Current User

If users sign in every time they open your app, this will directly affect the user experience of your app. To avoid this situation, you can use the cached CurrentUser object.

Whenever your app's user registration succeeds or the first login succeeds, there is a cached user object on the local disk, so you can log in by getting the cached user object:

Bmobuser Bmobuser = Bmobuser.getcurrentuser (this); if (bmobuser! = null) {

Allow users to use app}else{

When the cached user object is empty, you can open the User Registration screen ...}

To get the currently logged-in user with the extended user class, you can use the following sample code ( SpecialUser class can see above):

10. User documentation

Bmobfile allows your application to store files on the server, and common file types can be stored: comparison files, image files, music files, and any other binary data. Note: The following are the methods by which the SDK operates the file, and if you want to manipulate the file on the Web side, check out our help documentation. Http://docs.bmob.cn/helps/index.html?menukey=otherdoc&key =helps#index_ How to upload files in web background (slices)

9.1.5 To create a file object

Create file objects as follows:

String Picpath = "Sdcard/temp.jpg"; Bmobfile bmobfile = new Bmobfile (new File (Picpath));

9.1.6 Upload a single file

The file fragment upload method is very simple, the sample code is as follows:

Toast ("Upload file failed:" + msg);

}});

9.1.7 uploading files in bulk

bmobsdk_v3.2.7 New Batch upload file method, the use is also very simple, the sample code is as follows:

Detailed examples to view bmobfileactivity classes in Bmobexample Engineering

User Demand Analysis