Last week I taught our Use Case Modeling and Solution Requirements class. Towards the end of class, one of my students asked how functional requirements related to acceptance criteria. I get this question frequently. I think there’s a lot of confusion about the difference between requirements, acceptance criteria, and test cases.
Let’s start with some definitions…
Here are some key definitions from the BABOK:
Requirement: A usable representation of a need.
“Acceptance criteria describe the minimum set of requirements that must be met in order for a particular solution to be worth implementing.”
“Acceptance criteria are expressed in a testable form. This may require breaking requirements down into an atomic form so that test cases can be written to verify the solution against the criteria.”
“Acceptance criteria may be supplemented with other analysis models as needed.”
The IEEE provides a definition for a test case:
test case: (A) A set of test inputs, excecution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. (B) Documentation speficifying inputs, predicted results, and a set of execution conditions for a test item
Maybe a picture would help?
I’m honestly not sure the definitions really help that much. I had to draw this relationship out in order to really understand it. This is how I visualize the relationships between analysis models, acceptance criteria, requirements, and test cases:
In short, analysis models and requirements describe what is needed and how the solution should behave. Acceptance criteria and test cases are used to prove that we’ve delivered the requirements successfully. Analytical models, templates, and other analysis artifacts can provide supporting detail for acceptance criteria and test cases.
Getting to Acceptance Criteria
In a previous blog, I discussed how models and templates can be used to elaborate a user story. Let’s use some samples to show how acceptance criteria can be derived. I’m going to start with a simple user story, and assume we’ve developed supporting details for it:
How do I get from this collection of analysis models and text requirements to acceptance criteria? It depends…
In our class Writing Test Cases for Software Requirements, we teach analysts to derive test cases directly from requirements. If your organization takes this approach, then your requirements can also serve as your acceptance criteria.
Some organizations require that acceptance criteria be delivered as atomic text statements. A very common approach to that is the use of Gherkin scenarios. Gherkin scenarios use a specific syntax:
Given <a situation or context>
When <I taken an action>
Then <this is what should happen>
If you are trying to develop text-based acceptance criteria, the key word appears in my diagram above. Acceptance criteria are derived from your analysis work, and analysis artifacts are referenced as supporting detail.
If we use the use case or flowchart shown above as a starting point, Gherkin scenarios can be developed for the primary and alternate paths.
Derived from primary path and Business Rule BR001:
Scenario: Send completion certificates to students; all students selected are eligible.
Given I am a Training Admin
When I choose to send a completion certificate to one or more students in a selected class session and the enrollment status of all students in the selected class status is “Course Completed”
Then each student in that session should receive an email (see P008 Student Course Completion Email) and they should receive an attached course completion certificate (see in P009 Student Course Completion Certificate)
Derived from an alternate path and Business Rule BR001:
Scenario: Send completion certificates to students; some students selected are not eligible.
Given I am a Training Admin
When I choose to send a completion certificate to one or more students for a class session and at least one selected student has an enrollment status that is not “Course Completed”
Then each selected student whose enrollment status is “Course Completed” should receive an email (see P008, Student Course Completion Email) and they should receive an attached course completion certificate (see P009, Student Course Completion Certificate) and the Training Admin should receive an error message that identifies each Student who did not receive their course completion certificate (see EM123, Course Not Completed)
Of course, you can derive acceptance criteria from lots of other artifacts. Let’s say you’ve defined the Student First Name field as shown above: a required alphabetic field with a maximum length of 20 characters. Possible acceptance criteria scenarios include:
- Add a special character
- Add a space
- Leave it blank
- Try a number (what exactly does “CHAR” include, anyway?)
- Make the field too long
Non-functional requirements can also translate into Gherkin format:
Given the system is operational
When users send certificates throughout the day
Then the system must successfully send up to 250 certificates within a 24-hour period
These are just a few examples. If you look at most models and templates, there is a fairly straightforward way to take the results and translate them into text-based scenarios.
Where do test cases come in?
Once requirements and/or acceptance criteria have been developed, test cases can be written. Test cases differ from requirements or acceptance criteria because they detail exactly how the solution will be tested. Some key components of a test case are:
Preconditions
Any conditions or setup that must be in place before executing the test (e.g., user logged in, data available).
Test Data
Specific input values, configurations, or files used during the test.
Test Steps
A sequential list of actions the tester must perform.
Expected Result(s)
The outcome that should occur at each step if the system works correctly.
Postconditions (sometimes included)
State of the system after the test is executed (e.g., user remains logged in, database record created).
Actual Result
Captured during execution — what actually happened.
Status / Pass-Fail Criteria
Indicates whether the test passed, failed, or was blocked.
Hang on…
But wait, you may be thinking. Isn’t that double the work? If I have to write Gherkin statements, shouldn’t I just start there and use that format for my analysis work too? I mean, I only have a limited amount of time to do my work, so maybe I should just go straight to Gherkin.
Well, you could. But I personally don’t find text to be a great tool for analyzing requirements. It’s like using a the handle of a screwdriver to drive in a nail. You can do it…and you’ll eventually get there…but it’s not the most effective or efficient way to do it. I think you’ll find that the time savings you get using an appropriate analysis technique will more than make up for the time you spend transforming your results into another format.
Putting It Together
Requirements, acceptance criteria, and test cases are three important, interrelated concepts. I hope I’ve helped clarify the relationships between them. I also hope you see that models and other analytical artifacts can provide a lot of value in helping establish acceptance criteria and test cases. They’re not just extra work…they’re “thinking tools” that ensure we’ve asked all the right questions and hammered out all the details. In other words:
Given I have thoroughly analyzed a requirement and developed a solid representation of it
When I am asked to develop acceptance criteria
Then I should be able to easily derive a complete set of acceptance criteria from the requirement
Best,
–K.
Get the rest of the story!
This article is part of a series that we wrote based on challenges we faced during our own CRM conversion project in 2024. Each month we highlight a particular challenge and share tips, techniques, and tools you can use if you find yourself in a similar situation.
Kathy Claycomb
Managing Partner, Lead Expert
Kathy Claycomb brings over 35 years of experience to the classroom. She has participated in all phases of solution development using everything from agile to waterfall methodologies (and quite a few in between). Before joining B2T, her career spanned roles from application developer to Senior Director of Services at various organizations. Kathy has broad industry background including transportation, manufacturing, insurance, energy, healthcare, and banking.
Kathy’s first love is teaching, and throughout her career she has always managed to spend a portion of her time instructing. She has an engaging, highly interactive teaching style that ensures students leave the course with a thorough grasp of the material. Her students consistently praise her teaching abilities and her talent for drawing on her personal experience to enhance their learning.
Kathy served as the Technical Editor for Business Analysis for Dummies, 2nd Edition.
