Tag Archive for: Requirements & Requirements Management

DOORS

Jama Connect® vs. IBM® DOORS®: Document Generation: A User Experience Roundtable Chat

Increasing industry challenges and complexities are pushing innovative organizations to consider modernizing the tool(s) they use for requirements management (RM). In this blog series, Jama Connect® vs. IBM® DOORS®: A User Experience Roundtable Chat we’ll present several information-packed video blogs covering the challenges that teams face in their project management process.

In Episode 5 of our Roundtable Chat series, Mario Maldari – Director of Solutions Architecture at Jama Software® – and Susan Manupelli – Senior Solutions Architect at Jama Software® – walk us through document generation and reporting in Jama Connect vs. IBM DOORS.

To watch other episodes in this series, click HERE.

Watch the full video and find the video transcript below to learn more!

VIDEO TRANSCRIPT:

Mario Maldari: Hello, welcome to part five of our vlog series. I hope you guys are enjoying the series so far. My name is Mario Maldari, director of Solution Architecture here at Jama. I manage a team of solution architects. Spent about the last 20 years working with requirements software tools and watching them evolve over time. Happy to have landed here at Jama where we’re working with the Jama Connect product, which is great tool as well as a great company culture. Joined by my friend and colleague, Susan Manupelli. Susan, would you like to introduce yourself?

Susan Manupelli: Sure. Thank you, Mario. So my name is Susan Manupelli. I’m a solution architect here at Jama Software. Prior to joining Jama, I was over at IBM where I worked on their engineering lifecycle management suite, primarily on the requirements management products. So Doors and Doors Next Generation. And I’m also happy to be here at Jama.

Mario Maldari: Thank you, Susan. And this vlog episode will be discussing document generation from requirements tools. And so we often encourage our clients to stay within the requirements tool for the purpose of versioning and tracking change on requirements. But there are valid reasons why you’d want to get your documents out. And that could be something from sharing your requirements with suppliers or customers, long term archival, submitting documentation to a formal documentation system. So many reasons why you’d want to get them out. And I guess the difference would be between the tools is how easy is that to do and how seamless can that transition to a document generation be. So Sue, I know you’ve worked with requirements tools in the past and specifically Doors Classic. And how is that experience for you?

RELATED: Why Investing in Requirements Management During an Economic Downturn Makes Good Business Sense

Susan Manupelli: So, sure. So first for Doors Classic, you can print Doors modules using a standard print window and there is some control over what the printed output is going to look like through something called page setups. However, the challenge there is that it doesn’t actually export it to a common format like Word or PDF. So in order to actually generate a word or PDF document, you have to use another tool from IBM called Pub, it was renamed from Rational Publishing Engine. So that’s another tool outside of Doors.

Mario Maldari: I see. And is it the same for Doors Next?

Susan Manupelli: Yeah, so with DNG, the situation’s a little bit better. Out of the box, DNG does allow you to export certain documents to Word or PDF, but the challenge there is that there are very few customizations that can be done. There’s a few trivial settings that you can make when you’re doing your exports. But in order to actually customize the output, you have to use again Rational Publishing Engine. And there’s a few challenges with that. So first of all, it’s a separately licensed tool, so you have to pay extra for that. Second of all, using RPE requires a knowledge of the rest APIs. So you basically end up meeting a programmer to customize the reports for you and create that template. And then the third thing is in order to take the template from RPE and upload it into DNG, you have to have administrative privileges to be able to do that. So the users are really limited in what they can do from DNG.

Mario Maldari: Yeah. And how is that received by the customer base?

Susan Manupelli: I think it’s fair to say they would prefer a lot more flexibility for the users to be able to make some simple adjustments to the reports.

RELATED: Why Investing in Requirements Management During an Economic Downturn Makes Good Business Sense

Mario Maldari: Yeah, that makes sense. Okay. Well I’d like to show you how this is done in Jama. And let me share my screen and show you some options here. So in Jama, most views when you’re looking at your requirements, most of the views can be exported into either Word, Excel, PDF, or even a customized template. And so this is kind of interesting here and key. So customers often, if they’re exchanging requirements with stakeholders, they’ll want to put their requirements in a particular format with some branding or logos. And so you can do that easily in Jama by just modifying a Word document, uploading the template, and then once you have that template available, you can have your exports go into that format very easily.

So there’s a few different options here in terms of custom templates. You can create your own, which is great. And so when you’re looking at a view of requirements like this reading view, it’s easy to export it into Word. And let’s see if I have that up. And so you can take a look, and this is a customized template that I’ve created and you can see that the very basic one with just a logo, table of contents and then you see your requirements. The pictures in terms of the description as well as the name and some other information as well that comes in. So really easy to do that in Jama in terms of customizing your export template.
And if that’s not enough, we also have reports available out of the box canned reports with a number of different options that can be set down to Word or PDF. So a lot of different options in terms of pre-canned reports. But if the out of the box reports aren’t giving you what you need, then we also have a velocity engine where a lot of our customers create their own reports as well. And if they don’t have a skill set in that they can come to our services team and we can do that for you, which we do often all the time.

So a lot of different options in terms of getting your requirements out. And I think the key, you know, had mentioned flexibility, and I think that’s the key differentiator with Jama is to be able to have that flexibility, not only in terms of tools to get it out and export it into, but also to be able to customize.

Susan Manupelli: I agree, definitely for the end users to be able to do the kinds of changes that they need, straight Word is really a huge benefit.

Mario Maldari: Yeah, I agree. So just to summarize with Document Generation. We encourage you to work within your requirements tool, do everything you can, your reviews, your approvals changes your requirements. But of course there are cases where you want to get your requirements exported and I feel as though Jama does a really good job supporting that and providing the flexibility as well.

Susan Manupelli: I agree. Sounds great. Thanks Mario.

Mario Maldari: Yeah, Sue, I’d like to thank you so much for your time today and looking forward to having more of these vlog series. And yeah, take care and we’ll talk soon.

Susan Manupelli: Thanks. Bye guys.

Thank you for watching our Episode 5, Jama Connect vs. IBM DOORS: Review and Collaboration. To watch other episodes in this series, click HERE.

To learn more about available features in Jama Connect, visit: Empower Your Team and Improve Your Requirements Management Process

We hope you’ll join us for future Jama Connect Jama Connect vs. DOORS topics, including: Migration & Data Mapping; Industry Templates; Reuse and Variant Management; Requirements-Driven Testing; Total Cost of Ownership; and Why Did We Move to Jama Connect? A Customer’s Story.

Review and Collaboration

Jama Connect® vs. IBM® DOORS®: Review and Collaboration: A User Experience Roundtable Chat

Increasing industry challenges and complexities are pushing innovative organizations to consider modernizing the tool(s) they use for requirements management (RM). In this blog series, Jama Connect® vs. IBM® DOORS®: A User Experience Roundtable Chat we’ll present several information-packed video blogs covering the challenges that teams face in their project management process.

In Episode 4 of our Roundtable Chat series, Mario Maldari – Director of Solutions Architecture at Jama Software® – and Vincent Balgos – Director of Medical Device Solutions at Jama Software® – walk us through reviews and collaboration in Jama Connect vs. IBM DOORS.

To watch other episodes in this series, click HERE.

Watch the full video and find the video transcript below to learn more!

VIDEO TRANSCRIPT:

Vincent Balgos: Hi, welcome to part four of our vlog series. I hope you are enjoying the series so far. My name is Vincent Balgos, and I’ll be representing Jama Software today. In terms of experience, I’ve been working at Jama for over nine months now, but before joining Jama, I was a systems engineer in the medical device field working on requirements, reviews, risk and collaboration. I’m actually a former Jama customer and have been using the tool in practice for over six years developing complex medical products. I’m joined today by my colleague, Mario Maldari. Mario, would you like to introduce yourself and provide some background?

Mario Maldari: Yeah, thanks Vincent. My name is Mario Maldari. I’m Director of Solution Architecture at Jama. Spent about 20 years working in various requirement solutions, started with Requisite Pro back in the day and started working on the DOORS family. DOORS, DOORS Next Generation, so a lot of history with requirements management software in different industries.

Vincent Balgos: Great. How long have you been working at Jama?

Mario Maldari: Just about a year now.

Vincent Balgos: Oh great, so similar to myself. Welcome to the team and look forward to the discussion.

Mario Maldari: Thank you.

Vincent Balgos: As part of this series, we will be discussing actually the requirements, review and collaboration across different various tool sets. As many of you know, working and reviewing requirements are essential tasks that requires a significant effort sometimes from drafting the initial spirit of the requirement to the solidification of the final language. It’s an iterative and collaborative effort that usually requires lots of different teams across different function groups. There are many tools that can help with review and common ones that we’ve seen are generally emails, Word, Excel, PowerPoint to more complex tools, which is our focus today. Today we’d like to actually talk about the Review Center, a review and collaboration within the DOORS and how’s that compare to Jama, with Mario’s experience at DOORS, what’s been your experience with performing these tasks under the DOORS?

