This section describes
constraints on the requirements and the eventual design of the product.
4a. Solution constraints
Content
This specifies constraints
on the way that the problem must be solved. You can think of these as mandated
solutions. Carefully describe the mandated technology, include the appropriate
version numbers, and a measurement of how you will test compliance. If possible,
you should also explain the reason for using the technology.
Motivation
To identify constraints
that must be part of the final product. Your client, customer or user may have
design preferences. If these are not met then your solution is not acceptable.
Examples
The product must use the current 2-way radio system to
communicate with the drivers in their trucks.
The product must use the Windows NT operating system.
The product must be a hand-held device.
Considerations
We want to define the boundaries
within which we can solve the problem. Be careful because anyone who has
experience/exposure to a piece of technology tends to see requirements in terms
of that technology. This tendency leads people to impose solution constraints
for the wrong reason and it's very easy for untrue constraints to creep into a
specification. If you impose untrue constraints the danger is that you do not
have the creative freedom to come up with the best solution to the problem. The
solution constraints should only be those that are absolutely non-negotiable.
In other words, however you solve this problem you must use this particular
technology. Any other solution would be unacceptable.
4b. Implementation
environment
Content
This describes the
technological and physical environment in which the product will be installed.
This includes automated, mechanical, organizational and other devices. These
include the non-human adjacent systems.
Motivation
To describe the
technological environment into which the product must fit. The environment
places design constraints on the product. This part of the specification
provides enough information about the environment for the designers to make the
product successfully interact with its surrounding technology.
The operational requirements
are derived from this description.
Examples
This can be shown as a
diagram, with some kind of icon to represent each separate device or person
(processor). Draw arrows to identify the interfaces between the processors and
annotate them with their form and content .
Considerations
All the component parts of
the current system, regardless of their type, should be included in the
description of the implementation environment.
If the product is to affect,
or be important to the current organization, include an organization chart.
4c. Partner applications
Content
This describes applications
that are not part of the product but with which the product will collaborate.
These can be external applications, commercial packages or pre-existing
in-house applications.
Motivation
To provide information
about design constraints that are caused by using
partner applications. By describing or modeling these partner applications, you
discover and highlight potential problems of integration.
Examples
This section can be
completed by including written descriptions, models or references to other
specifications. The descriptions must include a full specification of all
interfaces that will have an effect on the product.
Considerations
Examine the work context
model to determine if any of the adjacent systems should be treated as partner
applications. It might also be necessary to examine some of the details of the
work to discover relevant partner applications.
4d. Off-the-shelf software
Content
This describes applications
that must be used to implement some of the requirements for the product.
Motivation
To identify and describe
existing commercial, free, open source, etc. products that must be incorporated
into the eventual product. The characteristics, behavior and interfaces of the
package are design constraints.
Examples
This section can be
completed by including written descriptions, models or references to supplier's
specifications.
Considerations
The use of a specific
package has been mandated. When gathering requirements you may discover
requirements that are in serious conflict with the behavior and characteristics
of the package. Keep in mind that the use of the package was mandated before
the full extent of the requirements was known. In light of your discoveries you
must consider whether the package is a viable choice when all the requirements
are known. If the use of the package is not negotiable, then the conflicting
requirements will have to be discarded.
You should also consider if
there are any legal implications arising from your use of the software. You
might also cover this in section 17 — Legal Requirements.
4e. Anticipated workplace
environment
Content
This describes the
workplace in which the users will work and use the product. This should
describe any features of the workplace that could have an effect on the design
of the product.
Motivation
To identify characteristics
of the physical workplace so that the product is designed to compensate for any
difficulties.
Examples
The printer is a considerable distance from the user's desk.
This constraint suggests that printed output should be de-emphasized.
The workplace is noisy, so audible signals might not work.
The workplace is outside so the product must be waterproof, have
displays that are visible in sunlight and allow for the effect of wind on any
paper output.
The user will be standing up or working in positions where he
must hold the product. This suggests a hand-held product but only a careful
study of the users' work and workplace will provide the necessary input to
identifying the operational requirements.
Considerations
The physical work
environment constrains the way that work is done. The product should overcome
whatever difficulties exist, however you might consider a redesign of the
workplace as an alternative to having the product compensate for it.
4f. How
long do the developers have to build the system?
Content
Any known deadlines, or
windows of opportunity, should be stated here.
Motivation
To identify critical times
and dates that have an effect on product requirements. If the deadline is
short, then the requirements must be kept to whatever can be built within the
time allowed.
Examples
To meet scheduled software releases.
There may be other parts of the business or other software
products that are dependent on this product.
Windows of marketing
opportunity.
Scheduled changes to the business that will use your product.
For example the organization may be starting up a new factory and your product
is needed before production can commence.
Considerations
State
deadline limitations that exist by stating the date and describing why it is
critical.
Also identify prior dates where parts of your product need to be available for
testing.
You should also ask
questions about the impact of not meeting the deadline like:
What happens if we don't
build the system by ......?
What is the financial
impact of not having, the system by?
4g. What
is the financial budget for the system?
Content
The
budget for the system, expressed in money or available resources.
Motivation
The requirements must not
exceed the budget. This may constrain the number of requirements that can be
included in the product.
The intention of this
question is to determine if the product is really wanted.
Considerations
Is it realistic to build a
product within this budget? If the answer to this question is no, then either
the client is not really committed to building the product or does not place
enough value on the product. In either case you should consider whether it is
worthwhile continuing.