Identifying key business information in the FDD will be key when reviewing the documentation in the future, as well as managing expectations. There are several pieces of business information I like to include.

In Scope - what is the goal of the project and what components will be included?  Identifying the rational and need for the customization will aid in the signoff process as well as in future review of the documentation. The scope should identify the end-goal of the customization.

Out of Scope - what components or areas are you not going to include as part of this solution? There are various reasons why something may be out of scope for a solution, including components that may be delayed to a further phase of the project. Regardless of the reason (budget, time, or other reasons) identifying these out of scope items will help to further manage expectations upon delivery of the customization.

Limitations - what limitations will the functionality have? I like to identify if the customization (especially reporting) is limited to using only data within D365 F&O. Identifying limitations is key when managing expectations of the new functionality or report. Calling these items out specifically will ensure all parties understand the limits of the design.

Key Stakeholders - who is requesting the change and approving the project to move forward. Depending on the relationship you have with the key stakeholders/business, a formal signoff process may or may not be necessary.

Level of Effort & Timeline - while not always necessary depending on the relationship with the company, providing a high level estimate on level of effort (LOE) and a timeline of how long the customization will take. LOE should include all project phases, including development, QA, code migration activities, and project management time. The timeline should keep into consideration the availability of resources, company holidays, version updates, and other factors that can impact the development, testing, and delivery of the customization. The timeline should be adjusted as the project priority changes.

Addition of Custom Parameters  - Additional parameters are often necessary for customizations, including reporting. Parameters may include items like a specific journal name to use when creating a general journal through a custom process, identifying customer groups to use, or even the main account to use for a transaction. Parameters allow us to create customizations that have the ability to grow with the business. For example, if we hardcoded a main account to use and the business changed the account structure or wanted to use a different main account in a new legal entity, additional development would be necessary to update the hardcoded values. Hardcoded values should always be avoided when possible and replaced with parameters to minimize the need for future rework.

Custom Design Elements - Screen mockups and a simulated step by step process of the design is heart of the FDD. Custom design elements include identifying what screens should look like, where new menu items will be added and what they should be called, and provide a complete explanation of how the custom process will work.

Use of Existing Functionality - Identifying existing functionality that is necessary for use in the customization is critical. While there is no development required on these elements, it is important to call out the dependency on them. Examples of using existing functionality include journals, workflows, or other standard functionality that is required to show a complete picture of the goal of the customization from start to finish. Including existing functionality that is initiates or is used in the middle of a customization is an important piece of information to ensure all elements are identified.  

Data Mapping - Identifying where data comes from and how different data components should interact with each other is another important piece of the FDD.  Developers may have more efficient ways to pull and combine data sources, but assisting with helping them to understands the interactions between the data is important. When calculations are involved, it is important that the documentation clearly identifies the order in which the calculation should be completed and also provides an example, especially in cases of multistep or complex calculations. Working with your development team, you will be able to identify the best data mapping strategy that works for your team.

Who will be using the new customization or report when it is completed? Do you need view access and maintain access to the new functionality to accommodate various departments? 

Identifying who will need access to use or view the new functionality is an important component when delivering the solution. There is nothing worse then sending an excited email to your key stakeholders that their customization is ready to test only to be met with a reply of "I can't find the menu item."

Not only should the security be created for users to test, but it should also be used during QA testing to ensure the users will not run into access issues when beginning testing. Security needs may vary by different groups of users. Depending on the complexity of the solution, there may be several layers of security for consideration. 

The rule of thumb to remember when creating a customization: if there is a new menu item, security is needed to access and secure the new functionality. If you don't know if the customization has a new menu item, ask your developers! 

Reporting as a result of a functional customization is not always required, but something to consider as you build out the process. While some customizations clearly need reporting, the reporting needs may not be immediately known until the customization is complete and users have a chance to interact with it. Adding additional requirements or project phases is not a bad thing. Flexibility in the design and delivery of the solution as a whole is necessary. 

Consider reporting during each phase of the project but keep in mind it may not be needed or is too early in the project to make that decision.