RELATED: Jama Connect® Solution for IBM® DOORS®

Mario Maldari: Yeah, it’s been interesting. I think some of the challenges that our customers faced at the time were difficulty with the tooling itself, the way that the collaboration and the review was done within the tool or facilitated within the tool. What would happen is they’d often go outside the tooling. They’d start using Word or documents and they’d email this back and forth. Besides going outside the tool, you’d end up losing a lot of history in terms of auditability, who made the decisions, and how the requirements evolved. It diminished the purpose and the value of a formal requirements tool. When it’s difficult, people just go outside the tool and that’s what we were seeing a lot with DOORS.

Then as DOORS Next started evolving, things didn’t get much better. It was very difficult to use the reviews within DOORS next. I was a test lead at the time trying to review requirements and test cases. I found that the UI itself was very difficult to use and facilitate. Again, it was just people going outside of the tooling to go with whatever was easier for them. It was quite a challenge from a usability point of view.

Vincent Balgos: That’s really interesting and that’s a little bit different workflow that we have actually natively within our Jama tool. Let me actually walk you through that. As you can see, Mario, here is actually the review center within natively within the Jama tool itself. This is actually a review that I just held with my team and we were reviewing actually five different requirements. We were able to collaborate, live and provide comment, feedback, approval, rejection or needs a revisit, and as a moderator, I can actually see and manage the whole review center within a single tool right through here.

For example, we highlighted this particular area and Carleda had some interesting comment here, but that’s a single point of comment. A more interesting one is one that we actually had here. We were talking about tolerances for a particular gain field requirement and I asked Jakob @Jakob, Hey, is this enough? What about X, Y, Z? Jakob responded as we had here. You can see this kind of maintains some of that audit trail traceability that you kind of mentioned that tend to get lost in different emails and different tools and stuff like that. But you can see that this is all collected in a single tool within the Jama space.

What’s also nice, as you know again, as you’re going through the review, you can see what the status of the review is in terms of the number of comments that we have here on the left, the number of approvals that we have, and then somewhere we may actually need a little bit more time. For example, this one here, I had a lot of conversation that I may want to have to go back with my team and kind of resolve that we have here. With that said, what do you think about Jam’s workflow?

Mario Maldari: Yeah, I think Jama’s workflow in terms of the review and approval, I think the usability is key here. When the tool itself facilitates a certain workflow and it makes it easy for the customers to use, I think that’s key. What I like about this is it stores everything within Jama. A year from now I can go back and look and say, who made the comment to get this approved and what was the discussion around that? I can easily see that. At the same time, I can easily get that information out of the tooling should I ever need to send it to an auditor or send it to management. The key is it’s all kept within the tool. I like that a lot.

RELATED: Why Investing in Requirements Management During an Economic Downturn Makes Good Business Sense

Vincent Balgos: We just really just covered a very small snippet of the capabilities and power of the review center, but we can do exports, we can moderate this. There are additional capabilities here, but it’s great to hear that this is a more seamless flow. As you can see in the short demo, collaborating within Review Center is as easy as posting on social media where you can see comments, tag people, continue the discussion of the requirement or whatever you’re reviewing all within a single place. Jama allows live collaboration natively within the tool. Gone are the days, as you describe, Mario, about handling which email, which Word versions that we should be looking at. It seems a lot more efficient process than you described at DOORS.

Mario Maldari: Yeah, and it’s one thing too, you could formally manage your requirements in a tool and that’s great, but if you cannot have a workflow that facilitates a proper review and approval, then the tooling itself is very diminished. This kind of rounds off that whole workflow of requirements management. I like that a lot.

Vincent Balgos: Yeah, right. While I may have shown you a medical example, this tool is actually agnostic to any industry that you have within. This could be applied to aerospace, auto, semiconductor, other areas of the business. Again, just want to kind of share that tidbit.

Well, thank you for this discussion and your perspective, Mario. This kind of concludes our v-log on review and collaboration and the significance within the requirements management domain. We truly hope you’ve been enjoying the series so far. Stay tuned for the next entry in our series and we look forward to seeing you then.

Mario Maldari: Thank you, Vincent.

Thank you for watching our Episode 4, Jama Connect vs. IBM DOORS: Review and Collaboration. To watch other episodes in this series, click HERE.

To learn more about available features in Jama Connect, visit: Empower Your Team and Improve Your Requirements Management Process

We hope you’ll join us for future Jama Connect Jama Connect vs. DOORS topics, including: Document Generation; Migration & Data Mapping; Industry Templates; Reuse and Variant Management; Requirements-Driven Testing; Total Cost of Ownership; and Why Did We Move to Jama Connect? A Customer’s Story.

Requirements Advisor

Jama Connect® Features in Five: Jama Connect Advisor™

Learn how you can supercharge your systems development process! In this blog series, we’re pulling back the curtains to give you a look at a few of Jama Connect®’s powerful features… in under five minutes.

In this Features in Five video, Joseph Pitarresi, Senior Product Manager at Jama Software, will introduce viewers to Jama Connect Advisor™, Jama Connect’s natural language processing (NLP) tool, designed to improve requirement quality.

In this session, we’ll explore the benefits of using Jama Connect Advisor™ to:

  • Reduce authoring errors
  • Increase clarity
  • Optimize foundational product needs and requirements managed in Jama Connect Cloud

Follow along with this short video below to learn more – and find the full video transcript below!

VIDEO TRANSCRIPT:

Joseph Pitarresi: Hello and welcome. Thanks for joining me today. I’m Joseph, Senior Product Manager at Jama Software. In this video, I’ll introduce Jama Connect Advisor, our new requirements authoring solution crafted with engineering-based natural language processing to help users write effective, efficient, and well-organized requirements. As a fully integrated add-on product for Jama Connect Cloud, it delivers extraordinary speed and accuracy in authoring advice. In this video, we’ll explore the benefits of using it in your daily product development to reduce authoring errors, increase clarity, and optimize the foundational product needs and requirements managed in Jama Connect Cloud.

Today, products of all types are rapidly becoming increasingly complex across every industry sector. Intelligent, connected products with rich software complexity are the new norm. Because of this, an exciting architectural evolution has emerged. The Systems-of-Systems architecture has become the new standard and brings with it the need to balance rigor and precision with agility and adaptability in the product development process. Success in this new form of product delivery starts by having accurate user requirements written clearly in natural language. Conversely, poorly written or ambiguous statements lead to development issues downstream.

RELATED: Jama Connect Advisor™ Datasheet

Joseph Pitarresi: Efficient, precise, and professionally written requirements form the foundation of product development success. This is exactly what Jama Connect Advisor is crafted to help you and your team create. Our solution has been intentionally designed to help teams author intricate product requirements quickly and with precision. It’s been created to minimize the interruption of engineering and creative workflow processes. Jama Connect Advisor is a state-of-the-art authoring optimizer powered by engineering-focused natural language processing and artificial intelligence. Our use of engineering-focused natural language is different from that used by general-purpose digital assistance. It applies to special engineering terminology and engineering syntax expertise essential for successful product development.

So how does it work? It applies the globally proven industry principles of the International Council on Systems Engineering requirement’s rules and the easy approach to the requirement’s syntax. Authoring is a challenging task. Even experienced systems engineers and MBSEs need to consider the over 40 INCOSE rules and EARS notations six patterns while authoring even one requirement sentence. This is a daunting task. The challenge represents the perfect application of engineering-based natural language processing and artificial intelligence to speed up productivity and enhance quality. When you use Jama Connect Advisor, it reinforces and extends the authoring skills for everyone involved, regardless of their current skill level.

RELATED: How the EARS Notation Supports Effective Requirements Management and Live Traceability™

Joseph Pitarresi: Now let’s see how you and your team can use Jama Connect Advisor. Step one is to open a requirement in Jama Connect. Step two is to select the edit button. Step three is highlighting the rich text of a statement for analysis. You’ll notice a purple analyze button will appear on the lower right, select it. You’ll first see the quick analysis. This saves time, avoiding the need to review already well-written statements. You will see either a green, yellow or red indicator in the quick analysis. This is a rough initial gauge of quality. Next, if you see a yellow or red indicator, you’ll want to view the detailed analysis. Select the detailed analysis button.

Now you can consider detailed advice given by the INCOSE rules and EARS patterns assessments. Once you’ve considered advice, you can dismiss the detailed analysis, make your desired changes right in Jama Connect single-item view. If desired, you can repeat the analysis after you’ve made changes just to confirm your improvements were effective. This is all done in real-time with minimal interruption to your workflow and the creative thinking process.

In summary, Jama Connect Advisor enhances development team effectiveness by enabling teams to develop, refine, and adopt authoring skills faster. It speeds the creation of institutional knowledge, helping to develop an organization’s own unique approach to capturing customer value during the product development process. Thank you for joining today. We look forward to hearing from you and please ask your Jama software representative for a demo and more information about Jama Connect Advisor. Thank you.

