Functional requirements define what the system or application will do - specifically in the context of an external interaction (with a user, or with another system).
When placing a new order, the system shall display the total cost and require confirmation from the user. That is a functional requirement; it describes a function of the system.
Refer to Wikipedia: Functional Requirement for more details.
Non-functional requirements are any requirements that don't describe the system's input/output behaviour. Note that we are still talking about requirements, not implementation details, so just because we're using the phrase "non-functional" doesn't mean that anything is fair game to put in that section.
The most common types of non-functional requirements you'll see relate to system operation (availability, continuity, DR), performance (throughput, latency, storage capacity), and security (authentication, authorization, auditing, privacy).
These are all cross-cutting concerns that impact every "feature" yet aren't really features themselves; they're more like feature metadata, helping describe not just whether the system does what it's supposed to but also how well it does it. Don't take that analogy too far, though - it's just an analogy.
Non-functional requirements are not subjective or hand-wavey, contrary to what some people here seem to be suggesting. In fact, they should actually have a hard metric attached to them (i.e. response time of no more than 100 ms). NF requirements are also not implementation details or tasks like "upgrade the ORM framework" - no clue where anyone would get that idea.
More details at Wikipedia: Non-Functional Requirement.
To specifically address the examples in the question:
On the list of selected devices, device can be repeated.
- Clearly a functional requirement. Describes what the system's output looks like.
Database must contain at least 100 items
- Sounds like a business rule, so also a functional requirement. However, it seems incomplete. What is the reason for this rule? What will happen/should happen if the database contains fewer than 100 items?
Currency of some value must be in USD dollar.
- Functional requirement, but not really a properly-stated one. A more useful wording would be: The system shall support one currency (USD). Obviously this would be amended if more than one currency needed to be supported, and then the requirement would have to include information about currency conversions and so on.
Device must have a name and power consumption value in Watts.
- Not really any kind of requirement, this is more like a technical specification. A functional requirement would be stated as the power rating is assumed to be in Watts. If there's more than one UOM, then as with the currency, the functional requirements should have sections about unit conversions, where/how they are configured, etc. (if applicable).
Disambiguation
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
Best Answer
I think that you are thinking about this a little too hard. Functional and non-functional requirement are not really as separable as you are suggesting, Take the login case for example.
The user SHALL be able to log in through a web interface. Technically, this is a functional requirement.
The system MUST respond to log in requests within 1 second. Technically, this is a non-functional requirement.
Either way they are both just as important regardless of specific classification.
Requirements can come from any number of places. You might want to have better performance than a competitor. A customer might have specific needs. There might be a request from marketing or sales. There isn't one place were they come from. Though, you could probably abstract away all the different sources and refer to them as customers. Ultimately that is what they are.
You can identify the difference using the following metric. Functional requirements describe what a system will do. A non-functional requirement specifies how it does it.