scrum vs IT requirments

It is possible to have system requirements which do not capture business value that is specific to an increment. Examples include adherence to organizational or architectural standards, and arguably certain NFR's such as scalability. These can be referenced in the Definition of Done, such that an increment cannot be considered potentially releasable unless the associated criteria are met. A DoD should always meet organizational standards.

However, any requirements that relate to product characteristics should be of concern to the Product Owner. The three examples of requirements that you give all relate to product features that stakeholders will care about once product increments are delivered and deployed. These people can include maintenance staff such as system administrators as well as end users.

It seems to me that the PO is taking too narrow a view of business value in this case, and has not identified all of the product stakeholders. It also seems likely that the PO has not fully considered the product's journey into service and cost of ownership.

+1 to Ian's response, with emphasis on the fact that the people doing operations, etc, are still very valuable stakeholders, and the PO should work hard to understand how their requirements also have very important business value. The PO is PO for *all* key stakeholders, not just the ones that are in his/her department. The PO should also be inviting some of these key stakeholders to the Sprint Reviews so that they can make the case for their requirements.

I need to comment on this too:
> PO writes: backlog, acceptence criteria ..

Many people understand the role of Scrum’s Product Owner as being that of an analyst responsible for creating requirements. Actually, Scrum doesn't require POs to create the requirements. They can have the Dev Team do this or help with this. Just understand, regardless of who creates/writes/documents/describes the requirements, the PO has the duty to make sure the understanding of the requirements is clear, and thus they own the *decisions* of the Product Backlog. Whether they do the legwork of maintaining the PBL or not is different for each PO/Dev Team. Some times the PO does all that work, sometimes the Dev Team does all that work, and sometimes it's a custom combination of the two. Experiment, inspect, and adapt!

This is a very good question.

I have faced this situation.
When a PO writes requirement. It will look like this

"make the website available in mobile phones and smart phones"

This is a high level requirements. To provide the test environment for this project , we need to get into so much details like , what market we are selling the product ? what is the majority of devices used in that market ? etc

This is why product backlog refinement is done. product backlog refinement is where development team will be involved to refine the requirements , add details and make tasks etc.

Obviously ,someone in the development team should represent the IT team , because the team should be "cross functional". This person should be responsible to come out with the tasks and the details of what needs to be achieved. PO is responsible for prioritization. So he cannot say "you deal with the details". Because for PO to prioritize and maximize ROI , he needs to understand the "estimates" and the tasks involved in achieving the story. He doesn't have to know how they achieve it. He needs to know what is the end result of this and that and the associated cost.