Act, Don’t Whine:

In many consulting projects over the last few years, we have seen devel­opment 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 assump­tions or specu­la­tions – very bad for the system or product.

The iSAQB Advanced module “REQ4ARC” (Requirements for Archi­tects) is based on the idea that devel­opment teams should help themselves in terms of requirements elici­tation instead of continuing to complain about bad requirements. In other words, as an architect or developer, you should learn enough about requirements elici­tation so that you can success­fully design projects and products.

Archi­tec­turally Signif­icant Requirements

A small effort is suffi­cient 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 stake­holders, 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 function­ality (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 archi­tec­turally signif­icant requirements in 1 — 2 percent of the overall project effort. With a typical Scrum team of 5 — 9 people devel­oping a product itera­tively and incre­men­tally 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 signif­i­cantly 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 devel­opment, it is suffi­cient to have a rough overview – as mentioned above. You can clarify functional details on-demand during devel­opment itera­tions. In agile terms, you can start with epics and – just in time for imple­men­tation – determine the detailed user stories for these epics.

For you as an architect, under­standing this hierar­chical 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 suffi­cient. 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 system­at­i­cally from the “big picture” into the necessary details. In some cases, techniques such as behavior-driven devel­opment (BDD) or speci­fi­cation-by-example (see [bdd] and [spec-by-example]) help to develop such detailed requirements together with suitable accep­tance criteria in a devel­opment-oriented and pragmatic manner.

Quality Requirements: The Achilles Heel in many Projects 

In our opinion, the biggest problem with requirements are insuf­fi­cient or absent quality requirements: Everyone expects good quality solutions from the team, but no one explicitly states what exactly is needed in terms of perfor­mance, security, robustness, exten­si­bility, etc.

More than 70,000 people (!!) have been trained and certified as requirements engineers in more than 80 countries under the super­vision of the Inter­na­tional Requirements Engineering Board (IREB, https://ireb.org) in the last 15 years. And the Scrum organi­za­tions also train thousands of product owners every year. Never­theless, quality requirements usually remain unspeakably poorly formu­lated or implicit in practice.

Yet it is precisely these quality requirements that are our key architectural drivers. Without really under­standing 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 compa­rable method­ological approaches.

Figure 3: A standardized scheme for qualities

Devel­opment teams should place particular emphasis on the explicit verifi­a­bility of quality requirements, for example by means of concrete and measurable accep­tance criteria. REQ4ARC training courses contain intensive exercises on this topic.

Close Cooper­ation 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 collab­o­ration between the devel­opment team and the stake­holders respon­sible for the product requirements (such as requirements engineers or product owners). We like the motto “discover to deliver” coined by Ellen Gottes­diener (see [gottes­diener]). She closely links the two topics of requirements analysis (discover) and architecture/development/deployment (deliver) instead of executing them sequen­tially one after the other, see Figure 4.

Figure 4: Discover to deliver

As part of this continuous collab­o­ration, you develop (deliver) parts of the product, and on this basis the business stake­holders discover changed or new requirements. In this way, both sides receive quick feedback and can jointly design the appro­priate system.

Alter­na­tively, approaches such as Three Amigo Sessions, Design Thinking or Lean Devel­opment also set up the teams in such a way that both roles work together inten­sively and ensure product success in short cycles.

Summary

In our pragmatic project work, we repeatedly find that archi­tects and devel­opment teams are unfor­tu­nately rarely adequately provided with suffi­ciently 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:

1. Clarify goals, scope, and context together with the relevant stakeholders.
2. Get an overview of the important high-level workflows, processes, or business functions (in agile terms: epics).
3. Clarify the 3 — 5 most important quality requirements, preferably measurable or decidable.
4. During devel­opment, refine (or ask the business side or product owner to refine) the high-level processes on-demand in feature and user stories.
5. In doing so, cooperate with the persons respon­sible 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 sugges­tions and concrete assis­tance on how to get a grip on this situation. May the power of good requirements be with you.

Sources

[REQ4ARC Curriculum] (Inter­na­tional Version) https://isaqb-org.github.io/curriculum-req4arc/

[REQ4ARC Book] P. Hruschka & G. Starke: Requirements Skills erfol­gre­icher Softwareteams. The book accom­pa­nying 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 Devel­opment, cf. e.g. https://cucumber.io/docs/bdd/

[spec-by-example] Gojko Adzic: Speci­fi­cation by Example, How Successful Teams Deliver the Right Software. Manning, 2011

[gottes­diener] Ellen Gottes­diener, Discover to Deliver. https://www.ebgconsulting.com/agile-resources/agile-books/