Skip to content
mainlogo star-rating mail call call-button cart
    Share this post

    Requirements traceability : What, why and how

    Written by:             Published on: Apr 5, 2018 12:00:00 AM

    Become an in-demand BA in 6 months or less!

    Talk to our Learning Advisor Today

    Traceability is one of the lesser understood aspects of business analysis. It is indeed quite hard to maintain good traceability unless automated. This is why BABoK® warns us being theoretical about traceability.

    In this article, I would like to explain traceability concepts with help of an example.

    BABoK® definition of traceability:

    Traceability is the ability to look at a requirement and others to which it is related, linking business requirements to stakeholder and solution requirements, to artifacts and to solution components.

    Traceability identifies and documents the lineage of each requirement, including its backward traceability (derivation), forward traceability (allocation) and its relationship to other requirements.

    Traceability ensures that the solution conforms to the requirements. It also helps in managing scope, risk, time, requirements changes, cost and communication. It can be used to detect missing functionalities or to identify whether the implemented functionality is supported by a specific requirement.

    Reasons for creating traceability are:

    Assist in impact analysis for requirements changes.

    Ensure requirements coverage: Understand how business objectives are implemented. Business objectives not traced to detailed components have not been analyzed and hence not included in the solution.

    Requirements allocation.

    Relationships

    Derive

    When one requirement is derived from the other. Stakeholder requirements are derived from business requirements. Solution requirements are derived from stakeholder requirements.

    Depends

    One requirement can be implemented only if the other has been implemented or easier to implement if the other is implemented.

    Satisfy

    Relationship between an implementation element and the requirements it is satisfying.

    Validate

    A relation between a requirement and its test case to validate whether the solution fulfills the requirement.

    Let’s take a practical example of a requirement to list all products on an eCommerce store (such as AdaptiveUS.com/eStore)

    Example Requirement:

    To list products on the ecommerce portal with their price.

    Derived from (Parent requirement)

    The requirement "To list products on the ecommerce portal with their price." is derived from the parent business requirement. "Enable e-commerce for business."

    Dependent requirement (Prerequisite)

    The requirement "To list products on the ecommerce portal with their price." requires payment functionality to be available. Without payment functionality, this requirement has little value. Hence, the requirement "The requirement "To list products on the ecommerce portal with their price." is dependent on the requirement, "Payment gateway to collect payment from customers."

    Satisfied by (Allocated to Solution component)

    Store front end solution component implements the requirement, "To list products on the ecommerce portal with their price." Hence here the relationship is of type, Satisfy.

    Validated by (Tested by test component)

    Test cases to test store functionality validate the requirement "To list products on the ecommerce portal with their price." Hence here the relationship is of type, Validate.

    This is a simple template to capture requirements traceability. You may transpose the same to handle multiple requirements in the template.

    If you still have any questions on the topic, do comment below.

     

      Previous Next  

    Related Posts

    Write Comment

    Write Comment