Requirements describe, in business or technical terms, the necessary properties, qualities, and characteristics of the desired solution. The customer should provide all requirements, but a good interview with the right people is needed to gain all the requirements that form the basis for the design. It’s possible that different requirements may conflict with each other, or that they may change through discussion and negotiation.

Constraints are not necessarily issues or limitations; they can also be related to business processes, a business decision, a business policy, or a technical limitation. In most cases, they are mandatory requirements. Some common constraints are, for example, the usage of existing hardware (or using a specific vendor for all the hardware), or regulatory requirements. Budget restrictions and timelines could be classified as constraints (for example, if there is a mandatory milestone in the timeline) or requirements, depending on the case.

Assumptions could also be expectations about the implementation, but usually, they are related to what cannot be confirmed during the assessment or design phases. Of course, at some point, assumptions must be validated, or the respective design areas are at risk (and you must analyze their impact through risk management). All the risks must be documented and rated based on the severity of the risk and the type of impact, and must be addressed with a mitigation plan or recommendation (more details on risk analysis will be provided in Chapter 12, Business Continuity and Disaster Recovery).

For technical assessment, in order to gain data from the existing environment refer to Chapter 3, Analysis and Assessment of an Existing Environment.