The demo looked great. The slick brochure promises every feature you can imagine, and the sales rep assures you that his package will do just what your users want. But that's what the other vendor's sales rep said, too.
Which package should you select? How can you be sure the one you choose will really meet your users' requirements? Even if you're adopting a commercial "off-the-shelf" packaged-software solution for a new project, you still need to capture requirements in some form.
Create Use Cases
There's little point in developing detailed 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 will 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 of installation from those that could wait to be supported in a future release or those that your users could live without.
To determine whether, and how well, the package will let the users perform those tasks, derive test cases from the high-priority use cases. 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. Include test cases that explore how the system 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 mistakes.
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? 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.
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.
Explore Users' Quality Goals
Requirements analysts often neglect to explore the users' performance goals and quality expectations. As a result, your system might fully satisfy the specified functional requirements, but the users will hate it because it's 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 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 package solution brings a level of uncertainty different from that which you experience on custom development projects. By thoughtfully applying the requirements development practices described here, you can select a package with confidence that it will satisfy the real needs of your users.
