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.
|A Word About "As Is" and "To Be" Business Models
When you're modeling both the "as is" and the "to be" views of your company, be clear on your intention. Your COTS shopping list should be based on the "to be" requirements. In contrast, your "as is" business models will help you when you implement your selected COTS application by identifying how users need to adapt to the new software.
Are you shopping to buy a commodity product (human resources, accounts payable), or are you looking to automate a specialized process? In either case, business modeling is essential. Building some lightweight, "as is" models will help you understand the context in which the COTS software will be used and also will help you identify processes that you might otherwise overlook because they "work" today. If you're looking for a specialized system, you need to build your "to be" business models before you begin shopping.
Business models provide context. With that context, you can start devising your shopping list.
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:
- 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.