Coloring Inside the Lines: Constraints in Software Development

Jan 12, 2025
3562 Views
0 Comments
5 Likes

 

Constraints of various kinds restrict the choices available to designers, developers, and project managers, hopefully for good reasons.

 

Coloring Inside the Lines: Constraints in Software Development

 

Software consultant Tim Lister defined project success as “meeting the set of all requirements and constraints held as expectations by key stakeholders.” There’s a vast body of literature on software requirements. In contrast, little is written about the various kinds of constraints that stakeholders might impose on a software initiative. Identifying, communicating, and working within constraints are essential aspects of successful software development. Let’s begin with a definition:

“A constraint is a restriction that limits the choices available for a product’s specification, design, construction, configuration, or project management.”

A software initiative is subject to three major classes of constraints: product, project, and process.

Product Constraints

A product constraint specifies a capability or characteristic that the solution being developed either must or cannot possess. This makes constraints sound rather similar to requirements, doesn’t it?

Product constraints are indeed a type of requirement information. The business analyst (BA) needs to explore constraints during requirements elicitation and document them so that designers and developers can address them properly. Some people consider all requirements to be constraints, but I don’t. More important than what you call them is to discover, understand, validate, document, communicate, and respect those significant pieces of information.

During elicitation, listen for keywords that indicate a design or implementation constraint is coming, such as must, must not, may not, and cannot:

 “…cannot exceed <some limit>

“…must use <a specific user interface control>

“…must use <a specific encryption technique>

“…must be written in <a specific programming language>

Don’t simply transcribe the stakeholder’s statement of a constraint. Ask why the constraint exists, confirm its validity, determine if any assumptions are being made—which might be obsolete or invalid—and record the rationale for including the constraint as part of the requirements. Recording that rationale can quickly resolve debates that might arise if a developer asks, “Do I have to do it like this, or would this other approach I thought of be okay?”

Design constraints that are included in the requirements specify that some aspect of the product design must be done in a certain way. Be alert for requirements that incorporate specific user interaction language: “When the user taps on Submit…” The BA should determine whether such statements are true restrictions or just a solution idea someone had. If it’s not a real constraint, generalize the requirement language so as not to preclude other creative design approaches: “When the user selects Submit…”

It’s fine to include solution ideas with requirements. Just make sure the reader knows whether it’s a restriction (“You must do it this way!”) or a thought-provoking suggestion (“Here’s an idea we had so you can see what we’re thinking.”). The BA should avoid recording premature, unnecessary, inadvertently imposed, or excessively stringent constraints as requirements.

Constraints can originate from many sources. Devices that contain embedded software often must respect physical constraints such as size, weight, materials used, shapes, both physical and software interfaces, and sustainability issues. The computing environment, platform, operating system, physical infrastructure, and other technological considerations can impose limits (such as on the number of concurrent users or transactions) because of memory, processor power, disk space, network speed and capacity, security, or compatibility.

Business rules dictate many constraints. In fact, per the Business Rules Group, “A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business.” A business rule could state that certain actions must or must not or may not be performed, or that only certain user roles can perform particular activities.

Complying with a constraining business rule in a software solution might lead to functionality that enforces user access, privilege levels, or similar usage restrictions. Constraints can specify how the system must perform certain calculations. Products that are subject to regulatory certification, such as transportation and medical devices, must comply with a whole raft of established constraints that are documented as business rules or standards.

Nonfunctional requirements often impose constraints as well. Security requirements provide a good example. Corporate standards or industry best practices often dictate specific protocols for user and device authentication. Are biometrics allowed for user authentication in your app, or must users employ an authentication app, physical security key, texted or emailed secret number, or other multifactor authentication technique? There are numerous ways to implement MFA; your requirements might specify which methods are required, allowed, and not permitted.

Other sources of product constraints include external industry, product, or government standards (such as data protection and access security) and compatibility with legacy systems or related product family members. As with requirements, the BA needs to cast a large net to make sure that the team identifies pertinent product constraints early in the process. Overlooking constraints can lead to performing extensive, unplanned design and code rework. Nobody wants that.

Document validated product constraints in your software requirements specification. They should conform to the practices of writing clear requirements, being complete, unambiguous, and so forth.

