Functional Description and Detailed Design Review Guideline
This guideline describes how to perform a Functional Description and Detailed Design review.
Review Rules
Author
- You may not approve your own changes.
- Do not merge to the master branch until the review is completed.
Reviewer
- Offer as much positive feedback as possible
- It is a great place to learn something new
- Proposed changes to the different functionality should be discussed and stored in separate work items. If the change is handled as part of future work, please add the corresponding work item
- Use the mandatory review checklist pointed out by the project.
Functional description
Review Goals
- Make the functional description understandable for other stakeholders than developers, such as product owners, testers, and user documenters.
- The descriptions shall be a base for the development of the component in future projects.
- The descriptions shall be detailed enough to understand the functionality in future projects.
- The functional description can also include other valid information about for example performance, scalability, maintenance, etc.
Review Checklist
- Is the functionality description consistent with the feature description?
- Is the functionality consistent with the capabilities?
- Are there forward and backward traceability to the capabilities?
Detailed design
Review Goals
- Help new developers get an overview of the code.
- The description shall describe the structure and design of components/modules and how different code modules and classes within the component interact.
- Describe the complex design parts, that will help developers to understand the code in the future.
- The detailed design shall be consistent with architectural modeling.
- Describe the design needed to fulfill the requirements of cyber security and safety.
Review Checklist
- Is the new design consistent with the current description?
- Are the public interfaces of the component described?
- Are the complex design parts described?
- If modeling is the checklist for modeling followed?
- Is there traceability to the functional descriptions?
- Is there traceability between the detailed design and the architecture model?
- Does the design follow/cover the intended security part of the architecture?
- Does the design consider security best practices listed at Secure Design Best Practices
- Does the design implement or follow the applicable mitigations described in the threat model?
Owner: Software Development Team