In the terminology the terminology that I'm used to, your uses for the words don't align. However, there may be alternative definitions in use by other organizations.
In my experience, there are multiple sources that place requirements on a software product. The customer and users have requirements, which is what I would call "customer requirements". These are the characteristics of the system that the customer and the users deem necessary. However, requirements can also come from the business (the company producing the software), usually because of domain experience and insight into continuing to develop the product across customers. Requirements may also come from regulatory sources - governments, laws, industry standards.
The customer requirements may require grooming of some kind. Chances are, the customer won't hand requirements that are totally usable from a technical perspective. There may be inconsistencies, ambiguities, or incompleteness that needs to be resolved. However, even after grooming and buy-in, they are still customer requirements.
The engineering team takes requirements from these sources to develop the system (and subsystem / component) requirements that pertain to the particular product. These requirements are a refinement of the customer, business, and regulatory requirements. At the highest system level, they still need discussion and negotiation with the customer since business and regulatory requirements may conflict with customer requirements and these conflicts need to be resolved.
Functional requirements are simply a type of requirement. A requirement can typically be called a "functional requirement" or a "non-functional requirement". Non-functional requirements are also sometimes called "quality attributes". Any requirement (customer, business, or regulatory) could be functional or non-functional.
There are other things that may be included in requirements specifications. These are called design constraints - things that don't describe the functionality or characteristics of the software but impact your design. For example, if your customer only runs Windows environments, then the fact that your software is going to be deployed on Windows is a design constraint. Design constraints may also come from business or regulatory requirements, but usually customer or business requirements drive design constraints.
In your specific example, I would say that the user being able to enter data in a specific format is a user requirement. In order to maintain a product line or security needs, there may be business or regulatory requirements on data validation, data integrity, checksums, or hashing as well. Your system requirements would be enough information to someone to design and test a system. I'd call the use of Java and Oracle DB design constraints.