Convert Requirement source and owner into objects with additional metadata

Description

Requirement source and owner are awkward and mis-understood... I'd like to include additional information about them to clarify and improve knowledge about them.

What will this enable

• Develop status tracker per requirements source
• Be able to link to original copy
• Include a job to test whether links are still valid (if reachable)

Background

The intent and purpose of the "Requirements source" and "requirement owner" fields was to explain the origin story of the individual KSAT. Due to confusion in understanding what these fields actually mean, they have not always been implemented correctly.

Examples of sources and owners

Below are a number of potential source requirements documents and their "owners". I'm including this to give a better example of what we'll need to be able to associate to KSATs.

Example 1 - National Level Document

The NICE Cybersecurity Workforce Framework developed a method for classifying all cybersecurity positions in the federal government. It has been mandated that all positions within the government will be aligned to one or more of these codes. OPM published a list of codes to be applied to all civilian positions (ref: https://dw.opm.gov/datastandards/referenceData/2273/current?index=C) and the DoD further adapted this NCWF into the Defense Cybersecurity Workforce Framework (which is roughly the same).

Because of this mandate I would like to track all of these requirements so if we were ever asked how we meet the guidance we can show that. Additionally, many KSAT's have been developed by the NCWF which we can re-use for our own purposes therefore hitting two birds with one stone.

Short Name: NCWF
Document Reference: NIST Special Publication 800-181
Title: NICE Cybersecurity Workforce Framework (NCWF)
Published date: August 2017
Version: 
OPR: NIST
Link: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-181.pdf
Comments: The SP-Dev-001 workrole applies to developer positions

Take the following KSAT as an example:

ID	Source	Owner	Parent(s)	Description	Children	Work Roles/Specializations
S0002	NCWF S0014	USCYBERCOM/J7	T0009, T0010	Skill in conducting software debugging.	S0016, S0017

Rather than a single entry for NCWF S0014 we should show the NCWF seperately from S0014 which is an internal ID to the NCWF.

ID	Source	Source Key	Owner	Parent(s)	Description
S0002	NCWF	S0014	USCYBERCOM/J7	T0009, T0010	Skill in conducting software debugging.

Example 2 - USCYBERCOMMAND Document

Display Name: JCT&CS
Document Reference: N/A
Title: Joint Cyber Training & Certification Standard
Published date: ???
Version: 3.0
OPR: USCYBERCOMMAND/J7
Link: insert unclass sharepoint
Classification: TS//SCI
Comments: This is the source of all joint position KSAT.  The overall document is TS//SCI however individual collections of requirements such as CCD are classified at the level of their requirements.  Therefore CCD is unclassified.

Example 3 - Workcenter Master Training Plan

Display Name: CYK MTP
Document Reference: N/A
Title: 90th Cyberspace Operations Squadron (90COS)/Weapons & Tactics Flight Master Training Plan
Published date: ???
OPR: CYK/CCS
Link: Link to MTP?
Comments: wish this was better

Example 4 - CFETP

Display Name: 3D0X4 CFETP
Document Reference: CFETP3D0X4
Title: 90th Cyberspace Operations Squadron (90COS)/Weapons & Tactics Flight Master Training Plan
Published date: 01 August 2013
OPR: CYT/UTM
Link: https://static.e-publishing.af.mil/production/1/af_a2_6/publication/cfetp3d0x4/cfetp3d0x4.pdf
Comments:

Example 5 - Issue submitted to our gitlab

When a request for a particular KSAT is made via our gitlab the conversation and discussion are captured within the ticket. We can simply link to the issue to track its origin. https://gitlab.com/90cos/public/mttl/-/merge_requests/17 was an MR but should have started as an issue to create these requirements.

Display Name: Issue #
Link: to issue

ID	Source	Source Key
S0002	Issue	issuelink

Example 6 - Request by Workrole owner? TD? TA? CC? (same as above?)

Display Name: Issue #
Link: to issue

User Experience Questions

1. @boon8218 "What happens when users click on a source?" Answer: I think we need to be able to select the behavior. Perhaps a field in the schema is (maybe that's a frontend question). If the source has a reachable link it should take them there so they can see the document for themselves. If there is not an external URL then we could take them to a file within the repo. Lastly, we could choose for the source to just not be linkable by leaving the display link blank.

2. @boon8218 "Does this change what shows up on the MTTL?" Answer: I don't know. I think we'll need to prototype that out. I'm assuming a lot of our source documents have an internal identification scheme we could use to give more fidelity to the reference... but maybe not. If they all have something perhaps a Source Key field should be added.

Mandatory Fields

• Display Name: What is displayed on the MTTL
• _ID: (do we need an id to reference within Mongo etc.)

Acceptance Criteria

• Sources are now objects that can have additional data attached to them
• Frontend changes to be applied in #108