Tag Archive for: living requirements

This post was originally published December 18, 2020, and has been recently updated.

Digital Thread Defined

Digital Thread Definition – a data-driven architecture that links together information generated from across the product lifecycle and is envisioned to be the primary or authoritative data and communication platform for a company’s products at any instance of time.

This is the best definition of Digital Thread we are aware of and is from an excellent 2018 paper by Singh and Willcox at MIT entitled Engineering with a Digital Thread. The term Digital Thread was first used in the 2006 with the publication of the Global Horizons report from USAF Global Science and Technology Vision task force. (If you have an earlier reference please share in the comments). In this document, Digital Thread is defined as “the use of digital tools and representations for design, evaluation, and life cycle management.”

As with many business terms, Digital Thread has now become over-used by consultants and software vendors. The definition of it — and how it differs from Digital Twin — have been interspersed with more general concepts of integration, simulation, data, and analytics and has lost the original, more precise meaning.

Digital Thread Components

Let’s break down the definition of Digital Thread into its components to better understand the concept and share the most common approaches we see as companies move to make the Digital Thread a reality. Here is the definition breakdown:

1 – a data-driven architecture

This recognizes that the use of a single common platform is impossible across all engineering disciplines (software, hardware, electrical, systems, risk, QA, etc.). Instead, a data-driven approach is required that determines the key information required from multiple tools. It’s important to remember that data-driven does not mean “gather all your data” but rather that you should be using data to answer questions. In other words, do not fall into the trap of tool focus, but rather focus on the questions and collect data to provide the answer.

2 – that links together information generated from across the product lifecycle

From initial requirement definition through to product release, significant information is generated across multiple tools. The challenge is to identify what information is most relevant and how to best link the information to make it actionable. The most common link we see is the definition of value to be delivered (user and system requirements). The most typical information captured across the product lifecycle are process statuses and exceptions (e.g., requirements that have not been approved, require rework, or are not fully addressed, gaps in testing or risk analyses). By linking these process statuses to requirements and tracking them through the product lifecycle it is possible to reduce the risk of negative product outcomes (e.g., delays, defects, cost overruns).

3 – and is envisioned to be the primary or authoritative data and communication platform

Most companies refer to this as a “system of record” or a “single version of the truth.” A Digital Thread is much more than simply integration or a data lake. By tying the definition of what is to be delivered (requirements) to the most critical downstream process meta-data, a Digital Thread create the ability to understand the state of the product development process, what risks are visible and what corrective actions should be considered. Without a Digital Thread, a company is flying blind in terms of the risks it faces in product development.

4 – or a company’s products at any instance of time

For a Digital Thread to be truly useful it must always reflect the current state of the product development process. The value is in seeing the product development process for the first time across fragmented teams and tools, to be able to identify process exceptions and early indicators of potential downstream risks. A static database of days or weeks old data will not be sufficient for a process that is changing rapidly across multiple, siloed teams.

Why the Digital Thread is So Important

The product development process is often fragmented across siloed teams and tools which leads to significant risk of product delays, defects, cost overruns, failed verification and validation, recalls, etc. End-to-end process visibility is required for better cross-team collaboration and the early detection of anomalies to reduce these risks. To solve for this, organizations often attempt to force everyone to use one common software platform, forgoing their choice best-of-breed tools. This solution is neither practical — nor particularly realistic — since engineers are (and should continue to be) allowed to choose discipline-specific tooling which optimize their activities.

What is required is a loosely coupled approach that ties together the necessary metadata across these disparate tools in a way that connects the desired outcome (user and system requirements) to downstream activities – the Digital Thread. The Digital Thread is the best approach to reduce the risk of negative product outcomes while preserving engineering autonomy and productivity.

Click here to learn how Jama Connect’s Live Traceability™ enables a digital thread.

LEARN MORE

Apex.AI-Selects-Jama-Connect-to-Increase Efficiency

In this post, we discuss Apex.AI’s selection of Jama Connect to shorten development time and increase efficiency.

Award Winning Automotive Software Developer Selects Jama Connect® to Shorten Development Time, Increase Efficiency, and Sail Through Audit Preparation.

