RFP Style Reference

The requirements documents (RFPs) typically include:

1. The objective of the system - this will include both the system required and the environment in which it will operate.
2. The operational vision - a scenario driven discussion of how the system is expected to function and be used by the individuals who will be responsible for its operation or as its end-users.
3. The administrative process - will include who to send proposals to, the process to be used for clarifications, the required pieces for proposals, the contacts of the requesting organization, the timeline for the process, and any other needed administrative detail.
4. The requirements structure - gives details on how to interpret the RFP. This section may also include a description of the process used to determine the requirements, if that is of value to respondents.
5. The detailed requirements, including (as needed):
1. General Requirements
2. Intellectual property requirements
3. Software Requirements
4. Hardware Requirements
5. User Interface Requirements
6. Issue Tracking
7. Interface Requirements for other systems
8. Management requirements
9. Vendor Input/Feature requirements
10. Requirements for specific sub-systems (as many as needed).
6. Optional Considerations or alternatives - would include descriptions of additional items that would be considered as enhancements to vendor proposals which are not specifically addressed in the requirements, or alternative methods of addressing the objective and operational vision of the system - such as out sourcing, hosted solutions, or other methods which do not adhere strictly to the requirements, but which may be considered as alternatives.
   This section may consist of only a short paragraph stating whether alternative implementations will be considered or not.

Requirements Tagging

Requirements tagging is often used to distinguish and identify requirements. Typical tags include:
R - Required functionality, everything marked with this is expected to be present in the response.
F - Future requirements, which may be included in the current design or in a design to be provided at a future date. These items must be addressed and will be considered in evaluating the proposals (separate pricing may be provided if not covered in the base quote).
D - Desired functionality, items which, while not required, if implemented may be considered in evaluating the proposals (separate pricing may be provided if not covered in the base quote).
O - Optional methods for obtaining a result (alternative costing may be provided if multiple alternatives are provided, otherwise optional methods must be in the base quote).

These Requirements tags are usually numbered, either sequentially ... R3, R4, R5 ... or by section ... (R1.3), (R1.4), (D1.2), (R1.5) ... using a seperate numbering sequence for each class of tag.

While an RFP generally uses the words must, would and will for required functionality and may, might and can for desired, or optional capabilities, the particular word usage is not authorative and should not be interpreted in lieu of the label. In all cases, the tag overrides any word choice.