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:
Jeremy. Thanks again for having me. I’m happy to be here. Just want to reiterate, I’d love to have everyone check out Advisor. It’s at labs.jamasoftware.com.
Jeremy Johnson:
Absolutely. And that was a big focus of our first podcast in this series. We talked about Requirements Advisor. We talked about the Jama Software Labs team and our charter and where we’re focused here today. Where do you think we should take this discussion Joseph?
Joseph Pitarresi:
Well, Jeremy, it’s a great topic. If we step aside from Advisor for just a second, I think it would be good to touch on some general best practices for requirements offering. And then I can talk a little bit about what’s next for Advisor on our roadmap innovation roadmap, and also some new concepts that we’re working on in Jama Software Labs.
Jeremy Johnson:
Sounds great. Yeah. So let’s maybe start with that first topic. What do you see as some of the things that we see at Jama? Some of the best practices folks can take away for improving their requirements development process?
Joseph Pitarresi:
Yeah. Well, I think is a great topic. So stepping a little bit, aside from the Requirements Advisor itself, authoring requirements that are clear and effective, and what are some skills that are helpful. And actually www.jamasoftware.com has an amazing amount of free information on authoring requirements. For me, it’s great to have a high level view and also go down into the details, but I really like our five best practices for writing requirements. We actually have an infographic on that and a white paper in a webinar. But, in a nutshell, you really want to create a great, effective communication between the stakeholders and product development and get that synergy, that cross organizational synergy, because it takes many talents and skills and unique strengths that individuals bring to a product development team.
Joseph Pitarresi:
Yes. And that’s the beauty of it. That’s the fun of this work. But getting everyone on the same page is a significant challenge. And so some of the basic things I think that people should think about is, number one, is have a really clear understanding of the problem that you’re trying to solve. And that’s the start.
Joseph Pitarresi:
Also one of the things that our people probably spend the least amount of time on because there’s a lot of assumptions brought to the table about what problems they’re trying to solve. So I think documenting and really having a clear group understanding of problems that’s trying to be solved is fundamental. And then usually most of the time there’s a hierarchy of requirements and of importance.
Joseph Pitarresi:
And so it’s important for everyone to have a view on importance, but also the interconnectedness of different requirements for any product, project or product. So having a requirements hierarchy is really, really helpful. Again, written down.
Joseph Pitarresi:
So that’s really key. And another thing, one misstep that is so common, and I think almost on every project is while people are writing requirements, it’s very tough, particularly for engineers, it’s very tough to avoid integration of design within the requirements themselves.
Joseph Pitarresi:
You’re talking about a battery and you take in some comments about the chemistry. What chemistry is the best chemistry?
Jeremy Johnson:
Start getting into the how and the specific details. Don’t do that. Just put the functional requirement or the requirement in there. And then go through a separate process to figuring out the best way to design it and do it.
Joseph Pitarresi:
So keeping design out of the requirements is really key.
Joseph Pitarresi:
Another thing that’s obvious, but challenging is ambiguity. You don’t want it to have ambiguity. But that’s easier to say and hard to do.
Joseph Pitarresi:
Particularly in the complex environment where you have mechanical intricacy, complex software, complex material science being used. In the confluence of all the elements of creating the product and the core building blocks, it’s very easy to get ambiguous in the requirements because of the complexity of the products that people are building today.
Something to keep in mind when authoring requirements is to ensure that they are unambiguous.
And then, one really helpful thing to do is to use templates and include group discussions. So if you have a template for how to structure requirements to get started, that accelerates,, saves a lot of time, but then as those are filled out, make that a group discussion and not an individual discussion because that gets mutual understanding people involved in the project and that leads to successful projects so much. It’s an exponential element of successful projects.
Jeremy Johnson:
Yeah, yeah, absolutely. Absolutely. Yeah. And I think those are great things for folks to focus on. There’s another piece that we have out there that folks can take a look at as well. They hit on some of the things that you mentioned, but there’s some additional pieces. We’ve got the eight do’s and don’ts of requirements management. That’s another good one. You hit on templates. And some of those…The other component that I think is important to add would be regular reviews with stakeholders. And you touched on it before, the collaborative piece. So I think it’s one to reinforce with folks is looking at early stages of the development process, collaborating on requirements, doing peer level reviews before you get into the more rigorous in-depth reviews later in the process, making sure that you’re capturing the right level of detail that you’re hitting on some of these things that you’ve outlined, so that things are very clear. So much benefit can happen in the entire product development life cycle when the requirements are tight and clean and well understood at the front end.
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.
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.
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.