@Dr Herbie:

"As a [user] I want to [be able to change my password, once logged in, using my existing password for verification,] so that I can [better protect my user security myself]."

I was looking at your 3 item list and wanted to use it to show just how much more clear the requirement becomes when using the sentence structure from Agile - SCRUM.

Personally, I tend to read one line at a time. In fact, since these are all related to the same feature, my understanding of one line may affect my understanding of another of the lines. That came out poorly, what I mean to say is that all those lines can be put into one clear statement instead which will only serve to clarify and streamline comprehension of the requirements for all involved.

Why John doesn't approve of Herbie's list as requirements document: Angel

  1. The first part, [role], specifies who the feature is targeting; admin, regular users, etc... A developer will either have to make an assumption here or ask for more information if this is not included. So you can see that the sentence structure itself already protects against ambiguity and confusion.
  2. The second part, [action], is rather verbose, but that isn't a bad thing. Features will often require more than one 'sentence' or requirement. This feature, for example, leaves admin's password requirements to be defined, as well as the "I forgot my password" user scenario... More sentences. 
  3. Notice the last part, [result], shows the 'why' for a requirement. Omitting this "reason for a requirement" allows features to be implemented without considering their value to the system. In addition, requirements can be ordered by importance when their value is assessed.

Herbie's list should do fine as an integration test list, but I would have it be derived from the "User Stories" which are compilations of multiple sentences with the structure described above.