Requirements Specification and its Documentation

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 [1] 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.

Scrum Balance between different requirements types

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:

  • Technical Requirements Submitter
  • Person responsible for the operation of the system
  • Enterprise Architect
  • Process Owner
  • Professional Requirements Analyst

Identify/ Document / Verify

Scrum Refinement of the requirements

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:

  1. Content
  2. Form of documentation
  3. Coordination

(vgl. Rupp, Pohl [1]). 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.

Budget and Requirements: The Dilemma

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:

The Cone of Uncertainty

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:

  • Don’t make estimations. Deliver high-quality executable software frequently and stop your work when the budget is spent.
  • Reduce uncertainty by different assessment methods, such as:
    • Parametric estimation models with historical project data
    • Function-point analysis
    • Work-Breakdown Structures with Pert estimates
    • Regular Planning Poker sessions
  • Assign budgets to feature Sets or Epics. Once you have a budget assigned, you can control the requirements engineering process in such a way that the complete specified feature set fits the assigned budget. For this purpose, regular reviews are required.

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:

  1. Refinement. Reserve 10-15% of the sprint time for refinement the Product Backlog. Leave it to the Team as to how they prepare for an effective planning meeting. Inexperienced Teams are often overwhelmed by this freedom and do very little preparation. They often use this time to improve the features that they are developing instead.
  2. Plan specific time boxes in which you work with the Product Owner to refine requirements or work on technical details (e.g. concepts or Work-Breakdown-Structures).
  3. Hold regular scheduled Planning Poker sessions to refine and address new requirements and estimate them with story points.

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.