The two concepts customers must be clear on before embarking on web application development are user management and work flow. Both are naturally linked and easily ill-considered. Specification diagrams of course are essential. While the details shouldn't be ignored (or assumed), the presentation of the logical flow should be as simple as possible.

For example, a publishing house with writers, reviewers and publishers would like an application that enforces roles and centralises their effort. The first thing that must happen is an agreed model of the required work flow - the traditional 'back of the napkin' diagram. Cleaned up, and rendered in a faux-UML format, it might look like this:

The first thing you will notice is that it is very ugly. The second, it's a mixture of process and condition/state. Third, actions are dependent on roles. It's a simple work flow, easily held in the mind in its entirety.

From this diagram, a list of effective rules can and should be extracted, this would help to clarify and confirm. No matter how evident a diagram is thought to be - ambiguity will creep in.

That which is not possible is not listed e.g. there are no 'cannots' otherwise, you might be tempted to state 'Users cannot ascend to heaven astride a winged horse'.

[This may seem (and is) tedious but can be automatically generated in English (of sorts) from a suitably formatted UML schematic.]

A created article is automatically submitted.

A writer can create an article.
A writer can edit a submitted article.
A writer can delete a submitted article.

A reviewer can perform all the functions of a writer.
A reviewer can approve a submitted article.
A reviewer can retract an approved article to submitted.
A reviewer can edit an approved article.
A reviewer can delete an approved article.

A publisher can perform all the functions of a writer.
A publisher can perform all the functions of a reviewer.
A publisher can publish approved articles.
A publisher can retract a published article to approved.
A publisher can retract a published article to submitted.
A publisher can edit a published article.
A publisher can delete a published article.

There is a certain flavour of exponential growth with these terms of course, but impact on understanding is minimal as long as inheritance is made clear. All of the terms are self contained and can be recited as a reflex when challenged.

Additional facts can be added to the list which may be helpful as a general illustration of the application at large. E.g.

There are 3 users
There are 3 roles
Users can have more than one role
Etc.

All of this is to make the intention of the application's work flow understood by a customer of whom no assumptions are made. It is my firm belief that when a customer grasps their own business logic and 'rules' as laid out in a specification, ambiguity can be massaged away, and change control can be clear-cut.