4. Mandated ConstraintsConstraints 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 ConstraintsSolution constraints are design decisions that mandate how the final product must look or what technology it must use or comply with. For example:
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 SystemSometimes the constraint reflects management's desire not to buy a new load of hardware.
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 ApplicationsAlmost 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.
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 SoftwareThis 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 EnvironmentThis section describes the workplace. Include it only if the workplace could have an effect on the requirements for the product. 4f. Schedule ConstraintsThis 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 ConstraintsThis 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.
|