CS-6302 APPLICATION LIFECYCLE MGT

WORKING WITH REQUIREMENTS AND ANALYZING RISK

Page |1

Module 005 WORKING WITH REQUIREMENTS

AND ANALYZING RISK

“Quality is never an accident; it is always the result of intelligent effort.”

– John Ruskin

Overview of the Course

Students learn how to manage quality information throughout the

development cycle, from constructing requirements, designing and executing tests,
through monitoring defects.

Students learn how to work with the Desktop client and the new Web client. In
addition, using the HP Sprinter and its new features are discussed, including:

 Using HP Sprinter on manual tests

 Using version control to keep track of changes and also to create and
manage libraries
 Creating and comparing baselines
 Importing and exporting from Microsoft Excel
 Generating reports and graphs using the dashboard
 Using cross-project customization and Project Planning and Tracking
(PPT)

Objectives:
After completing this module, you should be able to:

 Specify requirements

 Identify the characteristics of a useful requirement

 Add requirements to a project

 Create a requirements tree

 Assign requirements to releases and cycles

CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
Page |2

 Add traceability links using traceability

 Add traceability links between requirements

 Perform risk analysis for requirements

Researching beyond the coverage of this module is highly encouraged to
supplement your understanding of the topics covered. Always, think and see
beyond the box.
The citation provided is a guideline. Please check each citation for accuracy
before use.

So, what are we waiting for? Let us now explore the Lifecyle
Management of Application

Introduction

The ALM Roadmap

After creating releases in the Management module, you continue the
application testing process by defining requirements. Requirements detail what
needs to be tested in an application. When planning a project, you must allocate
time to clearly define the requirements of the testing process.
Requirements measure the progress of a project. This helps you plan and
execute the successive stages of the Application Lifecycle Management process.
For example, you use the requirements data during the Plan Tests stage to
create tests for testing the requirements. In the Execute Tests stage, you execute
these tests to check whether the requirements have been met. In the Track
Defects stage, you log and track defects to ensure that the final product does not
contain any errors.
Requirements must be based on a thorough knowledge of your
customer’s expectations and the requirements of your business processes.
After defining requirements, you navigate to the Management module and
create cycles within the release. After creating cycles, you again navigate to the
Requirements module and assign requirements to the releases and cycles
defined in the Management module.
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
Page |3

How to Use Requirements in ALM

Prerequisite – Clearly Defined Requirements

Requirements are the foundation of the entire testing process and should
describe in detail what needs to be solved or achieved to meet the objectives of
your application under development.
Defining requirements clearly and correctly at the beginning of a project has
the following advantages:
 Aids development and testing – Clearly defined requirements help
developers set a target for themselves and the testing team to identify
their testing priorities.
 Helps prevent scope creep – Documented requirements are the best
defense against scope creep, where requirement documents are
continually amended and appended, impeding software development
and testing efforts. Avoid constant changes with clearly defined goals at
the start of the project. You can then use that goal as a reference to focus
on individual efforts.
 Sets clear expectations between teams – Defining requirements and
gaining approval from relevant stakeholders is the best way to ensure
that expectations have been agreed upon by all parties involved—
product marketing, customer service, IT, and documentation. Ensure
that all necessary parties are involved in creating requirements. Then
confirm and validate their expectations.
 Saves time and money – “Measure twice, cut once” is a phrase used in
carpentry, but it also applies to defining requirements. Save time and
money by taking time at the beginning to invest in your requirements.
Characteristics of a Useful Requirement
A useful requirement is always:
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
Page |4

Unique – Is this the only requirement that defines this particular

objective?
 Precise – Is there any language that is difficult to interpret?
 Bounded – Are there clearly defined conditions for measuring the
objectives?
 Measurable – Build one or more test cases that completely verify all
aspects of a requirement.
Determining Requirements Scope
Determine the requirements scope by gathering information such as
functional and technical specifications, marketing and business
requirements documents, and stakeholders’ goals.
Example
Some questions you might want to ask are:
 What is the main purpose and direction of the application?
 What are the critical constraints of the application?
 What are the major features of the application?
 What is the relative importance of each element in the application
