problem-based-srs

Original source / Raw SKILL.md

---
name: problem-based-srs
description: Complete Problem-Based Software Requirements Specification methodology following Gorski & Stadzisz research. Use when you need to perform requirements engineering from business problems to functional requirements with full traceability.
license: MIT
metadata:
  author: rafael-gorski
  version: "1.3"
  methodology: problem-based-srs
---

# Problem-Based SRS

Orchestrate requirements engineering using the Problem-Based SRS methodology (Gorski & Stadzisz). This skill coordinates a structured process (Step 0 through Step 5) that ensures every requirement traces back to a real business problem.

## Methodology Overview

```
Stakeholder Input
       ↓
┌──────────────────┐
│ Step 0: BC       │ → Use skill: business-context
│ Business Context │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ Step 1: CP       │ → Use skill: customer-problems
│ Customer Problems│
└────────┬─────────┘
         ↓
┌──────────────────┐
│ Step 2: SG       │ → Use skill: software-glance
│ Software Glance  │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ Step 3: CN       │ → Use skill: customer-needs
│ Customer Needs   │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ Step 4: SV       │ → Use skill: software-vision
│ Software Vision  │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ Step 5: FR/NFR   │ → Use skill: functional-requirements
│ Requirements     │
└──────────────────┘
```

**Traceability Chain:** FR → CN → CP (every requirement traces back to a problem)

**Domain Mapping (WHY → WHAT → HOW):**
| Domain | Artifact | Question Answered |
|--------|----------|-------------------|
| **WHY** | Customer Problems (CP) | Why is the solution needed? (Business justification) |
| **WHAT** | Customer Needs (CN) | What outcomes must the software provide? |
| **HOW** | Functional Requirements (FR) | How will the system behave? |

## Available Skills

This orchestrator coordinates the following skills:

| Skill | Command | Purpose |
|-------|---------|---------|
| `business-context` | `/business-context` | Step 0: Establish structured business context and principles |
| `customer-problems` | `/customer-problems` | Step 1: Identify and classify customer problems |
| `software-glance` | `/software-glance` | Step 2: Create high-level solution view |
| `customer-needs` | `/customer-needs` | Step 3: Specify customer needs (outcomes) |
| `software-vision` | `/software-vision` | Step 4: Define software vision and architecture |
| `functional-requirements` | `/functional-requirements` | Step 5: Generate functional requirements |
| `zigzag-validator` | `/zigzag-validator` | Validate traceability across domains |
| `complexity-analysis` | `/complexity-analysis` | Optional: Axiomatic Design quality analysis |

## 📁 Saving Progress (CRITICAL)

**IMPORTANT:** At each step, you MUST save the produced artifacts to files. Progress is NOT automatically saved between sessions.

### First Time Setup

When starting a new project, ask the user:

```
Before we begin, where would you like to save your SRS artifacts?

Options:
1. `docs/srs/` (recommended - keeps SRS separate from code docs)
2. `requirements/` (alternative - at project root)
3. Custom path: [specify your preferred location]

All artifacts will be saved in this folder with consistent naming.
```

### Artifact File Structure

Create the following folder structure as you progress through each step:

```
[chosen-folder]/                      # e.g., docs/srs/
├── 00-business-context.md            # Step 0: Business context, principles, and constraints
├── 01-customer-problems.md           # Step 1: CPs (WHY)
├── 02-software-glance.md             # Step 2: High-level solution view
├── 03-customer-needs.md              # Step 3: CNs (WHAT)
├── 04-software-vision.md             # Step 4: Architecture and scope
├── functional-requirements/          # Step 5: Individual FR files
│   ├── _index.md                     # FR summary and traceability matrix
│   ├── FR-001.md                     # Individual FR file
│   ├── FR-002.md                     # Individual FR file
│   └── ...                           # One file per FR
├── non-functional-requirements/      # NFR files (quality attributes)
│   ├── _index.md                     # NFR summary
│   ├── NFR-001.md                    # Individual NFR file
│   └── ...                           # One file per NFR
└── traceability-matrix.md            # CP → CN → FR complete mapping
```

### Why Individual FR/NFR Files?

Each Functional Requirement and Non-Functional Requirement is saved as a **separate file** so that:

