Jama Connect

Jama Connect is the source of truth for requirements within the SKA Organisation (SKAO). We have used internally within SKAO to communicate between Engineering, Operations, and Scientists, but also to do requirement reviews with external consortia, to get their input. We are also using it for requirement flow-down and traceability, and using several report tools. With the SKAO being a non-profit organization, the main goal is delivering maximum value for the system being designed and later implemented, and having an agile way of dealing with requirements helps us. I have now additionally added the usage of Jama Connect to the Joint ALMA Observatory, where we are also using it as the source of truth for requirements. We have been introducing the system to different stakeholders, which are linking their subsystem requirements to the ALMA System Technical Requirements.

Easy management of requirements with integration to the Engineering Change Process. We have somewhat been successful in that, by creating reviews on sets of comments, and later importing the feedback into the system, but it is not too clear. Being able to link testing outcomes and testing plans with similar structures in Jama is the next step of the plan.

At ALMA, we are using Jama Connect for Change Requests (CREs; same as SKAO's ECPs), and the different teams are using it as they see fit.

The internal model for Jama is sound, and traceability and suspect links are some of the best tools that we have. However, interoperability is not the best, and many times the requirements being provided by other parties needed a lot of massaging before being able to be imported in Jama. The inclusion of the Jama Interconnect option makes it more easy to integrate with other parts of the organization.

I would not change it. The other options were more costly, and less powerful in terms of requirements management, although they provided more support for other systems engineering tasks.

Jama can be picked up by experimentation, and there are official and unofficial resources that can be used. However, given that Jama comes with included service credits, I recommend using them for training every so often.

You should look at what item types you might need, but try to reuse existing types. For specifications that are intended to become complex documents, that might include glossaries, or other entries, try to use components instead of a single Set of <ItemType>.

None.

Not Sure

They were able to diagnose a difficult fault… because the problem had been human generated without our knowledge. They were able to pinpoint the result, and provide a way of reverting a manual operation that, from the manual, could result in definitive loss of data. The data was recovered, and a new feature added for the future.

None in particular.

Not at liberty to discuss.

None, it is very easy to work with Jama Software, both regarding sales, training, engineering consultations, and support.

Jama Connect is being evaluated as a potential tool to do requirements verification and sell-off. For now, we will be evaluating it for one of our programs. Jama Connect has the potential to upgrade our current process to review and sell-off requirements via email to using a centralized web based tool.

Our hope is that Jama Connect will allow our engineers to focus on the requirements technical content rather than on the process. Much time is consumed in tracking and statusing so we hope that will be a fall-out from using Jama Connect. Jama offers the ability to have everything integrated.

Given our manual process, Jama Connect is a definite improvement. So, assuming the learning curve is not steep and Jama Connect is stable, then we should see immediate improvements from the get-go. Collaboration is a key trait of Jama as it allows for integration with other tools such as providing automatic email notifications.

Perform more extensive trial period and perform more extraneous use cases to define the limitations of the tool.

None

None

No, not at this time.

The initial sales support and demo was very useful.

None

Price for number of seats

Know your critical use cases beforehand

We are using Jama Connect for collecting/gathering different types of requirements (i.e. business requirements, functional requirements, and non-functional requirements). We also used to get approval for those requirements to start working on it. Also, we use this as the golden source for all types of work to then track in JIRA.

We used Jama as requirement gathering purpose and we have achieved it very well. From the functionality perspective also from the automation perspective we achieved 60% from the Jama.

Jama doesn't provide self onboarding if it uses the LDAP directory and that is creating extra work for L1/L2 team. so, automation forJama can not be possible to reduce the manual efforts. Also, Jama doesn't provide the proper audition history which also doesn't satisfy most of the needs.

Jama is well managed in the sense of traceability, reuse, export or importing batches etc. Reuse operation is very useful to avoid redundant work. Jama reviews are helpful in case someone needs to review the requirements before approving it. Then, we can add multiple reviewers. This functionality is good in all other tools. Upstreams functionality is useful when we have two or more epics or stories upstream.

Personally, I don't recommend using Jama Connect if you are looking for a requirement gathering system only, if you already have tools like JIRA or ALM. If there is JIRA, then you can develop your own approval plugin and it can bring the same functionality as Jama in JIRA. Most of the other features are available in JIRA, so we can use JIRA as development gathering tool. JIRA has a wide range of plugins that improve its the functionalities.

If there is no constraint on your budget, then I would recommend Jama for requirement gathering since we can keep requirements in separate tool and link those requirements to different tools. Even Tasktop-like tools consider Jama as the golden source of information.

Internal training is sufficient to learn Jama.

There should be only one configuration file and startup file. Also for setting environment variables, there should be only one environment variable file before you start Jama. Where customers want to configure their project and with which database must be the choice of customers. Right now, Jama doesn't support Oracle.

We added customized item types and their attributes or report templates in Jama Connect.

Jama supported us on the weekend when they generally don't support on weekends or on their off hours. We were facing some issues with the application and we wanted to fix it on weekend, but we wanted help from vendor. They helped with prior notice of one week.

If an item is integrated with any of the application, then Jama should not allow any conversion of that item otherwise the integration breaks. Also, REST API performance must be better because as soon as we increase the frequency of hits, Jama's performance gets degraded.

I never participated directly in negotiating but I was aware about the negotiation process with vendor. We generally keep in mind support, licensing cost and escalation process while negotiating, as well as defects resolution, audit perspective principles, and security vulnerabilities.

Ask for 24/7 support in case of production issues or outages if you are negotiating. Also, set the SLA time for the issue resolution. For premier support tickets, SLA must be there. Performance related issues must be resolved with patches and any defects that need immediate attention or require an immediate fix must be provided by the vendor in a set time frame. Right now, Jama doesn't prioritize the defects on customer impact, they prioritize on their own.