CLICK HERE TO TRY OUT JAMA CONNECT ADVISOR FOR FREE!

To learn more about available features in Jama Connect, visit: Jama Connect Features

We hope you’ll join us for future Jama Connect Features in Five topics, including Risk Management, Reviews, and more.

 


Systems Engineering

In this blog, we overview Part 1 of our eBook, “A Guide to Good Systems Engineering Best Practices: The Basics and Beyond” in which we discuss the fundamentals of systems engineering best practices, the “V” model,  the characteristics of good systems engineering, and lessons learned. To read the entire eBook, download it HERE.

A Guide to Good Systems Engineering Best Practices: The Basics and Beyond.

In the first part of this eBook, we discuss:

  • The fundamentals of systems engineering
  • The role of a systems engineer
  • Systems engineering process
  • The “V” Model of systems engineering

Part I: The Basics of Systems Engineering

What is systems engineering?

Systems engineering is an engineering field that takes an interdisciplinary approach to product development. Systems engineers analyze the collection of pieces to make sure when working together, they achieve the intended objectives or purpose of the product. For example, in automotive development, a propulsion system or braking system will involve mechanical engineers, electrical engineers, and a host of other specialized engineering disciplines. A systems engineer will focus on making each of the individual systems work together into an integrated whole that performs as expected across the lifecycle of the product.

What are the fundamentals of systems engineering?

In product development, systems engineering is the interdisciplinary field that focuses on designing, integrating, and managing the systems that work together to form a more complex system. Systems engineering is based around systems-thinking principles, and the goal of a systems engineer is to help a product team produce an engineered system that performs a useful function as defined by the requirements written at the beginning of the project. The final product should be one where the individual systems work together in a cohesive whole that meets the requirements of the product.

What is a system?

A system is a collection of different elements that produce results that individual elements cannot produce. Elements or parts can be wide-ranging and include people, hardware, software, facilities, policies, and documents. These elements interact with each other according to a set of rules that produce a unified whole with a purpose expressed by its functioning. An example of a system is the human auditory system; the system includes individual parts in the form of bones and tissue that interact in a way to produce sound waves, which are transferred to nerves that lead to the brain, which interprets the sounds and formulates a response. If any single part in the auditory system fails or experiences disruption, the entire system can fail to perform its function.

What is systems thinking?

Systems thinking is a way of thinking that looks at the overall function of a complex system rather than breaking it down into smaller parts. For example, systems thinking would consider an automobile a complex system that consists of smaller, specialized elements. While an electrical engineer might only be concerned with the electrical system of the automobile, someone looking at the entire complex system would consider how the electrical system would impact other systems in the automobile — and how those other systems might impact the electrical system. If one piece of the electrical system fails, for instance, how would that failure cascade to other systems to impact the operability of the automobile? Systems thinking will take a “big picture” approach to the overall product.

What is the role of a systems engineer?

A systems engineer is tasked with looking at the entire integrated system and evaluating it against its desired outcomes. In that role, the systems engineer must know a little bit about everything and have an ability to see the “big picture.” While specialists can focus on their specific disciplines, the systems engineer must evaluate the complex system — as a whole — against the initial requirements and desired outcomes. Systems engineers have multi-faceted roles to play, but primarily assist with:

  • Design compatibility
  • Definition of requirements
  • Management of projects
  • Cost analysis
  • Scheduling
  • Possible maintenance needs
  • Ease of operations
  • Future systems upgrades
  • Communication among engineers, managers, suppliers, and customers in regard to the system’s operations

RELATED: The Complete Guide to the Systems Engineering Body of Knowledge (SEBoK)

How can systems engineers help improve traceability?

For many systems engineers, balancing the needs of the individual systems and their engineers against the system as a whole results in addressing problems after the fact, holding unwanted meetings, and trying to persuade others to change behavior. Many organizations may not adequately focus on requirements and traceability, resulting in a lack of data that would allow a systems engineer to better evaluate the product. To avoid constantly chasing problems and start streamlining processes, systems engineers can use three best practices:

Baseline the current traceability performance:

Traceability spans the product development process, and product team members understand the value of data management, especially as concerns meeting industry requirements. By establishing a baseline of traceability performance, the entire team will be able to see existing risks and potential savings and improvements. In addition, a baseline can give a foundation for a plan of action to move toward Live Traceability™.

Build the business case for Live Traceability:

With a baseline in hand, systems engineers can offer a case for moving to Live Traceability based on data. The data can establish the ROI, productivity improvements, and risk reduction of moving from static traceability to Live Traceability.

Create quick wins:

Once the advantages of Live Traceability are established, the systems engineer can set up continuous syncing between requirements and task management programs, thus automating traceability from requirements to user stories. This simple shift can help demonstrate the value of shifting from after-the-fact traceability to Live Traceability.

RELATED: Better Product Development: Five Tips to Achieve Live Traceability™

What is the systems engineering process?

The systems engineering process can take a top-down approach, bottoms up, or middle out depending on the system being developed. The process encompasses all creative, manual, and technical activities necessary to define the ultimate outcomes and see that the development process results in a product that meets objectives. The process typically has four basic steps:

1. Task definition/analysis/conceptual: In this step, the systems engineer works with stakeholders to understand their needs and constraints. This stage could be considered a creative or idea stage where brainstorming takes place and market analysis and end user desires are included.

2. Design/requirements: In this phase, individual engineers and team members analyze the needs in step one and translate them into requirements that describe how the system needs to work. The systems engineer evaluates the systems as a whole and offers feedback to improve integration and overall design.

3. Create traceability: Although we’re listing traceability here as the third step, traceability is actually created throughout the lifecycle of development and is not an isolated activity taking place during one phase. Throughout the lifecycle of development, the team works together to design individual systems that will integrate into one cohesive whole. The systems engineer helps manage traceability and integration of the individual systems.

4. Implementation/market launch: When everyone has executed their roles properly, the final product is manufactured or launched with the assurance that it will operate as expected in a complex system throughout its anticipated lifecycle.

RELATED: Adopting the EARS Notation to Improve Requirements Engineering

The “V” diagram of systems engineering

Developed in the 1980s, the “V” Diagram of Systems Engineering is a way of specifying the specific series of steps that make up a systems engineering approach. While it was originally employed in a pre-Agile environment, it still has relevance to product development today and can enable faster, less risky product development. The “V” diagram allows system engineers multiple viewpoints and opportunities to evaluate systems as they integrate with each other. This approach starts with the desired outcomes and objectives and then deconstructs them into individual systems and system components for the purpose of design. Once the requirements and design details are established, individual systems can be tested and evaluated, then integrated into the overall piece for testing and verification. As the systems are integrated and become closer to the final complex system, teams have multiple opportunities to validate and verify concepts, requirements, and design.

For the systems engineer, the “V” Model can give a clear roadmap that allows the breakdown of the complex system into smaller parts and then the reintegration and reassembly of the pieces into a cohesive whole. With systems broken down to individual components, traceability, requirements management, and testing and validation become more manageable. In addition, as the pieces are reintegrated into the whole system, the “V” Model allows for an iterative process that gives a clearer view into potential risks and helps troubleshoot problems. Systems engineering is a discipline that’s vital to the success of a complex system. By including systems engineers in all stages of product development and requirements management, teams can reduce risks, improve time to market, and produce better products that more adequately meet end user requirements.

Why is Live Traceability Essential? Given the complexity of products today, it takes multiple team members to weigh in on key decisions. And the number of decision points are only growing as products get more complex, making it even harder to adequately weigh all the options and trace their impacts. Learn more.

To read Part 2 of “A Guide to Good Systems Engineering Best Practices: The Basics and Beyond”, download the entire eBook HERE.


DOORS

Jama Connect® vs. DOORS®: Filters, Search, and Analysis: A User Experience Roundtable Chat

Increasing industry challenges and complexities are pushing innovative organizations to consider modernizing the tool(s) they use for requirements management (RM). In this blog series, A User Experience Roundtable Chat About Jama Connect® vs. DOORS®, we’ll present several information-packed video blogs covering the challenges that teams face in their project management process.

In Episode 3 of our Roundtable Chat series, Richard Watson – Practice Director at Jama Software® – and Cary Bryczek – Director of Solutions Architecture, Jama Software® – walk us through filtering, searching, and analyzing content in Jama Connect® vs. DOORS®

To watch other episodes in this series, click HERE.

Watch the full video and find the video transcript below to learn more!

VIDEO TRANSCRIPT:

Richard Watson: Welcome to part three of our vlog series. I hope you’re enjoying the vlog so far. My name is Richard Watson and I’ll be representing DOORS today. In terms of experience, I’ve been using DOORS for just over 20 years and all of those was as the DOORS and DOORS Next product manager. I’m joined today by Cary.

Cary Bryczek: Hi everybody. I’m Cary. I haven’t had the pleasure of using DOORS for as many years as Richard. I’ve been blessed by not having to use it, but I have used Jama for a very long time and I’m the Director of Solutions Architecture here at Jama, and I’ve been in the requirements world for more than 25 years.

