also the principal keeper of the users' vision of the end product, and of the process of deriving requirements from and implementing that vision. Architects do not follow exact procedures. They communicate with users/sponsors in a highly interactive, relatively informal way— together they extract the true requirements necessary for the designed (end) system. The architect must remain constantly in communication with the end users and with the (principal) systems engineers. Therefore, the architect must be intimately familiar with the users' environment and problem, and with the engineering environment(s) of likely solution spaces. High level requirements The user requirements specification should be a joint product of the users and architect: the users bring their needs and wish list, the architect brings knowledge of what is likely to prove doable within the cost, time and other constraints. When the users needs are translated into a set of high-level requirements is also the best time to write the first version of the acceptance test, which should, thereafter, be religiously kept up to date with the requirements. That way, the users will be absolutely clear about what they are getting. It is also a safeguard against untestable requirements, misunderstandings, and requirements creep. The development of the first level of engineering requirements is not a purely analytical exercise and should also involve both the architect and engineer. If any compromises are to be made— to meet constraints- the architect must ensure that the final product and overall look and feel do not stray very far from the users' intent. The engineer should focus on developing a design that optimizes the constraints but ensures a workable, reliable, extensible and robust product. The provision of needed services to the users is the true function of an engineered system. However, as systems become ever larger and more complex, and as their emphases move away from simple hardware and software components, the narrow application of traditional systems development principles have been found to be insufficient— the application of more general principles of systems, hardware, and software architecture to the design of (sub)systems is seen to be needed. Architecture may also be seen as a simplified model of the finished end product— its primary function is to define the parts and their relationships to each other so that the whole can be seen to be a consistent, complete, and correct representation of what the users' had in mind— especially for