Savvy Shopping for COTS Software

Remember the last time you went grocery shopping without a list and you had your toddler, your mother, or spousal unit with you? Or when you stopped by the beer store and found yourself standing in the chip aisle, dazed and confused by the choices? Did you get what you needed? Did you spend as much money as you expected to? 

Often, we aren't clear on our requirements when we're shopping for groceries, clothes, a house, or even software. And when we aren't clear, we're likely to run afoul of the law of unintended consequences--buying too little or too much, buying something that doesn't work with the stuff we already have, or spending more than we meant to. Shopping for commercial off-the-shelf (COTS) software can be like that. Faced with a multitude of software products, what's a time-pressured, distracted shopper to do? You don't have to have all the answers, but the key is to know the right questions.

Set the Context for Shopping
The first step is to identify the need, pain, or opportunity that motivates your COTS shopping expedition. Before you decide which software to buy, you need to understand the business goals and objectives. Then elicit and analyze the current state of your organization. You can gather and sift this information by using a variety of business models. This sharpens your focus by scoping the effort.

To help you dive into appropriate business models, here are specific questions you should ask. 

• What? Uncover key functions in the organization by asking what organizational functions might you want to automate? When you've identified these functions, draw them on a relationship map, with directed lines representing the flow of information and products among the functions.
• Who comes in contact with the functions? Add the external customers and providers to the relationship map along with flows.
• What features will be included? "What are the definitions of terms?" It is not too early to capture the organization's vernacular (e.g., do you refer to your targets as customers, clients, or members?) in a glossary. Depict key terms in a conceptual data model to show their relationships at a high level.
• How? The reason for asking this question is to understand the major business processes in scope. A process map (also called a swimlane diagram) shows the sequence of processes across the various functions. This model can include the flows to and from external customers, providers, and systems that were first identified on the relationship map.
• When? The purpose of this question is to elicit events that trigger business processes shown in process maps--that is, when something happens in your organization. One answer to the "when" question might be to define the state of a key term. For example, an invoice's states might be "pending shipment," "delivered," "paid," and "canceled." States serve to verify the processes on your process map and can reveal missing processes. Also, don't forget about temporally initiated events (such as issuing paychecks on the same day each month). 

Questions to Define Your Requirements
User requirements models provide details for the shopping list and are essential for analyzing the gap between your needs and the solutions provided by the COTS software.

To identify actors (direct and indirect users, including people, other systems, and hardware devices) ask, "Who will interface with the COTS package?" Actors are a type of stakeholder and are shown on the borders of your relationship map and in the lanes on your process map.

Note: actors are only one category of stakeholders. Advisers are stakeholders who may never use the system, but they have subject matter expertise and are often knowledgeable about regulations and business rules. Providers, another type of stakeholder, are critical for COTS software selection and integration. Advisers and providers should be involved in your shopping expedition.

To clarify the system's environment, ask, "What?" and draw a context diagram to show the actors' interactions with the COTS solution. Use the conceptual data model you drafted during business modeling as the basis for capturing additional details, such as essential data attributes. The data model represents the data requirements that the COTS software must support. Note that any new terms on the context diagram should be added to the glossary.

To elicit events and states of significant data entities ask, "When?" You need to know which specific events the COTS product must respond to, including responses that involve interfacing systems. Defining the states of your data entities will uncover data you may have missed, as well as potential business rules.

To understand the business policies and business rules that must be enforced in the product you select, ask, "Why?" to learn the business motivations for enforcing specific standards, policies, regulations or legislation. The answers will help target necessary policies and business rules, and may include accessing rules residing in another system. This in turn might reveal additional system interfaces.

To elaborate details on your process maps, ask, "How?" Include manual and automated steps needed in the end-to-end process. Add lanes to represent the actors, providing a comprehensive picture of the process flow. You can also model the answer to the "How?" question by using stories or scenarios that describe specific instances through the process flows. When you include high-priority exception stories or scenarios, you'll learn more about business rules that need to be enforced.

Two Kinds of Requirements
Let's summarize the user requirements portion of your shopping list:

• Stakeholders
• Actors
• Glossary
• Context diagram
• Data model
• Business rules
• Process flows, with triggering events
• Scenarios or stories

But there's more. Don 't forge t your nonfunctional requirements:

• Quality attributes such as performance, reliability, security, interoperability, and usability.
• Design and implementation constraints such as your database management system (DBMS), browsers, operating system, and more--any technologies that make up your technical architecture.
• External interface specifications that define the interfaces (human-computer, report, system-to-system, hardware-to-system) visible on your context diagram. The COTS system must be able to interoperate with these systems.

You will need to prioritize your requirements, something that is best done collaboratively by your business and technical experts. With this comprehensive and prioritized shopping list in hand, you're ready to embark on your COTS solution shopping expedition.

Don't Pitch the List!
The models you've created serve multiple purposes, so don't throw them away! These requirements will not only help you identify candidate packages but also will become the basis for evaluating the candidates. To test how well candidate COTS products will deliver your high-priority features, data, and rules, have vendors execute your scenarios in demos. Remember to grade the candidates on both user and nonfunctional requirements.

Also use your shopping list of requirements when implementing the selected COTS package. Use it to structure your project plan, placing early emphasis on interfaces with other systems. Your requirements models, especially the scenarios and business rules, should be the basis for preparing test cases. Study your "as is" and "to be" process flows to identify where and how users' work will change. This analysis will help you make plans for easing the inevitable challenges that users face when first utilizing new software.

Save yourself aggravation and thrashing by being a savvy COTS shopper. Set the context for your shopping expedition, and use business and user requirements to find products, select the best fit, and implement your COTS solution.

Further Reading

• Gorman, Mary. "Events to the Rescue," StickyMinds Original, October, 2006.
• Gorman, Mary. "Ready, Fire, Aim: How Timely Interface Analysis Reduces Risk in Software Projects," StickyMinds Original, November, 2007.
• Gottesdiener, Ellen. The Software Requirements Memory Jogger. Goal/QPC, 2005.