There are many different ways that things can be structured, but this is one take on it:
System Requirements Specification (SyRS) : This is the high-level engineering document that enumerates the requirements on how the system is to function. It is not a software-only document; if the system involves hardware, or multiple software components, then it describes them as well.
Software Requirements Specification (SwRS) : This is a complete description of the requirements of a single software component.
Either of these two documents could be called a "functional specification". It depends on the scope of what you are talking about.
UPDATE: Generally, the SyRS should only contain those requirements / functional specifications that apply to the system as a whole. A greenfield SyRS does not decide what the system architecture is; that is for the design document.
The design document (call it System Architecture Document, SyAD) decides what software components are required and how they interface to each other.
The SwRS for each defined component is then a much more detailed functional specification of how each individual component works.
Sometimes, to ensure consistency of UI for example, it makes sense to bundle common requirements into the SyRS.
This can get confusing, but the test plan and test cases for each software component should pull the appropriate specifications from the appropriate place(s).
Requirements management tools like DOORS allow cross-linking between requirements docs (and traceability from product concept to final delivery).
Does Functional Requirement Specification talk about system design?
No, that should be handled by a design document.
should there be a single system requirements document and individual SRS for all the applications?
Yes, that sounds like a good way to proceed.
I also assume that functional requirements strictly deals only with requirements and not the design
Yes, the two are distinct, but people often confuse them.
Could each line of a pseudo code be defined as functional requirement eg: System B must pass emp id , name to System C on receipt of request from System A.
The example you quote certainly sounds like a system-level functional requirement. Just be careful not to include in the SyRS something like "and emp id must be in the form of a GUID". The only reason to include technical detail like that in an SyRS is if there is some constraint on the system (like all incoming or pre-existing emp ids are GUIDs).
Where I am getting this from is from the approach to Systems Engineering called the "design V" (sometimes the design W). See Wikipedia for more, though in an "Agile" world some of this gets forgotten.