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.