Open cbashioum opened 3 years ago
This will be addressed by the tutorials related to #854.
This relates to the discussion #1177.
Given the questions around core requirements for this issue and existing comments and labels, I will align the status with "DEFINE Research Needed."
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