Richard Watson: Thank you. So in this vlog we’re going to be talking about requirements analysis, that’s filtering, searching, dashboards, etc.

Analysis is probably one of the most important reasons that we actually pick a requirements tool in the first place. The risk of life or the risk of lots of money gets organizations imposing compliance needs or their industry will give them regulations that they simply have to meet. And document-based systems just don’t give the relevant granularity to enable things like live traceability. So we need a tool.

Over time, the way we’ve engineered complex systems has changed and we find a much wider community of stakeholders are interested in direct access to the requirements. They want to actually go into the tool. And so usability of that tool becomes key. We also continue to get a wide dynamic set of users and new users, certainly younger users expect the tool to almost be like their social media apps that they’re using.

Cary Bryczek: Yeah, right but aren’t developing with the social media tools that the younger folks are used to. We’re doing real engineering.

Richard Watson: So how to persuade them to use an engineering tool?
Today’s tool engineers are being overwhelmed by data. Data can have, of course, huge value, but if you can’t find the data, it can sometimes even hinder your process, let alone give you any value.

Cary Bryczek: To do that analysis, we need to know how the information is stored, maybe even over multiple systems and how it’s all related to each other. We need to have different views of all of that trace data to ensure that really everything is being done as expected.

RELATED: Jama Connect® Solution for IBM® DOORS®

FILTERS AND SEARCH

Richard Watson: So, okay, let’s start digging into the details. If we start with filters and search. Looking at DOORS, DOORS obviously has a world that’s wrapped around individual modules, and so trying to filter and search information across modules is next to impossible.

Initially, when we started out using DOORS years ago, that was okay. Today it’s not. Today we’re finding organizations have got thousands of DOORS modules and millions of requirements in those are total modules. It’s really difficult to find the data that you need. When you’re in a module, of course, DOORS has got quite sophisticated, complex filter definitions, but even they’re frustrating because if you want to modify them for some reason, perhaps you need to change them or maybe they’re even wrong, you have to start from scratch and normally, you need help to do that.

If we jump the fence DOORS Next, DOORS Next is DOORS next generation. It should be the next generation of DOORS, but it’s hampered by its history. DOORS Next actually was developed on top of an original tool requirements composer. And in order to introduce the DOORS, facilities, modules were added. And as a secondary fun function, modules actually confuse the situation. For example, when you add a requirement to a DOORS Next module, it also gets added to what’s called a base folder. And so when you’re searching for information, you need to know whether you’re looking for the requirement in a module or whether inadvertently you find that requirement in the folder. Sometimes you can even count these requirements twice because they’re in two separate places.

Cary Bryczek: Richard, that sounds complicated even listening to you describe it. Jama is a modern tool and we took a completely new approach with a web-based UI that’s designed for anybody to get up and running. And filters and searches is one of the prime areas that make it really super simple and easy to use for analysis.

Let me just show you what I mean. When we created Jama, we wanted it to be easy to use right away, and finding information should be just intuitive as possible. You don’t have to write any kind of DXL. I can see filters that I already have. I can see just things that I’ve bookmarked creating and searching. Again, I don’t have to write any DXL. It should just show me the particular type of requirements. I can even find things across. What are the ones that don’t have any downstream relationships.

Richard Watson: Yeah. This is so much different to DOORS, and also it’s an improvement over DOORS Next, Cary, because you can do filters on the information at the other side of the relationships and that’s quite difficult to do in DOORS Next and you just can’t do that in DOORS at all.

Cary Bryczek: Yeah. Filters are built into almost any view that you’re on. So if I’m right in a view that I’m looking at requirements, I’m able to filter it right there, filtered by keyword, filtered by the types of things that are in the view, even through traceability.

Richard Watson: Yeah. That’s really interesting, Cary. I particularly liked the way you were doing filters over relationships. I mean you consider it trying to do a filter in DOORS Next, which is impossible saying show me requirements related to defects that have been raised against failed test cases. You just can’t do that type of filtering inside of DOORS Next. So it’s pretty cool in Jama.

RELATED: Why Investing in Requirements Management During an Economic Downturn Makes Good Business Sense

DASHBOARDS

Richard Watson: Also, you’re showing the dashboard functionality. Dashboards in DOORS just don’t exist. So it’s got a welcome screen so you can sometimes see information on that welcome screen, but that was introduced so late in the process or the release schedule that not many organizations use it.
DOORS Next, of course, has dashboards, but again that’s hampered by history. DOORS Next dashboards are very much focused on requirements in folders. So for our DOORS user moving into DOORS Next, you’ll find that the maturity of dashboards around module information is pretty limited.

Cary Bryczek: With Jama, our dashboard technology is built right into the tool. You don’t need any extra add-on servers to make it work. And it’s something that is used as a launchpad for different stakeholders to get to the information. Let me show you what I mean.

We have dashboards that are built right in. The reporting engine is native inside of Jama itself, and then so you can take those filters that we were creating earlier and turn them into widgets, into pie charts, into bar charts, then you can download the information. You can download a picture of the things. You can see which requirements don’t have tests, what are the suspect ones, which are the recently viewed things, what’s the progress, which are the things that I’ve touched in the past few days. So if I need to pick up where I left off, launch that directly from a dashboard review.

RELATED: G2 Recognizes Jama Connect as the Only Leader in Requirements Management

ANALYSIS

Richard Watson: Yeah, that’s cool. I like the traceability map there as well. That’s really good. So let’s move on and talk about analysis of requirements. Analysis of requirements is where the fund is and we can start with DOORS.

DOORS has some analysis for capabilities, but mostly organizations are expected to develop DXL solutions. DXL it’s a cool thing to fill in gaps. I remember going around many of the software conferences and people will actually proudly come to me and say, “Hey, Richard. Our organization’s got hundreds of thousands of lines of DXL scripts,” sometimes over a million lines of DXL scripts.

Think about what we’re saying. A million lines of customization code where the organization’s core business is not developing requirements tools. That DXL hampers the performance of DOORS. Sometimes you lose sight of what’s making DOORS go slowly. Is it DOORS itself or is it a customization? And also, as time moved on, the number of people that have got skills in developing DXL is diminishing greatly. And so if you try to, you are exposing your organization to risk because you can’t maintain or extend your current environment.

Jumping the fence to DOORS Next, there’s a different problem entirely. DOORS Next, of course, doesn’t support front end customizations. It doesn’t support DXL. When you look at DOORS Next, actually you start to look at traceability. We want a system that can see an overall view of live traceability between data so that you can analyze that information. And the only way you can do that in DOORS Next is either with an additional tool, so Jazz reporting system, or you start looking at OSLC techniques. OSLC is okay if you’re looking at your Jazz-based products only. It’s got some very big constraints if you’re starting to get tools from different vendors. So you get tied into a single vendor solution simply because of the lack of maturity of OSLC implementations.

Cary Bryczek: Gosh, Richard. Again, that sounds really complicated. And one of the great things that Jama software did was build all of that workflow capability, all of the bits and pieces that you’d have to do with DXL into the software. So people just come in to Jama Connect and just start using it. And the live traceability aspect is probably my favorite aspect about the tool and it’s super powerful. Let me show you what I mean. One of the things that’s great is that live traceability enables pretty much anyone to find anything at the current moment across boundaries. And so, one of the ways that we start live traceability is through that relationship rule diagram. I can see the schema for what’s traced, and this information might be coming in live from other tools in the ecosystem.

We give you an easy way to organize. So if I’m starting to analyze a system just following this explore tree, and seeing how the information is organized by system and subsystem for this aircraft. Now once inside, just navigating to find that information is super simple. I even have live traceability here in the tools itself, so in the requirements, so I can see this particular function requirement, it traces to a system requirement.

Traceability is in almost every view that we look at. So if I’m in this one detail view of a requirement, I know it’s got upstream and downstream traces. If I’m in the live tracing view, my live tracing view, this is a multi-level view of requirements. So I can see if I’m following these requirements on down to the validation level or the system level. I can walk that traceability all the way down, multiple levels of requirements to look at test runs, to look at any defects along the way. It’s really powerful. And then I can start and filter right where I need to be. So if I want to have a filtered start from a filter view, which are the ones that are causing suspect?

Now, this shortens the amount of information that I have on the screen. It really makes the analysis much faster to do than having to work with DXL scripts or exporting stuff to spreadsheets and looking at the information.

Richard Watson: Thanks very much, Cary. That insight to Jama Connect is just reminding me of my last 18 months in Jama. I’ve really enjoyed picking up the Jama Connect product, really excited by it.
That brings us to the end of this particular vlog. I hope you all enjoyed it, and please feel free to take some time to look at some of the other vlogs in this series. Thanks very much, Cary.

Cary Bryczek: Thanks, Richard.

Thank you for watching our Episode 3, Jama Connect vs. DOORS: Filters, Search, and Analysis. To watch other episodes in this series, click HERE.

To learn more about available features in Jama Connect, visit: Empower Your Team and Improve Your Requirements Management Process

