Tag Archive for: requirements management

Centralizing Requirements

What is the truth?” can sound like an abstract philosophical question with no definitive answer. But for teams developing complex products like medical devices and connected cars, it’s a much more practical concern – as in, the truth about the current state of the project’s requirements, risks, and tests is often unclear. This is where centralizing your requirements, test, and risk in one place is key.

This uncertainty stems mostly from inefficient tools and processes for requirements management, rather than from anything that someone did wrong. More specifically, the widespread reliance on emailed documents and on general-purpose software such as Microsoft Word and Excel limits collaboration and results in miscommunications, silos, and rework.

The silver lining of this situation is that it’s possible to find the truth, once better tools are in place. A requirements, risk, and test management platform that centralizes everything into one system of record can provide the single source of truth missing from many product development processes.

The Problem with Having Multiple Versions of the Truth

When project activities are spread across different documents and communications channels, it becomes difficult for teams to coordinate their workflows and gather, author, and ultimately move forward with agreed-upon requirements – i.e., “the truth.” Instead, multiple disparate versions fill the vacuum, meaning outdated or flawed requirements make it too far into development.

The annual Project Management Institute (PMI) Pulse of the Profession survey has, over the years, flagged this particular issue as a common impediment to project management success. For example, the 2017 edition found that inaccurate requirements gathering, along with poor communication and problems managing frequent changes in priorities, was among the most cited challenges in project management.

The 2020 edition also highlighted the growing strategic importance of using modern technologies to support complex projects. Respondents thought that selecting the right tools and improving organizational agility were the biggest determinants of project success. In other words, relying on manual processes and aging platforms will hold organizations back by making it more challenging to find a single version of the truth and use it to respond to change.

Looking at these results, it becomes apparent both how multiple versions of the truth can arise and how legacy tools worsen the issue:

  • As projects evolve, key updates are manually circulated in lengthy documents that can get lost in inboxes. This communication process complicates the tracking of requirements and the changes to them, leading to different versions of the truth plus long review cycles.
  • Given the pace and complexity of development, it may also never be clear if a document is the latest one, or if it accounts for all risks. Teams may end up in silos, while attempts at reconciling various documents begin too late or are just too time-consuming to succeed.
  • Since Word and Excel are not specifically built for managing requirements, they require a lot of extra manual work for this purpose. For example, teams have to create their own ad hoc processes for adhering to industry standards when using documents and spreadsheets.

Similar problems exist with legacy requirements management (RM) platforms like IBM® DOORS®, which make difficult to integrate with other tools while also constraining users with outdated and cumbersome capabilities for change management, impact analysis, and requirements traceability.

Making the Upgrade: How Centralization Benefits Product Development

Creating a single source of truth, one that’s both authoritative and easy for contributors to access, is essential when building complex products. To see why, consider the case of electric vehicle manufacturer Rimac Automobili, which had previously recorded most of its requirements in Word and Excel.

Decentralized vs Centralized RM

Under this old, decentralized way of managing requirements, siloed teams often moved forward with key changes without consistently communicating the details and effects of these decisions to others. Sending an email describing the update did not guarantee that someone would really know what was going on, or it could get buried beneath many other messages.

Although the company also used OneNote to create a list of numbered requirements, those identifiers often became quickly outdated. Multiple versions of the truth emerged from the confusion of using different applications and numbering systems to manage requirements

As a result, review processes became cumbersome as teams struggled to stay in sync. But Rimac saw comprehensive improvement in its RM processes once it implemented Jama Connect, a single platform for managing requirements, risks, and tests.

The Advantages of Centralizing Your Requirements in One Place

By making the switch, the company established a unified system of record (i.e., one version of the truth), in which project contributors could reliably see current requirements along with their historical contexts and how they connect to tests.

The more specific benefits of implementing a requirements management platform like Jama Connect include:

Real-Time Collaboration

Not only does everything product development related live in the same platform, but any changes to items can be efficiently communicated to contributors for quick, informed action. After being notified, team members can collaborate in real time in a shared system, with up-to-date statuses, rather than asynchronously over email.

Simplified Compliance

When multiple versions of the truth are in play, it becomes much more challenging for teams to ensure that everyone’s different processes have been aligned around specific industry standards and will meet compliance requirements. A centralizing your requirements in one platform eliminates this doubt while also saving time, with guided workflows and frameworks.  The end result is a more straightforward way to prove compliance with industry-specific regulations and standards.

End to End Traceability

