Cursor rule

1---
2alwaysApply: false
3---
4 
5# Requirements Analysis (Adaptive)
6 
7**Assume the role** of a product owner
8 
9**Adaptive Phase**: Always executes. Detail level adapts to problem complexity.
10 
11**See [depth-levels.md](../common/depth-levels.md) for adaptive depth explanation**
12 
13## Prerequisites
14- Workspace Detection must be complete
15- Reverse Engineering must be complete (if brownfield)
16 
17## Execution Steps
18 
19### Step 1: Load Reverse Engineering Context (if available)
20 
21**IF brownfield project**:
22- Load `aidlc-docs/inception/reverse-engineering/architecture.md`
23- Load `aidlc-docs/inception/reverse-engineering/component-inventory.md`
24- Load `aidlc-docs/inception/reverse-engineering/technology-stack.md`
25- Use these to understand existing system when analyzing request
26 
27### Step 2: Analyze User Request (Intent Analysis)
28 
29#### 2.1 Request Clarity
30- **Clear**: Specific, well-defined, actionable
31- **Vague**: General, ambiguous, needs clarification
32- **Incomplete**: Missing key information
33 
34#### 2.2 Request Type
35- **New Feature**: Adding new functionality
36- **Bug Fix**: Fixing existing issue
37- **Refactoring**: Improving code structure
38- **Upgrade**: Updating dependencies or frameworks
39- **Migration**: Moving to different technology
40- **Enhancement**: Improving existing feature
41- **New Project**: Starting from scratch
42 
43#### 2.3 Initial Scope Estimate
44- **Single File**: Changes to one file
45- **Single Component**: Changes to one component/package
46- **Multiple Components**: Changes across multiple components
47- **System-wide**: Changes affecting entire system
48- **Cross-system**: Changes affecting multiple systems
49 
50#### 2.4 Initial Complexity Estimate
51- **Trivial**: Simple, straightforward change
52- **Simple**: Clear implementation path
53- **Moderate**: Some complexity, multiple considerations
54- **Complex**: Significant complexity, many considerations
55 
56### Step 3: Determine Requirements Depth
57 
58**Based on request analysis, determine depth:**
59 
60**Minimal Depth** - Use when:
61- Request is clear and simple
62- No detailed requirements needed
63- Just document the basic understanding
64 
65**Standard Depth** - Use when:
66- Request needs clarification
67- Functional and non-functional requirements needed
68- Normal complexity
69 
70**Comprehensive Depth** - Use when:
71- Complex project with multiple stakeholders
72- High risk or critical system
73- Detailed requirements with traceability needed
74 
75### Step 4: Assess Current Requirements
76 
77Analyze whatever the user has provided:
78   - Intent statements or descriptions (already logged in audit.md)
79   - Existing requirements documents (search workspace if mentioned)
80   - Pasted content or file references
81   - Convert any non-markdown documents to markdown format 
82 
83### Step 5: Thorough Completeness Analysis
84 
85**CRITICAL**: Use comprehensive analysis to evaluate requirements completeness. Default to asking questions when there is ANY ambiguity or missing detail.
86 
87**MANDATORY**: Evaluate ALL of these areas and ask questions for ANY that are unclear:
88- **Functional Requirements**: Core features, user interactions, system behaviors
89- **Non-Functional Requirements**: Performance, security, scalability, usability
90- **User Scenarios**: Use cases, user journeys, edge cases, error scenarios
91- **Business Context**: Goals, constraints, success criteria, stakeholder needs
92- **Technical Context**: Integration points, data requirements, system boundaries
93- **Quality Attributes**: Reliability, maintainability, testability, accessibility
94 
95**When in doubt, ask questions** - incomplete requirements lead to poor implementations.
96 
97### Step 5.1: Extension Opt-In Prompts
98 
99**MANDATORY**: Scan all loaded `*.opt-in.md` files (loaded at workflow start from `extensions/` subdirectories) for an `## Opt-In Prompt` section. For each extension that declares one, include that question in the clarifying questions file created in Step 6.
100 
101After receiving answers:
1021. Record each extension's enablement status in `aidlc-docs/aidlc-state.md` under `## Extension Configuration`:
103 
104```markdown
105## Extension Configuration
106| Extension | Enabled | Decided At |
107|---|---|---|
108| [Extension Name] | [Yes/No] | Requirements Analysis |
109```
110 
1112. **Deferred Rule Loading**: For each extension the user opted IN, load the full rules file now. The rules file is derived by naming convention: strip `.opt-in.md` from the opt-in filename and append `.md` (e.g., `security-baseline.opt-in.md` → `security-baseline.md`). For extensions the user opted OUT, do NOT load the full rules file.
112 
113### Step 6: Generate Clarifying Questions (PROACTIVE APPROACH)
114   - **ALWAYS** create `aidlc-docs/inception/requirements/requirement-verification-questions.md` unless requirements are exceptionally clear and complete
115   - Ask questions about ANY missing, unclear, or ambiguous areas
116   - Focus on functional requirements, non-functional requirements, user scenarios, and business context
117   - Request user to fill in all [Answer]: tags directly in the questions document
118   - If presenting multiple-choice options for answers:
119     - Label the options as A, B, C, D etc.
120     - Ensure options are mutually exclusive and don't overlap
121     - ALWAYS include option for custom response: "X) Other (please describe after [Answer]: tag below)"
122   - Wait for user answers in the document
123   - **MANDATORY**: Analyze ALL answers for ambiguities and create follow-up questions if needed
124   - **MANDATORY**: Keep asking questions until ALL ambiguities are resolved OR user explicitly asks to proceed
125 
126### ⛔ GATE: Await User Answers
127DO NOT proceed to Step 7 until all questions in requirement-verification-questions.md are answered and validated.
128Present the question file to the user and STOP.
129 
130### Step 7: Generate Requirements Document
131   - **PREREQUISITE**: Step 6 gate must be passed — all answers received and analyzed
132   - Create `aidlc-docs/inception/requirements/requirements.md`
133   - Include intent analysis summary at the top:
134     - User request
135     - Request type
136     - Scope estimate
137     - Complexity estimate
138   - Include both functional and non-functional requirements
139   - Incorporate user's answers to clarifying questions
140   - Provide brief summary of key requirements
141 
142### Step 8: Update State Tracking
143 
144Update `aidlc-docs/aidlc-state.md`:
145 
146```markdown
147## Stage Progress
148### 🔵 INCEPTION PHASE
149- [x] Workspace Detection
150- [x] Reverse Engineering (if applicable)
151- [x] Requirements Analysis
152```
153 
154### Step 9: Log and Proceed
155   - Log approval prompt with timestamp in `aidlc-docs/audit.md`
156   - Present completion message in this structure:
157     1. **Completion Announcement** (mandatory): Always start with this:
158 
159```markdown
160# 🔍 Requirements Analysis Complete
161```
162 
163     2. **AI Summary** (optional): Provide structured bullet-point summary of requirements
164        - Format: "Requirements analysis has identified [project type/complexity]:"
165        - List key functional requirements (bullet points)
166        - List key non-functional requirements (bullet points)
167        - Mention architectural considerations or technical decisions if relevant
168        - DO NOT include workflow instructions ("please review", "let me know", "proceed to next phase", "before we proceed")
169        - Keep factual and content-focused
170     3. **Formatted Workflow Message** (mandatory): Always end with this exact format:
171 
172```markdown
173> **📋 <u>**REVIEW REQUIRED:**</u>**  
174> Please examine the requirements document at: `aidlc-docs/inception/requirements/requirements.md`
175 
176 
177 
178> **🚀 <u>**WHAT'S NEXT?**</u>**
179>
180> **You may:**
181>
182> 🔧 **Request Changes** -  Ask for modifications to the requirements if required based on your review 
183> [IF User Stories will be skipped, add this option:]
184> 📝 **Add User Stories** - Choose to Include **User Stories** stage (currently skipped based on project simplicity)  
185> ✅ **Approve & Continue** - Approve requirements and proceed to **[User Stories/Workflow Planning]**
186 
187---
188```
189 
190**Note**: Include the "Add User Stories" option only when User Stories stage will be skipped. Replace [User Stories/Workflow Planning] with the actual next stage name.
191 
192   - Wait for explicit user approval before proceeding
193   - Record approval response with timestamp
194   - Update Requirements Analysis stage complete in aidlc-state.md
195