The following are some dos and don'ts while writing FDDs:

• Do not repurpose the unfit features to avoid customization. You will end up causing unforeseen issues down the road or blocking any future use of the functionality related to the feature.
• Do keep the architecture simple and easy to follow. The more complexity you add to the solution, the more difficult it will be to implement and support.
• Do try to reduce the duplication of data in multiple places; avoid unnecessary/complex integrations.
• Do design the solutions around standard functionality, without touching the core system. For example, if the customer wants to automate the creation of allocation journals based on the allocation rules defined in the general ledger module, as a functional consultant, I will design a separate customization that will extend the functionality of the core Finance and Operations allocation process rather than changing standard forms and features.

After the functional design document is completed and signed off, the development team needs to start writing a TDD. Let's learn about the TDD in the next topic.