Software Project Plan - Kutztown University of...

Software Requirements Specification

Fall 2015

Textbooku : textbook trader appTeam d

Version 3.0 | Primary Author: Emily Hoch

Software Requirements Specification May 19, 2023

TABLE OF CONTENTSREVISION HISTORY.......................................................................................................................................2

1.0 INTRODUCTION.....................................................................................................................................3

1.1 Purpose of Document........................................................................................................................3

1.2 High Level Product Overview.............................................................................................................3

1.3 Explanatory Material: Acronyms & References.................................................................................4

2.0 PROJECT CONSIDERATIONS...................................................................................................................5

2.1 Identified Costs..................................................................................................................................5

2.2 Possible Tools....................................................................................................................................5

2.3 Open Issues And Questions...............................................................................................................5

2.4 Long-term Plans For Future Releases And Features..........................................................................6

2.5 Standards And Regulatory Considerations.........................................................................................6

3.0 PROJECT SCOPE.....................................................................................................................................7

3.1 Administrative Perspective................................................................................................................7

3.2 User Perspective................................................................................................................................7

3.3 User Profile........................................................................................................................................8

3.4 User Interface Map............................................................................................................................9

3.5 System Architecture Diagram..........................................................................................................10

4.0 FUNCTIONAL REQUIREMENTS.............................................................................................................11

5.0 NONFUNCTIONAL REQUIREMENTS.....................................................................................................12

6.0 USE CASE DESCRIPTIONS.....................................................................................................................13

6.1 Maintain An Account.......................................................................................................................13

6.2 Support............................................................................................................................................18

6.3 Search For Books.............................................................................................................................22

6.4 Buy...................................................................................................................................................25

6.5 Sell...................................................................................................................................................27

6.6 Transactions.....................................................................................................................................28

1


REVISION HISTORYBelow is the up to date revision history chart. As changes to this document are made, the chart will be edited to include it.

Version Date Description Editor1.0 9/18/2015 First draft for submission (due

9/28/15)Emily Hoch (primary author)

Reviewed by: Tom Kratz, Ryan Harrington

1.1 09/23/2015 Changes reflect Requirement Elicitation meeting with Dr. Tan:

Added sections forFunctional Requirements,

Nonfunctional Requirements,And Use Case Descriptions

Emily H.

1.2 09/25/2015 First version for submission and review

Emily H (primary author), Use Case Descriptions Section 1 by Ryan H., Section 2 by Tom K.

1.3 09/28/2015 Changed diagram in Section 3.4 Emily H.

2.0 10/05/2015 Updated with changes from Dr. Tan’s feedback for v1.3

Emily H.Reviewed by: Tom K. & Ryan H.

3.0 01/25/2016 Updated with changes from feedback on v2.0, and with new

and more specific details on implementation; see Sections 2.2,

5.0, and 6.3

Emily H.Reviewed by: Tom K & Ryan H.

3.1 01/30/2016 Added deliverables dates to Functional Requirements table, Section 4.0; changed the Non-

Functional Requirements, Section 5.0

Emily H.Reviewed by: Tom K & Ryan H.

3.2 04/29/2016 Edited for Final Turn In Emily H.

Table 1: Revision History

2


1.0 INTRODUCTION1.1 Purpose of DocumentThis Software Requirements Specification document outlines the way the proposed app is intended to work by using high-level and detailed descriptions.

Section 2.0 details the software and non-software requirements of the project, and considerations for future development. Unresolved issues will be addressed in Section 2.3: Open Issues and Questions, which will be updated as the project proceeds

Section 3.0 describes the services the app will provide from the perspective of a user, and the maintenance requirements from the perspective of an administrator.

Section 4.0 provides the functionalities the application will need in order to work, from a user’s perspective. Briefly, these are: the ability to create an account and sign in, the ability to search for a book by its ISBN or by the course it is used for, the ability to purchase books from other users, and the ability to sell books to other users. User support will include the ability to report users for malicious activity, viewing the terms of service at any time, reporting issues with the app, and making suggestions.

Section 5.0 includes Nonfunctional Requirements, which are the Quality Attributes that will be tracked during the project, including usability testing, performance analysis, and security considerations. The purpose of these requirements is to improve the services provided and encourage adoption by users.

