This article discusses capability-based detailed requirements (DTRs) for a selected Commercial-Off-the-Shelf (COTS) information system. A complete set of DTRs identifies which “Out-of-the-Box” (OOTB) capabilities are to be implemented as is, which need changing, which aren’t needed, and which unsupported capabilities need to be added. A spreadsheet-based template is offered for documenting and managing these requirements.
COTS Product DTRs
A business analyst is normally expected to document requirements by describing what is needed, avoiding how a solution might satisfy them. But a selected COTS product is an existing solution. A domain-specific information system solution includes user interface (UI), data import, export, report, or automated function capabilities. Additionally, a COTS product’s selection may have been influenced in part by its inclusion of domain-independent capabilities such as configurable workflows or business rules.
A COTS DTR should document the results of the organization’s subject matter experts (SMEs) reviewing in detail an existing or additional product capability. It should identify how (or if) the capability should be implemented for that organization.
NOTE: The article “What Requirements Are Needed When Selecting a COTS Information System?” discusses capability-specific high-level requirements (HLRs). Those requirements are intended to be of the “What, not How” variety.
Detailed Requirements Effort Inputs
Ideally a BA tasked with eliciting and documenting DTRs for a selected COTS product would have access to the following resources:
- Domain Subject Matter Experts
- List of OOTB Capabilities
Domain Subject Matter Experts (SMEs)
The COTS information system is intended to be part of the solution to a business problem or opportunity. SMEs in the business processes and/or related operational or managerial decisions related to the solution need to be available. Their role is to confirm the OOTB details of the domain-specific capabilities the system provides. If changes or additional capabilities are needed, they supply those details.
NOTE: Lack of availability of SMEs leaves the organization reliant on the vendor domain-specific-expertise embodied in the relevant OOTB capabilities.
List of OOTB Capabilities
A COTS information system supports domain-specific business processes and operational and managerial decisions by means of user interface, data import, export, report, and automated function capabilities. The DTR effort should establish a DTR for each capability of each of these types the vendor provides OOTB.
Some DTRs will support the HLRs used during the product selection process. Some capabilities not originally required may be useful. Some may be unwanted either because they are not applicable to the organization or are out of scope (e.g. another system within the organization satisfactorily provides the capability).
NOTE: Ideally the COTS product supports implementing, but restricting access to, unwanted OOTB capabilities (e.g. by eliminating them from menus or select lists).
COTS Selection HLRs
A COTS product selection process typically involves producing a set of signed-off functional requirements. Ideally these are high-level and capability-based (see COTS Product Selection article). Vendors are expected to respond to each requirement indicating if their product satisfies it “OOTB”, “With Configuration” and/or “With Custom Development”, or “Can’t be Satisfied”.
As part of the DTR effort signed-off HLRs should be mapped to their corresponding OOTB capability DTR.
A COTS selection HLR with no corresponding OOTB capability should have a DTR established to represent a capability to be detailed for potential adding. These added DTRs represent organization-specific capabilities that would need to be added through configuration and/or custom development. Depending on the assigned priority of the DTR, and the eventual quoted cost of it being added, it may or may not remain in scope for implementation.
NOTE: Where the selection process documented capability-specific HLRs the DTR mapping exercise should be greatly simplified. Each HLR should map to a single capability DTR (OOTB or to be added).
Product Data Dictionary
A major benefit of having an information system to support business processes and decisions is that the data it maintains can be captured once (UI, imported, or auto-generated from other data), and referenced multiple times (UI, exported, reported, or used to auto-generate other data).
A selected COTS product is expected to be capable of maintaining domain-specific data. That data will have domain-meaningful record, field and relationship names (e.g. “Customer”, “Account”, “Sale”). As the DTR effort reviews OOTB capabilities, ideally there would be a product-specific data dictionary identifying each record type, the fields it contains, and relationships to other record types supported. Some indication to field size, relationship cardinality, and properties such as ‘mandatory’, ‘quantity precision’, etc. should be specified (see Managing Data-Specific Business Needs Using a Data Dictionary).
COTS Product SME
Having a product-specific SME as a resource during the DTR effort is as essential as having organizational domain-specific SMEs. When considering capability changes or additions this person should be able to advise how best this can be accomplished in the system. For more popular COTS products this resource could be from a 3rd party service provider that offers expertise in the product.
Some vendors will want this resource to facilitate DTR workshops with the organization’s SMEs. For a product that offers easy configuration options, it may be possible for some changes to be implemented as the workshops progress.
NOTE: Any changes implemented during the DTR effort should still be documented as part of a capability-specific DTR to ensure that they are properly managed (e.g. agreed, approved, tested, users trained).
Product Demo Version
A demo version of the selected product offers two important benefits. It allows the organization’s SMEs to spend time examining OOTB field and relationship-level details for each domain-specific UI capability. It also allows the BA documenting UI changes to capture screen shots - useful when specifying specific changes in a capability-specific DTR (see COTS Change Details section below).
COTS DTR Properties
Two objectives of DTRs for a selected domain-specific COTS product are answers to the questions:
“Which OOTB product capabilities should be implemented?”
“Which organization-specific changes and additions should be implemented given available budget and/or time constraints?”
The following DTR properties are intended support answering these questions:
DTR ID – Unique within the context of the information system being implemented.
Capability Label – For a DTR representing an OOTB capability this is how the product vendor refers to the capability in the list of capabilities supplied as an input to the DTR effort. That label may or may not include the capability’s type (e.g. “Sales Transactions UI” to distinguish it from a “Sales Transactions Import”. The label for a DTR representing an additional (organization-specific) capability should follow whatever format the vendor uses.
Capability Type – Whether or not the capability type is included in the DTR’s capability label, it should be identified separately to support DTR sorting or filtering. Values for an information system include UI, Data Import, Data Export, Report, Automated Function, “Other” (e.g. workflow, business rules).
Priority – Initially the same as the DTR’s matching HLR. The priority can change during the DTR effort based on SME input or quoted costs. Example priorities from highest to lowest:
- The implemented system must have this capability as part of solving the business problem or taking advantage of the business opportunity (e.g. “MVP”, “Must Have”)
- The full benefit of solving the business problem or taking advantage of the business opportunity will not be reached if this capability is not implemented. (e.g. “Should Have”).
- There is some, but not much, benefit from this capability being implemented (e.g. “Could Have”, “Nice to Have”).
- There is no benefit, or potentially negative benefit having this capability implemented in this system (e.g. “Won’t Have”, “Out of Scope”). This may be because this organization’s processes and/or decisions do not require it. Or it may be because the capability is satisfactorily supported by another of the organization’s information systems. This priority can apply to a DTR based on an originally signed-off HLR and/or OOTB capability.
OOTB – “Yes” indicates that the capability can be implemented OOTB. “No” indicates that the DTR includes details describing changes to an existing capability or for a capability to be added. (See COTS Add Details section below.)
Configuration Quote – A cost or amount of time determined by the vendor or 3rd party service provider to configure organization-specific details specified for the capability. In situations where budget is an issue the organization may choose to perform the configuration using internal [trained] resources, use the capability OOTB, or change the DTR’s priority removing the capability from scope.
Custom Development Quote – A cost or amount of time determined by the vendor or 3rd party service provider to custom develop organization-specific details specified for the capability. In situations where budget is an issue the organization may choose to simplify the specified details to obtain a reduced quote or change the DTR’s priority removing the capability from scope.
NOTE: where a COTS information system involves system interfaces (import or export capabilities), there can also be costs involved where another system requires changes or additions to be able to accommodate the interface.
HLR(s) – Supports traceability between the COTS product selection HLRs and product-specific DTRs. This allows stakeholders in the original HLRs to see the level of support the selected product indicated it offers for each required capability.
Supporting DTR(s) – Supports traceability between an existing or added capability and one or more “supporting” capabilities – either OOTB or to be added.
For example, a report capability intended to be emailed. The email is an additional “report” capability that should be represented by its own DTR – associated with the original report capability DTR it supports.
Other Requirement Management Properties – (See COTS Product Detailed Requirements spreadsheet template for further properties applicable to managing any high-level or detailed requirement.)
NOTE: Given the properties listed above applicable to a COTS capability, there should be no need for a “written” DTR statement (e.g. a formal “Shall” statement or User Story). The “labeled” DTR represents each capability to be implemented (or not). See Transitional Data Details section below regarding capability-related user roles.
COTS Change Details
When one or more of the organization’s SMEs identifies a COTS domain-specific capability that should not be implemented OOTB only the specific changes need to be documented. Because this article is restricted in scope to information system-based solutions, the following types of changes are the most common:
- Field(s) the organization utilizes in one or more processes need to be added
- Relationship(s) between record types need to be added
- One or more properties of a given field or relationship need changing (e.g. cardinality, size, precision, mandatory/not mandatory)
- Field(s) the organization does not utilize need to be hidden
- Existing relationship(s) between record types need to be hidden
- Fields offering a fixed set of values to choose from need changes to that value set
When a field or relationship that involves a change is maintained by the underlying information system its impact on other capabilities will need to be determined – along with whether implementing the changes can be done by configuration and/or custom development.
NOTE: Ideally a product data dictionary would be available during the DTR effort that provides the OOTB definition of each record type, its included fields and relationships to other record types (and the OOTB properties of each). See Data Dictionary Article.
A COTS product can come with record-type-specific business rules and/or workflows OOTB. If so then each of those needs to be reviewed by SMEs. The details of any changes needed should be documented as record-type-specific DTRs (e.g. “Sale Workflow”, “Account Eligibility Business Rules”).
COTS Add Details
When one or more of the organization’s SMEs identifies a capability that needs to be added, its details need to be fully specified. This specification should reference any OOTB record types, fields and relationships involved. The look and feel of how OOTB capabilities of the same type have been implemented can be referenced to avoid having to specify those details.
The need to add a domain-specific record type, its fields and relationships should similarly follow the form of the product data dictionary (or whatever COTS-product-specific data specification format is advised). The added data elements will likely be involved in more than one added capability (e.g. a maintenance UI plus one or more reports).
Transitional Data Details
The DTRs discussed above address implementing the functionality of the COTS product’s capabilities. Because we are dealing with an information system, there is likely to be specific data implemented before the system is usable (or even testable). The details of what’s needed could be considered detailed requirements, but the preferred term is Transitional Requirements (TRs).
A TR can address:
- Domain-specific reference data (e.g. Industry-standard Codes, Geographic Areas)
- Organization-specific Record Types (e.g. Sites, Business Units)
- Security-related details (e.g. User Roles, Capability-specific Access rights)
- Organization-Specific Product / Service Details
- Non-OOTB Workflow Definitions
- Non-OOTB Business Rules
- Historical Data (e.g. Customers, Products, Sales)
TRs the organization wants to outsource to the COTS product vendor or 3rd party service provider should be negotiated as a separate deliverable.
NOTE: The scope of TRs is much wider than information-system-related data (e.g. Training, Change Management, Operational Readiness). They also are applicable to either COTS or custom-developed solutions. Data-related TRs are included in this article because they are closely related to the DTR effort and involved SMEs.
Conclusion
The objective of implementing a COTS information system is to contribute to the solution of a business problem or help take advantage of a business opportunity. The objective of a DTR effort is to identify which of the available capabilities can be implemented OOTB, which aren’t needed, and organization-specific capability changes or additions. Where cost is an issue, changes and additions need to be weighed against benefit. Individual changes or whole capabilities can be removed from the implementation scope if necessary.
Organization-specific changes or additions removed from scope that impact the solution will need to be addressed by alternate means. Users can be trained to use OOTB capabilities in ways other than originally intended. Process activities or decisions left unsupported by system capabilities will need off-system sources of the information involved.
NOTE: Out of scope changes or additions that can be addressed through configuration by organization-trained resources can be actioned post-implementation.
Ideally the ultimate implementation of the COTS information system product based on in-scope DTRs will prove to be a successful solution.
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].