Include a high-level summary of the project - what are the high-level requirements, what is the scope of the project, are there any larger than usual risks involved, etc.

The audience of this summary is the MTM and will be used to endorse the project or not.

As we don't have revision history in JamJar, please use the following table instead to keep people aware of the changes made to the document.

Use this section to list the timing on any milestones or phases that are included in the project.

Use this section to explain why this project is beneficial to our clients.  Topics to cover can include:

• What will the end result be for the users?
• Who is the intended audience of this?
• What are the objectives (KPIs) to determine success?
• What are the success criteria?
• What, if any, dependencies exist?
• What is the competition doing?

If the project is more involved, you may want to use the more complete MRD template.

Use this section to explain the actual functional requirements needed

• Use cases
• Links to mock-ups, designs, wire-frames (see right-hand column for file uploader)
• Functional descriptions of system responses to user action
• Limitations / Constraints (i.e., if a field should only allow 8 character or only alpha-numerical characters)
• Technical dependencies (if any)
• Phases of implementation

In this section, provide information for the other groups in Webjam:

For Marketing - what are the key features of this new functionality that should be added to the marketing collateral?  Why is this feature so cool?

For Customer / Partner care - put in documentation on how this feature should be used so that customer / partner care can put together help guides, FAQ entries, or even training videos if the feature is complicated enough.

Add any known risks and/or side effects related to this project and any plans on how to handle.

This could include things like:

• performance
• security
• changes to notifications 
• migration plan required

To be filled in by the developer:

Architecture

[describe the architecture of the project, the structuring choices including programming language, third party tools, specific technologies that are going to be used and why (web services, Ajax, XSL/FO, XSLT, ..).

If there are interactions with other projects/modules, explain how it will be done and input & output parameters

If you plan to use a service from another company, explain how it will be done, what is the public API available from the provider, etc…

The project should be decomposed in software components. The role of each component and the links between them can be described here. For each of these components, the document should describe

• What it does
• The possible exceptions
• The internal data
• The external interfaces, including input and output data.]

Detailed specifications

[if you have UML diagrams, you can put them here]

Database schema changes

Updated code

Impact on existing code

[for example, if changes must be done in a class used by other modules, the impact must be describe here. It could be a change in its interface or a change in the behaviour …]

Dependencies

[Anything needed to complete the development must be listed here. For example, if an agreement with a service provider such as Amazon or eBay is mandatory to get the precise description of their API]