User stories are an Agile approach to requirements that emphasise end-user value.
All user stories are written in the language of the end-user such that they can be understood by a non-technical person who will instantly 'get' the value the story delivers.
The reason this is done is that it helps the non-technical end-users understand what progress the team is making and to prioritise work.
Something that begins with "As the system..." is not a user story. It is a technical task wrapped up in the user story format.
So where do technical tasks fit in?
Typically the Product Owner will create user stories that signify end-user value. They will prioritise them and then present them to the team as a part of backlog refinement or sprint planning.
The technical team often cannot look at a user story and understand exactly what it is they need to deliver. This is because a user story is an invitation to a conversation. The Product Owner talks the technical team through the user story. While they are doing that the technical team often breaks the story down in to one or more technical tasks. These technical tasks do not need to be understood by the end-users, can be written in a non-story format and can be highly technical in nature.
An an example, say I have the following user story:
As a first time website user I want to register so that I can get access to the website
The technical team might look at that story and break it down in to a number of technical tasks:
Create user table in database
Design the registration pages
Add validation to input fields
...and so on.
There should be few or no technical tasks that do not relate to a story. Even something like:
Set up the development environment
can be wrapped in to the first user story that delivers end-user value.
The goal with this approach is to have:
- User stories that the end-users can understand
- Technical tasks that the technical team understands and that are sufficient to deliver the user stories