Console
Specifications
Manage requirements documents that drive test coverage and traceability.
Overview
Specifications catalog requirements documents independently from individual projects, supporting reuse, version awareness, and organization-wide traceability. Product managers and compliance teams often maintain specifications while QA engineers link them to project-specific generation and coverage.
A specification record typically stores the document artifact, metadata (owner, product line, revision), and links to projects or coverage matrices. When behavior changes, update the specification and downstream projects rather than silently diverging copies.
Specifications integrate with Coverage to expose unmapped requirements, critical for audit-oriented release readiness where "we tested something" is insufficient without requirement IDs.
Who should read this
- QA engineers, SREs, platform teams, and developers operating Zof Console and APIs.
Prerequisites
- Access to Quality → Specifications or equivalent Console destination
- Requirements documents prepared with traceable requirement identifiers
When to use this workflow
- Onboarding new team members to Zof terminology and workflows
- Authoring internal runbooks aligned with Console labels
- Designing CI/CD or webhook integrations against documented behavior
Step-by-step procedure
Create a specification record
Open Quality → Specifications and select Add specification.
Upload the authoritative document and enter revision, owner, and product metadata.
Wait for ingestion processing before linking to projects or triggering generation.
Link specifications to projects
From project settings or the wizard, link the specification instead of uploading a duplicate file.
Prefer linking when multiple projects validate the same product baseline.
Document link changes in change management when audits require history.
Drive generation from specification content
Trigger test generation from linked projects using specification sections as source truth.
Review scenario titles for requirement ID references (for example SCN-PAY-014-refund-eligibility).
Reject generation output that invents requirements not present in the specification.
Maintain version discipline
Upload a new revision when product management publishes updated requirements.
Notify project owners to regenerate or manually adjust affected cases.
Keep superseded revisions available for historical run explainability when policy requires.
Analyze traceability in Coverage
Open Quality → Coverage and filter by specification or requirement ID.
Export gap reports for release readiness meetings highlighting unmapped requirements.
Pair gap remediation with test library edits or targeted generation passes.
Coordinate with stakeholders
Share specification links (not ad hoc attachments) in PRD review meetings.
Align compliance attestations to requirement IDs mapped in Coverage matrices.
Schedule periodic audits of orphan tests with no upstream requirement mapping.
Key concepts
- Organization scope
- All Zof Console and API operations are isolated to your authenticated tenant.
- Governed execution
- Agent output and remediation follow policy packs with human approval when configured.
Best practices
- Require requirement IDs inside specification text for machine-assisted traceability
- Single authoritative specification per product baseline, avoid departmental duplicates
- Pair specification updates with coverage review in the same change ticket
- Use consistent revision naming (v3.2, 2025-05-01) in metadata and change logs
Common issues
- Coverage shows gaps despite many tests
- Tests may lack requirement ID linkage in scenario metadata. Update titles or traceability fields and refresh coverage.
- Linked project still uses old behavior
- Project may not have regenerated after specification revision. Regenerate or manually update affected cases.
Was this page helpful?