Acceptance Tests are very similar to the Functional Tests. And they actually are the Integration Tests.

The main idea of the Acceptance Tests is to create Executable Specification (Spec) for the project. And that Spec will be readable by humans and machines. So ideally it could stand in place of requirement documents. To generate document all we need is just run Acceptance Tests with an parameter. Such reports could be send to the customer on the end of each iteration and could be available all the time on the CI server. It's the main advantage of the Acceptance Tests as for me.

1. So on the iteration start we have 10 requirements. 
2. We create 10 failing acceptance tests. 
3. During iteration as team implements functionality some Acceptance Tests begin to pass.
4. At the end of iteration we have a real picture of which requirements were implemented, which weren't implemented and which were implemented partially.

Here's some example of the .NET implementation of the ATDD using SpecFlow tool.

I. Define scenarios in plain-text: (right in the Visual Studio)



II. ... and let's execute them: (it's also screenshot from Visual Studio.



III. Also we could generate human readable report. Something like that:



ATDD means that we need to create Acceptance Test Before we will write any code. So

1. Create an Acceptance Test
2. Start writing code just as we do always (using TDD\BDD principles or without them) until functionality required to met Acceptance Test will be completed.