A hierarchy, not a flat list
Nest sub-requirements as deep as the work goes, with tasks as the leaves. One tree you expand, collapse, reorder, and re-parent — with types (Feature, Bug Fix, Performance, Enhancement) and a real status workflow: Draft → In Progress → In Review → Approved → Rejected → Archived.
Tasks — divide the work, keep the requirement whole
Break a requirement into lightweight tasks — To do, In progress, Done — and hand each to a person or a whole team. “The API” to backend, “the screen” to frontend, “load testing” to QA, all under one requirement, each with its own owner, links, and view.
Link at any level — it rolls up automatically
Attach test cases, defects, executions, and releases to a requirement, a sub-requirement, or a task — wherever the evidence lives. Hawzu rolls the whole subtree up to the parent, de-duplicated and always live. Directly-linked stays yours to edit; inherited is read-only, so nothing's double-counted.
A detail view that answers “is this done?”
One rich view per requirement: a formatted description with attachments, custom fields, an owner (a person or a team), and tabs for its test cases (direct and inherited), releases and runs, defects, sub-items, comments, and a change history with diffs. Watch it, and get pinged when it moves.
The traceability matrix — with explainable risk
Every requirement mapped to the tests that cover it and the defects they caught, with coverage and validation percentages and a High / Watch / Healthy risk read on every row — rules-based, with the reason spelled out: uncovered, a failing test, a severe open defect, stale evidence. Scope it to a release, and export it.
Polish the wording with AI
An optional AI assist rewrites a requirement's title or description for clarity and tone — pick from a few variations and apply. It sharpens what you wrote; it never invents requirements, and it never touches coverage or risk.