Item-based product development
Jama Connect is a product development platform that is database driven.
Why do we use items instead of documents? Several reasons:
Version control — Track changes and feedback at an individual item level, whether the item is a requirement, a risk, a test, or even project documentation.
Data integrity — Quickly search, filter, and create dashboards to view progress based on item attributes. Documents don’t allow for this functionality and often have data integrity issues.
Time savings — Save time by not having to manually maintain IDs and trace links in a document. In Jama Connect, traceability is a by-product of the way you work.
Review efficiency — Focus on smaller, more iterative item reviews. Users no longer have to wait for entire documents to be submitted before they can provide feedback. Get to market quicker!
Auditing quality — With a few clicks, identify items that are missing coverage throughout the product development process. Coverage is the extent to which items are validated by another item.
The shift from a document-based approach to item-based is key to the value of Jama Connect. Your team's methodology directly influences how you set up and configure your Jama Connect environment with different item types.
The following diagram illustrates how to shift from a document-based approach to an item-based approach using Jama Connect.
Identify the documents and content that need to live in Jama Connect.
Determine the item types that exist in those documents. For example, item types might be system requirements, use cases, or test cases. Item types must have defined relationships in Jama Connect, which you can specify with a relationship rule.
Configure a project structure, then build your content. You can import existing documentation or author directly in Jama Connect.
The following diagram is a typical relationship model in Jama Connect that adheres to a Systems Engineering Methodology (SEM). In it, a box represents a single item type and lines represent relationships.
Your team's development methodology comes into play here, for example classic vs. agile methodology. While some teams use only one method, many teams use a combination.
Each method might use different terms. For example:
Classic Systems Engineering | Agile Methodology |
|---|---|
|
|