Updates specification.md based on sa-tre#279 proposal

docs/source/specification.md

@@ -4,33 +4,17 @@
 
 The specification is presented in terms of the capabilities that a team running a TRE should aim for across all aspects of TRE provision.
 
-The specification is split into {ref}`four pillars <satre_pillars>`.
-
-## Structure of the specification
-
-This page explains what the specification is, and how it's structured.
+This page explains what the specification is and how it’s structured. 
+It also describes how the importance of components is categorised. 
 Consult the {ref}`FAQs <faqs>` for more on what the specification _is not_.
 
 :::{note}
 Throughout this document, we will use the term "{ref}`TRE operator <infrastructure_roles>`" to refer to the team running a particular TRE.
 :::
 
-The TRE capabilities are broken down into components.
-Each component is a statement of a process, method or practice that the operators should have in place to ensure they fulfil the capability requirements.
-These components are each labelled with an importance:
-
-:Mandatory: This is required: if this component is not supported, then the capability, and therefore the specification, is not met.
-:Recommended: Most TREs should have this component, but it is not essential.
-:Optional: Many TREs would benefit from this component, however, we recognise there are reasons a {ref}`TRE operator <infrastructure_roles>` may actively choose not to implement it.
-
-{ref}`TRE operator <infrastructure_roles>`s are able to demonstrate that they meet the specification by showing they can fulfil all **mandatory** components.
-Future versions of the specification may introduce more granular levels of evaluation, for instance tiered level of accreditation based on fulfilment of mandatory, recommended and optional components respectively.
-
-Any particular TRE implementation should be able to {ref}`score itself against each capability <scoring_method>`.
-
 ## Structure
 
-The SATRE specification contains four key parts:
+The SATRE specification comprises three key parts:
 
 ```{figure} ../images/Architecture.svg
 :alt: SATRE Specification Architecture
@@ -45,6 +29,7 @@ SATRE Specification Architecture
 
 Together, these provide a framework that {ref}`TRE operator <infrastructure_roles>`s can measure themselves against.
 
+
 ## Architectural Principles
 
 The SATRE specification has been developed based on the following principles:
@@ -78,3 +63,40 @@ SATRE Pillars Capability Map
 
 {ref}`4. Supporting capabilities <pillar_supporting>`
 : A {ref}`TRE operator <infrastructure_roles>` will need to possess various supporting capabilities, such as complying with legal requirements and managing relationships with stakeholders.
+
+### Importance
+
+The TRE capabilities are broken down into components.
+Each component is a statement of a process, method or practice that the operators should have in place to ensure they fulfil the capability requirements.
+These components are each labelled with an importance:
+
+:Mandatory: This is required: if this component is not supported, then the capability, and therefore the specification, is not met.
+:Recommended: Most TREs should have this component, but it is not essential.
+:Optional: Many TREs would benefit from this component, however, we recognise there are reasons a {ref}`TRE operator <infrastructure_roles>` may actively choose not to implement it.
+
+{ref}`TRE operator <infrastructure_roles>`s are able to demonstrate that they meet the specification by showing they can fulfil all **mandatory** components.
+Future versions of the specification may introduce more granular levels of evaluation, for instance tiered level of accreditation based on fulfilment of mandatory, recommended and optional components respectively.
+
+Any particular TRE implementation should be able to {ref}`score itself against each capability <scoring_method>`.
+
+## Roles
+
+A TRE needs to consider many different stakeholders. 
+SATRE provides specific roles which may or may not match titles used in your organisation. 
+However each of these are important to the successful operation of a TRE. 
+Roles are grouped into:
+
+{ref}`1. Project Roles <project_roles>`
+: Roles for TRE end-users conducting research or analysing data in the TRE and others involved in managing this research.
+
+{ref}`2. Data Management Roles <data_roles>`
+: Roles for people managing data and databases used in a TRE
+
+{ref}`3. Infrastructure Management Roles <infrastructure_roles>`
+: The IT professionals and software engineers who will be responsible for developing, deploying and managing instances of a TRE conforming to the SATRE specification.
+
+{ref}`4. Governance Roles <governance_roles>`
+: Roles that uphold the governance of TREs. Such governance responsibilities typically involve establishing policies and procedures to ensure the responsible use of data, protecting the privacy and confidentiality of research participants, and promoting transparency and accountability in research activities.
+
+{ref}`5. Public Roles <public_roles>`
+: Roles that concern members of the public with regard to TREs and TRE research.