As your question implies, you're headed in the right direction! Requirements play a valuable role in evaluating, selecting and implementing packages.
Requirements for evaluating packages
Just like any purchase, the buyer should understand their needs -- before engaging with a salesperson. I suggest you and your customers put together a COTS package "shopping list." It should contain a set of balanced business needs using scope-level requirements representations. Here's a suggested list:
- Identify the user roles or personas who will directly utilize the package to achieve business goals.
- Use features, events, or business processes (or a combination) to define visible functionality. If you use events, don't forget temporally initiated events.
- Name business policies to identify the guidelines, standards and regulations that must be met. These will become specific business rules when you implement the selected package. List any critical exceptions that must be supported (exceptions are business rules!). Remember: you are buying the COTS package's business rules (or its ability to customize rules).
- Define key terms in a glossary and facts (relationships between terms which can also be represented in a conceptual data model). You'll check these against the COTS package's glossary and core data entities.
Nonfunctional requirements are an important element of the evaluation and should be included in the "shopping list." They encompass three key categories:
- Quality attributes such as performance, reliability, security, interoperability, and usability.
- Design and implementation constraints such as DBMS, operating system, browsers, middleware and any other "musts" that are often part of your organization's technical architecture.
- External interfaces specifications list all of the external applications, databases, and hardware devices that need to interface with the COTS package. Consider drawing a context diagram to visualize the interfaces between the COTS application and the external components.
Making a good choice
Validate the requirements with the business. Engage both the business experts and technical experts to prioritize the requirements. Your requirements should be the criteria for identifying candidate COTS applications. Determine who will be on the evaluation team, again a cross-section of business and technical experts, and prepare a ranking scheme for selecting the application.
Prepare for product demos by writing scenarios or stories that instantiate the scope-level events or processes. Include high priority exception scenarios to verify the package can handle your business rules. Ensure business rules are correctly executed by having customers define expected results prior to the demo. Insist that the demos run your scenarios with your test data. Since you will be integrating the package into your existing environment include experts from the interfacing systems in the evaluation.
Your final scoring begins with the evaluation ratings of the functional and nonfunctional requirements. In a perfect world, you would never customize a COTS package! But since most of us don't live in such a world, document any changes necessary to meet the business needs as well as the associated estimated costs. When faced with trade-offs, refer to the original prioritized list of requirements to aid in the decision. Adjust the scores accordingly.
Implementing a COTS application has many facets. On the technical side, the interfaces with current systems and data structures are especially important. Use your context diagram to understand, at a scope-level, those interfaces. Then be sure to analyze each system-to-system interface by detailing the transmission content, messages, communications protocols, etc. Manage these integration points closely; implementing the interfaces requires shared resources with highly coordinated schedules to reach your "go-live" date. User acceptance testing is your opportunity to circle back to the initial prioritized requirements and ensure the package meets the business needs.
Another critical success factor when implementing a COTS package is effectively rolling it out to the business community. Understanding how the software application will change the way people work is essential for defining adoption strategies and minimizing negative byproducts of the change. Business process models help target where and how the software package will change business processes and people's roles. These business models, along with the "to be" requirements you used to make a smart choice, can be a basis for developing or tailoring job aids and training.
This was first published in January 2008