Maintaining an Overview

In the complex world of software devel­opment, maintaining a clear overview of requirements is crucial. Dr. Peter Hruschka and Dr. Gernot Starke illus­trate in their blog post how the REQ4ARC module aids archi­tects in managing detailed, architecture-related requirements efficiently, promoting a systematic approach to achieving a broad under­standing before delving into specifics.

Do you sometimes get bogged down in details and desper­ately want a way to have a greater overview of things? We have seen many projects and devel­opment teams that had a lot of fine-grained, highly detailed requirements. Sometimes, we had to deal with hundreds or even several thousand individual (“atomic”) requirements. To effec­tively process such a vast number of (detailed) requirements, it is essential to maintain an overview. You should system­at­i­cally create a sort of bird’s eye view and not rely on partic­i­pants to maintain an overview on their own.

In today’s (fortu­nately mostly agile) world, we can forego bloated and formally approved functional speci­fi­ca­tions in most cases. To begin system devel­opment (i.e., architecture decisions and imple­men­tation), all you need are the funda­mental architecture-related requirements, which provide the first oppor­tunity to gain an overview.

But let’s start with a basic observation.

25% of the work is eliciting the requirements.

You never get that much time. It also suffices if you roughly elaborate the architecture-related requirements with little A‑priori effort (approx. 1–2% of the total effort) and then simul­ta­ne­ously deliver the other 23–24% “just in time” in an iterative-incre­mental manner. This working method is propa­gated by the T model , where you deliver the crossbar of the “T” early on and then go into detail in each iteration.

The following illus­tration demon­strates this model.

Breadth before depth –“just in time” requirements

As a devel­opment team, our main concern is to handle architecture-related requirements—not so much “all” of them. Some requirements have a formative influence on architecture or technology decisions, and these are precisely the types of requirements that we are concerned with here. Architecture and devel­opment expertise is necessary to determine if a requirement is relevant to the architecture. In other words, only the devel­opment team or the architecture can identify this relevance.

You should already have an overview of the functional requirements early on so that you can better assess your overall task. We believe that this is necessary so that, based on business prior­ities and technical constraints, you can choose what you wish to address first and what to address after­wards in your overall task, as depicted by the T‑model (see illustration).

This overview also includes the three to five most important quality requirements for you (your preferred choices, such as perfor­mance, capacity, security, or usability) and the toughest constraints. After­wards, you may begin development.

Early on, the “big picture” should be clear enough so that you can antic­ipate the rough trajectory of devel­opment and start making the guiding techno­logical or struc­tural decisions accord­ingly. After­wards, you can add the detailed requirements just-in-time.

In practice: Missing the forest for the trees…

As the following quiz shows, simply knowing the details does not help the devel­opment team. You can see a lot of details in the following illus­tration. Can you identify what kind of system it is? Can you get an overview based on this information? If you are familiar with the name Kenworth Montana, then perhaps one of the details gave it away. If not, then you certainly don’t know what the entire system is. We’ve delib­er­ately made the example difficult to grasp – but we think you under­stand the problem.

The solution is at the bottom of this page…

Create an overview

In IT, we refer to the overview as the scope and context of a system.

Start from top-level business processes and system­at­i­cally build a hierarchy that allows you to delve into different areas. For our example, this could be a breakdown into the chassis, engine, exhaust, and cabin:

As an example, we could call this top-level decom­po­sition epics. From there, you can organize the details of the system (such as user stories or lower-level features) into the overall picture.

This results in the desired hierarchy:

What are the benefits?

Let’s do the math: 1000 detailed requirements are likely grouped into 100 features, and these in turn become 10 epics within the overall system. Therefore, with each level of the hierarchy, we simplify things by one order of magnitude (factor of 10).

For architectural tasks, it is important to famil­iarize yourself with these epics at the earliest oppor­tunity. It is also okay if details for some epics already exist. Regret­tably, it’s challenging to make signif­icant architectural decisions based on these kinds of details. 🙁

Solution: The complete overview

This is a trans­lation of the blog post “Behalten Sie den Überblick” by Dr. Peter Hruschka and Dr. Gernot Starke. Here you can find the original blog post in German.

Sources:
1. Requirements-for-Archi­tects (REQ4ARC) from iSAQB
2. Practice book in German for iSAQB CPSA-Advanced Module REQ4ARC, authored by Peter Hruschka & Gernot Starke: ‘Requirements Skills erfol­gre­icher Softwareteams’.