Act, Don’t Whine:
Systematically Improving Your Requirements With REQ4ARC
In many consulting projects over the last few years, we have seen development teams complain about two things: that they suffer from a lack of good requirements or that they have not received important requirements or have received them much too late. They then blame requirements engineers, business analysts, or product owners who “didn’t do their job well”. This results in architecture and design decisions based on implicit assumptions or speculations – very bad for the system or product.
The iSAQB Advanced module “REQ4ARC” (Requirements for Architects) is based on the idea that development teams should help themselves in terms of requirements elicitation instead of continuing to complain about bad requirements. In other words, as an architect or developer, you should learn enough about requirements elicitation so that you can successfully design projects and products.
Architecturally Significant Requirements
A small effort is sufficient to clarify the subset of requirements, that is important to make design decisions. Let’s start with the foundation, which we call “a clean project start”.
Three points should be explicitly clear to everyone in the team: The project goals, the stakeholders, and the scope of the project. In other words, “Where do we want to go?”, “Who may (or must) play a role?”, and “Is this our topic or not?” (see Figure 1).
Figure 1: A clean start (used with permission of req42)
If the right people come together and politics stays out of the discussion, a few hours or – in the case of very large projects – a few days are enough to gain clarity on these three key points. Additionally, an overview of the desired functionality (no details!) helps, as well as the key quality requirements (and we really mean only 3 — 5) and the hardest constraints.
In our experience, you can determine all these architecturally significant requirements in 1 — 2 percent of the overall project effort. With a typical Scrum team of 5 — 9 people developing a product iteratively and incrementally over one year (i.e., within 1000 to 1800 person days) that makes 10 — 36 person days only. With this very manageable amount of time, you can significantly mitigate the risk of wrong architectural decisions resulting in wrong products.
The Heart of the Matter: Processes and Functions
Functional requirements form a core topic of the entire requirements analysis: they determine what the system offers to its users, what business or work processes it must support.
At the beginning of development, it is sufficient to have a rough overview – as mentioned above. You can clarify functional details on-demand during development iterations. In agile terms, you can start with epics and – just in time for implementation – determine the detailed user stories for these epics.
For you as an architect, understanding this hierarchical nature of requirements is important because you only need to know the detailed functional requirements (i.e., the user stories) shortly before you develop the solution. For other parts, the overview is sufficient. This avoids up-front work and allows you to respond to changes in the business environment at short notice.
Figure 2: Hierarchy of functional requirements
REQ4ARC offers methods and techniques for refining requirements to be able to dive systematically from the “big picture” into the necessary details. In some cases, techniques such as behavior-driven development (BDD) or specification-by-example (see [bdd] and [spec-by-example]) help to develop such detailed requirements together with suitable acceptance criteria in a development-oriented and pragmatic manner.
Quality Requirements: The Achilles Heel in many Projects
In our opinion, the biggest problem with requirements are insufficient or absent quality requirements: Everyone expects good quality solutions from the team, but no one explicitly states what exactly is needed in terms of performance, security, robustness, extensibility, etc.
More than 70,000 people (!!) have been trained and certified as requirements engineers in more than 80 countries under the supervision of the International Requirements Engineering Board (IREB, https://ireb.org) in the last 15 years. And the Scrum organizations also train thousands of product owners every year. Nevertheless, quality requirements usually remain unspeakably poorly formulated or implicit in practice.
Yet it is precisely these quality requirements that are our key architectural drivers. Without really understanding which level of security is needed, how much the system must scale, what legal requirements have to be met, key design decisions often remain a matter of luck.
For this reason, REQ4ARC devotes a great deal of attention to this topic: We base the discussion on the proven ISO standard 25010 (see Figure 3) and go into detail about ways to refine individual quality requirements, for example with the help of quality scenarios or comparable methodological approaches.
Figure 3: A standardized scheme for qualities
Development teams should place particular emphasis on the explicit verifiability of quality requirements, for example by means of concrete and measurable acceptance criteria. REQ4ARC training courses contain intensive exercises on this topic.
Close Cooperation between Business and Development
Find the error in the following statement:
“Customers and users know exactly what they want.”
Sure, it’s a classic: In many cases, people (here: our business side) don’t know exactly what they want or need. Therefore, you should ensure the closest possible collaboration between the development team and the stakeholders responsible for the product requirements (such as requirements engineers or product owners). We like the motto “discover to deliver” coined by Ellen Gottesdiener (see [gottesdiener]). She closely links the two topics of requirements analysis (discover) and architecture/development/deployment (deliver) instead of executing them sequentially one after the other, see Figure 4.
Figure 4: Discover to deliver
As part of this continuous collaboration, you develop (deliver) parts of the product, and on this basis the business stakeholders discover changed or new requirements. In this way, both sides receive quick feedback and can jointly design the appropriate system.
Alternatively, approaches such as Three Amigo Sessions, Design Thinking or Lean Development also set up the teams in such a way that both roles work together intensively and ensure product success in short cycles.
Summary
In our pragmatic project work, we repeatedly find that architects and development teams are unfortunately rarely adequately provided with sufficiently good requirements. However, they urgently need them to make decisions about the architecture of products in a goal-oriented and future-proof manner.
In a nutshell:
- Clarify goals, scope, and context together with the relevant stakeholders.
- Get an overview of the important high-level workflows, processes, or business functions (in agile terms: epics).
- Clarify the 3 — 5 most important quality requirements, preferably measurable or decidable.
- During development, refine (or ask the business side or product owner to refine) the high-level processes on-demand in feature and user stories.
- In doing so, cooperate with the persons responsible for the product or system (e.g. business experts, business analysts, product owners).
As “help to self-help”, the practical REQ4ARC Advanced level module of iSAQB is an effective remedy that gives you suggestions and concrete assistance on how to get a grip on this situation. May the power of good requirements be with you.
Sources
[REQ4ARC Curriculum] (International Version) https://isaqb-org.github.io/curriculum-req4arc/
[REQ4ARC Book] P. Hruschka & G. Starke: Requirements Skills erfolgreicher Softwareteams. The book accompanying the REQ4ARC curriculum (in German). For readers of the iSAQB Blog 50% discount: https://leanpub.com/requirements-skills/c/isaqb-blog-coupon
[bdd] Behaviour Driven Development, cf. e.g. https://cucumber.io/docs/bdd/
[spec-by-example] Gojko Adzic: Specification by Example, How Successful Teams Deliver the Right Software. Manning, 2011
[gottesdiener] Ellen Gottesdiener, Discover to Deliver. https://www.ebgconsulting.com/agile-resources/agile-books/
Share this article:
Related Posts
Featured in this article