Requirements for Off-the-Shelf (COTS) Solutions

Key ideas#

What is different about this kind of project#

• The vendor has already designed the functions and screens, so detailed functional requirements are pointless. Wiegers and Beatty recommend working at the level of use cases or user stories and checking which package covers them.
• You adapt your business processes to the package. In custom development the software fits the process; here it is largely the reverse.
• There are four types of implementation, in growing order of effort: use as is; configure (settings, no code); integrate with existing systems (usually some custom code); extend (build missing functions). Even “as is” may require changes to the environment, such as operating system updates.

Scale the effort to the stakes#

Choosing personal accounting software needs a list of key use cases. A multimillion-dollar enterprise purchase needs full use cases plus data and quality requirements. The authors describe a choice among only three candidates for a semiconductor plant that took six months: effort follows cost and risk, not the number of candidates.

What to specify#

• User requirements: use cases or stories for the tasks that matter.
• Business rules: can the package be configured to your policies? Who updates global rules, such as tax calculations, when they change, and does it cost extra?
• Quality requirements: performance (response time, concurrent transactions), usability (familiar conventions, vendor training), flexibility (interfaces for extension, and whether your customizations survive upgrades), interoperability, integrity and security. For SaaS, look closely at the service level agreement (SLA).

Scoring candidates#

The authors present a four-step method from Lawlis and colleagues: 1. Weight each requirement’s importance from 1 to 10. 2. Score how well each package meets each requirement: 1 fully, 0.5 partly, 0 not at all. Use documentation, responses to your request for proposal (RFP) and hands-on checks. Always verify high-priority requirements yourself; RFP answers may not match reality. 3. Sum the weighted scores per package. 4. Separately assess cost, vendor reputation, support, external interfaces and fit with technical constraints. Compare cost after functional fit, not mixed into it.

Add tests based on your high-priority use cases, including error conditions, and run them on each candidate (an “operational profile”, after Musa). Have at least one person attend every evaluation so scores are interpreted the same way.

With many candidates, evaluate in rounds. In a case the authors describe, 60 vendors and 200 features were cut to 16 candidates using the 30 most important, distinguishing criteria; then to five finalists using all 200; each finalist was then trialed on a real project. Hands-on use with real data exposed gaps between claimed and actual behavior.

Requirements for implementation#

• Configuration: one process flow or use case at a time, guided by the package’s user manual; set up access with a roles and permissions matrix.
• Integration: adapters (change interfaces or add functions), firewalls (isolate the package from the rest of your systems) and wrappers (intercept and modify inputs and outputs).
• Extension: for each gap, decide whether to drop the requirement, change the process to fit the package, or build a bridge.
• Data: map entities and attributes; agree what unmatched data will be lost in migration.

Common difficulties#

• Too many candidates → shortlist on the most important criteria.
• Too many criteria → filter with business objectives.
• Sales misrepresentation → talk to the vendor’s technical staff, not only sales.
• Inflated expectations after a slick demo → ask for a demo of your use cases.
• User rejection → involve users in selection and early rollout.