Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Very Popular

    How to work with requirements that span multiple systems

    Jimi Wikman

    When working with requirements, there can be situations where a requirement in one system can create new requirements on other systems. This can happen for example when you have requirements that touch on data that flow through integrations.

    For example, we can take a scenario where we have an e-commerce system that update their product data with a new field called hazardous products. This new field needs to be added to the integration to the transport system, since items marked as a hazardous product need special form of transportation.  The way the system is set up, there is a message broker between the E-commerce system and the transport system that handle the transformation and flow of data between the systems.

    So we need to create a task for the E-commerce system to add the new data. We also need to add a task to update the integration and the integration contract between the E-commerce system and the message broker. These changes also require a task for the message broker and one for the transport system. So we will have three stories in Jira that will live in three different Jira Projects. This is not ideal and in order to keep track of the whole requirement so we also know when to conduct our end-to-end test, we create an Epic for this in the E-commerce Jira project. Then we connect the stories in the message broker Jira Project and the story in the transport Jira project.

    The E-commerce system own the requirement that is logged in their Confluence, and in this situation they are also responsible for driving the requirement towards the message broker and transport systems. Both the message broker and transport systems will update their documentation and their integration contract based on these new requirements, just as they would for any other requirement made to their system. If it makes sense for the dynamic between the three systems, the message broker and transport systems may add requirements to their Confluence as well.

    How to work with requirements that span multiple systems.jpg

      This works for integrations and between systems, but we also need a setup for temporary situations like projects and programs.

    Discuss the Guide

    Recommended Comments

    There are no comments to display.

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Latest Updates

  • Create New...