This lesson from Yale's Introduction to Medical Software course examines the Software Design Document, the artifact that translates high-level system requirements into instructions a programmer can actually code from. The instructor walks through the steps of building one: reviewing requirements, defining architecture, and specifying interfaces and data flows in enough detail to remove ambiguity before implementation begins. Particular attention goes to regulatory expectations for medical device software, including how teams document and justify their handling of Software of Unknown Provenance, third-party or legacy code whose origins and testing history are not fully known. The lesson also covers why interface design choices matter for safety, since a confusing screen or ambiguous control can lead a clinician into error. It is a short, practical session aimed at engineers who need to connect specification documents to code that will eventually run in a hospital setting.