UML Weekend Crash Course™ - To Parent Directory

38
Friday Evening
Constraints
The second type of requirement is called a constraint. Constraints are limitations on or
boundaries around what you can do when you develop a solution for the system.
Constraints can apply to virtually any aspect of your project and the resulting system.
Why do you care about constraints Because constraints limit the options you have at
virtually every phase of the development life cycle. Consider the constraints on each of
these four development phases:
Requirements gathering: Limitations on client skills and experience drive the type
of solutions that you can offer. The application may need to offer substantially
more help features for less-skilled users, whereas extremely skilled or experienced
users might reject the same features as a hindrance.
Analysis: Limitations imposed by policies and procedures, laws, contracts, and
industry standards restrict the models that you develop to document the problem
domain. You may not be able to be as creative as you’d like when the law or a contract
says that it has to be done a particular way. For example, the inventory system
must abide by generally accepted accounting principles. Failure to do so risks an
audit, fines, or worse.
Design: Programming languages, databases, middleware, and just about every technology
impose specific limitations. These technologies often dictate field data types
and sizes, data conversions, communication protocols, and more. This limits the
options available to you to when you try to satisfy the system requirements. You
might want to network the warehouse to the accounting office a few blocks away
only to find the phone lines are over 30 years old and are currently tied up in a
massive upgrade project that is running badly behind schedule.
Implementation: Implementation technologies impose performance limitations
that often conflict directly with the performance requirements for the business. This
is, in fact, the motivation behind so much technological advancement (that is,
removing these bottlenecks so that technological constraints don’t sabotage business
constraints). The warehouse may want to transition to radio frequency data
entry, but the substation next door causes too much interference; the technology
may be ideal, but to overcome the interference problem would cost twice what has
been budgeted for the whole project.
Rules
Constraints are like mandates: It must be done this way! Rules are more like agreements:
We’ve talked about it and agreed that the invoice needs to include these items and have
these approvals. Rules need to be enforced, but if you find a better way to do it you can
always talk about it again and choose to change it. In the meantime, you agree to implement
and follow the decision consistently. Rules can be anything from the look of a form or
screen, to a business process with checks and approvals, number of copies, and waiting periods.
Constraining policies are typically upper-management decisions or directives from the
business environment (legislation, regulations, and so on) and tend to be separate from the
processes that implement them.
In the case study, the inventory control system requires you to complete the receiving
documentation with the prescribed details about the shipper, products, shipping company,