You asked about Scrum in other questions on this site, so I'll asume this is about Scrum. The scrum guide refers to the work sitting on the backlog as Product Backlog Items (PBIs), not product requirements or business scope. The work a team does for a product isn't just implementation of requirements. You can have bugs, you can have technical tasks, you can have spikes, refactoring or clearing up technical debt.
As Thomas Owens mentions in his answer, you can sometimes have tasks assigned to the PBI that would require them, say refactoring for example. However this is not always possible as it can be something that's needed by the entire product not just some PBIs, things like changing the architecture of the application for better scaling, or something.
You really need to think about what kind of task it is. Configuring a development environment maybe isn't really something that should sit in the backlog since it's not enhancing the product per se. Maybe it can sit in the Sprint backlog instead of the product backlog. Also, there are tasks and there are tasks. Tasks as division in smaller pieces of a PBI don't belong in the product backlog, only in the sprint backlog. Technical tasks like the changing of the architecture of the application example I just gave can be placed in the backlog as a PBI itself.
It really depends how the team organizes their work and interacts with others. I've worked on one project where we used technical tasks in the backlog and the CEO once asked "what the heck is that?" during a discussion at a review meeting. He found the explanation interesting, but things could have turned out another way. So figure it out with everyone how best to proceed, and if you are still in doubt, you can just experiment, inspect and adapt.