Tracking requirements across multiple projects with JIRA (or other tools) [closed]_问答_开发者

Closed. This question needs to be more focused. It is not currently accepting answers.

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

My company has been using JIRA as a requirements tracking tool as well as a bug tracker, and it's been working pretty well while we've been working on one project at开发者_开发知识库 a time.

We now have a scenario where we have three different project proposals whose requirements partially overlap (e.g. requirement 1 applies to projects A and B, requirement 2 applies to projects B and C, etc.). I'd like to be able to enter a single JIRA issue for each requirement, but that doesn't appear to be possible since JIRA issues and projects have a one-to-one relationship.

Has anyone found a way to do this in JIRA, or maybe with some other tool that integrates with JIRA ?

While there's no single correct answer, I can offer an idea. I don't have enough information about your work process, but you mention that you have project proposals. So I'm assuming projects A, B and C are in early stages. Requirements gathering and such, no bugs yet.

Set up a single JIRA project, say, "Early Requirements". Put all the requirements for projects A, B and C into that JIRA project. To allow many-to-many relationship between requirements and real projects, set up a custom field of type "multiple checkboxes" or equivalent, and configure "project A", "project B" and "project C" as its values. For any requirement you can check which project it applies to.

Now - and I am making more assumptions here - let's say some proposals move on and some die away. You will need a process to a) extract all the requirements for real project A into a newly created JIRA project for A - this can be done via search & bulk clone issue; b) purge all requirements that have no live project associated with them - search & bulk delete.

Caveats: if you need to share requirements with different customers, it will get tricky. Permissions are configured per JIRA project & issue type.

Having said all that, JIRA lacks features for decent requirements management, such as baselines and traceability. But it may be ok for just collecting data for further work.

We use the "duplicates" or "relates to" function of jira.

So you raise an issue in each project, but you relate them together. That way you can have one issue "owned" by a project and you can close out all related projects once the changes are tested on each.

You could even use depends on linkage if this makes sense in your project setup.

We have the same problem. In the case where you have an issue (a bug or new feature) which involves multiple products and that have dependencies between them. (As an example lets say we have a server, a connection api and a client application). If there is a new idea about extending the client application in a certain way, it is quite possible that also the connection api and server need some kind of extension. Probably they are developed by different teams... So not handled in the same sprint / iteration, but as a product owner you want to keep track of all these new features as a group.

What we did was actually created a few custom fields. The first field we introduced was a 'Cascading Select', as 'Program' and 'Phase'. This gives the product owners the possibility to group the issues under a program and do some rough long term planning (several iterations).

Then we added another field (Text Field) for 'Epic' (or 'Theme') this bundles the issues related to a certain Epic / Theme. The idea is to use 'Epics' within a 'Program'. In case of an larger 'Program', you can probably separate it into different parts, which then get reflected in these 'Epics'. (A kind of storyline. A group of stories (which can spread over multiple products) which add value as a hole to the series of products).

Both fields make it now easy to filtering out issues, that cross multiple products, based on Program (with or without its Phase) and the Epic.

Indeed with linking enabled, you can now also create dependencies between the different issues, in the different products. And it is completely separated from default Jira product versioning. Which is great, so the normal release process stays as it is.

Another idea I'm thinking about to introduce is the field 'Iteration'. When going into the planning session (or just after it). This field could be updated with the name of that sprint (Jira is great in multiple issue editing / updating). Which then makes it easy to filter out all the issues for that sprint.

What I like most about using Jira also as a Scrum planning / Sprint tracking tool, is that you do not have a separate planning and backlog tool. Bugs are more visible. No double administration of bugs into planning tool and or planning items into Bug tracking tool (for the correct cvs/svn/etc commit numbers). Or the generation of release notes.

You're probably better of using confluence in addition to jira, in this case.

Use Jira for what it's best at, and use Confluence for everything else.

Divide your various projects into shared "sub modules" if you feel that is useful, however I would be inclined to suggest using Jira mostly for tracking actual implementation and associated bugs.

Another approach is create a multi-select custom field with hyper links (like 'XYZ-123') to issues as options.

Better way is to distinguish issues used for development tracking and requirements that often are the same at 80% for all your projects.

Solution exists: Rmsis a JIRA plugin: