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).
Short answer:
830-1998 is not a standard, it is a recommended best practice on how to write SRS in the style of 1998.
I can't find how it was superseeded (even with IEEE's advanced search :( )
But I guess it's because the whole method on how we specify requirements has changed drastically in recent years.
So, from now on, I try to answer a bit of modified question:
What is the industrial best practice / What are the recommended best practices on writing SRSs in the style of 2012?
On classical methods:
Usually I use IEEE 1471 recommendations for software documentation, although that was also superseeded recently by ISO/IEC 42010. This is a very complex kind of documentation, it's mainly used for handovers, although it does contain the requirements mostly (it's chapter 7 in the new ISO style document)
A moderately good book on formal documentation is Documenting Software Architectures, a surprisingly good book is the old iconix book, and an old classic is Cockburn's Writing Effective Use Cases.
On how it is actually done in the industry today:
Truth to be told, formal project documentation, especially requirements documentation was killed off mostly in the age of Agile, as the Agile Manifesto discourages formal documentation. There is no one, single, large formal specification, but instead, there are so called user stories, product backlogs and such. This is because of iterative development, only a handful of features are specified informally for each cycle of 2-4 weeks. A renowned book is User Stories Applied.
There are so-called "executable" specifications, which are formal, since they are essentially domain-specific languages (DSLs) for testing. They are no better or worse than UML's OCL, but they're more easier to grasp perhaps but also less scientific. Most of them are called BDD frameworks, and examples include FitNesse, Cucumber, Jasmine - you'll find a big bunch of these. There are also renowned books on BDD and TDD in general.
Also, specification by software engineers was superseeded by UX design, including information architecture and interaction design, so it's not done by people who can actually code nowadays, which can lead to conflict sometimes. This is a not-so-bad example on how one looks like (it's not a standard!), but you'll find a lot more inside the UX / interaction community, but there's even a whole separate stackexchange site for them. They have their own standards, recommended best practices, etc.
But what if you want to stick with the old methods, eg. for university work?
In general, try to adhere to the IEEE 830 (can't find on their webpage what was it superseeded with, although IEEE was never good with this, I guess it's because it doesn't matter anymore unfortunately), and make sure you try to record useful information (eg, I don't think that a single actor stick figure -> single bubble with a verb-subject is considered useful) from which the overall goals of the users, the overall range of users and the overall methods of usage can be reconstructed anytime.
Why do you recommend books? Why don't you show me standards instead?
Again, I guess this document was "superseeded" because today, we have a bit of chaos around requirements specification: there are many-many viewpoints on how it should be done.
There is no single authority who is able to tell you: "this is how specifications should be made". There are best practices, and I tried to provide you with a representative list of documents and directions, albeit by no means complete, and perhaps personally biased.
At the end of the day, what matters is wether the document you create is able to fulfill all the goals all the people who ever read it have with it: what people want to see, what people need to know in order to understand the requirements are pretty well described in these books, and these are best practices on their own right, albeit in much smaller communities than a single, undivided IT community what we had perhaps in 1998.
Best Answer
Is there a standard for software requirements specification? As far as I know there are only recommendations, and no formal standard for the SRS document. Therefore there won't be a standard for requirement ID's.
What you're describing is called the ID of the requirement. Each requirement should have a human readable name as well that helps humans identify the general purpose of the requirement at a glance. The only requirement for software requirement ID's is that it is unique in the spec that defines it and that it doesn't change after it's assigned.
Apart from being unique in the spec, it may be useful for the ID to be unique across all of an organization's products and for the ID to identify what product or whether the requirement is functional or nonfunctional. That way by looking only at the ID it can help you determine which spec the requirement would be in, and it allows for better requirements traceability, issue tracking, and project management. It's not important for requirement ID's to be strictly sequential. You'll often remove requirements, and you shouldn't try to maintain a number sequence.
IEEE recommendations reference requirement ID's:
Here is a template that uses ID's. You can find examples in 3.2.3.1