Apex.AI, founded in 2017 in Palo Alto, California, is a mobility software company, and makers of the ISO 26262 ASIL-D safety-certified software framework Apex.OS. As a pioneer in modern C++ software development for safety, they are the first organization to certify a modern C++ open-source product to ASIL-D. Their client list is extensive and prestigious, and they are backed by some of the leading venture capital firms in the world, including Lightspeed Ventures, Toyota AI Ventures, Volvo Ventures, and Airbus Ventures.

More about Apex.AI:

Headquartered in Palo Alto, CA in the heart of Silicon Valley with offices in Munich, Berlin, and Stuttgart, Germany and with employees worldwide.
Founded in 2017 in Palo Alto, CA
Expertise: Building robust, reliable, safe, secure, and certified software for mobility systems
Recent Awards for Apex.OS, the safety-certified automotive OS:
- Apex.OS wins two awards from the German Design Council (June 2021): “Best of the Best” award and “Innovation of the Year” award
- Apex.OS honored with the CES Innovation Award (Jan 2021)

With a mission to enable automotive developers to implement complex AI software, and enable AI developers to implement safety-critical applications, Apex.AI is an innovator in the automotive industry.

Comprised of alumni from top automotive, robotics, and software companies around the world, the Apex.AI team knew that development success starts with requirements management. That’s why they set out to evaluate the top requirements management solutions from the very beginning. The team had clear objectives and knew that their requirements management solution needed to:

Allow the team to create a centralized repository of requirements
Help them demonstrate compliance with stringent automotive standards like ISO 26262
Enable collaboration across a globally distributed team
Be a modern, cloud-based solution that all team members could use
Have industry acceptance and expertise

The team did not take the selection process lightly; they knew there was too much at stake. Apex.AI did an analysis of the full requirements management tools and software market and decided to evaluate Siemens Polarion and YAKINDU more in-depth.

After an in-depth analysis of these requirements management (RM) tools – including interviewing current users of these products – Jama Connect was selected as the solution of choice for the team for the following qualities:

End-to-end traceability from requirements all the way through to tests
Powerful, flexible solution that all team members can easily use
Industry-specific templates and expertise in automotive development
An easier path to compliance

“Why would an innovative automotive company consider Jama Connect? From my perspective, Jama Connect is the best of breed requirements analysis and requirements engineering tool… I would highly recommend it and I would use it again without any hesitation on any subsequent project. ”

Neil Langmead – Senior Functional Safety Engineer, Apex.AI

Jama Connect was also the only solution that had Living Requirements™ management, which allows teams to move away from static requirements trapped in disparate documents and creates a digital thread through upstream and downstream activities.

magniX chooses Jama Connect for its ease of use, quick deployment, and to help modernize their requirements management program and demonstrate compliance with standards.

Headquartered in Everett, Washington – located just outside of Seattle – magniX is the leading developer of propulsion systems for electric aircraft, including motors, inverters, and motor controllers.

magniX is working to bring affordable, emission-free, and quieter flights to communities around the world.

More about magniX:

Founded in 2009
Expertise: Leading developer of propulsion systems for electric
aircraft, including motors, inverters, and motor controllers
Recent Awards for magniX:
- 2020 Fast Company Most Innovative Company in Energy
- Finalist 2020 GeekWire Innovation of the Year award
- Frost and Sullivan Technology Innovation Leadership Award

With big plans on the horizon, magniX set out to find a modern requirements management solution that could help them make their ideas a reality.

Initially, the team was using Microsoft Excel and Word to manage their requirements, but they quickly realized it was only a temporary solution. The limitations and risks of using static requirements in this manual process were becoming apparent.

As they began their search for a requirements management solution, they knew the following things were most important:

- Moving to a modern, cloud-based RM tool
- Creating a centralized requirements repository
- Demonstrating compliance with aviation standards

While the evaluation process was short and led to the selection of Jama Connect®, the magniX team seriously evaluated multiple systems.

Jama Connect stood out for the following reasons:

Jama Connect was a more modern, easy-to-use solution with the powerful features they required
Jama Connect allowed for the magniX team to easily customize the solution to meet their needs, without requiring complex custom scripts to be written
The interface in Jama Connect was intuitive

“The ability to easily customize Jama Connect to fit our needs without custom scripts is a major advantage over other solutions,” said Carlos Souza, Head of Energy Storage Systems at magniX. “Jama Connect just allows us to achieve more with less work.”

Ease of use and quick deployment