functionality?
 What are the critical or high-risk functions of the application?
 What are your business or testing priorities?
 Do your customers/end users agree with your priorities?
 What are your overall quality goals?

Requirements Module Views

The Requirement module includes the following views. You select a

view from the View menu.
 Requirements Tree – Enables you to view your requirements
hierarchically in a tree.
 Requirement Details – Enables you to create links between
requirements and other entities. It also enables you to calculate
and analyze requirement risk.
 Requirements Grid – Enables you to view requirements in a flat
non-hierarchical view. Each line in the grid displays a separate
requirement.
 Coverage Analysis – Enables you to analyze the breakdown of
child requirements according to test coverage status.
 Traceability Matrix – Enables you to view traceability
relationships between requirements and other requirements or
tests in a matrix.

Requirement Types

Because the requirements management model can differ for each

company, ALM supports a variety of requirement types. These include
business requirements that meet the high-level objectives of the
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
Page |5

organization. ALM also supports functional requirements that describe

how the software should behave.
In addition, non-functional requirements, such as usability,
efficiency, portability, and maintainability, are supported in ALM by the
Testing and Undefined requirement types.
You can organize all requirement types using the Folder and
Group requirement types. Functionally, the two requirement types are
the same; however, you typically use folders to group requirements at a
higher level, while you use groups to group together similar, and yet very
specific, requirements. For example, you could organize all security-
related requirements in a folder, while organizing field validation
requirements in a group.
A Requirement tree is a visual organization of the relationship
between requirements. Requirements are defined in a hierarchy,
starting with business requirements on the highest level and drilling
down to functional and non-functional requirements on the lowest level
of the Requirement tree.

Specifying Requirements
What Is a Requirements Tree?
ALM helps you define requirements for the testing process in a
hierarchical form. You use the Requirements module to build a
Requirements tree to outline and organize the requirements of a project.
You typically organize requirements according to the functional
components of the application under test. The functional category is then
further broken down according to the type of requirements, such as
functional compared with performance. Your organization can follow
other conventions.
For example, the figure on the slide above shows the requirement
tree for the Mercury Tours application.
The Requirements tree also includes the Performance
requirement, which indicates the performance area that requires testing.
A test is a series of steps that check whether a requirement is met.
A test can be manual or automated and can be executed in a single stage
or in multiple stages of the testing process. If a test fails, you log defects
to indicate that a requirement has not been met.
Using the Requirements Tree View
You use the Requirements Tree view to add requirements within
the requirements hierarchy.
The Requirements Tree view displays the parent-child
relationship between requirements. This enables you to analyze
requirements with respect to their position in the requirements
hierarchy. Viewing requirements in the Requirements Tree view enables
you to determine the relationship of requirements with other entities,
such as tests and defects. If a child requirement is linked to a test, its
parent requirement automatically links to the same test. Similarly, if a
defect is logged against a child requirement, the same defect appears in
the Requirements Tree view for the parent requirement.
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
Page |6

Requirement Module Icons

Tools for Building a Requirements Tree

You start building a requirements tree by creating a requirement
within the Requirements folder at the root level. After creating a
requirement, you create requirements within the folder. Depending on
the need identified in the testing process, you might decide to create a
parent or a child requirement.
The table on the slide lists the tools for defining requirements and
building the requirements tree.
Note: You can create a requirement of type Folder only within another
requirement of type Folder. By default, ALM provides a Folder type
requirement with the name Requirements at the root of the
Requirements tree.

Toolbar Buttons in the Requirements Module

ALM provides a toolbar in the Requirements module for

managing requirements. The table on the slide above lists the available
toolbar buttons.

Creating a Requirement
To create a requirement, perform the following steps:
1. From the Requirements tree, select Requirements and click the
New Requirement button. The Create New Requirement dialog
box is displayed.
2. In the Create New Requirement dialog box, from the Requirement
Type list, select the type of requirement you want to create.
3. In the Name field, type an appropriate name for the new
requirement and click the OK button. The New Requirement
dialog box is displayed.
Note: A requirement name cannot include any of the following
characters: \ ^ *.

