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.