The organization of this document is based on the IEEE Guide to Software Requirements Specifications (Std 830-1984), and therefore the order of the sections may appear unusual to those not familiar with that standard.
Understanding this document requires careful mental preparation. Without getting into the right frame of mind, one might read something like ``requirements for the portion of the Hephaestus document describing the requirements phase for a product'' and get hopelessly confused.
Let's start on the ground floor and gradually climb up to higher levels of abstraction.
The first level is a product. To keep it as concrete as possible, imagine a particular computer program. See section 1.3 for a more complete definition of product.
The second level of abstraction includes documents such as Requirements, Architecture, and Design, which describe characteristics of a product. Imagine a project team sitting around a conference table, making decisions.
The third level of abstraction is a methodology or development process, which will be defined in the Hephaestus User Document. Imagine a project team looking in such a document to help them decide what to do next.
The fourth level of abstraction is this document. Imagine a software development group about to develop a methodology to improve the way they do software projects. The group needs to determine what specific characteristics its new methodology must have in order to be acceptable.
Keep the fourth level in mind while evaluating this document. Remember that the goal is to determine the requirements for an acceptable development process. If there is an acceptable development process that does not meet these requirements, then they are too specific. If there is an unacceptable development process that meets these requirements, then they are not specific enough.