Best Practices for Defining System Tree (Outline) for System Requirements

rgueler

I am new to Jama. I want to create a template for System Requirements. I created a Word file of the MIL STD requirements outline and imported it into Jama. All the items came in as System Requirements including the headings. Since the headings are not true requirements, what item type should I use for headings? I like the tree like structure and want to keep it. Any suggestions on how I can improve this template?

MSE

I also have the same concern. I had not tried importing my MIL-STD outline into Jama, but this helps me understand what is going on. However, I am still doubting whether we should be using the entire outline in Jama or not, instead keeping things limited to requirements item types and a limited number of folders. The reason is because every item type has attributes you need to manage.

However, to answer your question, I currently am using folders. So "Required States and Modes" is a folder containing requirements.

My other post on this topic raises some doubts. I am thinking for example of moving the outline part of things to a document template. I would then keep the requirements stored in Jama.

Alessandro Valli

My solution is not to use subitems. All headings are folders in my case. All my export templates are based on such assumption. The import was done via script (OK, you need some coding …)

Another constrain is that I do not use the description in folders. In case having a description in the folder I move it to a newly created text item under that folder location.

Dimitrios Pananakis

Alessandro, did you face/or foresee any issue with using subitems? I am wondering as we may have a use for them and haven't really applied it to any project yet.
Warm regards

Dimi

Alessandro Valli

These are the main reasons:

→ formatting in exported documents (we decided to use only folders for structuring and I ignore the description of folders).

→ which is semantic behind subitems? I mainly use relationships (for Requirements) to establish parent-child "associations". The only case me using subitems is for Architecture items (subitems are the interfaces of the top item)

→ I cannot remeber this being a defect or not (in recent cloud versions there is a defect fix about this …), but if the top item is locked, then you cannot edit subitems: my users do not like this

Dimitrios Pananakis

Thank you Alessandro,

The only use for subitems that I found is the following:
We have a set where we have requirements for a software application - we are using the use-case format to specify intended behavior (so the description field contains all required information a use-case needs e.g. Primary Actors, Preconditions, Scenario steps, Postconditions). This way of expressing software requirements has a lot of advantages for software applications that have complex flows.

So far so good. If we perform risk analysis on the application we may find that specific scenario steps are required so we may need to have one or more risk control items linked to the Use Case item. The problem is that we want to link risk control item to a specific scenario step (among the many it may have). So the only solution I thought of, is to use subitems expressing how the specific scenario step addresses the risk control.

Its kind of similar to when you have a top-level requirement that is linked downstream to another item that has a table in its description. It may be that only some of the rows/columns of that table address that specific top-level requirement. How can you address that, if not with some mechanism like this?

If you or anyone faced some similar need and have alternative solution let me know
Warm regards

Dimi