Tag Archive for: Requirements & Requirements Management
As we enter 2023, Jama Software® asked selected thought leaders – both internal Jama Software employees and our external partners – across various industries for the trends and events they foresee unfolding over the next year and beyond.
In the second part of our five-part series, we asked Craig E. Miller, PhD – Principal Engineer at Ansys, to weigh in on product and systems development trends he’s anticipating in 2023.
Visit part 1 of this series, 2023 Predictions for Product & Systems Development Teams here. We will link the remaining 2023 Industry Predictions as they are published.
Read more about the author at the end of this blog. Note: The opinions expressed are those of Craig E. Miller, PhD.
2023 Predictions for Aerospace & Defense Product Development
Design Trends – What are the biggest trends you’re seeing in your industry right now? How will they impact A&D product, systems, and software development?
Craig E. Miller: The most common design trend — one that will continue in the short and long term — is identifying how a digital transformation can enable a connected digital thread. A connected digital thread enables an organization to realize efficiencies encompassing all design teams, how these teams exchange data, and how enterprises will exchange data. A&D companies that can weave the design digital thread with business will become industry leaders. The digital thread can significantly improve efficiency relating to supply chain, energy, and safety. For example, virtually certifying subsystems — to quickly add suppliers to approved vendor lists — can add flexibility to supply chains. Coordinating digital hardware design, embedded software, and data (from T&E and/or the field) can enable trade studies to optimize energy efficiency of complex systems and can identify failure modes and expedite design modifications on existing (and future) platforms for continuous improvement.
Biggest Challenges – What are some of the biggest challenges you think A&D engineering firms will be working to overcome in 2023?
Miller: Probably the biggest problem that A&D firms need to solve is balancing resource allocation. How do you fulfill your future digital strategy without compromising short-term production work? Another significant challenge is managing supply chains, as global conflicts and inflation threaten to disrupt them. I would also add workforce enablement and cross-pollinating primary engineering efforts across aeronautics, space, and cyber as important challenges with respect to maintaining a competitive edge.
Regulations – What changing regulatory guidelines do you anticipate having an impact on companies in 2023?
Miller: Enabling virtual certification and coordinating virtual hardware design with software and data both require standards and regulations on virtual engineering. Such standards and regulations need to be coordinated among government, academia, and industry, and consortiums should start as soon as possible.
Tool Innovation – From an A&D engineering toolset perspective, what are some of the processes you think forward-thinking firms will be working to leverage or incorporate into their process, and why?
Miller: Aerospace and defense firms recognize that making the right choices, early, is the only way to succeed against the dual problems of increasing complexity and decreasing timelines. And one of the best ways to improve decision making is through engineering simulation standards, some of which are being developed right now. These standards should capture contextual metadata, facilitate collaboration, and make it easier to share knowledge within an organization — all of which contributes to faster, better-informed decisions.
It will be vital for the industry to support and adopt effective standards in the years ahead. And the challenge goes beyond development and adoption, because you have to manage the transition, too. In other words, if you adopt a standard without defining a clear path from “here” to “there,” you risk your teams developing ad hoc approaches, and that leaves you once again without a standard.
In your opinion, what are the biggest differences between an A&D company that survives to see 2030, and one that doesn’t?
Miller: The biggest discriminator has to be the ability to adapt to increasing complexity on shorter time-scales. These two pressures are everywhere, and they compound each other.
What advice would you give to new companies entering the A&D industry?
Miller: Take advantage of hard-earned wisdom and start with the right approach. Common traits of successful digital transformation initiatives are an open ecosystem, mission-centric alignment across teams, and a connected digital thread to facilitate and maintain that alignment. This is the what established firms are trying to achieve, but to get there they must contend with their legacy data and processes, as well as promoting a cultural transformation to enable this journey.
What do you predict for regulation in the A&D industry in 2023?
Miller: Certification for process and people. Regulation of training standards for people supporting a digital transformation. What coursework, certifications, etc. are required when matriculating from traditional design and manufacturing into modern environments? And this isn’t a question just for design and manufacturing engineers — it applies equally to management, to track that change process.
Will those trends still be prevalent 5 years from now? 10 years?
Miller: The trend of digital transformation will evolve for the next 5-10 years. There are many aspects of an A&D business that digital transformation will affect, and each will have its own prioritization that dictates the short- and long-term tasks to enable their digital strategy.
About the Author:
Craig E. Miller, PhD – Principal Engineer at Ansys
Craig Miller is a Principal Application Engineer with ANSYS Inc, where he leads several multiphysics simulation efforts for the Aerospace & Defense industry. Prior to ANSYS, he designed and analyzed a range of products, from nuclear reactors to fiber optic devices. Craig was a Graduate Research Fellow while earning his Ph.D. at the University of Maryland and earned his BS in Engineering Science at Penn State.
https://www.jamasoftware.com/media/2022/12/2022-12-08-2023-predictions-aerospace-and-defense-1.jpg5121024Decoteau Wilkerson/media/jama-logo-primary.svgDecoteau Wilkerson2022-12-08 03:00:032024-01-18 10:17:082023 Predictions for Aerospace & Defense Product Development
As we enter 2023, Jama Software® asked selected thought leaders – both internal Jama Software employees and our external partners – across various industries for the trends and events they foresee unfolding over the next year and beyond.
In the first part of our five-part series, we ask Josh Turpen, Chief Product Officer at Jama Software, to weigh in on product and systems development trends he’s anticipating in 2023.
We will link the remaining 2023 Industry Predictions as they are published. Read more about the author at end of this blog.
2023 Predictions for Product & Systems Development Teams
What product, systems, and software development trends are you expecting to take shape in 2023?
Josh Turpen: Natural Language Processing (NLP) is coming to the engineering space in a big way. Far from the “robot overlords” that have been feared, this technology is revolutionizing quality by spotting poor writing and anti-patterns as engineers are working, instead of late in the process during Root Cause Analysis (RCA) for test failures.
In terms of product and systems development, what do you think will remain the same over the next decade? What will change?
Josh Turpen: Development will continue to struggle with the changing regulatory and security landscape. This has been a perennial problem in software and hardware is feeling it more and more with an increasingly connected ecosystem. I’m excited for tools that offer easy traceability to regulatory requirements. It makes it so much easier to validate everything from tests to requirements to regulations, ensuring that you’ve met the mark. This level of discipline should become the norm.
How do you foresee regulations shifting in product and systems development over the next decade? Or maybe just engineering, or systems engineering, in general.
Josh Turpen: Security and safety regulations for advanced technology will start coming with severe financial, and potentially criminal penalties. We’re starting to see the beginning of this, and it is high time the industry paid close attention. We’re moving beyond a point where security vulnerabilities are annoying and into a time where they will become casualty events.
Any major disruptions in product and systems development you’re anticipating in 2023?
Josh Turpen: I don’t think NLP quality linters will be a “major disruption” but more of a leading trend in quality focus in the systems engineering space.
What sorts of process adjustments do you think development teams will need to make to be successful in 2023?
Josh Turpen: The delta between those companies that have embraced a distributed workforce and those that haven’t will continue to grow. Those that still insist on collocated teams and “big meetings” for process control are going the way of the Dodo.
What do you think will be some of the differentiators between a company surviving to see 2030, and those that do not?
Josh Turpen: Embracing distributed teams and the technology that helps them be productive.
Organizations that define, measure, and improve processes are always going to outperform those that do not.
Josh Turpen: Companies that codify change into their process will dominate. They can absorb change, measure the impact, adjust accordingly and iterate. If your product development process can’t do this, it is what needs to change.
What advice would you give to new companies developing products or systems from scratch?
Josh Turpen: Define your outcomes! These can change as new information becomes available, but don’t underestimate the power of clearly stating your objective.
What topic(s) do you wish companies were paying more attention to?
Josh Turpen: Process measurement and improvement. It shocks me the number of companies that have a product failure and their “RCA” is a big meeting without data. As an industry we are awash in data and those companies that are using this data to improve will dominate.
Where do you see Jama Software fitting in as the product development landscape evolves, and what can our customers expect as 2023 approaches?
Josh Turpen: We are the recognized industry leader and have the largest repository of systems engineering data on the planet. New capabilities built on that data, like the Jama Connect Advisor™
and our Industry Benchmarks are just the beginning of the journey. New capabilities to spot process issues and anti-patterns are on the horizon.
About the Author:
Josh Turpen, Chief Product Officer, Jama Software
With a deep background in software development and consulting, Josh oversees the ongoing innovation and refinement of Jama Software’s core product offerings. Beginning as an engineer, Josh’s career has taken him from Indiana to Germany, Colorado, and Portland. His work with the U.S. Department of Defense solidified his knowledge of safety-critical systems, and the vital role requirements and risk management plays within them. Having led product and engineering organizations, with teams distributed across the globe, Josh understands the daily challenges our customers face in a constantly changing marketplace and the tools they need to be successful.
https://www.jamasoftware.com/media/2022/11/2022-12-01-2023-predictions-product-systems-development-teams-1.jpg5121024Decoteau Wilkerson/media/jama-logo-primary.svgDecoteau Wilkerson2022-12-01 03:00:232024-01-18 10:49:142023 Predictions for Product & Systems Development Teams
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?
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.
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.
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.
https://www.jamasoftware.com/media/2022/11/Doors-VLOG-Episode-5-intro.jpg10801920Mario Maldari/media/jama-logo-primary.svgMario Maldari2022-11-30 03:00:522024-01-18 10:51:51Jama Connect® vs. IBM® DOORS®: Document Generation: A User Experience Roundtable Chat
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?
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.
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.
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.
https://www.jamasoftware.com/media/2022/11/Doors-VLOG-Episode-4-intro-1.jpg10801920Mario Maldari/media/jama-logo-primary.svgMario Maldari2022-11-16 03:00:132024-01-18 13:17:27Jama Connect® vs. IBM® DOORS®: Review and Collaboration: A User Experience Roundtable Chat
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
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.
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.
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.
https://www.jamasoftware.com/media/2022/10/2022-11-03-sytems-engineering-1.jpg5121024Decoteau Wilkerson/media/jama-logo-primary.svgDecoteau Wilkerson2022-11-03 03:00:272023-01-12 16:46:13A Guide to Good Systems Engineering Practices: The Basics and Beyond
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.
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.
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.
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.
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.
https://www.jamasoftware.com/media/2022/10/Doors-VLOG-Episode-3-intro-3-1.jpg10801920Richard Watson/media/jama-logo-primary.svgRichard Watson2022-11-02 03:00:142023-01-12 16:46:14Jama Connect® vs. DOORS®: Filters, Search, and Analysis: A User Experience Roundtable Chat
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.
https://www.jamasoftware.com/media/2022/10/2022-10-26-jama-connect-advisor-press-release-1.jpg5121024Karrie Sundbom/media/jama-logo-primary.svgKarrie Sundbom2022-10-26 07:00:572023-07-26 12:41:47Jama Software® Releases Jama Connect Advisor™ – The Industry’s First Native, Natural Language Processing (NLP) Advisor to Improve Requirement Quality
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.
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.
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.
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.
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.
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.
https://www.jamasoftware.com/media/2022/10/Doors-VLOG-Episode-2-Blog-Image.jpg10801920Cary Bryczek/media/jama-logo-primary.svgCary Bryczek2022-10-19 03:00:362023-01-12 16:46:16A User Experience Roundtable Chat About Jama Connect® vs. DOORS®: Adoptability for All Stakeholders
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.
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.
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 Traceable 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
https://www.jamasoftware.com/media/2022/09/2022-09-20-jama-connect-accelerating-systems-development-1.jpg5121024Decoteau Wilkerson/media/jama-logo-primary.svgDecoteau Wilkerson2022-09-20 03:00:382024-07-10 15:51:07Jama Connect®: Accelerating Systems Development with Requirements Management and Live Traceability™
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.
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.
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.
Since 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.
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.
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.
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.
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.
https://www.jamasoftware.com/media/2022/09/2022-09-15-ivdr-part2_1024x512-1.jpg5121024Vincent Balgos/media/jama-logo-primary.svgVincent Balgos2022-09-15 03:00:412023-01-12 16:46:21The New EU In Vitro Diagnostic Regulation: What’s Changing and What You Need to Know: Part 2
Since IVDR’s announcement in 2017, many companies and SME’s (including this author) started to update