選択できるのは25トピックまでです。 トピックは、先頭が英数字で、英数字とダッシュ('-')を使用した35文字以内のものにしてください。

step-10-nonfunctional.md 8.8KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230
  1. # Step 10: Non-Functional Requirements
  2. **Progress: Step 10 of 12** - Next: Polish Document
  3. ## MANDATORY EXECUTION RULES (READ FIRST):
  4. - 🛑 NEVER generate content without user input
  5. - 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
  6. - 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
  7. - ✅ ALWAYS treat this as collaborative discovery between PM peers
  8. - 📋 YOU ARE A FACILITATOR, not a content generator
  9. - 💬 FOCUS on quality attributes that matter for THIS specific product
  10. - 🎯 SELECTIVE: Only document NFRs that actually apply to the product
  11. - ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
  12. - ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
  13. ## EXECUTION PROTOCOLS:
  14. - 🎯 Show your analysis before taking any action
  15. - ⚠️ Present A/P/C menu after generating NFR content
  16. - 💾 ONLY save when user chooses C (Continue)
  17. - 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
  18. - 🚫 FORBIDDEN to load next step until C is selected
  19. ## CONTEXT BOUNDARIES:
  20. - Current document and frontmatter from previous steps are available
  21. - Functional requirements already defined and will inform NFRs
  22. - Domain and project-type context will guide which NFRs matter
  23. - Focus on specific, measurable quality criteria
  24. ## YOUR TASK:
  25. Define non-functional requirements that specify quality attributes for the product, focusing only on what matters for THIS specific product.
  26. ## NON-FUNCTIONAL REQUIREMENTS SEQUENCE:
  27. ### 1. Explain NFR Purpose and Scope
  28. Start by clarifying what NFRs are and why we're selective:
  29. **NFR Purpose:**
  30. NFRs define HOW WELL the system must perform, not WHAT it must do. They specify quality attributes like performance, security, scalability, etc.
  31. **Selective Approach:**
  32. We only document NFRs that matter for THIS product. If a category doesn't apply, we skip it entirely. This prevents requirement bloat and focuses on what's actually important.
  33. ### 2. Assess Product Context for NFR Relevance
  34. Evaluate which NFR categories matter based on product context:
  35. **Quick Assessment Questions:**
  36. - **Performance**: Is there user-facing impact of speed?
  37. - **Security**: Are we handling sensitive data or payments?
  38. - **Scalability**: Do we expect rapid user growth?
  39. - **Accessibility**: Are we serving broad public audiences?
  40. - **Integration**: Do we need to connect with other systems?
  41. - **Reliability**: Would downtime cause significant problems?
  42. ### 3. Explore Relevant NFR Categories
  43. For each relevant category, conduct targeted discovery:
  44. #### Performance NFRs (If relevant):
  45. Explore performance requirements:
  46. - What parts of the system need to be fast for users to be successful?
  47. - Are there specific response time expectations?
  48. - What happens if performance is slower than expected?
  49. - Are there concurrent user scenarios we need to support?
  50. #### Security NFRs (If relevant):
  51. Explore security requirements:
  52. - What data needs to be protected?
  53. - Who should have access to what?
  54. - What are the security risks we need to mitigate?
  55. - Are there compliance requirements (GDPR, HIPAA, PCI-DSS)?
  56. #### Scalability NFRs (If relevant):
  57. Explore scalability requirements:
  58. - How many users do we expect initially? Long-term?
  59. - Are there seasonal or event-based traffic spikes?
  60. - What happens if we exceed our capacity?
  61. - What growth scenarios should we plan for?
  62. #### Accessibility NFRs (If relevant):
  63. Explore accessibility requirements:
  64. - Are we serving users with visual, hearing, or motor impairments?
  65. - Are there legal accessibility requirements (WCAG, Section 508)?
  66. - What accessibility features are most important for our users?
  67. #### Integration NFRs (If relevant):
  68. Explore integration requirements:
  69. - What external systems do we need to connect with?
  70. - Are there APIs or data formats we must support?
  71. - How reliable do these integrations need to be?
  72. ### 4. Make NFRs Specific and Measurable
  73. For each relevant NFR category, ensure criteria are testable:
  74. **From Vague to Specific:**
  75. - NOT: "The system should be fast" → "User actions complete within 2 seconds"
  76. - NOT: "The system should be secure" → "All data is encrypted at rest and in transit"
  77. - NOT: "The system should scale" → "System supports 10x user growth with <10% performance degradation"
  78. ### 5. Generate NFR Content (Only Relevant Categories)
  79. Prepare the content to append to the document:
  80. #### Content Structure (Dynamic based on relevance):
  81. When saving to document, append these Level 2 and Level 3 sections (only include sections that are relevant):
  82. ```markdown
  83. ## Non-Functional Requirements
  84. ### Performance
  85. [Performance requirements based on conversation - only include if relevant]
  86. ### Security
  87. [Security requirements based on conversation - only include if relevant]
  88. ### Scalability
  89. [Scalability requirements based on conversation - only include if relevant]
  90. ### Accessibility
  91. [Accessibility requirements based on conversation - only include if relevant]
  92. ### Integration
  93. [Integration requirements based on conversation - only include if relevant]
  94. ```
  95. ### 6. Present MENU OPTIONS
  96. Present the non-functional requirements for review, then display menu:
  97. - Show defined NFRs (using structure from step 5)
  98. - Note that only relevant categories were included
  99. - Emphasize NFRs specify how well the system needs to perform
  100. - Ask if they'd like to refine further, get other perspectives, or proceed
  101. - Present menu options naturally as part of conversation
  102. Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Polish Document (Step 11 of 12)"
  103. #### Menu Handling Logic:
  104. - IF A: Invoke the `bmad-advanced-elicitation` skill with the current NFR content, process the enhanced quality attribute insights that come back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
  105. - IF P: Invoke the `bmad-party-mode` skill with the current NFR list, process the collaborative technical validation and additions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
  106. - IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-11-polish.md
  107. - IF Any other: help user respond, then redisplay menu
  108. #### EXECUTION RULES:
  109. - ALWAYS halt and wait for user input after presenting menu
  110. - ONLY proceed to next step when user selects 'C'
  111. - After other menu items execution, return to this menu
  112. ## APPEND TO DOCUMENT:
  113. When user selects 'C', append the content directly to the document using the structure from step 5.
  114. ## SUCCESS METRICS:
  115. ✅ Only relevant NFR categories documented (no requirement bloat)
  116. ✅ Each NFR is specific and measurable
  117. ✅ NFRs connected to actual user needs and business context
  118. ✅ Vague requirements converted to testable criteria
  119. ✅ Domain-specific compliance requirements included if relevant
  120. ✅ A/P/C menu presented and handled correctly
  121. ✅ Content properly appended to document when C selected
  122. ## FAILURE MODES:
  123. ❌ Documenting NFR categories that don't apply to the product
  124. ❌ Leaving requirements vague and unmeasurable
  125. ❌ Not connecting NFRs to actual user or business needs
  126. ❌ Missing domain-specific compliance requirements
  127. ❌ Creating overly prescriptive technical requirements
  128. ❌ Not presenting A/P/C menu after content generation
  129. ❌ Appending content without user selecting 'C'
  130. ❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
  131. ❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
  132. ❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
  133. ## NFR CATEGORY GUIDANCE:
  134. **Include Performance When:**
  135. - User-facing response times impact success
  136. - Real-time interactions are critical
  137. - Performance is a competitive differentiator
  138. **Include Security When:**
  139. - Handling sensitive user data
  140. - Processing payments or financial information
  141. - Subject to compliance regulations
  142. - Protecting intellectual property
  143. **Include Scalability When:**
  144. - Expecting rapid user growth
  145. - Handling variable traffic patterns
  146. - Supporting enterprise-scale usage
  147. - Planning for market expansion
  148. **Include Accessibility When:**
  149. - Serving broad public audiences
  150. - Subject to accessibility regulations
  151. - Targeting users with disabilities
  152. - B2B customers with accessibility requirements
  153. ## NEXT STEP:
  154. After user selects 'C' and content is saved to document, load ./step-11-polish.md to finalize the PRD and complete the workflow.
  155. Remember: Do NOT proceed to step-11 until user explicitly selects 'C' from the A/P/C menu and content is saved!