Software Engineering Feature Specification and Planning Best Practices

Comprehensive feature specification and planning guide for software engineers, product managers, and technical leads. Contains 42 rules across 8 categories, prioritized by impact to prevent scope creep and ensure project success.

When to Apply

Reference these guidelines when:

• Writing PRDs or feature specifications
• Defining requirements or user stories
• Managing scope and preventing scope creep
• Prioritizing features and backlog items
• Handling change requests
• Aligning stakeholders on project goals

Rule Categories by Priority

Priority	Category	Impact	Prefix
1	Scope Definition	CRITICAL	scope-
2	Requirements Clarity	CRITICAL	req-
3	Prioritization Frameworks	HIGH	prio-
4	Acceptance Criteria	HIGH	accept-
5	Stakeholder Alignment	MEDIUM-HIGH	stake-
6	Technical Specification	MEDIUM	tech-
7	Change Management	MEDIUM	change-
8	Documentation Standards	LOW	doc-

Quick Reference

1. Scope Definition (CRITICAL)

• scope-define-boundaries - Define explicit scope boundaries
• scope-document-assumptions - Document all assumptions explicitly
• scope-work-breakdown - Break scope into measurable work items
• scope-define-mvp - Define MVP before full feature set
• scope-stakeholder-signoff - Get stakeholder signoff on scope

2. Requirements Clarity (CRITICAL)

• req-specific-measurable - Write specific, measurable requirements
• req-user-stories - Structure requirements as user stories
• req-avoid-solution-language - Avoid solution-specific language
• req-functional-nonfunctional - Separate functional and non-functional
• req-consistent-terminology - Use consistent terminology
• req-traceability - Maintain requirements traceability

3. Prioritization Frameworks (HIGH)

• prio-moscow-method - Use MoSCoW prioritization method
• prio-rice-scoring - Apply RICE scoring for objectivity
• prio-value-vs-effort - Map value vs effort explicitly
• prio-dependencies-first - Identify and order dependencies
• prio-kano-model - Apply Kano model for feature classification

4. Acceptance Criteria (HIGH)

• accept-given-when-then - Use Given-When-Then format
• accept-testable-criteria - Write testable acceptance criteria
• accept-edge-cases - Include edge cases in acceptance
• accept-definition-of-done - Define clear definition of done
• accept-avoid-over-specification - Avoid over-specification

5. Stakeholder Alignment (MEDIUM-HIGH)

• stake-identify-stakeholders - Identify all stakeholders early
• stake-early-feedback - Gather feedback early and often
• stake-conflict-resolution - Resolve conflicts explicitly
• stake-communication-plan - Establish communication cadence
• stake-success-metrics - Align on success metrics

6. Technical Specification (MEDIUM)

• tech-system-context - Document system context and dependencies
• tech-api-contracts - Define API contracts before implementation
• tech-data-model - Specify data models and schema changes
• tech-error-handling - Plan error handling and recovery
• tech-performance-requirements - Specify performance requirements
• tech-security-considerations - Document security considerations

7. Change Management (MEDIUM)

• change-formal-process - Use formal change request process
• change-impact-assessment - Assess full impact before approval
• change-version-tracking - Version all specification documents
• change-scope-freeze - Implement scope freeze periods
• change-defer-log - Maintain deferred items log

8. Documentation Standards (LOW)

• doc-single-source - Maintain single source of truth
• doc-consistent-templates - Use consistent document templates
• doc-decision-records - Document key decisions with context
• doc-accessible-format - Keep documentation accessible
• doc-glossary-terms - Define project terminology