Specifying Requirement Details

The following is the list of the standard fields that you can use to
describe each requirement in more detail. If your project needs to
capture additional data, your ALM administrator can configure the
Requirements module to include custom-defined fields and selection
lists.
 Name – Assigns a short description of the requirement. ␣
Requirement Type – Indicates the type of the requirement,
which may be business, folder, functional, group, testing, or
undefined.
 Author – Indicates the name of the user who created the
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
Page |7

requirement. By default, the current user is set as the author.

 Direct Cover Status – Indicates the execution status of tests that
are linked to a requirement. It can be set to any one of the
following: Not Covered, Failed, Not Completed, Passed, No Run, or
N/A.
 Priority – Sets the priority level of the requirement. Selections
include 1-low, 2-medium, 3-high, ␣␣very high, and 5-urgent.
 Product – Indicates the component of the application on which
the requirement is based.
 Reviewed – Indicates whether the requirement has been
reviewed and approved.
 Target Cycle – Indicates the cycle to which the requirement is
assigned.
 Target Release – Indicates the release to which the requirement
is assigned.
After specifying a name for the requirement, you specify the details
for the new requirement. To specify the details for the new requirement,
perform the following steps:
1. In the New Requirement dialog box, select the appropriate values
for the various fields.
2. In the Description text box, type a detailed description of the
requirement.
3. Click the Submit button.
4. Click the Close button to add the new requirement to the
Requirements tree.

Viewing Requirement Details

You use the Requirement Details view to view and change the
values specified for various fields of a requirement. In addition, you use
the Requirement Details view to display requirements according to tests
with which they are associated, the requirements with which they are
traced, and the defects with which they are linked.
To display the Requirement Details view, from the Requirement
module menu bar, select View →Requirement Details. The Requirement
Details view is displayed.
In the Requirement Details view, in the left pane, select a
requirement. The right pane displays the following tabs for the selected
requirement:
 Details – Enables you to view and change the values of fields
specified for the selected requirement
 Rich Text – Enables you to add, view, and edit rich text using an
editor from within ALM
 Attachments – Enables you to add attachments to a requirement
 Linked Defects – Lists the defects linked to the currently selected
requirement
 Requirements Traceability – Enables you to associate the selected
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
Page |8

requirement with other requirements in the requirements tree

 Test Coverage – Lists the tests associated with the currently selected
requirement

 Business Models Linkage – Lists the business model entities linked

to the currently selected requirement

 Risk Assessment – Calculates and analyzes risk for the currently

selected requirement

 History – Displays a list of changes made to the currently selected

requirement

Description and Comments Tabs

In the right pane of the Requirement Details view, the Details tab
displays the following tabs:
 Description – Displays a description of the selected requirement.
You type this description while creating a requirement. You can
modify this description.
 Comments – Displays the comments added by various users for
the selected requirement. It also displays the username of the
user who added the comment and the date and time when the
comment was added. If required, you can add a new comment.

Rich Text Editor and Requirement Templates

The rich text editor has the same functionality for data input as
Microsoft Word. The content is fully searchable and reportable.
You create templates using the rich text feature. These allow you
to standardize and control your requirements by enforcing customized
templates and to facilitate capturing requirements in a consistent
structure across your entire organization.
The rich text editor includes the following features:
 An HTML editor
 Expanded viewable area
 Available as searchable field
 Enables using a rich text template
Note: You use the Tools →Customization menu to create templates.
To open the rich text editor, perform the following steps:
1. Click View→ Requirement Details.
2. Click the Rich Text tab.
To apply a Requirements template using the Rich Text feature, perform
the following steps:
1. Click the Apply Rich Text Template button. A warning message is
displayed stating that the template will overwrite the existing
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
Page |9

content.
2. Click the Yes button.

Viewing Multiple Requirements

The Requirements Grid view provides a non-hierarchical view of

