This article discusses the role of Capability-Based High-Level Requirements (HLRs) when an organization has chosen to acquire a Commercial-Off-The-Shelf (COTS) information system. The objective of the system is to contribute to the solution to a business problem or help take advantage of a business opportunity. HLRs are key to a vendor-product-selection effort.
If the organization knows the specific COTS product they want and expect to use it Out-Of-The-Box (OOTB), then HLRs are not needed. Otherwise, one or more of the following questions may need answering:
- What COTS products exist that address the business processes and/or areas in the solution scope?
- Which available COTS products come closest to meeting the [capability-based] HLRs within the solution scope and budget?
- What would be the cost of changes and/or additions to a selected COTS product’s OOTB capabilities?
A formal approach to answering #1 is for the organization to issue a Request for Information (RFI). For #2 – a Request for Proposal (RFP). And for #3 – a Request for Quote (RFQ) or Statement of Work (SOW). This article addresses the first two questions, the second of which involves HLRs. The third question involves capability-based detailed requirements. These are discussed in the companion article “What Requirements Are Needed When Implementing a COTS Information System?”
NOTE: A COTS information system can be thought of as a PRODUCT. From an organizational perspective it will have one or more PRODUCT OWNERS. It would be possible for User Stories and/or Acceptance Criteria to be used as a requirements specification style. However, due to the size and complexity of most COTS products the effort to select and implement one is not a good fit with the Agile objectives of frequent, incremental delivery into production. Addressing the three questions posed above is likely to depend on traditional Waterfall requirements and stakeholder management methods.
What COTS Products Exist?
The objective of question #1 is to identify existing COTS products that offer an information-system-based solution to a business problem or opportunity. The expectation is that such a system will improve the operation and management of existing business processes and/or support new or improved ones.
An appropriate COTS product would be expected to support a solution scope involving:
- One or more [named] business processes – E.g. Payroll, Billing
- A whole functional area – E.g. Human Resources, Customer Relationship Management
- One or more specific lines of business – E.g. Retail Clothing, Insurance
- Multiple integrated functional areas – E.g. An ERP system offering Sales, Inventory Management, and Accounting modules
See “The Functional View from 10,000 Feet” for a discussion of a generic-organization functional model representing Management, Line of Business, and Support functional areas.
Ideally, pursuing an answer to question #1 results in identifying one or more COTS products, each of which:
- Conforms to explicitly specified information-system-related constraints
- Supports most if not all of the in-scope business processes and/or functional areas
- Is suitable for the size of the organization (e.g. small, medium, large)
- Has an OOTB cost that does not exceed the estimated solution budget
- Has existing satisfied customers
The solution scope definition used to address the question #1 is used again when establishing the functional HLRs needed to address question #2.
Which COTS Products Are Suitable?
The objective of question #2 is to produce a shortlist of potentially suitable COTS products - one or more of which turn out to be acceptable solutions. Suitability is a combination of a product’s OOTB cost, the vendor’s viability, and the product’s ability to meet a specified set of HLRs.
Domain-Specific Record Types
An information system manages domain-specific data. This data supports business processes and decision making at operational and managerial levels. Subject Matter Experts (SMEs) in each of the in-scope business processes are needed to identify the domain-specific record types that each of those processes involve.
For example, consider a COTS product intended to support a [line of business] Sales functional area. An SME in the organization’s sales process would likely identify Sale as the primary record type, plus Customer and Product as secondary record types in that process. A suitable COTS product would therefore need to support the following three record-type-specific HLR examples:
“A user can maintain Sale information including relationships to other records.”
“A user can maintain Customer information including relationships to other records.”
“A user can maintain Product information including relationships to other records.”
A COTS product meeting the above HLRs would be expected to be able to support a Sales process. But it should also be able to support other processes within the Sales functional area that involve one or more of those record types – regardless of which was primary in a given process.
NOTE: Business Analysts are often advised to avoid use of the term “Maintain” in functional requirements. Use of the more specific terms 'Create,' 'Update,' 'Reference,' and 'Delete' is commonly recommended. However, in the case of HLRs for determining suitable COTS information systems, the more general term is sufficient.
Generic Information System Capabilities
A COTS information system provides the ability to maintain domain-specific record type data through integrated software components of five generic capability types:
- User Interface – presenting record-type-specific data views supporting business processes being performed by online users
- Data Import – processing machine-readable, record-type-specific data made available to the system
- Data Export – formatting record-type-specific data suitable for importing by another information system
- Report – formatting record-type-specific data readable offline by person(s) internal or external to the organization
- Automated Function – processing available record-type-specific data to generate other data intended for use by the system’s other capabilities
Business analysts are normally expected to document requirements representing what is needed, avoiding how a solution will satisfy a given requirement. But when selecting an existing information system, how it supports maintaining its domain-specific data has already been determined.
Data for record types the organization expects users to maintain online will need a user interface HLR for each. Record types that have machine-readable sources should have a data import HLR. And so on.
NOTE: Any critical field-level-specific requirements should be specified as constraints. Otherwise that level of detail can be viewed during vendor demonstrations of short-listed products, and ultimately specified as part of detailed requirements for changes or additions to the selected product.
Capability-Based HLR Examples
User Interface HLRs
User interfaces (UIs) commonly provide most of a COTS-product’s support for business processes. One or more screens present a specific record type’s data along with data from related record types. Instance-specific actions include the ability to edit values, add or remove items in a list, create a whole new instance, or delete an existing instance.
Navigation to a record type instance might be by a user doing one of the following:
- Selecting a “Home” screen menu option
- Providing the instance’s unique ID
- Selecting from a list of instances
- Utilizing an instance-specific link provided elsewhere
The Sale, Customer, and Product HLRs presented above each mention that a user is involved and thus are examples of the UI capability type. All details related to specific user types, data fields, relationships, or process-specific actions are intentionally omitted to keep the HLR high-level. (See Shortlisted COTS Products section below regarding field-level details during the selection process.)
Data Import HLRs
A business process recognized by an SME that allows the sourcing of data for a given record type in machine readable form is represented by a Data Import capability HLR.
Two aspects of a data import are significant enough to include in the HLR:
- Whether the capability is expected to perform in real time or as a background job
- A recognizable data format or source system name specific to the capability
For example:
“The system can import Customer Purchase Order information in EDI Document 850 format in real time.”
If the data import needs to function both in real time and as a background job, there should be a separate capability HLR for each.
A Data Import capability HLR should exclude details related to specific fields, modification actions (create, update, delete), or how processing exceptions should be dealt with.
Data Export HLRs
A business process recognized by an SME that involves the delivery of data of a given record type, in machine readable form is represented by a Data Export capability HLR.
Two aspects of a data export are significant enough to include in the HLR:
- Whether the capability is expected to perform in real time or as a background job
- A recognizable data format or target system name specific to the capability
For example:
“The system can export Supplier Purchase Order monthly totals to the SAP financial system.”
If the data export needs to function both in real time and as a background job, there should be a separate capability HLR for each. The requirement should exclude details related to specific fields, create, update, delete actions, or how processing exceptions should be dealt with.
Report HLRs
The capability of an information system to create a Report combines aspects of the user interface and data export capability types. The UI aspect deals with the formatting of any [read only] information displayed for viewing by online users. The data export aspect is that the data reported is a snapshot of what was available to the system at the time it was created.
A solution-domain SME should be able to “name” commonly recognized reports. Each report the organization expects to be available as part of a COTS solution should be represented by a Report capability HLR that identifies it as being a report with a domain-meaningful name.
Two aspects of a report are significant enough to include in the HLR:
- Whether its intended audience is internal (e.g. operational staff or management) or external (e.g. Customer, Supplier, Regulatory Body)
- Whether it’s produced regularly or ad hoc
For example:
“The system can report to a Customer their Statement of Account for the previous month.”
“Statement of Account” should be a commonly recognized type of report for a Customer. “… previous month.” indicates that it is produced regularly.
“The system can report to Management Month to Date Regional Sales Totals.”
The report name implies that it could be run at any time during a given month and thus would be ad hoc.
If the report needs to be produced both regularly and ad hoc, or at different intervals (e.g. weekly, monthly, yearly), there should be a separate capability HLR for each. The requirement should exclude details such as those related to specific fields, physical or electronic formats, delivery options, etc.
Fully Automated Function HLRs
A Fully Automated Function (FAF) capability within an information system is similar to the other four capability types in that it will involve primary, and possibly secondary, record types. It’s like a data export in that it operates using information the system has access to. It’s like a data import in that the end result will be one or more records created, updated, or deleted.
An FAF capability is responsible for performing one or more activities within a business process. The activity might currently be performed manually but is to be automated as part of the solution. Alternatively, a process activity might currently be automated but is implemented in an information system that is being replaced by a COTS system. Finally, the solution may intend to introduce new or changed processes, with specific activities within those processes targeted for automation.
A solution-domain SME should be able to “name” the activity(s) intended to be fully automated within a given business process. Each activity the organization expects to be fully automated as part of a COTS solution should be represented by an FAF capability HLR.
Two aspects of FAF capabilities are significant enough to include in the HLR:
- Whether it’s initiated by another capability or expected to self-monitor its triggering conditions
- Whether or not its resulting information is needed in real time
For example:
“The system can manage the authorization of an online purchase.”
“The system can manage Card expiration.”
The FAF in the first example is triggered by another capability and the resulting information is needed in real time. In the second example, the capability would be associated with a business rule somehow monitored by the system causing the function to be performed.
The requirement should exclude details related to specific fields, create, update, delete actions, or how processing exceptions should be dealt with.
Domain-Independent Functional HLRs
The HLRs discussed above address capabilities of a COTS product to manage domain-specific information utilized by in-scope business processes. There are domain-independent capabilities that can make a system more usable, or more easily extensible over time. For example:
“The system can support multiple languages.”
“The system can incorporate user-defined workflows.”
“The system can incorporate user-defined reports.”
“The system can incorporate user-defined business rules.”
A domain-independent functional HLR identifies the capability. There is no domain-specific record type that needs to be identified. There are no details related to user types or other capability-specifics (e.g. which languages the organization expects to be supported). A COTS product vendor should be able to indicate if a given domain-independent capability is currently “Available OOTB,” “On the Product Roadmap,” or ‘Not Available.”
NOTE: Requirements such as the examples above are commonly considered to be “Non-Functional.” But each of these particular examples would be achieved through software the COTS vendor has chosen to incorporate into its COTS product. See Fundamentals of Non-Functional Requirements for a further discussion of domain-independent requirements.
Shortlisted COTS Products
Based on COTS-product-vendor responses to capability-specific HLRs plus other evaluation criteria the organization should be able to identify a shortlist of products able to provide a minimal viable product (MVP).
SMEs and Stakeholders associated with each HLR should have the opportunity to see a demonstration of each of those products and/or have access to a demo version. This allows the SMEs to:
- Confirm vendor responses to HLRs regarding their product’s OOTB capabilities
- Observe OOTB field-level details in user interfaces and reports
- Observe the ‘Look and Feel’ of the product
Ideally the selection process leads to a final decision, allowing the organization to proceed with the acquisition of a COTS product. If it is known at this point that the product is to be used completely OOTB, then implementation can proceed without the need for detailed requirements. Otherwise question #3 posed at the start of this article will need to be addressed:
What would be the cost of changes and/or additions to a selected COTS product’s OOTB capabilities?
Obtaining an answer to this question involves detailed requirements. These are discussed in the article “What Requirements Are Needed When Implementing a COTS Information System?”
Author: Dan Tasker
Dan is the author of over 30 requirements-related articles and other resources. His 45+ year career in Information Technology has involved organizations in a variety of industry sectors in the United States, Canada, Australia, and New Zealand. His business analysis experience includes projects involving in-house software development, software vendor solution development, and COTS software acquisition and implementation. He continues to be passionate about quality requirements and helping business analysts produce them. He can be contacted at [email protected].