HP0-M31 Quality Center Certification Preparation 2 - Requirements Module

REQUIREMENTS

·         Requirements describe in detail what needs to be solved or achieved to meet the objectives of your application under development.

·         Not all fields and functionality in the Requirements module are available if you are working with the Starter Edition.

·         You use the requirements scope to determine the overall requirements for the application under development. You then define different groups of requirements based either on requirement type or functional area.  Requirement groups are recorded in the Requirements module by creating a requirements tree. The requirements tree is a graphical representation of your requirements specification, displaying the hierarchical relationship between different requirements.

·         For each requirement group, you create a list of detailed requirements in the requirements tree.

·         Each requirement in the tree is described in detail and can include any relevant attachments. You then assign the requirement a priority level which can be taken into consideration when creating the test plan.

·         After defining your requirements, you can add traceability between the requirements. When analyzing the impact of a change proposed in a specific requirement, traceability shows the other requirements that the change might affect.
(    Lets read more)

·         You can assign the requirements to releases and cycles of the releases tree in the Releases module. The releases tree specifies past, current, and upcoming product releases within a hierarchical tree structure.

·         The assigned requirements are then used as a basis for the test plan in the Test Plan module. The tests you create during the test plan phase are used to link to these requirements to create coverage.

·         After a requirement is approved, you change a requirement from a Not Reviewed status to Reviewed.

·         You can use risk-based quality management to help you decide how to allocate the resources you have available.

·         To help review the requirements, you can generate reports and graphs.

·         After the requirements have been reviewed and approved, you can create a baseline for your requirements. A baseline can be used as an agreement that all stakeholders are responsible for signing off. This baseline then serves as a point of reference against which changes can be compared. The requirements baseline can be reviewed throughout the project to ensure its ongoing validity.

·         You can also import requirements to your Quality Center project from Microsoft Word, Excel, or other third-party requirement management tools. To import requirements, you must first install the appropriate HP Quality Center add-in.

·         Indicator columns. Indicates that the specified requirement has attachments, linked defects, alerts, and follow up flags.

·         Rich Content - Enables you to add, view, and edit Microsoft Word rich text directly from Quality Center. Changes you make to the rich text for a requirement are saved automatically when you move to a different requirement or a different module.

·         To find a specific requirement by ReqID in the Requirements Tree view, choose Requirements > Go to Requirement, and type the requirement ID. To display the requirement ID, select the ReqID column using the Select Columns dialog box. You can only go to requirements that are in the current filter.

·         The Requirement Details view enables you to create links between requirements and other entities. It also enables you to calculate and analyze requirement risks.

·         Requirements Traceability tab. Lists the requirements linked to the currently selected requirement.

·         Test Coverage tab. Lists the tests associated with the currently selected requirement.

·         Linked Defects tab. Lists the defects linked to the currently selected requirement.

·         Risk tab. Calculates and analyzes requirement risks.

·         History tab. Displays a list of changes made to the currently selected requirement.

·         The Requirements Grid view enables you to display requirements in a flat non-hierarchical view. Each line in the grid displays a separate requirement.

·         The Coverage Analysis view enables you to analyze the breakdown of child requirements according to test coverage status.

·         The Versions menu is available in a version control enabled project. It contains commands that enable you to check in and check out requirements, undo a checkout, or view all the requirements you have checked out.

·         The Favorites menu contains commands that enable you to add, organize, and load favorite views.

·         The Analysis menu contains commands that enable you to generate requirements reports and graphs.

·         You can access the Requirements menu bar from the Requirements module by pressing the shortcut key F9.

·         Deleting a requirement also deletes its child requirements, tests coverage, defects linkage, and

attachments.

·         Direct Cover Status - The current status of the requirement. By default, the status is Not Covered.

A requirement status can be one of the following:

a)         Not Covered. The requirement has not been linked to a test.

b)         Failed. One or more tests covered by the requirement have an execution status of “Failed”.

c) Not Completed. One or more tests covered by the requirement have an execution status of “Not Completed”. Alternatively, tests covered by the requirement have execution statuses of “Passed” and “No Run”.

