代写data编程、代写Python，Java程序

日期：2022-03-19 02:28

Contents

1 Introduction 4

1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Intended Audience and Reading Suggestions . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Product Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Definitions, Acronyms, and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.6 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Overall Description 6

2.1 Product Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 System Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.3 Hardware Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.4 Software Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.5 Communication Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.6 Memory Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Product Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 User Classes and Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Operating Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 User Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6 Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.7 Assumption and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.8 Sample Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 External Interface Requirements 11

3.1 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Hardware Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Software Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4 Communication Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.5 Design and Implementation Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.5.1 Design Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.5.2 Special Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 System Features 15

4.1 Description and Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.1 Registration and Authentication Feature . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.2 WebSocket Chatting Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.3 Excess-Item Management Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.4 Transaction Management Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2.5 User Profile Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2.6 Administrator Monitoring Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.7 Statistics for visualization Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Other Nonfunctional Requirements 19

5.1 Performance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2

5.3 Software Quality Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.4 Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6 Change Management Process 20

7 Appendix 21

7.1 Appendix A:Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.2 Appendix B:Analysis Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.3 Appendix C: Requirements gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3

1 Introduction

1.1 Purpose

The purpose of this document, SRS, is to provide a detailed description for ”Campus Second-hand Trading

Platform”. The document is developed for designers, project managers, developers and testers to help

them understand requirements and functionality of the system to be developed. The ”Campus Secondhand

Trading Platform” creates a space for Students, Teachers, and Office Staffs to exchange items they

would like to give away or sell. This product is crucial to NYUAD, as our campus comprises of a highly

diverse student body. As first year students arrive on the campus, they are in need of both essentials and

decorative goods. Meanwhile, graduating students have extra items that they no longer in need of. Because

of the high demand and supply, our campus requires this trading system to facilitate the exchange of goods

on campus.

1.2 Intended Audience and Reading Suggestions

This SRS is developed mainly for developers, project managers, users and testers. Further, the discussion

will provide all the internal, external, functional and also non-functional details about ”Campus Secondhand

Trading Platform”. Please refer to 1.6 for an overview of this document.

1.3 Product Scope

Colleges tend to have a lot of shopping within their campuses. On one hand, there are many students

and faculties eager to deal with some of their excess items, but because of closed information and poor

communication, the items to be sold or given away typically end up being thrown away or wasted. On

the other hand, many students and faculties look for second-hand goods with high quality and low price

for spare or self-use, but they can’t find any way to buy them. Therefore, they have to ask around,

create their own posts on social media groups, or simply choose to buy expensive new products from retail

stores. There has long been a pattern of sellers wanting to sell their goods but being unable to find buyers.

Therefore, combined with the existing Internet technology, this system aims to solve the above transaction

dilemma.The campus second-hand market trading platform not only realizes the mutual benefit between

the buyer and the seller, but also helps the reasonable allocation of idle resources.

The main purpose of the website is to create a channel through which registered users can exchange their

items efficiently at a fair price.

The Campus Second-hand Trading System will be able to:

? Provide a platform for students and faculties to exchange excess items.

? Provide a platform for users to communicate their opinions and experience about the transaction

procedures.

? Track the transaction data for the users and provide data for the analysis of the supply and demand

pattern of on campus second-hand trading.

The Campus Second-hand Trading System will not:

? Allow the exchange of illegal items (including items legal off campus but illegal on campus such as

alcoholic beverages).

? Be available to those without a school account.

4

The Campus Second-hand Trading System will be expected to:

? Reduce the time and implicit costs during the second-hand transaction.

? Integrate social bonding experiences.

? Motivate students to exchange their excess items for greater target use.

1.4 Definitions, Acronyms, and Abbreviations

? CSTS: Campus Second-hand Trading System

1.5 References

No references are made in this SRS, all the content are self-contained and original.

1.6 Overview

The rest of the SRS contains: firstly the product functions for users and the reason why we want to design

this product for users in chapter 2, then it contains the design, mandatory or optional system requirements

and the implementation details of the system in chapter 3, 4 and 5. After that, channels for users to

communicate with the developers will be included. Additional minor requirements and supplementary information

are provided in chapter 6 and 7. Attached are the functional point analysis,details of requirement

gathering, project workflow justification and work plan.

5

2 Overall Description

2.1 Product Perspective

”Campus Second-hand Trading Platform” is the website form of the traditional point-to-point excess item

exchange process. This online system will keep track of all the excess items posted by the registered users,

categorizing them for fast retrievals and efficient management. The main goal of this product is to minimize

the time needed for excess item exchange and maximize the efficiency of trading process while providing an

easy way of making small personal profits. Similar exists where such systems tend to omit the importance

of dynamic supervision from the administrators. On top of that, since it is now a data-driven era, the

visualization of users’ transaction data shall be provided for better analysis of use demand and item supply

