Rideshare System Functional Requirements Document (EN)

about: Version written on 2025/10

0. Revision History

Defines the history of document version control and revision content.

Version	Date	Revised by/Approved by	Revision Summary	Notes
Ver.1.0	27/10/2025	Satoshi	Initial Draft	Initial Draft
Ver.1.1	30/10/2025	Satoshi	Added a deadline for acceptance	3.1.1.1, 4.2.10
			Added/Corrected to perform authorization repeatedly based on the number of matched passengers	3.2.2〜3.2.3.2
			Added option to set a fixed fare for a drive	3.1.6, 3.1.7
			Added points to describe regarding the addition of fares	3.7.4, 4.2.11, 5.9.5
Vre.1.2	03/11/2025	Satoshi	Drive history display correction	2.6.5
			Added simple explanatory sentences for each heading	Overall
			Started adding definitions for future planned expansion features, along with a review of the initial scope	8

1. System Overview and Basic Information

Defines fundamental information such as system name, form, basic policy, target users, and payment methods, which form the foundation of the entire service.

No.	Item	Content	Notes
1.1	System Name	Ride Share Platform notteco	Renewal of https://notteco.jp/
1.2	System Form	Browser-based Web System	Responsive design. The management screen is an exception. Supports camera function (QR code reading) on smartphones.
1.3	Basic Policy	Ensuring Safety and Reliability (eKYC mandatory), Fair Fare Setting, Exclusion of Profitability (Cost sharing of actual expenses)	The core principle of the service.
1.4	Target Users	Passengers, Drivers
1.5	Payment Methods	Passengers: Credit Card, Drivers: Bank Transfer
1.6	Search Function Availability	Search function for drives is available even without user registration.	Introduced to lower the barrier to entry as it is a browser-based service, not an application. Registration is required to use the drive.

Defines basic user functions and account management, such as Membership Registration, Identity Verification (eKYC), My Page, and Payment/Bank Account Information Management.

2.1. Membership Registration and Identity Verification (eKYC)

Definitions regarding the flow of membership registration, age restrictions, and the mechanism for identity verification (eKYC).

No.	Feature Requirement	Detailed Specification	Notes
2.1.1	Access to Registration	Provides the following 3 entry points: 1. Site TOP/Header, 2. Popup when contacting a listed drive, 3. Popup when registering one's own request drive.	Specific flow for browser-based systems.
2.1.2	Use of Search Function	Search function for drives is available even without membership registration.	Lowers the barrier to entry for the service.
2.1.3	Age Restriction	Registration by individuals under 18 years old is prohibited based on the entered date of birth.	Legal and service usage constraints.
2.1.4	Screen Transition after Registration	Transition destination is controlled based on the entry point. Normal flow → TOP, Drive contact → corresponding drive screen, Request registration → Request drive registration screen.	To prevent interruption of user action.
2.1.5	Driver Additional Registration	A "Passenger" status holder can obtain the additional "Driver" status by registering and undergoing screening for vehicle and insurance information.	Allows for staged status upgrade.
2.1.6	Driver's License Validity Check	Checks the expiration date of the driver's license registered via eKYC. If the expiration date is less than X months away, a warning notification is sent to the driver. If expired, drive registration and driver utilization are prohibited.	Maintains the reliability of the driver status.

2.2. Membership Registration Steps and Acquired Information (Definition)

Defines the steps in membership registration and the mandatory/optional information acquired in each step.

No.	Step Name	Detailed Specification	Notes
2.2.1	Step 1: Basic Information Registration	[Mandatory Items] Email address, Password, Phone number, Nickname, Full name, Full name (Kana), Gender, Date of birth, Residence.	Full name (Kana) is used for bank transfers, and the phone number is used for SMS authentication.
2.2.2	Step 2: Review Input Content	User is asked to confirm the content entered in Step 1.
2.2.3	Step 3: SMS Authentication	An x-digit authentication code is sent via SMS to the entered phone number, and the user is prompted to enter the code.	Authentication is mandatory. Prevents fraudulent use.
2.2.4	Step 4: Authentication Complete	Displays the SMS authentication completion screen and guides the user to eKYC.
2.2.5	Step 5: eKYC Execution	Identity verification using a photo ID + selfie is conducted via an external eKYC service. For passenger-only use, IDs other than a driver's license can be selected. For planned driver use, only a driver's license is mandatory.	Identity verification is mandatory. Ensures reliability. Image data is processed and stored by the external service; only the approval/disapproval result is linked to this system.
2.2.6	Step 6: Profile Registration	Registration of Hobbies, Smoking status, Women-only (for female registrants only), Self-introduction text, and Photo. Can be skipped (can be registered later from My Page).	Profile items are a critical factor for matching conditions.
2.2.7	Step 7: Payment/Bank Account Information Registration	Can be skipped (can be registered later from My Page). Details defined in 2.3, 2.4.	Registration can be deferred until the point it becomes mandatory for use.
2.2.8	Step 8: Registration Complete	Displays the completion screen and simultaneously sends the login page URL to the registered email address. Includes a "Log in and Continue" button.
2.2.9	Terms/Policy Consent Log	Records the date/time, version, and IP address when the user agreed to the Terms of Use and Privacy Policy.	Preservation of legal evidence.

2.3. Credit Card Information Registration for Payment (for Passengers)

Defines the registration of credit card information for passengers to pay for drive expenses.

No.	Feature Requirement	Detailed Specification	Notes
2.3.1	Timing of Registration	Registration is required by the time the passenger confirms matching to a drive (when transitioning to the payment screen).	Just before payment processing.
2.3.2	Registration Options	Option to save to My Page. One-time use (one-time input) is also possible.	Reduces the need for repeated input for repeat usage.
2.3.3	Registration Control	This registration is unnecessary if the user only wishes to utilize driver features.	Consideration for users specializing in driver use.

2.4. Driver Additional Registration (Vehicle, Insurance, Fuel Efficiency)

Defines the necessary registration of vehicle and insurance information when upgrading status from Passenger to Driver.

