This depends on what kind of "ordering system for a restaurant" you are creating, and who is actually using that software. If users of the software are only the staff or the restaurant owner, then you should interview them, not the customers.
If, however, you are creating an online "ordering system", where customers directly enter their wishes at a terminal or web page, then you should also include a "representative customer" for giving you feedback about the usability. However, for such a topic like "restaurant visit" you probably do not need a "special expert". You could try to fill this role by yourself, or include a person who has some experience in UI design, if you think you are not qualified enough in this.
If you get conflicting requirements this way, at the end the person you have a contract with decides, isn't that obvious? In your A level school project, assume this is the restaurant owner. Typically you get functional requirements concerning the content of the system and the processes by the client. He should be interested in getting the system as usable as well, and a "representative customer" can help you in gathering non-functional requirements like usability.
The biggest conflict risk you have here is when you are going to exceed your budget because of adding too many "bells and whistles" to the user interface. But finding the right balance between these constraints is exactly the job if you take the role of a business analyst.