1. **Engineers can work independently** on different requirements
2. **Version control** tracks changes to individual requirements
3. **Code reviews** can focus on specific requirements
4. **Traceability** is maintained at the file level
5. **Status tracking** is easier (draft, approved, implemented, tested)

### FR File Template (FR-XXX.md)

Each FR file follows this template:

```markdown
# FR-XXX: [Brief Title]

## Requirement

**Statement:** The [System] shall [verb] [object] [constraint] [condition].

**Priority:** [Must Have | Should Have | Could Have | Won't Have]
**Status:** [Draft | Review | Approved | Implemented | Tested]

## Traceability

| Traces To | ID | Description |
|-----------|-----|-------------|
| Customer Need | CN-XXX | [Brief CN description] |
| Customer Problem | CP-XXX | [Brief CP description] |

## Acceptance Criteria

- [ ] Criterion 1 (testable)
- [ ] Criterion 2 (testable)
- [ ] Criterion 3 (testable)

## Notes

[Any additional context, assumptions, or dependencies]

<!-- ⚠️ NO CODE SNIPPETS: Do not include code examples, SQL, or implementation details here.
     Construction details belong in design/ folder (see design/implementation-notes/) -->

---
*Created: [Date]*
*Last Updated: [Date]*
*Author: [Name]*
```

### NFR File Template (NFR-XXX.md)

```markdown
# NFR-XXX: [Brief Title]

## Requirement

**Category:** [Performance | Security | Usability | Reliability | Scalability | Maintainability]
**Statement:** The [System] shall [quality attribute with measurable criteria].

**Priority:** [Must Have | Should Have | Could Have | Won't Have]
**Status:** [Draft | Review | Approved | Implemented | Tested]

## Traceability

| Traces To | ID | Description |
|-----------|-----|-------------|
| Customer Need | CN-XXX | [Brief CN description] |
| Applies To FRs | FR-XXX, FR-YYY | [Related functional requirements] |

## Acceptance Criteria

- [ ] Criterion 1 (measurable)
- [ ] Criterion 2 (measurable)

## Measurement Method

[How this NFR will be verified/tested]

<!-- ⚠️ NO CODE SNIPPETS: Do not include code examples or implementation details here.
     Technical specifications belong in design/ folder -->

---
*Created: [Date]*
*Last Updated: [Date]*
```

### Save After Each Step

**After completing each step, ALWAYS:**

1. **Create or update** the corresponding file(s)
2. **Confirm with user** that files were saved
3. **Show the file paths** for reference

Example handoff for Step 5:

```
✅ Step 5 Complete: Functional Requirements Specified

📁 Saved to: docs/srs/functional-requirements/
   ├── _index.md (summary with 8 FRs)
   ├── FR-001.md → CN-001 (User Registration)
   ├── FR-002.md → CN-001 (User Authentication)
   ├── FR-003.md → CN-002 (Data Validation)
   ├── FR-004.md → CN-002 (Error Handling)
   ├── FR-005.md → CN-003 (Report Generation)
   ├── FR-006.md → CN-003 (Export Functionality)
   ├── FR-007.md → CN-004 (Search Capability)
   └── FR-008.md → CN-004 (Filter Options)

📁 Updated: docs/srs/traceability-matrix.md

Engineers can now work on individual requirements independently.
Each FR file contains full context and acceptance criteria.
```

### Business Context File (00-business-context.md)

Create this file at the start of every project using the `business-context` skill.

The business context captures: project identity, business principles (Mandatory/Guiding/Aspirational), stakeholders with influence levels, current situation (process, pain points, existing systems), domain boundaries, constraints with impact assessment, and measurable success criteria.

> **Use the `business-context` skill** for the full template, discovery questions, and examples.

## How to Use This Skill

### Starting Fresh
When user provides business context or problem description:
1. **Ask where to save artifacts** (if not already specified)
2. **Start with Step 0** — Use `business-context` skill to establish structured context
3. **Save `00-business-context.md`** with the structured business context
4. Detect current step (see Detection Heuristics below)
5. Invoke the appropriate skill
6. Follow instructions from that skill
7. **Save output to the corresponding file(s)**
8. Guide user through the process

