2 added 1138 characters in body
source | link

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:

  1. On the list of selected devices, device can be repeated.

    • Clearly a functional requirement. Describes what the system's output looks like.
  2. 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?
  3. 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.
  4. 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).

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.

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:

  1. On the list of selected devices, device can be repeated.

    • Clearly a functional requirement. Describes what the system's output looks like.
  2. 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?
  3. 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.
  4. 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).
1
source | link

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.