Welcome to the evil realm of nonfunctional requirements.
The core information your teacher gave you is, in other words, "No idea, go figure something out, and I will decide if I agree with it."
And this is what happens most of the time in real world projects.
Focusing on your information: one user, local environment, we already have some valuable points to analyse. What you need are use cases. What are your users suppose to be doing with the program, where is the focus of its use?
The program doesn't crash, if if you do X. X is your metric here, which you can brak down to e.g. "normal stuff", "extra stuff (running other programs in background, chaning focus,..), "evil things" (you want to leave these things out, because if a user decides to run the program on a laptop in a marathon race, blindfold, jumping on one leg and having pi calculated in the background to the 10^20000 decimal).
The user can work with the program, ..X. X as metric again: "...and is able to use all functions after no more than 3 clicks/windowchanges"(simple), "...and a new user is able to complete the program within a certain timeframe of x minutes" (evil)
Loading time for the program(<1min), time between changes when the user is interacting with it(<2s), and so on.
How should updates, bugfixes be handled? How often? (Like: once a year, updated must not require a full reinstall, ...)
It all depends on the scenario you whish to use the program in.
Your other issue, defending the metrics, requires some kind of evidence that you did not make these values up. My suggestion is to conduct a field analysis of those who should later use the program(assuming the user is at all in the scope of the program's design). Take times for performance issues, confront users with "this was 5s, are you sure you are satisified with this speed just for a scroll down action?". Just watch out that you are using realistic values: 0,01s reaction time is nice, but is it necessary for the aim of the program?