2023-01-27 TTA Requirements Meeting

STT-1146 - Getting issue details... STATUS

• SRP Member action and TTA Group member powers

• For a SRP member, they would not have a “save” option on conflict certification. They can only certify or the changes do not persist.

• A TTA member should be able to change a conflict designation at any time. We do not need the software to manage if it is the result of the auto conflict process or a user specified conflict, as we trust the TTA member.

• A TTA member should be able to certify a user's conflict status, if necessary.

688-TTAT-014-MGMT_REQ-Mapped-Jira-1-20-23.csv

• General nomenclature:
  • The top level requirement for the TTAT project is TTA-1.
  • The lower level requirements are listed as TTA-L0 and -L1. They are subdivided further by number (e.g., TTA-L0-2) in the requirements doc but consolidated as to be TTA-L0 and -L1 here
    • L0 are Science Requirements or Stakeholder Requirements.
    • L1 are System Level Requirements.
  • SRDP derived requirements are marked as TTA-SRDP.
• Procedure:
  • Map the stories from Jira to the requirements and rate, on a scale of 0 - 5 how well the stories met the requirement (marginally subjective).
    
    • 0 - The requirement is no longer a requirement.
      • TTA-L1-80: History of the changes made during the consensus review need to be tracked.
      • TTA-L1-29: It shall be possible  with best efforts  to create a new draft from a proposal in the WITHDRAWN or COMPLETED state.
    • 1 - The requirement does not need a story to explicitly be satisfied.
      • TTA-L1-94: In the rare case that a reviewer feels uncomfortable reviewing a proposal they will communicate outside the TTA Tools to a TTA Group member to reassign the review.
    • 2 - There is not a story that addresses the requirements.
    • 3 - There is at least one story that addresses the requirement but it is very insufficient in scope.
    • 4 - There is at least one story that addresses the requirement but not fully.
    • 5 - There is at least one story that meets or exceeds the scope of the requirement.
  • Make plots like a good scientist. Specifically, histograms.

High level requirements are used to create other requirements. The lower level requirements are mapped directly to the stories, generally, and scored. This plot compares the high level requirements directory to the score associated with the derived lower level requirements. The ordinate is the percentage of requirements associated with the high level requirement group (e.g., TTA-1, TTA-L0). The abscissa is the translation of the score into words. The colored bars represent each high level requirement group, and the black bar is the total number of requirements that belong to that scoring bin.

For example, in "Story does not exist", there are 10 low level requirements derived directly from the high level requirement group of TTA-1, which accounts for ~59% of the total requirements (17) associated with TTA-1.

The requirements are associated with Work Package names, which roughly translate to portions of the system (e.g., Create Projects, Review Configuration). The figure below shows how the low level requirements are scored by Work Package. As before, the total number of requirements per scoring bin in shown in black. The Work Packages of interest were

• Propose - Proposal Creation
• Review Configuration
• Review
• Allocate
• Close - End of Review Process
• Create Projects
• System
• Stakeholder
• Non-function Requirements

Not every story was mapped to a requirement for a variety of reasons:

• It did not increase the general scope of the stories already mapped to a requirement usually because of being an incremental story or sub-task.
• It was a bug.
• It was a developer story which was difficult to tie directly to a requirement.

The figure below shows the breakdown the number of stories (as of 1.19.23) were account for in this process. They are sorted into bins of "Not Mapped" and "Mapped", which means they are either not associated with a requirement or are, respectively. The status (as of 1.19.2023) of the ticket is also used to subdivide the tickets. Note, any ticket with the "In Progress" status was assumed to be "Done". The labels are roughly associated with the Work Package keyword, though they more descriptive to present parts of the software:

• Epic - the ticket was an Epic and not a story itself.
• Sub-Task - the ticket was a sub-task.
• User - General user story not explicitly associated with a Work Package.
• Bug - the ticket was a bug ticket.
• Developer - the ticket was a developer focused task not explicit associated with a Work Package.
• Submit -proposal submission