Understanding Design Constraints


As we described in Chapter 20, design constraints typically impose limitations on the design of the system or the processes we use to build a system.

We provided the following definition

restrictions on the design of a system, or the process by which a system is developed, that do not affect the external behavior of the system but that must be fulfilled to meet technical, business, or contractual obligations.

Sources of Design Constraints

While the sources are varied, design constraints typically originate from one of three sources: restriction of design options, conditions imposed on the development process, and regulations and imposed standards.

Restriction of Design Options

Most requirements allow for more than one design option. Whenever possible, we want to leave that choice to the designers rather than specifying it in the requirements, for they will be in the best position to evaluate the technical and economic merits of each option. Whenever we do not allow a choice to be made ("Use Oracle DBMS"), the design has been constrained, and a degree of flexibility and development freedom has been lost.

Conditions Imposed on the Development Process

Another type of design constraint occurs when a requirement is imposed on the process of building software. These types of design constraints can often be found when specifying the team's developmental infrastructure. Here are some examples.

  • Compatibility with existing systems : "The application must run on both our new and old platforms."

  • Application standards : "Use the class library from Developer's Library 99-724 on the corporate IT server."

  • Corporate best practices and standards : "Compatibility with the legacy database must be maintained ." "Use our C++ coding standards."

There may be many such sources and rationales, and the designers may have to accept them whether they like them or not. But it's important to distinguish them from the other types of requirements, for many of the constraints may be arbitrary, political, or subject to rapid technological change and might thus be subject to review or renegotiation at a later point.

Regulations and Imposed Standards

Another important source of design constraints is the body of regulations and standards under which the project is being developed. For example, the development of a medical product in the United States is subject to a significant number of Food and Drug Administration standards and regulations, imposed not only on the product but also on the process by which the product is developed and documented. Typical regulatory design constraints might include regulations and standards from the following:

  • Food and Drug Administration (FDA)

  • Federal Communications Commission (FCC)

  • Department of Defense (DOD)

  • International Organization for Standardization (ISO)

  • Underwriters Laboratory (UL)

  • International standards such as the German Industrial Standard (DIN)

Typically, the body of regulation imposed by these types of design constraints is too lengthy to incorporate directly into your requirements. In most cases, it is sufficient to include the design constraints by reference into your package. Thus, your requirements might appear in the form "The software shall fail safely per the provisions of T ¼V Software Standard, Sections 3.1 “3.4."

Incorporation by reference has its hazards, however. Where necessary, you should be careful to incorporate specific and relevant references instead of more general references. For example, a single reference of the form "The product must conform to ISO 601" effectively binds your product to all the standards in the entire document. As usual, you should strive for the "sweet spot" between too much specificity and not enough. (We'll explore this issue further in Chapter 23.)

Handling Design Constraints

Almost all projects have some design constraints. Generally, the best way to handle them is to follow these guidelines.

  • Distinguish them from the other requirements. For example, if you identified other software requirements with a tag, such as "SR," you might consider using "DC" for design constraints.

  • Include all design constraints in a special section of your requirements, or use a special attribute so they can be readily aggregated. That way, you can easily find them and review them when the factors that influenced them change.

  • Identify the source of each design constraint. By doing so, you can use the reference later to question or revise the requirement. You may wish to supply a specific bibliographic reference in the case of regulatory standard references. That way, you can find the standard more easily when you need to refer to it later.

  • Document the rationale for each design constraint. Write a sentence or two explaining why the design constraint was placed in the project. This will help remind you later of the motive for the design constraint.

Are Design Constraints True Requirements?

You could argue that design constraints are not true software requirements because they do not represent one of the five system elements in our elaborated definition. But when a design constraint is elevated to the level of legitimate business, political, or technical concern, it does meet our definition of a requirement as something necessary to satisfy a contract, standard, specification, or other formally imposed documentation.

In those cases, it's easiest to treat the design constraint just like any other requirement and to make certain that the system is designed and developed in compliance with that design constraint. However, we should strive to have as few design constraints as possible since their existence may often restrict our options for implementing the other requirements, those that directly fulfill a user need.

A Cautionary Tale

We were working with a Fortune 500 company well known in the industry for its adherence to process and procedure. Imagine our surprise when we found that the company was totally paralyzed in its current requirements collection activities because the team could not agree on whether certain requirements were functional requirements, nonfunctional requirements, or design constraints. In effect, the team's ability to move ahead with its project was stalled on semantic quibbles. We told the team that it didn't matter, just move on with something!

The value of the classification scheme is simply to spur your thinking, to assist you on your search for "Undiscovered Ruins," and to help you think about these things in different ways. But in a very real sense, the classification doesn't matter, so long as you understand that the requirement is something that you, or the system, will be measured against. Moving ahead with some sort of organized effort is superior to not moving ahead while preparing the perfect requirements categorization plan.


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
Year: 2003
Pages: 257

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net