ReqLens Academy
A working library for delivery teams. Start with the craft: what each role is accountable for, how to write a requirement someone can actually test, and how to keep scope, coverage and readiness visible from the first conversation to the release note.
Start with your role
Four roles, one set of requirements. Each path covers the craft first and the tooling second.
Product Owner
Owning outcomes: shaping scope, ordering the backlog, and deciding what good enough means.
16 guidesBusiness Analyst
Turning intent into requirements that are specific, testable, and traceable.
16 guidesQA Engineer
Designing coverage that proves the requirement, not just the code, and closing the loop on defects.
16 guidesDelivery Manager
Keeping scope, coverage, and readiness visible so a release date means something.
14 guidesFollow a path
Curated sequences through the library. The order is a suggestion, so you can join one wherever it is useful.
The Business Analyst path
From what the role is accountable for, through writing criteria a team can test, to elaborating and decomposing real requirements in ReqLens.
7 guidesLearning pathThe QA Engineer path
From testing the requirement rather than the build, through designing coverage and running cycles, to closing the loop on defects and traceability.
7 guidesLearning pathThe Product Owner path
From the three decisions only this role can make, through ordering and acceptance, to deciding whether something is genuinely ready to ship.
6 guidesLearning pathThe Delivery Manager path
From why status is not progress, through traceability and readiness, to reporting that a steering group can actually act on.
6 guidesLearning pathThe ReqLens pipeline, end to end
Every stage in order, from a raw requirement through to release reporting. The fastest route to understanding how the whole product fits together.
9 guidesFoundations
What each role actually does, and the shared vocabulary that lets four roles work from one set of requirements.
What a Business Analyst actually does
The Business Analyst turns intent into requirements a team can build and test. The real shape of the role, what it produces, and where it goes wrong.
What a Delivery Manager actually tracks
Status is not progress and a percentage is not evidence. What a Delivery Manager should be tracking, and the signals that are worth escalating early.
What a Product Owner actually owns
The Product Owner decides what is worth building and in what order. Here is what that accountability really covers, and the three ways it gets diluted.
What a QA Engineer actually does
QA is not the last step before release. It is the discipline of deciding what evidence would prove a requirement was met, and gathering it.
Practices
How the work gets done well: writing acceptance criteria, decomposing scope, tracing coverage, and calling a release ready.
Acceptance criteria examples and template
Acceptance criteria examples for login, payments and refunds: weak versus testable criteria, failure, boundary and permission cases, and a reusable template.
How to decompose an epic into user stories
How to break down an epic into user stories that ship alone: the cuts that fail, story splitting examples, and how to turn a PRD into features and stories.
Release readiness checklist and template
A release readiness checklist with owners, evidence and stop signals, test exit criteria, UAT sign-off, and a go or no-go decision record template.
Requirement quality checklist and examples
A requirement quality checklist with before-and-after examples of ambiguous, incomplete and untestable requirements, how to find gaps, and a review decision.
Requirements change impact analysis
How to analyse the impact of a requirement change: what to trace, which tests to review, how to reassess earlier results, plus a worked example and a template.
Requirements gathering tools and checklist
Requirements gathering tools grouped by the job they do, a checklist and question bank for each stage, and a handoff template for decisions and open questions.
Requirements traceability matrix template
How to create a requirements traceability matrix step by step: what to link, planned versus executed coverage, and a free Excel RTM template with an example.
Choosing a requirements management tool
How to choose a requirements management tool: a practical checklist, demo questions, a worked refund example, and a free printable evaluation sheet.
Product
ReqLens itself, one guide per stage of the pipeline, from requirement through to release reporting.
Test cases from Jira and Azure DevOps
Import Jira stories or Azure DevOps work items, generate reviewed test cases from their acceptance criteria, trace results, and push them back to the ticket.
Use case template and alternate flows
A use case template, a refund example with alternate and exception flows traced to criteria and tests, use case vs user story, and how ReqLens generates them.
Generating test cases from requirements
How to generate test cases from requirements, step by step: a worked refund example from acceptance criteria to linked test cases, review and approval.
Requirement Studio: rough to testable
How elaboration works in ReqLens: what it adds to a raw requirement, why every change needs approval, and how edits propagate to everything downstream.
Breaking a requirement into features
How ReqLens finds feature boundaries in a large requirement, why boundary detection and enrichment are separate steps, and what that separation protects.
Reporting coverage and traceability
How ReqLens turns pipeline evidence into reports a steering group can act on, and why end-to-end traceability is generated rather than assembled by hand.
Running a test cycle: a TestExecute guide
Why blocked is a first-class result rather than a kind of failure, what a run record needs to stay meaningful, and how execution feeds readiness.
Tracking defects across the pipeline
Defects do not only come from testing. How ReqLens tracks where a defect was found, separates severity from priority, and makes rejection reasons useful.
Workspaces, roles and permissions
Three roles, ranked rather than listed, and what each can do. How project access resolves, and why some things belong to the workspace rather than a person.
Browse by topic
Reference
21 guides published so far, with more added regularly.