the requirements data. Each line in the grid displays a separate
requirement. You can use this view to record and review the
requirement details.
To navigate to the Requirements Grid view, select View ␣
Requirements Grid from the menu bar in the Requirement module. The
Requirements Grid view is displayed.
The Requirements Grid view also enables you to filter
requirements based on different fields. For example, you can click the
text box below the direct cover status field, and click the browse button
that is displayed within the text box. Clicking the browse button displays
the Select Filter Condition dialog box. You can select the filter condition
and click OK to display the filtered Requirements Grid. In addition, you
can group requirements based on their attributes.

Editing Multiple Requirements

In addition to filtering requirements, you use the Requirements

Grid view to edit multiple requirements. You can replace field values for
a selected requirement and all of its child requirements, or for all
requirements in the requirements tree.
To edit multiple requirements, perform the following steps:
1. In the Requirements Grid view, select Edit ␣ Replace from the
menu bar. The Replace dialog box is displayed.
2. In the Replace dialog box, select or type the field for which you
want to replace values in the Find in Field list.
3. In the Value to Find box, select or type the value you want to
search.
4. In the Replace with dialog box, select or type the value to replace
the existing field values.
5. Click Replace All to replace the field values of all the
requirements.

Assigning Requirements to Releases and Cycles

After reviewing requirements in the Requirements module, you

assign a requirement to a release or to a cycle.
Assigning a requirement to a release enables you to track
requirements coverage by release. For each release, you can identify the
number of requirements that are covered. You can also create reports
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
P a g e | 10

that are based on the requirements coverage.

In addition to assigning a requirement to a release, you can assign
a requirement to a cycle. You assign a requirement to a cycle when you
want to test a function or feature only during a single cycle within a
release. For example, consider that the Online Banking application has
an existing feature to print the Savings account statement. To test this
existing functionality, you assign a requirement to a cycle that tests the
overall functionality of the Online Banking application. This is an existing
feature and you do not need to assign it to a cycle that tests only new
features.

Assigning Requirements to Releases

You assign a requirement to a release to test the requirement in all

cycles within the release. To assign a requirement to a release, perform
the following steps:
1. From the Requirements module menu bar, select View
→Requirements Tree. The Requirements Tree view is displayed.
2. From the Requirements tree, right-click a requirement and select
Assign To Release. The Select Releases dialog box is displayed.
3. In the Select Releases dialog box, expand the Release tree and
check the release check box to which you want to assign the
requirement.
4. Click the OK button to close the Select Releases dialog box. The
requirement and its child requirements, if any, are assigned to a
release.

Assigning Requirements to Cycles

You assign a requirement to a cycle to test a requirement only

within a specific cycle of a release.
To assign a requirement to a release, perform the following steps:
1. From the Requirements tree, right-click a requirement and select
Assign To Cycle. The Select Cycles dialog box is displayed.
2. In the Select Cycles dialog box, expand the Release tree and check
a cycle check box.
3. Click OK to close the Select Cycles dialog box.
The requirement and its child requirements, if any, are assigned to the
cycle.

Using Traceability

After creating a requirement in the Requirements tree, you can

establish traceability between requirements. Requirement traceability is
an ALM feature that enables you to create a relationship, and define a
link, between multiple requirements. While analyzing the impact of a
change proposed in a specific requirement, the traceability link enables
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
P a g e | 11

you to identify other requirements that the change might affect.

You use the Requirement Details view to add traceability links to
and from a requirement. In the right pane of the Requirement Details
view, click the Requirement Traceability tab.
The Requirement Traceability tab provides the following tabs for
working with traceability links:
 Relationships – Enables you to add and remove traceability links
between requirements
 Impact Analysis – Enables you to analyze the impact of
requirement changes by reviewing requirement relationships

Requirement Relationships

