Im deriving the functional requirements from a Edit User Account use case but I dont know if Im doing this corretly.

The use case is this:

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 on step 2 of the main flow.

Invalid Email

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

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


User account edited.

The functional requirements Im getting from this use case are:

  • The system must allow the user updates his user account.

  • The system must ensure that the user fill are mandatory fields to update his user account.

  • The system must ensure that the user insert a valid email to update his user account.

  • The system must ensure that the password has at least 6 characters long for the user update his user account.

  • the system must alert the user when he tries to save is account information inserting an email in a invalid format.

  • the system must alert the user when he tries to save is account information and dont fill are mandatory fields.

  • the system must inform the user that his account information was updated with success if he submits the form with success.

  • The system must inform the user that the password must be 6 characters long if he inserts a password with less than 6 characters.


Do you think this can be a way of writing functional requirements? Im with some doubts about how to write them. For example:

1- The first requirement is a functional requirement? Because it seems an obvious requirement but maybe its a functional requirement because its testable. We can test if the system allow the user to update his account right? So it should be a functional requirement.

2 - The second requirement we should specify what are the mandtory fields? For example email, etc?

  • 1
    First, why are you doing this? A use case is, like requirements specification, a way to document the requirements. It seems wasteful to simple convert between two methods of documenting requirements that are generally equivalent. Second, why the ambiguity? What "the data" is the user updating? What validation rule(s) are applied to what fields on the form? What fields does that form have? Which of those fields are mandatory?
    – Thomas Owens
    Commented Jun 9, 2017 at 8:57
  • Thanks for your answer. The use cases isnt a way to specify user requirement and from these use cases we can get the functional requirements? And in the use cases im using "the data" because we shouldnt specify ui components, labels and so on in the use cases right?
    – OZy
    Commented Jun 9, 2017 at 10:26
  • The use cases isnt a way to specify user requirement and from these use cases we can get the functional requirements? Use cases are one method of specifying user requirements. User stories with associated acceptance criteria are another. A specification (often a list of "shall" statements) is yet another. All of them should be written in a way that lets someone design, build, and software against - translating between them is a wasteful activity.
    – Thomas Owens
    Commented Jun 9, 2017 at 10:35
  • 1
    im using "the data" because we shouldnt specify ui components, labels and so on in the use cases There's a difference between specifying what the data is (dates and date formats, numbers and ranges, text and text quantities, a specific set of options) and the UI components (text box, text field, radio button, combo box). Specifying what needs to be gathered and what validations are applied are not UI but data inputs and transformations required by the system. How to capture and validate the data is a design activity, but the data needed and validation rules are requirements.
    – Thomas Owens
    Commented Jun 9, 2017 at 10:38
  • Thanks again. But if the use cases are a way of specifying user requirements and not functional, we dont need also to identify the functional requirements?
    – OZy
    Commented Jun 9, 2017 at 10:42

1 Answer 1



In this Q+A's comments, the Q to which this A belongs has been described as "entirely based around / founded on misconceptions" and "not warranting an answer". Furthermore, this A has been described as "wrong", "furthering the Q's misconceptions" and "spreading poor information to people who find it".