Traceability is difficult when managing requirements across multiple systems and manual processes. In contrast, centralizing your requirements in one solution like Jama Connect automatically saves user inputs, allows you to view the impact of change before the change is made, and ensure product quality with complete coverage.  Traceability in Jama Connect ultimately allows you to view related product data to make better decisions throughout the development lifecycle.

Jama Connect can help you create one version of the truth for your product development processes. Learn more by connecting with us today.

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

 SEE MORE RESOURCES

Requirements ManagementBeing a former McKinsey consultant, I have spent too much time immersed in frameworks, maturity models and methodologies. As I age, and my pragmatism grows, I find that many maturity models are too high level and vague and do not reflect the actual progression companies go through as they mature a given business function.     

What I do find extremely useful are empirical maturity models since they categorize what companies are ACTUALLY doing TODAY in response to given challenges and pressures. Unfortunately, most models, rather than providing empirical data, are often just theory. The reason for this is because frequently, the author does not have access to large numbers of relevant companies willing to share their experience.   

At Jama Software, we are quite fortunate to be working with hundreds of organizations immersed in maturing their requirements management approach within a broader product development process. Some are motivated to mature their requirements management process to reach compliance with relevant standards, others have experienced significant delays, cost overruns, or defects and are looking to improve process performance while the most advanced are able to measure end-end process performance and benchmark themselves against others. 

The table below shows the key dimensions of requirements management and the five maturity levels we observe within our customer base.    

Requirements Management Maturity Model 

Requirements Management

Let me start by describing the key dimensions: 
  • Change Control – The process by which requirements are documented, versioned, reviewed, approved, tracked, centralized, access controlled, updated, and referenced post–decomposition into development. 
  • Compliance Reporting – The generation of the necessary proof of process compliance to standards, most commonly: requirement validation, verification, traceability, risk assessments and test results.  
  • Living Requirements™ – Visibility and traceability of the state of each requirement and its downstream decomposition, development, and testing at any time from requirement draft through to product release. Requirements that are not living are static and trapped in documents with no system linkage to the entire product development process.  I discuss this topic in more detail in this earlier blog: Requirements Management: Living vs. Static. Living Requirements reduce common product development risks of delays, missed requirements, rework, compliance gaps, limited reuse, defects, and recalls.   
  • Process Improvement – Manage the product development process through data with the end-to-end visibility provided with Living Requirements. Cycle time targets at various stages, rework percentages, process exception reporting, etc.  
  • Benchmark – Once the end-to-end product development process can be measured, it can then be compared to peer organizations to determine areas to focus on for further process performance gains. 
Organizations are at different levels of requirements management maturity across these dimensions. Here are descriptions of each level:


(0) No Formal Requirements – No documentation exists for user or system requirements. Instead, development operates off user stories with no clear distinction between the functionality of the system being built and the expected user experience. 

(1) Document-Based Requirements – Static requirements documents are created and most often maintained by each author on his/her desktop with various emails, Slack comments, etc. containing more information.   

(2) Siloed Requirements Tool – A standalone tool is in place to draft, review, track comments, version, and store static requirements documents. 

(3) System-Based Compliance – Compliance is the forcing function to shift from static to Living Requirements to meet standards for requirement validation, verification, and traceability in a single end-to-end system.       

(4) Product Risk Reduction – A process-centric focus to reduce the likelihood of all forms of product risk via system–enabled Living Requirements. This requires detection and alerts for specification and functional changes, process exceptions, and test failures with the resulting impact analyses. The risks mitigated include: 

  • (a) Failure to meet the needs of customers 
  • (b) Failure to perform specified functions 
  • (c) Delays 
  • (d) Cost overruns 
  • (e) Defects 
  • (f) Compliance and regulatory gaps, delays, fines 
  • (g) Recalls 

(5) Development Process Improvement – Moving past compliance and risk and into the spirit of the standards based on quality management and process control.  A focus on measuring, managing, and improving the product development process. 

Current Level of Maturity 

Now that the model has been described, the first question is: Which maturity level best describes your organization today? Before working with us, most companies we speak with are either using Microsoft Word/Excel and at level 1 or frustrated with their current tool and struggling to move much past level 2. Our top customers are at level 4 and moving to level 5.  

Desired Level of Maturity 

Once you have made an honest assessment of what level your organization is currently at, the next step is to determine your desired maturity level and gain organizational support for the change. We generally do not recommend jumping more than 2 levels for the first stage of a process change.   

Next Step 

Once you have completed your self-assessment of current and desired maturity levels, we would encourage you to reach out to us to speak with one of our consultants.  We will listen to understand your organization’s unique needs and provide some guidance on best practices based on years of clients’ success. 

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

 SEE MORE RESOURCES

 

 

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 POST: See How Infineon Transitioned 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:

 
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 

 ✅  

 