No.	Feature Requirement	Detailed Specification	Notes
2.4.1	Vehicle Information Registration	[Mandatory Items] Vehicle license plate number (registration number), Vehicle model name, Maximum vehicle seating capacity (including the driver), Image upload of the vehicle inspection certificate.	Mandatory for using the driver status. Maximum capacity is used for validation during drive registration.
2.4.2	Insurance Information Registration	[Mandatory Items] Automobile insurance (voluntary insurance) company name, Policy number, Insurance expiration date, Image upload of the insurance policy.	For legal compliance and risk management. Driver use is prohibited if the insurance has expired.
2.4.3	Fuel Efficiency Registration	[Optional Item] Actual fuel efficiency (L/km) or manufacturer's stated value. Not used for system fare calculation but can be displayed as profile information.	For fairness in fare calculation (3.7.2), strictly for reference.
2.4.4	Multiple Vehicle Registration	A driver can register multiple vehicles (2.4.1 to 2.4.3). However, they must select one vehicle to use during drive registration.	Improves driver convenience.
2.4.5	Driver's License Reconfirmation	Confirms that the registered driver's license (2.2.5) and the owner of the vehicle/insurance information match.	Prevents fraudulent use.

2.5. Driver Bank Account Registration (for Drivers)

Defines the registration of bank account information for drivers to receive actual expense reimbursements.

No.	Feature Requirement	Detailed Specification	Notes
2.5.1	Timing of Registration	Can be entered at the time of transfer request to receive the actual expense amount.	Aligns with the timing of actual earnings, not necessarily at the time of driver registration.
2.5.2	Registration Option	Option to "Save to My Page" for the account information entered during the transfer request (one-time input is also possible).

2.6. My Page Functions

Defines a set of features for users to manage their information, such as member information, history, and income/expense management.

No.	Feature Requirement	Detailed Specification	Notes
2.6.1	Member Information Confirmation/Editing	Allows confirmation and editing of member and basic information.	Core information that has been identity-verified (e.g., name, date of birth) cannot be changed without re-authentication via eKYC.
2.6.2	Contact Information Editing	Allows confirmation and modification of email address, phone number, and password.	SMS authentication is mandatory for phone number changes.
2.6.3	Profile Editing	Allows confirmation and editing of smoking status, hobbies, self-introduction text, and photo entered during profile registration.	Changing smoking status is easy as it impacts matching.
2.6.4	Payment/Bank Account Management	Allows confirmation, new addition, deletion, and default setting editing of credit card information (for passengers) and bank account information (for drivers).	One-time credit card use setting can also be confirmed here.
2.6.5	Drive History Display	Lists past drive history (passenger list, conducted list) according to the user's status. Additionally, matched future drive plans are also listed.	Expanded to display future plans as well as past history. Initial construction will only support the list format.
2.6.6	Mutual Rating Results	Users can check the mutual rating received (average score, detailed comments) from past drive history.	Used for understanding and improving reliability.
2.6.7.1	Driver: Actual Expense Accumulation Display	Clearly displays the total accumulated actual expenses to date and the unsettled amount currently available for transfer request.	Supports the driver's income/expense management.
2.6.7.2	Driver: Actual Expense Transfer Request	Allows selection to request a transfer for the full amount or an arbitrary amount of the confirmed unsettled funds.	Enables flexible response to funding needs.
2.6.7.3	Point Balance Display	Displays the current point balance. (Future expansion feature)
2.6.8	Reverse Request History	Displays a list and status of past registered passenger-requested drives (reverse requests).
2.6.9	Frequently Used Routes Management	Allows confirmation, editing, and deletion of "Frequently Used Routes" saved during drive or reverse request registration.	Aims to reduce input load on the registration screen.
2.6.10	Membership Rank Display	Displays the current membership rank (5 levels) and the conditions for promotion to the next rank to the user.	Motivates continued use.
2.6.11	Driver Information (Vehicle/Insurance) Management	Allows confirmation, editing, and addition of new vehicles for registered vehicle information (plate number, model, max capacity, inspection certificate image) and insurance information (company, expiration date).	Maintains eligibility and convenience for driver use.

2.7. Point Usage Function (Future Expansion due to legal interpretations)

Definitions regarding the granting and use of points based on rank and usage history.

No.	Feature Requirement	Detailed Specification	Notes
2.7.1	Point Granting	Grants points to both passengers and drivers based on rank and number of uses (completed drives).	Granting rules are managed in 4.2.7.
2.7.2	Point Usage	Both passengers and drivers can use points to cover drive expenses (actual expenses, service fee).	Functions as a discount/incentive.
2.7.3	Currency Conversion Consideration	Considers legal regulations research and system design to potentially allow conversion/exchange to monetary value in the future (e.g., "x points = y yen").	Currently prohibited by law, but anticipates future expansion.

2.8. Login/Logout Functions

Definitions regarding user authentication, session management, and security.

No.	Feature Requirement	Detailed Specification	Notes
2.8.1	Login	Authentication via email address and password. Provides a two-factor authentication option.	Ensures user security.
2.8.2	Password Reset	Sends a reset URL to the registered email address to allow password re-setting.	SMS authentication can be used in combination to prevent fraudulent use.
2.8.3	Logout	Destroys the session and returns to the pre-login state.	Automatic logout when closing the browser will also be considered.
2.8.4	Session Maintenance	Allows session maintenance for a fixed period (automatic login) if the user selects it.	Improves UX (User Experience).

3. Drive/Matching Feature Definitions (Frontend)

Defines the core functions of the service, such as Drive Registration, Fare Setting, Matching Process, Fare Recalculation, Cancellation Process, and Search.

3.1. Drive Registration and Fare Setting (Driver Function)

Function for the driver to set the drive route, date/time, capacity, and fare.