You use the Relationships tab to view traceability links that exist
between requirements. In addition, the Relationships tab enables you to
add and remove traceability links between requirements. The
Relationships tab provides the Trace From and Trace to grids for
working with traceability links.
The Trace From grid displays requirements that affect the
requirement selected in the Requirements tree. For example, the
screenshot in the above slide shows that the Flight Tickets requirement
is affected by any changes to the Flight Reservation Service requirement.
The Trace To grid displays requirements that are affected by a
change to the requirement selected in the Requirements tree. For
example, the window in the slide above shows that any change to the
Flight Tickets requirement affects the Origin and Destination and the
Service Class requirements.
The Relationships tab provides tools for working with traceability
links. The window in the slide above shows the available tools.

Adding Traceability to Requirements

The Relationships tab enables you to add a traceability link between

requirements. To add a traceability link, perform the following steps:
1. Select the requirement you will add traceability to.
2. Select the Requirement Traceability tab.
3. On the Relationships toolbar, click the Add Requirement
Traceability button. The Requirements tree is displayed in the
right pane.
4. From the Requirements tree, expand Requirements and select a
requirement.
a. To add the selected requirement to the Trace From list,
click the Add to Traceability arrow and select Add to
Traceability (Trace From). The selected requirement is
displayed in the Trace From grid.
b. To add the selected requirement to the Trace To list, click
the Add To Traceability arrow and select Add To
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
P a g e | 12

Traceability (Trace To). The selected requirement is

displayed in the Trace To grid.

Impact Analysis

After establishing traceability relationships in the Relationships

tab, you use the Impact Analysis tab to analyze the impact of requirement
changes by reviewing the relationships.
The Impact Analysis tab displays requirements in a hierarchical
structure. In addition, each requirement in the Requirements tree
displays an icon. You use these icons to understand the associations and
dependencies that exist between requirements.

Traceability Matrix

The traceability matrix enables you to determine the extent of

relationships between requirements and other requirements, and
between requirements and tests. It helps you verify that all requirements
are met, and identify changes to the scope of your requirements when
they occur.
The traceability matrix lists:
 The source requirements and their associated requirements and
tests
 The total number of relationships for each source requirement
A low value can imply that the source requirement is not associated
with enough requirements or tests.
A high value can imply that the source requirement is too complex
and can perhaps be simplified.
A zero value indicates that no relationship exists.
To create a traceability matrix, perform the following steps:
1. In the Requirements module, click View ␣ Traceability Matrix on
the menu.
2. Click the Create a Configuration link. The Configure Traceability
Matrix dialog box is displayed.
3. Click the Define Source Requirements link.
4. Click the Set Filter/Sort button to filter/sort the source
requirements. The Filter Requirements dialog box is displayed.
5. Click the dropdown for Requirement Type or the filter condition
for the fields. The Select Filter Condition dialog box is displayed.
6. Enter the Filter Condition and click the OK button in the Select
Filter Condition dialog box.
7. Click the OK button in the Filter Requirements dialog box.
8. Click the Filter by Linked Requirements link.
9. Select the Filter by Linked Requirements checkbox.
10. Select one of the four available options for Include Source
Requirements:
 Affected By
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
P a g e | 13

 Not Affected By
 Affecting
 Not Affecting
11. If you selected Affecting or Not Affecting for Include Source
Requirements, select one of the three options:
 Direct Children And Traced To Requirements
 Direct Children
 Traced To Requirements
12. Click the Set Filter/Sort button to set the filter/sort for linked
requirements.
13. Click the filter by linked tests link.
14. Select the checkbox for Filter by Linked Tests.
15. Select Include Source Requirements Linked To Or Not Linked To
The Following Tests.
16. Click the Set Filter/Sort button to set the filter and sorting for the
linked tests.
17. Click the OK button in the Configure Traceability Matrix dialog
box.

Using Risk-based Testing

While planning tests for your requirements, you often face

challenges, such as inadequate resources, which force you to
compromise and only partially test some requirements. You identify
requirements that have a low criticality or have only a minor risk
associated with them.
After identifying the criticality and risk associated with
requirements, you use the risk- based testing feature in ALM to calculate
the level at which each requirement must be tested. The four testing
levels defined in ALM are Full, Partial, Basic and None. Risk-based testing
uses the requirement type and resource availability to calculate the
testing level.

Risk-based Quality Management

