FAQ: EARS Notation and Jama Connect™ Requirements Advisor
In our recent webinar, Adopting EARS Notation to Improve Requirements Engineering, attendees learned more about adopting EARS (Easy Approach to Requirements Syntax) to improve requirements engineering and got an exclusive look at the upcoming Jama Connect® Requirements Advisor, a tool in development that allows you to check the quality and accuracy of your requirements by leveraging the power of natural language processing.
That webinar included an extensive question and answer session from attendees. In this blog, we’ll present an extended list of frequently asked questions about EARS and Jama Connect® Requirements Advisor
Frequently Asked Questions
1: Why is it important to write good requirements?
Well-written requirements are critical for the development of any successful system. Requirements drive the design, development, and user experience of the system. Well-written requirements can improve productivity and quality. A good requirement states something that is necessary, verifiable, and attainable.
2: Is my requirement data secure?
Yes. Requirements Advisor Beta uses the same portfolio of security solutions as the production release of Jama Connect.
Your requirements statements stay within the Jama Connect Cloud with the same proven protection of Jama Connect.
3: What are the benefits of Requirements Advisor Beta for Jama Connect?
Improve the quality of your requirements statements quickly and efficiently using natural language processing.
Reduce the risk of late-stage errors.
Assists development teams in standardizing your process for requirement authoring, saving time, and enhancing accuracy.
4: When will Requirements Advisor be available in Jama Connect?
Beta: A limited customer beta is planned to begin calendar Q2 2022
Release: Initial product release is planned for H2 2022
Jama Software® reserves the right to continue development and consider potential, future Jama Connect integration options. Users can contribute to future capabilities by using the beta and providing feedback to Jama Software. Jama Software retains the rights to Jama Software Requirements Advisor and all derivative works.
5: How are requirements statements evaluated?
Advisor applies industry best-known methods from both INCOSE* and EARS*. Please review the details that follow on both below.
6: What is INCOSE?
International Council for Systems Engineering (INCOSE) is a not-for-profit membership organization founded in 1990 with the following goals:
Develop and disseminate the interdisciplinary principles and practices that enable the realization of successful systems.
Promote international collaboration in systems engineering practice, education, and research.
Assure the establishment of competitive, scale-able professional standards in the practice of systems engineering.
Encourage governmental and industrial support for research and educational programs that will improve the systems engineering process and its practice.
Learn more about INCOSE
7: Why use INCOSE rules?
INCOSE reflects the principles and processes of system engineering. The INCOSE Guide for Writing Requirements focuses on writing requirements in the context of systems engineering. It emphasizes the need to consider the context of the system of interest when writing requirements. Considering the environment in which the developed system is located is an integral part of the system approach.
8: What is the INCOSE Guide for Writing Requirements?
INCOSE created and published the first Guide for Writing Requirements in July 2009. Since then, the document has undergone several reprints, which incorporated the suggestions and comments of various practitioners. The latest version of the guide, (V3) at the time of this writing, was published in June 2019.
Alistair Mavin, “Mav,” the originator of the Easy Approach to Requirements Syntax (EARS) describes it as follows:
EARS is a mechanism to gently constrain written requirements. The EARS patterns provide structured guidance that enables authors to write high-quality requirements.
Mav and his colleagues at Rolls-Royce PLC developed EARS while analyzing the airworthiness regulations for a jet engine’s control system. The regulations contained high-level objectives, a mixture of implicit and explicit requirements at different levels, lists, guidelines, and supporting information.
In the process of extracting and simplifying the requirements, Mav noticed that the requirements all followed a similar structure. He found that requirements were easiest to read when the clauses always appeared in the same order. These patterns were refined and evolved to create EARS.
There is a set syntax (structure), with an underlying ruleset. A small number of keywords are used to denote the different clauses of an EARS requirement. The clauses are always in the same order, following chronological logic. The syntax and the keywords closely match common usage of English and are therefore intuitive.
The notation was first published in 2009 and has been adopted by many organizations across the world.
System requirements are usually written in unconstrained natural language (NL), which is inherently imprecise. Often, requirements authors are not trained in how to write requirements. During system development, requirements problems spread to lower levels. This creates unnecessary volatility and risk, impacting program schedule and cost.
EARS reduces or even eliminates common problems found in natural language requirements. It is especially effective for requirements authors who must write requirements in English, but whose first language is not English. EARS has proven popular with practitioners because it is lightweight, there is little training overhead, no specialist tool is necessary, and the resulting requirements are easy to read.
EARS is used worldwide by large and small organizations in different domains. These include blue-chip companies such as Airbus, Bosch, Dyson, Honeywell, Intel, NASA, Rolls-Royce, and Siemens.
The notation is taught at universities around the world including in France, Sweden, UK, and USA.
In this blog, we recap a webinar discussing Adopting EARS (Easy Approach to Requirements Syntax) to Improve Requirements Engineering.
Requirements are the foundation of a smooth-running process and are the essential inputs to your mission-critical projects. Yet writing requirements is also a practice that many underestimate and fumble.
The Easy Approach to Requirements Syntax (EARS) is a notation that “gently constrains” natural language requirements to help teams to easily achieve desired outcomes. Not only does adopting the EARS notation improve the quality of requirements, but it also enables cross team collaboration and synergy, improves product requirements, and reduces project risk. This webinar will introduce the EARS notation and walk through the benefits for both individuals and teams.
In our recent webinar, attendees got an exclusive look at the coming Jama Connect Requirements Advisor, a tool in development that allows you to check the quality and accuracy of your requirements by leveraging the power of natural language processing.
Watch this webinar recording to learn more about:
How to write better requirements with EARS, and the benefits for both teams and individuals
How EARS works alongside models and can help uncover what is not yet know
How Jama Connect Requirements Advisor will facilitate embedding EARS notation in your requirements engineering work.
Below is an abbreviated transcript, including a portion of the Q&A session at the end of the event, and a recording of our webinar.
Adopting EARS Notation to Improve Requirements Engineering
Alistair Mavin: What is this requirements engineering thing all about anyway? Well, in theory, you could say that requirements engineering is quite easy. What is requirements engineering? Well, you ask people what they want, you write it down, you build it and then you check that it does what they ask for. Like a lot of things, if you put it to a high level, it’s perhaps quite simple, but there’s obviously a lot more to requirements than that and they are in themselves quite slippery and difficult things.
But relevant to EARS, I think is the notion that asking people what they want and then writing them down, how you choose to write it down can guide what you ask them to tell you and can help them to tell you the useful things that you can then write down more effectively. The inherent nature of EARS, which I’ll explain in a little more detail helps a lot with elicitation because it identifies the things you need to know in order to write down a well-formed EARS-compliant requirement. There are certain things you need to know to be able to populate an EARS requirement effectively. That means you interrogate people, you ask people the right questions to be able to write a good question. From very early in your requirements elicitation, you are seeking the right information to get clearer requirements.
Alistair Mavin: I’ve said that in theory, requirements engineering is very easy. In practice, it’s not so easy. First of all, people don’t necessarily know what they want. If they don’t know what they want, they can’t tell you or maybe they do know what they want, but they don’t know quite how to express it, or if they’re an expert in something and after all many requirements are elicited from subject matter experts in various fields, it’s a well-known characteristic of experts that they don’t actually consciously know some of what their knowledge is. It’s so obvious to them and implicit. It’s tacit. They actually would struggle to articulate it because it’s so obvious to them, they don’t think of even mentioning it. That makes it quite a tricky discipline.
People want different things. If you’ve got a whole load of stakeholders, they’re going to want different things. They may be intention or in direct conflict. Who do you even ask anyway? Who are all the stakeholders? Almost always more than you first realize. Some of those stakeholders may not be available. You may literally not be able to get hold of them because they’re too busy or contractually or geographically or in time zones or for whatever reason, it might be hard to actually speak to those people. And of course, requirements also come from other places and people from documents and so on.
Below is an excerpt from the Questions and Answers portion of the webinar:
Question: “EARS notification seems beneficial for system requirements equals higher level requirements, but what about other low level requirements? What can you recommend using EARS for which level of requirements and for which requirement levels not using it?
Alistair Mavin: Good question. The first EARS paper, all we claimed was we’ve run it past some high level system requirements for a jet engine control system and it appears to work. That’s all we claimed. Subsequently, it was used by the team I was with within Rolls Royce and other people within Rolls Royce, and then once the paper was published, other people in other organizations for different sets of data in different domains and for systems at different levels. The short answer is it can be used pretty much at any level.
I mean, if you think about a system of… The thing about requirements engineering for me is you define your system to be built and you consider that as a block box. What are the inputs to it? What are things that it can detect that it’s going to react to? And what outputs does it produce in response to receiving those inputs? A system is a transfer function of inputs into outputs. Your system is whatever you define as a system. In that sense, you can do it pretty much at any level. The simple answer is it works at any level.
Interestingly, since we’ve talked about lower levels, one of the other questions, well, it’s not a question, but it’s a point put in the Q and A, Frederick Wolf, if I pronounce the correctly. Renault Software Factory is using EARS. There you go. Software people use EARS.
Question: “EARS notification seems to me to only be applicable to capture functional requirements. What about nonfunctional requirements, namely quality requirements and constraints?”
Alistair Mavin: Short answer, yes. EARS can handle nonfunctionals of all types. The way I recommend treating nonfunctionals within EARS is… It’s difficult to answer. This is a very short answer in the time we’ve got, but there are three distinct ways that you can handle nonfunctionals. Constraints can be handled with any EARS pattern. The system shall have a certain weight, maximum weight, shall comply with a standard, shall interface with some other system. Those sort of things can be specified just using any EARS pattern.
If you have a nonfunctional aspect that applies the one function, the system shall display a message within one second, that within one second is a quality of service. It’s called an EARS, is a little suffix you put on the end of an EARS requirement, which somehow gives a quality measure to how quickly, how accurately type of thing on the end of a functional requirement. Then the quality and performance requirements, which in a way are the purely nonfunctional requirements, if you like, quality and performance requirements, I recommend having three measures. A must, a plan, and a stretch, which is rather like Gilb’s Planguage, which handily, question four…
Question:“How does EARS compare to Gilb’s Planguage?”
Alistair Mavin: Well, in terms of how it handles nonfunctionals, it basically follows Gilb’s suggested notation for how to follow nonfunctionals. You would write a required following the general principles to make an EARS compliant requirement, but you would explicitly and specifically put in an imprecise word such as quickly, which in a normal requirement, you would not want a word like quickly. I would recommend tagging them as this is a QPR, this is a quality and performance requirement, so you know it has knowingly got an imprecise word such as quickly, and then you’d have metadata. Another attribute that says must, what’s the worst quickly will be? Within three seconds. The plan is within two seconds and the stretch is within one second. That maps exactly to Gilb’s Planguage… is taken from Gilb’s Planguage.
Question:“Is Jama Software the only provider of an EARS tool?”
Joseph Pitarresi: No, there are other suppliers in the market. Our approach, however, is to really provide this tool as a benefit to all Jama Connect users, many of the other solutions, and there are excellent solutions in the marketplace and we have partners that offer solutions as well, are created from a custom development process to where there’s either a special development tool and hands-on consulting required to develop a detailed approach to artificial intelligence. Again, we’re trying to provide the 80%, 90% of the value at a very high level across the INCOSE and the EARS patterns.
And so, we think that’s a huge value opportunity that we’re addressing, but we highly are happy to refer you to our partners who can build custom solutions for EARS analysis if you want to go into that kind of depth and you can contact me and I’m happy to refer you to our partners who want to go even deeper more than the Advisor, but just to be clear, Advisor will be integrated in our Connect platform. You’ll round trip your requirement statements that are in Jama Connect to the Advisor and back once you’ve decided if you want to make some changes. And so, it’ll be very quick and efficient right within our tool. You don’t have to be popping in and out of different tools.
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.
![[Webinar Recap] Adopting EARS Notation to Improve Requirements Engineering](https://www.jamasoftware.com/media/2022/03/WB-2022-03-23_Adopting-EARS-Notation_Social-Image-1024-×-512-px.png "[Webinar Recap] Adopting EARS Notation to Improve Requirements Engineering")
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.