No.	Feature Requirement	Detailed Specification	Notes
3.1.1	Basic Information Input	Mandatory input of departure location, destination, via points (optional, maximum 3 at release), departure date/time, and number of available seats (capacity). Validation is set so that the number of available seats does not exceed the maximum vehicle seating capacity (2.4.1) minus 1 driver (calculated based on adult count).	Via points are optional, but if set, route search must consider them. Driver safety and vehicle capacity compliance.
3.1.1.1	Drive Acceptance Deadline Setting	The default acceptance deadline for a drive registered by a driver is set to 60 minutes before the scheduled departure time. The driver can optionally set a deadline, up to this default time limit (60 minutes before), during drive registration.	The default time can be changed by the operator in 4.2.10. After the set deadline, the drive is hidden from the search list.
3.1.2	Fare Calculation Logic	entire route, including via points $Fare = (\frac{Distance \times Fuel Cost}{Capacity}) + (\frac{Toll Road Fee (after discount)}{Capacity})$ .	Regardless of via points, the total distance and total toll road fees for the entire route are shared.
3.1.2.1	Toll Road Fee Calculation	Accurately calculates the toll road fee after discount application by referencing the ETC fare database based on the planned route (entire route including via points), departure date/time, and day of the week.	Requires real-time or up-to-date fare data.
3.1.2.2	ETC Discount Consideration	The logic includes discounts relevant to the departure time, such as late-night, holiday, and commuter discounts.	Maintains fare fairness.
3.1.3	Exclusion of Profitability Control	Validation is set to prevent setting an amount higher than the system-calculated fare limit.	Considers the legal aspect of a carpooling service.
3.1.4	Optional Fare Setting	The driver can change the fare to an arbitrary amount lower than the calculated fare.
3.1.5	Re-registration Function	Allows new registration by citing information from history/template, with only the date/time setting being mandatory.	Improves driver convenience.
3.1.6	Fixed Fare Setting for Passengers	The driver can set a uniform fixed amount per passenger, up to the per-person fare calculated by the system based on the system-calculated fare (3.1.2) divided by (Driver + Available Capacity).	Addition of fare setting option. This ensures that the per-passenger fare does not fluctuate due to changes in the number of matched passengers.
3.1.7	Validation for Fixed Amount Setting	Validation is set to ensure that the total sum of $\times$ Available Capacity does not exceed the total actual expense amount, which is System Calculated Fare (3.1.2) minus the system fee applied to the total cost.	Guarantees Exclusion of Profitability (1.3) and the maximum value for the fixed fare setting.

3.2. Matching Process and Fare Recalculation

Functions related to processing after matching, such as passenger request approval, fare recalculation logic, authorization process, mutual rating, and chat.

No.	Feature Requirement	Detailed Specification	Notes
3.2.1	Request Processing	Passengers send a request, and the driver selects approval/rejection.	Driver-approved system.
3.2.2	Fare Recalculation Logic (Correction/Refinement)	If a fixed fare setting (3.1.6) was selected during drive registration, fare recalculation due to an increase or decrease in the number of matched people is not performedproportional setting $N$ people (including the driver), the fare is Total Expense / N.	Recalculation logic is skipped for fixed fare settings. Ensures fairness in cost sharing.
3.2.2.1	Authorization Process at Matching Completion	In the case of a fixed fare setting (3.1.6), a pre-authorization (auth) process is performed on the passenger's card for the fixed fare per passenger. In the case of a proportional setting, at the point the first person is matched, the fare based on the proportional division by 2 people (including the driver) is calculated, and a pre-authorization (auth) process is performed on the passenger's card.	Securing funds and the starting point for fare fluctuation.
3.2.2.2	Fare Recalculation and Re-Authorization for Additional Matching	In the case of a fixed fare setting (3.1.6), re-authorization for all existing passengers is not triggered even when the second or subsequent passengers are matched. Only the additional passenger undergoes authorization for the fixed amount. In the case of a proportional setting, each time the second or subsequent passengers are matched, the fare is recalculated based on the established number of people (Driver + all passengers). The system executes a process to re-authorize (pre-authorize) all existing passengers with the changed amount.	The cost will generally decrease in a proportional setting as the number of people increases. Caution regarding system load.
3.2.2.3	Fare Recalculation and Re-Authorization upon Cancellation	In the case of a fixed fare setting (3.1.6), even if a passenger cancels, re-authorization for all remaining passengers is not triggered. Only the canceling passenger undergoes payment processing based on the cancellation policy (3.4) and authorization is released. In the case of a proportional setting, if a passenger cancels after matching completion, the fare is recalculated based on the remaining established number of people. The system executes a process to re-authorize all remaining passengers with the changed amount.	The cost will generally increase in a proportional setting as the number of people decreases. Linked to the cancellation policy (3.4).
3.2.3	Payment Reservation (Authorization)	Immediately upon matching completion, the full final fare is pre-authorized (auth) on the passenger's card. (If a credit card is not registered, the user is prompted to register on the payment screen.)	Ensures funds are secured before the drive.
3.2.3.1	Display of Notice Regarding Fare Fluctuation (at Payment)	When matching is executed and the first payment reservation (auth) occurs, only for the proportional setting, a notice must clearly state that "Re-authorization will occur repeatedly, and the cost may increase or decrease due to changes in the number of matched people or cancellations."	Aligns user expectations regarding potential fare fluctuations.
3.2.3.2	Display of Notice Regarding Fare Fluctuation (on Detail Screen)	In the fare display area of the drive detail screen, only for the proportional setting, a notice must state that "Re-authorization will occur repeatedly, and the cost may increase or decrease due to changes in the number of people."	Ensures information is provided before the drive request.
3.2.4	Mutual Rating Function	After the drive is completed, the passenger and driver provide a mutual 5-star rating and comment.	Building reliability.
3.2.4.1	Completion Flag Function	The system sets the final completion flag for the drive when mutual rating is completed by both the passenger and the driver.	Used as the final completion condition for the drive. Triggers payment processing and history logging.
3.2.5	Chat Function	1-to-1 messaging function limited to the period from matching completion until the start of the drive.	For coordinating the meeting point.
3.2.6	Current Location Sharing	Provides a function on the chat screen after matching completion for the user to send their current location information (with map display) to the other party.	The sent location information is displayed as a pin on the map and is overwritten by the next location information transmission or expires (e.g., 30 minutes).
3.2.7	Ride Reminder Notification	Sends a reminder notification via email or SMS to both the passenger and driver 24 hours and 1 hour before the drive start time.	The notification includes details of the meeting place, a link to the chat, and the cancellation policy.
3.2.8	Forced Review Submission	Making the drive's mutual rating (review) mandatory for the system to consider the drive complete. Temporarily restricts further drive usage if the rating is incomplete.	Maximizes the review collection rate to ensure reliability.

3.3. Reverse Request Function (Passenger-Requested Drive)

Function for passengers to register their desired origin, destination, date/time, etc., to encourage drivers to register a corresponding drive.

