Extended Description
As a FedRAMP reviewer, in order to have clearer understanding of what is implemented right, what is implemented incorrectly, and what is missing for controls in section 13.
Preconditions
N/A
Acceptance Criteria
[ ] Reword relevant implementation-requirement or "implementation requirements" messaging in assertions (not technical diagnostic messaging) to "descriptions of how control requirements are implemented" or, for brevity, "control requirements."
Story Tasks
[ ]
Definition of Done
[ ] 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
[ ] 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
[ ] Code reviewed - Code reviewed by at least one other team members (or developed by a pair)
[ ] Source code merged - Code that’s demoed must be in source control and merged
[ ] 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)
[ ] Code refactored for clarity - Code must be clean, self-documenting
[ ] No local design debt
[ ] Load/performance tests passed - test data needed - saxon instrumentation
[ ] Documentation generated - update readme or contributing markdown as necessary.
[ ] Architectural Decision Record completed as necessary for significant design choices
Original issue: https://github.com/18F/fedramp-automation/issues/259
Extended Description As a FedRAMP reviewer, in order to have clearer understanding of what is implemented right, what is implemented incorrectly, and what is missing for controls in section 13.
Preconditions N/A
Acceptance Criteria
implementation-requirement
or "implementation requirements" messaging in assertions (not technical diagnostic messaging) to "descriptions of how control requirements are implemented" or, for brevity, "control requirements."Story Tasks
Definition of Done