Bidirectional Traceability of Software Requirements

Requirement Traceability - Bidirectional traceability, what is Horizontal traceability; What is vertical traceability; Why is this required?.......... Similar questions are galore for any QA Engineer. See if this clarifies these doubts:

Following is the 'text' as is, on the terms 'Horizontal traceability' & 'Vertical traceability'
from different sources.

(1) Source: http://www.sei.cmu.edu/cmmi/faq/new-faq.html

In the Requirements Management (REQM) process area, specific practice
1.4 states, "Maintain bidirectional traceability among the requirements and the project plans and work products." Bidirectional traceability primarily applies to vertical traceability and at a minimum needs to be implemented both forward and backward (i.e., from requirements to end products and from end product back to requirements).

Vertical traceability identifies the origin of items (e.g., customer
needs) and follows these same items as they travel through the hierarchy of the Work Breakdown Structure to the project teams and eventually to the customer. When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.
Horizontal traceability is also important and is mentioned in subpractice 3, but it is not required to satisfy bidirectional traceability.

Horizontal traceability identifies the relationships among related items across work groups or product components for the purpose of avoiding potential conflicts. It enables the project to anticipate potential problems (and mitigate or solve them) before integration testing. For example, horizontal traceability would follow related requirements across two work groups working on two associated components of a product. The traceability across these two work groups enables the work groups to see when and how a change in a requirement for one of the components may affect the other component.
Thus, horizontal traceability enables the project to anticipate potential problems (and mitigate or solve them) before integration testing.
--------------------------
(2) Source:

Author: Tim Kasse
Title: Practical Insight into CMMI
Pg 153-154

