B. Put the business purpose in the Description of each field.

Including the business purpose or the requirement that justified the creation of each field in its description provides immediate context directly within Salesforce. This practice helps anyone reviewing the field in the Salesforce setup to understand why the field was created and which business requirement it addresses, facilitating better maintenance and future updates.
C. Maintain a data dictionary with the justification for each field.

A data dictionary is an essential documentation tool that provides a comprehensive overview of each field, including its name, type, purpose, and the business justification for its inclusion. By maintaining a data dictionary, the architect ensures that there is a centralized reference point that can be used to trace configuration changes back to detailed requirements. This document can be updated with each phase of the rollout to reflect new changes and requirements.
The other options:

A. Review the setup audit trail for configuration changes. While the setup audit trail records who made what changes and when, it does not typically provide the why, meaning it does not directly link changes to the detailed business requirements or justifications unless such information is systematically included in the change process, which is uncommon.

D. Use the Force.com IDE to save the metadata files in source control. Saving metadata files in source control is a best practice for tracking changes over time and can help in understanding what changes were made. However, without proper documentation or comments linking these changes to business requirements, it's challenging to trace these changes back to the specific requirements they were meant to address. This method is more about version control and less about documenting the rationale behind configuration changes....