Skip to content
Hawzu Docs

Requirements Overview

3 min read

Requirements describe what a project needs to build, fix, improve, or validate. In Hawzu, requirements help teams connect planned work to test cases, releases, testruns, executions, defects, labels, and coverage views.

Use requirements when your team needs a clear way to answer: what are we validating, where is it tested, and what is still missing coverage?

What Requirements Track

Section titled “What Requirements Track”

A requirement can include:

  • A required Title
  • A rich Description
  • A Type
  • A Status
  • An Owner
  • A Parent requirement (to nest it under another requirement)
  • One or more Labels
  • Project custom fields
  • Linked test cases
  • Sub-requirements and tasks
  • Related releases, testruns, executions, and defects

Requirements are project-level records. They belong to the current project and are available to other project areas that support requirement traceability.

Structure: Hierarchy and Tasks

Section titled “Structure: Hierarchy and Tasks”

Requirements are no longer a flat list. Two features let you organize work in more detail:

  • Sub-requirements — break a large requirement into smaller child requirements, nested to any depth. See Sub-requirements & Hierarchy.
  • Tasks — lightweight items under a requirement that let multiple teams each own a slice of the same work. Tasks use a simple To do / In progress / Done status. See Tasks.

Both appear nested under their parent in the Requirements tree, and coverage from sub-requirements and tasks rolls up onto the parent requirement.

Opening Requirements

Section titled “Opening Requirements”

To open project requirements:

  1. Open a workspace.

  2. Open a project.

  3. Select Requirements from the project navigation.

The Requirements page lists the requirements in the project as a tree and gives you tools to search, filter, sort, create, and open requirement details.

Requirements Page

Section titled “Requirements Page”

The Requirements table shows requirements (and their sub-requirements and tasks) as an expandable tree. Available columns include:

  • Code
  • Title
  • Type
  • Status
  • Owner
  • Labels
  • Created By
  • Created On
  • Testcases
  • Defects
  • Tasks
  • Subscribe

Code and Title are always visible and stay pinned as you scroll. You can choose which of the other columns appear using the column control in the page header.

The Testcases, Defects, and Tasks columns roll up across a requirement’s whole subtree, so a parent shows combined coverage for itself, its sub-requirements, and their tasks. Requirements with no usage are easy to spot, which helps teams find missing coverage.

Requirement Types

Section titled “Requirement Types”

Hawzu supports these requirement types:

  • Feature
  • Bug Fix
  • Performance
  • Enhancement

Types help group requirements by the kind of work they represent. Tasks do not have a type — they are shown simply as Task.

Requirement Statuses

Section titled “Requirement Statuses”

Hawzu supports these requirement statuses:

  • Draft
  • In Progress
  • In Review
  • Approved
  • Rejected
  • Archived

Statuses help your team understand where each requirement sits in the review and validation process. Tasks use their own lightweight statuses: To do, In progress, and Done.

Owners

Section titled “Owners”

Each requirement or task can have an Owner — a project user responsible for it. Owners appear in the Requirements table and can be filtered on, so it is easy to see who is accountable for each item. Assigning an owner also subscribes them to updates for that item.

Subscriptions

Section titled “Subscriptions”

You can subscribe to (watch) a requirement or task to receive updates when it changes. The creator, and any user owner you assign, are subscribed automatically. Subscription updates appear under the Requirement updates category in Notifications.

Requirement Details

Section titled “Requirement Details”

Opening a requirement shows its details view. From there, you can review or update the requirement depending on your project access.

The details view includes:

  • Requirement title and description
  • Type and status
  • Owner and parent requirement
  • Labels
  • Custom fields
  • Linked test cases (directly linked, plus read-only ones from sub-requirements and tasks)
  • Sub-requirements and tasks
  • Releases and testruns that use the requirement
  • Defects linked directly to the requirement
  • Defects linked through the requirement’s test cases
  • Comments
  • A Change History timeline of edits

See Requirement Details for a full tour.

Permissions

Section titled “Permissions”

Requirement visibility and actions depend on project access. Users need the right project permissions to view, create, update, or delete requirements. Tasks reuse the same permissions as requirements.

Users without create or update access can still view requirements when their project role allows it.

Next Steps

Section titled “Next Steps”