An operational requirement, is a requirement where an objective third party, would be able to determine whether or not it is fulfilled, then the project is delivered. It might be directly verifiable, such as having login functionality, – or it might need expert knowledge such as assessing code quality.
This is an important tool to show that the deliveries is actually what has been agreed upon, – both for the client and the contractor.
Functional requirements are about the actual functionality and visible parts of the delivery, – this is often easy to check, ie. is there login-functionality, can you see the search results etc. See this as the minimum features you do expect. Instead of having a functionality list, it might be better to work in sprint with a common understanding of the direction, – but the backlog should still be clear.
Non-functional requirements are more meta requirement, ie. code quality, delivered documentation, etc. These are difficult to get correctly operational, ie. just writing it should follow best practises are very vague, – better to write that a certain coding standard should be followed in all new code, preferably with tools that automatically check that. That the overall architecture should be documented, and that there should be a step-by-step guide to get the project running. And also that there should be run automatically through the continuous integration server etc.
Even though you have good operational requirements, getting IT-solutions are still a question of trust. So remember to check that you have the same values and spirit of the agreement, and that you are on the same page. Also, it is in most cases impossible to do the perfect specification of a large project beforehand, so agile methods is highly recommendable.