The Requirements module provides you with a central repository for documenting and tracking all aspects of your project, from conception to delivery. This can include business goals, customer requests, functional requirements, or any other requirements whose approval and progress you want to track.
Requirements can be high-level descriptions or formal documentation for your release, depending on your development methodology.
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 also use requirements to document business-oriented information rather than simply defining deliverables. For example, within requirements you might enter business objectives, executive briefs, risk factors, or market opportunities.
You can link requirements to tests and defects, 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 item implements which requirement.
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 contain the overall story of what you want to deliver, rather than a hierarchy of tasks. For example, you 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 could work with both backlog and requirements in parallel. Alternatively, you could choose one of these modules to reflect quality implementation, and link your tests to that module.
First you create a framework of high-level requirements. You then 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 associate each requirement with releases, tags, tests, defects, and features.
The Requirements tree (left pane) contains a hierarchy of folders and requirements.
Within the requirements tree you can drag and drop requirements as needed. ALM Octane highlights locations for dropping the requirement in green or red, depending on whether you are able to drop a requirement in that location. Top level requirements cannot be moved out of the containing parent folder. Child requirements can be moved under a different parent requirement.
The Requirements module lets you 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 to 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, tables, images, and links.
In Author mode each requirement is displayed in a single document that extends from the highest-level requirement until the lowest-level child. Numbering inside the document indicates the requirement hierarchy (1, 1.1, 2, and so on). The title of the document is the title of the highest-level requirement.
Manage mode lets you create and work with requirements within a grid, similar to the Backlog module. Each requirement is an item in the grid, and you can perform operations on one or more requirements using the Preview pane on the right.
You create a container folder for a set of requirements, and then add additional child requirements to the folder. In this grid view you can filter items and perform bulk operations.
In the Children tab you can also work with a Board View, similar to the Backlog module. The Board View can help you manage the phases of your requirements.
For an overview, see Using the board view.
Use Author mode to define detailed requirements in a rich-text document view.
Within the Requirements module, select Author in the title bar.
In the requirements tree, select a folder and click + to add a requirement. Create a folder if needed.
Enter the requirement details in the Add Requirement dialog box. Within the description you can use the text editor to format text and to add tables, images, and links.
When you finish defining your high-level requirement, you will see it as a document in the right pane. Note that Author mode displays all the contents of a requirement as one document, but each child and sibling requirement is managed within a separate box. As you move your mouse between requirements, a dotted line is displayed showing which further actions you can take.
To create a child requirement in the right pane, click Add Child below an existing requirement. To add a sibling, click Add Sibling below an existing requirement.
For example, if you are in requirement 1 and you add a child, the new requirement will be labeled 1.1. If you add a sibling, it will be labeled 2.
Click Save to save your changes. Alternatively, when you leave a requirement your changes are saved automatically.
Use Manage mode to define a requirement in a grid view, and then perform operations using the Preview pane.
Within the Requirements module, select Manage in the title bar.
In the requirements tree, select a folder and click + to add a requirement. Create a folder if needed.
Alternatively, select the Children tab and click + Requirement.
Enter the requirement details in the Add Requirement dialog box. Within the description you can use the text editor to format text, and add images or links.
Select a requirement in the tree. The right pane lets you do the following:
Details tab. View a requirement's details and assign it to a release.
Children tab. View a requirement's children, add a child requirement, and perform operations on requirements using the Preview pane.
Tests tab. Assign a manual test, Gherkin test, or test suite to a requirement, and track progress using the Preview pane.
Defects tab. Assign defects to a requirement and track progress.
You can associate requirements with different work items in several ways:
- From a test, in the Covered requirement field, select the associated requirements.
- In Author mode, you can select a requirement and assign tags using the Preview pane.
When viewing a requirement's details (in either mode) you can assign tags and releases in the Details tab. In the Relations tab you can associate a requirement with a feature, defect, or test.
You can create an Excel file with a hierarchy of requirements, and import it into ALM Octane. In the Excel file the hierarchy is represented by relative indentation in each row, which is then converted into a hierarchy of requirements in ALM Octane.
For example, this is useful if someone who is not using ALM Octane (such as a business analyst) creates requirements, which are then imported and implemented by the development team.
The Import Requirements permission is enabled by default for all roles except Viewer and Team member.
To download an Excel template file, click the ALM Octane Settings button, and select Import > Requirement Documents. In the dialog box, click View import file example.
You can now edit this file, or create another file based on this template.
When importing, ALM Octane only imports the first sheet of the Excel file.
The first row of the first Excel sheet is the header, which represents the ALM Octane field labels. This row must contain the name column.
The text indentation level in the name column is used to determine the hierarchical order. For example:
The maximum hierarchy depth is 10 levels. The maximum number of imported entities is 1000.
When your Excel file is ready for import, click the ALM Octane Settings button, and select Import > Requirement Documents.
Browse to your file location. In the Root node field, select a parent requirement folder or requirement document in ALM Octane. All of the imported requirements will be nested under this parent.
Click Import. Each row in the Excel file is converted to a requirement document in ALM Octane.
Note that ALM Octane does not support updating requirement documents items via import. You can import each Excel file only once.
You can export requirements to Word or PDF files to help you document them for legal purposes, or share them within your organization.
Supported versions: Acrobat version 11.0.23 and higher.
In Author mode, select and click Export to Word or Export to PDF in the toolbar. ALM Octane creates a Word file or PDF using the hierarchy of the selected requirement.
Note: To generate PDFs and Word files properly in Linux environments, you need to have Arial Unicode MS installed on the server in site\storage\site\fonts or site\storage\sharedspaces\...\fonts. If additional fonts are missing, the admin should add them there. For details on installing fonts, see https://docs.aspose.com/words/java/install-truetype-fonts-on-linux/.
East Asian languages are not supported when exporting from a Linux server.
The styling in ALM Octane does not automatically generate identical styling in Word or PDF. If you want to generate output with particular fonts and sizes, select the relevant region in ALM Octane and apply a specific font and size to the text before exporting.
When you export tables, Word and PDF use their default table style rather than the style in ALM Octane.
Very wide tables and images in ALM Octane are not always exported correctly. If tables and images exceed A4 width, they are cut off when exported.
Use the Requirements module to analyze your requirements coverage.
In the Manage tab, open the Overview tab. This tab includes widgets that show useful information about the state of your project from a requirements point of view. By default, there are four widgets, including a Feature by Requirements graph. You can customize this view to display the widgets that suit you best.
In the Details tab for both Requirement folders and Requirement documents, you can add the Test coverage widget to determine the relationship between your requirements and test runs. To add this widget, customize the columns to show Test coverage. You can also add this column in the grid view in the Children tab. Hover over the widget for more information.
You can create custom graphs to display requirement status and test run coverage according to requirements. You can only create graphs for a current status.
To create a requirements status graph:
Create a custom graph using Requirements as the Item type and group by Phase. For details, see Set up the dashboard.
The requirements are displayed in alphabetical order.
To create a coverage graph:
Create a custom graph using Test runs as the Item type and Covered requirement as the X axis. For details, see Set up the dashboard.