What you are looking for is traceability.
Whether you use old-school waterfall or more modern iterative approaches, a unit of functionality necessarily follows a simple process:
- Define business requirements.
- Define functional requirements.
- Define technical requirements.
- Design the software. <-- You are here
- Implement the software.
- Test the software.
At each step of the process, you should be able to trace your requirements back and forth between steps.
Each functional requirement (the system shall have function X) must be traceable to a business requirement (we need a system to do X). Note that a business requirement is normally high level and spawns many functional requirements.
Each design element traces back to a functional requirement. E.g. the form elements on this screen all support functional requirement X. All of the data requirements in this functional or technical requirement are satisfied by this screen or interface.
When you have 100% coverage throughout the whole process, you know your design is functionally complete.
But wait! Can the design be implemented reasonably? The key here is collaboration. This is where design reviews come into play. Get the key players involved: customer, project management, developers, and QA. Can the design be implemented? Can it be tested? Does it really satisfy the requirements? Once the team comes to a consensus, you are likely done with the design.