It is 100% OK that your customer (in this case your Dad) doesn't want to bother with interviews to gather requirements as interviewing is but one method useful for requirements elicitation.
A few methods immediately come to my mind in this situation. If it were me, I'd probably pick and choose pieces of each of these to figure things out.
- ARM - Accelerated Requirements Method.
- Contextual Design, or Contextual Inquiry
- Tracer Bullets
- Straw Man SRS (Software Requirements Specification)
The Accelerated Requirements Method is a structured, fast, and relatively simple way to gather high level functional requirements. For this project you probably wouldn't need to apply the whole method, but instead focus on the "Brainstorm, Organize, and Name" phase. Basically you prompt a 7 minute brainstorming session with a question specific to some aspect of the project: "An important requirement of my day-to-day work is _." The point is to focus the brainstorming. Next you'd group and remove duplicates (shouldn't be too hard with one stakeholder...) and prioritize the gathered requirements by multi-voting. You might use some requirements to dive deeper in subsequent BON sessions. And you don't have enough stakeholders for multi-voting so you'll have to prioritize other ways.
See this case study from the SEI for an example using ARM to gather security requirements.
It sounds like a big piece of what you're missing is domain knowledge in which case contextual design could really help. There's a book by Beyer and Holtzblatt which explains the entire process. You will be most interested in the contextual inquiry phase in which you essentially observe users as they do what they do. The idea is to be a as much a "fly on the wall" as possible and ask questions go gain insight about what a user is doing, why they are doing it, artifacts they are using, and so on. You can find out all kinds of interesting things just by watching a person in their typical day that they might not be able to otherwise describe, or might not even know themselves.
This could actually be pretty fun, and informative, and a great chance to spend time with your Dad and learn more about what he does (my Dad's job was always a mystery to me growing up).
Straw Man SRS
In the same vein as tracer bullets, put something in front of your Dad and he'll start telling you what's wrong (or right) with it. In this case, maybe you'd right a couple of user stories or use cases and take them to him for feedback. The trick when using any kind of straw man is to make sure that he actually reads/evaluates it and to avoid playing "wrong rock" (in which whatever rock you bring back is always the wrong one). Be sure to ask what he doesn't like about a proposed requirement in the straw man so you're not left guessing - otherwise you'll likely be wrong again!