and also the websites’ future developmental increments. Therefore, in our product, instead of just providing

users with standardized functions of second-hand trading, we provide a visualization system for users to

track their trading history in a intuitive way and for administrators and software developers to learn about

the ”health” of the website.

2.1.1 System Interfaces

The CSTS is built upon a self-designed database. Users can have unlimited access to the functionality

of the system through the website interfaces and third party APIs (for verification code validation and

recommendation functionalities).

2.1.2 Interfaces

Website pages will be provided for users to interact within the website functionalities.

Website interfaces shall include:

? LoginUI: The login interface is for users to login into the CSTS. The system offers protection by

storing password in MD5 format. Sample page outlook: 2.8

? RegisterUI: Register interface is for users to register their accounts. Verification codes are used for

robot detection.

? ListUI: The item list page shall provide users with lists of items available for transaction, Sample

page outlook: 2.8

? IndexUI: The index page displays the popular items being traded, with a sliding animation.Sample

page outlook: 2.8

? NotificationUI: The notification interface enables the students and faculties to view notifications

posted by the administrators.

? AdminUI: This interface, exclusive for administrators, provides them with the ability to track the

website usage on the weekly basis.

? ReportAPI: This API enables users to download a brief report of his transaction style within a

month.

? ChattingUI: This interface enables users to directly communicate with each others online so as to

socialize instead of just exchanging items. 2.8

6

? UsercenterUI: This interface displays the basic information about a user, including user transaction

list, requested item list, Notification centers. Sample page outlook: 2.8

? VisualizationUI: This interface displays the transaction history for users with multiple graphs with

different marks and channels.

Optimization techniques shall include:

? Non-refreshing tabs: When users switch between different tabs or widget icons indicating different

interfaces, no global refreshing is allowed. User experience should be smooth enough.

? Logged in status icon for chat box should indicate whether users are away or online so that users can

communicate more efficiently.

2.1.3 Hardware Interfaces

The system has no hardware interface requirements.

2.1.4 Software Interfaces

The system is planned to be distributed on AliYun linux docker system, the IP address is provided:

42.192.234.217

2.1.5 Communication Interfaces

Users will be using HTTP/HTTPS protocols to access the website

2.1.6 Memory Constraints

Since the CSTS will be using data caching techniques, 4GB RAM are expected for online chatting functions

and smooth user experience.

2.2 Product Functions

Users have mainly three roles: students, faculties and Administrators

? All users should create an account for the website and be able to manage it.

? All users should be able to post their excess items with detailed descriptions on the website, place an

order on the items they like or request an item.

? All users should be able to see the item list based on their favorites and user type.

? All users should be able to chat with other users.

? Faculties should enjoy 2% to 5% of the discount for the item exchange services.

? Statistics should be accessible for all users to track the traded items and all users should be able to

download customized reports for their trading history.

? Administrators are able to supervise or delete non-standard items posted on the website based on the

submitted description of the items.

? Administrators will be able to publish items information from other portal campuses for trading.

7

2.3 User Classes and Characteristics

”Campus Second-hand Trading Website” has 4 types of users. All users should have an educational account

so as to be able to register and utilize the service.

? Faculties

– Teachers

– Official Staffs

? Students

? Administrators

Faculties has 2 types - Teachers define the course teachers who will instruct the courses. Official Staffs

define the members who manage the campus. Students will take advantages of the website. Administrators

play the role of making approval and supervise the website reliability.

? Students: Are expected to be at least undergraduate level with decent knowledge of how to use a

web application. Students will interact with the CSTS most often, and the availability of the trading

service should not be invalid. Therefore, a complete user guide shall be provided for them.

? Faculties: Are expected to be a full-time school members with decent knowledge of how to use web

application, and they can enjoy discount during transactions.

? Administrators: Must be very familiar with the supervision process and web usage. They should be

able to precisely spot the malicious operations on the network so that the CSTS system won’t be easily

attacked. On top of that, administrators should be sensitive to the data being collected everyday on

the website activity so if the requests sent to the website is skyrocketing within a very short period

of time, there may be web crawling processes running on some machines and administrators should

prevent such things from happening by setting up firewalls and strong robot.txt for the website.

Administrators should have the real-time website activity displayed to them. Thus, higher privileges

should be given to them when it comes to deletion and addition of the posted items.

Figure 2.1: User Class Hierarchy

2.4 Operating Environment

The website can be visited in any Operating Environment - Mac, Windows, Linux etc. Users just type in

the URL of the website and they can access the system.

8

2.5 User Documentation

User documentation will be released on Github Repository.

2.6 Constraint

Only the users who have a educational account can register into the system. Only registered users will be

authorized to use the service.

2.7 Assumption and Dependencies

? The payment system are assumed to be virtual during testing stage. In other words, each registered

