What's the best way to link formal specs to JIRA enchancement requests?

Question

What's the best way to link formal specs to JIRA enhancement requests?

I want to track changes to specifications using JIRA.

Ideally, I'd like to refer to a functional ID reference in a JIRA ticket (e.g. MYAPP>APPROVAL LOGIC>MAIN SCREEN), so that program managers can retrospectively categorise defects.

The reason for this, is so that QA scripts and documentation tickets can be searched/categorised meaningfully in the tracking system.

There seems to be a million possible ways to do this, e.g.

• should I write a custom component to select functional IDs from a tree?
• should I write the specs in confluence, or another CMS with a TrackBack facility?
• should I include a link to the documentation URL?
• should I use some other 3rd party plugin application?
• should I use some Atlassian application that i'm unaware of?
• am I using the wrong tracking tool/process to measure spec growth?

What's the best way, in your experience?

Answer 1

1. If you can afford to write the specs in Confluence, then I think using cross-links between Jira and Confluence is the best way. There are several plugins that implement such links (eg Application Links).
   • Since the Confluence page must be unique within the space, the hierarchical naming that you show above would be appropriate.
   • Confluence is a good tool for collaborative development of documents, but it takes a lot of discipline, organization and effort to keep things organized.
2. Alternatively, you can use the Labels jira plugin to tag issues with strings such as "myapp-approvalLogic-mainScreen". This lets you quickly find all related issues, but not to navigate to the spec
3. Neither of the approaches above provides a hierarchy though.
   • Jira+Agile (aka Greenhopper) provides a hierarchy of Versions which is very useful for agile planning. But typically one version (release) works on features from many requirements, so you probably cannot use this hierarchy
   • Jira components are not hierarchical, and issues are at only 2 levels (a problem that's been discussed for 4 years...)

Answer 2

Thanks for the reply!

There is another option that I'm considering, which is to implement the functional requirement as an actual ticket.

This makes a lot of sense (to me at least), because a functional requirements have owners, a lifecycle, and a clear concept of sub tickets for simple enhancements etc. The ability to link issues allows it to be connected to QA activities, documentation tickets, or any other kind of work. Functional requirements also link together, so the model fits.

The problem with this approach, is that unless you want to create every defect ticket as a sub-task to a requirement (and forgo additional subtask functionality), you have to create, and then link the ticket, using the standard 'link ticket' functionality, which isn't very quick to use. This is a high resistance workflow, which means it requires a lot of discipline.

I'd ideally like to be able to create a ticket, that is automatically linked to another ticket, similarly to the functionality of linking a sub ticket.

I can't be the first person to want to do this - I don't suppose you know of anyone who has tried this that you know of, or released a tool to making this easier?