problem-based-srs

Problem-Based SRS

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 RFC 8174 when, and only when, they appear in all capitals, as shown here.

Stop building the wrong thing. If you've ever spent weeks building a feature only to discover it didn't solve the actual problem—or worse, solved the wrong problem—this methodology is for you.

Let your AI agent guide you through proven requirements engineering that starts with real customer problems, not feature wish lists. Works with GitHub Copilot, Claude, and other AI coding assistants to help you create software requirements that actually solve business problems and maximize the impact of your work.

⚡ What You'll Get

This methodology helps engineers:

• ✅ Discover real problems - Identify what customers actually need before writing any code
• ✅ Align your work with business impact - Every line of code traces back to a problem it solves
• ✅ Avoid wasted effort - Stop building "nice-to-have" features disguised as critical requirements
• ✅ Ship with confidence - Know exactly why each feature matters and to whom
• ✅ Reduce rework - Catch misunderstandings early, before weeks of coding are invested
• ✅ AI-guided process - Your coding assistant walks you through each step automatically

Based on peer-reviewed research by Gorski & Stadzisz, this approach systematically addresses the #1 cause of software project failures: building what stakeholders asked for instead of what they actually need.

💰 Why Engineers Love This

Before Problem-Based SRS:

• Stakeholder: "We need a reporting dashboard with 20 charts."
• You: Build it over 3 weeks.
• Result: They only use 3 charts. The real problem was slow data access, not visualization.

With Problem-Based SRS:

• Step 1: Discover the actual problem → "Managers must access sales data within 5 seconds to make decisions."
• Step 2: Design solution → Simple data API + 3 key charts.
• Result: Built in 1 week. Solves the real problem. Stakeholders happy.

ROI: Spend 30 minutes upfront with your AI agent to save weeks of building the wrong thing.

🎯 See It In Action

Here's what happens when you use this methodology:

Your input:

I need requirements for an inventory management system. Our warehouse
tracks everything in spreadsheets and loses $50k/month due to errors.

The AI guides you through:

0. Business Context (CONTEXT)

   • Project: "InventoryPro" — Warehouse logistics
   • Principle: "Inventory data must reflect physical reality within 0.1% tolerance" (Mandatory)
   • Success: "Reduce inventory discrepancy from $50k to $5k/month"

1. Customer Problems (WHY)

   • CP.01: "Warehouse must track inventory accurately otherwise $50k/month lost to errors"
   • CP.02: "Staff expects real-time inventory visibility otherwise delays in fulfillment"

2. Software Glance

   • "Web-based inventory system with barcode scanning and real-time sync"

3. Customer Needs (WHAT)

   • CN.01.1: "Warehouse needs system to track inventory with 99.9% accuracy"
   • CN.02.1: "Staff needs system to scan items and update inventory within 2 seconds"

4. Software Vision

   • "Cloud inventory platform with mobile scanning app for 50 concurrent users"

5. Functional Requirements (HOW)

   • FR.01.1.1: "System shall maintain 99.9% accuracy in inventory counts"
   • FR.02.1.1: "System shall scan barcodes and update inventory database within 2 seconds"

Result: Every requirement traces back to the $50k problem. You build only what solves the actual business need. No wasted features.

👥 Who Should Use This

Perfect for:

• Software Engineers building features from vague stakeholder requests
• Tech Leads ensuring team builds the right thing
• Product Engineers validating ideas before sprint planning
• Solution Architects aligning technical design with business problems
• Anyone using AI coding assistants who wants better requirements