If you are producing a software requirements specification (SRS), I would expect that both GUI requirements and design constraints would be captured in that document.
In ISO/IEC/IEEE 29148-2011, the outline of the sample SRS says that the section for design constraints is used to "specify constraints on the system design imposed by external standards, regulatory requirements, or project limitations." The section on user interfaces is designed to contain "the logical characteristics of each interface between the software product and its users" and includes "required screen formats" and "page or window layouts" among other things as well as "all the aspects of optimizing the interface with the person who uses, maintains, or provides other support to the system".
If you look at previous iterations of the SRS standards, like IEEE 830-1998, you'll find multiple ways to structure the document. On top of that, many organizations may not produce a software requirements specification document, but keep their requirements in another format.
I wouldn't consider your examples to be examples of good software requirements. Both the statement that "requires" a three-layer design and the one that "requires" a tree object are design decisions.
In my experience, examples of design constraints include the use of a particular programming language or framework (or versions thereof), a specific operating system, or references to a standard reference architecture (and this reference architecture may, for example, levy requirements of three-layer architecture on the application). Examples of user interface requirements tend to require compliance to user interface style guides (for example, requiring a mobile app to conform to either the mobile OS style guide or the company's style guide).
At the end of the day, the requirements should be characteristics that the software must adhere to or it will fail to accomplish the stakeholder needs in the current environment.