-
Notifications
You must be signed in to change notification settings - Fork 2
Home
TxTchange Software Requirements Document
Version 1.0
The finished product is a mobile application, compatible with Android devices. Hofstra University students will have the ability to create an account, which allows them to buy and sell used textbooks from fellow students. Users interested in selling may post textbook listings, informing buyers of the textbook’s information and its physical condition. Users interested in buying can utilize the in-app search function, where they may search by ISBN number, author, or title and browse through a collection of relevant textbook listings. Once the user has chosen a listing, they may connect to the seller. At this point, the application will connect both parties via email. The finished product will not facilitate the actual transaction, but serves a bridge for buyer-seller communication.
The mobile application will be developed in Android Studio using the Jetpack Compose tool-kit with Java for backend development and with Java and Kotlin for frontend development. Users will be able to post listings that will be saved to a Google Firebase database in the cloud. This function will utilize a Google Books API that allows them to verify the title, display a cover image, and provide a text description. Utilizing the database, users will be able to create an account that will hold information about their Hofstra email, Hofstra ID number, password, and any book listings associated with the account. In addition, the built-in search function allows users to search the database for any available listings of the book they want. The user interface will be designed with Figma, an interface design tool.
The target users of this product will be Hofstra University students. It therefore provides a unified and secure one-stop-shop for students to purchase necessary academic books. The product also serves as an additional channel for students to obtain their textbooks aside from resources such as the Hofstra University Bookstore. Users may find this as a cheaper alternative to the traditional sources to purchase materials. Finally, it will allow for the recycling of books, thus reducing waste and working against global pollution.
The intended audience of this product, as aforementioned, are students of Hofstra University. It targets students who are searching for inexpensive academic materials, inspired by any need to reduce financial strain. Being that the target audience is Hofstra students, use of the application will be limited to those who have a valid Hofstra email account. Furthermore, the application will be created with students in mind so the required Hofstra email will have to be associated with a student but in further implementation it may be opened to all professors, administrators, and other staff members of the institution.
The following definitions and acronyms will be provided to allow readers to understand any unknown words and acronyms used to allow for brevity in the writing. API - Application programming interface UI - User interface ISBN - International Standard Book Number, a way to uniquely identify any book published within the United States post 1970 OS - Operating System Page/Screen - Describes a user interface where the user does certain functions; both words are used interchangeably
Priority #1 - It is the highest priority because without the ability to create an account and log in, users cannot access and utilize the other functionalities of the application making it a critical feature. Description: This feature allows users to create a new account and log in to the existing account. The creation of an account is a prerequisite for accessing the other functionalities of the application, as it ensures the security and personalization of the user. Functional Requirements: The application begins on the Login screen by default and must not allow the users to proceed without entering all the necessary information during login or account creation. If the user does not have an account, they can press on the “create account” button which will redirect them to the “Create Account” screen. Here, they will be required to verify their email with a verification code and then input their account information. Once this information is entered and the “Create Account” button is pressed, the system creates an account in the database and redirects the user to the Home screen (see 2.4.2 for “Create Account” screen). The user’s account information (first & last name, Hofstra ID, Hofstra email and their password) must be securely stored in the database. If the user has previously logged in, the application will default to the Home screen. Otherwise, existing users will enter their Hofstra ID and password on the Login screen (see section 2.4.1 for “Login” screen). It is essential to ensure that the entered login details match the stored information in the database for the user to access the Home screen (see 2.4.3 for “Home” screen).
Priority #2 - This is the second priority since it is fundamental to the purpose of the application and because there seems to be, at the moment, many edge-cases we must consider.. Description: This feature is one of the primary functionalities of the application. It allows users to list a book for sale by providing the necessary book information which is crucial for the application as it enables users to buy & sell books. Functional Requirements: From the Home screen, users can list books for sale by clicking on the 'Sell' page in the navigation bar to then, from the “Sell” page, click the “Post new listing” button to make a “Listing Info” page for that specific listing. Here in the “Listing Info” page, to list a book for sale, the user must fill out all of the necessary fields relating to the book information before pressing the “Submit” button as the user cannot proceed otherwise (see 2.4.8 for Listing Info page). If done correctly, the system will communicate with the Google Books API to search for the book with the corresponding ISBN, title, or author to fill out that book listing’s remaining information in the database (i.e. ISBN, title, or author if needed to be corrected; always fill out cover image, description, and price). Then, the user will be directed back to the “Sell” screen where that book is now displayed. From the “Sell” screen, the listed book must be able to be removed from the database by the use of a delete button (see 2.4.7 for “Sell” page). The seller will be externally notified (through their email) of a potential buyer. After negotiating a deal separate from the application, both the seller and the buyer must check their respective checkboxes within the “Book Info” page to prompt the system to remove the listing from the “Sell” page of the seller and from the “Saved” page of the buyer (see 2.4.6 for “Saved” page). After this is done, only then will the listing be removed from the database.
Priority #3 - This feature is the third priority because it is essential for the successful operation of the application but apart from the search functionality, the functional requirements, at the time of writing, seems more manageable to implement than the previous feature (Selling a Book). But even though Description: This feature is necessary for the application's purpose as it facilitates the completion of transactions between users. The buyer can use the search bar to search the database for a list of relevant books. Once the buyer finds a book, they can view its information and contact the seller to negotiate a deal. When both parties agree that the transaction has completed, they will confirm that it was successful and fair by checking off a checkbox for that list which prompts the system to remove the book listing from the database. Functional Requirements: The user must be able to find a book through the Home screen’s list of currently available books or through its search bar (see 2.4.3 for Home screen). When searching from the search bar, the user must be able to do so by a book ISBN, title, or author(s). With this information, the system will search the database for the relevant books and display them on the Search page to which the user will then be directed to (see 2.4.4 for this). After selecting a book from the Search page, the Home page’s list of currently available books, or the Saved page (explained later in this section), the user will be navigated to the Book Info screen (see 2.4.5 for Book Info). On the Book Info screen, all book’s information is retrieved from the database and shown. To buy the book, the user must use the “Contact” Button to see the seller’s email and spawn the buyer’s and seller’s checkboxes. From there, the buyer and seller discuss a deal, externally through email, the buyer must go back to the Book Info screen (easily accessible from the Saved screen) and check off their checkbox to confirm the deal. The buyer can only check off their box and can only view the seller’s checkbox. If both parties check off, the system then removes the book listing from the database and navigates the user back to the Home screen. The application must confirm that the transaction has been completed and remove the book listing from the database. This is essential to ensure that the book is no longer available for purchase once the transaction is complete. Any book displayed on the Search, Home, Saved, or Book Info page will also have a heart icon that can be pressed and highlighted which saves the listing in a saved list for that account. All saved books can be viewed from the “Saved” page accessible from the top navigation bar (see 2.4.6 for Saved page). Pressing the heart icon again (from the Search, Home, or Saved pages) will remove that book from that user’s saved listings from the Saved page as well as the database.
2.4.1) Login Page The initial login screen will contain two mandatory text fields for the password and Hofstra email as well as two buttons, “Login” and “Create Account.” The email address must contain "@pride.hofstra.edu". The “Login” button will navigate the user to the Home page once their account information has been verified with the database otherwise an error message will display. The “Create Account” button will navigate the user to the “Create Account” screen for account creation.
2.4.2) Create Account Page The “Create Account” page will have six mandatory text fields for the user’s email address, first name, last name, Hofstra ID, password and the verification code. In addition, there will be two buttons, “Send Verification Email” and “Create Account.” To confirm the user’s affiliation with Hofstra University, it is required for the email address to contain "@pride.hofstra.edu" as they will be unable to create an account otherwise. When the email field is filled and the “Send Verification Email” button is clicked, a verification code will be sent to their email to allow account creation. After filling out all the text fields, clicking the “Create Account” button will navigate the user to the Home screen once their account has been successfully added to the database.
2.4.3) Home Page
The “Home” page will consist of a search button, a container field, and a navigation bar. The search button, labeled “Find a Book”, allows users to click on it and be routed to a search page to search for books on sale in our database. The container field is a scrollable and clickable field where the user is presented with categories presenting different educational subjects. Clicking on a category within the container field will navigate the user to a search result presenting all available books within that category. Lastly, the navigation bar is an interactable element that allows the user to switch between the “Home” screen, “Search” screen, and “Sell” screen. The navigation bar will be available on all pages other than the registration and logins pages
2.4.4) Search Page The “Search” Page will contain a search field along with check marks to mark whether the search query is an “ISBN”, “Title”, or “Author”. The search page will also include the list of books returned from the user’s search. Interacting with the “Save” button alongside the result will add the book to the user's “Saved” page.
2.4.5) Book Info Page The “Book Info” page will consist of four text fields, an image field, one button, and two checkbox fields. The text fields will display the book's ISBN, title, authors, and condition. The “Book Images” field will allow users to view the uploaded book images to verify the book's condition. The “Contact” button, when clicked, will reveal the seller’s email address and will also add two checkboxes to the screen. These checkboxes are labeled “Seller Confirmation” and “Buyer Confirmation”.
2.4.6) Saved Page The user will be presented with the “Saved” page when clicking the “Saved” page navigation button. The “Saved” page will contain the list of books within the user. Interacting with a book inside this list will take the user to the “ Book Info” page. The user will be able to add up to fifty books to their “Saved” page.
2.4.7) Sell Page This page shows the user’s list of listed books for sale and has a button to post a new listing by linking to a new Listing Info page. The user must be able to click on each of their books that links to their respective Listing Info pages. On the list of books, each one must have a delete button that will prompt the user a confirmation message and if the user proceeds, the system will remove the listing from the database.
2.4.8) Listing Info Page The “Listing Info” page will allow the user to enter a new book listing. To make a new book listing, users will be required to enter the book's ISBN, title, author(s), and current condition into all of the four text fields. Additionally, images of the user’s book must be submitted in the “Book Images” image field. Only when all the necessary information fields are filled, the user can then list their book with the “Update” button. After the book is successfully added to the database, the user will be redirected to the “Sell” page where the active listings section is updated with a new book. Users are also able to edit the book’s condition or images (not including the cover image provided by the API) by returning to this page from the “Sell” page.
2.4.9) Account Page The “Account” page will allow the user to view their account details. The user will have options to edit their account details. All updates made to the account will be submitted to the application’s Firebase database.
2.5.1) User Management Admin can manage users by adding, deleting, or updating user information in the database. They have the ability to reset passwords, deactivate or activate accounts, and update user details. 2.5.2) Book Listings Management Admin can manage book listings by adding, deleting, or updating book details in the database. They are able to confirm book details, remove inappropriate content, and update book information. 2.5.3) Transaction Monitoring Admin can monitor the transactions taking place between users. This includes the ability to confirm successful transactions, resolve disputes, and remove listings that have been successfully transacted.
3.1.1) General Design Principles The User Interface for this application must deliver a seamless experience for both buyers and sellers. The flow for each role must be coherent and distinct, so that both sets of users can easily navigate through the application and achieve the goals their role requires. The design must model after a consistent application theme that is both attractive and accessible. For instance, a user should not experience confusion or lack of familiarity when navigating between pages. The properties of each interface should coincide with one another in terms of functionality and style. The User Interface should be compatible with various Android devices and screen sizes. It should be responsive and dynamic.
3.1.2) Screens 3.1.2.1) Login and Registration: The Login is the first screen the user sees when they open the application for the first time on their device or when they have logged out of their account. This screen will consist of a login form of two fields - a username field and a password field. Below the password field, is a submission button labeled “Login” that will redirect the user to the home screen once their login information has been validated . Under all of this houses a prompt text, “Don’t have an account?” and a button next to it labeled “Register”. When clicked, the button redirects the user to the Registration screen. The Registration screen has a form that will consist of the following fields: first name, last name, Hofstra ID, Hofstra email address, and password. Also, there is a field for the verification code and a “Send Verification Email” button next to it. At the bottom, there is a “Create Account” button.
3.1.2.2) Home: The Home screen will consist of the following core elements: a welcome message “Get Started”, a button labeled “Find a Book”, which links to the Search page, a button labeled “Sell a Book” which links to the Post Listings page, and an image below to fill whitespace. Home Screen Diagram: (Jeshuah, Dylan)
3.1.2.3) Navigation: The Navigation is a small component that is located on all screens except for the Login/Registration screens. This features top and bottom bars that contain elements for a smoother user experience, as the user can access important features from anywhere in the application. The top bar consists of three three elements (listed from left to right): the logo and name of the app, a button that links to the Saved screen, and a button that links to the user Account screen. The bottom bar will contain three elements: a button that links to the Home page, a button that links to the Sell page, and a button that links to the Search page. 3.1.2.4) Search: The Search page will display a title, “Search”. Underneath this title is a search bar. Below the search bar are filters - a set of radio buttons labeled “ISBN”, “Title”, “Author”. To the right of the search bar is a button to submit the search. Located under the search bar is a dropdown menu of additional filtering options for the search results. These options include sorting by textbook condition and price. The rest of the page is a paginated list of the search results. Each result contains a textbook image, price, title, author, a button to save the book, and a button linking to the Book Info page. Search Screen Diagram: (Jeshuah, Dylan)
3.1.2.5) Book Info: The Book Info page is an expanded view of the textbook information returned from search. It contains the textbook title, author, ISBN, condition, price, an image of the textbook, a button to save the book, and a button to contact the seller. Below this area is a set of Status information about the sale, activated when the contact button is clicked. It contains two checkboxes, one for seller confirmation and one for buyer confirmation. Book Info Screen Diagram: (Jeshuah, Dylan)
3.1.2.6) Saved: The Saved page is a view of all textbooks a user has set aside with the intention of purchasing a textbook. This page simply displays a vertical list of these listings, displaying the textbook image, and its supplemental information. Underneath each item is a button that will open an email box, preloaded with the seller’s email address in the Recipient field. Saved Info Screen Diagram: (Jeshuah, Dylan)
3.1.2.7) Sell: The Sell page contains the title “Sell” and a subtitle “My Listings:” above a grid view collection of thumbnails that represent all of the seller’s active listings. Each thumbnail contains the textbook image, a button that links to the Listing Info page, and a button that allows the seller to delete a listing. There is also a “New Listing” button located on the bottom of the page which links to the Listing Info page.
3.1.2.8) Listing Info: The Listing Info page is an expanded view of an individual listing that a seller will put for sale. It contains an image of the textbook, the title, author, ISBN, condition, and price. It also displays an edit button which turns some of these information fields into mutables, a delete button, and a button labeled “Update”. At the very bottom contains Status information about the sale. This information contains two checkboxes, one for seller confirmation and one for buyer confirmation. Listing Info Screen Diagram: (Jeshuah, Dylan)
3.1.2.9) Account: The Account screen hosts a view of the user’s personal information. At the top of the screen is a personalized welcome message with the user’s name: “Hello, [NAME]” and a logout button under the top nav bar. Below this message is an organized component view of all of the user’s information, their full name, username, and email. This area also contains the user’s preferred contact information. This information can be edited. Account Info Screen Diagram: (Jeshuah, Dylan)
The application will be created to interact with mobile devices using an Android operating system acting as an application that can be downloaded and used directly on the device.
The Google Firebase database will be used to store all information relating to users, book listing information, and a list of ISBN numbers that are associated with a book listing. This database will return information to the application for the search function, it will also be updated any time a new listing is put up, a new user account is created, and when a listing is deleted. The listing creation feature will also utilize a Google Books API to assist in avoiding user error by providing a title, author, ISBN, text description, and an image of the cover based off of the information they provide, starting with the ISBN but if that is not provided the results will be based on other information in an order of priority not yet determined, so that the user can verify that the book they are posting has the correct information. The search function will also utilize the same API. By providing the search query to the API so that it may return a list of ISBN numbers that can be compared with the list of ISBN numbers in the database to provide only books that are actively listed to the user based off of the original search query.
All external communication associated with the application will take place outside of the application with email addresses provided to allow for users to communicate with each other for the sake of completing a transaction. Users will also be provided with a support email for all inquiries and requests.
4.1.1) Data Protection We must comply with data protection laws by ensuring that user data is securely stored and not shared with third parties without consent. Firebase Service Data is personal information that Google collects and generates during the provision and administration of the Firebase services, excluding Customer Data and Google Cloud Service Data. Google uses Firebase Service Data in accordance with Google’s privacy policy and applicable terms.
4.1.2) Consumer Protection We must comply with consumer protection laws by ensuring that the transactions taking place on our platform are fair. Our buyer and seller checkboxes will be used to confirm transactions within our app. This feature is designed to provide both parties a clear understanding and acknowledgment of the terms, conditions, and validity of the transaction. Prior to completing a transaction, both parties will be required to actively confirm their agreement and understanding by checking these checkboxes. This ensures that both parties are fully informed and consent to the transaction, minimizing potential disputes and reinforcing the legitimacy and trustworthiness of our platform.
The application must have a response time of less than 2 seconds for all actions performed by the user. The application must be able to handle a minimum of 1000 simultaneous users without a significant drop in performance.
The project will be capable of handling a database that is one gigabyte in size. Being that the intended documents for the project will likely at most reach a size of one kilobyte, the project will be capable of containing roughly 76,900 users. Each user will have the ability to post five separate listings so the project will contain at maximum 384,500 listings. Each unique book posted will also create a document within the database containing its unique ISBN number as well as a subcollection of references to any listings associated with the unique ISBN number. This will produce a maximum size of at least 384,500 unique documents. The database will be limited to 50,000 document reads and 20,000 document writes and deletes respectively each day. The project will be limited to having 3,500 new listings to be created, 3,500 listing deletions to be processed, and 3,500 new accounts to be created per day. This will allow for an adequate amount of search functions to be processed per day. With a maximum expected user base of 5,000 users and an expected 15% of user base to be active daily in the beginning stages of the application’s release, these limitations should allow expected user activity to go unhindered.
The application is expected to be able to run on over 95% of Android devices since the SDK (Software Development Kit) and the API that we are using are considered to be “level 24.” In the Android development community, this means that our software requires Android version 7.0 (dubbed as “Nougat”) or higher to operate.
The application will have a goal of achieving limited down time and crashes to allow for constant user availability by attempting to avoid and prevent activities that will cause a fatal error and crash the application. The application developers will aim to achieve a 0.10% application downtime by the end of the project development cycle.
The project will follow coding standards put into place by the development team so that any necessary changes to the applications functions could be made by any member of the development team, and any new members of the development team will be able to read the code and accurately understand if necessary to make changes. These changes will require a range of time to be implemented that will be tested in later stages to determine an exact range.
As previously mentioned, the project is capable of storing roughly 76,900 user accounts, but not the daily activity of said users. This is limited due to the free quota enforced by Google Firebase. If the application began to generate money, potentially through taking a percentage of sales or the use of advert revenue, the project would be able to afford increasing the quota for Google Firebase. If these changes were to take place, the project could support a user base that encompasses all of Hofstra university as well as other New York colleges and universities.
Administrators will have a built-in function that allows them to update or find any user information based on the user's email address. They will receive requests for these actions within an email accessible only to administrators. In addition, they will have the ability to change the UI of the application to allow for changes based on either user requests or innovation within the development team and administrators. Users will be able to clearly identify functions associated with various buttons and widgets within the application with either the use of straight forward text or easy to identify symbols. Users screens will also not be cluttered with information and will be kept simple to avoid confusion and allow for easy navigation within the application. The application will also follow guidelines to allow for impaired users to easily use the application such as changeable font sizes, contrasting colors within themes, multiple different themes, and many more options.