jadudm
commented
4 days ago It has been recommended that, for velocity, just work from the template in GDocs or similar.
Closed jadudm closed 4 days ago
jadudm
commented
4 days ago It has been recommended that, for velocity, just work from the template in GDocs or similar.
At a glance
In order to get this thing live as a system owner I want to automate my SSP
Acceptance Criteria
We use DRY behavior-driven development wherever possible.
Shepherd
Background
There are examples both within TTS and elsewhere of using OSCAL/trestle for SSP generation.
The conversion of the JSON to JSonnet may provide a fast path to 1) modularity and 2) some generation improvements. Because JSonnet is a clean generator of JSON, it should gain efficiencies and lose nothing.
https://github.com/usnistgov/oscal-content
and
https://pages.nist.gov/OSCAL/
are starting points.
Security Considerations
Required per CM-4.
None. Although, the question of whether we can store the SSP in the repo needs to be double-checked.
Process checklist
- [ ] Has a clear story statement - [ ] Can reasonably be done in a few days (otherwise, split this up!) - [ ] Shepherds have been identified - [ ] UX youexes all the things - [ ] Design designs all the things - [ ] Engineering engineers all the things - [ ] Meets acceptance criteria - [ ] Meets [QASP conditions](https://derisking-guide.18f.gov/qasp/) - [ ] Presented in a review - [ ] Includes screenshots or references to artifacts - [ ] Tagged with the sprint where it was finished - [ ] Archived ### If there's UI... - [ ] Screen reader - Listen to the experience with a screen reader extension, ensure the information presented in order - [ ] Keyboard navigation - Run through acceptance criteria with keyboard tabs, ensure it works. - [ ] Text scaling - Adjust viewport to 1280 pixels wide and zoom to 200%, ensure everything renders as expected. Document 400% zoom issues with USWDS if appropriate.