Trying to filter out professional arguments from the criticism, one might say there were two categories.

  1. Deriving Functional Requirements from Behavioural Requirements (emphasis mine)...
    • "seems wasteful" because both "are generally equivalent",
    • "translating between them is a wasteful activity", because "they should be written in a way that lets someone design, implement and [test] software against",
    • "never makes sense" because "both capture the same information" and a "Use Case can also at least [cover / capture] some quality attributes of the system in addition to functionality",
    • is "never" done, because "their only difference is their representation",
    • "is a waste without decomposing" [them],
    • "should be avoided when possible".
  2. Other methodological points of subordinate interest for my edit, e.g. about the difference between deriving and decomposing lower level requirements from higher level requirements (and when they are decomposed instead of derived then that's not wasteful).

I see the points under 1. as slightly inconsistent, and while I might agree to the "seems" and "should be avoided" parts under certain circumstances and regarding the docuemnt situation, I do not at all agree to the "never" and "misconception" points. Therefore, here is my introductory explanation for the, well, people who find it.

  • If it were true that Functional Requirements are "never" derived from Behavioural Requirements (Use Cases), then the person who has to "design, implement and test" against these Use Cases...

    • can only hope that they "should be written" in a suitable way for this task and
    • will often (silently) derive Functional Requirmenets from the Bahavioural Requirements on-the-fly, which requires certain analytical skills, and it wouldn't hurt to train them.

    And that was the OP's intention, as he clearly stated and which I clearly repeated in the first sentence of my answer.

  • Even if Behavioural and Functional Requirements might be generally equivalent, ...
    • there are roughly two ways to denote Use Cases, name as a (UML) diagram or textually, and they show different strenghts and weaknesses,
    • consider Regular Expressions and Finite State Machines, which are proven to be equivalent notations, but in some cases one has a representation whis is by order of magnitude more efficient than the other -- and wouldn't it be wasteful to not use the more efficient notation, and is there no need to consolidate a mixture of Behavioural and Functional Requirements before decomposing them?
  • In this regard, let's look at reality:
    • Good luck trying to force your customer to provide an unambiguous, clear, complete specification which sticks to a single notation.
    • In some areas / indistries, you are obliged to counter your (ambiguous, unclear, partially redundant and partially incomplete, layered) specification with a reworked one, and this step does involve consolidating all the open points, where a comprehensive, uniform notation really helps a lot, especially if it uses a slightly lower level from where a better technical understanding can be reached and which makes decomposition easier.

In my view, requirements analysis can't be trained enough, and your enviroment will always provide you with specific instructions what to do how and when.

I see a big value in this Q+A and its clarifying discussion. The OP did not provide any more context information than that he wanted to train how to "identify and specify" requirements. From my experience, I wish more people would train this -- even if Functional Requirements are not written down after deriving them from use cases, I have witnessed many discussions where it would have helped if it had been done.

End of Edit

Now that I know you're doing this to get some practice, and since it makes sense in many situations to derive Functional Requirements from Use Cases:

Use Case

Some points.

  • Align "User" and "Admin" by either using only one of the two notions or connecting them via a "role" or something similar.
  • How do steps 4 and 5 of the main flow relate?
  • Post conditions: How about having a post condition for the main flow as well, and not calling it "profile edited" but "profile updated with validated and minimal data" or so?


  • Use Cases should not be too detailed. Whether or not you need to mention the required data here depends on a few factors, such as redundancy, mainainability, clarity, and context. If this is for a tender, you can have the supplier present you a specification of the data model they assume for their offer. If the specification is supposed to be complete, you need to specify the data model somehow, and then again, a sketch of the user interface with mandatory fields being marked could serve two purposes at the same time...
  • If you derive Functional Requirements, then a requirement may seem obvious, but it's not. Keep in mind that people will look at specifications from different perspectives -- if you don't specify it, you won't get it.

Your Functional Requirements

Syntactically, they're better than many which I've seen.


  • Regarding the implementation, there is a huge difference between a "valid e-mail address" and a "valid e-mail address format". A valid e-mail address is one which is actively confirmed. Stick with one term, don't mix them, and possibly even define the term in a glossary.
  • You distinguish between frontend and backend in a way (ensure vs alert), whcih is good, although I believe it can be simplified and made clearer.
  • You mention the acceptance criteria for the password (6 characters) twice, which is not such a good idea. This is difficult to maintain. Imagine this has to be changed; how can you be really sure you updated all occurences?
  • You invented a password security (well... sort of...) requirement. Yes this makes sense, but where is it coming from. Now it depends on the context. If you are deriving these requirements formally for the same organisation where the Use Cases were written, there should be a kind of internal standard specification you should refer to, so formally, you're not deriving this requirement from the Use Cases (as you claimed) but from another standard specification for such systems. If you're working for a supplier, analyse a potential customer's Use Cases and cast this requirement into existence, it should also come from an internal standard specification, but even if not, you're going to present this to the customer and say that you added it because your organisation finds it essential. Either way, it's not derived from the Use Case.
  • Dear downvoter, I would have appreciated a comment. ;) Commented Jun 9, 2017 at 15:19
  • This answer is wrong. It never makes sense to decompose a use case into functional requirements. That concept doesn't even make sense. They are two methods of capturing the same information. In fact, I'd argue that a use case can also at least some quality attributes of the system in addition to functionality provided. You can see the comments on the question, but the entire question is based around misconceptions. This answer just furthers those misconceptions.
    – Thomas Owens
    Commented Jun 9, 2017 at 15:25
  • Hello @ThomasOwens, nice to meet you. Your answer is valid for a certain range of industries. I'm kindly asking you to undo your downvote, because your judgement is inapplicable for the general case. I have asked the OP for his context / industry and he replied that he's doing this to get some practice. I also read your comments but neither they nor your reputation mean that you're right and I'm wrong. As an example, kindly consider ISO 26262, which requires system engineering, which requires lower level requirements being derived from higher level requirements, maintaining full traceability. Commented Jun 9, 2017 at 15:43
  • No, I won't undo my down vote. I'm very familiar with traceability from higher to lower level requirements, but that has no bearing here. It's conceivable that higher level requirements may be expressed in one format (shall statements vs a use case) and lower level requirements expressed in a different format. But this is not a case of systems requirements being decomposed into software requirements (for example). This answer only serves to spread poor information to people who find it. The entire question is founded on misconceptions and does not warrant an answer.
    – Thomas Owens
    Commented Jun 9, 2017 at 15:46
  • @ThomasOwens Please excuse me, if you are familiar with a situation where use cases on a higher level are decomposed to textual requirements on lower level, then what exactly is your criticism if someone is practicing this, and what are the main misconceptions which you see in this Q + A? I really want to understand this, and the same is certainly true for OZy. Commented Jun 9, 2017 at 15:52

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.