d)         Passed. All the tests covered by the requirement have an execution status of “Passed”.

e)         No Run. All the tests covered by the requirement have an execution status of “No Run”.

f) N/A. The current status of the requirement is not applicable.

g)         -----. The requirement does not have a direct cover status as it belongs to a requirement type that does not support coverage.

·         Requirement Type - Indicates the type of requirement. Default values are:

a)      Business. A business process requirement. By default, you cannot add coverage to this requirement.

b)      Folder. A folder for organizing requirements. By default, you cannot add coverage to this requirement.

c)       Functional. A system behavioral requirement.

d)      Group. A collection of related requirements.

e)      Testing. A system performance requirement.

f)       Undefined. An undefined requirement.

You can customize the default types and create your own requirement types.

·         Old Type (obsolete) (formerly Type) - The type of requirement (obsolete). In previous versions of Quality Center, the type could be any value configured in the project, with typical values Change, Functional, Guideline, Quality, Standard, and System. This field can only be in use for requirements of undefined type.

·         Business Impact, Risk – Possible values are A (High), B (Medium), and C (Low).

·         Failure Probability, Functional Complexity - Possible values are 1 (High), 2 (Medium), and 3 (Low).

·         Testing Level - 1-Full, 2-Partial, 3-Sanity, and 4-None

·         You can add user-defined fields and change the label of any of the fields in the Requirements module. You can also customize project lists.

·         You can use the Script Editor to restrict and dynamically change the fields and values in the Requirements module.

·         The Requirements module enables you to define and manage your requirements. You record requirements in Quality Center by creating a requirements tree. This is a graphical representation of your requirements specification, displaying your requirements hierarchically.

·         After defining your requirements, you can establish traceability between two or more requirements. Requirements traceability defines a relationship between the requirements. When a requirement changes, Quality Center alerts the directly influenced traced requirements.

·         During the requirements specification phase, you assign your requirements to a release or a cycle in the releases tree. Requirements can be assigned to one or more releases or cycles.

·         Assigned requirements can be associated with tests and defects. In this way, you can keep track at all stages of the software development life cycle. If a requirement changes, you can immediately identify which tests and defects are affected, and who is responsible.

·         You start a requirements tree by adding requirements to the Requirements root folder. You can organize your requirement topics into folders. The root folder cannot be renamed or deleted.

·         Quality Center Starter Edition: Requirement Types are not available.

·         In addition to creating requirements directly in Quality Center, you can also import requirement data from Microsoft Word or Microsoft Excel to your Quality Center project.

·         A folder name cannot include the following characters: \ ^ *

·         You can assign requirements to one or more releases or cycles in the releases tree.

·         During the test planning stage, you associate the tests in the Test Plan module to your assigned requirements to create coverage. By defining coverage, you can keep track of the relationship between the tests in your test plan and your requirements.

·         During the test running stage, you add the tests that cover the assigned requirements to test sets in the Test Lab module, and then you assign the test set folders to cycles.

·         Quality Center Starter Edition: Assigning requirements to releases or cycles is unavailable.

·         Assigning a parent requirement to a cycle also assigns its child requirements to the same cycle.

·         You can update your requirements directly in the requirements tree or grid, or in the Requirement Details dialog box. Using the Requirement Details dialog box, you can update the details, attachments, tests coverage, requirement traceability links, risk-based quality management settings, and defect links for any requirement. You can also view a list of changes made to any requirement.

·         You can search for a particular requirement by using the Find command.

·         You can replace field values in the requirements tree or in the requirements grid using the Replace command.

·         You can change the way the Requirements module displays the requirements tree. This includes zooming in and out of the tree, refreshing the tree, filtering the tree, and expanding and collapsing the branches of the tree.

·         Version Control: By default, the Versions and Baselines tab  is displayed.Click the Audit Log tab to view  requirement history. For each change to the requirement, the grid displays the date and time of the change and the name of the user who made the change.

·         You can send email about a requirement to other users in your Quality Center project. This enables you to routinely inform them about the status of your requirements. A link is included in the email message that enables the recipient to go directly to the requirement.

·         By default, Quality Center 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.

