nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Requirements engineering with fine-grained traceability - how do I do this with Jira/Confluence?

Martin Grill

The combination of out-of-the box installations of Jira/Greenhopper and Confluence already supports most activities along our standard software product lifecycle.

The last big gap is in the area of requirements engineering, and this is unfortunately preventing a more widespread use of Jira.

Our requirements are usually fine-grained, and the solutions we have looked at so far (primarily zAgile Wikidsmart and RMsis) do not seem to support this fine level of detail, but appear to be more geared towards "coarser" entities (requirements).

While tracking requirements as individual Confluence pages (each page a couple of screenfuls long, and containing subsections such as "Preconditions", "Rationale", "Detailed Description") might work for many projects, our development process (ISO/IEC 15504 "Spice" compliant) requires us to capture requirements pretty much on a sentence-by-sentence (or statement-by-statement) level. This is in large parts due to the fact that we need to ensure 100% test coverage, i.e. each statement (=fine-grained requirement) will give rise to at least one test case, and changes to each individual statement need to be tracked (down to source-level) and analysed.

This used to be the domain of the Requirements Engineering heavyweights such as IBM Doors or MKS/Integrity. Maybe it still is.

What solutions do others use? Has anyone found a viable solution to track such fine-grained requirements from inside the Atlassian ecosystem?

Accepted answers

Kinto Soft

Hi Martin,

If working with pages in Confluence is not good for you because you need work with sentences and if your original requirements are also in MS Word or PDF documents, then the DocMiner add-on can provide you a solution for:

our development process (ISO/IEC 15504 "Spice" compliant) requires us to capture requirements pretty much on a sentence-by-sentence (or statement-by-statement) level

DocMiner allows to capture requirements directly from documents sentence by sentence in a graceful way. It also keeps the traceability from the issue on JIRA to the sentence in the document. (VIDEO)

we need to ensure 100% test coverage, i.e. each statement (=fine-grained requirement) will give rise to at least one test case,

Well, DocMiner does not does it in an automatic way. But I (the author) could add a flag: if marked, then automatically create a test case and link it to its requirement parent for each requierement captured on a document. But honestly, I need to think more on this.

On the other hand, currently, DocMiner helps projects to ensure no any statment has been ommited: users can see capured issues embedded in documents and related to the sentece, so if a sentence has been ommited you can see it beacuse no issue is related to it while you read the document. Moreover, (I think there are also other plugi-ins that can help you here) DocMiner provides a treaciblity tree for the entire document, so you can use this that feature to identify the requiremets not linked to test cases. And do it from a single point.

and changes to each individual statement need to be tracked (down to source-level) and analysed

This it also 100% supported by DocMiner. The impact view provides those tracebility from the top requirement toward its children: requirement->test case->bug... (VIDEO)

As I say, the pre-requisite to use DocMiner is that your requirements must be in documents. It has also provides some advantages: you can deal with versions, compare them, see how changes in the new version impact on your current requirements and deal with that. Please, see the videos on the plugin page.

Pablo.

All comments

Kinto Soft

Hi Martin,

our development process (ISO/IEC 15504 "Spice" compliant) requires us to capture requirements pretty much on a sentence-by-sentence (or statement-by-statement) level

we need to ensure 100% test coverage, i.e. each statement (=fine-grained requirement) will give rise to at least one test case,

and changes to each individual statement need to be tracked (down to source-level) and analysed

This it also 100% supported by DocMiner. The impact view provides those tracebility from the top requirement toward its children: requirement->test case->bug... (VIDEO)

Pablo.

Martin Grill

Hi Pablo.

DocMiner seems like a nice tool, thanks for making me aware of it.

However, in our case, tracking requirements "sentence by sentence" also means that we need to make sure we track changes to the requirements themselves, not just changes to the artifacts they relate to.