In addition to ease of use and quick deployment, ultimately, the magniX team selected Jama Connect because the solution:

Allows for end-to-end traceability that gives the magniX team the ability to control requirements from the product level down to implementation in one single database
Is powerful, intuitive, and easy-to-use requiring very little training to see wide adoption and ROI
Enables configuration control throughout all stages of development

“One of the main reasons we selected Jama Connect is the ability to provide configuration control for all the requirements and maintain them in one database. It allows everyone in the company to have visibility into the requirements and their status,” said Souza.

Jama Connect helps to form a digital thread through development, test, and risk activities — enabling the magniX team to have end-to-end compliance, risk mitigation, and overall process improvement. Moving from static requirements (in disparate teams, activities, and tools) to Living Requirements™ management was the key to them achieving real-time, cross-team collaboration and coordination. And, because of its easy, intuitive, modern user interface, broad adoption is made simple.

Jama Connect: the Leading Platform for Requirements

Matt Graham: Thanks everybody for joining. So today, before we get into the agenda just to introduce the three products that there are three subject matter experts about. First of all, something near and dear to my heart, the Cadence vManager, verification management platform which is a scalable, reliable and very feature rich verification planning and management solution from Cadence. That sits on top of a number of our verification and provides a sort of roll up capability. And we’ll describe it in a little more detail in a couple of slides. On the OpsHub opposite side, we’ll be looking at the OpsHub integration manager that enables enterprises to integrate their best of breed tools together that are best suited for the various teams and their various roles and connect those two together for integration and collaboration. And then Jama Connect, which is the leading platform for requirements, risk and test management to help provide that sort of end-to-end compliance solution.

Our agenda today. First we’ll look at some of the challenges of the semiconductor and hardware development ecosystem. This is obviously a very fast paced, highly competitive type of environment and there’s a lot of specific challenges that the integration of the tools I just mentioned can help address and solve. We’ll look at how engineers in this space can scale effectively and efficiently utilizing some of these, the tools to address some of the ongoing transformations in that space. And then specific to semiconductor domain, bridging the gap in what has historically been a very siloed development process. And bringing together for efficiency, quality and reliability all of the various tools that I mentioned and giving it a really nice integrated development and verification environment. We’ll then have a specific use case and demo showing how the three tools work in concert and then look at some key takeaways. And as Marie mentioned, some Q and A.

Standards for Requirements such as ISO 26262

Specifically to the semiconductor and hardware ecosystem, there are a developing set of challenges. And of course they’ve always been challenges in this area. First pass design success is critical for hardware development. Just because the tooling costs are so great. We don’t want to have to respurn hardware. It’s not like just releasing more software. It is it requires expense. But that has been the way of hardware development for some time. In the last several years we’ve seen a need creeping into that environment for even stricter compliance, particularly around mission critical domain such as aero and defense, automotive especially as self-driving and autonomous vehicles come in. And adherence to standards like ISO 26262 presents another layer of requirements and need for management and collaboration on top of an already strict set of sort of design parameters.

As I mentioned, this development environment tends to be very siloed in its nature because it is so specialist. You have specialist designers, specialists verification engineers to test the designs, specialists post silicon, specialists layout engineers and so on and so forth. And all of those silos, well somewhat required of the specialty of each of those tasks tends to hinder collaboration, compromise quality and just impact efficiency and velocity overall. In an area where efficiency and quality is critical. We can’t have bugs in semiconductors going to automotive and we need to be able to turn those new cell phones, those new mobile devices as quickly as possible. So turnaround time is just getting compressed and the requirement for quality is increasing at the same time.

RELATED: A Guide to Understanding ISO Standards

All of that sort of siloed nature of the specialties as well as the need for velocity and quality really ends up in poor traceability of results in terms of compliance and quality issues creeping in. Especially when it comes to doing things like audits for ISO and other similar standards that are becoming the requirement across again aero and defense type applications, automotive type applications and even down into the sort of consumer device applications. And really traceability is a watch word now in the ecosystem of hardware and semiconductor development.

So how does the offering from Cadence, vManager fit into and help provide a solution to those challenges that I just mentioned? Well, for a number of years now, in fact, vManager has been around for about 15 years and in that entire time it’s had the key capability of the verification plan. And the verification plan really exists to provide traceability between what is being executed during the testing or verification of your semiconductor or hardware design. And what were the goals of that or the requirements of that testing or verification project. Things like testing interfaces, both internal and external to the semiconductor, testing compliance with standards like ethernet and USB, such as that, things like that. As well as the internal requirements of the device, it must route packets this fast. It must answer phone calls in this manner or whatever it might be.