RELATED POST: Requirements Traceability: How To Go Live

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.

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! 

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

 SEE MORE RESOURCES

 

 

 

 

 

 

Jama Deminar SeriesWith over 12.5 million active users, organizations around the globe rely on Jama Connect to help bring complex products to life. Innovative companies choose Jama Connect to improve quality, reduce rework, prove compliance, and get to market faster.

That’s why we’re excited to announce a six-part series of deminars (yes, you read that right – it’s a demonstration webinar!) where we’ll be giving you an inside look at the leading platform for requirements, risk, and test management. In this deminar series, we’ll cover key features and capabilities, seamless integrations, best practices, and more.

Below is a snapshot of when each deminar will happen, what will be covered, and how you can save your spot.

Product Essentials: A Quick Tour of Jama Connect for Modern Requirements Management

Thursday, September 10 – 8:00 a.m. PT | 17:00 CEST

Jama Connect enables consistency, collaboration, and alignment across the enterprise by providing a continuous flow of accurate requirements information. This webinar demonstration tour provides an overview of the Jama Connect platform.

In this demonstration session, you’ll learn how to:

    • Establish alignment across people, process, and technology to establish a single source of truth around digital requirements management
    • Collaborate across both internal and external teams using Review Center
    • Use traceability views to provide visibility across the entire product development cycle
    • Utilize our common integrations to extend the solution capabilities — including JIRA
    • Use Jama Connect to support testing, change management and impact analysis

Product Essentials: How to Streamline Reviews and Collaborate with Remote Teams, Customers, and Suppliers with Jama Connect.   

Thursday, September 24 – 8:00 a.m. PT | 17:00 CEST

Through structured collaboration in Jama connect, teams can source feedback from distributed teams and collect side-conversations in an actionable way to gain cross-team visibility.

In this demonstration session, you’ll learn how to:

  • Easily establish communication and document decisions across virtual teams
  • Immediately notify and prioritize critical decisions and pull in required contributors throughout the development process
  • Hold formal reviews and document those decisions in Review Center
  • Exchange requirements with remote teams, customers, and suppliers to extend the development process beyond your core team

REGISTER NOW

Product Essentials: Unpacking Requirements Traceability Capabilities of Jama Connect

Thursday, October 8 – 8:00 a.m. PT | 17:00 CEST

In this session you’ll learn how Jama Connect capabilities provide requirements traceability which improves product development accuracy and/or quality and ensures the ability to provide trace reports for audits. Learn how various options are used to track relationships to/from/between requirements and understand the full impact across the project.

In this demonstration session, you’ll learn how to:

  • Create relationship guardrails to ensure traceability rules will guide users and prevent dependency chaos
  • Right click to build relationship dependencies as you perform everyday work activities
  • Use trace view to:
    • Identify relationship dependencies between data
    • Track progress and identify missing work items
    • Analyze potential impact of changes
    • Gain visibility needed for prioritizing lower level work items against higher level requirements
  • Use item widgets to:
    • View impact analysis to understand the potential impact of change
    • Initiate conversations between connected users
    • Export relationship dependencies to support compliance audits

REGISTER NOW

Product Essentials: Using Jama Connect and JIRA to Manage Requirements for Software Development Teams

Thursday, October 22 – 8:00 a.m. PT | 17:00 CEST

In this session you’ll learn how Jama Connect provides the ability to link JIRA tasks and defects to requirements for full transparency, traceability, and change management throughout the software development process. Product and engineering teams can connect product planning to execution and stay in sync to ensure accuracy and quality of work.

In this demonstration session, you’ll learn how:

  • Link issues and defects from JIRA to Jama Connect
  • Support conversations across the team between the requirements and epics throughout the software development process
  • Analyze—at a dashboard level—the state of the tests, stories, and epics related to a project
  • Use the two-way integration between Jama and JIRA to allow the flow of information back and forth across the teams with synchronization, providing a single source repository and full traceability

REGISTER NOW

Product Essentials: Sharing How Jama Connect Allows for Earlier Testing in the Lifecycle to Increase Quality and Efficiency.

Thursday, November 5 – 8:00 a.m. PT | 17:00 CET

Through testing in Jama connect, teams can achieve value by incorporating the results of the test strategy into the product strategy and identify potential defects earlier in the product development lifecycle, which prevents late stage changes leading to costly rework.  Learn how Jama Connect provides full manual testing capabilities tied into the product development process ensuring that you release a best-quality product that meets customer expectations.

