"We've just acquired package XYZ. We'd like you to now go figure out what the business requirements are so we can implement it." How many of you have had that kind of conversation? I am going to discuss the role that use cases can fill in acquiring, extending, and rolling out a COTS package. Although use cases typically only represent 20-30% of the total requirements, they do represent a system's behavioural requirements and are of significant importance.

Let's start by looking at a couple of reasons why developing use cases on a COTS project may not be a popular sell.

The COTS package may have already been selected, as per Adrian Cook's forum "Use cases on a COTS integration project". With the COTS package selection a fait accompli there isn't much incentive to go back and detail what the original business requirements should've been. However, as Adrian points out in his forum, there are still gap issues to address.

As David Wright accurately points out in his blog "Are COTS products getting easier to buy?", many COTS packages are very sophisticated in their ability to implement unique data and work flow requirements without changing the code base. This is a very powerful feature and, if used correctly, can be a great boon to the customer. (See David's blog for his success story.) With this kind of feature, that reduces or eliminates code customization, is there a need to really understand the functional requirements in more depth? The caveat is you really have to understand your business requirements and the tools that enable such a feature in order to make effective use of it.

Another consideration is that many COTS packages address a very well known and common business domain, like human resources or accounting. The attitude may be that the business should conform to the package as it implements industry best practices and legislated rules. (For an interesting discussion on this subject refer to Keith Matthew's comment "New Systems for Old" on the "What are you doing Requirements for? ...a Survey" forum by David Wright.) The premise is undoubtedly true, why would a given enterprise have particularly unique accounting or HR requirements when everybody else has to adhere to the same conventions? However, no application, at least an enterprise-class application, lives in isolation. There would undoubtedly be many integration points with external systems, organizations, etc. that need to be considered. And let's not forget that matter about changing the business to fit the package.

Now, why should you develop use cases as part of a COTS project?

Benefit 1: The process of identifying the actors (people, organizations, other systems), the use cases (what are the expected business transactions/goals the solution needs to support) and prioritizing the use cases will help an enterprise to understand every area that is impacted, the scope that the COTS solution is to address, any unique requirements based on the class of user that will be interacting with the system, and what is really important.

Benefit 2: A more detailed description of the required functionality that can be made part of a request for proposal (RFP). This allows the COTS vendor to respond with how well their product fulfills each requirement in more fine-grained detail. The responses can then be used by the RFP authors to more accurately assess each respondent's fit, and to determine what customization may be required and what that customization would cost. This information can not only help in the selection of the best COTS solution, it may also feed into a buy vs. build decision or if multiple solutions must be employed should the responses indicate there isn't a close fit.

Benefit 3: When the COTS package is brought in the use cases and areas of integration and customization that had been identified earlier can then be used to feed into a host of activities for rolling out the new package. The use cases can form the basis for project planning in order to develop needed customizations. System architects can refer to the use cases to help describe an architecture that will not be disrupted by future COTS product releases. The use cases can be used to help in the test planning, and organization and development of the test cases to ensure the quality of the implementation. The business areas affected can use this information to help them in their plans to migrate to the new environment.

As an illustration I will briefly describe a very positive experience with one of our clients, employing use cases as one of the tools that helped them in a COTS vendor selection.

Our client had decided to approach several COTS vendors to replace their core business systems. Part of the approach was to employ use cases to describe the functionality required to support their business model. To this end a series of collaborative sessions with representatives of the business areas impacted (pretty much all of them!) were held to develop a use case model describing the actors, the use cases, and the logical packages of use cases that made up each major functional area. A ranking methodology was also developed to prioritize the importance of each use case. This collaborative effort helped to achieve a common consensus that was critical to our success.

When the RFP was put together it included a turn-around document for the COTS vendors to categorize their level of support for each use case. When the RFP responses were returned they were tabulated based on the use case rankings to help determine the COTS packages that were best able to meet the required functionality.

The exercise was quite successful. It allowed the client to objectively assess all the vendor responses and pick the best suite of COTS packages that came closest to meeting their needs. Nothing is perfect, of course, but since the gaps were readily identifiable it was much easier for the client to understand where they would need to develop custom functionality.

In summary, use cases can form an effective part of a COTS implementation project: from forming a common understanding of requirements, assessing vendor responses, and through to implementation and roll-out. The use cases that are initially described to frame the solution requirement can continue to be used to help resolve the gaps of the acquired COTS package, to test the implementation, and aid in the roll-out to the business.

For more information on an overall process (RUP) for selecting and deploying a COTS package refer to:

"COTS Package Delivery using the IBM Rational Unified Process" by Kevin McGaffey and Cécile Peraire

"The IBM Rational Unified Process for COTS-based project: An Introduction" by Cécile Peraire and Russel Pannone