·         You can automatically send the email to a specific user type. This can be any requirement column with a user name value, 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.

·         If you include the requirement’s Attachments, any rich text for the requirement is included as a separate attachment.

·         You cannot rename or delete or move the root folder. The root folder cannot be copied within the same project.

·         You can copy a requirement within the same project or between projects. When you copy a requirement topic, any children of the requirement topic are also copied.

·         Test coverage, defect linkage, and risk-based quality management data for the requirement are not copied.

·         To copy a requirement with traceability, you must also copy its associated traced requirements.

·         If you paste a requirement that has the same name as an existing requirement, the suffix _Copy is added automatically to the end of the requirement’s name.

·         You can copy a requirement and paste its URL as a link. The requirement itself is not copied. Instead, you can paste the address into another location, such as an email or a document. Clicking the link opens up Quality Center and takes you to the requirement. If you are not already logged in, Quality Center first prompts for login details.

·         You can move a requirement to a different location in the requirements tree. Moving a requirement topic also moves its child requirements, tests coverage, requirement traceability links, and defects linkage. You can also move a requirement to a new location in the requirements tree by dragging it.

·         You can delete a requirement from the Requirements module. Deleting a requirement also deletes its child requirements, tests coverage, requirement traceability links, and defects linkage. Deleting a requirement deletes all previous versions of the requirement.

·         There are two methods you can use to create tests from requirements:- Convert Requirements to Tests, Generate a Test from Requirements

·         Convert Requirements to Tests - Convert requirements to tests in a specified subject in the test plan tree. You can convert selected requirements or all requirements in the requirements tree. This method, using the Convert to Tests wizard, assists you when designing your test plan tree. Coverage is automatically created between the requirements and their corresponding tests.

·         Select Convert lowest child requirements to design steps to convert all lowest level child requirements to design steps, the next level up to tests, and all levels above to subjects.

·         Select Convert lowest child requirements to tests to convert all lowest level child requirements to tests and all levels above to subjects.

·         Select Convert all requirements to subjects to convert all selected requirements to subjects.

·         If you stop the conversion process, any requirements already converted are not deleted from the test plan tree. You must delete them manually.

·         Generate a Test from Requirements - Convert requirements to a test in a specified subject in the test plan tree and a specified test set in the Test Lab module. This method, using the Generate Test dialog box, enables you to quickly run a test when analyzing your requirements. Coverage is automatically created between the requirements and their corresponding tests. Note that by default you cannot generate a test for the following  requirement types, which do not enable coverage: Business, Folder, and Group.

·         Requirements traceability defines a relationship between requirements. As requirements or their linked requirements change, you can trace and monitor the impact of these changes. Requirements traceability is available for Quality Center Enterprise Edition and Quality Center Premier Edition. When analyzing the impact of a change proposed in a specific requirement, the traceability links indicate the other requirements that the change might affect.

·         After defining your requirements in the requirements tree, you can establish traceability between the requirements. Using the Requirements Traceability tab in the Requirement Details view, you can add traceability links to and from a selected requirement. Trace from links indicate requirements that affect a selected requirement. Trace to links indicate requirements that are affected by a selected requirement.

·         When a requirement changes, Quality Center alerts the affected requirements. The alerts can be seen by all users. Quality Center also sends email notifications to the authors of the affected requirements.

·         When a requirement changes, Quality Center flags the traced to requirements and sends email to notify the authors to evaluate the impact on their requirements.

·         You can define traceability relationships between requirements in the Relationships tab. This tab contains the Trace From and Trace To grids. You define a relationship by selecting a requirement from the requirements tree or by typing a requirement ID.

·         You can also add a requirement traceability link by dragging a requirement from the requirements tree to the appropriate grid.

·         The Impact Analysis tab helps you understand the many associations and dependencies that exist between the requirements by displaying them in a hierarchical tree structure. Unlike the Relationships tab, the Impact Analysis tab shows the affected requirements along with their parent and child requirements.

·         You can remove a traceability relationship link from the Relationships tab.

·         Risk-based quality management can assist you in determining testing strategy for your requirements. Risk-based quality management is available for Quality Center Enterprise Edition and Quality Center Premier Edition.

