1. Informative. The audience has at least some understanding of the subject, so the abstract gives background material as well as a discussion of the report (e.g. conference papers, journal articles, trade magazine articles).
2. Descriptive. A discussion of the contents of the report only.

Engineers may include any or all of the following in an abstract:

• statement of the subject
• purpose/objectives
• scope of the report
• description of methods/development
• findings/recommendations

Note that each of these items must be touched on briefly. The total length of a typical abstract is usually between 200 and 250 words. Some conferences, journals and trade publications even give specifications on abstract length, which must be followed scrupulously if you want to be published.

The passive voice, which generally inflates a report while offering little added value, is appropriate here. The abstract should be as disinterested in tone as possible. There'll be time enough in the body of the report to assign actions to individual subjects.

Sample Abstract

The following was taken from a conference paper:

Kinematics, the study of the motion of bodies without regard to their masses or the forces causing their motion, has been around for centuries. The scene graph is the emergent standard hierarchcal data structure for computer modeling of three dimensional worlds, but kinematic models of machines or mechanisms that have external constraints or constraints that span interior nodes do not sit comfortably on its open-branched tree topology.

Methods that have been developed to solve the kinematics of a constrained model tend to work backwards down the scene graph's branches from leaf to root, and the term "inverse kinematics" has been attached to them.

Inverse kinematics solvers have long been fixtures in computational modeling with particular activity in robotics, in human figure animation, and in proprietary CAD and machine design software. This paper describes a general approach to solving inverse kinematics on the Java 3DT scene graph and illustrates the approach using a particular example from classical mechanics with a focus on methods suitable for high fidelity simulation of continuous processes.

The above was rewritten as follows:

The scene graph is the standard data structure for modeling three-dimensional "worlds." Kinematic models of constrained mechanisms, such as robots, are not easily represented in scene graphs because the topology of the scene graph cannot be directly mapped to an inverse kinematic solution for mechanism motion.

This paper describes a general inverse kinematics solution on the Java 3DT scene graph, and illustrates the approach with a classical example. The solution method is suitable for high fidelity simulation of continuous mechanism processes.

The second is an improvement over the first in the sense that syntax is streamlined. On the other hand, though the first includes more detail than may be necessary, it follows a reviewer's comment based on the lack of knowledge of kinematics on the part of experts in scene graphs. Though the first could still be improved with some cuts, what should be cut varies with the audience.