In this demonstration session, you’ll learn how to:

  • Create a test case and configure filters to quickly access requirements that have no test coverage
  • View test cases, the tests associated, and test run results to analyze test coverage and easily view any gaps
  • Log defects from the testing interface and view automatic trace relationships
  • Export reports to support compliance activities

REGISTER NOW

Product Essentials: Working with baselines in Jama Connect to Facilitate Compliance and Reuse in Product Development.

Thursday, November 19 – 8:00 a.m. PT | 17:00 CET

Learn how to view and create a baseline to capture and preserve the project at a single point in time. This supports compliance and enables reuse in product development projects.

In this demonstration session, you’ll learn how to:

  • Coordinate product releases across teams and projects
  • Easily create a baseline release and track it effectively throughout the development of the product
  • Navigate the workflow across teams to support release schedules
  • Use baselines to fulfill regulatory requirements (with respect to record keeping) by producing a clear and readable audit trail.

REGISTER NOW

To view the full series, watch recordings of the deminars after they happen, or register for individual deminars, visit our Product Essentials page.

SEE ALL DEMINARS

Best Practices for Writing Requirements Better requirements lead to clearer, more effective communication between a product’s stakeholders — creating ripple effects across the entire organization including greater transparency; less rework; and, accelerated development without sacrificing product quality. While writing requirements is both an art and a science that will vary by context, there are a few best practices to consider.

In an ideal world, every individual user, business, and functional requirement would exhibit the following qualities: complete, correct, feasible, necessary, prioritized, unambiguous, verifiable, consistent, modifiable, and traceable.

We recently created an infographic of best practices to help keep teams aligned and reduce the chance of rework and product failure.

Download the full infographic to learn learn more about writing requirements, including:

  • Understand the problem
  • Define requirements hierarchy
  • Let the designers design
  • Be unambiguous
  • Use requirements templates and group discussions
Read the full infographic to see our tried and true best practices for writing requirements.

 

Ask Jama Release Management Webinar

Because we’re always looking for ways to support and enable our customers’ success, we’ve created this Ask Jama webinar series to keep you up to date on new product information, best practices, and tips and tricks on how to best use the platform. By popular request, the topic of this upcoming webinar will be Release Management options in Jama Connect. 

Ryan Moore, a Jama Connect expert and a consultant from our Professional Services team, will be discussing options for managing releases within Jama Connect. Concepts we’ll be covering include:

  • Leveraging Jama’s release field
  • Re-use and synchronization
  • Branching vs. mainline approaches

We’ve also made sure to include plenty of time to answer your questions around release management (or other relevant topics) during the event.

Date:        Wednesday, July 22nd, 2020
Time:        8:00 – 9:00am PST
Presented by:

 

Ryan Moore – Consultant, Jama Software
Ryan is a Business Consultant on the Professional Services team at Jama. He works directly with customers to implement Jama Connect, and help navigate requirements management, through best practice guidance.

Watch the recording now!

WATCH NOW

 

Requirements Management
EDITOR’S NOTE: This post on requirements was originally published here, by Medium, and this article was adapted from Software Requirements, Third Edition, by Karl Wiegers and Joy Beatty. If you’re interested in software requirements management, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources.

Creating a Culture that Respects Requirements

The leader of a corporate requirements organization once posed a question. “I’m experiencing issues in gaining agreement from some of our developers to participate in requirements development,” she said. “Can you please direct me to any documentation available on how developers should be engaged in the requirements process so I can help them understand the value of their participation?”

In another organization, a business analyst experienced a clash between developers seeking detailed input for an accounting system and an IT manager who simply wanted to brainstorm requirements without using any specific elicitation techniques. “Do readers of your book risk cultural conflict?” this BA asked me.

These questions exemplify the challenges that can arise when trying to engage business analysts, developers, and customers in a collaborative requirements partnership. You’d think it would be obvious to a user that providing requirements input makes it more likely that she’ll get what she needs. Developers ought to recognize that participating in the process will make their lives easier than being hit on the head by whatever requirements document flies over the proverbial wall. Obviously, not everyone is as excited about requirements as the typical business analyst is.

Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary.

Get Buy-In for a New Process

It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not worth their time. Understanding why people resist participating in requirements development is the first step to being able to address it.

It’s possible the resisters haven’t been exposed to solid requirements practices. Or they might have suffered from poor implementation of requirements processes, perhaps working on a project that produced a large, incomplete, and ignored requirements specification. Those experiences would leave anyone feeling frustrated.

Perhaps the resisters don’t understand and appreciate the value of those practices when performed effectively. They might not realize the price they have paid for having worked in a casual and unstructured environment in the past. That price mostly shows up as unexpected rework that leads to late deliveries and poor software. Such rework is buried in the daily activities of the project participants, so they don’t recognize it as a serious inefficiency.

