Look for Classes of Functional Requirements

Functional requirements, often captured as use cases or user stories, define the software system’s behavior but are only sometimes interesting when designing the architecture. All functional requirements are essential to the success of the software system, but not all system features have architectural significance. When a functional requirement drives architectural decision making, we call it an influential functional requirement.

Influential functional requirements can be referred to as architecture killers. If your architecture doesn’t allow you to implement one of these high-value, high-priority features, you’ll be forced to raze your architecture and start over.

Identifying influential functional requirements is equal parts art and science. It becomes easier with experience. Here’s how I do it:

1. Start with a notional architecture sketch that summarizes your current thinking about the architecture.
2. Identify general classes of requirements that represent the same type of architectural problem.
3. For each problem class identified, walk through the notional architecture and show how to achieve each requirement group. If it is not immediately obvious how you would implement the feature based on the known coarse-grained requirements, it might have architectural significance.

The goal of step two is to reduce a giant list of functional requirements down to a small number of representative categories. Here are a few strategies:

• Look for functional requirements that might be implemented within the same architectural elements. For example, features that require persistence go in one group whereas features that require user interaction go in another.

• Look for functional requirements that seem difficult to implement. These could be significant to the architecture.

• Look for high-value, high-priority functional requirements.

Here’s an example. Recall the simple calculator example. Adding two numbers together is an important functional requirement but has little influence on the architecture, so let’s spice it up a bit. Here’s a new feature: as an Adder User I can review my addition history even if I’ve lost my phone. “People love looking at past stuff they’ve done,” the marketing team assures us. “It’s going to be A-Mazing!”

Historical information? OK, no problem. We can save the user’s actions to a local database. Wait… even if they’ve lost their phone?!?! Now we need a remote database server, which opens up a ton of new questions. What happens when the user’s phone is offline? What about availability? Scalability? Hosting costs? Syncing the app when the schema changes? The list goes on.

That one seemingly innocent feature request introduces a swirl of complexity. In our simple calculator example, we can reduce any mathematical operation to the same general problem. To solve the newly requested history feature, we need remote storage. This one feature takes the architecture in a new direction that other functional requirements did not.

Reference any influential functional requirements in your architecture documentation but avoid duplicating the requirements engineering effort. Our goal is to call attention to critical features that influence our decision making.