For example, we would start with revision 1.0 of the requirements document, and would eventually receive/create revision, say, 1.1. All changes from 1.0 to 1.1 need to be tracked. I don't think this is something that can be achieved with DocMiner, although it is certainly an interesting step in the right direction (and I'm sure there are lots of applications where DocMiner's functionality is exactly what is needed).

Any other suggestions/recommendations, anyone?

Thanks

Martin

Kinto Soft

Hi Martin,

That is just one of the strongest features provided by DocMiner: it can track modified sentences across document revisions and identify the requirements (JIRA issues) impacted by those modified sentences. And provide such information in seconds and even in the go (from your mobile device) and fully integrated with JIRA and without mistakes.

For example, you can create a requirement X from the revision 1.0. Then compare boths revisions from DocMiner and see the impact of the revision 1.1. Then you could create anew issue Y ("improvement", for instace) from the revison 1.1 and link it to the original requirment (Y->X) on JIRA.

DocMiner will care about all the traceability details:

When you open the improvement Y on JIRA, DocMiner will show it on the revision 1.1 of the document.
If you open the requirment X, DocMiner will open the revision 1.0.
When you open the impact view (no matter the revison) you see: "The improvement Y impacts on the requirement X" if you are seeing the impact view from the revision 1.1. Or "the requirement X is impacted by the issue Y" if you open the impact view from the revision 1.0

I don't know if the following will help or will introduce more confusion... I will release a new JIRA plug-in (it's pending Atlassian approval): link to video. It provides traceability across linked issues. Just that plug-in is part of DocMiner, even more integrated for documents.

Regards,

Pablo.

Martin Grill

I'm going to have to give this an in-depth try. Certainly sounds promising.

-- Martin

JFT

Hi Martin, What you can do is define a new Issue Type in JIRA that is called: Requirement Then, you can create an issue (with issuetype = Requirement) for each fine-grained requirements in your project (exactly as you would do it in MKS or IBM Doors). For this new issue type, you could also create some specific custom fields like, requirement type, preconditions, rationale, etc. I would use Confluence to create your Requirements Specification documents. These documents would include all the boiler plate stuff, sections, diagrams/pictures and obviously your requirements. But instead of re-typing the requirements, you would include them as JIRA object in the Confluence page (using the JIRA insert issue macro or the AJIIM macro http://bit.ly/1kwt9uJ that was specially developed for this purpose and that can even show traceability). Back in JIRA, you can also define multiple levels of requirements (i.e.: User, system, software, etc.) and link them together using the issueLinks. The Impact plugin (http://bit.ly/1tYPzxu) can then let view your visualize your project traceability in a fully configurable tree view. This is ideal for impact analysis, finding requirements without tests (i.e ensuring that you have 100% test coverage), etc. By linking the issues to Stash/Git/SVN commits, you can even do your impact analysis down to the code. Obviously using other JIRA functionalities, you can also create project management dashboards, generate reports/documents, implement your requirements in an Agile manner, etc. All this bring you close to what you would do in MKS or IBM Doors.

Erez Kaminski -Ketryx-

Hi Martin!

Requirements Management (RM) in Jira is a major hurdle— Jira was created as an issue tracker, not a RM system. Turning it into one, is time-consuming and complex and is something a lot of teams building validated products struggle with. The 100% test coverage is a critical aspect of medical software development, that is foreign to most dev teams!

You can string together many different add-ons to do this, but this would lead to another complex lifecycle to manage, instead of less work.

We recently released Ketryx to the Atlassian Marketplace to solve this exact issue. By connecting Ketryx to your Jira instance, it automatically creates all the needed structure, traceability, and documentation needed by safety-critical regulations like ISO/IEC 15504 “SPICE”, IEC 62304 (medical device software lifecycle management), or DO-178C (Software Considerations in Airborne Systems and Equipment). We designed it, so you can continue developing in Jira and maintain all of your traceability and documentation simultaneously. It might be worth checking out to see if it’s a solution that works for you. Best of luck!

You can find the Ketryx app on the Atlassian marketplace here.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

jira

requirement