@intentsolutions/blueprint 2.0.0 โ 2.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/cli.js +1 -1
- package/dist/cli.js.map +1 -1
- package/dist/core/index.d.ts +62 -0
- package/dist/core/index.d.ts.map +1 -0
- package/dist/core/index.js +137 -0
- package/dist/core/index.js.map +1 -0
- package/dist/index.d.ts +9 -0
- package/dist/index.d.ts.map +1 -0
- package/dist/index.js +11 -0
- package/dist/index.js.map +1 -0
- package/dist/mcp/index.d.ts +7 -0
- package/dist/mcp/index.d.ts.map +1 -0
- package/dist/mcp/index.js +216 -0
- package/dist/mcp/index.js.map +1 -0
- package/package.json +30 -10
- package/templates/core/01_prd.md +465 -0
- package/templates/core/02_adr.md +432 -0
- package/templates/core/03_generate_tasks.md +418 -0
- package/templates/core/04_process_task_list.md +430 -0
- package/templates/core/05_market_research.md +483 -0
- package/templates/core/06_architecture.md +561 -0
- package/templates/core/07_competitor_analysis.md +462 -0
- package/templates/core/08_personas.md +367 -0
- package/templates/core/09_user_journeys.md +385 -0
- package/templates/core/10_user_stories.md +582 -0
- package/templates/core/11_acceptance_criteria.md +687 -0
- package/templates/core/12_qa_gate.md +737 -0
- package/templates/core/13_risk_register.md +605 -0
- package/templates/core/14_project_brief.md +477 -0
- package/templates/core/15_brainstorming.md +653 -0
- package/templates/core/16_frontend_spec.md +1479 -0
- package/templates/core/17_test_plan.md +878 -0
- package/templates/core/18_release_plan.md +994 -0
- package/templates/core/19_operational_readiness.md +1100 -0
- package/templates/core/20_metrics_dashboard.md +1375 -0
- package/templates/core/21_postmortem.md +1122 -0
- package/templates/core/22_playtest_usability.md +1624 -0
|
@@ -0,0 +1,687 @@
|
|
|
1
|
+
# โ
Acceptance Criteria Library & Validation Framework
|
|
2
|
+
|
|
3
|
+
**Metadata**
|
|
4
|
+
- Last Updated: {{DATE}}
|
|
5
|
+
- Maintainer: AI-Dev Toolkit
|
|
6
|
+
- Related Docs: Consumes 10_user_stories.md, feeds 12_qa_gate.md, 17_test_plan.md
|
|
7
|
+
|
|
8
|
+
> **๐ฏ Purpose**
|
|
9
|
+
> Comprehensive acceptance criteria patterns and validation framework ensuring consistent, testable, and complete requirements definition. This library provides enterprise-grade criteria templates that eliminate ambiguity and enable automated testing validation.
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## ๐ 1. Acceptance Criteria Framework & Standards
|
|
14
|
+
|
|
15
|
+
### 1.1 Gherkin Syntax Standards
|
|
16
|
+
**Given-When-Then Pattern:**
|
|
17
|
+
```gherkin
|
|
18
|
+
Given [initial context and preconditions]
|
|
19
|
+
When [user performs specific action]
|
|
20
|
+
Then [expected system response or outcome]
|
|
21
|
+
And [additional verification points]
|
|
22
|
+
But [negative case or exception]
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
**Quality Standards:**
|
|
26
|
+
- **Clear Context:** Given statements establish unambiguous starting conditions
|
|
27
|
+
- **Specific Actions:** When statements describe exact user interactions
|
|
28
|
+
- **Measurable Outcomes:** Then statements define verifiable results
|
|
29
|
+
- **Complete Coverage:** All scenarios and edge cases included
|
|
30
|
+
- **Testable Language:** Criteria can be automated with test frameworks
|
|
31
|
+
|
|
32
|
+
### 1.2 Acceptance Criteria Categories
|
|
33
|
+
| Category | Purpose | Pattern Template | Testing Approach |
|
|
34
|
+
|----------|---------|------------------|------------------|
|
|
35
|
+
| **Functional** | Core feature behavior | Given/When/Then scenarios | Automated unit/integration tests |
|
|
36
|
+
| **Performance** | Speed and efficiency | Response time constraints | Load testing and benchmarks |
|
|
37
|
+
| **Security** | Access and data protection | Auth/permissions scenarios | Security testing and audits |
|
|
38
|
+
| **Usability** | User experience | User interaction flows | Usability testing and feedback |
|
|
39
|
+
| **Compatibility** | Cross-platform support | Device/browser scenarios | Cross-platform testing |
|
|
40
|
+
| **Accessibility** | Inclusive design | Screen reader/keyboard nav | Accessibility testing tools |
|
|
41
|
+
|
|
42
|
+
### 1.3 Criteria Completeness Checklist
|
|
43
|
+
**Before Story Approval:**
|
|
44
|
+
- [ ] Happy path scenarios documented
|
|
45
|
+
- [ ] Error handling scenarios defined
|
|
46
|
+
- [ ] Edge cases and boundary conditions covered
|
|
47
|
+
- [ ] Performance requirements specified
|
|
48
|
+
- [ ] Security considerations included
|
|
49
|
+
- [ ] Accessibility requirements defined
|
|
50
|
+
- [ ] Browser/device compatibility specified
|
|
51
|
+
- [ ] Data validation rules documented
|
|
52
|
+
|
|
53
|
+
---
|
|
54
|
+
|
|
55
|
+
## ๐ 2. Authentication & Security Criteria Patterns
|
|
56
|
+
|
|
57
|
+
### 2.1 User Login & Authentication
|
|
58
|
+
**Pattern: Successful Login Flow**
|
|
59
|
+
```gherkin
|
|
60
|
+
Scenario: Valid user login with email and password
|
|
61
|
+
Given I am on the login page
|
|
62
|
+
And I have a valid user account with email "user@example.com"
|
|
63
|
+
When I enter email "user@example.com"
|
|
64
|
+
And I enter the correct password
|
|
65
|
+
And I click "Sign In"
|
|
66
|
+
Then I should be redirected to the dashboard
|
|
67
|
+
And I should see a welcome message with my name
|
|
68
|
+
And my session should be active for 24 hours
|
|
69
|
+
And the login attempt should be logged successfully
|
|
70
|
+
|
|
71
|
+
Scenario: Invalid login credentials
|
|
72
|
+
Given I am on the login page
|
|
73
|
+
When I enter email "user@example.com"
|
|
74
|
+
And I enter an incorrect password
|
|
75
|
+
And I click "Sign In"
|
|
76
|
+
Then I should see error message "Invalid email or password"
|
|
77
|
+
And I should remain on the login page
|
|
78
|
+
And the failed attempt should be logged for security monitoring
|
|
79
|
+
And I should not be logged in
|
|
80
|
+
|
|
81
|
+
Scenario: Account lockout after failed attempts
|
|
82
|
+
Given I have failed to login 4 times in the last 15 minutes
|
|
83
|
+
When I attempt to login with any credentials
|
|
84
|
+
Then I should see error message "Account temporarily locked. Try again in 15 minutes."
|
|
85
|
+
And my account should be locked for 15 minutes
|
|
86
|
+
And a security alert should be sent to my email
|
|
87
|
+
And the lockout should be logged for security review
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
### 2.2 Password Security & Validation
|
|
91
|
+
**Pattern: Password Strength Requirements**
|
|
92
|
+
```gherkin
|
|
93
|
+
Scenario: Strong password validation
|
|
94
|
+
Given I am creating a new password
|
|
95
|
+
When I enter a password with at least 8 characters
|
|
96
|
+
And it contains at least one uppercase letter
|
|
97
|
+
And it contains at least one lowercase letter
|
|
98
|
+
And it contains at least one number
|
|
99
|
+
And it contains at least one special character
|
|
100
|
+
Then the password should be accepted
|
|
101
|
+
And I should see "Strong password" indicator
|
|
102
|
+
And the password should be encrypted before storage
|
|
103
|
+
|
|
104
|
+
Scenario: Weak password rejection
|
|
105
|
+
Given I am creating a new password
|
|
106
|
+
When I enter "password123"
|
|
107
|
+
Then I should see error "Password must contain uppercase, lowercase, number, and special character"
|
|
108
|
+
And the password should not be accepted
|
|
109
|
+
And I should see suggestions for improving password strength
|
|
110
|
+
And no password should be stored
|
|
111
|
+
|
|
112
|
+
Scenario: Common password prevention
|
|
113
|
+
Given I am creating a new password
|
|
114
|
+
When I enter a password from the common passwords list
|
|
115
|
+
Then I should see error "Please choose a less common password"
|
|
116
|
+
And the password should not be accepted
|
|
117
|
+
And I should be prompted to try a different password
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
### 2.3 Multi-Factor Authentication Criteria
|
|
121
|
+
**Pattern: 2FA Setup and Usage**
|
|
122
|
+
```gherkin
|
|
123
|
+
Scenario: Enable TOTP-based 2FA
|
|
124
|
+
Given I am logged into my account settings
|
|
125
|
+
And 2FA is currently disabled
|
|
126
|
+
When I click "Enable Two-Factor Authentication"
|
|
127
|
+
Then I should see a QR code for authenticator app setup
|
|
128
|
+
And I should see manual entry key as backup
|
|
129
|
+
And I should be prompted to enter verification code
|
|
130
|
+
And setup should not complete until verification succeeds
|
|
131
|
+
|
|
132
|
+
Scenario: 2FA login verification
|
|
133
|
+
Given I have 2FA enabled on my account
|
|
134
|
+
And I have entered correct username and password
|
|
135
|
+
When I am prompted for 2FA code
|
|
136
|
+
And I enter a valid TOTP code from my authenticator
|
|
137
|
+
Then I should be logged in successfully
|
|
138
|
+
And I should bypass 2FA for 30 days on this device (if "Remember me" selected)
|
|
139
|
+
And the successful 2FA should be logged
|
|
140
|
+
|
|
141
|
+
Scenario: 2FA backup code usage
|
|
142
|
+
Given I have 2FA enabled but lost my authenticator device
|
|
143
|
+
When I click "Use backup code instead"
|
|
144
|
+
And I enter a valid unused backup code
|
|
145
|
+
Then I should be logged in successfully
|
|
146
|
+
And the backup code should be marked as used
|
|
147
|
+
And I should be prompted to regenerate backup codes
|
|
148
|
+
And I should receive email notification about backup code usage
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
---
|
|
152
|
+
|
|
153
|
+
## ๐ฐ 3. Payment & Billing Criteria Patterns
|
|
154
|
+
|
|
155
|
+
### 3.1 Payment Processing
|
|
156
|
+
**Pattern: Credit Card Payment Flow**
|
|
157
|
+
```gherkin
|
|
158
|
+
Scenario: Successful credit card payment
|
|
159
|
+
Given I am on the payment page for a $29.99 subscription
|
|
160
|
+
When I enter valid credit card number "4242424242424242"
|
|
161
|
+
And I enter expiration date "12/25"
|
|
162
|
+
And I enter CVV "123"
|
|
163
|
+
And I enter billing zip code "12345"
|
|
164
|
+
And I click "Complete Payment"
|
|
165
|
+
Then the payment should be processed within 10 seconds
|
|
166
|
+
And I should see confirmation message "Payment successful"
|
|
167
|
+
And I should receive email receipt within 5 minutes
|
|
168
|
+
And my subscription should be activated immediately
|
|
169
|
+
And I should be redirected to the success page
|
|
170
|
+
|
|
171
|
+
Scenario: Declined payment card
|
|
172
|
+
Given I am on the payment page
|
|
173
|
+
When I enter a card that will be declined "4000000000000002"
|
|
174
|
+
And I complete the payment form
|
|
175
|
+
And I click "Complete Payment"
|
|
176
|
+
Then I should see error "Your card was declined. Please try a different payment method."
|
|
177
|
+
And I should remain on the payment page
|
|
178
|
+
And no charge should be made to the card
|
|
179
|
+
And the failed payment should be logged
|
|
180
|
+
And I should be able to enter different payment information
|
|
181
|
+
|
|
182
|
+
Scenario: Payment form validation
|
|
183
|
+
Given I am on the payment page
|
|
184
|
+
When I enter invalid card number "1234"
|
|
185
|
+
Then I should see real-time validation error "Invalid card number"
|
|
186
|
+
And the "Complete Payment" button should be disabled
|
|
187
|
+
And the invalid field should be highlighted in red
|
|
188
|
+
When I enter valid card number "4242424242424242"
|
|
189
|
+
Then the validation error should disappear
|
|
190
|
+
And the field should be highlighted in green
|
|
191
|
+
And the "Complete Payment" button should be enabled
|
|
192
|
+
```
|
|
193
|
+
|
|
194
|
+
### 3.2 Subscription Management
|
|
195
|
+
**Pattern: Plan Upgrade/Downgrade**
|
|
196
|
+
```gherkin
|
|
197
|
+
Scenario: Upgrade subscription plan
|
|
198
|
+
Given I am on the "Basic" plan at $9.99/month
|
|
199
|
+
And I am viewing available plans
|
|
200
|
+
When I click "Upgrade" on the "Premium" plan at $19.99/month
|
|
201
|
+
Then I should see upgrade confirmation showing:
|
|
202
|
+
| Current Plan | Basic ($9.99/month) |
|
|
203
|
+
| New Plan | Premium ($19.99/month) |
|
|
204
|
+
| Prorated Amount | $6.67 (remaining days) |
|
|
205
|
+
| Next Bill Date | Same as current cycle |
|
|
206
|
+
When I confirm the upgrade
|
|
207
|
+
Then my plan should change to Premium immediately
|
|
208
|
+
And premium features should be available instantly
|
|
209
|
+
And I should be charged the prorated amount
|
|
210
|
+
And my next bill should be the full Premium amount
|
|
211
|
+
|
|
212
|
+
Scenario: Downgrade subscription plan
|
|
213
|
+
Given I am on the "Premium" plan at $19.99/month
|
|
214
|
+
When I select downgrade to "Basic" plan
|
|
215
|
+
Then I should see warning "You will lose access to: Advanced Analytics, Priority Support, API Access"
|
|
216
|
+
And I should see "Downgrade will take effect at your next billing cycle (March 15)"
|
|
217
|
+
When I confirm the downgrade
|
|
218
|
+
Then I should receive confirmation email
|
|
219
|
+
And my current Premium features should remain active until March 15
|
|
220
|
+
And my next bill should be for Basic plan ($9.99)
|
|
221
|
+
And downgrade should be scheduled in billing system
|
|
222
|
+
```
|
|
223
|
+
|
|
224
|
+
### 3.3 Invoice and Billing History
|
|
225
|
+
**Pattern: Billing History Access**
|
|
226
|
+
```gherkin
|
|
227
|
+
Scenario: View billing history
|
|
228
|
+
Given I am a paying customer with 6 months of history
|
|
229
|
+
When I navigate to "Billing & Payments" section
|
|
230
|
+
Then I should see a table of all past invoices with:
|
|
231
|
+
| Date | Amount | Status | Plan | Download |
|
|
232
|
+
And invoices should be sorted by date (newest first)
|
|
233
|
+
And I should be able to filter by date range
|
|
234
|
+
And I should be able to search by amount or status
|
|
235
|
+
And each invoice should have a "Download PDF" link
|
|
236
|
+
|
|
237
|
+
Scenario: Download invoice PDF
|
|
238
|
+
Given I am viewing my billing history
|
|
239
|
+
When I click "Download PDF" for any invoice
|
|
240
|
+
Then a PDF should download within 5 seconds
|
|
241
|
+
And the PDF should contain:
|
|
242
|
+
- Company name and billing address
|
|
243
|
+
- Invoice number and date
|
|
244
|
+
- Itemized charges with taxes
|
|
245
|
+
- Payment method used
|
|
246
|
+
- Total amount paid
|
|
247
|
+
And the PDF should be properly formatted for printing
|
|
248
|
+
```
|
|
249
|
+
|
|
250
|
+
---
|
|
251
|
+
|
|
252
|
+
## ๐ 4. Data & Analytics Criteria Patterns
|
|
253
|
+
|
|
254
|
+
### 4.1 Dashboard Performance
|
|
255
|
+
**Pattern: Real-time Data Display**
|
|
256
|
+
```gherkin
|
|
257
|
+
Scenario: Dashboard data loading performance
|
|
258
|
+
Given I have analytics data for the past 30 days
|
|
259
|
+
When I navigate to the analytics dashboard
|
|
260
|
+
Then the page should start loading within 500ms
|
|
261
|
+
And the initial charts should render within 2 seconds
|
|
262
|
+
And real-time data should update every 30 seconds
|
|
263
|
+
And I should see loading indicators during data refresh
|
|
264
|
+
And the dashboard should remain responsive during updates
|
|
265
|
+
|
|
266
|
+
Scenario: Dashboard data accuracy
|
|
267
|
+
Given I have performed 100 actions in the past 24 hours
|
|
268
|
+
When I view my dashboard metrics
|
|
269
|
+
Then the "Total Actions" count should show 100
|
|
270
|
+
And the data should be current within 5 minutes
|
|
271
|
+
And historical trend data should match previous day snapshots
|
|
272
|
+
And all percentages should be calculated correctly
|
|
273
|
+
And data should be consistent across different chart views
|
|
274
|
+
|
|
275
|
+
Scenario: Dashboard responsiveness
|
|
276
|
+
Given I am viewing the dashboard on different devices
|
|
277
|
+
When I access it on desktop (1920x1080)
|
|
278
|
+
Then all charts should be clearly visible
|
|
279
|
+
And navigation should be accessible
|
|
280
|
+
When I access it on tablet (768x1024)
|
|
281
|
+
Then charts should adapt to smaller screen
|
|
282
|
+
And touch interactions should work properly
|
|
283
|
+
When I access it on mobile (375x667)
|
|
284
|
+
Then charts should stack vertically
|
|
285
|
+
And all data should remain accessible
|
|
286
|
+
```
|
|
287
|
+
|
|
288
|
+
### 4.2 Data Export and Reporting
|
|
289
|
+
**Pattern: CSV Export Functionality**
|
|
290
|
+
```gherkin
|
|
291
|
+
Scenario: Export data to CSV
|
|
292
|
+
Given I am viewing analytics for a specific date range
|
|
293
|
+
When I click "Export to CSV"
|
|
294
|
+
Then a CSV file should download within 10 seconds
|
|
295
|
+
And the filename should include the date range "analytics_2024-01-01_2024-01-31.csv"
|
|
296
|
+
And the CSV should contain all visible data points
|
|
297
|
+
And column headers should be descriptive
|
|
298
|
+
And data should be formatted consistently
|
|
299
|
+
And special characters should be properly escaped
|
|
300
|
+
|
|
301
|
+
Scenario: Large dataset export
|
|
302
|
+
Given I am exporting data for 12 months (>10,000 records)
|
|
303
|
+
When I initiate the export
|
|
304
|
+
Then I should see progress indicator
|
|
305
|
+
And I should receive email when export is complete
|
|
306
|
+
And the export should complete within 5 minutes
|
|
307
|
+
And the file should be compressed if over 10MB
|
|
308
|
+
And I should be able to continue using the app during export
|
|
309
|
+
|
|
310
|
+
Scenario: Export data validation
|
|
311
|
+
Given I have exported my analytics data
|
|
312
|
+
When I open the CSV file in Excel
|
|
313
|
+
Then all numeric values should be properly formatted
|
|
314
|
+
And dates should be in consistent format (YYYY-MM-DD)
|
|
315
|
+
And there should be no missing or corrupted data
|
|
316
|
+
And formulas should not be executed (data only)
|
|
317
|
+
And the file should open without errors
|
|
318
|
+
```
|
|
319
|
+
|
|
320
|
+
---
|
|
321
|
+
|
|
322
|
+
## ๐ 5. Search & Filtering Criteria Patterns
|
|
323
|
+
|
|
324
|
+
### 5.1 Search Functionality
|
|
325
|
+
**Pattern: Basic Text Search**
|
|
326
|
+
```gherkin
|
|
327
|
+
Scenario: Successful search with results
|
|
328
|
+
Given I have 50 items in my account
|
|
329
|
+
And 5 items contain the word "project"
|
|
330
|
+
When I enter "project" in the search box
|
|
331
|
+
And I press Enter
|
|
332
|
+
Then I should see 5 search results within 1 second
|
|
333
|
+
And results should be ranked by relevance
|
|
334
|
+
And search terms should be highlighted in results
|
|
335
|
+
And I should see "5 results for 'project'" message
|
|
336
|
+
And pagination should appear if more than 10 results
|
|
337
|
+
|
|
338
|
+
Scenario: Search with no results
|
|
339
|
+
Given I am on a page with searchable content
|
|
340
|
+
When I search for "nonexistent123"
|
|
341
|
+
Then I should see "No results found for 'nonexistent123'" message
|
|
342
|
+
And I should see suggestions like "Try different keywords" or "Check spelling"
|
|
343
|
+
And I should have option to clear search and start over
|
|
344
|
+
And the search should complete within 1 second
|
|
345
|
+
|
|
346
|
+
Scenario: Search auto-suggestions
|
|
347
|
+
Given I am typing in the search box
|
|
348
|
+
When I type "proj"
|
|
349
|
+
Then I should see dropdown with suggestions starting with "proj"
|
|
350
|
+
And suggestions should appear within 300ms
|
|
351
|
+
And I should be able to select suggestions with mouse or keyboard
|
|
352
|
+
And my search history should influence suggestions
|
|
353
|
+
And suggestions should disappear when I click outside
|
|
354
|
+
```
|
|
355
|
+
|
|
356
|
+
### 5.2 Advanced Filtering
|
|
357
|
+
**Pattern: Multi-criteria Filtering**
|
|
358
|
+
```gherkin
|
|
359
|
+
Scenario: Apply multiple filters
|
|
360
|
+
Given I am viewing a list of 100 items
|
|
361
|
+
When I apply filter "Status: Active"
|
|
362
|
+
Then the list should update to show only active items
|
|
363
|
+
And item count should update to reflect filtered results
|
|
364
|
+
When I additionally apply filter "Category: Technology"
|
|
365
|
+
Then the list should show only items that are both Active AND Technology
|
|
366
|
+
And I should see applied filters as removable tags
|
|
367
|
+
And I should be able to clear individual filters or all filters
|
|
368
|
+
|
|
369
|
+
Scenario: Filter performance with large datasets
|
|
370
|
+
Given I have 10,000 items in my account
|
|
371
|
+
When I apply any single filter
|
|
372
|
+
Then results should update within 2 seconds
|
|
373
|
+
And I should see loading indicator during filtering
|
|
374
|
+
And the UI should remain responsive
|
|
375
|
+
When I apply multiple filters in quick succession
|
|
376
|
+
Then each filter should build upon the previous results
|
|
377
|
+
And the final result should be accurate
|
|
378
|
+
```
|
|
379
|
+
|
|
380
|
+
---
|
|
381
|
+
|
|
382
|
+
## ๐ฑ 6. Mobile & Responsive Criteria Patterns
|
|
383
|
+
|
|
384
|
+
### 6.1 Mobile Interface Behavior
|
|
385
|
+
**Pattern: Touch Interface Optimization**
|
|
386
|
+
```gherkin
|
|
387
|
+
Scenario: Touch target sizing
|
|
388
|
+
Given I am using the app on a mobile device
|
|
389
|
+
When I view any interactive element (buttons, links, form fields)
|
|
390
|
+
Then each touch target should be at least 44px x 44px
|
|
391
|
+
And there should be at least 8px spacing between adjacent targets
|
|
392
|
+
And touch targets should provide visual feedback when pressed
|
|
393
|
+
And accidental touches should be minimized through proper spacing
|
|
394
|
+
|
|
395
|
+
Scenario: Mobile form interaction
|
|
396
|
+
Given I am filling out a form on mobile
|
|
397
|
+
When I tap on an email input field
|
|
398
|
+
Then the email keyboard should appear automatically
|
|
399
|
+
And the page should scroll to keep the input visible
|
|
400
|
+
When I tap on a phone number field
|
|
401
|
+
Then the numeric keypad should appear
|
|
402
|
+
And the input should accept phone number formatting
|
|
403
|
+
When I submit the form
|
|
404
|
+
Then validation should work the same as on desktop
|
|
405
|
+
And success/error messages should be clearly visible
|
|
406
|
+
|
|
407
|
+
Scenario: Mobile navigation menu
|
|
408
|
+
Given I am on mobile and tap the hamburger menu
|
|
409
|
+
When the menu opens
|
|
410
|
+
Then it should cover the screen or slide in smoothly
|
|
411
|
+
And all navigation items should be easily tappable
|
|
412
|
+
And I should be able to close the menu by tapping outside
|
|
413
|
+
And the menu should remember my position when I return
|
|
414
|
+
And nested menus should work intuitively with touch
|
|
415
|
+
```
|
|
416
|
+
|
|
417
|
+
### 6.2 Cross-Device Synchronization
|
|
418
|
+
**Pattern: Multi-device Consistency**
|
|
419
|
+
```gherkin
|
|
420
|
+
Scenario: Data sync across devices
|
|
421
|
+
Given I make changes on my desktop
|
|
422
|
+
When I open the app on my mobile device within 1 minute
|
|
423
|
+
Then I should see all recent changes reflected
|
|
424
|
+
And data should be consistent across both devices
|
|
425
|
+
And no data should be lost in the synchronization
|
|
426
|
+
And sync conflicts should be handled gracefully
|
|
427
|
+
|
|
428
|
+
Scenario: Session continuity
|
|
429
|
+
Given I start a task on desktop
|
|
430
|
+
When I switch to mobile before completing it
|
|
431
|
+
Then I should be able to continue where I left off
|
|
432
|
+
And my progress should be preserved
|
|
433
|
+
And form data should be retained (if appropriate)
|
|
434
|
+
And I should receive seamless experience across devices
|
|
435
|
+
```
|
|
436
|
+
|
|
437
|
+
---
|
|
438
|
+
|
|
439
|
+
## ๐ก๏ธ 7. Security & Compliance Criteria Patterns
|
|
440
|
+
|
|
441
|
+
### 7.1 Data Protection & Privacy
|
|
442
|
+
**Pattern: GDPR Compliance**
|
|
443
|
+
```gherkin
|
|
444
|
+
Scenario: User data export request
|
|
445
|
+
Given I am a user requesting my personal data
|
|
446
|
+
When I submit a data export request
|
|
447
|
+
Then I should receive confirmation within 24 hours
|
|
448
|
+
And my complete data export should be provided within 30 days
|
|
449
|
+
And the export should include all personal data in machine-readable format
|
|
450
|
+
And I should be able to verify the completeness of exported data
|
|
451
|
+
And the export should be delivered via secure, encrypted method
|
|
452
|
+
|
|
453
|
+
Scenario: Right to be forgotten
|
|
454
|
+
Given I request deletion of my personal data
|
|
455
|
+
When I confirm the deletion request
|
|
456
|
+
Then all my personal data should be permanently deleted within 30 days
|
|
457
|
+
And I should receive confirmation of deletion
|
|
458
|
+
And my data should be removed from all backups within 90 days
|
|
459
|
+
And anonymized analytics data may be retained
|
|
460
|
+
And I should not be able to recover the deleted data
|
|
461
|
+
|
|
462
|
+
Scenario: Data processing consent
|
|
463
|
+
Given I am a new user signing up
|
|
464
|
+
When I create my account
|
|
465
|
+
Then I should see clear explanation of data collection
|
|
466
|
+
And I should be able to opt-in to marketing communications separately
|
|
467
|
+
And I should be able to withdraw consent at any time
|
|
468
|
+
And my choices should be respected immediately
|
|
469
|
+
And I should be able to update my preferences easily
|
|
470
|
+
```
|
|
471
|
+
|
|
472
|
+
### 7.2 Access Control & Permissions
|
|
473
|
+
**Pattern: Role-based Access Control**
|
|
474
|
+
```gherkin
|
|
475
|
+
Scenario: Admin user permissions
|
|
476
|
+
Given I am logged in as an administrator
|
|
477
|
+
When I access the admin panel
|
|
478
|
+
Then I should be able to view all user accounts
|
|
479
|
+
And I should be able to modify user permissions
|
|
480
|
+
And I should be able to access system settings
|
|
481
|
+
And all admin actions should be logged with timestamps
|
|
482
|
+
And I should be able to generate compliance reports
|
|
483
|
+
|
|
484
|
+
Scenario: Regular user permission restrictions
|
|
485
|
+
Given I am logged in as a regular user
|
|
486
|
+
When I attempt to access admin-only features
|
|
487
|
+
Then I should see "Access Denied" message
|
|
488
|
+
And I should be redirected to my authorized dashboard
|
|
489
|
+
And the unauthorized access attempt should be logged
|
|
490
|
+
And I should not see admin navigation options
|
|
491
|
+
And API calls to admin endpoints should return 403 Forbidden
|
|
492
|
+
|
|
493
|
+
Scenario: Permission escalation prevention
|
|
494
|
+
Given I am a regular user
|
|
495
|
+
When I attempt to modify my own permissions via API
|
|
496
|
+
Then the request should be rejected with 403 Forbidden
|
|
497
|
+
And the attempt should be logged as a security event
|
|
498
|
+
And my account should not be compromised
|
|
499
|
+
And security team should be notified of the attempt
|
|
500
|
+
```
|
|
501
|
+
|
|
502
|
+
---
|
|
503
|
+
|
|
504
|
+
## โก 8. Performance & Scalability Criteria Patterns
|
|
505
|
+
|
|
506
|
+
### 8.1 Page Load Performance
|
|
507
|
+
**Pattern: Core Web Vitals Compliance**
|
|
508
|
+
```gherkin
|
|
509
|
+
Scenario: First Contentful Paint performance
|
|
510
|
+
Given I am accessing any page on the platform
|
|
511
|
+
When the page starts loading
|
|
512
|
+
Then First Contentful Paint should occur within 1.5 seconds
|
|
513
|
+
And the measurement should be consistent across multiple loads
|
|
514
|
+
And performance should meet requirements on 3G connections
|
|
515
|
+
And lighthouse score for FCP should be 90+
|
|
516
|
+
|
|
517
|
+
Scenario: Largest Contentful Paint optimization
|
|
518
|
+
Given I am loading a content-heavy page
|
|
519
|
+
When the page renders
|
|
520
|
+
Then Largest Contentful Paint should occur within 2.5 seconds
|
|
521
|
+
And images should be optimized and properly sized
|
|
522
|
+
And critical resources should be prioritized
|
|
523
|
+
And lazy loading should be implemented for below-fold content
|
|
524
|
+
|
|
525
|
+
Scenario: Cumulative Layout Shift minimization
|
|
526
|
+
Given I am loading any page
|
|
527
|
+
When content renders and loads
|
|
528
|
+
Then Cumulative Layout Shift should be less than 0.1
|
|
529
|
+
And elements should not shift unexpectedly
|
|
530
|
+
And space should be reserved for images and ads
|
|
531
|
+
And font loading should not cause layout shifts
|
|
532
|
+
```
|
|
533
|
+
|
|
534
|
+
### 8.2 API Performance
|
|
535
|
+
**Pattern: Response Time Requirements**
|
|
536
|
+
```gherkin
|
|
537
|
+
Scenario: API response time under normal load
|
|
538
|
+
Given the system is under normal operating conditions
|
|
539
|
+
When I make an API call to any endpoint
|
|
540
|
+
Then the response should be returned within 500ms for 95% of requests
|
|
541
|
+
And no response should take longer than 2 seconds
|
|
542
|
+
And error responses should be returned within 100ms
|
|
543
|
+
And response times should be consistent across different endpoints
|
|
544
|
+
|
|
545
|
+
Scenario: API performance under high load
|
|
546
|
+
Given the system is experiencing high traffic (1000 concurrent users)
|
|
547
|
+
When I make API calls
|
|
548
|
+
Then response times should remain under 1 second for 90% of requests
|
|
549
|
+
And the system should not return 5xx errors due to load
|
|
550
|
+
And rate limiting should prevent system overload
|
|
551
|
+
And degraded performance should be communicated to users
|
|
552
|
+
|
|
553
|
+
Scenario: Database query optimization
|
|
554
|
+
Given I am performing data-intensive operations
|
|
555
|
+
When I query large datasets (>1 million records)
|
|
556
|
+
Then queries should complete within 3 seconds
|
|
557
|
+
And database connections should be properly managed
|
|
558
|
+
And query results should be paginated appropriately
|
|
559
|
+
And indexes should be utilized effectively
|
|
560
|
+
```
|
|
561
|
+
|
|
562
|
+
---
|
|
563
|
+
|
|
564
|
+
## ๐งช 9. Testing & Quality Assurance Integration
|
|
565
|
+
|
|
566
|
+
### 9.1 Automated Testing Requirements
|
|
567
|
+
**Pattern: Test Coverage Standards**
|
|
568
|
+
```gherkin
|
|
569
|
+
Scenario: Unit test coverage validation
|
|
570
|
+
Given I have implemented a new feature
|
|
571
|
+
When the automated test suite runs
|
|
572
|
+
Then unit test coverage should be at least 80%
|
|
573
|
+
And all critical paths should have 100% coverage
|
|
574
|
+
And edge cases should be included in test scenarios
|
|
575
|
+
And tests should run in under 5 minutes
|
|
576
|
+
And test results should be clearly reported
|
|
577
|
+
|
|
578
|
+
Scenario: Integration test validation
|
|
579
|
+
Given I have modified API endpoints
|
|
580
|
+
When integration tests execute
|
|
581
|
+
Then all API contracts should be validated
|
|
582
|
+
And database interactions should be tested
|
|
583
|
+
And third-party integrations should be mocked appropriately
|
|
584
|
+
And test data should be properly isolated
|
|
585
|
+
And tests should clean up after execution
|
|
586
|
+
|
|
587
|
+
Scenario: End-to-end test automation
|
|
588
|
+
Given I have completed a user story
|
|
589
|
+
When E2E tests run
|
|
590
|
+
Then critical user journeys should be automated
|
|
591
|
+
And tests should run in multiple browsers
|
|
592
|
+
And mobile responsiveness should be validated
|
|
593
|
+
And accessibility requirements should be checked
|
|
594
|
+
And performance benchmarks should be verified
|
|
595
|
+
```
|
|
596
|
+
|
|
597
|
+
### 9.2 Quality Gates & Acceptance
|
|
598
|
+
**Pattern: Definition of Done Validation**
|
|
599
|
+
```gherkin
|
|
600
|
+
Scenario: Code quality gate validation
|
|
601
|
+
Given I have submitted code for review
|
|
602
|
+
When the automated quality checks run
|
|
603
|
+
Then code coverage should meet minimum threshold (80%)
|
|
604
|
+
And static analysis should pass without critical issues
|
|
605
|
+
And security scanning should show no high-risk vulnerabilities
|
|
606
|
+
And code style should conform to project standards
|
|
607
|
+
And documentation should be updated where required
|
|
608
|
+
|
|
609
|
+
Scenario: User acceptance testing
|
|
610
|
+
Given a feature has passed all automated tests
|
|
611
|
+
When the product owner reviews the implementation
|
|
612
|
+
Then all acceptance criteria should be demonstrably met
|
|
613
|
+
And the feature should work as described in user stories
|
|
614
|
+
And edge cases should be handled appropriately
|
|
615
|
+
And the user experience should be intuitive
|
|
616
|
+
And performance should meet specified requirements
|
|
617
|
+
|
|
618
|
+
Scenario: Production readiness checklist
|
|
619
|
+
Given a feature is ready for deployment
|
|
620
|
+
When the production readiness review occurs
|
|
621
|
+
Then monitoring and alerting should be configured
|
|
622
|
+
And rollback procedures should be documented
|
|
623
|
+
And database migrations should be tested
|
|
624
|
+
And security review should be completed
|
|
625
|
+
And performance impact should be assessed
|
|
626
|
+
```
|
|
627
|
+
|
|
628
|
+
---
|
|
629
|
+
|
|
630
|
+
## ๐ 10. Criteria Quality Metrics & Validation
|
|
631
|
+
|
|
632
|
+
### 10.1 Acceptance Criteria Quality Assessment
|
|
633
|
+
**Quality Metrics Framework:**
|
|
634
|
+
| Metric | Target | Measurement Method | Improvement Actions |
|
|
635
|
+
|--------|--------|--------------------|---------------------|
|
|
636
|
+
| **Testability Score** | 95% | % of criteria that can be automated | Add measurable outcomes |
|
|
637
|
+
| **Completeness Score** | 90% | % of user story aspects covered | Review edge cases |
|
|
638
|
+
| **Clarity Score** | 85% | % understood without clarification | Simplify language |
|
|
639
|
+
| **Coverage Score** | 100% | % of acceptance criteria tested | Add missing test cases |
|
|
640
|
+
|
|
641
|
+
### 10.2 Continuous Improvement Process
|
|
642
|
+
**Monthly Criteria Review:**
|
|
643
|
+
- Analyze which criteria caused most clarification requests
|
|
644
|
+
- Identify patterns in rejected stories due to unclear criteria
|
|
645
|
+
- Update templates based on team feedback
|
|
646
|
+
- Validate criteria against actual implementation complexity
|
|
647
|
+
- Measure correlation between criteria quality and story success
|
|
648
|
+
|
|
649
|
+
**Criteria Enhancement Workflow:**
|
|
650
|
+
1. **Collection:** Gather feedback from developers, testers, and product owners
|
|
651
|
+
2. **Analysis:** Identify common issues and improvement opportunities
|
|
652
|
+
3. **Templates:** Update criteria patterns and templates
|
|
653
|
+
4. **Training:** Share best practices with the team
|
|
654
|
+
5. **Validation:** Measure improvement in story success rates
|
|
655
|
+
|
|
656
|
+
### 10.3 Automated Criteria Validation
|
|
657
|
+
**Criteria Checking Tools:**
|
|
658
|
+
```yaml
|
|
659
|
+
# Example criteria validation rules
|
|
660
|
+
criteria_validation:
|
|
661
|
+
required_sections:
|
|
662
|
+
- given_statements: minimum 1
|
|
663
|
+
- when_statements: minimum 1
|
|
664
|
+
- then_statements: minimum 1
|
|
665
|
+
|
|
666
|
+
quality_checks:
|
|
667
|
+
- measurable_outcomes: true
|
|
668
|
+
- specific_actions: true
|
|
669
|
+
- clear_context: true
|
|
670
|
+
- edge_cases_covered: true
|
|
671
|
+
|
|
672
|
+
performance_requirements:
|
|
673
|
+
- response_time_specified: true
|
|
674
|
+
- load_requirements_defined: true
|
|
675
|
+
- error_handling_included: true
|
|
676
|
+
```
|
|
677
|
+
|
|
678
|
+
---
|
|
679
|
+
|
|
680
|
+
**โ
Acceptance Criteria Success Metrics:**
|
|
681
|
+
- Criteria testability: 95%+
|
|
682
|
+
- Story acceptance rate: 90%+
|
|
683
|
+
- Clarification requests: <5% per story
|
|
684
|
+
- Automated test coverage: 85%+
|
|
685
|
+
- Team satisfaction with criteria quality: 8.5+/10
|
|
686
|
+
|
|
687
|
+
**Next Steps:** Use acceptance criteria to drive comprehensive testing strategy (17_test_plan.md) and establish quality gates (12_qa_gate.md).
|