The req42 Framework

req42 is everything you need to successfully handle needs and requirements in an agile organization. We call the role responsible for good requirements engineering “Product Owner” - following the suggestion of Scrum. (You can of course establish other names for this role in your environment, such as Business Analyst, Requirements Engineer, Product Manager, Solution Manager). For the sake of simplicity, we will stick with Product Owner.

Result-oriented - not process-oriented

req42 (like its sister framework arc42 for architects) is built to be result-oriented, not process-oriented. It provides you with 12 things that a good product owner should keep under control. In other words, 12 artifacts that you should develop and maintain as a requirements owner. Because:

Agile requirements engineering is much more than just managing the product backlog.

The following figure shows you the “universe of the product owner” from req42. The “guiding star” in the middle is of course the Product Backlog as the most important artifact, with which you will certainly spend most of your time. But around it many other artifacts are revolving that you should take seriously in your role as a product owner from a management perspective or from a requirements perspective.



The blue planets are the more requirements-oriented deliverables, the red planets are the more management-oriented records, and the green planet represents your development team’s intermediate deliverables (the continuously delivered product increments) that you, as the product owner, need to sign off on.

The six main tasks of product owners:

These deliverables, their structure, their management and their maintenance are the focus of our considerations. However, as a didactic aid, we have also identified the six main tasks of a product owner, which are shown in the following image.

You can see from the double arrows between the activities that in the role of a Product Owner you are constantly involved with all of these activities and can switch between them at will. We only use them for teaching and explaining the job.

req42 is process agnostic. There is no prescribed process that you must follow. Of course, we recommend an agile process where only the requirements that will soon be needed for implementation as a product increment are worked out in detail.

Not a document, but simply ordered knowledge

We hope that the metaphor of the universe will steer you away from having to manage all artifacts in the form of a document. You should just have these artifacts tangible in some form that allows all stakeholders involved to communicate about them in a reasonable way.

Think of these artifacts as a cabinet, where each artifact has its own compartment. The cabinet today should of course not be one filled with lots of paper in different compartments, but rather a wiki with an appropriate structure or some other electronic collection. With such a cabinet, you can number the product owner’s universe and place the artifacts in the respective cabinet compartment.

  1. Business Goals
  2. Stakeholders
  3. Scope
  4. Product Backlog
    4.1 Epics
    4.2 Features
    4.3 User-Storys
  5. Supporting Models
  6. Quality Requirements
  7. Constraints
  8. Domain Terminology
  9. Assets
  10. Team Structure
  11. Roadmaps
  12. Risks/Assumptions

(If you miss the green planet - the product increments: these are contained in your development team’s cabinet. As a product owner, you don’t own this artifact; you only review it after the development team declares it as “done”.)

The following table shows how the planets of the universe, or the compartments of the cabinet, are related to the tasks of a product owner. You can see a bit more clearly which artifacts you mainly have to deal with as a product owner in which activity.

Aufgabe Artefakte
Clean Start 9. Assets
  1. Business Goals
  2. Stakeholders
  3. Scope
Handle Functional Requirements 4. Product Backlog
  5. Supporting Models
  8. Domain Terminology
Handle Quality and Constraints 6. Quality Requirements
  7. Constraints
Planning & Estimating 10. Team Structure
  11.Roadmaps
  12. Risks / Assumptions
Check Results 13. Product Increments

req42 is more than Scrum

The worldwide triumph and the high level of dissemination of Scrum has led many IT people to equate Scrum with agile methods. Yes, Scrum builds on the core values of the agile manifesto. But, actually Scrum is (just) a good framework for managing complex products. It starts where budgets are approved, potential team members are named and initial requirements are already gathered and stops where the day-to-day work starts. In Scrum, specific methods, techniques and notations are deliberately kept open in order to be able to adapt to as many situations and preconditions as possible.

Besides Scrum, many other agile methodologies have emerged, such as XP, Lean Development, Design Thinking, Crystal, and others. We have borrowed from many of them and assembled them into req42 - as a pragmatic collection of “good practices”.

Note that we avoid the word “best practices.” “Best” sounds like there is someone who knows the absolute best - and we don’t believe in that. “Good Practices” are tips and advice from real-world experience: things that have worked in projects and product developments and are worth trying, following the agile principle of “Inspect & Adapt”. You will see that - depending on the constraints - we may even recommend contradictory “good practices” - adapted and appropriate to the situation in each case.

In our flagship workshop „Mastering Agile Requirements“ and in our impulse coachings sessions we teach you countless “good practices”, pragmatic tips and tricks for dealing with the core artifacts. As a product owner, you will learn how to develop products in such a way that they are loved by your customers and users.