Page History

• 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.
      • only 2 requirements have this score:
        
        • 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.
      • only 1 requirement has this score:
        
        • 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 requirementsrequirement.
    • 3 - There is at least one story that addresses the requirement but it is very severely insufficient in scope or too high level.
    • 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, specifically, histograms, like a good scientist. Specifically, histograms.

High level requirements are used to create other lower level 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. Roughly 58% of all the requirements do not have a story associated with the requirement.

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 when sorted 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:, usually because

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

The figure below shows the breakdown of the number of stories (as of 1.19.23) that were account for in this processanalysis. 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 tickets with the "In Progress" status was were assumed to be "Done". The labels are roughly associated with the Work Package keyword, though they more descriptive to present parts represents sections of the software:

• Epic - the ticket was an Epic and not a story itself, which contains many stories.
• 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 explicitly associated with a Work Package.
• Submit - proposal submissionStories about Proposal Submission.

Image Modified