·         The risk-based quality management feature enables you to calculate at which level to test each requirement, based on the nature of the requirement and the resources you have available. You can then plan your testing process based on these recommendations.

·         Each requirement type can be enabled for risk-based quality management. Each requirement type with risk-based quality management enabled can support either risk analysis which is referred to as an analysis requirement, or an individual risk assessment which is referred to as an assessment requirement.

·         An analysis requirement is a requirement belonging to a type that represents higher levels in the requirements tree hierarchy, such as the Folder type. You perform risk analysis on an analysis requirement based on the assessment requirements under it in the requirements tree. The risk results of multiple assessment requirements are aggregated to give an overall risk analysis which can then be used to determine testing effort and test strategy.

·         An assessment requirement is a requirement belonging to a type that represents requirements that are children of analysis requirements and at a lower level in the requirements tree hierarchy. Assessment requirements under a particular analysis requirement form the basis for risk analysis on that analysis requirement.

·         You work with risk-based quality management in the Requirement Details view of the Requirements module. You can also work with risk-based quality management in the Risk view of the Requirement Details dialog box.

·         You can customize default settings for risk-based quality management.

·         Performing a risk-based quality management analysis for an analysis requirement involves the following steps:  Assess Requirements, Define Testing Policy Settings, Finalize Testing Policy, Analyze Testing Strategy

·         For each assessment requirement under the analysis requirement, you determine the Risk and Functional Complexity Categories.

·         The Risk Category is composed of two factors: Business Criticality and Failure Probability.

·         Business Criticality measures how crucial a requirement is for the business. It has three possible values: A - Critical,B - Important, and C - Nice to Have.

·         Failure Probability indicates how likely a test based on the requirement is to fail. It has three possible values: 1 - High, 2 - Medium, and 3 - Low.

·         The Functional Complexity Category indicates the complexity of the requirement’s implementation. It has three possible values: 1 - High, 2 - Medium, and 3 - Low.

·         After you determine the Risk and Functional Complexity Categories of the assessment requirements under an analysis requirement, you define the initial settings for testing the analysis requirement and the assessment requirements under it. These settings include how much time to assign to a requirement of a specific Functional Complexity were you to test it fully and how long it would take you to perform partial or basic testing on a requirement. You also decide which level of testing you want to perform on requirements for each Risk and Functional Complexity.

·         After you determine the testing policy settings, Quality Center calculates the total estimated testing time for the analysis requirement and the assessment requirements under it. You decide how much time you have to assign to test these requirements, and can then make adjustments to the testing policy to ensure that you have enough time to perform all the testing, and that no resources are wasted.

·         After you finalize how many resources to allocate to each requirement, you can view a report to analyze the conclusions you reached.

·         You determine the Business Criticality, Failure Probability, and Functional Complexity of a requirement by assigning them values directly or by assigning values to a set of criteria. If you do not determine these factors for a requirement, Quality Center does not include the requirement in the risk analysis. You can customize these criteria, their possible values, and how these values determine the Business Criticality, Failure Probability, and Functional Complexity. You can also customize how the Business Criticality and Failure Probability are used to calculate the Risk.

·         Quality Center can then calculate the total estimated development time for an analysis requirement and its children as the sum of the estimated development times of the children. Assigning the estimated development time is optional, and does not affect the risk analysis.

·         The time needed to test a requirement depends on the Functional Complexity of the requirement. A requirement with a high Functional Complexity generally requires more testing time as it is more likely that the requirement’s implementation contains defects. For each Functional Complexity, you define the Testing Time needed to fully test a requirement with that Functional Complexity

·         Quality Center defines four Testing Levels: Full, Partial, Basic, and None.

·         For  partial and basic testing, you define how much Testing Time is required for a requirement as a percentage of full testing.

·         A requirement whose Testing Level is set to None is not tested at all, and the Testing Effort is zero.

·         Based on the testing policy you defined, Quality Center can calculate the total estimated testing time for the analysis requirement and the assessment requirements under it. You estimate how much time you have available to test these requirements and make adjustments to the testing policy to make sure that the testing time required does not exceed the testing resources

