Requirements & Requirements Management

Innovation Insights Podcast Episode 2: Best Practices for Authoring Requirements

By |

Requirements Authoring

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, Jama Software’s Innovation and New Technology, share some best practices for requirements authoring.

Jeremy and Joseph also offer a preview of what’s next from the Jama Software© Labs Requirements Advisor that applies Natural Language Processing and adopts 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:
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.

To hear more about best practices for authoring requirements, listen to the full podcast.


Jama Software
Latest posts by Jama Software (see all)