FDDs speak the application language and terminology, so business analysts writing the functional design documents must understand the Dynamics 365 for Finance and Operations, Enterprise edition application and functionality. A lack of product knowledge and understanding can keep the documents at a high level, pushing the design aspects to the developers, which deviates from the purpose of the documents.

Always ensure that all the key decisions made during the design time are recorded in the key decision log and signed off from the project team. Recommended areas where key decisions are mostly taken are as follows:

• Financials
• Inventory costing
• Adjustments
• Integrations
• Reporting

Also, all assumptions should be documented and validated with the concerned stakeholders to ensure a solution built to purpose.

Microsoft Dynamics Sure Step provided good templates to write FDDs. Create your own version with the sections relevant to your project and have the team follow the template.

Always have one or many requirements in the Requirements Traceability Matrix (RTM) corresponding to the functional design document. RTM is a foundational element in ERP implementations, as it ensures consistent delivery against contract and business requirements.