Stuff Lending System Problem Description

Introduction

An environment-conscious community seeks to develop a system that promotes item sharing, reducing the overall amount of consumer goods each household needs to possess. The Stuff Lending System allows members to lend out their belongings in exchange for credits, which they can use to borrow items from others. The system tracks where items are at a given time.

Stuff Lending System Use Cases

Primary Actors

Member The members register their possessions to the system and earn credits for every listing. They also lend items from other members using credits and are responsible for returning the items within the agreed time.

System Administrator Manages overall system functionality and provides administrative oversight. This includes tracking item listings, membership records, and the day counter.

Supporting Actors

Member Validation Service Ensures unique member registration by validating identity, and checking email and phone number uniqueness.

Use Cases

Stuff Lending System Use Cases

Primary Actors

Member The members register their possessions to the system and earn credits for every listing. They also lend items from other members using credits and are responsible for returning the items within the agreed time.

System Administrator Manages overall system functionality and provides administrative oversight. This includes tracking item listings, membership records, and the day counter.

Supporting Actors

Member Validation Service Ensures unique member registration by validating identity, and checking email and phone number uniqueness.

Use Cases

1 Authenticate

A person wants to be authenticated as a role. The person is authenticated and assigned a role.

Precondition: The person is not already authenticated.

Postcondition: The person is authenticated as a role (Member, System Administrator).

Main Scenario

  1. The person wants to be authenticated.
  2. The system asks for log in information.
  3. The person supplies a username and password.
  4. The system controls the username and password and authenticates the person as a role (Member, System Administrator) in the system, the assigned role is presented.

Secondary Scenarios

2.1 The combination of user name and password is wrong

  1. The system presents an error message and asks for log in information again.
  2. Go to step 3 in main scenario.

2 Register Member

Precondition: The person is not yet registered in the Stuff Lending System. Postcondition: The person is registered as a member and assigned a unique member ID.

Main Scenario:

  1. The person initiates a request to register as a member.
  2. The system asks for member information.
  3. The person supplies a username, a password, an email and a phone number.
  4. The system contacts the Member Validation Service with the email and phone number.
  5. The Member Validation Service checks the identity of the person and returns a positive reply.
  6. The system creates a new member profile, assigns a unique member ID, and records the date of creation.

Secondary Scenario:

4A. The system detects a non-unique email or phone number

  1. The system denies the registration request and informs the user of the reason for denial.

5A. The Member Validation Service cannot confirm the identity.

  1. The system denies the registration request and informs the user of the reason for denial.

3 Add Item

Main Scenario:

  1. The member provides the item details including category, name, and a short description.
  2. System validates the information and registers the item to the member's account.
  3. The system rewards member with 100 credits and records the day of item registration.

4 Establish Lending Contract and Verify Credit Amount

Precondition: The borrower has enough credits and the item is available for specific timeframe. Postcondition: A contract is created, credits are transferred, and item availability is updated for specific timeframe.

Main Scenario:

  1. Member initiates a request to borrow an item.
  2. System verifies the member's credit amounts against the item's lending cost.
  3. If sufficient credits exist, move forward with lending process.
  4. System creates a lending contract.
  5. Credits are transferred from lender member to lending member based on the contract.

Secondary Scenario:

3A. If member does not have enough credits or the item is unavailable, the system denies the lending request.

5 Advance Day Count

Main Scenario:

  1. Admin triggers Advance Day count command.
  2. System increases the current day count.
  3. System triggers all established lending contracts.
  4. Each lending contract triggers a credit transfer equalling the item's lending cost.
  5. System transfers credits from the borrowing member to the lending member's account.

Secondary Scenario:

4A. If a lending contract cannot be executed (i.e. insufficient credits), the system flags the contract and notifies both the borrowing and lending member.

6 Change Item information

Main Scenario:

  1. Member initiates a request to update item details.
  2. System validates and updates the requested information.

7 Member Profile Update

Main Scenario:

  1. Member initiates a request to update profile information.
  2. System validates the information and updates the member's profile.

8 View Member/Item details

Main Scenario:

  1. A request is initiated to view Member/Item details.
  2. System fetches and displays the requested details.

9 Delete Member

Precondition: The member exists in the system. Postcondition: The member and their associated data are removed from the system.

Main Scenario:

  1. A request to delete a specific member profile is initiated.
  2. System validates and deletes the member profile.

10 Delete an Item

Precondition: The item is listed in the system. Postcondition: The Item and its associated data are removed from the system.

Main Scenario:

  1. A request to delete a specific item is initiated.
  2. System validates and deletes the item from the system.

11 View Contracts

Precondition: A contract exists for the member (as a borrower or a lender).

Main Scenario:

  1. Member requests to view contract details.
  2. System retrieves the necessary contract information and displays it to the member.

12 List All Members

Main Scenario:

  1. Admin triggers a request to view all members.
  2. System retrieves and displays all member details and number of owned items in a simple or verbose manner.

Open Issues

Open Issues

  1. Define Credit System: The use cases mention that a member gains credits when they list an item and spends credits when they borrow. It would help to define a use case detailing the conditions under which credits are awarded, spent, or transferred.

  2. Item Availability and Loan Terms: More details are needed about how item availability is determined and tracked. What happens if a borrowed item is not returned within the agreed timeframe should also be defined.

  3. Conflict Resolution: It's unclear what happens if there's a disagreement between two members over an item's condition, or if an item is lost or damaged. Incorporating a use case covering conflict resolution or dispute processes might be necessary.

  4. Notifications: Notifications or updates being sent to members should be covered in the use cases. This is a common feature in lending or rental platforms. A use case for notifications, especially in situations like credit transfers, item unavailability, or disputed transactions, should be considered.