And the verification plan in vManager really allows the user to enter those requirements and then connect them to the real results that are occurring. We ran these tests, these tests were associated with a given requirement. Those tests passed therefore the requirement is satisfied. And so the V plan becomes a very natural place. And in fact the appropriate place to connect the rest of the ecosystem via OpsHub, two tool requirements coming from Jama Connect so that we can have traceability across the software development, the hardware development, whatever. The mechanical development et cetera ecosystems. And the vManager and the verification plan is really where that hardware verification, that hardware and semiconductor development information enters that ecosystem through the conduit of the verification plan. So let’s look a little bit more on, well what exactly is in that verification plan that vManager provides.

Enabling Digital Transformation: Static Documents Cause Challenges

And the V plan is really what we call, what we refer to in our vManager sort of pitch if you will as an executable verification specification or an executable verification contract. And what that means is that there’s data incoming to that during the creation, the authoring of that verification plan. Not only through connectivity to tools like Jama but also from say static documents like standards specifications, ethernet that I mentioned before, USB those are standard protocols that have very lengthy standards documents and needs to be a way to import, kind of gather the data from that and put it in the verification plan. Another input to the verification plan is other verification plans. So if you think about a system on a chip that is not a single piece of intellectual property, it’s built up of many, many different pieces, a USB piece, a central processing piece, a memory management piece and so on.

And each of those pieces can have their own verification plans for the verification at that sort of lower block level as well as then can sort of conglomerating or aggregating those verification plans into a single sort of system on a chip verification plan. And the vManager, V plan allows that through sort of parameterization and instantiation and really flexible set of sort of reuse capabilities for verification lands. And then of course just engineers authoring their verification plan. Literally writing, typing in here’s a specific requirement et cetera. And then we have the component of mapping those requirements to items that exist in the actual testing environment. Things like we have a test, did it pass or fail? What requirement is that test related to? So there’s mapping the test to a particular requirement and then did that test pass or fail. Those of you familiar with hardware verification know that tests passing and failing is not the only statistic or metric that we track.

There’s other metrics and statistics such as code coverage, functional coverage, assertion coverage, software coverage, all tracking what scenarios and what stimulus were driven to the specific device under test. And what was the reaction of the device under test? And then what percentage of the device has been exercised during that test? It is all basically statistics gathering from the testing effort. All that data can be mapped into the verification plan, directed to the specific requirement or multiple requirements that it may satisfy. And of course, this gives us the ability to not only specify a requirement, but then capture whether that requirement was met. Was it satisfied? And this is the place where I’ll hand over to Jeremy now to talk about what those requirements in those higher level requirements or system level requirements in the general world and how they’re going to connect into this hardware verification, hardware development world.

Developing autonomous vehicles requires an incredible number of moving pieces to communicate with one another. From sensors, to computers, to the automatic braking system, vehicles today require a complex system that leaves no room for error in communication.

In this blog post, we take a look at Arteris IP’s top challenges in autonomous vehicle development and why they selected Jama Connect to help.

Managing Complexities Across Remote Semiconductor IP Development

In a world of increasing automotive complexity and connectivity, developing the world’s most innovative semiconductor IP comes with a set of challenges. Arteris IP turned to Jama Software to help address these critical business challenges:

1. Adapting to Increasing Complexities in Semiconductor Development

As semiconductors get larger with more processing power and more functionality, they also become more complex and more connected. In addition to the standard complexity of semiconductor IP, Arteris IP was the first to add state-of-the-art functional safety mechanisms directly into the on-chip interconnect semiconductor IP, compounding their product development complexity.

In conjunction with their response to increasing complexity in semiconductor development, Arteris IP was also expanding their product lines from one to four, and therefore greatly increasing the number of requirements they’d need to manage.

“I find it really interesting that as the automotive industry becomes more complex, it’s becoming much riskier to base a product development process on static requirements trapped in documents. You need a living requirements thread through the end-to-end process to minimize the risk of negative outcomes and maximize productivity.”

– Kurt Shuler Vice President of Marketing Arteris IP