If you’re trying to get developers, managers, and customers on board, make sure everyone understands the past pain the organization and customers have experienced because of requirements problems. Find specific examples to demonstrate the impact in case individuals haven’t felt the pain themselves.

RELATED: Three Reasons You Need a Requirements Management Solution

Quantify the Costs of Requirement Problems

Express the cost in units that are meaningful to the organization, be it dollars, time, customer dissatisfaction, or lost business opportunities. Development managers often aren’t aware of how badly requirements shortcomings hurt their teams’ productivity. So show them how poor requirements slow down design and lead to excessive — and expensive — course corrections.

Even if you don’t have data available to quantify the costs of requirements problems, every organization has an anecdotal legacy of project failures. People remember systems that were dead on arrival, rejected by users as unacceptable. Isn’t it strange how project teams never feel they have the time to devote to getting the requirements right, and yet they always find the time, staff, and money to fix systems that were deeply flawed because of requirements errors? Use such stories from the corporate folklore to help steer the culture to recognize that, without solid requirements, failure is highly likely.

Developers are stakeholders in the project, but sometimes their input isn’t solicited and they become the “victims” of the requirements that are thrust upon them. Therefore, they benefit from providing input that will make the requirements documentation as useful and meaningful as possible. I like to have developers review requirements as they are evolving. That way they know what’s coming and can spot areas that need more clarity.

RELATED: The Business Value of Better Requirements Management

Get Input from Developers, QA, and Testers

You also need developer input when specifying internal quality attributes that aren’t visible to users. Developers can offer suggestions no one else might have thought about: easier ways to do certain things; functionality that would be very expensive to implement; unnecessary imposed design constraints; missing requirements, such as how exceptions should be handled; and creative opportunities to take advantage of technologies.

Quality assurance staff and testers are also valuable contributors to excellent requirements. Instead of waiting until later in the project, engage these sharp-eyed people in the iterative review of requirements early on. They’re likely to find many ambiguities, conflicts, and concerns with the requirements as they are developing their test cases and scenarios from the requirements. Testers can also provide input on specifying verifiable quality attribute requirements.

Management Needs to Lead the Charge

Management plays a dominant role in shaping an organization’s culture. The leadership must understand the need for the organization to have effective business analysis and requirements engineering capabilities as strategic core competencies. Yes, project-specific and localized grassroots efforts are important. But without management commitment, the improvements and benefits likely won’t be sustained after the project ends or after a reorganization. It doesn’t help if your senior people say they “support” the improvements but then revert to the same old processes the minute there is a fire.

Behaviors — not pronouncements —are evidence of a commitment to quality. Figure 1 lists ten signs that your organization’s management is truly committed to excellent requirements processes.

Requirements Management

Figure 1. Some behaviors that indicate management’s commitment to excellent requirements processes.

Resistance to process or culture change can indicate fear, uncertainty, or lack of knowledge. If you can discern the source of the resistance, you can confront it with facts, reassurance, clarification, and education. Show people how their constructive participation in the requirements process not only is in their personal best interest but also will lead to collectively better results. Everyone wins when they work together toward a common objective.

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

SEE MORE RESOURCES

jama connect for medical device development

Infographic: Jama Connect™ for Medical Device Development

We’re excited to share our latest infographic for the Jama Connect for Medical Device Development solution which explains how Jama Connect can help accelerate innovation, maintain product quality, and manage the ever-changing complex regulations in medical device development. This is a single powerful platform for medical device teams to manage design controls for device requirements and related risks, simplifying regulatory submissions, and audit preparations while accelerating time to market.

RELATED: Your Guide to Selecting a Medical Device Development Platform

Bringing a medical device to market requires navigating a sea of complex and ever-changing regulations, not to mention bearing significant costs along the way. A device recall can cost $600 million, while the indirect costs of lost revenue and diminished market cap are even higher at $1-3 billion per company. Those costs are especially significant considering the price tag of product development—$75 million in FDA compliance alone, and an average timeline of three to seven years.

→Jama Connect customers have been able to reduce planning time as much as 80%, thanks to consolidated feedback replacing emails and a document-based approach to project management.

→Better quality products get out the door faster. By understanding the impact of change, capturing decisions and feedback in real-time and reusing existing IP, Jama Connect reduces medical device development time by an average of 130 days per project.

→Jama Software reduces rework, which accounts for approximately 30-50% of a given project and arises from issues such as requirements errors. Improving the ability to track requirements from design through verification and validation ensures teams build the right medical devices with the lowest possible lifecycle costs.

