Back to portfolio
Requirements

User registration

Requirements for user registration: user story with acceptance criteria, use case with alternative flows, and prioritized development tasks.

  • User story
  • Acceptance criteria
  • Use case
  • MoSCoW

Task

Write requirements for user registration on the «ABC» platform, from user story to use case to prioritized development tasks.

Approach

  • Started from the user's goal: a user story with acceptance criteria.
  • Detailed the behaviour in a use case: actors, preconditions and postconditions, a 10-step main flow, alternative flows (invalid data, high fraud risk, email failure, unused or expired verification link), and a sub-use case for manual review.
  • Defined the account status model: New → Pending verification → Approved, plus Manual review, Rejected and Cancelled.
  • Broke the feature down into 15 development tasks (UI, internal and external integrations, business logic), prioritized for Soft Launch and Full Launch.

Result

User story

As a new user, I want to create an account at «ABC» platform by providing my basic personal details, so that I can get access to platform functionality.

Acceptance criteria

  • The user registration form should allow users to enter their email addresses and passwords.
  • The platform should validate the uniqueness of the entered email address and the safety of the password according to the business rules and show an error message if the validation fails.
  • The platform should automatically screen each new registration against internal risk rules and mark potentially fraudulent accounts for manual verification.
  • The platform should verify user data by sending a verification email with a unique, time-sensitive link.
  • The platform should show a registration status message if a new user tries to log in with the account in the wrong status.

Use case

Name

«User registration»

Description

A new user signs up for «ABC» platform, enters personal data, passes profile verification procedure and finally gets access to the platform functionality.

Actors

  • User
  • Administrator

Preconditions

  • The user has a valid email address and is able to receive emails.
  • The platform is accessible.
  • The user enters the website of «ABC» platform and decides to sign up.

Postconditions

  • Success: the user account is created in the "Approved" status, and the user can log in to the platform.
  • Failure: the account is not created (invalid registration data), or it ends in the "Rejected" status (after manual review) or the "Cancelled" status (not verified within 24 hours).

Main flow

  1. The user clicks “Sign up” button
  2. The platform opens registration form
  3. The user fills in all required fields (email and password) and clicks “Submit” button
  4. The platform validates the data (unique email, strong password) according to the business rules
  5. The platform creates a user account in the "New" status.
  6. The platform performs the risk assessment procedure, gets a low risk score and shows the user a new form with the notification on the verification procedure.
  7. The platform changes the account status to "Pending verification".
  8. The platform generates a time-sensitive verification link with the unique token and sends a verification email to the user.
  9. The user clicks the verification link in the email within the time limit.
  10. The platform successfully validates the token, marks the user account with "Approved" status and shows the welcome form with “Log in” button.

Alternative flows

4aInvalid Registration Data

If the data is invalid (e.g., duplicate email, weak password), the platform displays an error message and does not create an account. The use case restarts at Step 2.

6aHigh risk score / Risk assessment procedure fails

  1. The risk assessment procedure returns a high risk score or fails.
  2. The platform updates the account status to "Manual review".
  3. The platform adds the verification task to the Administrator's review queue and prioritizes it according to the business rule.

(See «SUB-UC extend» “Perform Manual review”).

8aThe email sending procedure fails

  1. The email sending procedure fails
  2. The platform tries to resend the emails every 15 minutes for 1 hour
  3. If the problem is not solved in 1 hour, the platform sends alert notification to system administrators group

9aThe user doesn’t use the verification link

If the user doesn’t confirm the account in 24 hours, the platform marks the account with "Cancelled" status.

10aEmail Link is invalid

If the link is expired or invalid, the platform informs the user and provides an option to request a new verification email.

Sub-use case: Perform Manual Review

Main flow

  1. The administrator logs into the admin dashboard.
  2. The platform displays the queue of tasks for manual verification (the queue prioritized according to business rule)
  3. The administrator selects the top-priority task and reviews the provided information
  4. The administrator resolves the task with the decision: Approve
  5. The platform reports analytics data
  6. The platform changes account status to "Pending Verification"
  7. The use case returns to the Main UC flow Step 8

Alternative flow

4aReject

  1. The administrator resolves the task with the decision: Reject
  2. The platform reports analytics data
  3. The platform changes account status to "Rejected"

Business rules

Detailed business rules are out of scope of this task.

Development tasks

CodeNamePriority
01_UIDevelop User registration formhigh
02_UIDevelop Error forms
  • Wrong account status to log in
  • Wrong verification link
high
03_UIDevelop User notification form about verification procedurehigh
04_UIDevelop User welcome formhigh
01_API_intDevelop Frontend-Backend APIHigh
02_API_intDevelop API to create the task in Platform Administration moduleMiddle
03_API_intDevelop API to get information on task resolution in Platform Administration moduleMiddle
01_API_extDevelop integration with external API “Send_email” to send emails with verification linksHigh
01_BsLDevelop business rules to check:
  • the uniqueness of emails
  • safety of passwords
High
02_BsLDevelop business rules for risk assessmentMiddle
03_BsLDevelop procedures to generate and verify verification linkHigh
04_BsLDevelop DB procedure to manage user accountsHigh
05_BsLConfigure workflow and analytics for new type of the administration tasksMiddle
06_BsLDevelop resend emails logicLow
07_BsLDevelop account cancellation logicLow

Code legend

  • UI – User interface
  • API_int – internal integrations
  • API_ext – external integrations
  • BsL – business logic

Priority legend

  • High – must have (main features for Soft Launch)
  • Middle – should have (features for Full Launch)
  • Low – could have (additional features)