2

If an organization is regulated, it has pass the audit and show that it has implemented a "requirements traceability". Which means it has documented the path from specific requirement to a code change to a working product in production. At least that is how I understand it.

How does this work in Agile/Scrum? Currently, only way I saw this is implemented is as follows:

  1. Any change, no matter how big or small, needs to have a ticket in an tracker, like Jira.
  2. This ticket needs to have all the necessities of a specification, before it gets implemented.
    • This means things like detailed acceptance criteria and time estimates.
  3. When implemented, changes to the code must include the tracker ID of the requirement. Either in commit itself or in reviewed pull request.
  4. The ticket in tracker must follow a pre-defined process of steps from Grooming, In Dev, In QA and finally into Done.

As an XP person myself, I find this extremely stifling. If I were to find a place to make an improvement, I would need to go through that whole process to get it implemented. This process can easily take days or even weeks(I mean in real time, not effort time, lots of time waiting between grooming, planning and implementation). Even when the change itself might take 30 minutes. I understand the need for this kind of documentation, but I'm not versed enough in this specific law to be able to figure out if this is acceptable or not.

Is my understanding of this problem correct? Are there any other ways to implement requirements traceability for regulated organization that doesn't have such big overhead? Or is this something I should learn to live with?

4

Your understanding of traceability is correct. The idea is to trace functionality from the source to the implementation and deployment in order to determine if the system implements the required functionality.

Any change, no matter how big or small, needs to have a ticket in an tracker, like Jira.

This is somewhat correct. Tools like Jira that have integration with version control systems and documentation tools make traceability easier because of those integrations, but traceability doesn't require specific tools. Conceivably, you can keep requirements in a document or spreadsheet and use unique IDs to trace to commits and pull requests.

This ticket needs to have all the necessities of a specification, before it gets implemented. This means things like detailed acceptance criteria and time estimates.

The level of specification in the work item varies. Estimates are not required for requirements traceability at all. I would expect that the issue in the issue tracking system would be self-contained and provide easy access to things like the acceptance criteria, either by inclusion or reference. I would consider the characteristics of good requirements and the INVEST criteria.

When implemented, all changes to the code must include the tracker ID of the requirement.

This is not typically a requirement. For example, Jira gives each issue a unique ID. Jira also allows for linking the issue to the pull request and the pull request back to the issue(s). The linkage is what is important. If you can look at a line of code, find the commit that introduced it, go to the commit or pull request where it was added, and find the issue that represents the requirement for that work (and the other way, from requirement to lines of code), traceability is satisfied.

The ticket in tracker must follow a pre-defined process of steps from Grooming, In Dev, In QA and finally into Done.

Although this is helpful, the workflow in the issue tracking system should reflect the actual process and be useful to the team. Tools like Jira maintain a history for each issue - who updated what fields, comments and discussion, linkage between related issues to show dependencies and decomposition.

As an XP person myself, I find this extremely stifling. If I were to find a place to make an improvement, I would need to go through that whole process to get it implemented. This process can easily take days or even weeks. Even when the change itself might take 30 minutes. I understand the need for this kind of documentation, but I'm not versed enough in this specific law to be able to figure out if this is acceptable or not.

Is my understanding of this problem correct? Are there any other ways to implement requirements traceability for regulated organization that doesn't have such big overhead? Or is this something I should learn to live with?

If you're using tools appropriately and correctly configured tools that facilitate the process, I don't see why requirements traceability should take "days or even weeks". Depending on your choice of tools, some aspects of the traceability can just "fall out" of the way that you use the tools.

  • The last sentence sounds to me like : "If you do things effectively, they will be effective." Not much helpful. But thanks for answer. You seem to agree with my last assertion that this is something that is necessary and something I should live with, yes? – Euphoric Jan 27 at 15:45
  • 2
    @Euphoric It's more like "if you configure your tools effectively, they can support your process instead of hindering it". Traceability is required, but it doesn't need to be painful. I'm having trouble imagining a situation where you need to wait days or weeks to establish traceability. Seems like their may be waste or inefficiencies in other processes. – Thomas Owens Jan 27 at 16:01
  • 1
    I see the issue with desirable code changes (refactoring, removing technical debt) that are not triggered by customer requirements. You need to have an agreement with the customer that as part of ongoing code maintenance, these technical requirements will come up and will be handled like customer requirements. This needs a certain level of trust in the dev team that they don't inject undesirable changes camouflaged as necessary refactorings... – Hans-Martin Mosner Jan 27 at 18:53
  • @Hans-MartinMosner There are two ways to handle it. One is consider it standard business - as you are developing new features, you can refactor around it. Of course, you'd want to stay focused on the areas that are affected by the requested change. The other would be to enter a work item / ticket / issue to perform a set of refactoring and treat that just like a customer requirement that is delivered independently. – Thomas Owens Jan 27 at 19:01
1

Behaviour Driven Development (BDD) can be a neat way to reduce the overhead of requirements traceability.

The approach is as follows:

  • Requirements are generated by the stakeholders/Product Owner
  • The 'three amigos' (representing business, development and testing) get together and create features and scenarios that correspond and flesh out the requirements
  • Typically tests are written to confirm that the functionality has been implemented

Using this approach it is relatively simple to add requirements traceability.

You can argue that the self-documenting nature of BDD is sufficient or you may still need to add in IDs if your organisation requires it.

There is still effort involved of course, but it is useful effort that helps to produce fleshed out requirements, to allow for thorough regression testing and to produce self-documented code that is easier to work with.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.