2. Collaborating Across Distributed Teams

With teams spread across the United States, Europe, and Asia, having clear communication and collaboration is crucial to Arteris IP’s success. The team found that sending documents and spreadsheets over email made it nearly impossible to maintain version control, and spending hours in a room reviewing requirements was not only ineffective, it was inefficient.

And while developing semiconductor IP was never an easy task, the global COVID-19 pandemic of 2020 added new challenges to Arteris IP as engineering teams shifted to be fully remote.

The challenge of engineering teams working remotely across multiple time zones made communication and collaboration even more vital, emphasizing the need for a solution that enabled everybody to collaborate seamlessly on a project virtually, regardless of physical location.

Jama Connect is our single source of truth. If it’s not in Jama Connect, it’s not happening. If it’s not in Jama Connect, it didn’t happen. When I tell people in the automotive industry we use Jama Software, they all know what it is. If you’re using anything other than Jama Software in the automotive industry, you’re going to get more questions.”

– Kurt Shuler Vice President of Marketing Arteris IP

3. Managing Document and Tracking Disparities Lacking in Traceability

With just Word Documents, email, and Excel spreadsheets, the Arteris IP team found themselves struggling to keep track of things due to the lack of traceability and a central source of information.

Macro-level traceability is key to the Arteris IP development process, and their current system did not provide end-to-end traceability — all the way from requirements to verification and validation. Atlassian Jira also played an important role in their development process, and the team needed a way to seamlessly link requirements to Jira and keep those in sync as things shifted.

As an innovative leader in the automotive industry, other organizations were looking to Arteris IP for guidance on development processes, quality management, and adherence to ISO 26262. They knew there must be a better way than spreadsheets and documents.

4. Proving Compliance and Providing an Audit Trail

With many of the most important Arteris IP clients being in the automotive industry, and some also in aerospace and industrial machinery, meeting regulatory standards is a critical challenge for the organization. ISO 26262 is the most important functional safety standard for Arteris IP, and proving compliance is critical. And as previously mentioned, their current solution did not provide the level of traceability necessary to prove compliance with ISO 26262.

The team needed a solution that both enables traceability and helps demonstrate that functional safety standards and industry regulations like ISO 26262 have been met during the development process.

Arteris IP Selects Jama Connect to help Develop Connected Semiconductor IP for Autonomous Vehicle Development

After considering all market options, including IBM® DOORS® Next Generation, Arteris IP selected Jama Connect as their requirements, risk, and test management solution. The decision, Kurt Shuler, VP of Marketing, said, ultimately came down to the semiconductor and automotive industry’s trust in Jama Software as an industry-leading solution.

He explained that after speaking with many of his semiconductor company and automotive Tier-1 customers, the majority of whom were replacing their outdated, legacy systems and adopting Jama Connect, he knew this was the right path for Arteris IP.

Download the full customer story to see how Jama Connect helped Arteris IP manage the complexity of developing highly sophisticated semiconductor IP by simplifying their requirements management and review processes and improving communication and visibility across distributed teams.

Read the full customer story to see how Jama Connect helps industry leader Arteris IP with autonomous vehicle development.

SEE THE FULL STORY

Requirements Traceability – What are you missing?

For systems engineers, business analysts, and product owners, requirements traceability (the ability to trace requirements to downstream development, test, verification, validation, and risk activities) is an unquestioned good and an unquestioned need. Traceability is required to demonstrate compliance to relevant standards in industries such as medical device, automotive, semiconductor, aerospace, and financial services. In addition to compliance requirements, traceability is quite helpful to assess the impact of change required on all relevant requirements and related downstream activities. But the largest potential value is missed by many organizations.

After-the fact use cases

The two main use cases for traceability noted above are both reactive to requests: the need to demonstrate standards compliance to third parties and the need to analyze the impact of a change request. Both use cases view requirements as static and passive. Requirements are documented and links created to downstream artifacts in software, hardware, and electrical development test and risk assessment — which are stored in a system. The system then waits until a request comes in from outside to document that a process has been followed or to identify which elements are impacted by a change. Both use cases reflect an after-the-fact mindset that limits the value that can be achieved from the effort put into establishing traceability.

Analogies to other business-critical functions

To view something we think we know well in a new light, it is often helpful to place it in a different context and look at it from a fresh perspective. So, let’s give it a try and compare traceability in the product development process to traceability in the new customer acquisition process.

