From problem-based-srs
Establishes structured business context: project identity, principles, stakeholders, domain boundaries, success criteria. Step 0 of Problem-Based SRS before customer problem discovery.
npx claudepluginhub rafaelgorski/problem-based-srsThis skill uses the workspace's default tool permissions.
> **Step 0** of the Problem-Based SRS methodology
Conducts structured business analysis for projects: problem/stakeholder analysis, as-is/to-be gap analysis, user personas, scope definition. Creates BA documents and manages GitHub issues/PRs/branches.
Orchestrates Problem-Based SRS methodology to derive traceable functional requirements from business problems via 6 structured steps and sub-skills.
Gathers and documents business requirements, maps AS-IS/TO-BE processes, performs gap analysis, writes BRDs, and manages stakeholders for software projects.
Share bugs, ideas, or general feedback.
Step 0 of the Problem-Based SRS methodology Domain: CONTEXT — Establishes the foundation for problem discovery
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.
Establish a structured business context before identifying Customer Problems. The Business Context captures the foundational understanding of the project: who is involved, what principles govern decisions, what boundaries exist, and how success is measured. This ensures that Step 1 (Customer Problems) starts from a shared, well-defined understanding rather than ad-hoc descriptions.
Inspired by: The project constitution concept — establishing non-negotiable principles and governance before specification work begins.
| Aspect | Boundary |
|---|---|
| This skill does | Capture project identity, business principles, stakeholders, domain boundaries, constraints, and success criteria |
| This skill does NOT | Identify problems, define solutions, or derive requirements |
| Input from | Stakeholder conversations, project briefs, existing documentation, domain knowledge |
| Output to | Step 1: Customer Problems (customer-problems skill) |
Use when starting from scratch — interview stakeholders or analyze existing documentation to build the business context.
Use when business context already exists and needs validation, expansion, or amendment.
Collect and structure the foundational business context for a project.
Work through the following sections systematically. For each section, either:
Capture the essential identity of the project:
| Field | Description | Example |
|---|---|---|
| Project Name | Official name | "InventoryPro" |
| Business Domain | Industry/area | "Warehouse logistics" |
| Purpose Statement | One-sentence WHY | "Eliminate $50k/month inventory losses" |
| Inception Date | When the project started or is starting | "2026-01" |
Define the non-negotiable rules and values that govern this project. Each principle SHOULD be:
Classify each principle:
| Class | Description | Example |
|---|---|---|
| Mandatory | Non-negotiable; violation is unacceptable | "All data must be encrypted at rest and in transit" |
| Guiding | Strongly preferred; exceptions need justification | "Prefer open-source technologies over proprietary" |
| Aspirational | Desired direction; not yet enforced | "Achieve zero-downtime deployments" |
Typical principle categories:
Identify all parties involved and their relationship to the project:
| Role | Name/Group | Interest | Influence |
|---|---|---|---|
| Sponsor | Who funds/approves | Business goals | Decision authority |
| User | Who uses the system | Usability, efficiency | Usage feedback |
| Customer | Who benefits from outcomes | Value delivery | Requirements input |
| Regulator | Who sets compliance rules | Legal compliance | Constraints |
| Development | Who builds the system | Feasibility, clarity | Technical input |
Document the as-is state:
Define the scope of the project:
Document limitations that shape the solution space:
| Category | Constraint | Impact |
|---|---|---|
| Technical | Platform, language, infrastructure | Limits technology choices |
| Organizational | Team size, skills, availability | Limits delivery capacity |
| Regulatory | Laws, standards, certifications | Mandates specific behaviors |
| Financial | Budget, cost limits | Limits scope and quality |
| Timeline | Deadlines, milestones | Limits what can be delivered when |
Define measurable outcomes that indicate project success:
# Business Context: [Project Name]
**Version:** [BC_VERSION] | **Created:** [CREATION_DATE] | **Last Updated:** [LAST_UPDATED_DATE]
## Project Identity
| Field | Value |
|-------|-------|
| **Project Name** | [Name] |
| **Business Domain** | [Domain] |
| **Purpose** | [One-sentence purpose statement] |
| **Inception Date** | [Date] |
## Business Principles
### BP-001: [Principle Name]
**Statement:** [Declarative principle statement]
**Class:** [Mandatory | Guiding | Aspirational]
**Rationale:** [Why this principle matters]
### BP-002: [Principle Name]
**Statement:** [Declarative principle statement]
**Class:** [Mandatory | Guiding | Aspirational]
**Rationale:** [Why this principle matters]
<!-- Add more principles as needed -->
## Stakeholders
| Role | Name/Group | Interest | Influence |
|------|------------|----------|-----------|
| [Role] | [Who] | [What they care about] | [Decision/Input/Informed] |
## Current Situation
### Current Process
[Description of how things work today]
### Pain Points
- [Pain point 1]
- [Pain point 2]
### Existing Systems
- [System 1 — purpose]
- [System 2 — purpose]
### What Works Well
- [Element to preserve 1]
- [Element to preserve 2]
## Domain Boundaries
### In Scope
- [Scope item 1]
- [Scope item 2]
### Out of Scope
- [Exclusion 1]
- [Exclusion 2]
### Adjacent Systems
- [System — interaction type]
### Future Considerations
- [Deferred item 1]
## Constraints
| Category | Constraint | Impact |
|----------|-----------|--------|
| [Category] | [Constraint description] | [Impact on project] |
## Success Criteria
| ID | Criterion | Measure | Target |
|----|-----------|---------|--------|
| SC-01 | [What success looks like] | [How to measure] | [Target value] |
| SC-02 | [What success looks like] | [How to measure] | [Target value] |
Review and update an existing Business Context document.
00-business-context.mdWhen updating, prepend a change summary:
<!-- Business Context Amendment Report
Version: [old] → [new]
Changes:
- [Change 1]
- [Change 2]
Impact on existing artifacts:
- [Impact on CPs if any]
- [Impact on CNs if any]
-->
# Business Context: InventoryPro
**Version:** 1.0 | **Created:** 2026-01-15 | **Last Updated:** 2026-01-15
## Project Identity
| Field | Value |
|-------|-------|
| **Project Name** | InventoryPro |
| **Business Domain** | Warehouse logistics |
| **Purpose** | Eliminate $50k/month inventory losses caused by manual tracking errors |
| **Inception Date** | 2026-01 |
## Business Principles
### BP-001: Data Accuracy First
**Statement:** Inventory data must reflect physical reality within 0.1% tolerance at all times.
**Class:** Mandatory
**Rationale:** Financial losses are directly caused by data inaccuracy; this is non-negotiable.
### BP-002: Mobile-First Operations
**Statement:** All warehouse floor operations must be performable from mobile devices.
**Class:** Guiding
**Rationale:** Staff work on the warehouse floor, not at desks. Desktop-only solutions fail adoption.
### BP-003: Open Standards
**Statement:** Prefer open data formats and standard APIs for integration.
**Class:** Aspirational
**Rationale:** Reduces vendor lock-in and enables future integrations with supply chain partners.
## Stakeholders
| Role | Name/Group | Interest | Influence |
|------|------------|----------|-----------|
| Sponsor | VP Operations | Reduce inventory losses | Decision |
| User | Warehouse Staff (50) | Easy scanning and lookup | Input |
| Customer | Supply Chain Partners | Accurate availability data | Informed |
| Regulator | Industry Standards Body | Compliance with tracking regulations | Constraints |
| Development | Internal IT Team (8) | Feasibility and maintenance | Technical Input |
## Current Situation
### Current Process
Manual spreadsheet tracking with weekly physical counts. Staff update spreadsheets at end of shift. Discrepancies found during monthly audits.
### Pain Points
- 3-5 day lag between physical changes and spreadsheet updates
- No real-time visibility into stock levels
- Monthly audits reveal $50k average discrepancy
### Existing Systems
- Excel spreadsheets — inventory tracking (primary)
- SAP ERP — financial reporting (receives monthly data)
- Barcode printers — label generation
### What Works Well
- Barcode labeling system is established and reliable
- Staff are familiar with scanning workflows
- SAP integration for financials is stable
## Domain Boundaries
### In Scope
- Real-time inventory tracking
- Barcode scanning for receiving and shipping
- Stock level alerts and reporting
- Integration with existing SAP ERP
### Out of Scope
- Supply chain management (upstream)
- Customer-facing order portal
- Warehouse layout optimization
### Adjacent Systems
- SAP ERP — receives inventory data
- Supplier portals — send purchase orders (manual today)
### Future Considerations
- Automated reorder triggers (Phase 2)
- RFID tracking pilot (Phase 3)
## Constraints
| Category | Constraint | Impact |
|----------|-----------|--------|
| Technical | Must integrate with SAP ERP via existing APIs | Limits data format choices |
| Organizational | IT team of 8, 3 available for project | Limits parallel development |
| Financial | $200k budget for Phase 1 | Limits scope and vendor options |
| Timeline | Must go live by Q3 2026 | 6-month delivery window |
| Regulatory | Industry tracking compliance required | Mandates audit trail features |
## Success Criteria
| ID | Criterion | Measure | Target |
|----|-----------|---------|--------|
| SC-01 | Inventory accuracy | Monthly audit discrepancy | < $5k/month (from $50k) |
| SC-02 | Data freshness | Time between physical change and system update | < 5 minutes |
| SC-03 | Staff adoption | Active daily users | > 90% of warehouse staff |
| SC-04 | Process efficiency | Time spent on manual data entry | Reduce by 80% |
Ensure the Business Context:
| ❌ Wrong | ✅ Correct |
|---|---|
| "We need a React web app" | "Operations must be accessible from warehouse floor devices" |
| "Use microservices architecture" | "System must support independent team development and deployment" |
| "Success = deploy to production" | "Success = reduce inventory discrepancy from $50k to $5k/month" |
| "All stakeholders" (vague) | "VP Operations (sponsor), 50 warehouse staff (users), IT team of 8" |
| "Should be fast" | "System must update inventory within 5 minutes of physical change" |
Before proceeding to Step 1 (Customer Problems), verify:
When Business Context is complete, provide:
✅ Step 0 Complete: Business Context Established
📁 Saved to: [path]/00-business-context.md
Summary:
- Project: [Project Name] — [Purpose Statement]
- [N] Business Principles defined ([N] Mandatory, [N] Guiding, [N] Aspirational)
- [N] Stakeholders identified
- [N] Constraints documented
- [N] Success Criteria defined
The Business Context provides structured foundation for problem discovery.
→ Next Step: 1 - Customer Problems
→ Use skill: customer-problems
→ Input: The Business Context above (especially Current Situation and Pain Points)
Version: 1.0 Step: 0 of 5 Next: customer-problems skill