UNCLASSIFIED - NO CUI

Skip to content

Requirement file reorg for requirement source codeowners

Description

As a requirement owner, I want direct control to change the requirements that I created without intervention with the system administrator so I can iteratively change them for the better

Acceptance Criteria

  • allow requirement owners to change their KSATs without approval from the MTTL system maintainers (CODEOWNERS feature requires separation of the requirement owners KSATs into files)
  • ability to identify what KSATs have been derived and which ones are original

Initial Plan

Current vs new requirements Directory structure

requirements                       requirements                    
- KNOWLEDGE.json                   - sources
- SKILLS.json                         - ACC_CCD_CDD_TTL.json
- ABILITIES.json           =>         - CYT.json
- TASKS.json                          - CYX.json
                                      - JCT&CS.json
                                      - ...
                                   - grouped_ksats.json

Currently the MTTL KSAT folder structure is very flat. Although it is useful to organize the requirements into their respective category it is not entirely useful from a maintainer's perspective because all KSATs will end up in the MTTL no matter what file they're located.

We want the ability to utilize the CODEOWNERS GitLab feature, which allows us to specify owners for specific files so any change to those files will require the owners approval. In this case, the KSATs are already defined to have a requirement_owner. This owner is the originator of the requirement and thus the most logical organization parameter of the KSATs so the owner can maintain their own requirements. From this, every requirement owner will have their own file at which they will control via the CODEOWNERs feature.

It is also necessary to consider that there will be duplicates between requirement owner KSATs. In order to identify overlapping requirements we use a separate file to group these KSATs together so when the MTTL is created there will only be one entry for both requirement owners.

{
	"_id": {
		"$oid": "5f457f1e1ea90ba9adb32a9d"
	},
	"ksat_id": "K0002",
	"parent": [
		{
			"$oid": "5f457f1e1ea90ba9adb32c9c"
		}
	],
	"description": "Describe Modular Design",
	"topic": "Software Engineering fundamentals",
	"requirement_src": [
		"ACC CCD CDD TTL"
	],
	"requirement_owner": "ACC A3/2/6KO",
	"comments": "",
	"updated_on": "2020-07-10"
}

Above is a dataset entry for a knowledge requirement.

We also want the ability to identify what has been derived and what is the original requirement description. The easiest modification to account for derivation of a description is to add a new field to this structure, derived_description. If the derived_description is present in the dataset entry, it will be used in the MTTL instead of the original description (we could keep it too and show it somewhere on the frontend when the requirement is expanded but that is outside the scope of this feature). This will keep the original description of the requirement in the structure until it is agreed upon by higher authority to make the derived descriptions official.

UNCLASSIFIED - NO CUI