SDS Template

The SDS should provide a comprehensive explanation of how the system functions and how it has been configured or developed to support a specific phase. It should be updated and tailored for each phase accordingly. 1.Support new developer by helping them understand how the system is configured. 2.Serve as a reference for SMEs conducting initial assessments of ongoing changes, including effort estimation and high-level solutioning. 3.Assist in evaluating the impact of customizations during system upgrades. When documenting the SDS, it’s important to include the following key elements: 1. Out-of-the-box (OOB) components: Identify which standard features are being leveraged. 2. Customizations: Detail any enhancements or deviations from the default configuration. 3. Data Model (Tables): List the tables involved in the design and describe how they interact with other models. Reference the data dictionary to clarify which fields are used in the current phase. Any customized relationships between tables—especially those not part of the default OOB setup—should be explicitly highlighted. 4.Security Configuration: Explain how user access is structured, including distinctions between read-only and write permissions. 5.User Interface (UI): Include wireframes or UI screenshots that map back to user mockups to validate requirements. 6.Downstream Impact: Outline the effects of changes on related in-app models or data consumers. 7.External Integrations: Specify any third-party or external system interactions, such as issue management invoking the Archer API. 8.Logging and Monitoring: Describe how changes are tracked, whether through OOB mechanisms or customized tables.