In this infographic, we share how, with the right requirements management solution, you can accelerate the development of cost-effective products that also comply with both safety and quality standards.
You’ll learn: 
  • How to overcome the biggest challenges in medical device development 
  • The ways Jama Connect for Medical Device Development can help 
  • Keys to unlocking a better customer experience 

 

application lifecycle management tools

Application lifecycle management (ALM) tools enable efficient, standardized communication and collaboration between teams in application development, testing, and other business departments. The benefits of a top ALM platforms include less risk from manual and siloed application lifecycle management processes, plus superior confidence in the outcome of compliance and product quality.

What is application lifecycle management?

ALM itself is a broad term. It encompasses key activities across requirements management, quality assurance (QA), IT service delivery, and project management. By spanning all of these diverse activities, ALM may include every workflow from mapping out a preliminary route to regulatory approval for a software-driven medical device, to the testing of that same product in alignment with its requirements and its eventual post-release maintenance.

The exact structure of ALM, and the particular solutions selected to support it, will vary based on the software development practices in use at an organization. For example,  ALM can support Agile methodologies as well as DevOps automation processes built around continuous integration and deployment pipelines. In these instances, an integrated ALM process, backed by the right ALM platform, helps bring teams together and ensures all requirements are met for each application.

Application lifecycle management tools can also work within Waterfall methodologies in which activities are broken down into discrete stages instead of approached continuously. Process-agnostic ALM platforms may be configured to support a variety of software projects and extended to support hardware initiatives that revolve around product lifecycle management (PLM), too.

In fact, ALM first emerged as a software-specific evolution of PLM, which applies to physical products such as automobiles. Organizations may seek integration between their ALM and PLM process and technologies to maximize the efficiency of their development processes, such as in the case of a complex connected device within the Internet of Things (IoT).

What do application lifecycle management tools do?

At a high level, best-of-breed modern ALM platforms may provide tools for:

Requirements management

Traditional processes for managing requirements are outdated, as they often involve maintaining numerous Microsoft Word documents and/or spreadsheets, all of which may need to be developed and reviewed separately. This approach slows down the application lifecycle while increasing costs by introducing unnecessary risk related to human error.

In contrast, an ALM tool form offers a comprehensive solution for requirements management. Teams can define all requirements, risks, and tests, plus create virtual relationships between work items, perform risk analysis, and have easy visibility into the potential impact of making changes. Requirements can be scheduled and managed from one interface.

Essentially, the ALM platform serves as a single source of truth where costly rework and time-consuming reviews of multiple siloed data sources can be avoided. Meanwhile, development processes are typically accelerated through substantial reductions in the time needed to identify and remediate requirements-related defects.

RELATED: How Better Requirements Management — and Requirements Management Tools — Can Improve Your Product Development Process

End-to-end activity traceability

With applications being developed on increasingly fast timelines and in accordance with a growing array of requirements and regulations, traceability is crucial.

Are development and testing activities adequately fulfilling all defined requirements (on both general and granular subsystem levels)? Are there any gaps in test coverage? Can proof of requirements fulfillment easily be reviewed, signed, and used to demonstrate compliance?

Getting reliable answers to these questions and others requires a capable ALM platform. The right ALM platform provides solutions for creating virtual trace relationships between requirements, risk, tests, and other development activities. More flexible ALM platforms can be extended through toolchain integrations (see below) to capture activity traces across teams and platforms. Virtual traces also tie electronic signatures to any defined milestones and released documents, as well as provide a way to see and analyze the potential impact of making changes. Proof of requirements fulfillment (i.e. trace views and matrixes) should be easy to monitor and export to demonstrate compliance.

RELATED: How Adopting Modern Traceability Leads to Better Products

Software testing and QA

Testing is an important part of ALM. More specifically, test results will need to be continually updated to accurately reflect the progress of an application’s lifecycle.

Keeping track of these details is more practical with a modern ALM platform that makes it easy to see the status of existing test results, add new tests as needed, and perform time-saving batch updates that capture or change the status of multiple test executions, all in one repository

With the right application lifecycle management tools, these testing and QA processes can be greatly streamlined by providing teams greater visibility into the requirements that inform their work. Accordingly, teams can get the most from their Agile processes and deliver the highest quality software to market as quickly as possible.

Real-time team collaboration

ALM is a fundamentally collaborative endeavor, as it spans a wide range of activities from project management to QA. But efficient collaboration can’t be taken for granted – teams need intuitive collaboration technologies to keep their work aligned and on track.