We hope you’ll join us for future Jama Connect Jama Connect vs. DOORS topics, including: Review and Collaboration; Document Generation; Migration & Data Mapping; Industry Templates; Reuse and Variant Management; Requirements-Driven Testing; Total Cost of Ownership; and Why Did We Move to Jama Connect? A Customer’s Story.


Jama Connect Advisor

In this blog, we recap our press release covering the new performance and scale benchmarks set with the release of Jama Connect Advisor™ – The Industry’s First Native, Natural Language Processing (NLP) Advisor to Improve Requirement Quality.

Jama Software® Releases Jama Connect Advisor™ – The Industry’s First Native, Natural Language Processing (NLP) Advisor to Improve Requirement Quality

Jama Software®, the leading requirements management and traceability solution provider, has announced the launch of the Jama Connect Advisor™ — an intelligent, natural language advisor that improves the quality of requirements based on industry-recommended best practices by INCOSE (International Council on Systems Engineering) rules and EARS (Easy Approach to Requirements Syntax) notation for successful product development and market delivery.

Maintaining requirements quality is critical for product development as studies have shown that 70 to 85 percent of rework is due to faulty requirements. Efficient, precise, and accurately written requirements are the single source of truth that aligns development effort across engineering disciplines reducing rework, lengthy integration meetings, and costly late-stage surprises.

“Requirement quality is critical to our success, but it is hard to train and enforce. Jama Connect Advisor gives us the ability to train new engineers and ensure consistent requirement quality across projects – a real game changer for us,” said Sheila King, Senior Project Engineer, Rockwell Automation.

Companies not only benefit from reduced rework, but also the automation of training for new engineers to learn requirements authoring best practices. Jama Connect Advisor provides self-paced training as requirements are being authored and reviewed to help new engineers ramp up quickly without placing time demands on more experienced engineers.

“Needs, requirements, verification, and validation are common threads that tie all systems lifecycle activities and artifacts together. Because of this, the quality of the needs and requirements is critical to project success. Tools such as Jama Connect Advisor — that aid those defining well-formed needs and requirements and have the characteristics defined in the INCOSE Guide to Writing Requirements — are invaluable,“ said Lou Wheatcraft, Senior Consultant, Managing Member, Wheatland Consulting, LLC, and Co-Chair INCOSE Requirements Working Group.

Jama Connect Advisor helps engineers and product developers:

  • Leverage engineering-based natural language processing guidance while editing within Jama Connect®
  • Author intricate product requirements quickly, easily, and with precision
  • Develop and improve authoring skills through guidance based on industry-recommended practice by INCOSE Rules and EARS Notation

“Jama Software is committed to helping our clients improve the performance of the engineering process. Fundamental to this improvement is ensuring the quality of requirements through intelligent analysis and automated training for new engineers,” said Marc Osofsky, Chief Executive Officer, Jama Software.

Key Benefits of Jama Connect Advisor:

  • Reduce costly rework
  • Automate the training of engineers on requirements authoring best practices
  • Eliminate late-stage errors due to faulty requirements
  • Reduce tedious and morale-draining integration meetings
  • Increase engineering productivity through quality automation

With correct, precise, and efficient requirements, companies can accelerate product development to remain competitive in this new era of innovation.

For more information on Jama Connect Advisor:
DOWNLOAD THE DATASHEET OR CLICK HERE TO TRY OUT JAMA CONNECT ADVISOR FOR FREE!

Read the entire press release here! Jama Software® Releases Jama Connect Advisor™


Jama Connect vs DOORS

A User Experience Roundtable Chat About Jama Connect® vs. DOORS®: Adoptability for All Stakeholders

Increasing industry challenges and complexities are pushing innovative organizations to consider modernizing the tool(s) they use for requirements management (RM). In this blog series, A User Experience Roundtable Chat About Jama Connect® vs. DOORS®, we’ll present several information-packed video blogs covering the challenges that teams face in their project management process.

In Episode 2 of our Roundtable Chat series, Cary Bryczek – Director of Solutions Architecture, Jama Software® and Susan Manupelli – Senior Solutions Architect,  Jama Software® – walk us through the importance of adaptability, and ease of use, for all stakeholders in a requirements management tool.

To watch Episode 1 of this series, click HERE.

Watch this short video below to learn more and find the full video transcript below!

VIDEO TRANSCRIPT:

Cary Bryczek: Hi everybody. Welcome to part two of our vlog series. I hope you’re enjoying the series so far. My name is Cary Bryczek, and I’ll be representing Jama software today. In terms of experience, I’ve been using Jama for nine years, but have used DOORS and numerous other requirements tools for the past 20 years. I’m joined today by Susan.

Susan Manupelli: Hi there. My name is Susan Manupelli. I’m a solutions architect here at Jama Software. Prior to joining Jama, I was a test architect working on the engineering lifecycle management suite of products, particularly on Rational DOORS Next Generation and the Global Configuration Manager. So I’m happy to be here with you today to talk requirements management adoptability

Cary Bryczek: Thank you Susan. In this vlog, we’re going to be talking about the adoptability for all stakeholders. Adoptability, it might be the most important aspect for a requirements tool and sometimes it’s the most overlooked. Adoptability isn’t just about being able to get users to actually use the software, but it’s about how well it fits into the IT ecosystem. How hard or easy it is to maintain, or even whether or not the organization recognizes its benefits.

UI, Ease of Use, and Adoptability

Susan Manupelli: Right. Let’s talk… One of the first challenges in the adoption of DOORS Classic is that many dev teams are distributed globally. DOORS is a legacy client server application, which doesn’t scale well over the WAM, so DWA, DOORS Web Access, was released as the answer to that problem, but it lacks significant functionality only available in the desktop client.

Another challenge with DOORS Classic is that the UI look and feel is very dated. Modern engineering teams are energized by utilizing the very latest technologies for developing state-of-the-art products for the future, and then they’re asked to use a requirements tool that was designed some 30 years ago. So that just doesn’t fly very well.

Let’s talk a little bit about DOORS Next Generation. It was marketed as a new modern alternative to DOORS Classic. Unfortunately, it’s very hard to use. There are too many different options for use and a lack of direction on best practices. So we’ll go through some of these challenges in the vlog.

The first place where users struggle to adopt DOORS Next Generation is a very basic question; whether to use modules or not. DNG originally only allowed you to organize requirements in a tree view hierarchy of folders. And later, to accommodate users that were more familiar with DOORS Classic, modules were added to DNG. Modules provide a document-like view for requirements, but these same artifacts outside of the module view show up in alpha numeric order in the true view, it makes organization of artifacts outside of the module very confusing.

RELATED: Jama Connect® Solution for IBM® DOORS®

Cary Bryczek: Wow. Yeah, that does sound complicated to comprehend. Jama was developed as a web-based solution from scratch. We wanted to fulfill the lowest common denominator stakeholder so anybody could come in and use our software. Our UI is modern and intuitive. Let me show you what I mean.

This is what I mean about our UI. It’s very streamlined. There’s hardly any button clicks or menus to learn how to use. There’s four main menus. And then the rest of them are kind of like right click kinds of options. We have the dashboard built right in. Our views are super simple. The explorer tree matches exactly what you see in our list view. And our views are very simple to navigate. So if this is the list view, and I wanted to see a document or a reading kind of view, I can just toggle the buttons to show those different types of views.

Teaching someone how to use this is really super simple, and it doesn’t take that much time at all. In fact, analysts have even recognized Jama Software as being the easiest user tool in the marketplace. You can go out there and see something like from G2, which queries users without us even knowing about it to get their direct feedback on the tools.

Link Relationship Rules and Traceability

Susan Manupelli: Well thanks, Cary. That was great. Another area that’s confusing in DNG has to do with linking. Linking behavior is different between module artifacts and non-module artifacts. A lack of understanding leads to incorrect or incomplete traceability analysis. In DNG, if you link to artifacts that are outside of a module, the link is placed on the core artifact. If you link to artifacts within a module, the link only appears in that particular module. If you then print a traceability report, you’ll only see links made in the module context. So links to core artifacts won’t be displayed. So as a user, that behavior is very confusing.

Another gate to adoptability has to do with enforcing link relationships. Enforcing relationship rules in DNG it’s just hard to do. Either all links are allowed, which means that users can kind of willy-nilly apply link rules that don’t make sense really for relationship, or allowed link rules are specified in a list form for a given component, and then they must be recreated across all components in the project. There’s also no visual representation of link rules in DNG, and there’s no notion of enforcement of required link rules, so compliance is hard to maintain.

Cary Bryczek: Gosh, just listening to that sounds really confusing to me, and I’ve even used DOORS. In Jama, linking is just straightforward. If an item is linked to another item, that link relationship will be visible wherever you are in the UI. We also have the capability to see what our relationship schema looks like and enforce a consistent way to apply traceability. Let me show you what I mean.

