Design and Implementation Constraints

2025-06-21 18:08 Business analysis

Today, I’d like to talk about constraints (in the sense of "design and implementation constraints"). These will be free-form reflections on this rather specific and rare type of requirements in the practice of many analysts. The goal is to understand what the experts say about it and share some of my own thoughts. I often find that this kind of requirements is challenging for analysts, especially beginners, so let's try to unpack it.

First things first: what is it exactly, and where does it fit in the broader set of information analysts work with?

Karl Wiegers and Joy Beatty — Software Requirements v.3:

A restriction that is imposed on the choices available to the developer for the design and construction of a product.

Let me rephrase this: a limitation imposed on the range of solutions available to developers in the context of designing and building a product.

I’ve emphasized key points here that we'll return to shortly. In Wiegers' classification, this is a subtype of non-functional requirements. He discusses constraints quite thoroughly, which I’ll explore later.

BABOK v3.0:

An influencing factor that cannot be changed, and that places a limit or restriction on a possible solution or solution option.

If we get philosophical, we could say this basically aligns with the definition before. But not necessarily — there’s room for alternative interpretations. Still, BABOK doesn’t offer much more on the topic, so we won't dive further here.

CPRE Foundation Level Handbook (IREB):

Constraints are requirements that limit the solution space beyond what is necessary to meet the given functional requirements and quality requirements.

Requirements that limit the solution space beyond what is needed to satisfy functional and quality requirements. Again, these are requirements, similar in meaning to what has been described above. Notably, in IREB’s classification, constraints are a separate category alongside Functional and Quality Requirements.

Now, here’s my own interpretation: constraints are things that limit the development team’s creativity in how they implement a solution. To grasp this more clearly, I recommend reading the article about what requirements actually are and how they differ from implementation details.

In particular, here's what we need to understand: there are requirements (what the solution must include) and implementation details/designs (how to implement those requirements). A feature like "Order Creation" and its functional and quality aspects are requirements. Code, database structures, and other developer decisions (and note: not just developers — this includes the entire development team: frontenders, backenders, testers, UX designers, project managers) are implementation details. These areas overlap, and sometimes it’s unclear where something belongs. It depends on the team and its processes (see the previously mentioned article).

In an ideal world, the customer and other external stakeholders are sources of requirements — they define what is needed. The how is up to the development team, the experts. As in: “Folks, don’t meddle in our domain — we’ll decide how to build what you need. That’s what you pay us for. You don’t need a database table called 'Orders' — you need to be able to create an order a certain way.” Of course, we all know that "what" doesn’t only come from people. Requirements can stem from business rules, documents, processes, systems, and more.

The point here is that sometimes external factors (stakeholders, regulations, third-party systems, etc.) do interfere with the how. Simply because they can. And when they do, they limit the development team’s options in design. This isn’t an ideal situation for us — teams don’t like being told how to do their job. But sometimes, there’s no choice: the client pays the bills; governments don’t care about your feelings; third-party services have rules for integration. So, who else but the analyst, the bridge to the outside world, should uncover these constraints?

Let’s look at it another way: constraints are a very specific kind of requirements that reflect how external entities interfere with the how. It might take time to internalize that.

Examples from Karl Wiegers' book with some notes:

CO-1: The system’s design, code, and maintenance documentation shall conform to the Process Impact Intranet Development Standard, Version 1.3.

Architecture, code, and documentation (yes, documentation is also part of how you develop the system) must conform to an external standard. Whether it's actually external in Wiegers' example isn't clear, but if it’s internal, then it’s not a constraint — just internal rules.

CO-2: The system shall use the current corporate standard Oracle database engine.

The development team is limited in the choice of DBMS.

CO-3: All HTML code shall conform to the HTML 5.0 standard.

A constraint on how HTML is written.

Mr. Wiegers also offers this insight:

Requirements that incorporate or are written in the form of solution ideas rather than needs are imposing design constraints, often unnecessarily, so watch out for those.

When stakeholders offer solutions instead of needs, they create constraints. And yes, that’s true. Whether and how to treat them as constraints is up to us. For example, UI often sits in the grey zone between requirements and designs. Many would argue that UI is a "how", not a "what". Ideally, stakeholders shouldn’t dictate specific UI implementations — just the quality expectations (usability, speed, etc.). It’s good to be aware of this, especially since your team likely includes UI experts. Maybe it’s even you, the analyst.
So, when a user says, "I want to click a link to create an order," don’t treat it like any other requirement. Instead:

Listen.
Ask: why exactly this way? “Look, we’re the experts here, my friend. Is it truly essential that this is a link? Why? If it is, sure — but maybe leave the decision about which control to use to our in-house experts, aka the smart people?”
If the constraint turns out to be non-negotiable then pass it along to the designer with something like: “This one has to be just like that — sorry, mate.”
If you manage to convince user that it’s not worth tying the team’s hands (for instance, by immediately offering him some friendlier alternatives), then don’t do anything at all. Just design it the way your team sees fit.

Let’s now look at what else Mr. Wiegers says about constraints (and I’ll dare to disagree with some of it — maybe I haven’t yet matured enough to see it his way — happy to discuss in the channel comments if there’s something I’ve misunderstood).