To perform risk-based quality management, you:

 Establish business criticality – You determine how critical a
requirement is for your business. You do not measure how
difficult it is to implement a requirement. For example, the Online
Banking application requires that users must be able to access the
application for at least 23 hours a day. If the application stops
working, it has a negative impact on your business. Therefore, the
availability of the Online Banking application is a highly critical
requirement for your business.
 Establish failure probability – You determine the likelihood of
failure of a test associated with a requirement. Determining
failure probability enables you to devise mitigation strategies
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
P a g e | 14

well in advance. For example, if there is a high probability that the

Online Banking application is inaccessible, you can deploy a back-
up server for load sharing when a large number of users access
the Online Banking application. This ensures that your business
is not affected.
 Assess functional complexity – You determine the complexity of
the requirement’s implementation. For example, a requirement
with implementation that involves making significant changes to
your application to enable it to communicate with other systems
would probably be assigned a high complexity value.
 Perform risk analysis – Based on the business criticality and
failure probability of a requirement, you allocate testing time for
the requirement. Based on the testing time, ALM calculates the
testing level for the requirement and you use this testing level to
determine whether a requirement should be tested fully or
partially.
 View analysis results – After performing risk analysis, you view
the analysis results using graphs.

Analyzing and Assessing Risks

Based on the type of a requirement, ALM enables you to analyze or

assess the associated risks. For example, a requirement of type Folder is
at a high level in the Requirements tree and has child requirements. You
assess the risks associated with all child requirements and based on this
assessment, analyze the risks associated with the parent requirement.
The parent requirement is the analysis requirement and the child
requirements are the assessment requirements.
 Assessment Results tab – This area displays the assigned or
calculated values of the risk and functional complexity of an
assessment requirement.
 Assessment Questions tab – This tab enables you to determine the
business criticality, failure probability, and functional complexity
of a requirement by assigning it values directly or by assigning
values to a set of criteria.

Establishing Business Criticality

To establish business criticality for a requirement, perform the following

steps:
1. In the Requirement Details view, from the Requirements tree,
select a requirement and in the right pane, click the Risk
Assessment tab. On the right pane, click the Assessment
Questions tab.
2. Click The Business Criticality tab. The Business Criticality page
displays a list of criteria used to determine the business criticality
of the selected requirement.
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
P a g e | 15

3. To assign a value to a criterion, from the Criterion column, select

a criterion name. A description of the selected criterion appears
in the Description of Criterion field.
4. From the Value column, select a value for the criterion.
After you assign a value to each criterion, ALM calculates the business
criticality of the requirement and displays it in the Calculated
Business Criticality field.

Establishing Failure Probability

After defining the risk category for each requirement, you

determine how much time each requirement needs to be tested. The time
needed to test a requirement depends on the failure probability of the
requirement. You generally need more time to test a requirement with a
failure probability that is high because it is likely that the
implementation of this requirement contains defects.
To establish the failure probability of a requirement, perform the
following steps:
1. In the right pane, click the Failure Probability tab. The Failure
Probability page displays a list of criteria used to determine the
business criticality of the selected requirement.
2. To assign a value to a criterion, from the Criterion column, select
a criterion name. A description of the selected criterion is
displayed in the Description of Criterion field.
3. From the Value column, select a value for the criterion.
After you assign a value to each criterion, ALM calculates the failure
of the requirement and displays it in the Calculated Failure
Probability field.

Establishing Functional Complexity

You can assign or calculate the functional complexity category of

an assessment requirement. A requirement’s functional complexity
indicates the complexity of the requirement’s implementation. It has
three possible values: High, Medium, and Low
For example, a requirement with an implementation that involves
making significant changes to your application to enable it to
communicate with other systems probably has a high complexity and
would be assigned a high functional complexity.
In contrast, a requirement that involves no significant changes to
enable your application to communicate with other systems would
probably not have many associated risks, and so is likely to be assigned
a low functional complexity.
To determine the functional complexity category for a requirement,
perform the following steps:
1. On the right pane, click the Functional Complexity tab. The
Functional Complexity tab displays a list of criteria used to
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
P a g e | 16

