In the context of requirements engineering, the concept of a “system requirement” is referring to a level of decomposition. In a sufficiently complex system, you could have any number of components (where a component could be hardware or software elements). Each component would have its own requirements, usually derived from the system requirements, that can be used to verify the behavior of the component in isolation prior to integration and verification and validation of the system as a whole throughout the integration process.

In the comments, Robert Harvey mentions another type of “system requirements”: the required characteristics of the system that the software is being deployed on. These often include the hardware, operating system, and maybe even software dependencies. These would often be based on the technical system requirements that I mentioned above.

A functional requirement is a definition of a result of the system. The set of functional requirements on a system or component define what the system does. The opposite of a functional requirement is a non-functional requirement, which define attributes of a system, such as reliability, fault tolerance, documentation, security, testability, etc.

System requirements can be functional or non-functional, and define the behavior and attributes of a set of components.