No.	Feature Requirement	Detailed Specification	Notes
3.3.1	Desired Drive Registration	Passengers register the origin, destination, via points (optional, maximum 3), desired date/time, and desired number of people.	Via points are optional, allowing more specific desired routes to be presented to drivers.
3.3.2	Notification to Drivers	Notifies drivers when the request has a high match rate with their "Frequently Used Drives."	Encourages potential drive opportunities.
3.3.3	Drive Generation	Drivers can use the request information to auto-fill the new drive registration screen.	Reduces the driver's registration load.
3.3.4	Notification to Passengers	An individual notification is sent to the requesting passenger when a driver publicly registers a drive.	Provides matching opportunities.
3.3.5	Re-registration Function	Allows new requests by citing information from past request history, with only the date/time setting being mandatory.	Reduces the passenger's request registration load.
3.3.6	Driver Search Function	Drivers can view the list of passenger requests via search (origin, destination, date/time).	Allows drivers to actively look for requests, not just relying on notifications.
3.3.7	Request Acceptance Deadline Setting	The default acceptance deadline for a request registered by a passenger is set to 360 minutes before the scheduled departure time. The passenger can optionally set a deadline, up to this default time limit (360 minutes before), during request registration.	The default time can be changed by the operator in 4.2.10. After the set deadline, the request is hidden from the driver's search list.
3.3.7	Separation of Search UI	Adopts a UI that clearly separates the "Search for a Drive" button (for passengers) and the "Search for Drive Requests" button (for drivers) on the site TOP and search screen.	Provides clear entry points based on the user's role.

3.4. Cancellation Process and Policy

Defines the policy, fees, penalties, and administrator intervention rules for drive cancellation.

No.	Feature Requirement	Detailed Specification	Notes
3.4.1	Policy Setting	Defines and applies a cancellation fee rate based on the time remaining until the drive start time.
3.4.1.1	Mutual Agreement Exemption	If the counterparty agrees (approves) an explicit cancellation request from one user within the deadline, no penalty (fee charge, reward payment, rating reduction, etc.) is incurred.	Encourages amicable cancellation.
3.4.1.2	Administrator Intervention on No Response	If the counterparty does not take action on a cancellation request within the system-defined period (e.g., 24 hours), an alert is issued to the administrator.	Prevents delays in resolving disputes.
3.4.1.3	Administrator Processing	The administrator can, based on the alert, check the situation and ultimately execute the cancellation completion process (including applying/waiving penalties).	Problem resolution through operational intervention.
3.4.2	Non-Payment Processing	Automatic cancellation and release of authorization (with refund processing) if payment is not made by the deadline.
3.4.3	Same-Day No-Show (Passenger)	Full charge (penalty) is applied to the passenger and a reward is paid to the driver based on the driver's report.	Compensates for the driver's time loss.
3.4.4	Same-Day Non-Performance (Driver)	The passenger's authorization is released (full refund), and a strict penalty is applied to the driver.	To protect the service's reliability.
3.4.5	Completion Status	When the cancellation process is complete, the status of the drive becomes "Cancellation Complete," and the rating function is hidden.	Ratings only apply to executed drives.

3.5. Drive Search, List, and Detail Screens

Defines search criteria, result display, filters, and the structure of the detail screen for users to find drives.

No.	Feature Requirement	Detailed Specification	Notes
3.5.1.1	Search Items	Mandatory items: Departure location, Destination, Departure date/time. Optional items: Number of passengers, Via points (max 3 locations).	Enables simple and intuitive searching.
3.5.1.2	Search Result List	Drives that match the search criteria are displayed in a list sorted by time sequence.
3.5.1.3	List Display Items	Items to be displayed on each drive card: Date and time of departure, Departure/Destination (place name and icon), Fare (per person), Driver's nickname and profile image, Number of available seats.	Structure allows quick grasp of necessary information.
3.5.1.4	Filter Function	Provides the following filter/sort functions for the search results: Fare (Ascending/Descending), Departure Time, Direct trips only, Smoking status, Filter by hobby, Others.	Allows users to narrow down based on preferred conditions.
3.5.1.5	Hobby Filter	Allows filtering based on hobbies and interests (multiple selections possible) registered in the driver's profile.	Promotes matching between users with common conversation points.
3.5.1.6	Other Filters	Provides a filter area that can be expanded for future feature expansion (e.g., pet allowance, luggage limits, in-car Wi-Fi availability).
3.5.1.7	Search Result Optimization	The search results (3.5.1.2) default to a "Recommended Order" that comprehensively considers factors such as proximity from origin/destination, driver's average rating, and fare, not just time order.	Improves the matching rate.
3.5.2.1	Drive Detail Screen	A page displaying all information for the selected drive.
3.5.2.2	Detail Screen Components	Includes the following information: 1. Route Map Display 2. Fare and Available Seats 3. Driver Information 4. Exact Pick-up/Drop-off Points 5. Vehicle Information 6. Drive Registration Comments	Aggregates information to assess driver reliability and drive comfort.
3.5.2.3	Request Flow	A large "Ride Request" button is placed at the bottom or side of the detail screen. Unregistered users are guided to the Login/New Registration popup (2.1.1).
3.5.2.4	Flexibility of Pick-up/Drop-off Points	On the drive detail screen, an option is displayed to set an arbitrary point within X km of the origin/destination set by the driver as the "Actual Pick-up/Drop-off Point."	Improves user convenience. If driver approval is required for the request, coordination is prompted via chat (3.2.5).

3.6. Drive Start/End Functions

Functions that trigger ride confirmation (QR code) at the start of the drive, completion operation, and subsequent payment processing.

