Page History
...
3. Review and discuss triage of possible requirements (see D3 Triage, previously distributed)
4. Start work on purpose and use cases (see Example Use Cases attached)
5. Confirm Next Meeting - Tuesday 26 July
Apologies: Andrew Sullivan, Scott Hollenbeck, James Gannon, Holly Raiche, Daniel Nanghaka, Steve Metalitz, Susan Prosser,
On audio only: none
Notes – RDS PDP WG Meeting 20 Jully 2016:
...
- RDS PDP List of Possible Requirements D3 - TriageInProgress - 13 July.docx (previously distributed)
- An Excel workbook version is also available for filtering on phase and group: PRSpreadsheets-D3Triage-13July.xlsx
- Note that a word version was also distributed (on 13 July)
- Purpose of excel sheet is to be able to filter on different phases and groups.
- Not stopping with draft 3, draft 4 will be produced next which will include all the possible requirements that have been submitted since draft 3.
- Triage is not intended to add, change any of the requirements, it is only a re-organisation of the possible requirements. It includes formatting to include a grid to be able to add columns. This version currently includes 5 columns - first three two are the same as in the original document. Column 4 includes the proposed phase according to the charter (phase 1 - requirements, phase 2, policy, phase 3 - implementation / co-existence), column 5 includes a possible grouping - which is just a starting point to highlight possible interdependencies. Unique identifier number means it should always be possible to find back the possible requirement, no matter how the table is sorted.
- Guidance from the charter which derives from the process approach determined currently proposed phase. In some cases, a possible requirement may fall into more than 1 stage - likely that these will get refined.
- Objective of phase identification column (4) is to allow WG to first focus on deliberating phase 1 possible requirements.
- Pre-Requisites/Dependencies column aims column (3) aims to identify possible requirements that have some linkage and/or interdependency (duplicates, connection, sub-requirement of other requirement, etc.). Idea is that this would allow to identify the most foundational requirements that do not have any dependencies.
- Group column (5) includes letters - these are a key (see last page for description). Main focus of the possible requirements was determining factor for assigning a key, which was easy in some cases more difficult in others. This is not set in stone - as the WG deliberates and reviews the use cases, it will be able to update as needed. Groups are not intended to be exhaustive. In some cases, possible requirements fell into multiple groups. Categories came from possible requirements themselves, no separate kind of overall grouping approach was applied. May be better to think of them as key words / hashtags, not "group" as that may imply some kind of segregation that was not intended. Key words would allow to show at one glance all requirements linked to for example consent, or proxy. Noting is pulled out - grouping is just a keyword/tag to allow for filtering/sorting.
- Best place to focus for WG is pre-requisites & depencies column as well as phase column, to make sure these are accurately. At this stage, there may not be too much value in refining / reviewing the groupings. Grouping is aimed at organising work, it is not a determining factor in how/when possible requirements are deliberated.
- Excel sorting will allow WG to view certain parts of the possible requirements to facilitate deliberations.
- Word document includes some introductory materials as well as cross-cutting questions identified in the charter that are not available in the excel version.
- The triage is assisting us in quickly locating useful information amongst at least 800 items. The grouping doesn't assign any value or restrictions to the requirement.
...
