Early PreviewJoin us on the road to v1.0 — help shape the future of specification engineering.Get Involved
SPECLAN mascotSPECLAN

Roles

SPECLAN's specification-driven workflow distributes responsibility across six roles. Each role owns specific lifecycle stages and collaborates with others at clearly defined handoff points. This page is your go-to reference for understanding who does what and when.

Want a narrative introduction? Read the companion blog post Your PO Should Own the Spec, Not the Developer — Here's How for a storytelling perspective on roles in SPECLAN, including a video walkthrough.

The Six Roles

Requirements Engineers

Requirements Engineers are the authors and stewards of specifications. They translate business goals into structured, testable specifications that the rest of the team can act on.

Primary responsibilities:

  • Create and maintain Goals, Features, and Requirements
  • Write clear acceptance criteria that define "done"
  • Shepherd specifications through draft and review stages
  • Respond to review feedback and refine specifications until they meet approval criteria
  • Ensure specifications remain consistent, traceable, and complete

Lifecycle ownership:

  • draft -- Create and iterate on specifications freely
  • review -- Submit specifications for stakeholder review, track and address all feedback

Collaboration points:

  • Hand off approved specifications to Development Teams for implementation
  • Collaborate with Product Teams to ensure specifications align with business goals
  • Review Change Requests submitted by Development or QA Teams during locked stages

Development Teams

Development Teams turn approved specifications into working software. They own the implementation phase and signal readiness for testing when their work is complete.

Primary responsibilities:

  • Implement specifications according to acceptance criteria
  • Transition specifications from approved through in-development to under-test
  • Submit Change Requests when specifications need modifications during implementation
  • Use the Implementation Assistant to generate optimized plans and prompts for coding tools

Lifecycle ownership:

  • in-development -- Active implementation; the specification is locked to prevent moving targets

Collaboration points:

  • Receive approved specifications from Requirements Engineers
  • Hand off completed work to QA Teams by transitioning to under-test
  • Submit Change Requests to Requirements Engineers when spec changes are needed during development
  • Coordinate with AI Systems that may assist with or perform implementation tasks

QA Teams

QA Teams validate that implementations match their specifications. They are the gatekeepers who decide whether work is ready for release.

Primary responsibilities:

  • Verify implementations against acceptance criteria and test scenarios
  • Document test results and communicate findings
  • Transition verified specifications from under-test to released
  • Return failing work to Development Teams with clear explanations of what went wrong

Lifecycle ownership:

  • under-test -- Conduct validation; approve or reject implementations

Collaboration points:

  • Receive completed implementations from Development Teams
  • Return failing items to Development Teams for rework
  • Submit Change Requests to Requirements Engineers if specifications need clarification or correction
  • Report release status to Managers and Product Teams

Product Teams

Product Teams set the strategic direction. They define business goals and ensure that specifications align with the product vision.

Primary responsibilities:

  • Define and prioritize business goals (G-### entities)
  • Review specifications during the review stage to verify alignment with product strategy
  • Approve or request changes to specifications that affect product direction
  • Monitor the overall health and progress of the specification portfolio

Lifecycle ownership:

  • review -- Participate as stakeholders, providing feedback and approval on specification content

Collaboration points:

  • Work with Requirements Engineers to define goals and shape feature priorities
  • Provide business context that helps Development Teams understand the "why" behind specifications
  • Receive release reports from QA Teams and Managers

Managers

Managers oversee the workflow from a process and delivery perspective. They ensure that work moves through the lifecycle smoothly and that teams have what they need.

Primary responsibilities:

  • Monitor specification status across the portfolio
  • Identify bottlenecks and resolve cross-team blockers
  • Track progress through lifecycle stages
  • Ensure compliance with process rules (e.g., Change Request requirements for locked specifications)

Lifecycle ownership:

  • Managers do not own a specific lifecycle stage but have visibility across all stages

Collaboration points:

  • Coordinate between Requirements Engineers, Development Teams, and QA Teams
  • Escalate issues that block lifecycle transitions
  • Use the SPECLAN tree view and status reports to maintain portfolio-level awareness

AI Systems

AI Systems participate as implementation agents, working alongside or in place of human developers. SPECLAN treats AI as a first-class participant with the same workflow rules as human team members.

Primary responsibilities:

  • Implement specifications according to acceptance criteria (same as Development Teams)
  • Follow the locked-specification workflow -- AI cannot modify specs without a Change Request
  • Generate implementation plans using the Implementation Assistant
  • Operate within the boundaries set by approved specifications

Lifecycle ownership:

  • in-development -- Perform implementation tasks, identical to human Development Teams

Collaboration points:

  • Receive work assignments through the Implementation Assistant or directly from Development Teams
  • Produce implementations that QA Teams validate through the same process as human-authored code
  • Operate under the same Change Request rules -- if a spec needs modification, AI must request it through the formal process

Roles and the Lifecycle

The diagram below maps each role to the lifecycle stages where they are active. Roles shown in bold own that stage; roles in regular text participate or collaborate.

Key Handoff Points

  1. review to approved -- Requirements Engineers complete the review process. The specification becomes the authoritative reference for what to build. Ownership transitions to Development Teams.

  2. approved to in-development -- Development Teams (or AI Systems) pick up the specification and begin implementation. The specification locks -- further changes require a Change Request.

  3. in-development to under-test -- Development Teams signal that implementation is complete. QA Teams take ownership and begin validation against acceptance criteria.

  4. under-test to released -- QA Teams verify the implementation and approve it for release. If testing fails, the item returns to Development Teams for rework.

How Roles Interact with Change Requests

Once a specification reaches in-development or later, it is locked. Any role that needs a modification must create a Change Request rather than editing the specification directly. This ensures traceability and prevents moving targets during active work.

Situation Who Creates the Change Request
Spec ambiguity discovered during implementation Development Teams or AI Systems
Test reveals a spec defect QA Teams
Business priorities shift Product Teams (via Requirements Engineers)
Process or compliance update needed Managers (via Requirements Engineers)

Related Topics