determine functional complexity.

2. Assign a value to each criterion. To assign a value to a criterion, in
the Criterion column, click a criterion name and select a value
from the Value column. You can view a description of a criterion
in the Description of Criterion box. After you have assigned a
value to each criterion, the calculated functional complexity is
updated according to the values you assigned to the criteria.

Performing Risk Analysis

After establishing the failure probability for assessment

requirements, you perform risk analysis by allocating testing time to the
analysis requirement. You can perform analysis without specifying a
testing time, but providing the testing time results in better analysis. In
the early stages of a release, you can estimate testing time based on a set
of generalized criteria to establish some baselines and to gauge the
magnitude of the testing effort.
Is the screen new or existing? Are we adding calculated values to
a new database field or populating them with user data? Answers to
these types of questions might be stated in terms of very general testing
numbers. For instance, all new screens in this release might be allocated
80 hours of testing, whereas changes to existing screens might only be
allocated 40 hours. Database changes involving new fields might be
estimated at 60 hours, but populating existing fields might only require
20 hours.
Later, as requirements become less fluid, you can make more
precise allocations. At the same time, you can move hours to those
requirements that need more testing time. Analysis can help a project
stay on track because it clearly illustrates where one set of requirements
has an excess of hours that might benefit another.
To perform risk analysis, complete the following steps:
1. In the Requirement Details view, from the Requirements tree,
select the analysis requirement you want to analyze. It is a folder
or group of fields.
2. In the right pane, click the Assessment Results tab.
3. In the Total Allocated Testing Time field, type the time available
to test the requirement and its children.
4. Click Analyze and Apply To Children. ALM calculates the testing
time and testing level of each assessment requirement. This
calculation is based on the risk category of the assessment
requirements, and the testing level and testing time of the
analysis requirement.

Viewing Analysis Results

The results of the risk analysis calculation display in the following ways:
 The Total Required Testing Time field – Displays the total testing
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
P a g e | 17

time needed to test all assessment requirements included in the

risk analysis
 The Total Required Development Time field – Displays the total
time needed to develop all the assessment requirements, based
on the required development time you estimated for each
assessment requirement
 No. of Requirements Graph – Displays the number of child
requirements associated with each risk category
 Total Testing Time Graph – Displays the total calculated testing
effort needed to test all requirements of a particular risk category

Drilling Down into Results

To view the requirements included in each risk category, click a

segment in the No. of Requirements graph. The Drill Down Results
window is displayed with a list of requirements in the risk category. You
can customize the order and appearance of the columns and view details
for an individual requirement. You can also export the contents of the
grid as a text file, Microsoft Excel spreadsheet, Microsoft Word
document, or HTML document.
To display the requirements that were not included in the
analysis, click the Excluded link. The Drill Down Results window displays
a list of requirements that were not included in the analysis.
After viewing and drilling down into results, compare the total
calculated testing time with the number of available resources. If the
number of available resources is not sufficient to test the requirement,
you should reduce the testing level of the assessment requirements or
reduce the testing time assigned to each testing level. After reducing the
testing level or the testing time, perform the risk analysis again.

Generating a Risk Report

After finalizing the testing policy for your requirements, you can
generate a risk report that details your testing strategy for the analysis
requirement.
To generate a risk report, perform the following steps:
1. On the Risk page, click the Report button. The Generate Report
dialog box is displayed.
2. In the Generate Report dialog box, type the name and location of
the Word file to which you want the data to be exported in the
Default Location field. Alternatively, click the browse button to
select a location from the Save As dialog box.
3. To add the report as an attachment to the analysis requirement,
check the Add Report as Attachment checkbox.
4. To include a list of assessment requirements included in the risk
analysis, check the Include List of Requirements in the Report
checkbox.
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
P a g e | 18

5. Click the Generate button. ALM generates and saves a report in

the specified location.

Test Coverage

You begin by defining your requirements in the Requirements

