When an organization offers one or more products or services to a significant number of customers, an information system will typically be involved. This article discusses three fundamental scenarios a BA might face when asked to document product requirements for such an information system. Those scenarios are:
- An existing system able to support a new product through configuration.
- One or more aspects of a new product that will need custom/bespoke development.
- A packaged solution, able to support a new product, to be acquired and implemented.
For the purpose of this discussion the term PRODUCT includes the concept of SERVICE and is defined as:
“Something of perceived value that an organization makes available, or intends to make available, to external parties.”
This definition is intended to be applicable to any industry sector, including government and not for profit. It’s intended to exclude a work product or product-owner product, where that product does not meet the criteria of the above definition.
NOTE: The term product is like the term report in that, depending on the context, it actually represents either a type or an instance. E.g. a developer develops a report (type) while a user receives a report (instance). Within the context of requirements, it’s understood that what’s wanted are requirements for a type of product, not an instance of one.
Scenario 1. Product Configuration Possible
An information system designed to be configurable allows certain capabilities to be enhanced though data, without resorting to additional software development. When the configurable capabilities relate to products, what is required is the set of specific data values that will represent the new product and its related aspects (e.g. pricing, eligibility factors).
The first part of configuration involves a subject matter expert (SME) who understands the configurable aspects. This person may be an experienced system user, a BA, or a system analyst.
The second part of configuration involves a SME able to provide the specific data values needed for the new product. Note that this person may or may not be the product’s owner. The first SME understands the configuration form. This second provides the content.
A spreadsheet is commonly used to capture the new product-specific configuration values. A spreadsheet has two main advantages:
1. Business-friendly – individual worksheets representing the different aspects of the product and, within a worksheet, column headings that identify the individual properties related to a given aspect. This makes the requirements easy for stakeholders to review and sign-off.
2. Machine-readable – a spreadsheet file allows corresponding system tables to be updated via data import capability or database script. NOTE: Manually entering configuration data into a test environment is ok. But there would ideally be an automated way to get successfully tested configuration data into production.
Scenario 2. Custom / Bespoke Development Needed
Custom development is needed in cases where a new system is to be developed (or acquired) or an existing system does not provide sufficient configuration capabilities. Either of these cases will involve three types of requirements:
1. Functional Requirements – to support the product’s operation. These should start with high-level capability-based requirements. These HLRs act as a context for detailed requirements needed to support design, development, and testing of the new or modified system. (See the Requirements in Context Series).
2. Data Requirements – to support additional configuration capabilities and/or information needs associated with additional functional capabilities. (See Managing Data-specific Needs using a Data Dictionary). NOTE: Design of custom capabilities for an information system supporting products should consider including configuration capabilities for future products.
3. Product Requirements – In addition to the custom functionality being delivered, the specific product that the software is intended to support needs to be delivered as part of going operational with the new functionality. (See Scenario 1 section above.)
Scenario 3. Packaged Solution
High-Level Requirements for Selected Package Implementation
The two things a product packaged solution needs to support are:
- Activities within Product Development, Sales, and Customer Care processes that the organization believes must be supported
NOTE: From an information system perspective, Product Development only applies to preparing the information system to support Sales and Customer Care processes. The product can be something physical or digital. Any requirements related to the design or production of physical products are separate from information system requirements.
A vendor should be able to provide details of their package’s product configuration capabilities in a form that can be reviewed by the organization’s product SME(s). This review should involve any existing products that are to be supported by the package, as well as new products to be offered when the system becomes operational.
With regards to the organization’s ‘must be supported’ product-related activities, they should be documented as HLRs – the same as if the system capabilities were to be delivered through custom development. (See Keeping High-Level Requirements High-Level.) These HLRs should be part of the gap analysis for a packaged solution. Any shortlisted vendor should be able to demonstrate those capabilities they have indicated full or partial match.
Detailed Requirements for Selected Package Implementation
Detailed requirements (DTRs) for a packaged solution should not be needed until a package has been selected. That package will provide, ‘out of the box’, some or all of the capability that would otherwise need software design, development, and unit testing. It does not eliminate the need for:
- System configuration (e.g. system users to user type security profiles)
- Operational readiness activities
Detailed requirements are needed to support all the above.
Given the package to be implemented, if there is agreement that one or more functional capability gaps are to be filled by custom development, detailed requirements are needed for those capabilities. (See Scenario 2 section above.)
If implementing the package includes migrating data from one or more existing systems, detailed data requirements are needed to support that activity. (See Managing Data-specific Needs using a Data Dictionary).
Where the package is supporting one or more products within an existing line of business, the package implementation effort should begin with the organization’s product SMEs working with package SMEs. This work addresses product configuration, plus mapping the functional HLRs to specific package capabilities (e.g. sections within the package’s documentation). If a field-level data dictionary is available for the package, it should be used as the basis for mapping to the organization’s data concepts – necessary to support testing, user training, and any data migration.
NOTE: Where a selected package contains one or more functional capabilities over and above those originally identified as HLRs, those capabilities should be evaluated for adding to the scope of the solution being implemented. For those capabilities selected for inclusion, detailed requirements will be needed for the same reasons listed above.
Summary
Product configuration requirements are a specialized type of requirement when an information system supports product-related needs through data values. Where there are specific changes to business processes needed to sell and/or operate a new product, the requirements for the information system to support activities within those processes involve standard functional requirements.
Whether an information system can support a product though configuration or requires custom development, when an information system is involved there are standard pre-go-live activities that need to be performed (e.g. testing). Requirements support those activities.
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].