For engineers, these processes may at first appear to be too disparate for an apt analogy, but at a fundamental level, they are quite similar. Both start with a documented value (requirement vs. opportunity) that must transition through multiple phases and involve many other functions to reach the desired outcome (release vs. win) — and all sorts of things can go wrong along the way leading to delays, costs incurred, and failure.

The aspect I want to focus on is how these two processes are managed. In the sales process, the element of value (the opportunity) is living — actively measured, analyzed, and tracked for exceptions on a daily basis. The key process metrics are defined with ranges for acceptable performance. Current process performance is automatically calculated based on the movement through stages of all opportunities. Alerts are raised for opportunities stuck in a process stage too long (relative to average dwell times) and predictions are made about future period performance based on the opportunities in the system.

RELATED POST: Requirements Management – Living NOT Static

In contrast, for most product development organizations, requirement traceability is static and in after-the-fact analysis and not living — in the way opportunities are traced in sales as described above. To make requirement traceability living (like a sales opportunity) traceability would require software-enabled best practices in the following areas:

Process metrics must be defined
Actual performance against process metrics must be captured
Once standard metric performance is defined, current performance must be compared to the standard
Exceptions need to be defined
Alerts need to be set up to notify when exceptions occur
Learnings need to be incorporated into process improvement

Once these steps are taken to improve requirements traceability, then requirements become living, not static, and performance improvement is possible: the risk of negative product outcomes is reduced, and process performance is improved; the product development process can then be data-driven, measured, and managed like all other business-critical processes. Without measurement, there is no way to benchmark performance against other organizations. There is no way to learn, no way to know, and no way to improve.

Jama Connect’s Requirements Management Enables Live Traceability™ Across Your Development Process

Bridge engineering siloes across development, test, and risk activities. Provide end-to-end compliance, risk mitigation, and process improvement with our intuitive, award-winning requirements management platform. Learn more!

Better to stay in the dark?

There may be some that would prefer to keep the product development process shrouded in mystery and avoid data-driven analysis, measurement, and process performance improvement. There used to be chief revenue officers (CROs) that felt the same way. It is extremely hard to find any current CROs with that mindset. Those that can lead through data and drive performance improvements gain the support of leadership and elevate their careers. The same opportunity is now on the table for product leadership to turn requirements traceability into Live Traceability™ in order to reduce the risk of negative product outcomes and improve the performance of the end-to-end product development process.

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

SEE MORE RESOURCES

Looking for a new way to manage your requirements in 2021 but not sure where to start? Selecting a modern requirements management tool might be the right next step. A growing number of organizations are exploring and adopting product development solutions that manage the complexity that comes with designing connected systems.

Requirements are the foundation of a smooth-running process and are the essential inputs to your mission-critical projects. Effectively managing the flow of changes and refinements early in your lifecycle will significantly reduce both quality issues downstream and the volatility that plagues so many projects – and the right requirements management solution can make all the difference.

The right requirements management solution can help manage the complexity of product, systems, and software development, but it also allows teams to:

Build higher-quality products with fewer defects and rework
Get to market more efficiently with fewer people and spending less money
Capitalize on opportunity faster through earlier launch dates and a prolonged market window

Another thing to consider when selecting a requirements management solution, is whether it allows for living requirements. Living requirements are becoming a competitive advantage in the innovation economy. If your requirements management solution doesn’t allow for living requirements, it’s like that your team will fall behind.

Differences between static and living requirements

Living requirements address the root causes 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

Whether you’re building products, systems, or software, check out this handy checklist to make sure you’re getting everything you need in a requirements management solution in order to improve efficiencies, cut down on costly rework, and mitigate negative product development outcomes.

Have confidence that you’re selecting the right requirements management solution by downloading our checklist for essential features and functionality.

DOWNLOAD NOW

Any engineering team working in a regulated industry understands the complex nature of product development and management. In areas like automotive, aerospace, defense, and medical device manufacturing, it’s a high-stakes effort navigating tight operational margins with little room for product integrity errors. In fact, it requires them to operate at different cadences and with new methodologies and practices to continuously deliver these products to the market quickly and safely – no easy feat!

