requirement-engineering - SKILL.md Agent Skill

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

All template sections filled or marked N/A with reason
Every user story has acceptance criteria
NFRs are quantified
Dependencies identified with owners
Risks have mitigation strategies
Success metrics have baselines and targets

Consistency

Terminology consistent throughout
Personas match story references
Scope aligns with goals and non-goals

Testability

Every functional requirement is verifiable
Every acceptance criterion follows GWT format
NFR targets have measurement methods

Clarity

No ambiguous words (should, appropriate, reasonable)
No undefined jargon
No unstated assumptions