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.
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).
Best Answer
I would go for number two.
Functions in function definitions while they should be worded in business terms should be atomic. What I mean by that is "maintain customer data" could include add, edit, delete, archive, disable etc. etc. A in list of functions "delete the customer data" could mean only one thing.
This helps specify the system more exactly in discussion with users as they are liable to say things like "I didn't mean remove the customer form the file, I meant flag him as an ex-customer", which they might have felt was an obvious implication of "maintain customer data".