Monday, December 15, 2008

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 = pn .

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.