Search the Community
Showing results for tags 'multiple systems'.
-
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.