There’s a couple of different ways to look at the traceability. I can see that traceability right away. So I know that this standard aircraft platform requirement is traced to another object downstream. I can see the traceability numbers, so this one in this list view. I can see that this one requirement has five different traceability things. I can see it also in the trace view. We’ll tee up a live real-time version of what’s currently traceable out there. It’s very easy to see where there’s gaps in traceability because there’s just no information there.

We have our traceability rule set. Think of this picture as being the schema for what types of objects are allowed to be traced to one another. So I might have four levels of requirements traceability. I might have test cases in there. And so this set of rules would enforce the users to create consistent traces. And then I can follow those rules down in the live trace view as well. So if I’m following this aircraft level requirement, I can see the system requirements, and any kind of lower level objects, whether those are high level software requirements. Here I see some verification tests and agency test runs. Traceability is really made to be super intuitive, real-time, live, to allow anybody to understand and analyze the current situation.

RELATED: G2 Recognizes Jama Connect as the Only Leader in Requirements Management

Administration and Maintenance

Susan Manupelli: Another common issue is that DOORS Next is hard to administer and maintain. Upgrades are often a challenge. As major architectural changes have occurred in recent releases of the DNG, the time and effort and ultimately the cost to upgrade has been daunting.

Another area of maintenance in DNG has to do with the type system. The type system, that’s the part of DNG that keeps track of your artifact types, your attributes and your values and their relationships. And that needs to be consistent from project to project for cross component and cross project reporting. And there’s no global way to keep these items in sync from project to project or component to component.

Cary Bryczek: Cool. That’s really different than the experience here at Jama. Our host of solutions get updates just about every 60 days. Middleware and security updates are handled as necessary. And sometimes the middlewares might take six months to a year or so. Very stable releases and changes to the ecosystem. We have self-hosted solutions and even customers that have air gap, we can satisfy those sort of ecosystem environments. Very easy to set up and deploy.

Now, it was interesting that you talked about, Susan, though the type rules. In Jama, we’re a little bit different for item types and attributes. We define those globally. Here’s an example.

Our type rules are defined globally, like I said. Here’s an example of schema for the types that are relevant to this particular achiever one project. When we define them globally, it’s all point and click kinds of experience of dealing with that. These attributes are now consistent from project to project to project. And that way you can have really easy reuse scenarios. If you’re doing complex scenarios like product line engineering or if you have complex libraries of data that you use from one project to the next, having that consistent type definition really makes it easier for you to do analysis, leverage reuse, have shorter project startup times.

RELATED: Why Investing in Requirements Management During an Economic Downturn Makes Good Business Sense

Running and Exporting Reports

Susan Manupelli: Yeah, sure. I can definitely see that. One other area that I wanted to talk about has to do with reporting. For all the effort that’s put into DNG to maintain the projects, to build up the requirement specs, the reporting needed to meet certifications is hard or sometimes impossible to create. Mistakes or inconsistencies in the type system that we just talked about, those often manifest as issues once you try to do some traceability reporting. Keeping data consistent between DNG in the reporting data stores has proven to be a challenge, so we’re talking about the data warehouse and LQE. And basically robust reporting out of DNG requires the use of additional IBM tooling, either Jazz Reporting Service, or RPE, the Rational Publishing Engine, and those products are outside of DNG.

Cary Bryczek: That sounds complicated. Again, one of the great things that we have at Jama is our reporting engine is built right into Jama itself. And Jama is a single application, so there’s no deploying 11 different servers of applications that are sort of cobbled together through an integration under the covers. Jama is just a single application. And exporting is super easy. Let me show you what I mean.

We have lots of built in reports. Lots of different kinds of reports that you can add in. We have the capability to export directly to Excel, Word, right there. All a user has to do is configure the view that they’re looking at, whether that’s the reading view or the list view that’s customized to match what they need to have. And then they can have the built in export templates that are just creatable via Microsoft Word templates, so there’s no custom coding in most cases that a user has to do to run these kinds of reports. Doesn’t that sound much easier, Susan?

Susan Manupelli: It sure does.

Cary Bryczek: That brings us to the end of this particular vlog. I hope you all have enjoyed it. Please, I hope you also take some time out to look at some of the other vlogs in this series. Thank you so much, Susan, for your perspective on DOORS and DNG as well.

Susan Manupelli: Thank you Cary. Happy to be here.

Thank you for watching our Episode 2, Jama Connect vs. DOORS: Adoptability for All Stakeholders. To watch Episode 1 of this video series, click HERE.

To learn more about available features in Jama Connect, visit: Empower Your Team and Improve Your Requirements Management Process

We hope you’ll join us for future Jama Connect Jama Connect vs. DOORS topics, including: Adoptability for All Stakeholders; Filters, Search and Analysis; Review and Collaboration; Document Generation; Migration & Data Mapping; Industry Templates; Reuse and Variant Management; Requirements-Driven Testing; Total Cost of Ownership; and Why Did We Move to Jama Connect? A Customer’s Story.


Systems Development

Jama Software is always on the lookout for news and content to benefit and inform our industry partners. As such, we’ve curated a series of articles that we found insightful. In this blog post, we share content sourced from Lifecycle Insights – Jama Connect®: Accelerating Systems Development with Requirements Management and Live Traceability™  – which was originally published on August 17, 2022, by John McMillan.

Jama Connect®: Accelerating Systems Development with Requirements Management and Live Traceability™

How does Jama Software®’s approach to managing the vast array of complex engineering requirements provide organizations a competitive advantage? Their approach is a software solution developed specifically to provide unified requirements management and traceability across organization development processes whether that be the traditional V-model, Waterfall, Agile, or otherwise. Jama Connect requirements management software with Live Traceability was designed to help development and engineering organizations improve quality, reduce rework, ensure compliance, and get high-quality complex products, systems, and software to market faster and on budget.

Historically in product development, each engineering discipline utilizes tools that are specifically suited to maximize their ability to be innovative and productive in their own design space. Communication between other disciplines and the broader organization however has historically been siloed or fragmented and often managed through “throw-over-the-wall” manual approaches. Those approaches are error-prone and often result in discovering late-stage issues downstream that result in design rework, delay product delivery, and create cost overruns that impact the organizations’ bottom line.

The Cost of Discovering Late-Stage Issues

When late-stage issues are discovered during integration testing, systems testing, and during final acceptance testing they are expensive to fix. Jama Connect platform was developed to enable organizations to detect and correct requirement and testing issues and solve disjointed discipline problems. This is provided through a requirements management platform designed specifically to help engineering organizations align people, processes, and tools in one concise application early on and throughout product development- when the cost of change is lowest.

Jama Connect was designed to provide unique real-time visibility and actionable insights for the end-to-end product, systems, and software development processes. Within the application, users develop relationship models between each discipline’s tools by way of data elements. These data elements are connected with direct tool integrations with Live Traceability. Once the flow of each element’s connections is defined and reflected throughout the system – should a data element be modified, the connected element stakeholders are alerted, and each discipline can review and address any changes accordingly. The application’s unique open architecture allows integrations with a range of premium solutions across the full ALM-PLM tool ecosystem.

Related: Requirements Traceability Benchmark

What about Integration and Customization?

Jama Connects list of supported tools and plug-in integrations for Live Traceability is already quite extensive and is growing.

  • For Design and Simulation model-based requirements management Connect seamlessly integrates with MBSE and SysML tools including Ansys, MathWorks, Enterprise Architecture, and Catia’s No Magic.
  • For Task Management, Live Traceability is directly supported for Jira, Bugzilla, Azure DevOps, and TFS without any changes required by software developers’ preferred tools, methodology, or field values.
  • For PLM and PLE link requirements to hardware specifications and product line engineering for traceability and impact analysis are seamlessly supported for Teamcenter, Windchill, Aras, Pure-Systems, and BigLever.
  • For Test Automation, live trace requirements and test cases to automated testing results are supported from tools including Tricentis, Ansys, LDRA, TestRail, ZEPHYR, Vector, Jenkins, Bugzilla, and Parasoft.
  • For Risk Management, traceability is supported from Ansys FMEA/DFMEA calculations as well as Microsoft Excel including functions and spreadsheets, is also supported without any changes required to Risk team’s tooling or approaches.
  • For DevOps, Live Traceability is extended down to source code with applications including GitLab, GitHub, and Azure DevOps with no changes required to software developers’ tools or methodologies.

Though Jama Connect provides users with the ability to develop custom model system frameworks, it also includes the frameworks for plans, templates, and checklists that are specifically aligned to industry standards for medical devices, automotive, semiconductor, aerospace, defense/government, software development, and industrial manufacturing. In addition, an extensive list of industry standards and regulations are supported including ISO, IEC, FDA, EU, SEBoK, ARP, DO, and more. These industry-specific standards help organizations ensure end-to-end compliance, mitigate risk, and overall process improvement guidance.

Addressing risk management with system analysis that is tailored to each product’s industry standards and regulations, “left-shifts” risk management throughout the product’s development flow and in turn serves as an integral part of the product lifecycle process. Organizations can standardize and integrate their own risk analysis, evaluation, and risk management processes within Jama Connect’s platform to create a single source of truth for everything risk related.

