As a FedRAMP reviewer, to ensure that SSP submitters properly identify the status of a previous authorization for the same system, I want to a check that a package FedRAMP System ID is valid (as published in the FedRAMP Marketplace).
Preconditions
[x] A confirmation that the source FedRAMP Marketplace data is parseable and usable in JSON form by our Schematron and XPath 3.1 processing toolchain.
Acceptance Critera
[x] A rule that checks and warns that, given a FedRAMP-based system identifier (Guide to OSCAL-based FedRAMP System Security Plans Section 4.1), an assertion is made that a FedRAMP identifier is associated with a valid, active package.
Story Tasks
[x] Create conditional Schematron assertion
[x] No unit test is possible: test with schema-driven editor
[x] Update business rules
Definition of Done
[x] Acceptance criteria met - Each user story should meet the acceptance criteria in the description
- [ ] Unit test coverage of our code > 90% (from QASP) this may be fuzzy and hard to prove- [ ] Code quality checks passed (from QASP)- [ ] Accessibility: (from QASP) as we create guidance or documentation and reports (semantic tagging including aria tags): demonstrate with 0 errors reported for WCAG 2.1 AA standards using an automated scanner and 0 errors reported in manual testing
[x] Code reviewed - Code reviewed by at least one other team members (or developed by a pair)
[x] Source code merged - Code that’s demoed must be in source control and merged
[x] Code must successfully build and deploy into staging environment (from QASP): this may evolve from xslt sh pipline into something more
- [ ] Security reviewed and reported - Conduct vulnerability and compliance scanning. threat modeling?- [ ] Code submitted must be free of medium- and high-level static and dynamic security vulnerabilities (from QASP)- [ ] Usability tests passed - Each user story should be easy to use by target users (development community? FedRAMP FART team)- [ ] Usability testing and other user research methods must be conducted at regular intervals throughout the development process (not just at the beginning or end). (from QASP)
[x] Code refactored for clarity - Code must be clean, self-documenting
[x] No local design debt
[x] Load/performance tests passed - test data needed - saxon instrumentation
[x] Documentation generated - update readme or contributing markdown as necessary.
- [ ] Architectural Decision Record completed as necessary for significant design choices
Extended Description
As a FedRAMP reviewer, to ensure that SSP submitters properly identify the status of a previous authorization for the same system, I want to a check that a package FedRAMP System ID is valid (as published in the FedRAMP Marketplace).
Preconditions
Acceptance Critera
Story Tasks
Definition of Done
- [ ] Unit test coverage of our code > 90% (from QASP) this may be fuzzy and hard to prove- [ ] Code quality checks passed (from QASP)- [ ] Accessibility: (from QASP) as we create guidance or documentation and reports (semantic tagging including aria tags): demonstrate with 0 errors reported for WCAG 2.1 AA standards using an automated scanner and 0 errors reported in manual testing- [ ] Security reviewed and reported - Conduct vulnerability and compliance scanning. threat modeling?- [ ] Code submitted must be free of medium- and high-level static and dynamic security vulnerabilities (from QASP)- [ ] Usability tests passed - Each user story should be easy to use by target users (development community? FedRAMP FART team)- [ ] Usability testing and other user research methods must be conducted at regular intervals throughout the development process (not just at the beginning or end). (from QASP)- [ ] Architectural Decision Record completed as necessary for significant design choices