Section 6.0 outlines Use Cases from the perspective of a user. The Use Cases correspond to the Functional Requirements from Section 4.0. Their purpose is to provide a clear picture of the requirements for each action users may perform while using the app.

1.2 High Level Product OverviewThe textbook trader application, TextbooKU, is a tool that college students will be able to use to buy and sell text books on their campus. After registering with their .edu email address, students with books will be able to scan their book’s barcode, then the app will get prices and images from the web, and the user can list it for sale locally. Other students will be able to search for books that they need by ISBN or course, and create wish lists of the books they want. When a user acting as a buyer offers to purchase a book, the system will notify the user who has listed that book for sale. Conversely, when a user acting as seller lists a book for sale, the system will notify users who have placed that book on a wish list.

3


1.3 Explanatory Material: Acronyms & ReferencesThe following references will be used throughout this document.

Acronym Full NameIDE Integrated Development EnvironmentKU Kutztown University of PennsylvaniaLLC Limited Liability CompanyOS Operating SystemRMP Risk Management Plan (most recent version)SDK Software Development KitSPP Software Project Plan (most recent version)UI User InterfaceTable 2: Acronyms & References

4


2.0 PROJECT CONSIDERATIONSAdditional details of costs, schedules, and required tools can be found in the SPP, under the section Project Estimates.

2.1 Identified CostsDuring planning and development, we are attempting to keep costs to a minimum. We have some personal equipment that can be used for prototyping and testing. However, if we deploy this app “to the real world” we may need to source materials or fund some potential costs. These include:

• Equipment: A Raspberry Pi to use as a server, possibly other hardware for server; alternatively, we may pay for monthly cloud hosting for server capabilities. Ryan has found a service that costs $5 per month, and would perform faster than our Pi.

We are borrowing Android-based Nexus tablets from the KU Computer Science department, so we will not need to buy those for testing during this semester’s development cycles. Android or iOS tablets may be a future cost if we continue developing the app after graduation.

• Licenses & Fees: registering a business name as an LLC; fees to sell through the Apple AppStore if we end up porting to iOS.

2.2 Possible ToolsIdentifying tools to use to build the TextbooKU software has been one of the most important topics under consideration. The following items have been tried out or are being used currently. Items marked with a * are the current favorites to proceed with.

Android SDK & IDE – developing environment for Android OS* IntelliJ IDE – another possible IDE to work in Import.io – automated collection of website data Ionic framework – Front-end UI* Bootstrap – Also for Front-end UI Git & GitHub – version control*

2.3 Open Issues And QuestionsAt this time, the primary open issues are ones of implementation, such as what software to use for the IDE, database(s), and server.

We are also working on details of how to flag users who abuse the system or each other. We are thinking that by prompting users to report back about each transaction, they will have a chance to flag anyone who used the system in bad faith. If a user is flagged 3 or more times, they may be blocked from using the system permanently or temporarily. This will be explained in the Terms of Service.

5


2.4 Long-term Plans For Future Releases And FeaturesThis project is intended as a model or prototype to be tested at Kutztown University. If successful, we may be able to accomplish the following:

Launch the app on multiple college campuses. Derive income through sales of the app itself, via Google Play for Android devices; or if

highly successful, we could also derive income through ads or taking a small percentage of each sale.

Port the app to iOS, and sell through the Apple AppStore. Incorporate our team as an LLC before making any sales.

2.5 Standards And Regulatory ConsiderationsWe will meet with the KU legal counsel office to review potential legal issues. We want to ascertain that by providing a means for students to sell books to each other, we are not going to be liable for any potential damages. For example, if one student cheated another. We also want to get feedback on how to write Terms of Service.

The Terms of Service document should be completed early on in this semester.

6


3.0 PROJECT SCOPETo give a fuller sense of the project, and by way of transitioning to the functional and nonfunctional requirements sections, this section will cover the services offered by the textbook app. Since the primary agents involved are students, the app should guide them through each step and make it simple to use. Administrative tasks are intended to be kept to a minimum.

3.1 Administrative PerspectiveAdministrative tasks involve the upkeep of the app. With regard to the software itself, the main areas identified will include:

