Product Idea

There should be a way to regenerate item IDs for a specific item type in a project starting from 1 and ensure that the IDs are created in the order that the item type is listed in the hierarchy.  This should be something that only a project admin can do.

Where this comes from is a need to re-order and re-number after a review and approvals process where other users have significantly changed the order and hierarchy of items. This doesn't occur all of the time, but there have been a few instances where a review has resulted in a massive restructuring of items, yielding item IDs that are completely out of order.

For example, I might have three requirements that were entered as follows:
Req-1
Req-2
Req-3

But I've reorganized them in the hierarchy (and subsequently, the report) to be in a different order, as well as added another requirement:
Req-3
Req-1
Req-164
Req-2

If I use "regenerate item ids", the item ids update to:
Req-167
Req-165
Req-328
Req-166

When what I really wanted was:
Req-1
Req-2
Req-3
Req-4

Since the items IDs are different from the API ID and the Global ID used for tracking, I would expect that this operation would be available already, but it's not.

We use ID's in technical documents and for some customer communications - this would really be helpful for making references/documents more "human friendly".

Yes!! I was just about to write a post about this exact topic.

This would be so useful - often when you're drafting requirements you jump about and don't necessarily write them in any order. However, before I sent them for their first review I would like to give them an ID which reflects their order in the hierarchy

Agree that this should be project admin only

I would not want such a feature, as we need a stable reference to identify a requirement. Latest after having exchanged information in a document, being able to change the reference would create severe issues in our environment.

Restricting that to a project admin, is not restrictive enough, as for several reasons nearly everybody needs that permission.

Hi Harold, you can already change Item IDs - we're just asking that when the change takes place, we have the option to start the numbering from 1.

Jennifer, thanks for sharing this topic, and thanks Harald and Scott for the further discussion. 
I know that stability is very important to folks in many organizations, and I can see how this could help that work—but might be a hindrance at the same time if you consider the item IDs gospel (and don't ever change them). 

Question for you all: how important, really, is the hierarchy in the Explorer Tree for stability/traceability/compliance? I appreciate your point, Scott, that you can renumber items already (but you can't go backwards). But in terms of renumbering from 1 and in accordance with the explorer hierarchy, that's a different story since unique IDs traditionally don't have anything to do with the hierarchy (only the Heading does).

If I understand your question correctly, hierarchy is vital to our use of Jama which is why the coverage report bug in hosted Jama is so painful.

For us, hierarchy is a convenient way to understand coverage in different contexts (and also for assigning high level accountability).  Our designs are verified using several techniques that are each "containerized" in the hierarchy.  Items typically have multiple downstream links to the various containers.  Depending on where we are in the development process we monitor particular types of coverage to assess completeness of the type.

Regarding the renumbering - I agree that at some point the numbers must not change.  I was thinking of using renumbering as a "clean up" step after initial requirements are entered/organized or if a "project reset" occurs.

Thanks Lawrence, and yeah, my question was a little tough to parse—I was curious about how important hierarchy via tree is and how important numbering is to that.

Thanks for your thoughts on this!

Hi Kristina,

My company does both software and hardware/instrumentation development and manages and maintains design inputs through Contour.  So by virtue of that, hierarchy is vital to understanding coverage and maintaining traceability across the multiple documents that are eventually produced and stored in our Design History File.

As an example, we might have a requirement that is under a folder (in Contour) or heading (in our report) of "Electrical Requirements".  Then we may have a hazard that is related to that requirement under "Shock Hazards".  This may also be intertwined with a failure mode that's found under "Electronics".  All of these items will link to several "Electrical Specifications" that allow us to meet the original requirement, while mitigating the hazards and/or failure modes associated with that requirement.  Technically, even without the hierarchy I could have all of these items in a large single-level list of reqs/hazards/failures modes/specs and they could trace the same way, but from a human-reviewer perspective, the hierarchy is very helpful in understanding how various reqs/hazards/failures trace to various specs.

Additionally, hierarchy is used as a jumping-off point when we write our design verification and design validation plans and reports.  Since we have many different pieces that all need to come together for a final product (and many different engineers or groups of engineers responsible for each item), we generally split up verification/validation plans into smaller parts to divvy up responsibilities efficiently and quickly.  Hierarchy allows us to quickly do an initial pass in splitting up writing and performing those test plans.  Using my example from before, all of the System Design Specifications associated with "Electrical Specifications" may go to one or more EEs, and we'll have analogous scenarios for mechanical, software, integration, and other "specification buckets" (so to speak) that are divvied up accordingly.

Another thing to note is that our reviews generally take place outside of Contour.  While technically, in the example in my original post, there is no real difference in whether a requirement is numbered Req-3 or Req-167 or Req-1 as long as it traces properly to the right specification(s), from a human-readable perspective, the feedback I always get is that it "looks weird".  That's why I made the request in the first place--it's mostly for human readability.

Hope that helps!

Jen

Ah, right—humans always get in the way of things. Thanks for explaining everything so thoroughly; it's very helpful. I have a question that I think our Product team will ask: why doesn't your team do reviews in Jama?

Thanks for the feedback Jennifer. Your scenario (at least the way I'm reading it) would probably benefit from what many refer to as a "tag based" approach - allowing you to tag your items with one or many attributes that would allow for different layers of visualization. Right now, Jama has either hierarchical views tied to the tree or relationships. Ideally, we could separate the data to be parsed and visualized in multiple ways, not necessarily constrained by the tree or ID's. Would you agree?

Hi Kristina and Jeremy:

Sorry for the delayed response, I haven't had a chance to get back to you until today.

The team does not do reviews in Jama because the number of people who are potential reviewers across varying projects is around 50-75.  (Note that these reviewers are split across about 7 projects and that not everyone reviews every document.  For example, we might have 10 reviewers on a single PRD, but only 5 reviewers on a single FMECA.)  Therefore, with the number of potential reviewers for any given document as high as it is, we've found it a lower barrier-to-entry from a company standpoint to do reviews in MS Word or Excel and have a more limited set of people interact with Contour.

As far as tags are concerned, yes, this would be a great mode of data visualization if everyone was always working in Contour.  However, since that's not the case, the headings in the output documents (which are directly related to the hierarchical structure in Contour) are more useful.  With that said, if it was as easy to export the data visualization using tags as it is to say, create an export of a coverage view, then yes, this would be an excellent feature.

Jen

To Kristina's question, numbering according to hierarchy would be fantastic for us. I had this same request years ago.

Our need is similar to Jennifer and Scott's:

• Being able to renumber from 1
• Being able to lock down WHO can trigger the renumbering
• Being able to lock down when renumbering is possible/no longer possible

ie, During the requirement writing process, before it's sent for review. I'd like to renumber from 1 to reflect the hierarchy of the requirements for easier reviewer readability. I'd like the Admin (or someone granted rights by the Admin) to be able to do this. AFTER review, I want to lock down the IDs so that renumbering is not possible anymore. We need the stability of knowing the IDs will not change after the requirements have been reviewed.

Thank you for the detailed scenario, Felicia.