• Concentrate on making this assertion and only this assertion in a succinct set of 1 to 3 paragraphs
• A common mistake is to explain too much of the problem context first. Instead, state the problem essentially as a claim, and leave explanations supporting your claim to the next part, "Why it is not already solved."

• Your new idea need not solve every problem but it should solve at least one that is not already solved
• This is the place to provide a succinct description of the problem context giving enough information to support the claim that a problem exists, made in the preceding problem declaration.

• A succinct statement of why the reader should care enough to read the rest of the paper.

• This should include a statement about the characteristics of your solution to the problem which 1) make it a solution, and 2) make it superior to other solutions to the same problem.

• The short statement below is often all you need, but you should change it when your paper has a different structure, or when more information is required to describe what a given section contains. If it isn’t required then you don’t want to say it here.

• Resist the urge to point out only flaws in other work. Do your best to point out both the strengths and weaknesses to provide as well rounded a view of how your idea relates to other work as possible
• In a social and political sense it is very smart as well as ethically superior to say good things, which are true, about other people’s work. A major motivation for this is that editors and program committee members have to get a set of reviews for your paper. The easiest way for them to decide who should review it is to look at the set of references to related work (e.g., [1,2, 3]) to find people who are likely to be competent to review your paper. The people whose work you talk about are thus likely to be reading what you say about their work while deciding what to say about your work.
• Clear enough? Speak the truth, say what you have to say, but be generous to the efforts of others.

• Many times no one has solved your exact problem before, but others have solved closely related problems or problems with aspects that are strongly analogous to aspects of your problem

• Another way to look at this section is as a paper, within a paper, describing your implementation. That viewpoint makes this the introduction to the subordinate paper, which should describe the overall structure of your implementation and how it is designed to address the problem effectively.
• Then, describe the structure of the rest of this section, and what each subsection describes.

• This is the body of the subordinate paper describing your solution. It may be divided into several subsections as required by the nature of your implementation.
• The level of detail about how the solution works is determined by what is appropriate to the type of paper (conference, journal, technical report)
• This section can be fairly short for conference papers, fairly long for journal papers, or quite long in technical reports. It all depends on the purpose of the paper and the target audience
• Proposals are necessarily a good deal more vague in this section since you have to convince someone you know enough to have a good chance of building a solution, but that you have not already done so.

• Performance metrics
• Performance parameters
• Experimental design

• Presentation and Interpretation
• Why, how, and to what degree our solution is better
• Why the reader should be impressed with our solution
• Comments

• What the results do and do not say

• The most succinct statement of the problem in the paper. Ideally one sentence. More realistically two or three. Remember that you simply state it without argument. If you have written a good paper you are simply reminding the reader of what they now believe and of how much they agree with you.

• Again, the succinct statement that you have presented a solution
• Sometimes it works well to leave it at that and not even describe your solution here. If you do, then again state your solution in one or two sentences taking the rhetorical stance that this is all obvious. If you have a good solution and have written an effective paper, then the reader already agrees with you.

• Again, a succinct restatement in just a few sentences of why your solution is worthwhile assuming the reader already agrees with you

• A few sentences about why your solution is valuable, and thus why the reader should be glad to have read the paper and why they should be glad you did this work.

• Improve our solution
• Apply our solution to harder or more realistic versions of this problem
• Apply our solution or a related solution to a related problem

[1] Anderson, J., Ramamurthy, S., Jeffay, K., "Real-Time Computing with Lock-Free Shared Objects," Proceedings of the 16th IEEE Real-Time Systems Symposium, IEEE Computer Society Press, December 1995, pp. 28-37.

[2] Baruah, S., Howell, R., Rosier, L., "Algorithms and Complexity Concerning the Preemptively Scheduling of Periodic, Real-Time Tasks on One Processor," Real-Time Systems Journal, Vol. 2, 1990, pp. 301-324.

[3] Goddard, S., Jeffay, K., "Analyzing the Real-Time Properties of a Dataflow Execution Paradigm using a Synthetic Aperture Radar Application," Proc. IEEE Real-Time Technology and Applications Symposium, June 1997, pp. 60-71.