Define the problem at a fairly high level assuming the reader knows nothing about the feature you’re adding, but knows OpenMAMA very well.
Detail requirements in this section - you may find that a diagram or list of bullets will help light the way here. Be sure to keep all documentation succinct and unambiguous here.
You may only present only one choice if the solution is obvious and leave this section out, but where there are many possible solutions, this is a good chance to explain why your particular option was chosen, and to demonstrate to the community that more than one option was considered.
Repeat this section to taste. Summary detail of this choice. Do not go into low level implementation detail if it can be avoided. Even for the chosen option.
Brief description of the pros of this choice. Most likely bullet points.
Brief description of the cons of this choice. Most likely bullet points.
Include detailed summary description of the choice taken and explain the rationale behind it.
Repeat this section to taste. Detail related changes. E.g. a component may be a specific language or flow.
Detail any changes required to the interface or any new interfaces being introduced. Provide examples.
Any changes to underlying data structures (particularly shared ones) should be detailed here.
If the component is unit testable, specify the details here. No specific method names required - simply a list of the general things you plan on unit testing (e.g. null conditions, boundary tests).
If the component changes behaviour in how it interacts with other components, detail what has changed here (e.g. wire format has changed, need to test backwards compatibility)
Refer to this when considering this section.
If application interface is changed, document it here and justify the impact is worth the improvement.
If the bridge interface is changed, document it here and justify the impact is worth the improvement.
If any internal interface is changed, document it here and justify the impact is worth the improvement.