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.
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.