Where is Arena Going with Requirements Management?

Would you tell me please, which way I ought to go from here?
That depends a good deal on where you want to get to, said the cat.
I don’t much care where—, said Alice.
Then it doesn’t matter which way you go, said the cat.

Since its publication in 1865, Lewis Carroll’s novel Alice’s Adventures in Wonderland has delighted generations of readers. But does this nonsensical story of a young girl chasing a white rabbit down a hole speak to today’s product companies?

Let’s start with the impish rhetoric of the Cheshire Cat: “That depends a good deal on where you want to get to.” Today’s product companies don’t have time to fall down a rabbit hole or linger at a tea party. And requirements management is just the thing to ensure you not only know where you want to get to, but also which way you go to get there. Arena recently introduced Arena Requirements Management as part of its Summer 2018 software release. I interviewed Paul Welch, Product Management Director, to understand why Arena made this move.

Amanda: How is requirements management done today?

Paul: In talking with many different product companies, the anecdotal evidence I collected certainly confirms the industry research statistic that 95% of companies use word processing software to create and manage their product requirements documents. Most commonly, they use Microsoft Word. Sometimes these files are very large. For example, one company I spoke to said they regularly managed thousands of requirements in one document. Often, companies will use a suite of tools—including document sharing tools like Dropbox and Box—to manage the product requirements documents they’ve created. Other companies use a patchwork of tools—Microsoft Word, Microsoft Excel, JIRA, and Confluence—to stitch together their requirements management process. Some companies even rely on email threads. Finally, there are companies who actually use requirements management software tools, but I’d say these companies are in the minority.

Amanda: What are some of the shortcomings of these approaches?

Paul: The former approaches are incredibly labor and time intensive, regularly pulling team members into design review meetings where documents are manually updated. Often there’s no standardization or formalization, which results in reinventing the wheel. For example, many companies don’t have templates for their requirements documents so they rely on tribal knowledge or checklists each time they create a new product. As the company or product portfolio grows, manual updates become unwieldy. This approach can also reinforce silos as teams start to use different approaches and tools. Additionally, relying on a patchwork of tools increases the risk of errors and possible data loss. I spoke to one company that admitted their product requirements documents live on a team member’s laptop.

Amanda: Why did Arena expand into requirements management?

Paul: Historically, product lifecycle management (PLM) solutions were perceived to manage processes that take place after a product was conceived of, designed, and developed. PLM has generally captured output. Arena saw an opportunity to help customers earlier in the new product development (NPD) process by providing a requirements management solution that enabled them to enter requirements information into the same system linked to the product record—to make it seamless. Teams currently using a solution like Microsoft Word tend to go through the requirements definition process, reach consensus, and then never look at the documents again. The documents are stored in a separate repository and get left behind. In hardware development, cycle times can be long, and by the time teams have reached the design implementation phase, several months may have passed. People forget what they agreed to. Creating, managing, and tracking requirements in Arena and connecting those requirements to the product record as product companies go through design and development keeps requirements at the forefront.

Amanda: Which new features are you really excited about?

Paul: I’m really excited about two key features: the document-reading experience, which required us to develop a brand-new user interface (UI), and traceability, which was a priority for us and for our regulated customers.

The document-reading experience enables users to structure product requirements documents hierarchically and to be able to read requirements in context. This design mirrors the existing user experience and workflow for teams currently managing requirements in word processing software programs like Microsoft Word.

Traceability is another key feature I’m really excited about. Traceability allows customers to link requirements together. High level marketing requirements are distilled into more granular requirements and, what’s important for regulated companies, is that they maintain these linkages. They need to prove that every single requirement is driven by user need and that every feature is tested.

Amanda: How do companies know when they should implement requirements management software?

Paul: I think it really depends on the vertical. Let’s talk about medical device and high-tech electronics companies.

I would recommend medical devices companies consider implementing an enterprise requirements management software solution to enable a more collaborative NPD process ASAP. They benefit from moving away from traditional word processing solutions to database-driven requirements management tools immediately because they can establish traceability sooner with less risk of error. Medical device companies must maintain traceability for design inputs and design outputs. Connecting requirements to the product record also helps with design control, which the FDA mandates.

For high-tech electronics companies, implementing requirements management software provides a centralized solution that enables teams to collaborate and understand requirements–especially when it’s connected to the rest of the product record and NPI process. While it may not be a priority at first, high-tech electronics companies will benefit from using some kind of requirements management tool as they build their product portfolio. Additionally, if a company has a product that is big or complex, it’s important to have better control over requirements sooner rather than later.

Amanda: What are some tips for getting started?

Paul: Before implementing any requirements management software solutions, I would strongly recommend establishing and articulating how your requirements management strategy fits into your new product introduction (NPI) process. No matter how good a software solution is, it can’t automatically create a process or fix a broken one. If a company has a well-defined NPI process and is ready to implement requirements management software, they should stop relying on disconnected word processing solutions. Instead, they can begin by assessing their product needs using a requirements management software solution.

Ultimately, finding the right balance between features and ease of use is key. Many legacy tools originated from the defense and aerospace industries, so they can be overly complex and difficult to use. It’s important to remember product requirements evolve throughout the NPD process and teams need to test, learn, and adjust constantly. And, the value of having a historical audit trail of requirements connected to your product development process becomes more crucial as your portfolio grows. Arena’s requirements management software solution has the right balance and is definitely designed to address today’s complex product companies’ needs.

Thanks Paul!