| name | requirement-engineering |
| description | Skill for requirement analysis and PRD writing — stakeholder identification, user story mapping, acceptance criteria, PRD structure, and risk analysis. |
| stage | planning |
| type | delivery-skill |
| version | 3.0 |
| category | delivery |
| scope | platform |
| tags | ["methodology","planning","requirements","prd"] |
| note | Merged from prd-writing + requirement-analysis. Covers the full requirement engineering lifecycle. |
Requirement Engineering Skill
Purpose
Guides the SuperAgent through the full requirement engineering lifecycle: from raw feature requests to well-structured PRDs with testable acceptance criteria.
Phase 1: Stakeholder & Context Analysis
Stakeholder Identification
- Direct stakeholders: requester, end users, dev team, QA, ops/support
- Indirect stakeholders: dependent teams, downstream services, compliance/regulatory
- Map concerns to priorities:
| Stakeholder | Concern | Priority |
|---|
| End User | Usability, performance | High |
| Product Owner | Business value, timeline | High |
| Dev Team | Feasibility, maintainability | Medium |
| QA Team | Testability, acceptance criteria | Medium |
| Ops Team | Deployability, observability | Medium |
| Security Team | Security, compliance | High |
- RACI matrix (for complex features): Responsible / Accountable / Consulted / Informed
Phase 2: User Story Mapping
Story Hierarchy
Epic (large feature)
├── Feature (deliverable capability)
│ ├── User Story (user-facing behavior)
│ │ ├── Acceptance Criteria (Given-When-Then)
│ │ └── Technical Tasks
│ └── User Story
└── Feature
└── User Story
User Story Format
As a [persona], I want to [action/goal], so that [benefit/value].
INVEST Criteria
- Independent: deliverable on its own
- Negotiable: details refined during development
- Valuable: delivers user or business value
- Estimable: team can estimate effort
- Small: completable within one sprint
- Testable: clear criteria to verify
Acceptance Criteria (Given-When-Then)
Given [precondition/context],
When [action/trigger],
Then [expected outcome].
Rules:
- Use concrete values, not vague descriptions
- Cover happy path, error path, and edge cases
- Every criterion must be verifiable by an automated test or human
- Criteria must be independent of each other's ordering
Phase 3: PRD Structure
Every PRD follows this structure (sections may be shortened for smaller features but never omitted):
Required Sections
- Metadata: author, status, created/updated dates, reviewers
- Background & Problem Statement: why this feature exists, data-backed motivation
- Goals & Non-Goals: specific measurable outcomes + explicitly excluded scope
- User Personas: role, goals, pain points, technical proficiency
- User Stories & Acceptance Criteria: epics → stories → GWT criteria → priority
- Functional Requirements: FR-001 format with input/processing/output/validation
- Non-Functional Requirements: performance, security, scalability, reliability targets
- Scope & Boundaries: in-scope, out-of-scope (with reasons), future considerations
- Dependencies & Risks: dependency table + risk register with mitigations
- Timeline & Milestones: milestone table with target dates
- Success Metrics: metric name, baseline, target, measurement method
Writing Rules
| Bad | Good |
|---|
| "The system should be fast" | "API response time < 200ms at p95 under 1000 concurrent users" |
| "Handle errors gracefully" | "On validation error, return HTTP 400 with error code, field name, and message" |
| "should" | "must" (required) or "may" (optional) |
| "etc." | List all items explicitly |
| "appropriate" | Define what is appropriate |
Phase 4: Risk & Dependency Analysis
Risk Categories
| Category | Key Questions |
|---|
| Technical | Technically feasible? Do we have the skills? |
| Integration | External system dependencies? API stability? |
| Data | Data quality issues? Migration risks? |
| Performance | Can the system handle expected load? |
| Security | New attack surfaces? Compliance implications? |
| Schedule | Achievable in target timeline? |
Risk Assessment Matrix
| Probability / Impact | Low Impact | Medium Impact | High Impact |
|---|
| High Probability | Medium | High | Critical |
| Medium Probability | Low | Medium | High |
| Low Probability | Negligible | Low | Medium |
Mitigation Strategies
- Avoidance: change approach to eliminate the risk
- Mitigation: reduce probability or impact
- Transfer: shift to another party (SLA, insurance)
- Acceptance: monitor and accept the risk
Non-Functional Requirements Checklist
- Performance: response times (p50/p95/p99), throughput, concurrent users
- Security: auth, authorization, encryption, PII handling, audit logging, compliance
- Scalability: growth rate, horizontal scaling, data partitioning
- Reliability: availability target, RTO, RPO, graceful degradation
- Usability: accessibility (WCAG 2.1), i18n, browser/device matrix
- Maintainability: logging, observability, config management, feature flags
Quality Checklist (HITL Checkpoint)
Completeness
Consistency
Testability
Clarity
