Why not just "Implement about dialog with version number.".
I'm pretty sure 99% of 'user stories' are just feature lists written in a really really awkward and annoying way.
"As a user, I want to be able to find the full version number of the product to make it easier to get help when raising support requests".
This is now something we can argue about — is this story bringing more or less value than, e.g. setting reminders or 2FA?
If you write the narrative statements in a banal or glib way, just for the sake of them, then of course there's no point, but that's true of most processes — e.g. JavaDocs are a good idea in principle, but you can make them equally useless: "return Boolean: true or false".
"We want to add the software version number to the dialog. We think they will then cite this when they raise tickets"
?
At least in this form, you can expand on the context and justify it in depth.
Also, user stories often phrase the context as a given when it's really not. In your example, it's an implicit premise that a version number may help. In mine, the writer admits scepticism and therefore invites the programmer to think up some better solution.
* By having a premise, it forces you to question its validity up front (before any development work is done), getting rid of ambiguities early and having a shared understanding between business and technical team members (rather than the developer implementing what they think is a better solution, the product owner being unhappy with the outcome & only finding this out at the end).
* Using the format of "As a <type of user>, I want to <use a feature>, so that I can <achieve some value>" forces you to think about what user (customer/website editor/back office) gets what specific value (faster/cheaper/less error prone) from implementing some feature. By following the same pattern it makes it easier to compare unrelated areas.
I don't think the format is sacrosanct, but it's like any constraint you put on yourself (e.g. coding conventions) — if you find it hard to make a story work in that format, it's an indication that it may not be properly understood it really bringing value.
User stories are mostly there to frame progress only in terms of things your project owner cares about. If you talk to non-tech people describing their experience of a product, they don't just reel off a list of nouns at you. They say 'you can click on the little thing and it wiggles'. So this is how you should be reporting to your non-tech boss.
Don't say 'I made /timesheet/:id redirect to /timesheet/:id/slug-of-sheet-name', say 'Users trying to get back to a timesheet can just type some of the name in their browser's URL bar and it will show up'. Definitely don't say the word 'slug'. They will thank you for it.
The requirement you wrote makes it easy to accept it as a complete spec (just implement this!), when it isn't.
The user story you wrote prompts more questions -- what's the dialog look like? Do we display the whole version number? Does the dialog contain anything else? How does the user close the dialog? Where does the user interact to open the dialog?
Admin :: Roles :: Multiple Roles)
And the "story" part goes in the body:
"As an adminstrator I assign multiple roles to users so they have access to all the parts (and only those parts) of the application they need to do their job."
..with additional context, exceptions, rules, examples, etc, in the body.