When you look at Evaluation Specifications or Requests for Proposal (RFPs), you will sometimes see functional (behavioral) and non-functional product or service related requirements being mixed up.

It is recommended to clearly distinguish between functional and non-functional requirements for the following reasons:

• Focus: A set of logically related functional requirements constitutes a feature. Non-functional (non-behavioral) requirements are not about features but rather about quality attributes, design and implementation constraints, etc.
• Time: Normally, the focus is on functional requirements first. Non-functional requirements will be defined when the functional requirements are known. Of course, this sequence of activities does not imply a waterfall model, but should be seen in the greater context of iterative and incremental requirements definition.
• Responsibility: Typically, authoring functional requirements involves substantial technical expertise, which is why technically oriented persons, such as systems engineers, are tasked with writing functional requirements. Non-functional requirements are generally less technical and can be authored by business managers, with the assistance of domain experts, if needed.

It is also recommended practice to keep requirements that are product or service related apart from requirements that are not. Therefore, you would accommodate business partner related or contract related requirements in separate parts (chapters) of an Evaluation Specification.