The definination of "Acceptance Criteria" in Agile

• Acceptance Criteria Definition 1: “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” (via Microsoft Press)
• Acceptance Criteria Definition 2: “Pre-established standards or requirements a product or project must meet.” (via Google)

My Own opinion:

The second definition may be considered the main definition, "Acceptance Criteria" is nothing but the usual functional, and non-functional requirements.

The purpose of acceptance criteria is to articulate precisely when the user story is 'done' from the product owner's perspective.

They should translate into 'acceptance tests’ that a tester (or quality assurance tester) can use to verify the quality of a feature.

A tester should be involved in writing them, but it is a product owner's responsibility to produce them.

Agile business analysts are very helpful in assisting product owners and extracting the right information for user stories.

Acceptance Criteria template:

|  A <role> should <see/be able to do> the following: 
|     - <AC1> 
|     - <AC2>
|     - <AC...> 
| 
|  Edge Cases: 
|    - <EC1> 
|    - <EC2> 

|    - <EC...>

Example in a user story:

Refrences:
http://pashunconsulting.co.uk/blog/productbacklog.html
https://www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/
Paul VII. Agile Product Management: User Stories:  How to capture, and manage requirements for Agile Product Management and Business Analysis with Scrum (scrum, ... development, agile software development) (p. 31). Pashun Consulting Ltd.. Kindle Edition.