A Technical Design Document (TDD) includes information about the programmatic approach of how a particular requirement will be implemented.
TDDs are prepared primarily by the developer for the final development. They are also used by the testing team to write detailed test cases. The following are the key objectives of technical design documentation:
- Details of application architecture and design goals
- Data validation
- Documentation of the code (high level)
- Data flow diagrams
We will discuss the design patterns and things to be cognizant of while putting together a technical design. A technical design is about the solution planning and putting together a skeleton of the technical solution. Putting together good design documentation will help you save development rework and improve the quality of code by allowing you to think through several facets of the solution before you start coding.
Consider the following before starting to write TDDs:
- The technical design typically starts after the signoff of the functional design. It can also, start early for a functional area where the requirements are clear.
- Engage the technical lead early on during functional designing to understand the functional requirements and the functional flow.
- Plan brainstorming sessions amongst the team to discuss different solution ideas.
- Plan separate technical specs for integrations and data migration.
- Plan communication among the team to handle cross-functional designs.
Consider the following when writing TDDs:
- Process flow: Depict the overall process flow for the functional area so that it's clear to the developer what the final outcome is and how to reach it.
- UI and usability: Keep in mind the users and processes that will be using the new forms: is it workers on the floor or a person in the accounting department? Is it a repetitive function, such as shipping sales orders or invoicing POs, or is it a batch process, such as invoicing sales orders? Use familiar UI patterns considering the users of the functionality.
- Scalability of solution: Think about how the solution can be scalable, such as more controlled by parameters and data rather than code. Having it controlled by parameters will help you in global environments. For example, you can turn off the functionality for companies that don't want to use it. Also, should you have an issue in production with the recently released functionality, you might have the option to turn it off using parameters, rather than a full rollback during business hours.
- Apply generic design patterns: Utilize solution ideas and frameworks offered within the product. The goal is not to rewrite the Dynamics AX product; you are just extending its capability for business use. For example, if you have a bulk integration requirement, try to evaluate whether you can expand the DIXF framework for this rather than building a new framework from scratch. Follow the design patterns of the standard Dynamics AX Forms for custom forms.
- Performance: Identify the volume of transactions in the current production and anticipated growth in the next few years. The solution should consider the performance requirement early on. Design a prototype and generate sample data to test performance.
- Exception handling: Identify exceptional scenarios and document them. Build enough controls to avoid mistakes by users (you don't want to leave flaws that would let users hurt themselves). On the other hand, you don't want to spend too much time on building an extremely idiot-proof system.
- Security: Consider security aspects as part of the technical design.
- Review: Review the technical design solution ideas with the solution architect and functional leads for their input on a periodic basis to incorporate feedback.
- Brainstorm: There are multiple ways to solve a problem—discussions and brainstorming lead to the identification of the best possible one.