No.	Item	Feature Requirement	Detailed Specification	Notes
3.6.1	Passenger QR Code Presentation	When the passenger performs the "Display Ride QR" operation on the drive detail screen, a QR code is displayed on the screen.	The QR code includes ride information such as Drive ID and Passenger ID.	Presented by the passenger boarding as proof of their ride.
3.6.2	Driver QR Code Reading	The driver performs ride confirmation on the system side by reading the passenger's QR code using the in-browser camera function.	If there are multiple passengers, the driver individually reads the QR codes of all scheduled passengers to confirm boarding for each. This sets the drive start flag.	Utilizes the browser's Media Devices API. Also applies to additional pick-ups at via points.
3.6.3	UI Control after Ride Confirmation	For passengers whose boarding is confirmed after reading, the QR display button is hidden on their screen.	Prevents unauthorized reuse.
3.6.4	Driver Drive End Operation	After confirming the passenger's drop-off, the driver initiates the drive completion process by pressing the "End Drive" button on the drive detail screen.	The end operation offers options to select all passengers at once or select individually (for drop-offs at via points) who have alighted.	Starting point for drive completion.
3.6.5	Transition to Mutual Rating Screen	When the driver executes the end operation and the system determines the completion conditions are met, a link to the mutual rating input screen is displayed on the screens of both the passenger and the driver.	Guides to rating completion. (Links to 3.2.4)
3.6.6	Payment Processing (Actual Sale/Completion)	Upon completion of the mutual rating (3.2.4.1), the authorization (pre-authorization) on the passenger is released, and the actual sale (capture) process is executed.	Finalization of expenses. Trigger for reward payment processing.

3.7. Prerequisites for Fare Calculation

Definitions of the values and rules that serve as the basis for ensuring fairness and transparency in fare calculation (3.1.2).

No.	Feature Requirement	Detailed Specification	Notes
3.7.1	Display of Actual Expense Calculation Basis	The drive detail screen clearly displays the figures that form the basis of the actual expense sharing amount to both passengers and drivers, such as distance (km), fuel cost coefficient (JPY/km), toll road fees (after discount), and number of passengers applied in the fare calculation logic (3.1.2).	Ensures transparency of the fare to guarantee the "Exclusion of Profitability" (1.3).
3.7.2	Fuel Efficiency Application per Vehicle	The standard fuel efficiency value (4.2.2) per vehicle model/class set in the management screen, based on the vehicle information registered by the driver, is applied to the calculation of fuel costs in the fare calculation logic (3.1.2).	Fair standard values are used, rather than the driver's actual fuel efficiency, to maintain fare stability.
3.7.3	System Fee Application	The system usage fee is added to the fares of both the driver and the passenger, based on the system fee rate (4.2.1.1) set on the management screen, and displayed. The fee does not affect the driver's actual expense share.	Clarifies the revenue source for service operation and complies with the principle of actual cost sharing (1.3).
3.7.4	Clarification of Fare Setting Standard	The drive detail screen clearly displays to both passengers and drivers whether the set fare is based on a "proportional system based on the number of matched people" or a "uniform fixed fare system (3.1.6)."	Clarifies the fare setting standard and prevents user misunderstandings.

3.8. Trouble/Fraud Prevention Features

Functions for reporting, blocking, and rating control in the event of fraudulent activities or disputes between users or against the system.

No.	Feature Requirement	Detailed Specification	Notes
3.8.1	Reporting Function	Allows reporting of violations of the terms of use, such as harassment, same-day non-performance, or suspected fraudulent use, both before and after the drive execution.	Flow for rapid dispute resolution (4.3.3.1).
3.8.2	Blocking Function	Provides a blocking function for users to reject requests or messages from specific individuals.	Prevents unwanted contact between users.
3.8.3	Rating Weighting	Introduces a logic where the system controls the influence (weight) of mutual ratings (3.2.4) based on driver/passenger status, past usage history, and membership rank.	Suppresses fraudulent use and bias in the rating system.

4. Management Screen (Back Office) Feature Definitions

Defines features required for the back office, such as User/Legal Compliance Management, Service Operation Settings, Drive/Matching Monitoring, Payment/Financial Management, Data Analysis, and Operator Permissions.

4.1. User and Legal Compliance Management

Management functions related to legal compliance, such as searching/managing user information, checking eKYC screening results, and managing driver vehicle/insurance information.

No.	Feature Requirement	Detailed Specification	Notes
4.1.1	Registered User Management	User information search/listing, forced suspension/resumption of accounts function.	Basis for fraudulent use and trouble handling.
4.1.2	eKYC Screening	Assigns approval/disapproval status based on the linkage result from the external eKYC service. (Image data is not viewable).	Strict identity verification is performed. If screening is completed by the external service, this item only reflects the status.
4.1.3	Vehicle/Insurance Information Management	Confirmation of driver vehicle information and insurance information. Alert function for insurance expiration date.	Legal compliance and risk management.
4.1.4	Operator Account Management	The System Administrator (Full Admin, 4.6.1) can create, edit, suspend, and delete accounts for Operation Administrators (Operator, 4.6.2).	Maintenance of the back-office operation structure.
4.1.5	Permission Granting/Modification	The System Administrator can select the role (permission level) to be granted when creating and editing an operator account.	Application of appropriate access rights.

4.2. Service Operation and Setting Management

Functions to manage various settings that form the core of the service, such as fare calculation parameters, master data, and terms content.

No.	Feature Requirement	Detailed Specification	Notes
4.2.1.1	Fare Calculation Parameter Control	Allows editing and updating of variables in the fare calculation logic, such as the system fee rate and fuel cost coefficient per distance.	Adjustment of service profitability and fare fairness.
4.2.1.2	Toll Road Fee Master Management	Manages and updates master data required for fare calculation, such as ETC discount types, applicable time slots, and discount rates.	For accurate operation of the fare calculation logic.
4.2.2	Fuel Efficiency Value Control for Registered Vehicles	Registers and updates standard fuel efficiency values (L/km) per vehicle model/class as master data.	Basis for fare calculation.
4.2.3	NG Word Control	Master management function to register, edit, and delete prohibited words.	Maintenance of content health.
4.2.4	Terms/Policy CMS	CMS function to update the text content of the Terms of Use and various policies.	Rapid response to law changes.
4.2.5	Marketing Tag Management	Screen to configure and register measurement tags such as Google Analytics (GA) tags.	Preparation of access analysis environment.
4.2.6	SEO/Meta Tag Management	Function to register and edit SEO meta tags for the entire site and individual pages, and OG tags for social media.	Search engine optimization and improved SNS sharing.
4.2.7.1	Basic Point Granting Rule Setting	Allows management and setting of the basic point granting rate according to rank and usage count (completed drives).	Included as an important point for future expansion.
4.2.7.2	Campaign Grant Rate Control	Allows control of the increase (boost) in the point granting rate when specific periods or conditions are set and met. Multiple settings are possible.	Included as an important point for future expansion.
4.2.8	Penalty Rule Master Management	Allows setting and changing of same-day cancellation penalty rates (3.4.3, 3.4.4) and trigger conditions for forced account suspension in the management screen.	Flexible management of service operation rules.
4.2.9	Membership Rank Criteria Setting	Allows setting of promotion/demotion criteria for membership ranks (2.5.10) (e.g., number of completed drives, average rating score, cumulative actual expense contribution) from the management screen as master data.	Flexible operation of user motivation measures.
4.2.10	Drive Acceptance Deadline Master Management	Allows setting and updating the default acceptance deadline (in minutes) for Drives (driver registration) and Drive Requests (passenger request) as a numerical value.	Enables control of default values applied in the frontend (3.1.1.1, 3.3.7).
4.2.11	Operational Rules for Fixed Fare Setting	Allows setting the maximum value for the fixed fare that a driver can set from the management screen, based on a coefficient calculated from the proportional value derived from the system-calculated fare (3.1.2).	Necessary to manage the operational risk (exclusion of profitability) of the fixed fare setting.