Many of these organizations, however, have a difficult time keeping pace with the rapidly changing product development environment, especially when their teams work in silos using legacy requirements management systems. As businesses continue to shift focus to faster time-to-market and customer-driven product development, deeper structured collaboration amongst teams is not only desired but necessary.

What is Structured Collaboration

Structured collaboration is centered around the idea that people can work and interact with one another, moving toward specific and measurable goals. This approach works in two parts, utilizing technology and process frameworks to settle on new and innovative ideas that drive business outcomes.

By combining presence and unified collaboration with elements of content management (content about your product or system), development process management, and task management — all integrated into a workflow process that coordinates multiple activities from several teams — workers can produce the results that drive the business forward.

Lacking structure at the forefront for product development can lead to wasted time, untraceable changes, lost context for decisions that were made, and missed opportunities for innovation.

Innovation is Dependent on Structured Collaboration

Bringing together innovators across cultures, institutions, and geographic regions to create a new way of accomplishing goals can revolutionize a sector. We’ve experienced this first-hand watching the automotive and healthcare sectors come together to produce life-saving products amid the COVID-19 pandemic. It also presents unique challenges with each group having their own standards and entrenched way of tackling the task at hand. So, how do these teams tackle complicated divides seamlessly?

Unify Their Goals: When cross-organizational teams have clear and unified goals for developing a product, innovation, or service, they can better overcome challenges inherent to collaborating in a complex environment.

Clarify Their Roles: Clearly communicating expectations for how and when each team member will be asked to participate helps alleviate the uncertainty that comes with collaborating in a new way. By documenting goals and tracking collaboration each step of the way, it will keep programs moving forward smoothly.

Encourage Expression of Unique Points of View: Unlocking the creativity needed for innovation requires harnessing insights and unique perspectives across different stakeholders. By bringing in contrasting points of view and encouraging team members to speak up, it will result in robust and better-considered ideas for implementation. Having representation from across the team will also help better assess the impacts of decisions made and identify issues before they become problems.

Use the Right Tools: We’re fortunate these days to have a plethora of choice in collaboration tools from Slack and Microsoft Teams to Zoom and Google Hangouts. As teams seek input and feedback critical to capturing insights in real-time, these tools begin to serve a vital purpose. These only scratch the surface in eliciting the type of collaboration necessary for modern systems engineering, though.

Enable Cross-Team Alignment with Live Traceability™

While meetings, emails and instant messaging channels serve a purpose, they are simply not sufficient enough for making and tracking key decisions that impact an entire team. Especially when decisions need to be made at the drop of a hat. Modern systems engineering must include means for live data to be shared and accessed by teams anywhere in the world — at any given time.

As members of the product team seek to communicate requirements and project status across departments, roles, and geographic boundaries, the golden age of sharing documents and spreadsheets will no longer serve its purpose. Without a digital thread that connects people and processes — from definition to delivery — development teams face increased risk, challenges meeting compliance, and delays that can impact time-to-market and product and systems safety.

Live Traceability in Jama Connect provide a single-source of truth, cross-team collaboration and end-to-end visibility which forms the digital thread through siloed complex product, systems, and software development.

Eliminate Collaboration Silos to Enable More Strategic Partnerships

Today’s market demand requires companies to consider strategic partnerships as they seek solutions with more specialized materials. With this comes greater sharing of data across distributed teams, partner organizations and business units. Living in the era of rapidly accelerating change, teams that still operate in silos with legacy systems will not be equipped to meet demands set by the market.

For engineers so accustomed to working in internal, siloed groups, these new partnerships present previously unforeseen challenges. Structured and strategic team collaboration is the key to improving the product development process for all team members – and this includes everyone across the supply chain.

People working together is at the very core of all product development. For companies to turn the research of today into the products of tomorrow, it is critical that their teams stay connected, synchronized and unified. By aligning business objectives with a system in place that allows for structured reviews and collaboration, teams can elicit feedback, review product features with stakeholders in real-time and track critical decisions across teams and locations. Simply put, it gives complex manufacturers the edge they may otherwise be lacking.

Download our eBook to learn how to optimize product development with strategic team collaboration.

DOWNLOAD NOW

I am writing this post about reducing the risk of negative outcomes in the product development process in the hopes of saving at least some of you from the fate that has befallen many companies before they reach out to us. Unfortunately, many of our new clients come to us AFTER they‘ve had a negative product outcome at their current company, or even more common, at their new one.

