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.
Best Answer
One strategy:
There are other strategies, such as using dotted decimals to cluster requirements, for example:
As you might guess, the respective requirements should be ordered under the top-level number accordingly: 1.1, 1.2...for GUI, 2.1, 2.3, 2.4 for DB, etc. Note that this strategy will need some form of controlled method for managing deletions and additions.
The key thing to enforce in a requirements document: once an ID has been used for a requirement, it cannot be used again different requirement. In other words, if SRS 1234 was used and then deleted, it cannot resurface later. (Allowing it to do so wreaks absolute havoc on requirements traceability over the course of an evolving project.)
Note that virtually any SRS organization/structure will have deficiencies. Pick the one that suits your development environment and your application needs. (For example, the strategies above work reasonably well in highly-controlled development environments, such as those monitored by the FDA or other governmental bodies.)
Finally, consider using a requirements management tool. There are good ones out there (open source to $$$$$) that will take care of all of this for you.