Mark, before deciding on fields, I'd say the first thing is to decide the objects (or entities) that are required. Each entity will have its own table in the universe our database is modelling.
One thing I've found doing custom work, often by asking what needs to be "shown / reported" you will get a lot of "X,Y,Z" answers that help identify what the actual tables will be.
Trying to identify all objects first often causes about half the tables to be omitted if your client doesn't understand how to create a database. If you ask what they need to see, you get all kinds of interesting input that allows you, the professional, to identify what those tables should be.
From your own list I'd never have both "Tenant" and "Owner" as separate tables. I would instead have contacts. A contact could be linked to a property as an owner, as a manager, as a tenant, as an emergency contact, as a service representative, or as several of these types. The "Entity" would be a person or business. Their relation to a given piece of property is time dependent, so they should be linked to a property based on their relation at that time.
By asking for what should be on reports, afan will see that the list of "Tenants" and the list of "Owners" will have redundant data. This will allow them to evaluate what is required by the client and work out how to model it in their data structure.
I've never had a client come up to me with enough knowledge of data structures to actually specify how data should be stored, but they will always know what results they need to be able to pull.
And then they decide they need entirely new outputs and wonder why the program didn't anticipate their needs...