Interoperability with current and new versions of the Android OS. Updating databases used by the app to provide items such as department course lists,

so that users may select from menus when choosing what courses or departments to search for books under. As courses change by semester and year, this list will need revision periodically.

Updating the software that will scrape the web for prices and book images.

In addition to maintaining the software, we will also have a responsibility to users, similar to the role of moderators in online forums. We anticipate that this will include responding to user feedback and questions, and taking appropriate actions to flag or remove users who abuse the system (for example, if one student cheated or attempted to cheat another during a sale).

Lastly, if we test or deploy the app using a Raspberry Pi server, there will be minor work to perform in setting up and maintaining that hardware. Cloud hosting may be preferable, but for the sake of completeness, this is mentioned.

3.2 User PerspectiveUsers with a valid .edu email address will be able to register for an account with TextbooKU, initially using their name, email address, and telephone number. They will then will have access to the following services:

Log in and view account activity, such as history of transactions. Get help and information about the app, make suggestions, or report something. Search for books by ISBN: either by scanning the barcode with their phone, or by

manually entering one Search by major: select from a list of majors by their abbreviation (e.g. CSC) and browse

available books that other students have listed for sale. Create a wish list of books they want to buy (tagged by ISBN) Review notifications.

After doing a search, a user has two paths to follow: Sell or Buy

Sell a book: after searching the ISBN, the user will have the option to list a book for sale.

7


Get prices: if the user chooses to sell, the app will retrieve prices from sellers on the web for the same book. The user will set their own price.

Buy a book: after searching by either method, if the book is found, the user can place an offer to buy it.

Arrange a transaction: The system will notify a seller if a buyer made an offer, and it will notify a buyer if a wish list item became available. The system will then prompt both the buyer and seller to arrange a time to meet.

Report on the transaction: The system will prompt the buyer and seller to rate whether their transaction was successful and to report any issues with the corresponding user.

3.3 User ProfileThis app is intended for use by college students with Android-based smartphones or tablets. Accordingly, there will be a range of user skill level in using mobile applications. In order to meet the needs of those who may be less skilled at web searching, the app should be simple to use, even for those uncomfortable with technology. The following aspects were designed with this simplicity in mind:

The app asks for permission to access the camera in order to scan barcodes. Scanning is easier than manually entering an ISBN, but the app will also allow users to manually enter them in case they don’t wish to give the app camera permissions.

The app will obtain images of the book and relevant price information to cut down on the work the user must do to buy or sell a book.

The app will guide users throughout the process by presenting relevant screens after each action is performed. See chart in Section 3.4 to view the flow of activities.

The app will prompt users to arrange a time to meet when a sale is being arranged. Because this section relies on users acting outside the scope of the app’s control, we wish to make the process as simple as possible, in order to increase the probability that users will follow through with a transaction. The app will prompt buyer and seller to list three different times that they are available to meet, and allow respective parties to accept the other’s offer or make a counter offer with alternate times. If no acceptable time can be found, a sale can be cancelled and the system places the book back on the list of available books.

8


3.4 User Interface MapThis diagram shows a flow of activities based on screens, mapping the functionalities available through various navigation buttons and screens. In other words: which screens lead to possible actions which are available to users.

Figure 1: Screen View Hierarchy

9


3.5 System Architecture DiagramShown below is the most current plan for implementing the TextbooKU system. This architecture has changed since version 2.0 of this document, and also since the original design shown in the SPP.

Figure 2: System Architecture diagram

10


4.0 FUNCTIONAL REQUIREMENTSThe following table contains a list of functional requirements, corresponding to the Use Cases in Section 6.0. The Delivery Group shows which functionalities will be delivered at the Intermediate and Final delivery dates; intermediate deliveries are marked 1 and Final deliveries 2. The Intermediate delivery date is March 04, 2016, the Final delivery is due April 25, 2016.

F.R. Number Requirement Description Category Delivery Group1.1 Create an Account Allows user to create an account. Maintain

account1

1.2 Sign In Allows user to sign in to their account.

Maintain account

1

1.3 Respond to Validation Code

The application will verify that the user is eligible to use the app.

Maintain account

2

1.4 Manage Activity Allows user to view history of purchases, sales, and notification activity.

