The role of the Product Owner is to be aware of all of the different types of requirements in his project and manage them. Basically, requirement types can be distinguished. So distinguish e.g. Pohl & Rupp  into functional requirements, quality requirements and into boundary conditions.
It should be noted that requirements can come from different Stakeholder Groups. For example, the traditional Product Owner rather focuses on the implementation of functional requirements. Here, the technical aspects of IT operations would then be
neglected. Therefore, some demands on the requirements management also emerge in agile methods in order to ensure that the expectations of all Stakeholder Groups are considered.
Scrum does not define the content criteria of requirements, but says only that the Product Owner is solely responsible for the management of the requirements.
Therefore, the Product Owner must ensure that all of the relevant requirements are entered into the Product Backlog. In reality, a number of challenges arise from this as it can be very difficult for the Product Owner to represent and estimate the requirements for all of the Stakeholders.
We recommend identifying the relevant requirements requestors by an initial stakeholder analysis, and in large projects to appoint not only just one single Product Owner, but to have a Product Owner Team. The Team appoints a “Chief Product Owner” who bears full responsibility and makes decisions in the event of disagreements.
Diagram 19: Balance between different requirements types
The diagram shown here illustrates the additional information that must be formulated by the requirements controller, the Product Owner, in order to formulate a system holistically and also after initial development completion, to transfer into an operating phase.
The Product Owner Team should then fulfill the following roles:
Diagram 20: Refinement of the requirements
The requirements analyst helps the Product Owner find and formulate the requirements using professional methods. In this respect, interview techniques and also moderated workshops are particularly suitable.
Furthermore, the analyst helps capture the requirements so that they satisfy the quality aspects:
(vgl. Rupp, Pohl ). Meaningful and helpful criteria regarding requirements could for example be the quality criteria defined by the Standard IEEE 830, the criteria of the Sophist Group or the INVEST- criteria according to Cohn (See section ‘Standards’).
At the beginning of a project, Stakeholders express their expectations and define the quality criteria to be met.
At the beginning of a project there is often the Requirements Dilemma: The requirements are still unclear but the budget is already fixed.
The amount of detailed knowledge you need to have about your requirements depends on the stage of the project as well as the contractual constraints you might find in your organization. The knowledge usually increases and the uncertainty decreases as the project progresses. The Cone of Uncertainty visualizes this:
Diagram 21: The Cone of Uncertainty
Agile projects concentrate on the early creation of functioning software. Only this can contribute value to a company. An integrated requirements engineering and development process reduces risks because the results are regularly evaluated and a continuous creation of value takes place.
In reality, the project budget is often fixed before being discussed with the Stakeholders and before all of the requirements have been defined. However, there are different ways to deal with this problem and to enable an assessment under uncertainty:
The above and many more other methods are available to deal with uncertainty before a project starts. Scrum does not provide a solution to remove uncertainty beforehand but is simply an iterative method to deliver value in each Sprint and reduce the risk of a project failing.
A basic prerequisite for good estimation and planning is a good understanding of the requirements. There are various methodologies in Scrum to achieve this:
There are many ways to improve the above mentioned quality criteria. When it comes to larger projects in regulated environments, it is advisable to formalize parts of the requirements engineering process.