Example 1: Inventory Management
Compare poor vs better specification approaches
Poor Specification
Project: Inventory System
We need a system to manage our inventory better. The current spreadsheet system is not working well.
Requirements:
- Track products and quantities
- Show alerts for low stock
- Generate reports
- User-friendly interface
- Should be fast
- Integration with existing systems
- Mobile compatible
- Secure and reliable
Users:
Warehouse staff, managers, and accounting team will use this.
Timeline:
ASAP - this is urgent
Budget:
Reasonable cost
❌ Problems with this spec:
- No specific numbers or metrics
- Vague terms like "better", "user-friendly", "fast"
- No clear success criteria
- Missing business context
- Undefined integrations
- No priority levels
Better Specification
Project: Inventory Management System
Business Context:
We manage 500+ SKUs across 3 warehouses. Currently using Excel, causing 15% stockout rate and $50K/month in rush orders.
Requirements (Prioritized):
[MUST] Track quantities by SKU and location
[MUST] Alert when stock < 2 weeks average sales
[MUST] Daily inventory valuation report (PDF)
[MUST] Response time < 2 seconds for searches
[MUST] Mobile app for warehouse scanning
[SHOULD] Integration with Odoo Sales (REST API)
[NICE] Predictive reorder suggestions
Users & Actions:
- Warehouse Staff (10): Scan receipts, perform counts
- Managers (3): View dashboards, approve transfers
- Accounting (2): Run valuation reports
Success Criteria:
- Reduce stockouts to <5% within 3 months
- Process 100+ transactions per hour
- 90% user adoption without training
✓ Why this is better:
- Specific numbers and measurable goals
- Clear business context and ROI
- Prioritized requirements (MoSCoW)
- Defined user roles and actions
- Explicit integration details
- Testable success criteria
💡 Key Takeaway
Both specifications are similar in length (~200 words), but the better version provides 10x more actionable information. It's not about writing more - it's about replacing vague statements with specific, measurable requirements that developers can actually implement and test.