In addition to risk management, Jama Connect provides critical verification and validation requirements for complex systems via test management. The tool supports customized reporting for proof of regulatory compliance and performs manual user-acceptance testing to ensure products are designed with end-users in mind. The tool generates links to disparate processes, sources, and people that increase visibility and simplifies the user’s path to compliance with traceability of tests back to its requirement. It also traces failed tests to new and existing defects for quick resolution, enabling users to reuse validated requirements saving time when testing consistent features across products.

Related: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering (MBSE)

MBSE Platform, Decision Making, and Traceability

MBSE (Model Based System Engineering) is another key area that Jama Connect provides a streamlined and collaborative data-driven approach to in the product development cycle. Jama Connect’s Companion MBSE platform combines requirements, architectures, behaviors, verification, and validation into a single model of the system by applying structure and rules for data and a consistent interface language between the parts of the system. The MBSE platform is designed to help organizations formalize the development, integration, and use of models to inform enterprise and program decision-making. It also allows non-technical stakeholders to visualize a model of the system of interest and interact with its data in familiar views like documents and spreadsheets.

A leading problem that product engineering organizations face is complying with traceability spanning siloed teams and tools (e.g., design, hardware, software, test, risk, quality) creating an increased risk of negative outcomes such as extensive rework, delays, & cost overruns. Requirements traceability across the entire systems development lifecycle is a core tenant of the systems engineering discipline and underpins industry standards to ensure higher quality, faster cycle times, and less costly rework.

RELATED


IVDR

This is part 2 of a two-part blog series covering our whitepaper, “The New EU In Vitro Diagnostic Regulation: What’s Changing and What You Need to Know” written by Vincent Balgos, Medial Solution Manager at Jama Software. In this paper, Vincent discusses the In Vitro Diagnostic Regulation (IVDR), developed by the EU Commission (CE), which was created to replace the previous In Vitro Diagnostic Directive (IVDD).

Part 1 of this blog series is available HERE. To read the whitepaper in its entirety, download it HERE.

The New EU In Vitro Diagnostic Regulation (IVDR): What’s Changing and What You Need to Know

The IVDR Overview

With more than 150 pages of regulations, there were many changes to strengthen and grow the path to IVDs marketed and distributed in the EU. The IVDR provides a more comprehensive approach to regulating devices as it encompasses the entire product lifecycle: from initial concept to design and manufacturing, to continual on-market support along maintaining good documentation practices. For the purpose of this paper,
only a few selected topics will be covered in detail with some additional insights from an industry perspective.

Related: Download the Full IVDR Regulation Here

High Level Overview of the IVDR and Key Facts:

Who is impacted?

Medical companies that develop IVD’s marketed to the European Union, and its population. This includes non-EU-based companies that have products in the EU region.

What is impacted?

In-Vitro Diagnostics (IVDs) products and accessories that are used to perform tests on various sample types to help diagnose a condition, detect infections, or monitor drug responses.

When is it happening?

Date of Application: May 26, 2022, where only IVDR applications will be accepted by NB. A two-year window period afterwards to allow companies to transition their IVDD to IVDR certification. By May 2025, all IVDD certificates will be voided, with IVDR covering all placed IVDs in market.

What countries are impacted?

European Union and the United Kingdom specifically, but companies from around the world who have products in the UK or EU are also required to conform.

Why are things changing?

To improve the safety and quality of IVDs in the EU market.

Discuss on Key Topics

Changes to Classifications

A key significant change of the new regulation is how IVD’s are classified. Similar to the previous directive, a risk-based approach (with respects to public and patient) is used to classify IVDs under the new IVDR framework. There are four main classes as listed in the table below, established by seven classifications rules defined in Annex VIII of IVDR.

While there may be nuances to the rules set, these four categories broadly cover the majority of the IVD spectrum. This new classification schema only allows Class A devices to be self-certified by manufacturers, whereas Class B, C, and D require more assessment and certification by notified bodies.

As in similar regulatory pathways, device classification is significant in determining the overall requirements, as the higher the IVD risks, the more onerous the regulatory requirements, and the higher the involvement with an external Notified Body. For example, a new HIV Test would be categorized as Class D, which would require the highest number of internal activities during design, development, on-market support, and associated documentation. This would also require the highest amount of interaction, assessment, and certification from the Notified Body. Furthermore, specific regulations such Post-Market Surveillance, Quality Management System elements, and annual updates to reports are required for higher risk class (C and D) devices.

Based on general research from industry subject matter experts, it was estimated that only 20% required Notified Body certification under the previous IVDD, while 80% did not require certification. With the new classification schema and requirements under IVDR, that ratio has flipped where it is expected that the majority of IVD’s (80%) will now need some Notified Body involvement. This new shift (in engaging Notified Bodies and the new requirement) is significant in many ways as it not only impacts the manufacturers, but also the Notified Bodies as demand for their engagement has risen exponentially. There are some concerns about the current Notified Body capacity, so it is encouraged to start engaging with a Notified Body proactively, as the backlog to engage could be longer than anticipated.

IVDR Chart

Related: The Impact of ISO 26262 on Automotive Development

No Grandfathering Clauses

For certified IVD’s that are currently on-market classified under the IVDD guidance, reclassification to the IVDR categories and recertification to meet the IVDR is required for continual sale and distribution to EU market. Under the IVDR, there are no grandfathering clauses to allow the IVDD devices to remain on market after May 2025. Considering there are many IVD’s in use, the EU established a five-year timeline to allow manufacturers to transition to IVDR. See the timeline below for more details.

IVDR TransitionalSince IVDR’s announcement in 2017, many companies and SME’s (including this author) started to update
their internal procedures, adjust development and documentation activities, and hire additional resources
in response to the impending changes. In addition, remediations to current devices’ Design History Files
(DHFs) to align with regulations were also underway. These include adding additional testing for new
requirements such as performance studies, clinical evaluations, etc. These activities may be significant,
and a major resource pull from other ongoing projects. Therefore, it’s critical to acknowledge that the new
IVDR regulations impact not only future but current IVDs on the market as well.

Related: Medical Device: Reduce Project Risk in the Product Development Process

One Person Responsible for Regulatory Compliance

Under Article 15, a new IVDR requirement is that manufacturers are required to have a regulatory compliance expert in their organization to be responsible for the compliance of the in-vitro diagnostics regulations. This person must be a qualified regulatory expert with previous demonstrated qualification such as 1) formal certification from approved regulatory body and/or 2) minimum of four years of industry experience as a regulatory affairs professional in the IVD field. This role (new for some organizations) provides general regulatory affairs guidance, interpretation of regulations to internal teams, and helps facilitate discussions with Notified Bodies, regulatory agencies, and EU Competent Authorities.

Establishing Risk Management

While not a new requirement to IVD practices, Annex I Chapter I of the IVDR has multiple languages referring to and establishing risk management practices. This further substantiates the EU focus on a riskbased approach when developing devices and encourages many best practices that Jama Software® has seen many of our IVD customers follow.

This new language includes the following requirements:

  • To establish, implement, document, and maintain a risk management system.
  • To enforce continuous and iterative risk management process with regular updates to the risk files throughout the device lifecycle, especially after the product has been launched to market.
  • To reduce risks as far as possible without adversely affecting the benefit-risk ratio and inclusion of this analysis in technical files submission. This includes risks related to use errors of the device.
  • To consider design accommodations to assure that characteristics of safety and performance are maintained during the transport and storage of the product, and for the expected lifetime of the product.
  • To minimize all known and foreseeable risks and be acceptable when weighed against the potential benefits.

This updated language continues the industry practice of risk management that is further established in ISO 14971 “Medical Devices – Application of Risk management to Medical Devices” and TR 24971 “Medical Devices – Guidance on the application of ISO 14971.” Based on the reasons why the IVDR came into fruition (PIP accidents), it can be surmised that an organization’s risk management process will be under significant scrutiny by the Notified Body. Therefore, Risk Management Procedures have been a focal point of update for organizations to strengthen risk practices and ensure compliance. Remediation of risk files may also be warranted for devices currently on the market, or soon to be on the market in the EU.

Based on this author’s experience, this risk activity alone requires significant time and resources to accomplish. Considering some risk files could have significate number of documents (plans, evaluations, reports) with details that require comprehensive review from many stakeholders, this is an effort that needs formal organization support to successfully comply with the IVDR and its compliance timeline. Therefore, it is recommended to prioritize
appropriately and revisit the Risk Management section, and other impacted areas of the IVDR as soon as possible.

Related: Whitepaper: Application of Risk Analysis Techniques in Jama Connect® to Satisfy ISO 14971

General IVDR Guidance for Medical Device Companies

