It's difficult to comment on a database design without knowing what business rules are supposed to be in force. You need to determine that from your own analysis of the business domain. Without that information all we can do is make some assumptions and guesses based on a list of table and column names.
The person table looks problematic. Are the student and staff columns supposed to be nullabale? It looks to me like you are maintaining two distinct types of person in one table. Probably better to create distinct tables for each of those person subtypes and just have the attributes that are common to both student and staff in the person table.
The concept of 3NF is based on relations and dependencies which permit only values, never nulls. If you have nulls then you don't have a relation that satisfies 3NF. Further, if staff_no is supposed to be a determinant for the staff attributes then it is a non-key determinant (because it's nullable). Nullable uniqueness constraints are a bad idea for multiple reasons and you should try to avoid them.