Solution Constraints

Your specification should describe any mandated designs or solutions to the problem. For example, you may be told that the only acceptable solution is one that will run on a mobile phone. Your management or some other party may have other expectations about the eventual design, such that no other design is allowable. While we warn you against designing the solution before knowing all the requirements, it may be that for some overriding reason marketing, cultural, managerial, political, expectations, or financialonly one acceptable design solution exists. If this is the case, it must be part of your specification.

Any partner or collaborative applications should also be brought to light and recorded at the blastoff. Partner applications are those other applications or systems with which your product must cooperate. For example, your product may have to interact with existing databases, reporting systems, or Web-based systems. Thus the interfaces to those systems become constraints on your product. Mandated operating systems should also be included here.

Commercial off-the-shelf (COTS) and open source applications, if they are to be used, are recorded under the Constraint heading. It may be that your product must interact with COTS or open source software, or perhaps your product must incorporate COTS/open source software in the eventual solution. There may be good reasons for mandating this cooperationbut then again, there may not. The blastoff is the ideal opportunity for you to reach a consensus with the stakeholders as to whether the decision to incorporate ready-built software is appropriate for your situation.