Traditional Template sample project: Item types

Helix ALM supports the following item types: requirement documents, requirements, test cases, manual test runs, and issues. You can modify these item types to support almost any type of work item or asset your team manages during the development process.

In the Traditional Template project, the team is using Helix ALM to manage business requirements, functional requirements, non-functional requirements, technical specifications, requirement documents, test cases, manual test runs, and issues.

The following information explains the most commonly used fields in the Traditional Template. Items may contain additional fields.

Business Requirement

Business requirements represent the business needs for the product or feature. For example, this could be a new mobile application for employees in the field or enhanced security to protect the company’s intellectual property. Business requirements contain the following fields.

Field Use to:
Difficulty Rate the difficulty of implementing the requirement.
Uncertainty Rate the uncertainty involved in implementing the requirement.
Risk View an assessment of how risky the requirement is based on Difficulty and Uncertainty.
Product Identify the product the requirement will be implemented in.

Business requirements are broken down into functional requirements, non-functional requirements, and technical specifications that the team uses for implementation.

Functional Requirement

Functional requirements detail the features and capabilities needed to meet the business requirement. Functional requirements contain the following fields.

Field Use to:
Difficulty Rate the difficulty of implementing the requirement.
Uncertainty Rate the uncertainty involved in implementing the requirement.
Risk View an assessment of how risky the requirement is based on Difficulty and Uncertainty.
Product Identify the product the requirement will be implemented in.

Non-Functional Requirement

Non-functional requirements detail additional information or requirements needed to meet the business requirement. Non-functional requirements contain the following fields.

Field Use to:
Difficulty Rate the difficulty of implementing the requirement.
Uncertainty Rate the uncertainty involved in implementing the requirement.
Risk View an assessment of how risky the requirement is based on Difficulty and Uncertainty.
Product Identify the product the requirement will be implemented in.

Technical Specification

Technical specifications outline technical details or requirements needed to meet the business requirement. Technical specifications contain the following fields.

Field Use to:
Difficulty Rate the difficulty of implementing the specification.
Uncertainty Rate the uncertainty involved in implementing the specification.
Risk View an assessment of how risky the specification is based on Difficulty and Uncertainty.
Product Identify the product the specification will be implemented in.
You can configure requirements to support multiple item types. For each type, you can configure the fields to capture data, permissions for adding, editing, and updating items, and how items are visually represented in Helix ALM. For example, in the Traditional Template, Business Requirements, Functional Requirements, Non-Functional Requirements, and Technical Specifications are all types of requirements.

Requirement Document

Requirement documents typically group requirements by feature, release, or product in an outline format. In the Traditional Template, documents group business, functional, and non-functional requirements, and technical specifications.

Test Case

Test cases represent a set of conditions (pre-conditions, test steps, expected results, etc.) used to determine if a specific product is working as expected. Test cases contain the following fields.

Field Use to:
Type Identify the type of test case.
Automated test Identify if the test is automated. Can use to integrate automated testing tools with Helix ALM.
Product Identify the product to run the test against.
Component Identify the product component to run the test against.
Estimated run time Estimate the run time for the test. Used for release planning and project status reporting.
Expected Results Document results a tester running the test can expect. You can also add this information in the test case steps.

Manual Test Run

Manual test runs represent executable instances of a test case that will be run against the tested application. In practice, every time a test case needs to be run, a manual test run should be created. Manual test runs contain the following fields.

Field Use to:
Type View the test type. Populated by the related test case and cannot be changed.
Automated test View if the test is automated. Populated by the related test case and cannot be changed.
Product Identify the product to run the test against.
Component Identify the product component to run the test against.
Estimated run time View an estimated run time for the test. Populated by the related test case and cannot be changed.
Expected Results View or document results a tester running the test can expect. This information may also be included in the manual test run steps.
Manual Test Run Set Group related manual test runs to make tracking and reporting on test results easier. Populated when manual test runs are generated and cannot be changed.

Issue

Issues represent defects, feature requests, customer complaints, or other feedback on the product from internal or external users. Issues contain the following fields.

Field Use to:
Disposition Identify the issue disposition, such as Open - Reviewed, Hold, or Fix in Future Release. Hidden for Administration and Engineering security groups.
Type Identify the issue type, such as Incorrect Functionality, Cosmetic, or Feature Request.
Priority Identify the issue priority.
Product Identify the product the issue was found in.
Component Identify the product component the issue was found in.
Severity Identify the issue severity.
Reported by Capture who found the issue, the product version it was found in, and details about how it was found. Each issue can have multiple Reported by records if more than one person submits the same defect or feature request.
Days in Current State View the total number of days the issue has been in the current workflow state.
Weeks to Close View the number of weeks between the date the issue was created and the date the issue was closed.
Risk Score View an estimated risk level for the issue based on several other pieces of data associated with the issue (e.g., Type, Severity, Reproduced).
Fix Churn View the number of times the Fix event was applied to the issue.