- Home
- Skills
- Jasonkneen
- Kiro
- Requirements Engineering
requirements-engineering_skill
- TypeScript
492
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill jasonkneen/kiro --skill requirements-engineering- SKILL.md8.4 KB
Overview
This skill transforms vague feature ideas into clear, testable requirements using the EARS (Easy Approach to Requirements Syntax) format. It captures user stories, generates precise acceptance criteria, surfaces edge cases, and validates completeness before design. The result is a consistent, unambiguous requirements set ready for implementation and testing.
How this skill works
Start by converting stakeholder input into concise user stories (As a [role], I want [feature], so that [benefit]). For each story, the skill produces acceptance criteria written in EARS patterns (WHEN/IF ... THEN system SHALL ...) and enumerates edge cases like errors, boundaries, concurrency, and empty states. It runs a checklist-based validation for completeness, clarity, consistency, and testability so requirements are ready to hand off to design and QA.
When to use it
- At the start of any new feature or project
- When stakeholder requests are ambiguous or high-level
- To define acceptance criteria for user stories and sprint tickets
- When documenting system behavior for QA and testing
- Before moving from requirements to design or implementation
Best practices
- Always write a one-line user story before acceptance criteria
- Use EARS patterns consistently (WHEN/IF ... THEN system SHALL ...) for testability
- List edge cases explicitly: empty inputs, boundaries, errors, concurrency
- Avoid implementation detail; state observable system behavior and measurable metrics
- Validate with checklist: roles, normal flows, edge cases, error handling, and measurable performance
Example use cases
- Convert a product idea into a requirements document with EARS-formatted acceptance criteria
- Create detailed acceptance criteria for payment, upload, or search features
- Identify and document edge cases and error-handling requirements before development
- Produce a validated requirements template to share with stakeholders and QA
- Turn stakeholder emails or meeting notes into testable user stories and acceptance criteria
FAQ
EARS (Easy Approach to Requirements Syntax) gives repeatable patterns (WHEN/IF ... THEN system SHALL ...) that make requirements specific, unambiguous, and testable.
How does this skill handle non-functional requirements?
It captures measurable non-functional requirements (performance, security, accessibility) as EARS-style statements or explicit metrics in the non-functional section of the document.
Can it find missing edge cases automatically?
It suggests common edge-case categories (errors, boundaries, concurrency, empty states) and prompts you to confirm or add cases relevant to the feature.