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 requirement.
    • 3 - There is at least one story that addresses the requirement but it is 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.

High level requirements create lower level requirements. The lower level requirements are mapped directly to the stories 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. The number of requirements is shown at the top of each bar.

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, and the number of requirements is shown at the top of each bar. 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, usually because

• It did not increase the general scope of the stories already mapped to a requirement (e.g., incremental story or sub-task).
• It was a bug.
• It was a developer-facing story 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 analysis. 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, tickets with the "In Progress" status were assumed to be "Done". As before, the total number of requirements per scoring bin in shown in black, and the number of requirements is shown at the top of each bar. The labels are roughly associated with the Work Package keyword, though they more descriptive to represents sections of the software:

• Epic - the ticket was an Epic, 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.
• Developer - the ticket was a developer focused task not explicitly associated with a Work Package.
• Submit - Stories about Proposal Submission.