Based on discussions with various IVD customers, general research, and internal experience, we recommend the following guidance:

  • Determine the new IVDR classification for each of your devices on market, or plan to be launched in the EU, and their associated requirements. Consult with Regulatory affairs to proactively affirm
    classification with a notified body.
  • Review and remediate procedures and documents to include new IVDR regulation languages and requirements. Based on your organization’s level of compliance, this could be a significant activity so
    may need management support.
  • Identify the accredited regulatory affairs expert in your organization that will be responsible to drive the activities to comply with the IVDR regulations. This may include updating general regulatory
    procedures, product development processes, and for existing technical documentation.
  • Review and update risk management procedures to include new requirements such as regular updates of the risk files, incorporate use-risk scenarios, and ensuring the benefit-risk comply with
    new language.

As with many types of changes in regulations, these have substantial impact on how organizations and their teams operate in the design, development, and manufacturing documentation of IVDs. It is encouraged to proactively review these new regulations as it may require significant time and resource to adapt to continue developing IVD’s for the European market.

DISCLAIMER
Jama Software is not an accredited regulatory subject matter expert, so these are general guidance and insights from working with many IVD customers, general research, and some internal experience. It is suggested to work with a certified Regulatory Affairs consultant for formal recommendations for your organization.

References:
1. https://www.bsigroup.com/meddev/LocalFiles/en-IN/Technologies/BSI-md-ivd-diagnostic-directive-guide-brochure-UK-EN.pdf
2. https://ec.europa.eu/growth/single-market/ce-marking_en

Accelerate Innovation in Medical Device Development While Adhering to Industry Regulations

With the new IVDR, it is expected that manufacturers will need to shift to a more regimented process of developing, manufacturing, and managing IVD’s. Similar to other regulatory pathways, good requirements management is the best practice in ensuring compliance with regulations, reducing risk, and launching safe and effective products.

Jama Connect® for Medical Device Development helps medical device teams reduce the effort required to achieve regulatory compliance throughout the development process. With this solution, medical device teams can manage design controls for device requirements and related risks, simplifying regulatory submissions and audit preparations while accelerating time to market. Jama Connect creates a digital thread for systems engineering and
ensures Live Traceability™ and alignment across the product development lifecycle to seamlessly connect development solutions and facilitate product success.

Related: Learn What’s Included in Jama Connect’s Medical Device Development Solution

ABOUT THE AUTHOR, VINCENT BALGOS
Vincent Balgos currently leads the Medical Solution at Jama Software. Prior to joining Jama Software, he worked in the medical device / IVD industry for over 17 years with roles in systems engineering, product development and project management. Vincent has successful history in launching new products to the global regulated market, and is experienced in product development, risk management, quality systems, and medical device regulations.

Part 1 of this blog series is available HERE. To read the whitepaper in its entirety, download it HERE.


In Vitro Diagnostic Regulation (IVDR)

This is part 1 of a two-part blog series covering our whitepaper, “The New EU In Vitro Diagnostic Regulation: What’s Changing and What You Need to Know” written by Vincent Balgos, Medial Solution Manager at Jama Software. In this paper, Vincent discusses the In Vitro Diagnostic Regulation (IVDR), developed by the EU Commission (CE), which was created to replace the previous In Vitro Diagnostic Directive (IVDD).

We will share the link to part 2 when it publishes. In the meantime, you can download the eBook HERE.

The New EU In Vitro Diagnostic Regulation (IVDR): What’s Changing and What You Need to Know

Learn more about how IVDR differs from IVDD, key takeaways from the new regulation, and guidance for how to adapt.

Disclaimer: The IVDR regulation is broad and requires focused review and interpretation by each organization — so by no means is this paper intended to be all-exclusive, as it will only discuss select topics.

Jama Software® is not an accredited regulatory body, so these are general discussions and insights from our experience working with many IVD customers, general research, and some internal subject matter expertise. It is suggested to work with a certified Regulatory Affairs consultant (a new IVDR regulation) to obtain formal recommendations for your organization.

If you’re looking for guidance on who to work with when it comes to regulatory compliance, TÜV SÜD has provided certification and testing services for manufacturers and suppliers of medical devices and in vitro diagnostics for over 30 years.

They combine expert medical product testing knowledge with a global network of internationally accredited laboratories and facilities, providing you with a one-stop solution. In fact, Jama Connect® is certified through TÜV SÜD as a software tool for development of medical devices according to IEC 62304. 

Introduction

In May of 2022 a paradigm shift emerged in how In-Vitro Diagnostics (IVD’s) will be developed, managed, and regulated in the European Union (EU). The EU Commission (CE) has developed new regulations named the In Vitro Diagnostic Regulation (IVDR) to replace the previous In Vitro Diagnostic Directive (IVDD). The main goal of the IVDR is to improve upon the quality, safety, and reliability of IVD’s within the European market. This will change the current status quo as IVDR has been predicted to have a significant impact in medical device organizations with IVD sale and business operations.

In this whitepaper, we will provide an overview of the new regulation, discuss some specific topics, and offer considerations for organizations as they adapt to this new paradigm.

Related: The Impact of ISO 26262 on Automotive Development

Overview of the IVDR and The Significant Impact on EU

Figure 1. CE Mark

Prior to the IVDR, the In-Vitro Diagnostics Directive (IVDD) was the governing regulation for devices placed in Europe. Officially adopted in 1997, the IVDD established the regulatory requirements for CE Marking approval for in vitro diagnostics¹. In order to sell and market IVD’s in the European Union, manufacturers need to show compliance with the essential requirements prior to marking the product with the CE label. The CE mark allows for legal distribution
of the IVD within the European Economic Area (EEA)². The CE mark indicates conformity across many different types of products and is based on compliance with specific European regulations based on the product type. See example marking to the left.

For medical devices and IVDs, compliance to the EU Medical Device Directive (MDD) and the EU IVDD was required to obtain CE marking, respectively.

Related: Medical Device: Reduce Project Risk in the Product Development Process

IVDD Overview:

  • IVDD was established in 1997 by the EU for trade within the EEA with 27 EU members plus Iceland, Liechtenstein, and Norway. 
  • IVDD applies to all Reagents, Calibrators, Kit, Instrument, Equipment, Systems used for in vitro diagnostics purposes in the EEA, regardless of origin of design and manufacturing.
  • IVDD is 43 pages providing general requirements. You can read the full document here.
  • Essential Requirements included requirements for design, production, labeling, and the instructions for use (IFU). Some specific requirements included the diagnostic’s analytical sensitivity and specificity, accuracy, repeatability, and reproducibility.
  • There are four general categories that are based on level of risk to public health and/or patient.
    • Annex II List A – Highest risk which require notified body review including HxV’s such as HIV, HBV, HCV
    • Annex II List B – Moderate Risk including IVD’s such as HLA, Glucose monitoring
    • Self-Test – Examples include pregnancy home tests, and cholesterol
    • General – No notified body required as OEM can ‘self-declare’ conformity

Key factors such as the device classification, risk level to patients/public, etc. would determine the manufacturer’s level of approach to developing, manufacturing, and documenting the IVD. A common industry practice for launching an IVD to the global market was that organizations would first launch their products in the EU, and then to broader markets. Due to less rigidity of the IVDD when compared to other countries, it was easier, faster, and more economical for companies to launch there first. The involvement of an external notified body was also less rigid, so many organizations tended to follow the least resistant pathway to market, with many following the ‘self-declaration’/ self-certification pathway. Learnings from the EU launch (e.g., clinical studies) could then be leveraged when then submitting to the more rigid regulatory pathways such as the U.S. Food and Drug Administration (FDA).

This common approach enabled organizations to get new products to the market faster through the regulatory pathway. In the author’s experience, this approach was practiced on many of the IVD’s developed throughout their career in multiple diagnostic applications. The general regulatory roadmap was to have initial launches in EU markets and then proceed with FDA pathway. This provided additional time to work on FDA submission activities since the level of rigidity and documentation was expected to be much higher. However, with the IVDR enforcement now in full effect, it is expected to have a tectonic shift in how manufacturers develop IVDs.

Related: Webinar: Understanding Integrated Risk Management for Medical Device

Compelling Events for Change

As seen with many types of general regulations, changes are commonly in response to mass incidents, generally with negative impact resulting in patient injury and sometimes even death. The US FDA has seen their regulations shift in reaction to mass incidents including the Therac-25 (radiation therapy) and Dalkon Shield (intrauterine device). The accidents led to significant legislative changes to prevent recurrences and improve industry practices to ensure ‘safe and effective’ products.

The emergence of IVDR follows a similar path, where there were European several high-profile events that led to the regulation update. The most notable was the Poly Implant
Prosthesis (PIP) breast implant scandal (based in France) that impacted many patients with high incidents of ruptured implants with unapproved industrial silicone filling. You can read more about the incident here, and the subsequent
clinical recommendations here.

This event led to significant updates to the medical device space with the culmination of the EU Medical Device Regulation published in 2017. Following the MDR initiative, the incumbent IVDD was also overhauled into the new IVDR paradigm which entered into force on May 26, 2017

Stay tuned for Part 2 of this blog series. To read the whitepaper in its entirety, download it HERE.