IME, system specs define the hardware and software environment that the new application will operate in, while functional specs define what the application will do (my experience may not be typical, however).
Design documents are a different animal. They define the structure of the application, breaking it into components, specifying the implementation of each component, the interfaces between components, the order in which components perform their operations, etc. ("component" is meant to be a very high-level, abstract term here; it could correspond to classes, modules, or even individual functions or methods). Design documents also often have a "traceability matrix" showing which requirements are satisfied by particular elements of the design.
For a stupidly simple example:
System specification: The application will run on Linux as a command-line app in a bash shell.
Functional specification: The application will print the text "Hello, World" to the console and then terminate.
Design document: The application will be implemented as a single C program consisting of the function
main, taking no arguments. Upon entry, it will call the standard library function
printf with the string literal "Hello, World\n" as its sole argument. After the
printf call, the application will return a 0 to the execution environment.
The "design document" isn't usually so detailed as to specify individual lines of code, but you should get the idea.