available.

·         Total required testing time. Displays the total calculated time required to test all the assessment requirements under the analysis requirement matching the current filter and included in the risk analysis.

·         Total required development time. Displays the total time required to develop all the assessment requirements under the analysis requirement, based on the required development time you optionally estimated for each assessment requirement.

·         No. of Requirements per Risk Category graph. Displays the number of sub-requirements of the analysis requirement of each Risk Category.

·         Total Testing Time per Risk Category graph. Displays the total calculated testing time required to test all the requirements of each Risk Category.

·         The missing assessment link displays the requirements for which you did not determine a category or exclude explicitly from the analysis. Verify that there are no requirements that should be assigned a category. If you do not want to include a requirement in the analysis, then exclude it from the analysis explicitly.

·         If the resources you have available are not sufficient to test the requirement according to the current settings, you can reduce the Testing Level for a Risk Category, or reduce the Testing Time assigned to each Testing Level, and perform the calculation again.

·         After you have finalized your testing policy for an analysis requirement, you can analyze the testing strategy for the analysis requirement and for the assessment requirements under it. The analysis results are only valid for the requirements at the time the analysis was last performed. If you subsequently modify the Risk or Functional Complexity Categories of the requirements, or the testing policy, you should re-perform the analysis.

·         After you have finalized your testing policy for an analysis requirement, you can generate a report detailing your testing strategy. The report is saved as a Microsoft Word document in a specific file directory. It can also be saved as an attachment to the analysis requirement. To generate the report, Microsoft Word and Excel must be installed on your machine.

·         After you have finalized your testing policy for an analysis requirement, you can analyze its effect on the assessment requirements under the analysis requirement.

·         Based on analysis requirement. Displays the analysis requirement on which the last analysis that included the current requirement was performed. You can click the analysis requirement’s name to go to the analysis requirement in the requirements tree.

·         Last analysis on date. The date on which the last analysis that included the current requirement was performed.

·         Overall Risk Assessment. Calculates the risk based on the Business Criticality and Failure Probability for the requirement.

·         Calculated Testing Level. The level at which to test the requirement, as calculated in the last analysis that included the current requirement.

·         Calculated Testing Time. The time allocated to test the requirement, as calculated in the last analysis that included the current requirement.

·         Date last saved - The date on which the risk analysis was last performed.

·         Filter - The filter used to determine which requirements were included in the risk analysis.

·         Processed - The number of requirements included in the risk analysis. Also provides a breakdown of which requirements had assessment, which were missing assessment, and which were not assessable.

·         Total required testing time - The total time required to test the requirements included in the risk analysis, according to the testing policy you determined.

·         Total allocated testing time - The total time allocated to test the requirements included in the risk analysis.

·         Total required development time - The total time required to develop the features defined by the requirements.

·         No. of Requirements per Risk Category - A graph displaying a breakdown of the number of

requirements by their Risk Category.

·         Total Testing Time per Risk Category - A graph displaying the total time needed to test all the requirements of each Risk Category.

·         Implemented testing policy - The time necessary to test requirements belonging to each Risk Category, according to the testing policy used in the risk analysis.

·         Analyzed requirements - A list of the requirements included in the risk analysis which had assessments, together with their Risk Category, Testing Level, and Testing Time.

·         Requirements with missing assessments - A list of the requirements included in the risk analysis which did not have assessments.

·         Not assessable requirements - A list of the requirements that cannot be assessed. These may be requirements explicitly excluded from the analysis, or requirements belonging to a type that does not support risk-based quality management.

·         Based on analysis requirement. Displays the analysis requirement on which the last analysis that included the current requirement was performed. You can click the analysis requirement’s name to go to the analysis requirement in the requirements tree.

·         Last analysis on date. The date on which the last analysis that included the current requirement was performed.

·         Overall Risk Assessment. Calculates the risk based on the Business Criticality and Failure Probability for the requirement.

·         Calculated Testing Level. The level at which to test the requirement, as calculated in the last analysis that included the current requirement.

·         Calculated Testing Time. The time allocated to test the requirement, as calculated in the last analysis that included the current requirement.