Project Constraints

When people talk about software constraints, they most commonly mean project constraints. These are often represented in the form of the classic iron triangle of time, cost, and scope:

Constraints: Time, cost, scope - classing iron triangle

Also called the triple constraint, the fundamental point is that if one of the three aspects changes, the others must be adjusted to accommodate the change. The project manager must make trade-off decisions depending on how much flexibility they have around each of the three dimensions. That triangular model is overly simplistic and is represented in various ways. Quality shows up in some of the diagrams, but not often and not in a consistent way.

I find it more illuminating to think in terms of five project dimensions: features (or scope), schedule (or time), cost (or budget), staff, and quality. Treat quality as a discrete dimension, as people routinely trade off quality for speed or scope, rightly or wrongly. I don’t lump staff and budget together and call the combination “resources” as is sometimes done. Sometimes a project team has adequate funding but can’t hire more people. Some people also consider risk to be a constraint, as risk analysis could lead a team to restrict its technology choices or guide business strategies.

Each of these five dimensions can take one of three roles on any given project: a constraint, a driver, or a degree of freedom. A dimension that provides no flexibility is a constraint. Examples include an immutably fixed delivery date, a limited team size, a fixed budget, or a nonnegotiable feature set. Those dimensions that are not constraints offer some adjustability. The project manager’s challenge, then, is to adjust the more flexible dimensions so the project achieves its success drivers within the limits that the constraints impose.

An important safety tip: Not all five dimensions (or three, if you prefer the iron triangle) can be inflexible constraints. Something must be able to give whenever project realities change. The team and its leadership need a shared understanding of which dimensions are constraints and which are flexible at the outset.

Process Constraints

Process constraints limit or dictate the approaches the development team can take or the development artifacts it produces, often because of organizational or external standards. I know of a large organization that mandated an enterprise agile framework for all of its projects, whether or not that was the optimal approach for a particular initiative. That’s how the teams had to operate, per management decree, even when it was a bad fit for the activity. In an organization that mandates the use of, say, Scrum, the teams must fill the team roles defined by Scrum; perform the Scrum activities, events, and ceremonies; and create Scrum artifacts, such as a product backlog, sprint backlog, and definition of done.

Some products that are subject to regulatory review and certification must be developed using certain protocols and standards. They might need to produce particular deliverables that contain specified contents presented in certain forms. Certain checkpoint reviews and approvals may be required. If your organization wishes to maintain its ISO 9000 certification, its quality management system must conform to established standards. To achieve a specific CMMI maturity level, an organization needs to establish—and follow—appropriate processes.

Other possible sources of process constraints include these:

  • Tools and diagram conventions used for software analysis and design modeling
  • Templates required for deliverable documents
  • Development environments, configuration management tools and repositories, and the like
  • Programming languages or language features to be used or avoided for portability or compatibility reasons
  • Ways to represent requirements
  • Security and reliability issues regarding the use of tools or services from third-party vendors, such as large language models (LLMs) or other AI products, cloud-based services, and the like
  • Project planning, tracking, and reporting conventions

The Importance of Constraints

Identifying relevant constraints is an essential aspect of project planning and requirements development. Planners must know where their flexibility lies so they can respond to changing realities. Designers have to ensure that their products conform to pertinent rules, regulations, policies, and standards.

Design constraints aren’t necessarily bad. They can improve learnability and usability by providing consistency for logically similar operations both within and across products. An example is the ways I can delete objects from my phone. Different apps use a variety of interaction techniques, visual design elements, and language. The method can vary depending on whether you’re deleting a single item or multiple items at once. You may or may not need to confirm deletion. It gets confusing. Defining user interface standards imposes constraints on the UX designers, yes, but to the users’ benefit.

Creative people might not like having limits placed on how they do their work, but that’s the reality. Understanding constraints up front can lead to more appropriate products produced less chaotically.


Author: Karl Wiegers

Karl Wiegers is the author of numerous books, including Software Requirements (with Joy Beatty), Software Requirements Essentials (with Candase Hokanson, Software Development Pearls, The Thoughtless Design of Everyday Things, and Successful Business Analysis Consulting.

Copyright 2006-2025 by Modern Analyst Media LLC