To submit feedback about any of the content - click here
Capabilities and Standards Structure
Each Capability will have a Title, Description, Outcomes, Epics and Acceptance Criteria and then some or all of the other elements to give more detail as necessary. This section describes the structure of a Capability and the detail within it.
Capabilities and Standards Structure
Capabilities and Standards will each have the content detailed in the table below.
ID | Each Capability and Standard has a unique identifier composed of one letter followed by a number. The letter "C" indicates a Capability and an "S" indicates a Standard. The number is arbitrary and does not have any additional meaning such as priority, sequence or inter-relationships. This allows for the identification of Capabilities and Standards in a consistent manner. |
Version | Each Capability and Standard has a version number. Each Capability and Standard can change independently and its version number will change accordingly. Version numbers are subject to change depending on the nature of the change (e.g. major, minor, patch). There is no relationship between the version numbers of different Capabilities and Standards. |
Type | Categorises as a Capability or a Standard and, where applicable defines the type of Standard:
|
Status | Each Capability and Standard will have one of five statuses:
|
Effective Date | Those Standards that are mandated under the Catalogue Agreement will have an Effective Date by which Suppliers must comply with the Standard. Suppliers will need to have achieved compliance against all Effective Standards (see Status above) in order to onboard on to the Catalogue. There may be other Standards that Suppliers need to achieve compliance with as part of the Framework Agreement in order to be awarded a place on a Framework. |
Structure of Capabilities
Description | A concise description of the purpose of the Capability covering the mandatory scope. |
Outcomes | The Outcomes section describes the main users of the Capability and the outcomes they want to achieve from using a Solution that meets the Capability based on the mandatory scope. |
Epics and Acceptance Criteria | Epics are individual high level business requirements and describe features relevant to the Capabilities they belong to. All Epics together define the full scope of a Capability. The Acceptance Criteria associated with an Epic define the minimum expected functions a Supplier’s Solution must deliver and are test scenarios that will be used during Capability Assessment stage of Onboarding to establish whether a Supplier’s Solution meets the Epic or not. In order to pass any Epic, all associated Acceptance Criteria for that Epic must pass the assessment. Epics are classified as either Must or May Epics and all Epics will be assessed during the Capability Assessment stage of Onboarding. It is recommended that Suppliers consider all Epics as part of User Research to understand what the Minimal Viable Product (MVP) is for their users. MUST EpicsMUST Epics describe the minimum functionality required to deliver a Capability. Solutions MUST be successfully evaluated against each Epic and Acceptance Criteria via Capability Assessment in order to be associated with this Capability. MAY EpicsMAY Epics describe additional functionality associated with the Capability. Suppliers should consider all MAY Epics as part of their User Research. Suppliers can choose to map their Solutions to these Epics and they will be evaluated via Capability Assessment. Framework Authorities or purchasing organisations may require these Epics as product qualification or requirements criteria. |
Additional Implementation Details | Additional Implementation Details are mandatory details related to a specific Epic and could be assessed during the Assurance stage of Onboarding. These details can include references to other Standards and Suppliers will need to complete any separate assurance activities related to those Standards. |
Supporting Information | This information may be useful to Suppliers when implementing the related Epic, but is not mandatory and is for guidance only. |
Overarching Standards | Overarching Standards apply to all Suppliers irrespective of the Capabilities their Solutions support. Suppliers will be assured against Overarching Standards during the Standards Assessment stage of Onboarding. |
Interoperability Standard | This Standard provides a single place for Suppliers to find out which interfaces they need to implement and to access the required documentation. It also contains overarching requirements that apply to all interfaces in the scope of the Interoperability Standard which are offered by a Solution. |
Roadmap | The Roadmap section summarises future changes and opportunities for Suppliers in relation to the Capability or Standard. These are linked to the individual Roadmap pages which provide further information on the Roadmap item. |
Structure of Standards
Requirement ID | Each requirement within a Standard will have a unique ID so it can be recognised during compliance |
Requirement Text | The description of each requirement within a Standard that will be used to determine compliance of a Solution with the Standard |
Requirement Level | Each requirement within a Standard will have a level as defined in RFC 2119.1, the Change Management and Roadmap Content ancillary document and the Master Glossary |
***