4.3. Drive/Matching Management

Functions to monitor and manage the status after matching, such as checking drive registration information, chat monitoring, and tracking trouble reports.

No.	Feature Requirement	Detailed Specification	Notes
4.3.1	Drive Information List	Search and list display of registered drives (with auxiliary information such as registration count, execution count, completion count).	Overall grasp of service provision status.
4.3.2	Monitoring of Matching Messages	Extracts chat logs where NG words are detected and displays them with an alert for administrators.	Early detection of disputes and evidence preservation.
4.3.3.1	Trouble Report Tracking	Accepts trouble reports from users (e.g., same-day non-performance) and manages the response status.	Streamlines CS (Customer Support) operations.
4.3.3.2	Cancellation No-Response Alert	Notifies the administrator screen with a high-priority alert when the counterparty's response to a cancellation request exceeds the stipulated deadline (e.g., 24 hours).	Identification of cases requiring administrator intervention.
4.3.4	Alert Display for Users Potentially Violating Terms	Automatically detects and lists high-risk users based on history of frequent cancellations, NG word usage, etc.	Identification of pre-emptive risks.

4.4. Payment/Financial Management

Management functions related to finance, such as sales, fees, reward payment processing to drivers, and tracking of payment transactions.

No.	Feature Requirement	Detailed Specification	Notes
4.4.1	Sales Aggregation and Driver Reward Payment Processing	Automatic aggregation of total sales, fees, and total payments by period. Generation of reward payment lists and export of bank transfer data.	Automation of accounting tasks.
4.4.2	Payment Log Tracking	Log function to search and track all payment transactions (authorization, refund, fees).	For audit and tracking during disputes.
4.4.3	Point Log Management	Tracks and manages the history of point granting, usage, and expiration for each user.	For audit and checking fraudulent use. Included as an important point for future expansion.

4.5. Data Analysis/Monitoring

Functions to visualize and analyze key service KPIs, user demographics, and usage trends through graphs and reports.

No.	Feature Requirement	Detailed Specification	Notes
4.5.1	Numerical Analysis Screen	Dashboard to visualize key KPIs such as drive registration count, execution count, completion count, and cancellation rate with graphs.	Grasping service growth rate and challenges.
4.5.2.1	User Demographics Aggregation	Aggregates and displays data such as new member registration count, withdrawal count (churn rate), daily/monthly active users (DAU/MAU), and user type (driver/passenger) ratio.	Service overall health check.
4.5.2.2	Usage Trend Analysis	Analysis reports on drive demand by area and time zone.	Basis for marketing strategy planning.
4.5.2.3	Needs Route Aggregation	Aggregation of data registered by users as "Frequently Used Routes." Allows extraction of high-demand routes, separate from actual drive performance.	Used to identify latent demand and areas where new drive registration should be encouraged.
4.5.3	Rating/Review Analysis	Extracts and lists the average mutual rating and low-rated comments.	Maintenance and improvement of service quality.

4.6. Back Office Operator Permission Definition

Clearly defines the access rights and scope of operation for each role: System Administrator and Operation Administrator.

4.6.1. Operator Role Definition

Defines the management screen users according to their permission level.

No.	Role Name	Permission Level	Notes
4.6.1	System Administrator (Full Admin)	Full Access	Has access rights to all functions, including overall system operation, personal information management, financial processing, and data export.
4.6.2	Operation Administrator (Operator)	Limited Access	Has limited access rights necessary for operation, such as drive/matching monitoring, CS response, and viewing profiles/messages. Personal information viewing is prohibited.

4.6.2. Access Target Function and Permission Mapping

Maps the extent of access rights each role has for individual management functions.

4.7. Management Screen Access/Authentication Function

Functions related to security and authentication for operators to access the management screen.

No.	Feature Requirement	Detailed Specification	Notes
4.7.1	Management Screen Login Function	System and Operation Administrators must use dedicated login authentication (ID/Password) to access the management screen.	Strictly prevents access by unauthorized users.
4.7.2	Multi-Factor Authentication (MFA)	Multi-Factor Authentication (MFA) is mandatory or recommended for logging into the management screen.	Enhanced security for highly confidential data protection.
4.7.3	Password Policy	Enforces a strong password policy (length, use of upper/lower case, symbols) for management screen authentication information.
4.7.4	Access Log Recording	All histories of login/logout, and login failures by operators are recorded as audit logs (7.1).	Monitoring unauthorized access and preservation of audit trails.

5. Infrastructure/Security Requirements (To be coordinated with relevant parties)

Defines requirements for the system infrastructure and security, such as Personal Information Protection, Data Encryption, External Collaboration, Location Information Management, and Legal Compliance.

