I think the student’s first instinct was about right. For a program idea that sounds like it’s kind of a user whim ‘I think I’d like to have a log file of URLs I copy pasted’, it seems like it would be good to get a prototype into the professor’s hands to see if he actually finds it useful or if in fact it just winds up recording a bunch of URLs he never looks at before investing more than a couple of hours in making it super user friendly.
Instead, he just explained to the students why it’s much more complicated than that, probably discouraged them from trying to build anything at all, and as a result is no closer to having any kind of way to capture the URLs he copy pasted during the day. No value was created in this exchange.
My overall reaction to this is this feels very much like an academic approach untethered to what kind of practices actually work for creating products in industry, and instead is working to inculcate students in bad habits that will turn them into the kind of developer who, when asked to solve a problem, comes up with a long list of reasons why it’s too much effort to be worthwhile, rather than a list of ways to figure out how to solve the problem.
In particular, this pattern of listing ‘but have you thought about…’ questions is amateurish product owner BS and it does students a disservice to suggest this qualifies as any kind of requirement analysis model, let alone a first step in deciding how to go about building a piece of software. It is a great way to stop yourself from even starting.
Requirements gathering doesn’t consist of guessing what things a user might want, or even asking a user what they think they want. Yet the professor goes off positing a need for a pause mode, timestamps recording next to URLs, log encryption… all of which are maybe interesting but none of them seem like they make or break the viability of the product.
On the other hand, if it turns out you can’t actually make a program that has sufficient permissions to read arbitrary clipboard contents without triggering a malware detector or getting blocked from installation on a university computer, that would rather screw with the entire project, so maybe focus on verifying that you can at least do that first before you start wondering about what color the system tray icon is going to be.
And maybe your research will turn up some interesting affordances or edge cases in the clipboard API that you hadn’t thought of that take the project in a completely different direction?
The fact one of the students said something important that identified a key risk to the entire project concept: ‘I’ve never interacted with the clipboard api before’ - and then that got glossed over for discussion of all the shiny affordances that could be bolted on to the solution - was a real miss of a teachable
moment.