Section 4. Mandated Constraints


4. Mandated Constraints

Constraints are globalthey are factors that apply to the entire product. The product must be built within the stated constraints. Sometimes we know about the constraints, or they are mandated before the project gets under way. They are probably determined by management and are worth considering carefullythey restrict what you can do and so shape the product.

Constraints are requirements. That is, they are like the other requirements you gather during your trawling. The difference is that constraints are mandated, usually at the outset of the project.

4a. Solution Constraints

Solution constraints are design decisions that mandate how the final product must look or what technology it must use or comply with. For example:

The product shall be able to be downloaded to 3G mobile phones.


Here we see that management or marketing has decided the product will be successful if it is designed to comply with this constraint. Similarly, the client organization may have a standard stating that all new products are to use a specified programming language, or run on certain computers, or fit in with preexisting products.

Many projects chose at the outset to make use of available software products, such as shrink-wrap or open source products. The solution constraint is that the product under development must make use of the off-the-shelf (OTS) products and correctly interact with them.

While we discourage you from including any design details in your requirements specificationdesign and requirements are not the same thingthere will always be some mandates about the design dictated by the client or the organization. It would be unrealistic and unacceptable to ignore them.

However, despite this caveat and some obvious advantages of using certain designs, we warn you to examine the motive behind all design constraints. Is it given as a constraint because using the mandated technology offers a realistic advantage? Is there a real business need for this kind of solution? Or could it be that you are being given a perceived solution to the problem in lieu of a genuine statement of the true business need?

4b. Implementation Environment of the Current System

Sometimes the constraint reflects management's desire not to buy a new load of hardware.

The product shall run on the existing network of personal computers.


This constraint restricts any computerized solution to the existing technology. Thus the requirements may not specify a product that is so elaborate as to need different computing capabilities to implement it.

This section is also used to describe the current environment, or at least that part of it used by the new product.

4c. Partner or Collaborative Applications

Almost all software projects have to construct a product that must interact with several other software products both inside and outside the owning organization. This section sets out for your developers what those other products are and explains why they are considered partners to the current product.

The product shall interface with the Rosa DM31 weather stations.

The product shall interface with the Thermal Mapping Database.

The product shall interface with the Road Engineering Computer System.


Constraints might also be written when the solution intends to use OTS software as part, or all, of the new product. These types of restrictions are covered in section 4d of the specification. Just as these sections describe the technological environment, section 4e describes the anticipated workplace environment. This gives a picture of the workplace and any features, including the users who could have an effect on the design of the product.

4d. Off-the-Shelf Software

This section is where you specify any brought-in software. Because of the abundant supply and myriad capabilities of OTS software available to almost all projects, it usually makes sense to use some of these products. This section identifies which brought-in products you intend to use. You might also use this section to specify the interfaces and special functionality necessitated by the OTS product; however, we find it is less confusing to include that functionality along with your other functional requirements.

4e. Anticipated Workplace Environment

This section describes the workplace. Include it only if the workplace could have an effect on the requirements for the product.

4f. Schedule Constraints

This section specifies the time allowed to build the product. When the requirements team knows the deadline, it helps team members restrict their requirements gathering to what it is possible to build in the allowed time.

4g. Budget Constraints

This section shows the allowable resourcesmoney or effort or peoplefor the project. It is intended to restrict the wildest ambitions and to prevent the team from gathering requirements for an Airbus 380 when the budget can buy only a Cessna.

The budget for building the product is $500,000.





Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

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