Vertical traceability: Traceability `from requirements through the associated life-cycle work products of architecture specifications, detailed designs, Code, unit test plans, integration test plans, system test plans, so forth and back"

Horizontal traceability: refers to the traceability from the requirements to the associated plans such as the project plan, quality assurance plan, configuration management plan, risk management plan, and so forth
--------------------------------
(3) Source:

Author: Shari Lawrence Pfleeger
Title: Software Engineering - Theory & practice
Pages: 439-441

Vertical traceability expresses the relationship among parts of the workproduct. For example, vertical traceability of the requirements describes the interdependencies among the system requirements.

Horizontal traceability addresses the relationship of the components across collections of workproducts. For instance, each design component is traced code components that implements that part of the design

Quality Attributes for an Information System

Quality Attributes for an Information System

Correctness

The software system’s fulfillment of the specifications underlying its development. The correctness of a software system refers to:

• Agreement of program code with specifications
• Independence of the actual application of the software system.

The correctness of a program becomes especially critical when it is embedded in a complex software system.

Example 1.1 Let p be the probability that an individual program is correct; then the probability P of correctness of the software system consisting of n programs is computed as P = pⁿ .

If n is very large, then p must be nearly 1 in order to allow P to deviate significantly from 0 [Dijkstra 1972b].

Reliability

Reliability of a software system derives from

• Correctness, and
• Availability.

The behavior over time for the fulfillment of a given specification depends on the reliability of the software system.

Reliability of a software system is defined as the probability that this system fulfills a function (determined by the specifications) for a specified number of input trials under specified input conditions in a specified time interval (assuming that hardware and input are free of errors).

A software system can be seen as reliable if this test produces a low error rate (i.e., the probability that an error will occur in a specified time interval.)

The error rate depends on the frequency of inputs and on the probability that an individual input will lead to an error.

User friendliness:

• Adequacy
• Learnability
• Robustness

Adequacy

Factors for the requirement of Adequacy:

1. The input required of the user should be limited to only what is necessary. The software system should expect information only if it is necessary for the functions that the user wishes to carry out. The software system should enable flexible data input on the part of the user and should carry out plausibility checks on the input. In dialog-driven software systems, we vest particular importance in the uniformity, clarity and simplicity of the dialogs.
2. The performance offered by the software system should be adapted to the wishes of the user with the consideration given to extensibility; i.e., the functions should be limited to these in the specification.
3. The results produced by the software system:
   The results that a software system delivers should be output in a clear and well-structured form and be easy to interpret. The software system should afford the user flexibility with respect to the scope, the degree of detail, and the form of presentation of the results.Error messages must be provided in a form that is comprehensible for the user.

Learnability

Learnability of a software system depends on:

• The design of user interfaces
• The clarity and the simplicity of the user instructions (tutorial or user manual).

The user interface should present information as close to reality as possible and permit efficient utilization of the software’s failures.

The user manual should be structured clearly and simply and be free of all dead weight. It should explain to the user what the software system should do, how the individual functions are activated, what relationships exist between functions, and which exceptions might arise and how they can be corrected. In addition, the user manual should serve as a reference that supports the user in quickly and comfortably finding the correct answers to questions.

Robustness

Robustness reduces the impact of operational mistakes, erroneous input data, and hardware errors.

A software system is robust if the consequences of an error in its operation, in the input, or in the hardware, in relation to a given application, are inversely proportional to the probability of the occurrence of this error in the given application.

• Frequent errors (e.g. erroneous commands, typing errors) must be handled with particular care
• Less frequent errors (e.g. power failure) can be handled more laxly, but still must not lead to irreversible consequences.

Maintainability

Maintainability = suitability for debugging (localization and correction of errors) and for modification and extension of functionality.

The maintainability of a software system depends on its:

• Readability
• Extensibility
• Testability

Readability

Readability of a software system depends on its:

• Form of representation
• Programming style
• Consistency
• Readability of the implementation programming languages
• Structuredness of the system
• Quality of the documentation
• Tools available for inspection

Extensibility

Extensibility allows required modifications at the appropriate locations to be made without undesirable side effects.

Extensibility of a software system depends on its:

• Structuredness (modularity) of the software system
• Possibilities that the implementation language provides for this purpose
• Readability (to find the appropriate location) of the code
• Availability of comprehensible program documentation

Testability

Testability: suitability for allowing the programmer to follow program execution (run-time behavior under given conditions) and for debugging.

The testability of a software system depends on its:

• Modularity
• Structuredness

Modular, well-structured programs prove more suitable for systematic, stepwise testing than monolithic, unstructured programs.

Testing tools and the possibility of formulating consistency conditions (assertions) in the source code reduce the testing effort and provide important prerequisites for the extensive, systematic testing of all system components.

Efficiency

Efficiency: ability of a software system to fulfill its purpose with the best possible utilization of all necessary resources (time, storage, transmission channels, and peripherals).

Portability

Portability: the ease with which a software system can be adapted to run on computers other than the one for which it was designed.

The portability of a software system depends on:

• Degree of hardware independence
• Implementation language
• Extent of exploitation of specialized system functions
• Hardware properties
• Structuredness: System-dependent elements are collected in easily interchangeable program components.

A software system can be said to be portable if the effort required for porting it proves significantly less than the effort necessary for a new implementation.

Guidelines for Project Kick Off

Guidelines for Project Kick Off

COM/INI/G/01

Version 01

	Author / Owner	Approved By	Issued By
Designation	MR	COO	MR
Signature
Date

This document and the information contained herein are confidential to and the property of ABC Technologies Private Limited, and are made available to ABC employees and others acting on behalf of the company for the sole purpose of conducting ABC’s business.

Revision History

Version No.	Date	Section No. Changed	Change description
01	01/11/2008	All	First Release

1 PURPOSE

The purpose of a kick off (PREVIEW) is to prepare the team for the activity about to be undertaken. During the preview, the team members will come to agreement on the details of the activity about to be undertaken. A preview gives a chance to look ahead, to identify major areas of risk in the next phase, and generally to assess the upcoming activities.

2 When to conduct a preview

At a minimum, previews shall be conducted by a project at the commencement of each major project activity. Additional previews may be held at any time benefit may be gained – for long duration activities periodic previews should be conducted as appropriate. Previews are of most value when they are conducted as close as possible to the commencing of the activities being previewed.

3 Inputs to previews

In order to conduct a complete and successful preview the following inputs must be available :

• Folder of all documents relating to the project
• Project plans and any related documents
• Estimates for the activity being previewed
• Project metrics and organizational baseline metrics
• Project closure reports from other projects carrying out similar activities and any previous project post-mortems.
• Relevant organizational metrics
• Any standards which are to be followed

4 Attendees

• Project Manager
• Project Team. One member of the project team shall act as the meeting minutes taker.
• SEPG Member

5 Preparation

Each team member attending the preview shall prepare for the preview. In order to prepare, read through the suggested agenda below and make notes.

In addition gather the necessary inputs for the preview. The project leader shall assign a minute taker for the meeting.

6 Preview Meeting

The SEPG member shall act as facilitator for the preview meeting. Below is the suggested agenda for the preview meeting. The project team should also discuss any other issues pertinent to the success of the activity being previewed.

6.1Team Objectives

The project manager and project leader shall summarize the objectives of the activity about to be undertaken.

§ Purpose of the activity

§ Milestones

§ Expected deliveries to the customer and other expected outputs

6.2Detailed Planning

Examine the overall project plan and any other proposed plans, answer the following questions.

• Estimates
• Are the estimates for size, effort, schedule etc. appropriate?
• Can the estimates be justified in comparison with baseline metrics?
• Can the team members commit to the estimates?
• Do the estimates need to be revised?
• Detailed Schedule
• Does the detailed schedule cover all activities, which need to be performed?
• Does it make adequate allowance for training, staff absence, etc.?
• Does the schedule have a relationship with the estimates?
• Does the schedule need to be revised?
• Critical Path
• Are all team members aware of the critical path?
• Are team members on the critical path aware of their responsibilities?
• Is there a strategy for dealing with delays on the critical path?
• Configuration Items
• Are the configuration items for the forthcoming activity defined?
• Are the defined configuration items appropriate?
• Is any pre-existing or third party material intended to be included or used?
• If so, has formal, written permission been obtained and placed on record in the project folder?
• Peer Reviews
• Are the artifacts to be peer reviewed determined?
• Is the level of peer review appropriate?
• Are reviewers external to the project required?
• Is there a strategy for conducting the necessary peer reviews?
• Has a schedule for peer reviews been determined (this can be refined at the weekly meeting)?
• What special perspectives need to be considered – performance, interfaces, etc.?
• Customer Issues
• Do you expect the customer to have an effect on the project team?
• Positive or Negative effect?
• What strategies are there to reduce any negative impact the customer may have?
• Are the project requirements expected to be volatile?
• What strategies are in place to handle requirements changes?
• Are the strategies adequate?
• Are the acceptance criteria for all customer deliverables clearly defined?
• Are the acceptance criteria achievable?
• System Requirements
• Do you have all the system requirements available in order to execute the plan successfully?
• Have you discussed with system administration department whether the lead-time you have given is adequate for any installations?
• Have you identified the machines you would be running CPU intensive operations, like testing?
• Have you verified that they would be available to you when needed?

It is the role of the project manager to revise the project plans as necessary following the preview.

6.3Methods, Tools and Standards

From the knowledge of the methods, tools and standard proposed and by looking at previous project experiences answer the following questions.

• Methods
• What methods are to be used for the upcoming activity?
• Are the methods appropriate?
• Are there any known weaknesses in the method?
• Are the team members sufficiently trained in the method?
• Is any training required?
• Standards
• What standards are to be used for the upcoming activity?
• Are the standards appropriate?
• Are there any known weaknesses in the standards?
• Are the team members sufficiently versed in the standards to use it?
• What are the notation and naming conventions to be used by the team?
• Are these conventions appropriate?
• Is training related to any standards required?
• Tools
• What Off-the-shelf tools are to be used for the upcoming activity?
• Are the tools appropriate?
• Are there sufficient licenses to accommodate the project team?
• Do the tools require special hardware or administrative support?
• Are there any known weaknesses or defects in the tool?
• Are there any workarounds for the weaknesses or defects?
• Are the team members sufficiently trained to use the tool?
• Is any training required?
• Have mentors been identified within the project or within ABC?
• Are there any tools available in the ABC tool library, which would be useful for the upcoming activity?
• Will the project need to develop any tools to support the upcoming activity?
• Has sufficient time been allocated for the development?
• Are the requirements for the tool well defined?
• Has a quality goal for the tool been determined?
• Traceability
• What method for maintaining Traceability will be used?
• Is the method appropriate?

6.4Software Production Process and Tailoring

Compare the proposed plan to the software production life cycle model selected. From this comparison, your experience, and experience of previous projects, answer the following questions.

• Tailoring
• Are there any deviations from the software life cycle model in the project plans?
• Are these deviations appropriate?
• What is the intended purpose of any deviation?
• If the purpose of the deviation is to increase quality, decrease cycle time, or reduce effort required, give an estimate of the expected effect.
• Software Life Cycle Model
• Will any untailored component of the software life cycle model cause difficulty for the project?
• Should they be tailored?
• Document the project tailoring in the preview report and project plans.

6.5Defect Prevention

The purpose of this section of the meeting is to make the project team aware of the common causes of errors, which occur during the upcoming activity.

• Make the team aware of the common errors that need to be prevented during that phase.
• Prepare the list of error categories specific to the project and that phase, if required.
• Present the projected errors for that phase and discuss methods for prevention. Document any defect prevention strategy devised, ensure that all project team members are aware of the strategy and able to implement the strategy.

6.6Reuse

By looking at what will be developed during the upcoming activities answer the following questions.

• Reuse by the project
• Are there any components in appropriate libraries suitable for reuse by the project?
• Are the components documented sufficiently to allow for efficient reuse?
• Is there a plan for reusing the components?
• Development for reuse
• Are there constraints from the customer, which would preclude the reuse by others of components developed by the project?
• Are there any components to be developed which would be suitable for reuse within ABC?
• Would any extra effort be required to make the components reusable?
• Can the project afford the extra effort?
• Is the extra effort factored into the estimates and schedules?

6.7Risks

Examine the risks listed in the proposed plan, answer the following questions.

• Management Risks
• Are all known management risks listed?
• Are there any other risks?
• Are the impacts of the risks determined?
• Are the risk mitigation strategies adequate and sensible?
• Is the frequency of tracking of risks adequate?
• Technical Risks
• Are all known technical risks listed?
• Are there any other risks?
• Are the impacts of the risks determined?
• Are the risk mitigation strategies adequate and sensible?
• Is the frequency of tracking of risks adequate?
• Dependencies
• What are the external dependencies of the project?
• Are any of the dependencies likely to become critical?
• Are there any strategies to lessen the impact of dependency slippage?

6.8Configuration Management

Examine the proposed plans and from your knowledge of configuration management and by looking at previous project experiences, answer the following questions.

• Individual configuration management strategy
• Is the CM strategy for individuals defined?
• Is the strategy sufficient to guarantee the integrity of project configuration items?
• Is the strategy adequate to support the required project activities?
• Is the strategy easy to understand and implement?
• Project configuration management strategy
• Is the CM strategy at the project level defined?
• Is the strategy sufficient to guarantee the integrity of project configuration items?
• Is the strategy adequate to support the required project activities?
• Is the strategy easy to understand and implement?
• Are the baselines adequate to support the required project activities?
• Are all baselines defined?
• Is the change process adequately defined?
• Is the change process understood by all team members?
• Are the mechanisms for releasing artifacts to the customer understood by all team members?

6.9Project Goals

Examine the proposed project goals in the light of your experience, any metrics for the current project or metrics for projects in similar domain and the ABC’s organizational baseline metrics, answer the following questions.

• Product Goals
• Are goals for the product established (e.g., on-time, functionality, performance goals)?
• What is the basis for the setting of the goals?
• Are these goals achievable?
• Are there strategies in place to assist in achieving the goals?
• Do all team members commit to the goals?
• Process Goals
• Are goals for the process established (e.g., 100% requirements tested, estimates within 10%)?
• What is the basis for the setting of the goals?
• Are these goals achievable?
• Are there strategies in place to assist in achieving the goals?
• Do all team members commit to the goals?

7 Preview Measurements

The preview report shall include the following measurements.

• Total preparation time for the preview (Person Hours)
• Number of attendees at the preview
• Effort expended on the preview meeting (Person Hours)

The measurements will form part of the measurement of organizational defect prevention activities.

8 Outputs

The output of a preview meeting is a preview report. The report shall contain:

• The minutes of the preview meeting
• The required preview measurements
• Any actions and responsibilities there of arising from the preview