Guidance for granularity of component definition

[cbashioum]

User Story:

As an OSCAL component description implementer, I would like to have some "rule of thumb" or other guidance/recommendations on what would be a reasonable granularity of the component

Goals:

Whether I am a vendor or capability provider (e.g., a Government PMO), I would like some guidance on how to approach identifying a reasonable granularity of component. In some cases, I may be a vendor with a "system of systems" based product, that itself may be extensible. As a capability provider (e.g., Government PMO) my capability may be composed of multiple subsystems, and I would like to be able to have some guidance on how to approach "parsing" my capability into reasonable components.

Note that folks at GovReady and C2 Labs mentioned at the OSCAL Workshop 2020 that thinking about "unit of reusability" and/or at the level of an OpenID Connect client might be helpful

Dependencies:

Some experiences creating component descriptions

Acceptance Criteria

• [ ] All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• [ ] A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• [ ] The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.
• [ ] Specific section in the Component Definition Model (https://pages.nist.gov/OSCAL/documentation/schema/implementation-layer/component/) addessing this issue

[david-waltermire]

This will be addressed by the tutorials related to #854.

[david-waltermire]

This relates to the discussion #1177.

[aj-stein-nist]

Given the questions around core requirements for this issue and existing comments and labels, I will align the status with "DEFINE Research Needed."