user will be assigned a random number of credit in their account so that developers can test transaction

function.

? An item can be requested multiple times but are separated into different request with unique request -

id.

? Assuming administrator should monitor the posted items on a half-day basis so that disqualified items

will be deleted. A notification will be sent to his account by the website system.

2.8 Sample Interfaces

Figure 2.2: Login Page Figure 2.3: Index Page

Figure 2.4: User Center Page Figure 2.5: Item List Page

9

Figure 2.6: Chatting Box

10

3 External Interface Requirements

3.1 User Interface

The following pictures show the desired design of some key website interfaces:

? LoginUI: The login interface is for users to login into the CSTS. Users shall login in the system

based on their educational email and password. The password shall be stored in the database with

MD5 encryption.

If either the email and password is wrong, the corresponding input box shall turn red and display

error messages beside the input box.

“Remember me” options (a button) should be provided.

? RegisterUI: Register interface is for users to register their accounts based on submission of form

data.

The information that the form requires are: name, city, educational email, password, birthday. The

login shall be based on email and password.

Form field validation:

1. Email format shall be checked. If the email doesn’t end with “.edu”, the input box will turn

red, and “non educational email” error message shall appear beside the input box.

2. Password format shall be “6-16 character with at least one capital letter and one number”. If

the input format doesn’t match, the input box shall turn red and “Format error” error should

be display beside the input box.

3. When user input birthday, a auxiliary calendar shall pop out, prompting users to choose the

year, month and date in sequence.

4. Other fields shall not be empty, if either is empty, the input box shall turn red and error message

shall be displayed beside that input box.

5. Before users submit their registration form, verification codes shall be used for robot detection.

? ListUI: The list interface shall include the following functionalities:

1. Display all the items in card boxes categorized by price range, usage, and posted time range.

The card box includes a favorite button, item image, price information, and brief descriptions

of the item.

2. Provide a button for all users to click to post items by uploading item pictures and text descriptions,

which shall be updated into the card box display. A pop out modal shall appear for users

to enter item information.

3. Check item details based on price, reviews, detailed text descriptions, and publisher information

by clicking the item card box.

4. Favorite items by clicking the like button in the card box.

5. Search items with filters of categories, price range, posted timestamp.

6. Review the items if users have bought this item before.

7. Customized Display: Depending on the user type and transaction history, the default item list

page shall be different. For example, for students, items shall purposefully centered on sports,

study, and room decorations categories. For faculties, the displayed items shall be centered on

file covers, folders, and second-handed books.

11

? ChattingUI: The communication interface, in the form of chatbox, shall enables all users to directly

communicate with each other to discuss about the items to be traded. The chattingUI is embedded

into the UsercenterUI.

The interface design should resemble Wechat or Whatsapp, as long as it includes text sending button,

file transferring button and display box.

2.8

? UsercenterUI: The interface shall enable users to:

1. Edit personal information like phone number, address, and birthday.

2. Reset password, verification code is required during resetting process.

3. Show the auditing process of the posted item (Audited: 1, waiting for auditing: 2, Improper:3,

delivered:4).

4. Delete the posted items by clicking the deletion button. (Deletion:5) A window will pop out to

confirm this operation.

5. When clicking on the user profile page, a chatting box should pop up, enabling users to see who

is also online.

– The chatting box should list all the online users that you have recently sent messages.

– When clicking the user icons in the chatting list, the main chatting window should pop up,

enabling the user to directly chat with other online users. Sample interface design: 2.8

6. Receive website message notifications published by the administrator.

7. Check all the favorite items with item details displayed (Auditing status, price, and descriptions).

8. Check all the transaction history based on itemID and item descriptions.

9. Delete the transaction history by clicking a button with a pop-up window for confirmation.

? NotificationUI: The interface shall provide the users with:

1. A clickable button to display a drop-down menu showing the notifications.

2. When users click the unread messages, a pop-out modal shall show up and display the detailed

messages.

3. A corner mark showing how many notifications are unchecked by the receiving users.

? AdminUI: This interface is accessible only by administrators and they shall be able to:

1. Check the online user list. (Green dot for online and grey dot for offline).

2. Freeze the account if any user violates the website regulations (improper posted items, strange

remark)

3. Audit the posted items based on posted images and descriptions.

4. Check all the items based on auditing status, posted timestamp, poster, item details(price and

description).

5. Approve or deny the posted items by clicking a button, a pop-up window will show up for

confirmation.

? ReportAPI: This API shall be embedded in the usercenterUI as a clickable button. When the

button is clicked, a pop-up modal shall let user choose which file format they want to download

as,including(.pdf, .csv, .xlsx, .png, .jpg).

? VisualizationUI:

1. Bar and pie charts are expected for showing users’ categorical transaction comparisons and the

most requested category of items on a weekly basis.

12