For example, for a site like Ebay we can identify these requirements:

  • Search Products

  • Add product to cart

  • Buy product

  • Add to favorite

  • Edit user account

  • Add comment

  • Remove comment

  • Close session in the system

  • Start session in the system

Are the requirements above considered functional?

If they not, then if we add to each one of these requirements a use case, can the use cases that describe each one of these requirements be considered functional requirements?

For example, for the edit user account requirement, the use case is:

Title: Edit user account

Pre-conditions: The admin is authenticated.

Trigger: The user wants to edit his account.

Ator: User

Main flow:

1- The system presents the saved user account data to the user.

2- The user updates the data he wants.

3- The system validates the form.

4- The system informs the user that the information was updated with success.

5- The admin chooses a list option


Alternative Scenarios:

Empty fields

1- The system presents a message informing the user that he must fill all mandatory fields.

2- The flow continues onto step 2 of the main flow.

Invalid Email

1- The system presents a message informing the user that the email has an invalid format.

2 - The flow continues onto step 2 of the main flow.


User account edited.

With this use case, can the requirement "Edit user account" be considered a functional requirement?

  • To me, your examples look like use case titles, not functional requirements. What does a system do? As written, "edit user account" isn't a behavior of the system, nor is it a property; it's something an actor might do with the system, though, which makes it a use case.
    – Todd A. Jacobs
    Commented Jun 10, 2017 at 17:24

1 Answer 1


Having followed the discussion in the context of your previous post, I want to make a few points.

Use Case vs. Functional Requirement

The bullet points in your question, intended as examples referring to eBay, are not Functional Requirements by themselves. "Add Product to Cart" is not a Functional Requirement. It is, however, a potential title for a Use Case. A fully specified Use Case is a Behavioural Requirement. Functional Requirements can be derived from Behavioural Requirements.

In other words, one Use Case often represents several requirements, and several Use Cases often share a common subset of Functional Requirements. E.g. "The system shall provide an authentication mechanism for users" is a Functional Requirement, and there will certainly be several Use Cases which refer to it.

Non-Functional Requirements

In your earlier Q, you indicated that you think that requirements which can be tested are Functional Requirements. This is not exactly true. Non-Functional Requirements can also be tested, the worst case being methodology / process audits, code reviews and the like. But there are also Non-Functional Requirements which can be observed while the system is used, and hence, they can be tested.

Derivation of Requirements From Use Cases

Functional or not, do you have to derive requirements from your Use Cases? It depends. Do you want to derive requirements from your Use Cases? Maybe.

Do your Use Cases cover all aspects of your system?

Let's say your system has a user interface with authentication mechanism and different access rights. Would you accept a solution where rights must be set per user, or would you want groups or roles to define the rights and add users to groups? Would you be willng to accept a system where roles / groups are fixed, or would you want to be able to add roles / groups? -- Yes, you can write Use Cases for that.

However, already here, we're touching the question: When is a specification ready?

In reality, it's never ready. In reality, it's inefficient to strive for a perfect specification. In reality, specifications stop at a level of "common sense" (with developers, suppliers etc).

So since role and rights models are common for decades, and since the administrator is not your valued customer to whom you want to present a flawless user interface, would you net be able to finish your specification earlier if you switched from Use Cases to Functional Requirements?

Taking it one step further, would you be willing to live with a system where a change of the access rights becomes valid only the next calendar day?

If not, you're going to have a requirrement such as "The system shall perform each operation applying the relevant settings which are valid at the respective point in time."

Clearly a Functional Requirement. And now, if you have only Use Cases, you'll have to expand each of them textually. If you have UML Use Cases, you might want to cover this by an include, but this requires that you place a kind of a "basic operation" there which starts by checking the current access rights.

This is not what Use Cases are for. This is not their strength. You want them to be comprehensive and concise. Use Cases are not the place to describe detailed operations or functionality. And the access rights checks are very basic. You want to specify it in a single prominent place.


Much depends on the context.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.