tree and then assigning them to a release or a cycle in the Releases tree.
In the planning stage, you build a Test Plan tree based on these assigned
requirements. To keep track of the relationship between your assigned
requirements and tests, you add links between them. In the Test Plan
module, you create requirements coverage by selecting requirements to
link to a test. Alternatively, in the Requirements module, you create test
coverage by selecting tests to link to a requirement. You can also create
coverage by converting requirements to tests in the test plan tree.
Coverage is automatically created between the requirements and their
corresponding tests.
A test can cover more than one requirement and a requirement
can be covered by more than one test.

Linked Defects

You can link defects to the following entities: requirements, tests,

test sets, test instances, runs, run steps, and other defects. Defect linkage
is useful, for example, when a new test is created specifically for a defect.
By creating this linkage, you can determine if the test should be run
based on the status of the defect.
You can link a defect directly or indirectly to an entity. When you
add a defect link to an entity, ALM adds a direct link to this entity and
indirect links to other related entities. In addition, during a manual test
run, if you add a defect, ALM automatically creates a linkage between the
test run and the new defect.

Mailing Requirements

You can send an email about a requirement to other users in your

ALM project. This enables you to routinely inform them about the status
of your requirements. A link included in the email message enables the
recipient to go directly to the requirement.
Note: By default, ALM sends email in HTML format. To send email as
plain text instead, edit the Mail Format parameter in the Site
Configuration tab in Site Administration.
To Mail a Requirement
Follow these steps to mail the requirements:
1. Select one or more requirements and click the Send By Email
button. The Send Email dialog box opens.
Tip: You can automatically send the email to a specific user type.
This can be any requirement column with a user name value,
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
P a g e | 19

including user-defined fields. Click the Send By Email arrow and

choose an option. For example, choose Send By Email to Author
to send the email to the user who wrote the requirement.
2. Type a valid email address or user name. Alternatively, click the
To button or Cc button to select users. The Select Recipients
dialog box is displayed. You can sort the users list, search for
users, group users by user groups, and select users from the list
or from a group tree.
3. In the Subject box, type a subject for the email.
4. Choose whether you want to include the requirement’s
attachments, history, test coverage and/or traced requirements.
If you include the requirement’s attachments, any rich text for the
requirement is included as a separate attachment.
5. Click Send to send the email.

Working with Business Process Models

The ALM Business Models module addresses the need for a

stronger connection between business process modeling, quality
assurance management, and requirement definition. The module
integrates business process models into the application lifecycle.
This integration fosters collaboration between the various roles
involved in the business process modeling and testing lifecycles, thereby
facilitating communication between business users and people in more
technical departments. This collaboration facilitates better business
outcomes by identifying high-level activities, thus guiding the QA
manager in determining the high level test requirements.
Integrating business process models into ALM involves importing
those models and linking requirements and tests to models, activities,
and end-to-end business flows. After executing tests, you can display
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
P a g e | 20

quality status views on the business process model level.

To work with business process models in ALM, you must first design
models with standard modeling tools, and import the models to ALM.

Working with Application Lifecycle Intelligence (ALI)

To fully gain insight and remove the latency in decision-making,

an IT staff needs traceability down to the actual artifacts and systems
used by development teams to build the applications.
HP Application Lifecycle Intelligence (ALI) delivers this
traceability. ALI is embedded in ALM to aggregate information from
multiple development tools and to establish complete ALM traceability.
By linking requirements and testing activities with source code
analysis and build management systems, ALI can surface actionable
information and help application stakeholders make informed decisions.
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
P a g e | 21
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
P a g e | 22

References and Supplementary Materials

Books and Journals

Micro. Customized Application Lifecycle Management 12.0 Essentials

Student Guide
Hewlett-Packard Development Company, L.P.
http://hp.com/software/education

Markov, Georgi and Druzhinina, Olga; 2011; Towards an industrial ALM

(Application Lifecycle) Tool Integration; Blekinge Institute of Technology,
School of Computing
CS-6302 APPLICATION LIFECYCLE MGT
WORKING WITH REQUIREMENTS AND ANALYZING RISK
P a g e | 23