There are typically layers to requirements, especially if the software is complex or when specifying a system that includes both hardware and software elements. Depending on the complexity of the system, you can have any number of layers.
I do disagree with your definitions, however. Requirements always address what the system does (functional requirements or behavioral requirements) or criteria used to assess the system (non-functional requirements, non-behavioral requirements, or quality attributes). They have different source and different levels of granularity, but all meet the characteristics of a good requirement.
The first source of requirements is what I would call the "customer requirements". These are all requirements that come from the customers that are paying for the design and development of the software or the people who will be using the software. These would typically be expressed using the domain language of the customer and users. Often, these would need to be translated into more technical requirements that can be designed and implemented.
Rules, laws, and regulations also provide a source of requirements. I usually hear these referred to as "regulatory requirements" or "compliance requirements". These may or may not be explicitly identified by customers or users, or may be identified at a high level (such as referring to a law or regulation that must be adhered to). The specific regulatory requirements would identify specific behaviors or attributes of the system that can be traced to a regulation or law, but aren't present in the customer requirements.
Another source of requirements would be the "business requirements". These are requirements that are levied by the developing organization. Perhaps there is an overall strategy by the development organization to achieve a product roadmap. In order to follow this roadmap, additional constraints must be put on the design of the software.
There may be conflicts between these higher level requirements. One step of the requirements engineering process is to analyze the requirements and negotiate around conflicts to achieve a set of requirements that can be designed and implemented. Customers may not be fully aware of some regulations that the development organization is aware of. The customer desires may conflict with a product roadmap of the developing organization. These issues must be resolved by the requirements engineers.
All of these top level requirements are likely to be written in domain-specific language that may not be suitable for design and test. All of the next layers of requirements would be far more technical in nature. However, how many layers you have depends on the complexity of the system.
In a more simple software system, you can combine your user requirements, regulatory requirements, and business requirements into a single set of software requirements. In this example, you would only have two layers of requirements.
In a complex hardware/software system, you may have multiple levels, consisting of system requirements that describe the complete hardware/software system, and then separate requirements for different components. Depending on the complexity, if you have multiple components, you may have sets of requirements on subsystems and components. However, any grouping would be for the management of the requirements and products.
Wikipedia also has a slightly different set of types of requirements. However, that list is a cross between level and type.
I would recommend checking out some resources on requirements engineering for a lot more detail. Personally, my top choice would be Software Requirements, which is now in its third edition. I have heard positive things about Managing the Requirements Process as well, though.