Maintain account

1

1.5 Delete Account Allows user to have their account shut down.

Maintain account

1

2.1 Contact Us The user can ask for help or make suggestions.

Support 2

2.2 View Tutorial The user can view a how-to about using the app.

Support 2

2.3 Report a User The user can report malicious activity by another user.

Support 2

2.4 View Terms of Use The user can view the terms of use.

Support 2

3.1 Search by Major User can search for a book according to the course it’s used for.

Search For Books

2

3.2 Search by ISBN Scan User can search for a book by scanning the bar code with the device’s camera.

Search For Books

2

3.3 Search by ISBN Manual Entry

User can search for a book by manually entering the alphanumeric bar code.

Search For Books

1

4.1 Make an Offer User can offer to purchase a book listed by another user.

Buy 1

4.2 Add Book to Wish List

User can place a book on a list of books they wish to purchase.

Buy 1

5.1 List a Book User can offer a book for sale. Sell 16.1 Schedule a Meet Buyer and seller can arrange a

time to exchange books for payment.

Transact 2

6.2 Report Back Users may rate other users. Transact 2Table 3: Functional Requirements

11


5.0 NONFUNCTIONAL REQUIREMENTSThe three Quality Attributes we have chosen to track for this project have been modified from the ones outlined in the SPP, section Tracking and Control Mechanisms. These attributes were chosen because in order to be successful, the app should function as intended with few hiccups, and should be appealing and useful for users. We have modified the second and third attributes to reflect newer plans for how the app will be hosted on a server. By tracking these requirements, we will be able to gather feedback during development for future improvements.

Note (as of 04/26/2016): See also the Nonfunctional Requirements Paper that was turned in late in the Spring semester for more up-to-date information.

Requirement Purpose How The Requirement Will Be MeasuredUsability testing

To gain feedback that will make the app easy to use and promote adoption by users.

We will conduct surveys during testing, asking test-users to rate specific items with a “1-5 stars” system. This will allow quantitative measurement of performance, functionalities, and design. The surveys will include open-ended questions for qualitative feedback, such as suggestions.

Responsiveness To measure the time the app takes to respond to inputs from users.

Once the data base is set up, the speed of queries can be recorded.

Compatibility To maintain compatibility with different and new versions of the Android OS

The Android SDK allows the app to be tested with any version of Android. We will utilize the SDK to ensure the app is compatible with current versions in popular use.

Table 4: Nonfunctional Requirements

12


6.0 USE CASE DESCRIPTIONSThese use cases represent the system’s behavior from the point of view of a user. The following subsections are comprised of the functional requirements, and are grouped by purpose:

6.1 Maintain An Account6.2 Support 6.3 Search For Books6.4 Buy6.5 Sell6.6 Transactions

We envision these categories as the logical flow of events while using the app, from registering or signing in to an account (6.1); getting help, reporting issues, or viewing tutorials as needed (6.2); searching for a book (6.3), listing it for sale or making an offer to buy (6.4 and 6.5), and then arranging an exchange(6.6).

6.1 Maintain An Account6.1 Maintain An Account

Use Case Name: Create an Account

Functional Requirement: 1.1

Scenario: User wants to create an account

Brief Description:The user will create their account by entering their KU email and a password of their choice.

Actors: The User of the app

Stakeholders: Buyer & Seller

Preconditions: User has valid .edu address; has chosen a password

Postconditions: System sends confirmation email and creates preliminary account.

Flow of Activities:

Actor System

1. User enters login email (must be KU email address) and password and clicks register account.

1. System will then enter the user’s account into the database under the account table thus creating the account

Exceptions: Mistyped input, database errors, no account found

Related Use Cases: 1.2; 1.3

13


6.1 Maintain An Account

Use Case Name: Sign In


Scenario: User wants to sign in to the app

Brief Description: The user will input their email address and password for their account that has already been registered



Preconditions: Have already registered an account through our app.

Postconditions: User has access to their account.

Flow of Activities:

Actor System1. User enters login email and

password and clicks sign in.1.1 System check email against

database of registered emails

1.2 If the email address (user name) and password that the user entered match in the database then the user ‘logs in’.