No.	Item	Feature Requirement	Detailed Specification	Notes
5.1	Personal Information Data Encryption/Storage	Confidential information such as Full Name, Phone Number, and Bank Account Information is saved with AES-256 encryption.	Encryption keys are managed with AWS KMS (Key Management Service). eKYC image data is not included.	Most critical security requirement.
5.2	Data Split Storage (Separation)	Confidential data and non-confidential data (nickname, drive history, etc.) are saved separated at the database or table level.	Only external reference keys such as User ID are shared, and access rights are separated.	Enhanced security and legal compliance.
5.3	External Collaboration: Payment Service (Stripe)	Credit card information (2.3) is not retained on the company server but is directly stored on Stripe's secure infrastructure (PCI DSS compliant), and only tokenized information is managed in the company database.	Maintains PCI DSS compliance.	Non-retention of credit card information.
5.4	External Collaboration: Map Service (Google Maps)	Utilizes the Google Maps Platform API for route calculation, geocoding, and location information sharing.	Strict management of API Keys and setting of API restrictions to prevent fraudulent use.	Stable utilization of collaboration services.
5.5	Establishment of Notification Infrastructure	Notifications related to matching and reminders are appropriately sent via push notifications, SMS, or email based on user usage status.	Utilizes AWS SNS/SES or third-party notification services to ensure a configuration that allows reliable and timely notifications.	Ensures user convenience and immediacy.
5.6	Use of Serverless/Containers	Actively utilizes technologies such as AWS Lambda or Amazon ECS/EKS for processes with large load fluctuations, such as drive fare recalculation, point calculation, and batch processing.	Scalability and cost optimization.
5.7	Camera Access Requirements	For the QR code reading function (3.6.2), HTTPS connection is mandatory for in-browser camera use, and implementation includes the use of the Media Devices API and control of user permission requests.	Ensures feasibility of the function in a browser-based environment.
5.8	External Collaboration: eKYC Service	In eKYC collaboration, image data of identity verification documents is not retained or passed through this system at all.	The system only receives the approval/disapproval status, confirmation completion date/time, and attribute information such as name and date of birth extracted from the submitted information via API collaboration with the external service.	Most critical item for legal aspects and reduction of security risk.
5.9.1	Clarification of Personal Information Usage Purpose	The specific purpose of use for acquired personal information is clearly stated during member registration (2.2.1) and in the Terms of Use/Privacy Policy.	It is explicitly stated that location information (3.2.6, 3.5.1.1) will not be used for purposes other than drive matching, understanding operating status, and emergency contact.	Most critical item for compliance with Personal Information Protection Law and other regulations.
5.9.2	Location Information (GPS) Usage Control	The real-time location sharing function (3.2.6) is designed to be sent to the counterparty user only when the user explicitly operates it. Also, the shared information has an expiration date.	Continuous tracking is not performed, limiting usage based on user intent. When the expiration date (30 minutes) is reached, the pin on the map is deleted or hidden.	Prioritizes privacy protection.
5.9.3	Log Anonymization	Defines a process to anonymize personally identifiable information in operational logs after a certain period or when used for aggregation.	Strengthens privacy protection while meeting legal record retention requirements.	Reduces the risk of confidential information remaining in logs for an extended period.
5.9.4	Withdrawal (Data Deletion)	If a user performs the withdrawal procedure, all personal information data is completely deleted from the system unless there is a legally defined period or a legitimate business reason.	Only the minimum necessary information such as the withdrawal log and transaction history is stored in an anonymized form, and other confidential information (5.1) is promptly deleted.	Enables response that considers the Right to be Forgotten.
5.9.5	Agreement on Fare Fluctuation/Fixed Fare	When requesting a drive, it is clearly stated whether the fare is a proportional system (potential for fluctuation) or a fixed fare system (no fluctuation), and a log of the passenger's understanding and agreement to this setting is recorded.	Prevents fare-related disputes and preserves legal evidence.

6. Development, Testing, and Deployment Requirements (To be coordinated with relevant parties)

Defines requirements for the development process and quality assurance, such as Development Environment, Technology Stack, Code Quality, Testing Policy, and CI/CD Environment.

No.	Item	Feature Requirement	Detailed Specification	Notes
6.1	Development Environment/Technology Stack	Selects and defines development languages, frameworks (frontend/backend), and main DB (e.g., AWS RDS).	Clearly states the reasons for technology selection (e.g., scalability, development efficiency).	Must be defined at the start of the project.
6.2	Code Quality	Formulates a unified coding standard, makes code review mandatory, and introduces static code analysis tools.	Early bug detection and maintenance assurance.	Quality assurance.
6.3	Testing Policy	Unit tests (UT) and integration tests (IT) are automated, and coverage goals are set. System testing (ST) specifically verifies the accuracy of the fare calculation logic (3.1.2).	Core of quality assurance.
6.4	CI/CD Environment	Constructs a Continuous Integration (CI) and Continuous Deployment (CD) pipeline. (e.g., AWS CodePipeline/GitHub Actions)	Enables automatic deployment after successful testing, balancing development speed and safety.	Improved delivery efficiency.
6.5	Separation of Production Environment and Data	Completely separates Development/Staging/Production environments, and prohibits direct access to production data from the development environment.	Security and data protection.

7. Operation, Maintenance, and Audit Requirements (To be coordinated with relevant parties)

Defines requirements for service continuity after release, such as System Audit Logs, Alert Settings, Performance Goals, Data Backup, and Incident Response Flow.

No.	Item	Feature Requirement	Detailed Specification	Notes
7.1	System Audit Logs	All privileged operations, such as Full Admin (4.6.1.1) viewing personal information, changing system setting masters, and suspending/resuming accounts, are recorded, and tamper-proofing measures are implemented.	Links with 4.6 to enable tracking of unauthorized operations and information leaks.	Most critical item for log audit.
7.2	Critical Alert Settings	Urgent notifications are sent to administrators when the payment failure rate exceeds X%, eKYC approval fails Y times consecutively, or the server response time exceeds Z seconds.	Utilizes monitoring services like AWS CloudWatch and links with the notification infrastructure in 5.5.	Early detection of incidents.
7.3	Performance Goal (Response Time)	The response time for key user-facing screens (search results display, drive details) is less than X seconds on average.	Assumes N concurrent users and implements load testing.	Maintenance of UX (User Experience).
7.4	Data Backup Strategy	The database implements automated backup and cross-region (or cross-availability zone) replication based on RTO (Recovery Time Objective) and RPO (Recovery Point Objective).	Data loss prevention and rapid service recovery.	Data preservation.
7.5	Incident Response Flow	The detection, reporting, response, and escalation flow in case of an incident are clearly defined and documented.	Rapid service recovery and prevention of response delays.	Service continuity.

8. Future Planned Expansion Features Definition

