Requirements for Implementing Packaged Solutions

Many organizations acquire and adapt purchased packaged solutions (also called commercial off-the-shelf, or COTS, products) to meet their software needs, instead of building new systems from scratch. Software as a service (SaaS), or cloud, solutions are becoming increasingly available to meet software needs as well. Whether you’re using a package as part or all of the solution for a new project or implementing a solution in the cloud, you still need requirements. Requirements let you evaluate solution candidates so that you can select the most appropriate package, and then they let you adapt the package to meet your needs. This article describes several ways to approach requirements definition when you plan to acquire a commercial package to meet your needs.

Figure 1 shows that the spectrum of effort required to make a packaged solution useful ranges from using the package as is, right out of the box, to performing considerable requirements specification and software development for extensions. Table 1 describes these four types of COTS package implementations, which are not mutually exclusive. Any of these implementations might also require making infrastructure changes in the operating environment, such as upgrading operating systems or other software components that interact with the package.

Figure 1. A spectrum of implementation effort for packaged solutions.

Table 1. COTS package implementation approaches.

One advantage of purchasing a COTS solution is that it might provide useful capabilities that you hadn’t originally sought. You typically select the package based on what you know you need. However, during implementation, you might discover valuable features that you hadn’t even thought of. This can change the amount of work needed to install the package to exploit the additional features.

Configuration Requirements

Sometimes you can use a package just as it comes from the vendor. More often, you’ll need to adjust various configuration parameters in the package to better meet your needs. Configuration requirements are essential to most successful COTS implementations. One approach is to define configuration requirements for one process flow, use case, or user story at a time, which could work well when deploying a COTS solution using an agile approach. Walk through user manuals for the purchased system to learn how to execute a specific task, looking for settings that need to be configured to suit your environment.

Consider the full set of business rules when you are configuring the system, not just those you examined during the selection process. It might be helpful to create decision tables and decision trees to model these requirements. Many COTS solutions come with predefined mechanisms to specify roles and permissions. Use a roles and permissions matrix to define which roles to create and what permissions those roles should have.

Integration Requirements

Unless the packaged solution is used in a standalone mode, you’ll need to integrate it into your application environment. This integration involves understanding the external interfaces the package will present to each of the other applications with which it must interact. Precisely specify the requirements for interchanging data and services between the package and other components in your environment. You will likely have to create some custom code to make all the parts fit together, and new code demands requirements. This code could take the form of:

• Adapters that modify interfaces or add missing functionality.

• Firewalls that isolate the COTS software from other parts of the enterprise.

• Wrappers that intercept inputs to and outputs from the package and modify the data as necessary to be used on the other side of the interface.

Extension Requirements

One common goal of COTS implementations is to minimize customizations to the solution. Otherwise, you should just custom-build the application yourself. In most COTS projects, though, there will be gaps between what the organization needs and what the package delivers. For each such gap, decide whether to ignore it (remove the requirement and just live with the tool); change how you do something outside the solution (modify the business process); or build something to bridge the gap (extend the solution).

If you are extending the COTS solution, you’ll need to fully specify the requirements for those new capabilities just as you would for any new product development effort. While analyzing the requirements for any components to be added, assess whether they could negatively affect any existing elements or workflows in the package.

Data Requirements

Begin with the data requirements used in the selection process. Map data entities and attributes from your existing data dictionary to the COTS entities and attributes. There will likely be areas where the solution doesn’t handle some of your existing data entities or attributes. As with functional gaps, you’ll need to decide how to handle data gaps, typically by adding attributes or repurposing an existing data structure in the COTS solution. Otherwise, when you convert data from any existing systems into the COTS solution, you will likely lose any data that was not properly mapped. Use report tables to specify requirements for deploying existing or new reports (see Chapter 13 of Software Requirements, 3rd Edition). Many COTS packages will provide some standard report templates to start with.

Business Process Changes

COTS packages are usually selected because implementing and maintaining them is expected to be less expensive than building custom software. Organizations need to be prepared to adapt their business processes to the package’s workflow capabilities and limitations. This is different from most development projects where the software is designed specifically to accommodate existing or planned processes. In fact, a COTS solution that can be fully configured to meet your existing processes is likely to be expensive and complex. The more buttons and knobs you can adjust, the harder it is to configure. You need to strike a balance between implementing all of the desired user functionality and only what the COTS product offers out of the box.

Start with the user requirements identified during the selection process. Develop use cases or swimlane diagrams to understand how the tasks will change when users execute their tasks in the COTS solution. Users might resist the new packaged solution because it looks or behaves differently than their existing systems, so involve them early in this process. Users are more willing to accept the new solution if they contributed to shaping the necessary changes in their business processes.

Buy or Build: An Eternal Question

Buying, configuring, and extending a commercial software package often is a sensible business alternative to building a custom solution. Packages can provide a lot of flexibility, but at the same time they come with built-in limitations and constraints. You don’t want to pay for a lot of features that your organization doesn’t need. Nor do you want to build a fragile structure of extensions and integrations that might break when the vendor releases the next version of the package. A careful package selection and implementation process will help you find the optimum balance of capability, usability, extensibility, and maintainability in a commercial packaged software solution.

Authors: Karl Wiegers is Principal Consultant at Process Impact, www.processimpact.com. Joy Beatty is a Vice President at Seilevel, www.seilevel.com. Karl and Joy are co-authors of the award-winning book Software Requirements, 3rd Edition, from which this article is adapted. Karl's most recent book is Software Development Pearls: Lessons from Fifty Years of Software Experience.