Assumptions:
[Identify assumptions made for this work.]
It is assumed that any issues will be surfaced to determine impact, even technical issues, as the technical approach IS the product in this case and affects business interests. It is also assumed that the systems currently in place for traceability, backlog management, source code management, and build/release are capable of full integration.
Reasoning: It could be an environment's existence or technical approach. This could be detailed understanding of a regulation, access to a certain system, pair programming, TDD, following best practices (although that should be the standard assumption), etc.
Regulatory guidance: TODO
Technical notes:
[For the technical team to put any information that they want to remember and callout, follow up, or discuss as a larger group.]
Potential options to review are the new abilities in Azure Blueprints, ARM templates, PowerShell capabilities, AAD integration, Azure Cloud Services (extended support), and/or any hybrid that may come to mind in the reviewing and discarding of any of those approaches.
Reasoning: This one is mainly for the developers to capture their discussion with each other or a placeholder for follow up or design. Again, trying to keep the backlog as the source of truth.
Regulatory guidance: TODO
Technical risks:
[Identify risks that are not obvious –and shouldn't be –to the product or business side. They *should* be able to assume that the engineers are doing their jobs correctly.]
Reasoning: This is basically as it says. It is for the developers but can also be an addendum to the risks identified by the product team as well, or something specific to a technical need. Again, this also provides evidence of a risk analysis having occurred, as required by several standards.
Regulatory guidance: TODO
留言