Verification: Did we build what the customer asked for?
Validation: Does what we built work?
Edit For Clarification:
"yet testers use functional spec for their test cases"
Who cares if the testers use the functional spec they are still performing both Verification and Validation based on my original statements.
There are supposed to be three switches and two buttons on this wall. (verification)
The switches are supposed to be equi-distant apart and 48 inches off the floor (verification)
The buttons are supposed to be on either side of the switches (verification)
The left button is supposed to be labeled "Left" (verification)
The right button is supposed to be labeled "Right" (verification)
If I click the left button on, does it disable the far right switch? (validation)
If I click the left buton off, does it enable the far right switch? (validation)
If I click the right button on, does it disable the far left switch? (validation)
If I click the right button off, does it enable the far left switch? (validation)
If I click both buttons on does only the middle switch work? (validation)
Given the lack of this document how are we supposed to prove that the
system does or does not do what it's supposed to to an auditor?
Why is that a given? There is no rule of scrum that the only thing created is software. Make your acceptance criteria include "done when we have a detailed ISO 9001 compliant functional specification". Or, make that a separate story altogether: "as a developer on an ISO 9001 team, I need a functional spec so that our software is compliant". Create the spec, and then from that you can come up with the stories necessary to implement that spec.
In the comments to this question, @Pete expressed concern that if the spec were a story, how can the product be "potentially shippable" if all that is delivered after an iteration is a spec?
Look at it this way: your end product is composed of many pieces: A, B, C, D, etc. At the end of each iteration you should have one of those pieces finished and potentially shippable, right? When A is done it should be potentially shippable. When B is done it should be potentially shippable, and so on.
Where does it say that A must be a software product? A can be potentially shippable even if it is simply a functional spec, or a test case, or a DB schema, etc.
Don't look at your functional spec like it is somehow outside of your product. Instead, see it as an integral part of the product you are delivering, on equal footing with software, DB schemas, test cases, user guides, etc.
Best Answer
Disambiguation
System Requirements (used in systems engineering)
Software Requirements (used in software engineering)
Main Answer
System requirements outline the requirements for the whole system. A system is a set of hardware and software to support a specific business need.
Software requirements are only concerned with software. They are much more detailed than system requirements, so that the software can be actually built from these.
The Software Requirements Specification (SRS) is a standard: IEEE 830-1998. Functional requirements are a part of this standard.
Functional specification is a separate document which is no longer used today (at least in Software Engineering). It was a standard at times when waterfall was used as the best-known technique, and before the IEEE Software Requirements Specification became a standard. The SRS has replaced it because functional requirements are now defined as a part of a larger document (software requirements).
At the dark times of software crisis, I believe that functional specification was the best they knew (without all these amenities the full SRS gives us). They thought software requirements specification is only a specification of required functions. Today we know there is more to it. (see the SRS)
History and Current Use of the SRS
The SRS is from 1998 and it wasn't meant for OOP. I've used it in my company, but only as a basis for customization. Instead of describing functional requirements using natural language, like the old functional specification document, I've used UML (use case diagrams). This is something that wasn't considered by 1998 yet, so that engineers still described the needs quite inefficiently.
Conclusion
Functional specification is a part of the software specification document. The document is useful, but I wouldn't recommend adopting it as-is because it was defined in 1998; instead, I suggest considering UML where appropriate to replace natural language specification.
References
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=720574
http://en.wikipedia.org/wiki/Software_requirements_specification
http://en.wikipedia.org/wiki/Use_case
http://en.wikipedia.org/wiki/Functional_specification