### Description <!-- **User Stories** are the primary means of expressing needed functionality. Since they focus on the user as the subject of interest, and not the system, user stories are value and customer-centric. Recommended form is the "user-voice form": As a (user role), I want to (activity), so that (business value) By using this format, the teams are guided to understand who is using the system, what they are doing with it, and why they are doing it. **Enabler Stories** are written to support exploration, architecture, or infrastructure. Enabler stories may be expressed in technical rather than user-centric language. Enabler stories are demonstrated just like user stories, typically by showing the knowledge gained, artifacts produced, or the user interface, stub, or mock-up. --> ### Acceptance Criteria <!-- Acceptance criteria is used to confirm that the story was completed correctly. Criteria can be written in any format, or a "given-when-then" form may be used: Given *some context* When *some action is carried out* Then *a particular set of observable consequences should obtain* --> - [ ] 1. .dcm must match
Description
Acceptance Criteria