Exceptions: Mistyped input, database errors, no account foundRelated Use Cases: 1.1

14


6.1 Maintain an Account

Use Case Name: Respond to Validation Code/EmailFunctional Requirement: 1.3

Scenario: User wants to validate their email for full account access

Brief Description:The user will enter a validation code into the app that was sent via email to validate their account.



Preconditions: Have already registered an account through our app.

Postconditions: New account created for user in our database.

Flow of Activities:

Actor System

1. User will enter the validation code they received in their email into the app after registering for an account.

1.1 System check validation code to make sure it is correct.1.2 If the validation code is correct the account will be completely created and validated granting full access to the application.


Related Use Cases: 1.1

15



Use Case Name: Manage History/Activity


Scenario: User wants to see their account history/activity

Brief Description: The user will click on the Manage Account button to check their account history.



Preconditions: User has registered an account.

Postconditions: System displays log of user activity.

Flow of Activities:

Actor System

1. Clicks on manage history button to see their past offers, transactions, and wish list.

1.1 System will query the database and output a table of all their transactions, and offers.

1.2 System will also query for their wish list that they can create through this section

Exceptions: No history to show, system will display blank table

Related Use Cases:

16



Use Case Name: Delete Account


Scenario: User wants to delete their account

Brief Description: User goes through an account removal process by clicking “Delete Account”



Preconditions: User has already registered an account.

Postconditions: System removes user’s account information

Flow of Activities:

Actor System1. User clicks on “delete

account” under account management.

1.1 System check email against database of registered emails

2. User must reenter their password as a security measure.

2.1 If the password that user entered matches with their account email in the database then the user account will be deleted.


Related Use Cases: 1.1

17


6.2 Support6.2 Support

Use Case Name: Contact Us


Scenario:A user will be able to click a button on the support screen to contact the proprietors with questions or suggestions about the application.

Brief Description:After clicking the “Contact Us” button, the user will be taken to a page that where they can fill out a topic field and a content field. After doing so a message will be sent to the project team that can be replied to via the log in email of the user.

Actors: Application users (Buyer and Seller), Support Team

Stakeholders:

Preconditions: The user has signed in to their account.

Postconditions: A message is sent from the user to the support team.

Flow of Activities:

Actor System

1. User presses the “Contact Us” button

1.1 System Generates a blank suggestion/question form

2. User fills out and submits form 2.1 System sends the form to the support team via email with the user’s email attached.

3. Support team responds to the suggestion/question email.

3.1 The email is sent to the user when the support team “Replies to all”.

Exceptions: The user does not have access to that email address anymore

Related Use Cases:

18


6.2 Support

Use Case Name: View Tutorial


Scenario:After creating an account, a user will be able to learn the functions of the application by watching a tutorial.

Brief Description:The user will be shown the various screens of the application with an overlay detailing the functions of the buttons. The tutorial will be focused around the buying and selling process.

Actors: Application users (Buyer and Seller)

Stakeholders: Buyer

Preconditions: The user has created an account and is signed in.

Postconditions: The user has viewed the application tutorial

Flow of Activities:

Actor System

1. User presses the “View Tutorial” button

1.1 System begins running the tutorial

2. User presses a “Continue Button”

2.1 System advances the tutorial to the next section

3. User completes the tutorial 3.1 The system closes the tutorial

3.2 The system returns the user to the application home screen

Exceptions: The user closes the app while the tutorial is in process

Related Use Cases:

19


6.2 Support

Use Case Name: Report a User


Scenario:If a user has a bad interaction with another user, mainly getting ripped off in a transaction, the user can submit an incident report to the support team. This incident report may be used to ban unwanted users from the application.

Brief Description:After clicking the “Report User” button, the user will be asked to fill out fields identifying the malicious user and the incident that took place. This report will then be sent to the support team.

Actors: Application users (Buyer and Seller), Support Team

Stakeholders: User, Management

Preconditions: The user has had an incident with another user

Postconditions: The support team has received an incident report, and will look into taking appropriate action.

Flow of Activities:

Actor System

1. User presses the “Report a User” button

1.1 System generates a blank incident report form

2. User fills out the incident report and clicks submit

2.1 System sends the report to the support team

