Requirements Management - An Interview with Dave Ewing of Aras
/An Interview with Dave Ewing (Aras Product Manager) by Martin van der Roest of the vdR Group.
Martin
To start, give us a summary overview of Aras’ Requirements Management module.
Dave:
Requirements Management is another one of our applications that pairs with Aras Innovator and is part of the subscription model. Its primary capabilities are twofold. You can create individual requirements and requirement documents that are a collection of requirements. Typically, you are generating a requirements document or documents as you are designing a product or perhaps documenting regulatory requirements. That is the type of usage we see from our various customers.
Martin:
Profile the kind of organization and their activities that the Requirements Managements module supports.
Dave:
Requirements Management is an application that doesn’t get enough play across all industries and all sizes. For the most part, you see the largest instances of it in aerospace, automotive, and high-tech manufacturing. It’s the likes of Airbus, Boeing, Ford, GM, Lockheed Martin, and others with highly complex products.
If you don’t have a grasp on your requirements as you start designing and building these products, it’s very hard to make sure that you are staying the course as far as what those requirements dictated. You also see the same need in the chemical manufacturing or processing based industries. From a food and drug perspective, requirements are critical to be able to execute a quality product whatever that might be. We are encouraging a lot of folks to use it.
As for the activities, typically you see authors and consumers of requirements. Your requirement author might be your product or project engineers, depending on how your company is organized. Or, you might have specific requirement team members that handle that. They gather the information from customers and regulatory bodies and document them accordingly.
On the consumer side, you have your design engineering side of the world and manufacturing. They are then consuming those requirements and executing according to them. You know if your requirement says it needs to be 10 inches wide, the CAD people pick it up and make sure the design is 10 inches wide. In manufacturing, you might have a call out for a specific process, say anodizing. Then the manufacturing folks would use the proper anodizing process to achieve that specific anodizing requirement.
Martin:
With a couple of our partners, we are running into a number of build-to-order and/or engineer-to-order organizations. Is that a place for requirements management? If so, play out the possible use case we might encounter.
Dave:
Yes, I think Requirements Management fits right in. All of them have to start with requirements somewhere. If you are taking a build-to-stock perspective, your marketing team may be defining what the product needs to be. And that information is transferred to the product design team. If you have a highly complex engineer-to-order product, whatever that example might be, you may have a standard baseline. Starting from that design and those requirements that were set by the market and the industry, the customer says, “Okay I would like these modifications!” Capturing both levels of requirements is key to being able to validate that you’ve met all of those requirements. That leads to quality from a customer perspective, whether that’s a B2B or B2C environment.
Martin:
Ultimately, requirements management drives quality … which in turn strikes me as being a key value proposition.
Dave:
Absolutely, products continue to grow in complexity. There is mechanical and electrical coupled with more software on top of that. It’s imperative that you get those requirements written down in an actionable sense. Using Excel and Outlook to do that falls apart fast as the complexity takes off. It’s very hard for a human being to try to keep track of all of that. You need a system that allows you to capture the requirements, relate it to the different systems and/or parts, and that you can trace back and make sure that everything has been done.
Martin:
Dave, talk a bit more about “how it works” and the primary use cases.
Dave:
Well, there are two fronts that I talk about in a use case.
The first is capturing those regulatory requirements. Maybe it’s the FAA or FDA. They publish those documents that you can obtain from their website and they contain various requirements. In Aerospace seating, AC21-49 serves as a collection of requirements addressing the electronics that might be in a seat. You would take all those requirements in that document and author those as individual requirements in your PLM requirements solution. Then roll those together in a requirements document.
Martin:
So, are you suggesting that with the Requirements Management module you get a number of these standards already accessible or buried in for later access?
Dave:
The standards aren’t provided to you in an Aras requirement format, or an XML format. You know the regulatory body and the customer are providing you a PDF for a word file. Translating those into your requirements solution is a smart thing to do because those specs from the FAA or FDA or NTSB, aren’t changing daily. If you put the effort in one time, you are able to reuse those requirements many, many times over, in many products, and many R&D efforts.
Martin:
So what is the second use case?
Dave:
The second use case is related to the product, capturing the information for marketing, design, and manufacturing. And, most importantly, validating that those requirements have been met. Your internal design requirements are going to guide how you design the product; they can span many different domains. If you have a purely mechanical product, it might be one set of information. But, as you start to put electronics and associated information together, it is key to capture the requirements of how they need to operate also.
Now you have those two streams of requirements that come together and are consumed by the product design team. The validation portion of the use case is in the back end as you are going through a design review process; every company does that a little differently, but we generalize it. You can start to trace your requirements through the design process and check to see if each one has been met. A user can trace both forward and backward to insure that the intent of every given requirement is met. You can use reports in different ways to gather all that information. Every company will do it a little differently.
Martin:
Is there a provision that allows these requirements to be fed into test documentation?
Dave:
Yes. Absolutely, that is one of the examples we have in our demo database. You can reuse those in that manner and pull them into different documents. Because Innovator uses XML for interchange, it’s very straight-forward to build integration and whatever your document authoring tool might be. Let’s just say it’s Word. It’s a straight-forward effort to pull the information from requirement number 123 into your test requirement document and be able to issue that.
Now one of the areas that we are suggesting is to build your test plan right inside of Requirements Management. Now you can just link requirements back and forth, and have further traceability. Every company might need to walk before they run. As with everything else in Innovator, there are many ways to skin the cat, so we can help you build your business process, whatever that may be.
Martin:
I am going to veer off a little, but I wanted to call attention to the Tech Docs solution that I know is coming out around the New Year. Will Tech Docs have a role in being able to be the recipient of these requirements for creating test documentation?
Dave:
Yes, I think so. You bring up a standard use case. I anticipate that Tech Docs will have connections. From a Change Management perspective, if my requirement changes, I need to change those tech documents. So, I do need a connection between the two and that’s a very standard case and an important one.
If a requirement changes significantly, you may need to change your test plan. If you are not capturing that, your testing finds out. The test team tends to be the end of the design cycle where they don’t have a lot of time to make changes. You could be setting them up for failure, if you didn’t capture the necessary information. That goes right back to that value of why you should be capturing requirements and why you should be managing them during the entire lifecycle of the product design.
To capture the value and to make sure your team has the information they need, make sure the changes are propagated. We think that is the key reason to integrate Requirements Management into PLM and to not have that information sitting out on an island.
Martin:
It seems like it would be a very compelling combination of solutions.
Finally Dave, give us some thoughts on the factors a company should be thinking about in setting something like this up?
Dave:
Well, as far as the literal set up in terms of the software, you need a subscription. This is just a matter of downloading the package and performing the installation. It’s actually a very straight-forward process. It creates the items types and all the necessary relationships.
Last time we talked about Change Management and taking a critical look at your processes. I think this is the same kind of thing. Take a critical look at your requirements process. Does the out-of-the-box requirement solution fit that bill? You may need to tweak the process a little bit in what lifecycles you might want the requirement. Those things would need to be upgraded from our general out-of-the-box solution to something that fits your business processes.
From there we tend to be practitioners of lean, agile or scrum. I’d suggest you would want to use it for a while … say six months. Then use that as a point where you can look back at what’s working, what’s not, make the first set of tweaks, and be able to apply those rapidly, so your business is able to upgrade. The software is resilient and can upgrade with you, and you can get the most value out of the product.
Martin:
What are the version considerations for the Requirements Management module?
Dave:
You can run it on 11R2. We have a service pack upgrade that we will be pushing out with 11 service pack 5.
Martin:
Dave, are there any other comments you would like to offer?
Dave:
Yes, from a general perspective we encourage our customers to go with a connected PLM solution. This connection is something we have been looking at as we look at model base systems engineering (MBSE), technical documentation and quality documentation. Specifically, how do these solutions have to play together to pass information back and forth? The link from a requirements item to testing documentation link is very important, as are all of the other links made in a product design. So there will be some upgrades coming forward in requirements as we look into version 12. From that aspect, we certainly would be encouraged to have ideas or thoughts or use cases from our customer base and our partner base that says, “Hey, these are some of our use cases.” It would be nice if folks want to reach out to give us some information and join us at ACE2016. Information is great! We like to hear from the customers and help them out and try to build going forward.
Martin:
Dave, thanks for taking time to share your insights and views with our readers.
About Practical PLM
Our mission is to help engineering/manufacturing companies achieve the promise of product lifecycle management (PLM). We do this by exploring practical action steps that drive business value and that yield measurable revenue contributions and/or reduced expenses.
PLM is a combination of business strategies, best practices and technology. Hence, this monthly newsletter looks at business drivers, processes, along with considerations for various technologies.
The Aras PLM platform is a cornerstone of this trifecta. Aras is the fast growing PLM vendor today. The vdR Group is a full service partner of Aras.
Copyright © 2015 The vdR Group, Inc., All rights reserved.
All trademarks belong to their respective holders. Content, responses and opinions expressed are not necessarily shared by Aras.
Written by Martin van der Roest - Martin has nearly 3 decades of experience in the systems and software development business. A majority of this time has been spent in the product lifecycle management (PLM) space with a specific focus on solutions for engineering and manufacturing organizations.