Requirements Engineer

The Requirements Engineer is the persona that encodes, decomposes, and traces requirements with discipline. In an AI-native SDLC, the Requirements Engineer operates a stack of validated primitives that convert draft intent into auditable EARS clauses.

Executive summary

The Requirements Engineer decomposes approved specifications into atomic, testable EARS requirements and maintains the traceability matrix from requirement to test to deployed artifact. In an AI-native SDLC the Requirements Engineer operates inside the Discovery phase with a fixed set of primitives: one EARS encoding agent, four slash prompts, scoped instructions, schema-validated hooks, and a curated list of validated MCPs. Primary outputs are atomic requirement files, gap analyses, traceability reports, and requirement review records.

Role and responsibilities

Think of the Requirements Engineer like a legal codifier who turns a legislator’s intent into numbered statutes that courts can apply without interpretation. The legislator proposes, the codifier transforms, and every future judgment cites a clause by number. In an AI-native SDLC the Product Owner proposes in SPECIFICATION.md, the Requirements Engineer codifies in atomic EARS form, and every test, commit, and release note cites a requirement ID.

Primary responsibilities:

• Decompose every approved spec into atomic EARS requirements under docs/requirements/
• Maintain the traceability matrix that links each requirement to its acceptance criteria, tests, pull requests, and deployed artifacts
• Run gap scans to detect requirements without tests, tests without requirements, and deployments without either
• Run requirement reviews with the Product Owner, Software Architect, and QA Engineer at defined gates
• Operate the EARS Encoder agent and the /ears, /traceability, /gap-scan, /requirement-review prompts
• Govern the requirement change log, ensuring every change references an approved spec diff
• Publish the readiness report that releases depend on

Jobs to be done

1. As a Requirements Engineer, I want to decompose an approved spec into atomic requirements within hours, so that development is never blocked on clarification.
2. As a Requirements Engineer, I want every requirement in strict EARS form, so that agents and humans parse it identically.
3. As a Requirements Engineer, I want the traceability matrix to regenerate on every merge, so that audit answers are always current.
4. As a Requirements Engineer, I want gap scans to run on every pull request, so that tests and requirements never diverge silently.
5. As a Requirements Engineer, I want requirement reviews to be structured and recorded, so that decisions persist beyond the meeting.
6. As a Requirements Engineer, I want the readiness report to refuse release if any gap is unresolved, so that scope discipline is enforced at the gate.

Pain points before AI-native

1. Specs too coarse to test. High-level specs cannot be bound to test cases. Developers improvise decomposition inconsistently.
2. Traceability built once and abandoned. Matrix spreadsheets go stale within a sprint. Audit preparation becomes a rebuild.
3. Gaps discovered at release. Missing tests and orphan features surface at the release gate, forcing schedule slips.
4. Reviews without records. Clarifications happen verbally. Next sprint, the same question is asked again.
5. Requirement churn untracked. Changes are made in place without a diff history. Regressions in scope are invisible.

AI-native daily workflow

The Requirements Engineer operates a fixed loop each day. The loop uses GitHub Copilot primitives inside Visual Studio Code and Claude Code at the terminal, plus a small catalog of validated MCPs for external context.

Morning setup

1. Open the repository in Visual Studio Code. GitHub Copilot Chat loads AGENTS.md and the scoped requirement instructions.
2. Pull the latest main and review overnight spec changes by the Product Owner.
3. Run /gap-scan to produce the current gap report: requirements without tests, tests without requirements, deployments without either.
4. Review the traceability dashboard generated from the Azure MCP Server and GitHub MCP telemetry.

Midday execution

1. Decomposition. Invoke /ears on each new spec section. The EARS Encoder agent produces atomic requirements with unique IDs, each in strict WHEN ... THE system SHALL ... form.
2. Traceability. Invoke /traceability to bind each new requirement to existing tests, pull requests, and deployment records. The agent updates the matrix and flags orphans.
3. Gap closure. For each gap flagged in the morning scan, either author the missing requirement, raise a test task for QA Engineer, or file an ADR if architectural change is required.
4. Cross-persona sync. Use the Microsoft 365 Agents SDK MCP to raise clarification requests in the Teams channel when spec intent is ambiguous.

Afternoon review

1. Invoke /requirement-review to run the structured review session with the Product Owner, Software Architect, and QA Engineer. The agent prepares the agenda from the day’s diffs and records decisions against requirement IDs.
2. Open a pull request on the requirement files. GitHub Copilot Code Review comments on EARS compliance; human reviewers approve content.
3. Update the readiness report. A post-merge hook regenerates the report with gap counts and blocker lists.
4. Publish the daily requirement digest to the product Teams channel via the Microsoft 365 Agents SDK.

Recommended primitives

Agent

Agent	File	Purpose
ears-encoder	.github/agents/ears-encoder.agent.md	Decompose specs into atomic EARS requirements, maintain traceability, run gap scans

The EARS Encoder uses claude-sonnet-4-6 by default. Tools: read, edit, search, grep, glob. No bash access. Extended thinking is enabled for /gap-scan only, where cross-document correlation benefits from deep reasoning.

Slash prompts

Command	File	Purpose
/ears	.github/prompts/ears.prompt.md	Decompose a spec section into atomic EARS requirements
/traceability	.github/prompts/traceability.prompt.md	Bind requirements to tests, PRs, and deployments, regenerate the matrix
/gap-scan	.github/prompts/gap-scan.prompt.md	Detect requirements without tests, tests without requirements, orphan deployments
/requirement-review	.github/prompts/requirement-review.prompt.md	Prepare and record the structured review session

Instructions scoped

Scoped applyTo reduces token cost by approximately 68 percent compared to global instructions.