3. Support team makes the decision to ban the malicious user

3.1 The System sends the malicious user a notice

3.2 The system removes the account

3.3 The system adds the account information to a “blacklist” of banned users

Exceptions: The user submits a false report

Related Use Cases:

1.2, 6.1, 6.2

20


6.2 Support

Use Case Name: Terms of Use


Scenario:When the user attempts to make an account, they must agree to the proprietors’ Terms of Use before access is granted. These terms may be viewed at any time under the support section.

Brief Description: The terms of use will be displayed on the screen. Accepting the terms allows the user to continue, declining will cause the application to revert to the start screen.

Actors: Application users (Buyer and Seller)

Stakeholders: Users, Management

Preconditions: The user is prompted to read the Terms of Use

Postconditions: The user has either accepted or declined the Terms of Use

Flow of Activities:

Actor System

1. User creates account or hits the “View Terms of Use” button

1.1 System displays the Terms of Use

2. User accepts the Terms of Use 2.1 System allows the user to advance to the main application screen

3. User declines the Terms of Use 3.1 The System returns the user to the application start screen

Exceptions:

Related Use Cases:

1.2

6.3 Search For Books6.3 Search For Books

21


Use Case Name: Search book by major


Scenario: User logs in and wants to search for books to buy.

Brief Description:

User fills out form with department acronym to search for list of available books, e.g. CSC.

Actors: User as buyer, other user(s) as sellers who have previously listed books with that department tag.

Stakeholders: User acting as buyer, other users in major who have listed books as sellers.

Preconditions: The system has a list of majors to choose from;Other sellers have listed copies of the books for sale.

Postconditions: A list of available books tagged with that major.

Flow of Activities:

Actor System1. User searches a major 1.1 System returns a list of

books available which are tagged with that major.

2. User finds book, adds to wish list

2.1 System records user’s addition to their wish list

3. User finds book, makes offer to buy

3.1 System marks the book “sale pending”, making the book temporarily unavailable.

3.2 System alerts seller that an offer to buy was received.

Exceptions: No books listed by that major; system does not have a an entry for that major (e.g.: User enters ANT for Anthropology, system does not have ANT).

Related Use Cases: 5.1, 4.2

22


6.3 Search For Books

Use Case Name: Search by ISBN Scan



Brief Description: User scans an ISBN barcode with the device’s camera.

Actors: User as buyer

Stakeholders: Buyers and sellers

Preconditions:System is able to search web for a given ISBN;System is able to obtain image of book for ISBN;User has allowed the app to access the camera to scan a barcode;

Postconditions:System returns an image of the book and current prices; as well as a list of any available copies of that book;User may add book to wish list.

Flow of Activities:

Actor System1. User scans book barcode (of

a book they currently own) to get current price suggestions.

1.1 System looks up the ISBN and returns info about the book.

Exceptions: Barcode unreadable; no ISBN found by system (obscure textbook); User has not given the app permission to access their camera.

Related Use Cases: 2.2, 3.1, 3.3, 5.1

23


6.3 Search For Books

Use Case Name: Search by ISBN Manual Entry



Brief Description: User manually enters the ISBN


Stakeholders: Buyers and sellers

Preconditions:System is able to search web for a given ISBN;System is able to obtain image of book for ISBN;User has correctly typed the alphanumeric bar code.

Postconditions:System returns an image of the book and current prices; as well as a list of any available copies of that book;User may add book to wish list.

Flow of Activities:

Actor System1. User types in the book

barcode (of a book they currently own) to get current price suggestions.

1.1 System looks up the ISBN and returns info about the book.

Exceptions: Barcode mistyped; no ISBN found by system (obscure textbook); User has not given the app permission to access their camera.


24


6.4 Buy6.4 Buy

Use Case Name: Make an offer to purchaseFunctional Requirement: 4.1

Scenario: User logs in and finds a book to buy.Brief Description:

The user (as buyer) locates an available book in the system and offers to purchase it from the seller.


Stakeholders: User acting as buyer, other users who have listed books as sellers.

Preconditions: Search for the book was successful; the book is available to buy.

Postconditions: System alerts the seller that a buyer is available for their book.

Flow of Activities:

Actor System1. User locates book. 1.1 System displays list of