The real-time collaboration capabilities in an ALM or ALM-adjacent tools enable productive reviews and approvals. Features such as virtual reviews and electronic signatures containing a complete timestamp provide structured solutions for distributed/remote teams to streamline collaboration and ensure compliance with regulatory standards.

Feedback can be captured in one place, allowing for items to be quickly and efficiently categorized as approved or in need of work. Centralizing collaboration features with requirements management provides a solution to track which stakeholders are involved so that follow-up actions can be appropriately assigned as necessary. Moreover, it reduces the risks associated with protracted project times and personnel churn, as knowledge it retained in the system itself rather than in individual minds, making key insights readily available down the line.

RELATED: Innovation Can’t Happen Without Collaboration

Toolchain integration

Multiple platforms may be combined to handle all of the different aspects of ALM-PLM. Platform extensions are typically constructed through built-in integrations or through the use of open APIs that support custom work.

The integration of platforms is important to keep activities, such as software development, properly aligned with requirements. An ideal integration allows for essential information to synchronize between platforms, facilitating collaboration, and improving visibility across otherwise siloed teams and/or technologies. In many cases, a toolchain integration offers a solution for improved traceability to demonstrate compliance.

Testing tools, task, and bug tracking software, and automation servers have great potential for integration with application lifecycle management platforms. Overall, an integrated ALM toolchain will lower risk and lead to better quality and compliance. The integration between Jama Connect and Jira is a prime example of how pairing different best-in-class platforms can increase visibility and support the work of global teams.

To learn more about Jama Connect, visit the main product development page, or get in touch with a member of our team.

To learn more on the topic of requirements management, we’ve compiled a handy list of valuable resources for you!
SEE MORE RESOURCES

 

How to Choose the Right Tool for ASIL D Requirement Management ISO 26262 / IEC 61508

Editor’s Note: This posts on tool selection around ASIL D requirement management for ISO 26262 / IEC 61508 was originally published here by LHP Engineering Solutions and written by Steve Neemeh. When the options for choosing a requirements management tool are endless, what factors should you be looking at to help make your decision? This article provides some concrete considerations you may use to guide your selection.

requirement management

 

Which tools should I use for ASIL D requirement management ISO 26262 / IEC 61508?

There are a multitude of requirements management tools in the marketplace (e.g., IBM DNG, Siemens Polarion, Jama Software, Helix). How does an organization make the important decision of which is best for its needs when the options are endless or when using Microsoft Word/Excel or Google Docs for requirements management can be considered? Is there even one tool that can meet all of the organization’s needs? This blog will describe why selecting a tool based on one specific departmental need, such as requirements management, might be impractical.

To begin the search, here are five items that might be considered:

1. Cost of Tools
  • The range of costs can vary significantly. For a small organization, some of the larger toolchains may not be affordable. On the other hand, some of the smaller tools may not address parts of requirements management that are critical for ASIL D development.
2. Size and Distribution of the Organization
  • How many engineers need the tools and in how many locations? Some license agreements are floating so utilization could be optimized if the tools are used across multiple time zones (e.g. India and USA).
3. Number of Requirements and Requirements Hierarchy
  • Are there 100 safety-critical requirements or 5,000? Out of these requirements, how many of them are related to software, hardware, or test cases? How large is the HARA and how many safety goals are there? This will define the size of the requirements hierarchy.
4. Existing tools
  • The selection and integration of a new tool will inevitably impact the use of the exiting toolchains.
5. Full ISO 26262 workflow
  • Refer to V diagram.
requirements management ISO 26262 / IEC 61508

LHP’s requirements management V diagram for the Application Lifecycle Management toolchain

 

When researching tools for an organization, it is a common discovery that there is not one tool that meets all of the needs. The tools industry has not caught up with the complexity of the safety lifecycle. What is found in the marketplace are versions of Application Lifecycle Management (ALM) tools, but what is really needed is an LHP ecosystem-based Safety Lifecycle Management (SLM) toolchain. This SLM is based on guidelines for safety-critical development as defined in the 700+ pages of requirements, work products, and methods in standards such as ISO 26262 or the Safety of The Intended Functionality (SOTIF).

What is the Workflow for Functional Safety, ASPICE, and Other Safety-Critical Applications?

The V diagram covers the foundational items that need to be considered in addressing a standard like ISO 26262: project management, task management, and change management. In this particular case, four tools have been considered: ANSYS Medini, Jama Software, Atlassian JIRA, and National Instruments. All four tools provide partial solutions to meeting the needs of functional safety.

  • ANSYS Medini: HARA and systems-level modeling, as well as hardware metrics calculations (Parts 3 & 5 of ISO 26262)
  • Jama Software: Requirements management (required by ISO 26262, emphasized in Part 8)
  • Atlassian JIRA: Project management and change management
  • National Instruments Tools: Automated test and test scripting

