Requirements Management – Living NOT Static

Marc Osofsky

living requirements management

My first job out of college I worked for a large agri-business in Russia and toured all types of food processing facilities. The saying that you do not want to see sausage being made definitely holds true. What may surprise many of you is that the behind-the-scenes process to make the newest, shiniest tech, can be equally messy.

At Jama Software, we are fortunate to be working with leading companies, in the most innovative sectors of the economy, and are deeply immersed with our clients on state-of-the-art approaches to product development. So, we “see the sausage being made.”

Common Symptoms

When we begin working with a new client, the described symptoms of the product development process are often not pretty: business stakeholders are frustrated, requirements are not validated nor verified, requirements are missed, there is limited reuse, defects are too prevalent, costly delays, after the fact compliance that is heavily manual, no requirements traceability, significant rework, no real-time visibility and much more. After articulating these symptoms, most companies do not have a clear understanding of what the root causes are that are the origin of the symptoms.

Two Fundamental Causes

Our perspective, after working with over 600 companies, is that most organizations face two fundamental root causes that must be addressed to resolve these symptoms and reduce product development risk:

  1. The end-to-end process to deliver product is fragmented into siloed teams, activities, and tools
  2. The requirements that specify necessary dependencies and outcomes are trapped in static documents

As a result of these two key issues, the costs and risks of product delays, defects, omissions, regulatory gaps, and failures continues to run much too high.

As with most organizational challenges, there is a good reason for the fragmentation of the product development process – engineers. Engineers have been (and continue to be) enabled to choose their own tooling that best enables their productivity within their field of responsibility. As a result, end-to-end process data is siloed in numerous tools — within software, hardware, electrical, embedded systems, testing, etc.

RELATED: See how Infineon transition from a document-based to a data-centric development workflow using Jama Connect

The Resolution

Nearly every other business process has resolved this problem by forcing everyone on a common platform (think ERP, CRM, etc.). That approach will not work for the product development process given the complexity and diversity of engineering disciplines. The answer lies in somehow connecting static requirements to downstream activity – but how is that possible with requirements stuck in documents and little to no integration among the fragmented engineering silos?

Our top-performing clients are all taking the same approach. They have moved away from static requirements documents and have implemented LIVING REQUIREMENTS that form the common thread through all downstream activity to link each requirement to its decomposed user stories, dev status across engineering teams, change impact analysis, risk analysis, test results, defects, rework, launch and market feedback. The table below highlights the main differences between STATIC and LIVING requirements:


Item-level thread to all downstream process states 


Impact of change easily determined 


Exception reporting on missed requirements  


Compliance is highly automated 


Enables end-end process improvement 


Enables benchmarking performance 


Team productivity improvements 


Overall product risk reduction* 




Differences between STATIC and LIVING requirements

In short, LIVING requirements address the root causes (identified above) to deliver increased productivity, faster speed of delivery, and risk reduction. This includes all areas of the complex product, systems, and software delivery lifecycle that can experience negative outcomes and should be actively managed to reduce the likelihood of occurrence.

  • Performance | Product fails to perform specified functions
  • Quality | Product defects are discovered by customers post-launch
  • Delays | Product release deadlines are missed
  • Fit to Requirements | Product fails to meet the needs of customers
  • Compliance Gap | Gap identified late and extreme cost to rework and fix
  • Regulatory Action | Product is not approved for launch or recalled post-launch

LIVING REQUIREMENTS are clearly becoming a competitive advantage in the innovation economy. If your requirements are still STATIC, you are falling behind. We encourage you to reach out to our team of experts and learn more about joining the LIVING.

To learn more on the topic of requirements management, we’ve curated some of our best resources for you here.








Previous Article
Introducing Jama Software’s Product Essentials Deminar Series
Introducing Jama Software’s Product Essentials Deminar Series

In this blog post, we introduce our 6-part deminar series where we’ll cover key features and capabilities o...

Next Article
WEBINAR: Ask Jama: Release Management Options in Jama Connect
WEBINAR: Ask Jama: Release Management Options in Jama Connect

Join us on July 22nd for our Ask Jama webinar where Ryan Moore will be discussing options for managing rele...


First Name
Last Name
Pending Opt-In
All fields are required. Your privacy is important to us.
Thank you!
Error - something went wrong!