available books.

2. User offers to purchase book.

2.1 System alerts the seller that a buyer is available.

Exceptions: No books listed for sale

Related Use Cases: 5.1, 4.2

25


6.4 Buy

Use Case Name: Add book to wish list


Scenario: User logs in, searches for a book, and locates its information

Brief Description:

The book requested by the user is not currently available for sale by any sellers.


Stakeholders: User acting as buyer

Preconditions:

There is a book with the specified ISBN;System is able to return current prices for that ISBN;System is able to obtain image of book for ISBN;User has allowed the app to access the camera to scan a barcode;

Postconditions: System has added that book (by ISBN) to the user’s wish list in their account profile

Flow of Activities:

Actor System1. User searches for a book by

ISBN or major1.1 System returns a list of

books available which are tagged with that major.

2. User does not find book for sale, so adds it to wish list

2.1 System records user’s addition to their wish list

3. User does find book, makes offer to buy

3.1 System marks the book “sale pending”, making the book temporarily unavailable.

3.2 System alerts seller that an offer to buy was received.

Exceptions: No books listed for sale; unable to locate info about book.


26


6.5 Sell6.5 Sell

Use Case Name: List a book for saleFunctional Requirement: 5.1

Scenario: User logs in and searches for a book to retrieve its info, and is ready to list it for sale.

Brief Description:

Upon retrieving info about a particular book, the user places the book for sale in the system.

Actors: User as seller

Stakeholders: User as seller, other user(s) acting as buyers

Preconditions:

There is a book with the specified ISBN;System is able to return current prices for that ISBN;System is able to obtain image of book for ISBN;User has allowed the app to access the camera to scan a barcode;

Postconditions: The book is listed as available to purchase.

Flow of Activities:

Actor System1. Seller locates info about

book and places it for sale in the system.

1.1 System records the book as being available.

1.2 System sends alert to buyers who have placed this book on their wish list(s).

Exceptions: Unable to locate info about book with specified ISBN.Related Use Cases: 2.1, 2.2, 2.4, 3.1, 3.2

27


6.6 Transactions6.6 Transactions

Use Case Name: Schedule a meetFunctional Requirement: 6.1

Scenario:A buyer has located an available book and offered to purchase it; a seller has accepted the offer; the system prompts them to arrange a time and place to exchange.

Brief Description: A potential buyer and seller arrange a time to meet to transact a sale.

Actors: User as buyer, other user as seller.

Stakeholders: Buyer and seller

Preconditions: A book was available to purchase; the system notified the seller; the seller agreed to the sale; the buyer was notified that the seller agrees.

Postconditions: Seller and buyer negotiate a time and place to meet.

Flow of Activities:

Actor System1. Seller accepts purchase offer 1.1 System alerts buyer that the

sale is accepted1.2 System prompts buyer and

seller to arrange time to meet up

2. Buyer and seller 2.1 Buyer and seller back and forth until an acceptable time to meet is arranged

3. Buyer and seller can not arrange an acceptable time to meet; Buyer or seller cancels the sale

3.1 System places the book back on the available list.

Exceptions: Seller does not agree to sell book; Buyer and seller can not negotiate a time to meet.

Related Use Cases: 2.3, 4.2, 5.1

28


6.6 Transactions

Use Case Name: Report back


Scenario: Two users have met to trade a book.

Brief Description: A transaction has been made or cancelled (in person)

Actors: User as buyer, other user as seller

Stakeholders: Buyer and seller

Preconditions: Buyer and seller agreed to meet for a transaction

Postconditions: System records user’s rating of the transaction and any reports about users.

Flow of Activities:

Actor System1. Buyer reports any issues

(good or bad) about the transaction

1.1 System records the report1.2 If necessary, system flags a

user who got a bad report(Possibly block users flagged 3 or more times)

2. Seller reports any issues about the transaction

2.1 System records the report2.2 If necessary, system flags a

user who got a bad report2.3 (Possibly block users flagged

3 or more times)

Exceptions: No books listed by that major.Related Use Cases: 2.1, 2.3, 2.4, 6.1

29

Software Project Plan - Kutztown University of...

Documents

Transcript of Software Project Plan - Kutztown University of...