According to an Engineering.com survey (full disclosure: we sponsored it) 83% of those companies surveyed experienced at least one negative product outcome including: significant delays, cost overruns, product defects, compliance gaps, recalls, omitted requirements, and lengthy rework. In many cases these negative outcomes were quite significant and led to changes in management and staff.

Root Causes of Risk in the Product Development Process

All of these companies conducted root cause analyses to determine what led to these negative product outcomes. The root causes identified are quite similar across the organizations:

Limited customer and cross-functional involvement in the review and approval of requirements
Static requirement documents rarely viewed by key stakeholders, maintained in Microsoft Word/Excel or a standalone tool, and used only be a few as a repository
Missing decomposed requirements
No ability to track the life of a requirement through development, test and release
Release cycle misalignment across engineering disciplines
Misinterpretation of requirements across engineering disciplines
No process exception tracking to determine requirements that have been omitted or modified
No identification of process risk patterns – delays in development, multiple test failures, rework cycles, etc.

Product Development Process is Not Under Control

With all of these informational and process gaps, the end-to-end product development process is “not under control”, to extend the concept of Six Sigma statistical process control to a complex process. A process that is not under control cannot be relied upon to deliver predictable results. The outcomes can vary widely and with no ability to truly monitor risk probabilities as the process moves along, the negative outcome occurs as a surprise at the end of the process where the cost is highest.

Many companies operate under the illusion of risk mitigation. The process is “not under control”, so management relies on managing people and takes each team lead’s assessment of progress and risk as comfort that the risk of a negative outcome is low. Unfortunately, the team leads are only assessing their teams and what they see. This misses the most likely points of failure that connect teams and extend over time. Without Living Requirements™ it’s hard for anyone to see across all teams (and time) to identify the exceptions, omissions, defects, rework, delays and dependencies.

Even organizations more mature in their end-to-end product development process management are still often surprised by negative outcomes. A very thoughtful root cause analysis of an actual situation of this type has been done by Michael Panis and presented at the 2020 IEEE 28th International Requirements Engineering Conference (RE). His key findings include:

“Poor traceability and missing subsystem requirements when a system requirement is decomposed through an error budget or other complex logic.”
“Missing requirements due to a decision to only trace to subsystems directly responsible for given system requirements.”

ROI from Risk Reduction in the Product Development Process

Investments to improve the product development process are typically justified through gains in engineering productivity. What is often missed is the even greater benefit to the organization of bringing the product development process under control and reducing the probabilities of negative outcomes. A basic approach is to quantify the magnitude of the various negative outcomes — and the likelihood of their occurrence — to determine the current risks in financial terms that could be faced by the organization. The next step is to estimate the reduction in occurrence probability given the improvements in the process and then calculate the overall reduction in the magnitude of the expected negative outcomes. A more advanced model is described in the paper by Machac, Steiner and Tupa.

A Common Mistake to Avoid

Let’s wrap up with a common mistake many make when measuring risk in the product development process. There is an obvious difference between the likelihood of a negative outcome and the financial impact if the negative outcome occurs as the graphic below shows.

However, many confuse a constant likelihood of a negative occurrence (scenario A – unmanaged risk in the graphic) with a constant level of financial impact when, in fact, it is growing dramatically throughout the product development process as investment and costs to remediate omissions, defects, and reputation grow over time. The only way to maintain a constant and low level of risk is to actively manage down the likelihood of a negative outcome continuously through the development process as shown as scenario B in the graphic. For a deeper dive into this concept please check out a fine piece by Preston Smith in Research- Technology Management, Managing Risk as Product Development Schedules Shrink, and the source of the graphic above.

Watch this webinar to learn more about moving away from documents-based design control and risk management.

WATCH THE WEBINAR

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:

The end-to-end process to deliver product is fragmented into siloed teams, activities, and tools
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.

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:

	STATIC Requirements	LIVING Requirements
Item-level thread to all downstream process states	X	✅
Impact of change easily determined	X	✅
Exception reporting on missed requirements	X	✅
Compliance is highly automated	X	✅
Enables end-end process improvement	X	✅
Enables benchmarking performance	X	✅
Team productivity improvements	X	✅
Overall product risk reduction*	X	✅

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.

Jama Connect’s Requirements Management Enables Live Traceability™ Across Your Development Process.

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