As a System Engineer managing requirements do you ever feel like you’re playing a game of Topple? First, you start with a board that is relatively balanced, but depending on where you put the pieces it can quickly get off kilter. As the game evolves you are adding more and more pieces to the board. Now let’s make the game harder. Some of those pieces weigh more than others, so putting one green piece on the board means adding two red pieces to balance the load. Just for fun, lets now tie a few of those pieces together with some string, meaning you can’t add one or move one piece with out moving another. And are you really playing this game all by yourself?
Finding balance between competing requirements can seem just this precarious. If you’re building a medical device, you are likely weighing human safety over product aesthetics. When you add cost to one area of the product you have to adjust another area to keep cost in balance. And likely you’re working with a team of engineers who are building this product and must stay in close communication with them in order to deliver a complete, quality system. And as your product evolves you’re receiving requirements from many sources: business, product, hardware, and software.
How do you manage all of these competing priorities, conduct effective impact analysis and keep all stakeholders and developers in alignment? You are likely using some sort of complex matrix to keep track of the individual requirements and their relationships. It could be in Excel or even in a legacy RM tool. And this may work if all requirements were created equal, or if you’re the only person who needs to know about the impacts to the complete system.
But likely, that spreadsheet is not working.
Here’s what that spreadsheet on your desktop cannot do:
- manage the complex web of traceability to truly understand the relationships between requirements and the people who are responsible for them
- quickly find who and what are impacted by changes to the system
- ensure that each requirement is validated and verified, proving that when the product is complete, you are delivering what was asked for and that the system has been thoroughly tested
In my work as a Jama consultant, I’ve seen our customers solve these very problems using Jama. Like Sirius XM, who picked Jama for traceability and alignment from requirements to testing. They wanted visibility into change so that they knew what was impacted. And they needed to eliminate the chaos from spreadsheets and emails.
Our partner, Deloitte, first implemented traceability with Jama to get visible coverage from requirements through test. Then, they connected their many stakeholders to the requirements those people owned, and, as questions came up throughout development, the right people could be pulled into conversation, within the Jama application, to get to a decision quickly. These changes were captured along with the discussion right in Jama so there was a history of decisions that linked back to the original requirements requests.
One of the things I often hear in my work is a belief that implementing a new system will only increase the complexity of an already difficult-to-manage process. I understand the concern, and I’ve written before about how to ensure adoption of a new enterprise application. One thing that makes it easy for teams to adopt Jama is its ease-of-use, especially when you compare it to the chaos of documents and email and file sharing applications. In our next post, Matt Mickle, another Jama consultant will discuss the characteristics in the Jama application that make it easy to transition from document-based traceability to visible coverage in a collaborative system.