### Continuing Work
If user has existing artifacts (CPs, CNs, etc.):
1. **Check for existing SRS folder** (docs/srs/, requirements/, etc.)
2. **Read existing files** to understand current state
3. Identify what they have
4. Jump to appropriate step
5. Invoke that step's skill
6. Continue from there, **updating files as needed**

### Validation
At any point, use zigzag-validator skill to check consistency.

## Detection Heuristics

Determine current step by checking what artifacts exist:

| If user has... | Current Step | Use Skill | Save To |
|----------------|--------------|-----------|---------|
| Nothing / business idea only | 0 | business-context | 00-business-context.md |
| Business Context (BC) | 1 | customer-problems | 01-customer-problems.md |
| Customer Problems (CPs) | 2 | software-glance | 02-software-glance.md |
| CPs + Software Glance | 3 | customer-needs | 03-customer-needs.md |
| CPs + CNs + Software Glance | 4 | software-vision | 04-software-vision.md |
| CPs + CNs + Software Vision | 5 | functional-requirements | functional-requirements/*.md |

## The Steps (Quick Reference)

### Step 0: Business Context (BC)
**Purpose:** Establish structured business context and project principles
**Input:** Stakeholder conversations, project briefs, existing documentation
**Output:** Business context document with identity, principles, stakeholders, boundaries, constraints, success criteria
**Save to:** `00-business-context.md`
**Skill:** business-context

### Step 1: Customer Problems (CP)
**Purpose:** Identify and document business problems
**Input:** Business Context (Step 0)
**Output:** List of CPs classified as Obligation/Expectation/Hope
**Syntax:** `[Subject] [must/expects/hopes] [Object] [Penalty]`
**Save to:** `01-customer-problems.md`
**Skill:** customer-problems

### Step 2: Software Glance (SG)
**Purpose:** Create initial abstract solution view  
**Input:** Customer Problems  
**Output:** High-level system description with boundaries and components  
**Save to:** `02-software-glance.md`  
**Skill:** software-glance

### Step 3: Customer Needs (CN)
**Purpose:** Specify outcomes software must provide  
**Input:** CPs + Software Glance  
**Output:** CNs with outcome classes (Information/Control/Construction/Entertainment)  
**Syntax:** `[Subject] needs [system] to [Verb] [Object] [Condition]`  
**Save to:** `03-customer-needs.md`  
**Skill:** customer-needs

### Step 4: Software Vision (SV)
**Purpose:** Define high-level scope and positioning  
**Input:** CNs + Software Glance  
**Output:** Vision document with stakeholders, features, architecture  
**Save to:** `04-software-vision.md`  
**Skill:** software-vision

### Step 5: Functional Requirements (FR) & Non-Functional Requirements (NFR)
**Purpose:** Generate detailed requirements  
**Input:** CNs + Software Vision  
**Output:** Individual FR and NFR files with traceability  
**Syntax FR:** `The [System] shall [Verb] [Object] [Constraint] [Condition]`  
**Save to:** `functional-requirements/FR-XXX.md` and `non-functional-requirements/NFR-XXX.md`  
**Skill:** functional-requirements

## Quality Gates

**IMPORTANT:** Zigzag validation using zigzag-validator skill is **MANDATORY** after Steps 3 and 5 to verify traceability and identify gaps.

### After Step 0 (BC)
- [ ] Project identity complete (name, domain, purpose)
- [ ] Business principles defined and classified (Mandatory/Guiding/Aspirational)
- [ ] Stakeholders identified with roles and influence
- [ ] Current situation documented
- [ ] Domain boundaries defined
- [ ] Constraints documented
- [ ] Success criteria measurable
- [ ] **File saved:** `00-business-context.md`

### After Step 1 (CPs)
- [ ] All CPs use structured notation
- [ ] Classifications assigned (Obligation/Expectation/Hope)
- [ ] No solutions embedded in problem statements
- [ ] **File saved:** `01-customer-problems.md`

### After Step 2 (SG)
- [ ] System boundaries defined
- [ ] Main actors and interfaces identified
- [ ] High-level components described
- [ ] **File saved:** `02-software-glance.md`

### After Step 3 (CNs)
- [ ] Every CP has at least one CN
- [ ] All CNs use structured notation
- [ ] Outcome classes assigned
- [ ] **File saved:** `03-customer-needs.md`
- [ ] **MANDATORY: Run zigzag validation** (CP → CN mapping)

### After Step 4 (SV)
- [ ] Positioning statement clear
- [ ] All stakeholders identified
- [ ] Major features listed
- [ ] **File saved:** `04-software-vision.md`

### After Step 5 (FRs/NFRs)
- [ ] Every CN has at least one FR
- [ ] All FRs use "shall" or "should"
- [ ] Each FR saved as individual file in `functional-requirements/`
- [ ] Each NFR saved as individual file in `non-functional-requirements/`
- [ ] Index files created (`_index.md`)
- [ ] Traceability matrix complete (FR → CN → CP)
- [ ] No code snippets or programming examples in FR/NFR files
- [ ] Construction details in separate `design/` folder (not in FR/NFR files)
- [ ] **File saved:** `traceability-matrix.md`
- [ ] **MANDATORY: Run zigzag validation** (full chain verification)

## Problem-First Enforcement

If user attempts to skip to solutions, redirect:

**Detect:** User mentions specific technology, feature, or implementation before CPs exist

**Redirect:**
```
I notice you're describing a solution. Let's first understand the problem.

Before we design [mentioned solution], help me understand:
1. What is the business context? (→ business-context skill)
2. What business obligation, expectation, or hope drives this need?
3. What negative consequences occur without this?
4. Who is impacted?

→ Loading: business-context skill (if no BC exists)
→ Loading: customer-problems skill (if BC exists)
```

## Quick Syntax Reference

| Artifact | Syntax Pattern |
|----------|----------------|
| **CP** | [Subject] [must/expects/hopes] [Object] [Penalty] |
| **CN** | [Subject] needs [system] to [Verb] [Object] [Condition] |
| **FR** | The [System] shall [Verb] [Object] [Constraint] [Condition] |
| **NFR** | The [System] shall [quality attribute with measurable criteria] |

## Handoff Protocol

When completing each step:

1. **Save** outputs to the appropriate file(s)
2. **Summary** of outputs produced
3. **Validation** that gate criteria are met
4. **Next step** recommendation
5. **Required inputs** for next step

Example:
```
✅ Step 3 Complete: Customer Needs Specified

📁 Saved to: docs/srs/03-customer-needs.md

Outputs:
- CN-001: [Information] User needs system to display...
- CN-002: [Control] Admin needs system to manage...
- CN-003: [Information] Manager needs system to report...

Gate Check:
- [x] All CNs use structured notation
- [x] Outcome classes assigned
- [x] Every CP has at least one CN
- [x] File saved

→ Next: Step 4 - Software Vision
→ Loading: references/step4-software-vision.md
→ Will save to: docs/srs/04-software-vision.md
→ Input: The CNs documented above
```

## Usage Patterns

### Pattern 1: Full Process (New Project)
Start with Step 0 (Business Context) and progress through all steps sequentially.
**Remember:** Ask where to save files, establish business context first.

### Pattern 2: Jump In (Existing Artifacts)
Detect what artifacts exist, skip completed steps, resume at current step.
**Remember:** Check for existing SRS folder and read current files.

### Pattern 3: Iterative Refinement
Complete initial pass, then iterate on specific steps as understanding improves.
**Remember:** Update existing files rather than creating new ones.

### Pattern 4: Validation Only
Use zigzag-validator skill to check existing artifacts without generating new ones.

### Pattern 5: Independent Development
After Step 5, engineers can pick up individual FR files and develop independently.
Each FR file contains all context needed (traceability, acceptance criteria).

### Pattern 6: Agile/Sprint Integration
Use Problem-Based SRS iteratively within agile workflows:
- **Sprint 0:** Steps 0-2 (BC + CPs + Software Glance) for product vision
- **Sprint 1+:** Steps 3-5 for specific feature sets
- **Per Feature:** Complete CP→CN→FR chain for one feature at a time
- **Validation:** Run zigzag-validator after each sprint to ensure traceability

### Pattern 7: Minimal Viable SRS
For quick prototypes or MVPs:
1. Identify 2-3 core CPs (Obligations only)
2. Create minimal Software Glance
3. Derive essential CNs
4. Generate only critical FRs
5. Skip detailed validation until expansion

## When to Use Each Skill

- **business-context:** User is starting a new project and needs to establish structured context
- **customer-problems:** User has business context but no structured problems
- **software-glance:** User has CPs and needs high-level solution view
- **customer-needs:** User has CPs + SG and needs to specify outcomes
- **software-vision:** User has CNs and needs detailed vision document
- **functional-requirements:** User has CNs + SV and needs functional requirements
- **zigzag-validator:** User needs to check traceability or consistency
- **complexity-analysis:** User explicitly requests Axiomatic Design analysis

## Optional: Complexity Analysis

For deeper quality analysis, users can explicitly invoke the `complexity-analysis` skill for Axiomatic Design-based specification quality analysis. Use for critical systems, large specifications, or formal reviews. This is **NOT** part of the standard flow.

## Examples

For complete walkthroughs, see:
- [CRM Example](references/crm-example.md) — Business domain (Customer Relationship Management)
- [MicroER Example](references/microer-example.md) — Technical domain (Renewable Energy System)

**Use skills individually** based on current step to minimize context usage.

---

## Referenced Files

> The following files are referenced in this skill and included for context.

### references/crm-example.md

```markdown
# Example: CRM System

> **Condensed walkthrough** of Problem-Based SRS methodology  
> **Domain:** Customer Relationship Management  
> **Purpose:** Learn by example how to apply each step

---

## Business Context

The company has difficulties maintaining an effective relationship with its customers. They believe a CRM (Customer Relationship Management) software system can help reduce these difficulties.

---

## Step 1: Customer Problems (CP)

### Identified Problems

| ID | Statement | Class |
|----|-----------|-------|
| CP.1 | The company must ensure the existence of a communication channel with all customers, otherwise it risks losing customers, affecting marketing, promotions, feedback, and future sales. | Obligation |
| CP.1.1 | The company must ensure it can contact all of its customers. | Obligation |
| CP.1.2 | The company must ensure each customer is contacted regularly. | Obligation |
| CP.2 | The company must consider customer feedback statistics in planning, otherwise it creates customer dissatisfaction and loses market share. | Obligation |
| CP.3 | Customers expect the company to respond to their feedback, otherwise they become frustrated and company reputation decreases. | Expectation |
| CP.4 | The company must align sales strategies with customer behavior, otherwise it misses sales opportunities. | Obligation |
| CP.5 | The company must project sales, otherwise it loses opportunities and makes inadequate provisions. | Obligation |

### Decomposition Note

CP.1 was decomposed into CP.1.1 and CP.1.2 to clarify two distinct facets:
- **CP.1.1:** Ability to contact (having contact information)
- **CP.1.2:** Regular contact (frequency of communication)

---

## Step 2: Software Glance

### High-Level Solution

CRM software will:
- Interact with customers through a **web interface** (marketing campaigns, feedback, responses)
- Provide **local interfaces** for the Manager
- Store customer data, feedback, and sales history in a **database**
- Include a **LAN interface** to the Sales Management software

### Block Diagram

```
┌─────────────────────────────────────────────────────────┐
│                      CRM Software                        │
├─────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐     │
│  │   Customer  │  │   Manager   │  │    Sales    │     │
│  │  Web Portal │  │  Dashboard  │  │ Management  │     │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘     │
│         │                │                │             │
│         └────────────────┼────────────────┘             │
│                          │                              │
│                    ┌─────▼─────┐                        │
│                    │  Database │                        │
│                    │(Customers,│                        │
│                    │ Feedback, │                        │
│                    │  Sales)   │                        │
│                    └───────────┘                        │
└─────────────────────────────────────────────────────────┘
```

---

## Step 3: Customer Needs (CN)

### Needs Specification

| ID | Statement | Outcome Class | Traces To |
|----|-----------|---------------|-----------|
| CN.1 | The company needs a CRM software to know who its customers are and have updated contact information. | Information | CP.1.1 |
| CN.2 | The company needs a CRM software to be aware of when each customer was last contacted. | Information | CP.1.2 |
| CN.3 | The company needs a CRM software to know customer feedback statistics monthly. | Information | CP.2 |
| CN.4 | The company needs a CRM software to allow responding to customer feedback. | Construction | CP.3 |
| CN.5 | The company needs a CRM software to know customer behavior patterns. | Information | CP.4 |
| CN.6 | The company needs a CRM software to know projected sales forecasts quarterly. | Information | CP.5 |

---

## Step 4: Software Vision

### Positioning
CRM software for companies with customer relationship difficulties. Unlike generic CRMs, this solution focuses on communication channel management and feedback responsiveness.

### Stakeholders
| Stakeholder | Interest |
|-------------|----------|
| Marketing Team | Customer campaigns, contact management |
| Manager | Statistics, reports, decision making |
| Sales Team | Sales forecasting, behavior analysis |
| Customers | Feedback submission, response tracking |

### High-Level Features
1. Customer contact database management
2. Marketing campaign execution
3. Feedback collection and response
4. Statistics and analytics dashboard
5. Sales forecasting

---

## Step 5: Functional Requirements (FR)

### Requirements Specification

| ID | Statement | Traces To |
|----|-----------|-----------|
| FR.1 | The CRM shall store and display customer contact information including name, email, phone, and address. | CN.1 |
| FR.2 | The CRM shall record the date of last contact for each customer. | CN.2 |
| FR.3 | The CRM shall display customers not contacted within a configurable period. | CN.2 |
| FR.4 | The CRM shall calculate and display feedback statistics by category monthly. | CN.3 |
| FR.5 | The CRM shall allow users to compose and send responses to customer feedback. | CN.4 |
| FR.6 | The CRM shall analyze and display customer purchase behavior patterns. | CN.5 |
| FR.7 | The CRM shall generate quarterly sales forecasts based on historical data. | CN.6 |
| FR.8 | The CRM shall send marketing campaigns to selected customer segments. | CN.1, CN.2 |

---

## Traceability Matrix

### CP → CN Coverage

|     | CN.1 | CN.2 | CN.3 | CN.4 | CN.5 | CN.6 |
|-----|------|------|------|------|------|------|
| CP.1.1 | C |   |   |   |   |   |
| CP.1.2 |   | C |   |   |   |   |
| CP.2 |   |   | C |   |   |   |
| CP.3 |   |   |   | C |   |   |
| CP.4 |   |   |   |   | C |   |
| CP.5 |   |   |   |   |   | C |

**C** = Complete coverage ✅

### CN → FR Coverage

|     | FR.1 | FR.2 | FR.3 | FR.4 | FR.5 | FR.6 | FR.7 | FR.8 |
|-----|------|------|------|------|------|------|------|------|
| CN.1 | C |   |   |   |   |   |   | P |
| CN.2 |   | C | P |   |   |   |   | P |
| CN.3 |   |   |   | C |   |   |   |   |
| CN.4 |   |   |   |   | C |   |   |   |
| CN.5 |   |   |   |   |   | C |   |   |
| CN.6 |   |   |   |   |   |   | C |   |

**C** = Complete, **P** = Partial ✅

---

## Summary

| Artifact | Count |
|----------|-------|
| Customer Problems | 7 (5 main + 2 sub) |
| Customer Needs | 6 |
| Functional Requirements | 8 |

**Specification Type:** Slightly redundant (8 FRs for 6 CNs) but acceptable.

**Traceability:** Complete — all CPs covered, no orphan FRs.

---

## Key Learnings

1. **Decomposition:** CP.1 was split into sub-problems for clarity
2. **Outcome Classes:** Most CNs are Information-type (typical for CRM)
3. **Multiple FRs per CN:** CN.2 needed two FRs to be fully addressed
4. **Shared FRs:** FR.8 traces to multiple CNs (marketing uses contact data)

---

*Based on: Problem-Based SRS Dissertation, Chapter 4 (Gorski & Stadzisz, 2016)*

```

### references/microer-example.md

```markdown
# Example: MicroER - Renewable Energy System

> **Condensed walkthrough** of Problem-Based SRS methodology  
> **Domain:** Renewable Energy Microgeneration Management  
> **Purpose:** Technical domain example with embedded systems

---

## Business Context

A residential end user is concerned about rational energy use and has invested in a renewable energy microgeneration unit with solar and wind sources. The user wants to:
- Reduce overall energy consumption
- Minimize environmental impact
- Adapt consumption patterns to energy availability
- Monitor system efficiency

---

## Step 1: Customer Problems (CP)

### Identified Problems

| ID | Statement | Class |
|----|-----------|-------|
| CP.1 | The customer intends to reduce energy consumption to lower costs using a renewable microgeneration system based on solar and wind sources. | Obligation |
| CP.1.1 | The customer must reduce unnecessary energy consumption to reduce costs. | Obligation |
| CP.1.2 | The customer must change consumption patterns, otherwise unable to reduce consumption. | Obligation |
| CP.1.3 | The customer must monitor consumption patterns, otherwise unable to optimize usage. | Obligation |
| CP.1.4 | The customer must ensure generating unit efficiency, otherwise must consume from public grid. | Obligation |
| CP.1.5 | The customer must ensure maintenance status of generating unit, otherwise malfunction occurs. | Obligation |
| CP.2 | The customer intends to contribute to minimizing environmental impacts of public energy sources. | Hope |
| CP.2.1 | The customer must be aware of the environmental impact of their consumption. | Expectation |
| CP.2.2 | The customer intends to rationalize energy use. | Hope |
| CP.3 | The customer intends to contribute to reducing consumption pressure on regional/national energy matrix. | Hope |
| CP.4 | The customer intends to influence others toward energy and environmental causes. | Hope |

### Decomposition Notes

- **CP.1** decomposed into 5 sub-problems covering: waste reduction, behavior change, monitoring, efficiency, and maintenance
- **CP.2** decomposed into awareness and rationalization aspects

---

## Step 2: Software Glance

### High-Level Solution

MicroER software will:
- Integrate with **hardware components** (sensors, controllers)
- Provide **user interface** for consumption monitoring and profile configuration
- Collect data from **solar and wind sources**
- Control **energy distribution** based on user preferences
- Display **efficiency and maintenance** status

### System Diagram

```
┌─────────────────────────────────────────────────────────────┐
│                     MicroER System                           │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌────────────────┐        ┌────────────────┐              │
│  │  Solar Panels  │        │  Wind Turbine  │              │
│  └───────┬────────┘        └───────┬────────┘              │
│          │                         │                        │
│          └─────────┬───────────────┘                        │
│                    ▼                                         │
│          ┌─────────────────┐                                │
│          │ Energy Manager  │◄──────┐                        │
│          │   Controller    │       │                        │
│          └────────┬────────┘       │                        │
│                   │                │                        │
│    ┌──────────────┼────────────────┤                        │
│    ▼              ▼                ▼                        │
│ ┌──────┐    ┌──────────┐    ┌───────────┐                  │
│ │ Home │    │ Battery  │    │   User    │                  │
│ │Loads │    │ Storage  │    │ Interface │                  │
│ └──────┘    └──────────┘    └───────────┘                  │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

---

## Step 3: Customer Needs (CN)

### Needs Specification

| ID | Statement | Outcome Class | Traces To |
|----|-----------|---------------|-----------|
| CN.1 | The user needs MicroER to know current energy consumption in real-time. | Information | CP.1.1 |
| CN.2 | The user needs MicroER to control energy distribution based on consumption profiles. | Control | CP.1.2 |
| CN.3 | The user needs MicroER to know consumption patterns over time. | Information | CP.1.3 |
| CN.4 | The user needs MicroER to know generating unit efficiency status. | Information | CP.1.4 |
| CN.5 | The user needs MicroER to be aware of maintenance alerts. | Information | CP.1.5 |
| CN.6 | The user needs MicroER to know environmental impact metrics. | Information | CP.2.1 |
| CN.7 | The user needs MicroER to control load prioritization during low generation. | Control | CP.2.2 |
| CN.8 | The user needs MicroER to create consumption profiles. | Construction | CP.1.2 |

### Outcome Class Distribution

| Class | Count | Examples |
|-------|-------|----------|
| Information | 6 | Real-time data, statistics, alerts |
| Control | 2 | Energy distribution, load prioritization |
| Construction | 1 | Profile creation |
| Entertainment | 0 | N/A for this domain |

---

## Step 4: Software Vision

### Positioning
MicroER is energy management software for residential users with renewable microgeneration systems. Unlike simple monitors, MicroER provides active control of energy distribution based on user-defined consumption profiles.

### Stakeholders
| Stakeholder | Interest |
|-------------|----------|
| Homeowner | Cost reduction, consumption awareness |
| Maintenance Tech | System health, alerts |
| Environmental Advocate | Impact metrics, efficiency |

### High-Level Features
1. Real-time energy monitoring dashboard
2. Consumption profile configuration
3. Automatic energy distribution control
4. Efficiency and maintenance monitoring
5. Environmental impact reporting

### Environment
- Embedded hardware controllers (NI platform)
- Solar panel sensors
- Wind turbine sensors
- Battery management system
- Home automation integration (optional)

---

## Step 5: Functional Requirements (FR)

### Requirements Specification

| ID | Statement | Traces To |
|----|-----------|-----------|
| FR.1 | MicroER shall display real-time energy consumption in watts and kilowatt-hours. | CN.1 |
| FR.2 | MicroER shall allow users to define consumption profiles with load priorities. | CN.8 |
| FR.3 | MicroER shall automatically adjust energy distribution based on active profile. | CN.2 |
| FR.4 | MicroER shall display hourly, daily, weekly, and monthly consumption graphs. | CN.3 |
| FR.5 | MicroER shall calculate and display generation efficiency percentage. | CN.4 |
| FR.6 | MicroER shall generate maintenance alerts when efficiency drops below threshold. | CN.5 |
| FR.7 | MicroER shall calculate and display CO₂ offset compared to grid consumption. | CN.6 |
| FR.8 | MicroER shall reduce non-priority loads when generation falls below demand. | CN.7 |
| FR.9 | MicroER shall log all consumption and generation data for historical analysis. | CN.3 |

---

## Traceability Matrix

### CP → CN Coverage (Partial View)

|      | CN.1 | CN.2 | CN.3 | CN.4 | CN.5 | CN.6 | CN.7 | CN.8 |
|------|------|------|------|------|------|------|------|------|
| CP.1.1 | C |   |   |   |   |   |   |   |
| CP.1.2 |   | C |   |   |   |   |   | P |
| CP.1.3 |   |   | C |   |   |   |   |   |
| CP.1.4 |   |   |   | C |   |   |   |   |
| CP.1.5 |   |   |   |   | C |   |   |   |
| CP.2.1 |   |   |   |   |   | C |   |   |
| CP.2.2 |   |   |   |   |   |   | C |   |

**C** = Complete, **P** = Partial ✅

### CN → FR Coverage

|     | FR.1 | FR.2 | FR.3 | FR.4 | FR.5 | FR.6 | FR.7 | FR.8 | FR.9 |
|-----|------|------|------|------|------|------|------|------|------|
| CN.1 | C |   |   |   |   |   |   |   |   |
| CN.2 |   |   | C |   |   |   |   |   |   |
| CN.3 |   |   |   | C |   |   |   |   | P |
| CN.4 |   |   |   |   | C |   |   |   |   |
| CN.5 |   |   |   |   |   | C |   |   |   |
| CN.6 |   |   |   |   |   |   | C |   |   |
| CN.7 |   |   |   |   |   |   |   | C |   |
| CN.8 |   | C |   |   |   |   |   |   |   |

**C** = Complete, **P** = Partial ✅

---

## Summary

| Artifact | Count |
|----------|-------|
| Customer Problems | 11 (4 main + 7 sub) |
| Customer Needs | 8 |
| Functional Requirements | 9 |

**Specification Type:** Slightly redundant but well-structured.

**Traceability:** Complete — all major CPs covered.

---

## Key Learnings

1. **Technical Domain:** Embedded systems require more Control-type CNs
2. **Deep Decomposition:** CP.1 has 5 sub-problems reflecting system complexity
3. **Hardware Integration:** Software Glance must acknowledge hardware boundaries
4. **Multiple Outcome Classes:** Mix of Information (6), Control (2), and Construction (1)
5. **Hope-class Problems:** CP.3 and CP.4 are aspirational; may not generate direct FRs

---

*Based on: Problem-Based SRS Dissertation, Chapter 5 (Gorski & Stadzisz, 2016)*

```