In this episode of the Jama Software© Innovation Insights Podcast Series our host, Jeremy Johnson, Vice President of Product Management and Product Design at Jama Software, joined by Joseph Pitarresi, Senior Product Manager, to talk about the Jama Software© Labs, an initiative with a team of extremely talented engineers and developers that apply new technologies, such as Natural Language Processing and Machine Learning, to help companies build better, more innovative, higher quality products with requirements management best practices.
Jama Software© Labs’ mission is to create off-road map technology and usage innovations with the freedom to ideate in a broader way, without the constraints of the traditional product roadmap.
Jeremy and Joseph also have an in-depth discussion on the new Jama Software© Requirements Advisor (technology beta) that provides an enhanced level of guidance on writing requirements with an unique approach on applying Natural Language Processing and two key best-known methods for authoring requirements (INCOSE, which is the International Council on Systems Engineering, and EARS, which is the Easy Approach to Requirements Syntax).
Below you’ll find the full podcast episode and an abbreviated transcript. Stay tuned for coming episodes in the Innovation Insights Podcast series!
Jeremy Johnson: Hello, and welcome to this edition of Jama Software Innovation Insights Podcast Series. I’m your host for today’s edition, Jeremy Johnson. I’m the Vice President of Product Management and Product Design here at Jama Software. Joining me today is Joseph Pitarresi. He’s our Senior Product Manager, overseeing Jama Software’s innovation and new technology initiatives.
Joseph Pitarresi: Hi everyone.
Jeremy Johnson: Joseph is a 30 year veteran of product development and innovation in semiconductor, automotive and software industries. He’s worked in natural language processing and other new technologies along the way. Thanks for joining us here today. Joseph, welcome.
Joseph Pitarresi:Thanks. This is going to be a lot of fun. I’m excited to share what we’ve been doing.
Jeremy Johnson: Absolutely. Today, and it’s really fitting for us [00:01:00] today. I think Joseph, that in this innovation series, we’re going to talk about Jama Software Labs. This is really an initiative that we started about a year ago. Really highly focused initiative targeted team, of course, with yourself leading from the product management side. We have a small team of really extremely talented developers working [00:01:30] with you on these initiatives. For the folks listening out there, it’s really something that we looked at that. We wanted to look at how we could apply new technologies to our solution set. Looking at things like natural language processing, looking at machine learning, to help our customers really build better, more innovative, higher quality products and so we formed this team and really [00:02:00] wanted to have this team that could work quickly, work iteratively, look at things and really try to see what fit, what resonated with customers, what could really add a tremendous amount of value.
How we could unlock some of the potential that we have with Jama Software, the content that we have, throughout our customer base, so it was a really great opportunity to augment what we’re doing in our core customer focused roadmap. I think the topic that [00:02:30] we probably should talk through first here, Joseph is, what are some of the initial areas, the primary focus that you and the team have here, initially and what gave rise to that focus? What were some of the challenges that we’re looking to address?
Joseph Pitarresi: Well, thanks again. I appreciate the opportunity to talk about what we’re doing. I’m just going to reiterate, Jama Labs mission [00:03:00] is to create off-road map technology and usage innovations. We’re a research team, so what we’re doing is of course, our objective is to intercept the roadmap with new technologies, but we have the freedom, which helps us ideate in a broader way, without the constraints of the traditional product roadmap. We’re constantly looking for things that can add to that, but we have a little bit more freedom to experiment and [00:03:30] actually fail and that’s really helpful in our process.
Jeremy Johnson: Absolutely.
Joseph Pitarresi: We’re a hundred percent agile, so we focused on rapid ideation and functional prototyping. We collect feedback and we repeat. There’s equal value to things that people like and things that people don’t like, because when we get negative feedback, that gives us the opportunity to ideate and create new technologies and new capabilities. That’s [00:04:00] how we work. When this project originally started, we looked at a lot of different areas of potential innovation. One of the first things we did was, we looked at some third-party research and we like engineering.com. A lot of customers develop highly engineered products. We found some really interesting things, so over the last seven years, 90% of engineers, [00:04:30] people interviewed, reported increasing complexity in their products. Specifically, the parts of this product complexity, is involved increases in mechanical design, intricacy, the increased use of electronics, new materials, applying new materials to new product development and increased software complexity. That’s both the embedded software and user software. [00:05:00] That was really helpful to look at that. Then, they also indicated, 83% of the product failures that they experienced, were due to poorly documented requirements. It’s like, Wow, that’s a pretty big indicator that there’s an opportunity.
Jeremy Johnson: That’s huge, yeah. Absolutely.
Joseph Pitarresi: Huge. 62% said that regulatory reprimands were based on [00:05:30] the same problems, associated to poor documentation, or inadequately authored requirements. Those really shone the light on the area that we want to focus on. Then, beyond the third-party research, we started interviewing our own customers. It became really clear that were significant challenges, in terms of authoring, accurate requirements, helping them be understood across organizations. Development [00:06:00] teams today are geographically dispersed. We have a new era of privilege, in terms of seeking the best talent, regardless of where they are geographically. Teams are often geographically dispersed. Sometimes that includes challenges around native language that’s spoken as well. Our customers really confirmed that this was a good area for us to work in. [00:06:30] This pointed us to this idea of, how to increase requirement quality, provide some guidance. We’re not the engineers, we’re not engineering the product, but, how can we help, in terms of structuring the language that’s used and the language used in engineering requirements is very specific. It’s not traditional [00:07:00] language opportunities, very specific to engineering requirements.
Jeremy Johnson: Yeah, absolutely. That’s great. That’s good feedback on that area. I think the interesting piece, I think, coming out of this research of course, is when the team, we started looking more closely at it, you and your team started looking more closely. [00:07:30] We saw this opportunity and over the last couple weeks here, have introduced the Jama Software Requirements Advisor, technology beta. Just to give folks an idea of what that looks like, and I should probably mention upfront, that that is something that’s available for folks to look at. It’s free. It’s something that provides a level of guidance on requirements. That’s [00:08:00] at labs.jamasoftware.com. It’s a beta application and I’ll ask it here, Joseph, to dive into some of the details on that, but a lot of folks want to know, what does that mean, what does a beta mean, what does that look like?
Really, it’s a technology test, right? The team has gone in and looked at some of these quality components, looked at some standards in the industry, that can really provide a level of guidance. [00:08:30] Develop this web interface, it’s out there, it’s free. It can provide guidance for people, that are looking for a level of guidance on writing requirements. It’s of course, advantageous to us, because we get an understanding of usage patterns and things like that in the industry. I think our approach, there are some other folks in the industry, that look at this, but our approach is a little bit different. We look at a couple industry standards and things, and I [00:09:00] think it’d be good for Joseph to maybe talk folks through our approach and how we looked at that Requirements Adviser beta, and some of the components that make up that analysis.
Joseph Pitarresi: It’s a very interesting process. Jama Connect is a really comprehensive platform, with many capabilities. In [00:09:30] looking at how we were going to approach this, we felt that it would be best, for our mission, in terms of rapid ideation and agile development, to develop this as a standalone capability. To develop the core technologies and worry about integration and integrating within Jama Connect, after we mature the technology. That’s really our approach. We plan on that. That’s our [00:10:00] objective, is to land within Jama Connect, but right now this is a standalone web application, because of that, it’s very easy to access the news. That allowed us to craft a very frictionless experience. You can really log in and use it right away. What is the Jama Labs Requirements Advisor, is a good question to start with.
What it does, is it delivers fast, [00:10:30] accurate analysis for an advice, for offering requirements. Since requirements use natural language, we’re applying natural language processing. Now, the natural language in engineering requirements, is different from authoring a resume or another type of document. We’re focused on that type of language, so fine tuning the engineering language that’s used in requirement statements. In looking across the industry broadly, [00:11:00] we found two key best known methods for author and requirements. The first one is from INCOSE, which is the… INCOSE is the international council on systems engineering. They actually have developed some rules around writing good requirements. Like all good rules, they’re technical and they’re specific and they’re good for experts. They’re hard to use for [00:11:30] average writers and authors. We really looked at those rules. Then additionally, another area that’s surfaced is the EARS.
It’s the easy approach to requirements syntax. What we found is we have a good rule book, which it’s right on, developed from INCOSE, but then, how to apply those rules and structure sentences, is something that EARS really provides, the easy approach [00:12:00] to requirements syntax. Our assessment of statements combined, it’s a unique combination of both of those lenses on requirements statements. That’s the unique value that we’re bringing to this space. We’ll talk more, a little bit more about INCOSE and EARS. If you go to the website, there’s a lot of detailed references to both those, which are really useful. In a sense, we’re taking those two industry best known [00:12:30] methods, combining them in a unique way to assess requirement, statements and then reporting, evaluating those, based on those filters. That’s our approach. Now, that’s how we’re starting.
Jeremy Johnson: I think the thing that’s… A couple of things that are key there, that are, I think important to stress. You noted the variability in [00:13:00] folks that are experts in requirements. Have done it for many years, have formal training and they’re extremely active. We tend to hear a lot then from… What about these other engineers? These other folks, that are as part of this product development process. There may be a irregular authors or requirements, or they’re less experienced [00:13:30] or on a project by project. I think that’s one of the things that we’re… That’s exciting for us and exciting for our customers that we’ve started talking to initially is, how can we provide a level of guidance to those folks, that don’t have that formal training or they’re not offering regularly?
I always talk about, our customers are not requirements offering companies. That’s not what they do. They build very [00:14:00] cool products. They need this… Something like this, to really reduce some friction in their development cycle. For folks that don’t have to hit the books and hit training classes, they can get constant feedback and things like that to really tighten things up. I think that’s something that’s very critical and I’m curious too and I think the folks listening will be curious to [00:14:30] understand, those are one of the things we’re focused on. What are some of the things that you’re hearing, that we’re hearing, just from this initial beta getting feedback, as we entered through this process. What are some customers saying? What’s the feedback thus far?
Joseph Pitarresi: It’s really been a fantastic experience, working with our customers and having that close relationship. Actually, the customers are expressing [00:15:00] the fact that we’re listening and responding, is something that is really valuable to them. We’ve had a lot… Customers have been delighted actually, with the tool. They’ve confirmed the problem that we identified and that we’re trying to solve. They’ve taught us some things about the tool and the value of the tool and how it might be able to help. Today, we have advisor of customers in the medical device sector, [00:15:30] automotive, aerospace, and defense and silicon development. These are all rapidly growing, highly technical, innovative sectors, that are looking for help, as much as they can. What we found is that, even though this is a standalone web app, separate from Jama Connect, customers are adopting it and using it [00:16:00] for their real work today, so they’re trialing it, giving us feedback and they’re literally using it to refine statements and put those statements into Jama Connect. It’s already helping them, so that’s really encouraging, from our perspective.
Jeremy Johnson: Absolutely.
Joseph Pitarresi: Another thing that they’ve taught us about, which I guess we could have thought of it, but we didn’t. The value, the educational [00:16:30] value of using this tool, is really high. Again, with customers, what we found is that, typically, in the senior levels of the organizations, in the engineering and development organizations, there’s pretty good awareness of the INCOSE rules and their value and their importance. And also, even EARS, which was this kind of development with Rolls Royce Aerospace. The awareness at the senior level on those [00:17:00] best known methods is quite good. But, repeatedly over and over, we’ve heard they’ve had a really hard time, winning adoption into the lower levels of their organization and even into the individual team level and then also, training. There’s this barrier. Not only is the awareness well at the high level, but building that in the organization is important. [00:17:30] Then also, training.
People just don’t have the time or don’t want to take the time, even though its valuable time to spend, to take formal classes on the INCOSE rules and also on EARS. Then, develop the skills on how to apply those. The really cool thing about this and we should have known that when we started, but it’s something that our customers have told us. Well, this helps them win adoption, within their organization, [00:18:00] for using the INCOSE rules. Then, while people use it, use the adviser, they’re learning the best known methods, so it becomes more automatic in their behavior. I’m excited about that now, more so in the front and I didn’t really even start on this adventure with that in mind. That’s… It’s really high value from that, so customers are really positive.
RELATED: Jama Connect® for Automotive: Accelerate Requirements Management for Safety- and Cybersecurity-Critical Systems
Jeremy Johnson: I think that’s a… These companies [00:18:30] are moving so quickly, to get things to market, to meet compliance deadlines, to do all of those things, that you’re right, taking time out to do a seminar and doing formal training and things. I think we all know, just the nature of teaching and learning is doing one upfront seminar and then never addressing it again. It’s very difficult to then get that in part of your thinking and application, so putting this stuff in real time, is certainly a significant [00:19:00] benefit to these companies that are really trying to move quickly. And you’re right, we thought the efficacy and the quality of requirements would be and certainly that’s paramount to these companies, but having that real time and that educational piece and getting this indoctrination, has been pretty significant. Pretty good feedback.
Joseph Pitarresi: One thing that the customers have told us is that, because they’ve experimented with different tools, [00:19:30] trying to improve requirements. Repeatedly, over and over, each customer has told me, the closer in time you can provide this feedback, to the task of writing and authoring requirements, the more powerful this is, from a quality enhancer and also from a learning perspective. Whatever you do, as you go forward, try to bring it closer together. Bring back the evaluation [00:20:00] and the reporting, in the time context of actually offering, so make it as real-time as possible.
Jeremy Johnson: Absolutely. Well, I think that’s a good place for us to take a break. We’ll pick this up in part two of this edition, where we’ll focus on general best practices of requirements development. We’ll also cast our gaze a little bit more into the future of Jama Software Labs. Joseph, again, really appreciate the insight.
Joseph Pitarresi: Well thanks, Jeremy. I just want to encourage everyone [00:20:30] to give Adviser a try at labs.jamasoftware.com and I’m really looking forward to continuing our discussion.
- The Seven Steps to Performing FMEA - February 22, 2024
- Overview of FDA ISO 13485 and 21 CFR Part 820 Harmonization - February 20, 2024
- Secure by Design: A Crucial Imperative for Medical Device Teams - February 15, 2024