By combining the engineering best practices with the tools’ strengths and considering an organization’s main drivers, a workflow can be defined; one that optimizes tool usage and reduces the load on engineers. Ultimately, to be successful within safety-critical development, an organization needs to develop against a standard while also reducing the labor associated with engineering and testing.

Without the latter, the cost and time for development escalate exponentially. Are engineers going to copy and paste data across tools? Are they going to have multiple versions of the same information across different toolchains? As the complexity of systems increases, a non-optimized toolchain can paralyze an organization and its development process.

In the absence of a commercial off-the-shelf fully-compliant SLM tool, the solution of integration tools can provide the same functionality. For this purpose, the tools provide methods of connectivity with REST (Representational State Transfer) API. An example of a REST API between Jama Software and JIRA is shown in the appendix.

Conclusion

When selecting a requirements management tool, it is crucial to consider the needs of the organization as a whole, the safety workflow, and the customization and connectivity for optimization of the tools. In a typical implementation of a safety-critical system, most organizations just consider one, or parts of one, of these critical items, causing large rework and tool spend that can otherwise be avoided.

Take-a-Ways
  • There is no one tool that meets the needs of requirements management in compliance with functional safety.
  • The tool capability varies greatly based on cost, and there is feature overlap between tools.
  • The holistic organization, not just a single department, needs to be involved in making the tool selection. The needs of each department: management, engineering, IT, manufacturing, regulators, and even certification agencies all must be considered.
  • The tool must be appropriate for the size and scale of the organization.
  • There are methods of automating data transfer that significantly reduce labor and cost on development programs (as shown in the appendix).
  • Successful organizations are going to get ahead by creating efficient workflows that allow them to release products faster and more economically in the new electric vehicle/autonomous vehicle (EV/AV) world of transportation.
Appendix: More Details About REST API

Both Jama Software and JIRA provide access to their cloud resources via Representational State Transfer (REST API). REST is a web-based application programming interface that exposes a set of Uniform Resource Locators (URLs) with which to carry out Create, Read, Update, Delete (CRUD) operations in the tool. LHP Engineering Solutions has implemented a Domain Object Model (DOM) connection for both Jama Software and JIRA with a third integration piece to connect the two. The integration piece is a configurable application that implements the customer use cases.

REST API integration

Benefits of Using REST API
  • Ease of implementation
    • REST is a standard specification of how to access web resources
    • All web and cloud-based tools expose REST APIs
    • Returns data, as well as metadata, which allows for conditional and iterative processing
    • Implemented in a JAVA wrapper making it configurable and portable to any system
  • Customizable authentication feature
    • Simple user and password authentication if desired
    • Simple user and access token authentication if more security is desired
    • OAuth authentication is also available but not required
  • Portability of output to Web and other tool frameworks
    • XML/JSON that any tool can consume
    • XML/JSON are standard serialized data formats for web resources
    • Web applications typically take XML/JSON as input files for data exchange, data migration, report building, etc.
REST API Complexities
  • Requires a non-standard mapping of attributes from Jama Software to JIRA and vice-versa. Each customer mapping will need to be customized.
    • The REST specification defines what the API should do but not how it should do it. No standardization of data schema. Therefore, tools will have disparate data models.
    • Attribute A in Tool A must be mapped via a mapping file to Attribute B in Tool B etc. This goes for attributes, links, attachments, and all data elements in each data model.
    • A UI will have to be developed to allow for the mapping creation and management.
Standard Feature Set of REST API
  • Mapping and transfer of attributes and attachments from one tool to the other
    • Data models are mapped as closely to 1:1 as possible
    • UI to build and manage mappings
  • Scheduled and on-demand synchronization
    • Synchronization data between toolsets via UI
    • Synchronize data between toolsets by scheduling a task
  • Intermediate transformations (e.g., risk calculations)
    • Calculating or transforming the data from the source tool before reaching the target tool
  • Linking from one tool to the other via hypertext links
    • URLs from source resources to target resources and vice versa for traceability
  • Reports
    • Since the REST APIs produce a consumable output, any reporting tool that can consume XML/JSON can be used to produce reports.
      • Jama Software reports
      • JIRA reports
      • Requirements gap analysis
      • Test coverage gap analysis
      • Requirements Traceability Matrix
      • Bug reports
      • Customized reports
We’ve compiled a list of helpful resources for requirements management in automotive development, click the button to learn more!
SEE MORE RESOURCES