Edit
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.
- 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".
- 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?
General
- 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.
Formally:
- 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.
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.im using "the data" because we shouldnt specify ui components, labels and so on in the use casesThere'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.