Defines features that are outside the initial construction scope, such as Event Calendar Function and AI-Powered Inquiry/QA Function, which will be considered for future addition. Note: These are excluded from the scope of initial construction priority judgment and are not merged with other definitions.

8.1. Event Calendar Function

A set of features that links event information with drive/request registration to create matching opportunities for specific events.

8.1.1. Member-Facing Feature Definition

Functions related to viewing event information, guiding to drive/request registration, and displaying calendars on My Page.

No.	Feature Requirement	Detailed Specification	Notes
8.1.1.1	Event Information Masterization	Basic information such as event name, date/time, venue, and summary is registered and managed as master data, either by crawling external sites or by operator registration.
8.1.1.2	Event Calendar Construction	An event calendar page is constructed based on the masterized information.
8.1.1.3	Display Format Switching	Allows switching between monthly and weekly displays in addition to the calendar format.
8.1.1.4	Transition to Event Details	Clicking on an event title on the calendar transitions to the event detail page.
8.1.1.5	Event Detail Display Items	The event detail page includes event information as well as information necessary for drive registration or request registration (e.g., suggestion of origin/destination).
8.1.1.6	Guidance to Drive Registration	A "Register Drive for this Event" button is placed on the event detail page, leading to the new drive registration screen (3.1), with event information (date/time, venue, etc.) pre-filled.	For drivers.
8.1.1.7	Guidance to Request Registration	A "Register Request for this Event" button is placed on the event detail page, leading to the reverse request registration screen (3.3), with event information (date/time, venue, etc.) pre-filled.	For passengers.
8.1.1.8	My Page: Drive Schedule Calendar Display Function	Enables a calendar format display for the drive schedule display on My Page (2.6.5).	Defined as an expansion of the display format of 2.6.5.
8.1.1.9	My Page: Display Format Switching Function	Allows switching between calendar and list format displays for the drive schedule display on My Page (2.6.5).

8.1.2. Operator-Facing Feature Definition

Functions for administrators to register/manage event information and approve external crawl results.

No.	Feature Requirement	Detailed Specification	Notes
8.1.2.1	Event Master Management Function	Provides a management function (to be added to 4.2 series) to create new, edit, delete event information, and approve/reject external crawl information.
8.1.2.2	Crawl/Registration Information Validation	Implements validation logic to ensure that the registered event's venue is accurately linked to map information and that the date/time is valid.

8.2. Inquiry/QA Function

A set of features that utilizes AI and chat to promote user self-resolution and streamline CS operations.

8.2.1. Member-Facing Feature Definition

Frontend features for users to access self-resolution or live chat.

No.	Feature Requirement	Detailed Specification	Notes
8.2.1.1	Placement of QA Page (FAQ)	A separate QA page is prepared within the site, displaying a list of "Frequently Asked Questions" organized by category.
8.2.1.2	Search Function within QA Page	A free-word search function targeting question text and answer text is installed within the QA page.
8.2.1.3	Placement of Chat Window	A chat window is installed on the main pages and QA page of the site to enhance the path to inquiries.	Improves the ease of reaching the inquiry function.
8.2.1.4	AI First Response	An AI chatbot is introduced within the chat window, enabling automatic responses (first response) based on the QA master (8.2.2.2) and manuals in response to user input.	Streamlines CS operations.
8.2.1.5	Switching to Live Support	Provides a seamless transition to live operator chat (real-time or messaging) if the AI chatbot cannot resolve the issue.

8.2.2. Operator-Facing Feature Definition

Functions for managing the AI chatbot, editing the QA master, and centralized management of live chat.

No.	Feature Requirement	Detailed Specification	Notes
8.2.2.1	Chat/Inquiry Management System	Provides a dashboard for the centralized management of user chats and live support messages. (Links with 4.3 series)
8.2.2.2	QA Master Management (CMS)	Provides a CMS function (links with 4.2.4) to create new, edit, and categorize the Frequently Asked Questions and Answers.	Used as the answer source for the AI chatbot.
8.2.2.3	AI Response Log/Analysis	Provides a function to record and analyze the response history and resolution rate by the AI chatbot.	Used to improve the accuracy of the QA master and AI.

about: Version written on 2025/10

0. Revision History

1. System Overview and Basic Information

2. User-Related Feature Definitions (Frontend)

2.1. Membership Registration and Identity Verification (eKYC)

2.2. Membership Registration Steps and Acquired Information (Definition)

2.3. Credit Card Information Registration for Payment (for Passengers)

2.4. Driver Additional Registration (Vehicle, Insurance, Fuel Efficiency)

2.5. Driver Bank Account Registration (for Drivers)

2.6. My Page Functions

2.7. Point Usage Function (Future Expansion due to legal interpretations)

2.8. Login/Logout Functions

3. Drive/Matching Feature Definitions (Frontend)

3.1. Drive Registration and Fare Setting (Driver Function)

3.2. Matching Process and Fare Recalculation

3.3. Reverse Request Function (Passenger-Requested Drive)

3.4. Cancellation Process and Policy

3.5. Drive Search, List, and Detail Screens

3.6. Drive Start/End Functions

3.7. Prerequisites for Fare Calculation

3.8. Trouble/Fraud Prevention Features

4. Management Screen (Back Office) Feature Definitions

4.1. User and Legal Compliance Management

4.2. Service Operation and Setting Management

4.3. Drive/Matching Management

4.4. Payment/Financial Management

4.5. Data Analysis/Monitoring

4.6. Back Office Operator Permission Definition

4.6.1. Operator Role Definition

4.6.2. Access Target Function and Permission Mapping

4.7. Management Screen Access/Authentication Function

5. Infrastructure/Security Requirements (To be coordinated with relevant parties)

6. Development, Testing, and Deployment Requirements (To be coordinated with relevant parties)

7. Operation, Maintenance, and Audit Requirements (To be coordinated with relevant parties)

8. Future Planned Expansion Features Definition

8.1. Event Calendar Function

8.1.1. Member-Facing Feature Definition

8.1.2. Operator-Facing Feature Definition

8.2. Inquiry/QA Function

8.2. Inquiry/QA Function

8.2.1. Member-Facing Feature Definition

8.2.2. Operator-Facing Feature Definition

supplement

suppl.01. Membership Registration Flow

suppl.03. Reverse Request Matching Flow (Passenger-Led)

suppl.04. Cancellation Process Flow