Sources of constraints include: ■ Specific technologies, tools, languages, and databases that must be used or avoided.

Yes — if these aren’t internal team decisions but are dictated from outside.

■ Restrictions because of the product’s operating environment or platform, such as the types and versions of web browsers or operating systems that will be used.

I disagree. Requirements about the operating environment are part of the solution requirements, not external constraints. They guide the implementation, sure, but that’s just regular development. Requirements, by nature, influence how the system is built. Okay, so we need to support Google Chrome as the browser — fine, we’ll design accordingly, taking that into account. How is that different from accommodating any other requirement like support for a specific feature?

■ Required development conventions or standards. (For instance, if the customer’s organization will be maintaining the software, the organization might specify design notations and coding standards that a subcontractor must follow.)

Exactly — yep. The example in parentheses makes it clear why this is a valid constraint.

■ Limitations or compliance requirements imposed by regulations or other business rules.

Yes — business rules (e.g. legal requirements around data storage in a given country or domain) are absolutely legitimate sources of constraints.

■ Interfaces to other existing systems, such as data formats and communication protocols.

Absolutely: if we need to integrate with something, that “something” might dictate how we store or encrypt the data we send. A third-party service might say, “Sure, we’ll open up our API to you — but only if your customer data is stored on your end in this exact encrypted format.”

■ Restrictions because of the size of the display, as when running on a tablet or phone.

Don’t agree — for the same reasons mentioned earlier. Screen size is part of the environment. If we’re building a system for the iPhone, its dimensions and specs are just requirements for where the system will run. Do these factors influence developer decisions? Yes, of course — just like any other requirement. But I don’t see how they’re external constraints.

These aren’t all of them, of course — but to me, they’re the most interesting and illustrative examples from Mr. Wiegers’ book.

Here are a few more examples from him that I find helpful:

CON-1. The user clicks at the top of the project list to change the sort sequence. [specific user interface control imposed as a design constraint on a functional requirement]

CON-2. Only open source software available under the GNU General Public License may be used to implement the product. [implementation constraint]

CON-3. The application must use Microsoft .NET framework 4.5. [architecture constraint]

CON-6. All textual data used by the application shall be stored in the form of XML files. [data constraint]

But then here’s another excerpt worth examining:

Note that some of these constraints exist to comply with some perhaps-unstated quality expectation. Ask why each constraint is imposed to try to reach that underlying quality requirement. Why must open-source software be used, as stated in CON-2? Perhaps because of a desire for increased modifiability, so that’s the requirement that leads to the constraint.

Here again, I’ll push back on the maestro a bit — or maybe just try to extend the thinking. So what’s the actual constraint here? If, based on a modifiability requirement, the development team chooses to use only open-source software, then this isn’t a constraint at all — it’s a straightforward internal design decision about how to implement a stated requirement.

However, if this mandate comes from an external stakeholder, then:

You investigate — “Why exactly like this?”
You find out that the stakeholder chose this solution to fulfill an underlying need (e.g., modifiability).
You reflect that back: “Okay, so if extensibility is what you really care about, maybe let us decide how best to implement that?”
If they agree — then CON-2 doesn’t need to be written down at all.
But only if they don’t agree (and they have the authority to enforce it), does this become a legitimate constraint.

Now here’s what IREB has to say about sources of constraints:

When specifying constraints, the following categories of constraints should be considered:

▪ Technical: given interfaces or protocols, components, or frameworks that have to be used, etc.

▪ Legal: restrictions imposed by laws, contracts, standards, or regulations

▪ Organizational: there may be constraints in terms of organizational structures, processes, or policies that must not be changed by the system.

▪ Cultural: user habits and expectations are to some extent shaped by the culture the users live in. This is a particularly important aspect to consider when the users of a system come from different cultures or when Requirements Engineers and developers are rooted in a different culture to the system’s users.

▪ Environmental: when specifying cyber-physical systems, environmental conditions such as temperature, humidity, radiation, or vibration may have to be considered as constraints; energy consumption and heat dissipation may constitute further constraints.

▪ Physical: when a system comprises physical components or interacts with them, the system becomes constrained by the laws of physics and the properties of materials used for the physical components.

▪ Furthermore, particular solutions or restrictions demanded by important stakeholders also constitute constraints.

What makes me a bit uneasy are the italicized items:

Organizational seems to me like regular business rules, which — if relevant to the solution — should be reflected in the requirements. How exactly do these become constraints on design rather than just requirements the system must meet?

Same goes for Cultural: can user habits and expectations really dictate development process or technical choices? Would love to see concrete examples here to make that clear.

To sum up:

Understanding constraints and working with them effectively is incredibly useful.

Without that understanding, the development team may overlook these issues — and by the time they realize, it may be too late (think: major architecture changes leading to massive cost overruns).

But with this understanding — and with an analyst trained to look for them — the team can work with a clear list of things that must be considered during their creative implementation phase.

Basic algorithm for working with constraints:

1) Identify them — notice them in conversations, go through a checklist, study relevant laws and API docs, think through where constraints might be lurking in your project context.
2) Check if they’re truly unavoidable — ask: “Is this really a constraint? What happens if we remove it?”
3) Pass them to the team — ideally in the SRS or on a dedicated Confluence page — along with a tissue to wipe away the tears.