How to Buy the
Right Software

Practical Help for
Companies of Every Size

Chapter 3: Capturing Requirements

Shopping for almost anything, including software, is as easy as a Google search today. With a few phrases and clicks, we can quickly see what’s available in any category from phone apps for meditation or financial planning to enterprise software for product lifecycle or quality management. Amazing and convenient, right? We also can quickly go down rabbit holes of possible solutions without the guidance of requirements. We do cover the research and evaluation stage later in this guide, but before you start Googling or checking out G2 reviews, you need to articulate and prioritize your requirements.

What Are Solution Requirements?

You may be familiar with product requirements, which range from market, customer/user, and business to functional, technical, operational, quality, and more. While you won’t be doing full requirements management activities as you do with your own products, you need to identify requirements for the solution that will meet your business needs.

Solution requirements are capabilities or conditions the software you select must have to meet the business needs and provide confidence in continued success.

Requirement Categories

You can name and sort requirements into categories. This will help you as you work through requirements prioritization or weighting discussions as well as provide some organization to your list. You may also further group requirements into areas under the main categories.

Business Needs

Explanation:
The specific information, behaviors, rules, and operations a solution should have to ensure desired outcomes and meet the business needs.

Possible Requirements Areas:
Business-need requirement areas will map to the processes that support your business needs—so this will vary.

Get a PLM/QMS requirements template in the project plan template for examples of areas for product companies shopping for PLM and QMS solutions.

Functional

Explanation:
The manner or environment in which the solution needs to operate, including additional expectations you have for the solution or qualities it should include across all business need(s).

Possible Requirements Areas:

  • Security and access
  • Administration capabilities
  • History and audit
  • Configuration and extensibility
  • Usability and acceptance
  • Data flows and integrations
  • Search, reporting, analytics
  • Availability, performance, and system requirements

Non-Functional

Explanation:
The attributes of the solution as well as the vendor’s strength (financial, historical, customer success, customer support) to support your projected growth and future needs.

Possible Requirements Areas:

  • Vendor offerings and customer base overlap with your business
  • Vendor product development philosophy, release history, and vision/roadmap
  • Vendor customer success
  • Vendor customer support and care
  • Vendor financial health
Exchange Icon

Insider Tip: Two Dangers to Doing Requirements Well

  1. Confusing preferences and requirements
  2. Finding new problems to solve

Identifying Requirements

Creating a full requirements list from scratch is work and can be challenging if you have not defined solution requirements before. Instead, upcycle! Gather a few templates for requirements in the solution space you need and use them as the basis of your own.

Where to find templates?

  • Vendors (should be free!)
  • Teams that have done this before (free!)
  • Peers at other companies with similar needs (free!)—reach out to them via LinkedIn and other networks
  • Software consulting companies (usually as part of a fee-based service)
  • Industry analysts (often fee-based)

Prioritizing Requirements

“The perfect is the enemy of the good.”
– Voltaire

There is no perfect solution. You won’t meet all stakeholder needs and you can’t make all users happy. You can find the best solution—the solution that best:

  1. Meets business needs based on prioritized requirements
  2. Will be adopted by users
  3. Fits within your overall cost structures and resource plan
  4. Will grow with you in the future

To get to the best solution, you will need to prioritize requirements. You can use a simple prioritization, such as 1=must have, 2=nice to have, and 3=do not need. As you evaluate solutions, you’ll use this prioritization value to determine weighted final scores, so use numbers.

Don’t overcomplicate the priorities. The simpler the scheme, the more valuable your conversations about what is needed, preferred, or just technology-induced dreams.

Adjusting Requirements

As you engage with vendors and see the functionality they offer, you may realize that what the vendors are providing differs in scope more than you expected. Indeed, sometimes no vendor does all you need in one package. In these cases, you want to talk with vendors (and some of their customers) about how they help with your business needs and how they don’t. With structured data and standards, many companies use data flows and integrations across systems as needed. This removes the pressure to settle for a cumbersome, expensive, or unfriendly “all-in-one” solution.

Chapter Activities Summary

✓ Find one or more solid requirements templates to jump-start your identification efforts—we provide a PLM/QMS requirements template for you in our master software search project template
✓ Get the team together (virtually or F2F) and work on completing requirements identification and prioritization
✓ Put the requirements document somewhere accessible to the team, preferably attached to the project plan (this project plan template includes the requirements template and more)

Next Chapter: Engaging and Evaluating Vendors
Download The Guide