The Requirements module provides you with a free-form method of describing what you want to deliver, in terms of ideas and general specifications. For example, you might have a requirement to send an astronaut to Mars and bring them back to Earth, and your backlog will be comprised of a huge number of detailed features, user stories and tasks.
You can link requirements to tests, providing you with coverage on each requirement. If your team works with both requirements and backlog, the two can be linked to one another, showing which backlog feature implements which requirement.
You can use the Requirements module to document any business-value oriented information that you need to document, rather than simply defining deliverables. For example, within requirements you might enter business objectives, executive briefs, risk factors, or market opportunities.
In this topic:
The Requirements tree contains a hierarchy of folders and requirements:
First you create a framework of high-level requirements, then you add additional child requirements to break these into manageable parts and give team members a better understanding of the specific objectives. Requirements can also be formed in traditional ways such as goals, use cases, security effects, or performance changes.
You can then associate each requirement with releases, tags, tests, and features.
The Requirements module enables you to work in two modes: Author mode, and Manage mode. Both modes show the same content, but use a different visualization with different functionality:
Author mode enables you define requirements in a document view. You define the full details for the parent requirement, and add child requirements and their details in the same document. In author mode you can use rich text capabilities, such as adding diagrams, images and links.
Manage mode enables you to define requirements in a grid-like approach. You create a container folder for a set of requirements, and then add additional child requirements in the folder. In this grid view you can filter items, and perform bulk operations.
From a use-case perspective, the Backlog module is project-management oriented. Backlog items are defined in a hierarchy of epics, features, and stories, and different backlog items are created for different teams (for example back-end vs. client).
Requirements on the other hand contain an overall story of what you want to deliver rather than a hierarchy of tasks, and a low-level requirement might contain a major task. You therefore might define a requirement as "Multi-language support," and this could be mapped to ten different items in the backlog.
This is also reflected in the personas using these modules; backlog items may be written by project owners or PMOs, while requirements may be written by business analysts or PMs.
From the perspective of test coverage, you can work with both backlog and requirements, or you can choose one of these modules to reflect quality implementation, and link your tests to the selected module only.