Make Sure You Buy the Right Packaged-Software Solution

Karl Wiegers
Apr 16, 2020 · 5 min read

The demo looked great. The slick brochure promises every imaginable feature, and the sales rep assures you that his package will do just what your users want. But that’s what all the other vendors’ sales reps said, too.

Which package should you select? How can you be sure the one you choose will really meet your users’ requirements? What if it only meets some of their needs? Even if you’re adopting a commercial off-the-shelf (COTS) packaged-software solution for a new project, you still need to capture requirements in some form.

As Figure 1 shows, COTS packages typically need to be configured, integrated, and extended to work in the target environment. Some COTS products can be deployed out of the box with no additional work needed to make them usable. Most, though, require some customization. This could take the form of configuring the default product, creating integrations to other systems, and/or developing extensions to provide additional functionality that isn’t included in the package.

Figure 1. COTS packages can be configured, integrated into the existing application environment, and/or extended with new functionality.

These activities all demand requirements, but the approach you’ll take to defining requirements for selecting and implementing package solutions is a bit different from defining the requirements for a custom-built solution. Here are some recommendations for how to approach requirements exploration for package-solution implementations.

Develop Use Cases

There’s little point in detailing the functional requirements or designing a user interface if you know you’re going to acquire a commercial package and extend or customize it to meet your needs. Instead, begin requirements elicitation for such a project by understanding the business tasks the intended users must perform using the new system. Use cases are an excellent tool for this purpose.

The use-case approach focuses on user goals and tasks, rather than on system functions. Any package you select must let your users accomplish their task objectives, although each might do so in a different way. Identify your various user classes and gather use cases from each.

Because any package solution probably won’t accommodate every use case you identify, prioritize your use-case collection. Distinguish tasks that are critical and must be supported on day one from those that could wait to be supported in a future release or those that your users could live without, perhaps forever.

To determine whether — and how well — the package will let the users perform those tasks, I like to derive test cases from the high-priority use cases for both success and failure scenarios. High-level, conceptual test cases describe conditions and interaction sequences between the user and the system which should lead to specific outcomes, without regard to the specific details of user interface implementation. These test cases let you perform a systematic and competitive analysis of several candidate packages.

Be sure to include test cases that explore how the COTS package handles exception conditions that might arise. This will help you judge how well the package will hold up under unanticipated conditions, such as handling missing or invalid input data and recovering from user, system, and network errors.

Consider Your Business Rules

Your requirements exploration should also identify pertinent business rules to which the system must conform. Business rules exist outside the context of a software application, but often they lead to specific functional requirements that implement or enforce them. Can you configure the package to comply with your corporate policies, industry standards, or government regulations? How easily can you modify the package when these rules change?

Depending on your application domain, some packages will embed global business rules, such as income tax information or standards for regulated industries. Do you trust that these are implemented correctly? Will the package vendor provide you with new versions as those rules change? Will the vendor provide you a list of the business rules they implement? If the package implements any intrinsic business rules that don’t apply to you, can you disable or modify them? Record pertinent business rules and manage them as a corporate asset.

You might also define the data structures required to satisfy your use cases and business rules, and see if you can compare them to the vendor’s data model for the package to look for any major disconnects.

Explore Users’ Quality Expectations

Business analysts sometimes forget to explore the users’ performance goals and quality expectations. This can lead to a system that fully satisfies its functional requirements, but the users might hate it. Maybe the system is too slow, or it takes too many steps to perform some task, or the task flow doesn’t align well with the user’s natural work flow, or it crashes frequently.

To avoid these traps with your package solution, discuss quality attributes with your users and specify these often unstated goals as precisely as you can. Help your users devise acceptance criteria so you can judge how well each candidate package achieves your quality goals. Explore at least the following quality attributes:

  • Performance: What maximum response times are acceptable for specific interactions?
  • Usability: Does the package conform to any established user interface conventions? Is the interface similar to that used in other applications with which the users are familiar? How easily can your customers learn to use the package?
  • Flexibility: How much work will it take for your developers to modify the package to meet your specific needs? How easily can they extend it? Does the package provide appropriate hooks and APIs for adding extensions?
  • Interoperability: How easy is it for you to integrate the package with other components or applications? Does it use standard data interchange formats?
  • Integrity: Does the package permit control over which users are allowed to access the system or specific functions within the system? Does it contain safeguards to protect data from loss or unauthorized access and to resist virus attacks?

Buying a commercial packaged solution brings a level of uncertainty different from that which you experience on custom development projects. By thoughtfully applying these requirements development practices, you can select a package with confidence that it will let you satisfy your users’ real needs.


This article is adapted from Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty. If you’re interested in software requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources. Karl’s latest book is The Thoughtless Design of Everyday Things.

The Startup

Get smarter at building your thing. Join The Startup’s +793K followers.

By The Startup

Get smarter at building your thing. Subscribe to receive The Startup's top 10 most read stories — delivered straight into your inbox, once a week. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Karl Wiegers

Written by

Author of 12 books on software, design, management, consulting, and a mystery novel. Guitars, wine, and military history fill the voids.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +793K followers.

Karl Wiegers

Written by

Author of 12 books on software, design, management, consulting, and a mystery novel. Guitars, wine, and military history fill the voids.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +793K followers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store