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-2030-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 - 4 how well the stories met the requirement (marginally subjective).
    
    • 0 - The requirement is no longer in scope.
      
      • e.g.
        
        • 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.
      • e.g.
        
        • 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 are no stories associated with the requirement yet.
    • 3 - The stories to do not satisfy the requirement.
    • 4 - There is at least one story that meets the scope of the requirement.

Multiple high level requirements create lower level requirements. The origin of the low level requirements are mapped directly to the stories and scored in the figure below.  The ordinate is the percentage of requirements associated with the requirement group (e.g., TTA-1, TTA-L0). The abscissa is the translation of the score into words. The colored bars represent each 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. Note that there may be duplication in counting the requirements (see next figure for only the low level requirements).

For example, in "Story does not exist", there are 6 requirements derived directly from the high level requirement group of TTA-1, which accounts for ~48% of the total requirements (17) associated with TTA-1. The black bar in this bin shows that roughly 55% of all the requirement groups accounted for here do not have a story associated with them.

The figure below shows only the low level requirements of TTA-L0, TTA-L1, and TTA-SRDP. These requirements will be mapped to software versions in a subsequent figure.

Of interest is how the requirements are satisfied according to software versions and what percentage of the stories are complete. The versions shown in the figure below are associated with keywords (source: https://open-confluence.nrao.edu/x/4CL2BQ):

• Versions 0.1, 0.5, and 0.6 → Proposal Creation and Solicitation Configurations
• Version 0.2 → Proposal Submission and Review Process
• Version 0.3 → Time Allocation
• Version 0.4 → Project Creation and Proposal Closeout
• Version 0.0 and stories not associated with a version → General

Also shown in the bottom subplot is the percentage of stories that are done per group (as of 1.29.23).

Image RemovedImage Added

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.29.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.