As an experienced Product Owner on Agile IT Projects with NVISIA, I have found two great ways to refine the Acceptance Criteria when adding it to User Stories.
Acceptance Criteria is a given set of scenarios and expected results that should be accounted for in each User Story. Acceptance Criteria is important because it gives the development team a definition of "done" for a given User Story. Acceptance Criteria begins with input from existing product Stakeholders. In my experience, I have found there are always some edge cases that are missed unless we go through a couple extra steps.
Here are two ways I have found to dig out important edge cases to create a complete set of Acceptance Criteria for a User Story.
I set aside time to sit with various Subject Matter Experts and watch them run through their processes many times. They are usually very willing and thoughtful in sharing their knowledge about the processes as we work through them. It can feel repetitive at first, but then there is always something "Out of the Ordinary" to their usual process that occurs. I capture these edge cases and bring them to the attention of our client. It may be an important scenario that the User Story may need to accommodate.
System & Data Analysis
While defining Acceptance Criteria for a User Story, if there is an existing system with data related to the processes impacted by the story, I always try to get my hands on the data for analysis. The data can point out some scenarios that may be important to the client. I also try to sit in the seat of the user (not literally) and walk through the system in a test environment (preferably one with data that mimics production data as closely as possible). I take the Standard Operating Procedures and try to run through some of the procedures myself. I usually find some interesting scenarios to bring to the attention of our client as well.
Over the years, I have learned that devoting a little more time to Shadowing & System/Data Analysis can produce robust Acceptance Criteria for our clients. This gives the Development and Testing Teams a clearer Definition of Done for a User Story.