Checks for Additional PoCs (source: 18F/fedramp-automation: 311)

[danielnaab]

Original issue: 18F#311

Extended Description
As a FedRAMP reviewer, in order to easily determine what other people I may need to reach out to for clarifications on details of a FedRAMP package or the systems' implementations, I want a check to know additional points of contact for responsible parties have been added beyond those that are minimally required.

Preconditions

Acceptance Criteria

• A check that highlights the additional PoCs added beyond those required (as currently defined in checks added for Check Role Mappings 18F/fedramp-automation#51)

Story Tasks

• 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
• 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
• 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

[aj-stein-gsa]

Re ADR 7, we will not use the previous constraint architecture as-is and the relevant code will soon be removed. I am closing this issue as not planned.