Scope (applyTo)	File	Purpose
docs/requirements/**/*.md	.github/instructions/requirements.instructions.md	Atomic EARS format, ID schema, cross-reference rules
docs/traceability/**/*.md	.github/instructions/traceability.instructions.md	Matrix schema, regeneration rules, audit evidence format
docs/reviews/**/*.md	.github/instructions/reviews.instructions.md	Review agenda template, decision record format

Hooks

Hooks cost zero LLM tokens. They are the strongest governance layer for requirements.

• pre-commit: reject any requirement file with non-atomic or non-EARS clauses, or with duplicate IDs
• post-commit: regenerate the traceability matrix and the readiness report
• pre-merge: block merge of any requirement change that introduces a new gap without a linked follow-up issue

Validated MCPs

MCP	Purpose	Owner
GitHub MCP Server	Read pull requests, tests, and Actions runs to populate the traceability matrix	GitHub (official)
Azure DevOps MCP Server	Read Azure Boards work items and test plans when the team uses Azure DevOps	Microsoft (official)
Azure MCP Server	Query Application Insights to confirm deployed artifacts match requirement IDs	Microsoft (official)
Microsoft Learn Docs MCP	Ground requirements on Microsoft product surfaces in current documentation	Microsoft (official)
Microsoft 365 Agents SDK MCP	Raise clarification threads in Teams and record decisions from Outlook	Microsoft (official)

Real examples

Example 1: decompose an approved spec section

Input: A spec section on contract renewal covering initiation, eligibility, and notification, approved by the Product Owner.

Invocation: /ears followed by /traceability.

Expected output:

1. A docs/requirements/contract-renewal/ directory with twelve atomic requirement files, each with a unique ID and strict EARS clause.
2. A regenerated traceability matrix that binds three pre-existing tests to two of the new requirements and flags the remaining ten as gaps.
3. A pull request with Copilot Code Review comments on clause shape and ID consistency.

Example 2: gap closure before release

Input: A release candidate with 146 merged requirements. The morning /gap-scan report flags six requirements without passing tests and two tests without requirements.

Invocation: /gap-scan followed by /requirement-review.

Expected output:

1. Six tasks in GitHub Projects created via the GitHub MCP, each linked to the requirement anchor and assigned to QA Engineer.
2. Two requirement files authored to bind the orphan tests to requirement IDs.
3. A recorded review session in docs/reviews/2026-q3-release-readiness.md with decisions tagged by requirement ID.
4. A readiness report update that reopens the release gate until all eight items close.

Anti-patterns

1. Compound requirements. Clauses that bundle two or more conditions cannot be tested atomically. Mitigation: the /ears agent and the pre-commit hook reject non-atomic clauses.
2. Manual traceability. Spreadsheets cannot be trusted on a sprint boundary. Mitigation: the matrix regenerates on post-commit.
3. Silent ID collisions. Reused IDs break audit trails. Mitigation: the pre-commit hook rejects duplicates across the docs/requirements/ tree.
4. Reviews without records. Verbal clarifications evaporate. Mitigation: /requirement-review enforces a recorded decision for every agenda item.
5. Gaps waived verbally. A waived gap without an ADR or follow-up issue re-emerges at release. Mitigation: pre-merge blocks the waiver path.

KPIs and impact metrics

KPI	Baseline	Target	Measurement
Requirements in atomic EARS	30 percent	100 percent	Requirements linter in GitHub Actions
Traceability freshness, last regeneration	7 days	< 1 hour	Post-commit hook timestamp
Gap count at release gate	14	0	Readiness report
Requirement review cycle time	2 weeks	< 1 week	PR timestamps
Orphan test rate	12 percent	< 2 percent	Gap scan output
Audit query response time	1 day	< 1 hour	Traceability matrix query log

Maturity in four levels

Level	Name	Markers
L1	Manual	Prose specs, ad-hoc decomposition, traceability built by hand
L2	Assisted	Copilot used to polish requirement phrasing, no atomic discipline
L3	Augmented	EARS Encoder agent, four slash prompts, scoped instructions, matrix auto-generated, gap scans on PR
L4	Autonomous	Full primitives kit, hooks enforced, readiness report live, reviews recorded automatically, audit response within the hour

Integration with other personas

• From Product Owner: approved SPECIFICATION.md with numbered EARS requirements as the canonical input
• From Business Manager: KPI-bound outcomes that inform gap prioritization
• To Software Architect: stable requirement IDs that anchor CODEMAP.md and API contracts
• To QA Engineer: atomic requirements that drive test case generation and coverage reports
• To Developer: requirement anchor on every PR enabling implementation traceability
• To Compliance Auditor: regenerated matrix as audit evidence on demand
• To Release Manager: readiness report gating the release cut

Glossary

• EARS: Easy Approach to Requirements Syntax. The canonical WHEN ... THE system SHALL ... form.
• Atomic requirement: a single testable clause with a unique ID, no conjunctions that introduce independent conditions.
• Traceability matrix: generated table binding each requirement to acceptance criteria, tests, pull requests, and deployments.
• Gap scan: automated sweep that detects requirements without tests, tests without requirements, and deployments without either.
• Readiness report: generated document summarizing release gate status against open requirement gaps.
• Requirement review: structured, recorded session that approves or defers requirement changes with named participants.

References

• GitHub Copilot documentation — agent mode, prompts, and instructions
• Azure Boards documentation — work item tracking for requirement-linked tasks
• GitHub Actions documentation — automation for traceability regeneration and gap scans
• Application Insights documentation — deployed artifact telemetry for requirement verification
• Microsoft Learn, Well-Architected Framework — operational excellence and audit evidence guidance