Site problems Program Requirements and Constraints Perhaps not so evident on a day-to-day basis, but nonetheless important, the stakeholder is the ultimate Customer (the people who will likely be the recipient of the products or services). The Customer may or may not also be the Authority. The Program Office must work hand-in-hand with the Customer to translate the objectives into meaningful customer requirements and, in-turn, the more comprehensive product and/or services requirements that will be delivered to the program. The Program Office will needs to completely derive and document the requirements. Requirements  must be defined in the beginning of any program to avoid months of activity working toward the wrong objectives or in the wrong direction. The requirements document must avoid errors, ambiguities, and misunderstandings. A good requirements document possesses attributes such as clear, complete and verifiable requirements supported by rigor of analysis. Finally, the requirements should be agreed upon by the program stakeholders. The SMC Systems Engineering Handbook provides guidance and methods to define technical requirements for Space and Launch systems.  Program constraints, such as program schedule and funding constraints, must also be taken into account. There are often many other types of constraints -- security, the use of pre-specified resources that dictate interface constraints, constraints imposed by the environments where the services are performed or services are used -- to name just a few. The Program Office should always keep the Customer informed of all significant requirements and constraints as they are understood.