This phase of the life cycle is where all of the conceptual items come together, hopefully in a form or fashion that's ready for  the actual creation of code to start. If there is a formal PMP document as a result, its outline might look something like this:

• Business purpose
• Objectives
• Goals
• What's included
• What's excluded
• Key assumptions
• Project organization:
  • Roles and responsibilities
  • Stakeholders
  • Communication

• Risks, issues, and dependencies
• Preliminary schedule of deliverables
• Change management
• Risk and issue management

Developers won't need all of these items, but knowing where to look for various bits and pieces of the information they will need (or, in some cases, who to contact for information) is advantageous, so:

The Business purpose, Objectives, and Goals sections should, ideally, collect all of the original vision information (from the initial concept/vision phase) with whatever details have been added or changes made after the concept design was complete. These will, in all probability, include the starting points for the Requirements analysis and definition efforts that go on during the development-specific phases of the life cycle. In addition, the What's included, What's excluded, and Key assumptions sections, between them, should expose what the actual scope of development looks like, as well as providing high-level design decisions and any relevant high-level system modeling information. Risks, issues, and dependencies may provide specific items of concern or other interests that will help shape the development efforts. Finally, Change management will set expectations (at a high level, at least) for what processes are expected or planned for as changes to the system are made.

People in a position to answer questions or make decisions about the system's implementation that fall outside the scope of pure development will probably be listed in the Roles and responsibilities and/or Stakeholders sections, though there may be specific established processes for raising those questions in the Communication section.

Even without formal documentation around project management expectations, much of the information noted previously should still be made known to development staff—the less time spent having to track down who can answer a question, the more time can be devoted to actually writing code, after all.