Skip to content
Hawzu Docs

Sub-requirements & Hierarchy

3 min read

Requirements in Hawzu can be organized into a hierarchy. A requirement can contain sub-requirements, and each of those can contain sub-requirements of its own. This lets you break a large requirement down into smaller, focused pieces while keeping everything connected.

Use hierarchy when a single requirement is too broad to test as one item and you want to track coverage at both the parent and child level.

What Is a Sub-requirement

Section titled “What Is a Sub-requirement”

A sub-requirement is a normal requirement that has a parent requirement. It has the same fields and behavior as any other requirement:

  • Title, description, type, status
  • Owner, labels, and custom fields
  • Linked test cases, releases, testruns, and defects
  • Comments and change history

The only difference is that it sits underneath another requirement instead of at the top level.

There is no fixed limit on how deep the hierarchy can go — you can nest sub-requirements as many levels as your project needs.

The Requirements Tree

Section titled “The Requirements Tree”

The Requirements page always shows requirements as a tree. Sub-requirements are nested under their parent, and you can expand or collapse each branch:

  • A parent requirement shows a chevron you can click to Expand or Collapse its children.
  • Sub-requirements are always listed before tasks under the same parent.
  • Indentation and folder icons show each item’s place in the hierarchy.

The tree starts fully expanded so you can see the full structure at a glance.

Create a Sub-requirement

Section titled “Create a Sub-requirement”

You create a sub-requirement the same way you create any requirement — by choosing a Parent requirement in the create form.

  1. Open the project Requirements page.

  2. Click Create Requirement.

  3. Fill in the requirement fields.

  4. In Parent requirement, choose the requirement this new item should sit under.

  5. Click Create Requirement.

Leaving Parent requirement set to None (top-level requirement) creates a normal top-level requirement instead.

The parent picker shows your existing requirements as an indented tree, so you can pick the right place in the structure. Tasks cannot be chosen as a parent — only requirements can contain sub-requirements.

Move a Requirement (Re-parenting)

Section titled “Move a Requirement (Re-parenting)”

You can change where a requirement sits in the hierarchy at any time.

  1. Open the requirement.

  2. Click Edit Requirement.

  3. Change the Parent requirement field:

    • Pick a different requirement to move it under a new parent.
    • Clear the field (None (top-level requirement)) to promote it back to the top level.

  4. Click Save Changes.

To keep the hierarchy valid, you cannot move a requirement under itself or under one of its own sub-requirements.

How Coverage Adds Up

Section titled “How Coverage Adds Up”

Hierarchy affects how coverage is summarized on the Requirements page and in the requirement detail view.

  • A parent requirement’s Testcases count is the total across the requirement itself, all of its sub-requirements, and their tasks. A test case linked in more than one place is counted once.
  • A parent requirement’s Defects breakdown adds up the same way, across all the requirements and tasks below it.
  • The Tasks column shows how many of the requirement’s tasks are done, out of the total.

Inside the requirement detail view, test cases, releases, testruns, and defects that come from sub-requirements are shown in separate, clearly labeled sections:

  • Directly linked items belong to the requirement itself and can be edited there.
  • Items From sub-requirements & tasks are shown for context and are read-only — you manage them on the sub-requirement or task that owns them.

This lets you see complete coverage for a parent requirement without losing track of where each link actually lives.

Deleting Within a Hierarchy

Section titled “Deleting Within a Hierarchy”

Deleting a requirement also removes everything nested under it — all of its sub-requirements and their tasks are deleted together. Review the tree before deleting a parent so you do not remove children you still need. See Delete Requirements for details.

Next Steps

Section titled “Next Steps”