INSECURE MODE — CAPTCHA is NOT invalidated after use, no rate limiting
Phase 4Development — User Stories & Sprint Planning

Dev Lead — Amir Hassan

Amir receives the architecture design from James and breaks it down into implementable user stories for the development team. The stories are estimated, prioritized, and assigned for the upcoming sprint.

Sprint 24-Q1-03 — Customer Complaint Module

3 stories13 total points
BANK-1247
High5 pts

Implement Customer Complaint Form

As a banking customer, I want to submit a complaint through the online portal so that I can report issues with my banking services.

Acceptance Criteria:

Form includes Author, Comment (max 500 chars), Rating (1-5), and Submit button
Author field is auto-populated with 'anonymous' as default
Form validates that comment is not empty before submission
Successful submission shows a confirmation message with reference number
Sprint 24-Q1-03Dev: Priya Sharma
BANK-1248
High3 pts

Implement CAPTCHA Verification

As a system, I want to verify that the user is human by presenting a math-based CAPTCHA challenge before allowing complaint submission.

Acceptance Criteria:

Server generates a random math question (e.g., 3+8-2) and stores the answer
CAPTCHA question is displayed on the form with an input field for the answer
Server validates the CAPTCHA answer matches the stored answer for the given captchaId
Incorrect CAPTCHA answer returns a 400 error with a descriptive message
Sprint 24-Q1-03Dev: Priya Sharma
BANK-1249
High5 pts

Create Feedback API Endpoint

As a backend developer, I need to create a POST /api/Feedbacks/ endpoint that processes complaint submissions and stores them in the database.

Acceptance Criteria:

Endpoint accepts JSON payload with captchaId, captcha, comment, rating, author
Validates all required fields are present
Stores the feedback in the feedbacks table with auto-generated ID and timestamp
Returns 201 with the created feedback record on success
Sprint 24-Q1-03Dev: Raj Patel

What's Missing from These Stories?

Notice that the acceptance criteria focus entirely on functional correctness — does the form work? Does the CAPTCHA validate? Does it store in the database? But there's nothing about abuse prevention. No mention of CAPTCHA invalidation after use, no rate limiting, no replay detection. A developer implementing these stories exactly as written would create a perfectly functional but completely vulnerable application.