Discovery, Analysis, Specification, Architecture, and Design

What level of analysis belongs in the Project Charter, the requirements specification, the end of what the Unified Method calls Initiation and then Specification? How do we reconcile the need for incremental and iterative refinement of work products with contracts that pay for deliverables, not some esoteric definition of earned value analysis.
Let's start by distinguishing between business analysis and functional specification.
Business analysis encompasses business process analysis (as-is and to-be), functional requirements and non-functional requirements, the conceptual data model, harvesting business rules, identification of business use cases based on examination of the process models, and identification of internal and external interfaces. The conceptual data model can include the glossary of business terms.
Functional Specification includes the entity-relationship diagram, the data elements dictionary, the web page hierarchy diagram, the storyboard (wireframes and user narrative), re-factored business rules, and the use cases.
Skilled business analysts with experience working throughout the system development life cycle can do all the work in conjunction with customer subject matter experts for both the analysis and the specification.
Architectural work occurs on two levels: end-to-end and application-specific.
End-to-End architecture addresses existing enterprise capabilities and standards such as those for databases, programming languages, internal and external portals, industry standards for data exchange, existing applications that may be re-used as a web service, investments needed for the project that can contribute to future projects throughout the enterprise, interoperability across platforms such as content management, imaging, business intelligence, and the number and type of environments needed for development, testing, acceptance and staging, and production.
Application architecture addresses more than just the presentation, business, and data access layers. Within the business layer, application architecture addresses the buy versus build approach to managing and executing business rules, orchestration and workflow, and the determination of components within the application. Component boundaries need to recognize future re-use opportunities throughout the enterprise as well as what makes immediate sense for the current application.
Only once the project begins work on the detailed design's work products do the software design specialists need get involved. Designers will work with architects on the scope of components described above to meet application as well as future enterprise opportunities. Designers will address buy versus build for handling workflow, orchestration, and business rules. Customer and project architects and designers will establish how to implement the integration tier that supports interfaces to external systems as well as interoperability with legacy systems within the enterprise. Increasingly, projects will implement an enterprise service bus (ESB) product to manage the integration tier without the fanfare of declaring victory for service oriented architecture. The ESB selection for the integration tier can result from something as simple as a buy versus build analysis on how to manage data transformations, orchestration, logging, guaranteed delivery, and other responsibilities when moving data from one system to another.