The actual document format doesn't really matter. Something as simple as a bulleted list would work, all the way to something full of workflows, charts, and images.

This is a simple, unambiguous sentence structure for requirements that is used in Agile development methodologies like SCRUM.

I recommend it because, with this structure, a savvy coder can get their audience/users to draft the requirements themselves -- and there is no better way to stay on the same page and get it right than this way.

So once more:

"As a [role] I want to [action] so that I get [result]."

E.g.

1. The system must require the user to log in with a unique username and a password.

2. The system must supply an option to allow the user to change their password once they are logged in.

3. When changing a password, the user must supply their existing password as well as their new password.

...

Break it up into sections based on functional areas so it isn't too overwhelming.

In this format it's easy to do through the list and check off each item when testing.  It can also form the basis of the user's sign-off when the system is complete.

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:

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.