I agree with Euchris this is more of a Workplace SE question, and this is something of a Workplace SE answer. I've attempted to keep it within IPS SE guidelines and have it still be something of an IPS SE answer as well.
My position is similar to yours. I don't manage or supervise any employees, but I have a 'mentoring' task on my job description that's been there for a little over a decade. As a fairly technical person with a programming background working on a team of systems administrators, I'd been doing that job unofficially for most of the decade prior to that as well.
As a mentor, I don't select their tasks, set deadlines, do performance evaluations, or handle any paperwork associated with their employment. My mentor job is to guide them with what they need to do or learn to handle their tasks.
I'd like to have an easier to implement answer for this. What I try to do is talk with them about the problem they're supposed to solve at length, as long as they're able to tolerate. (If we ever actually covered the full topic, I'd end there, but when dealing with very junior employees, that never happens.) It's probably important to understand up front that if they haven't heard all of the concerns for the project they're working on, they will fail, and it won't be their fault.
Chances are good, no one person set them up for this failure, it's just life. There are only so many problems that are sufficiently urgent to tackle at this time, and they probably weren't perfectly suited for any of them. But the goal isn't for them to get it right the first time, it's to get it right with the assistance they can get by the deadline they have.
So they'll make a first attempt, and come to you with that attempt. Sometimes, it will be overly literal like you're struggling with. Other times, it'll be something "out in left field" which seems like complete insanity. And then there are times when it'll be so far from what you expected that you can't even recognize it as an attempt to solve the problem they were given, until you have had some time to think about it.
Don't be discouraged. This was attempt one. It's real goal was to help enlighten you on what is needed to get their task completed. Whatever they bring you can help with this task. In roughly 20 years of mentoring, I've known immediately how to proceed from what they brought me to tell them exactly what they needed to do to get the job done without me having to spend more than a minute or two talking with them about it less than once per year.
Most of the time, however, it's been a lot less clear than that.
Based on your question, you're seeing multiple obvious failings with their solution, and they're all things that you haven't actually talked with them about. Because they weren't discussed, you can't reasonably be upset with them about them. Although, that said, even if they were things you'd discussed, being visibly upset frequently isn't conducive to maintaining the communication that you need to do your job.
So talk with them about the situations their product will be used in. Ask them to do most of the work here. "Imagine if" the various base situations happen, and ask them to list various possible outcomes. As much as feasible, get them to explain how what they've provided doesn't meet the needs that you have.
You haven't really talked about what type of work they're doing. But the sort of brainstorming one does in test driven development to come up with the test cases for software can be used for more things than software development. You maybe can't use automated testing to evaluate those tests, but you can still come up with tests, or rather have them come up with tests.
The biggest frustration I've had with this approach is some people are literal enough that they still won't see their issues. Once when I was working with someone who saw me as his counterpart in my organization, so he wasn't looking to me for any guidance, I found myself unable to get him to really follow through on any thinking about what if something didn't go according to plan, until I verbally walked him through one particular failure use case.
At this point, he basically gave up and admitted that his program wouldn't work for that case. I tried talking with him about how to make it fail more gracefully, but he just dismissed it as too much work. Any further attempt I made to discuss it was returned with the assertion that I wasn't his boss.
I'm still not sure what I could've done better in that case. I'd been asked to work with him because his code was generally seen to be too fragile, and his boss hadn't been able to get through to him.
Most of the time, though, the people I've worked with have been much easier to help see the issues with what they'd first submitted as a solution to the problem they were given to fix. Getting them to notice the problem without me explaining it to them has generally been much more conducive to getting them to move from recognizing that there is a problem onto fixing it. If I tell them exactly what the problem is, there tends to be a significant lag period before they even acknowledge my message.
I work in corporate for a very big company, so the vast majority of my mentoring has been of people who are not located at the same site that I'm at, so I haven't really had the privilege of being able to drop in on these people and check on how they're doing. I mean, I can send them an instant message easily enough, but that generally doesn't work as well as a traditional 'water cooler' discussion.
Of course, if you are at the same work location as they are, 'water cooler' discussions might be an option. But it's something to be careful about. As somebody who is actually their boss, this can be a bit delicate - there's a fine line between a boss checking on how their employee is doing and a boss who is interrupting their breaks to nag them back to the grind stone. Unfortunately, as somebody who hasn't actually been somebody's boss, I don't feel like I can properly advise you on how to do that dance.
At the beginning of the assignment lifecycle, one can encourage some creativity by suggesting a brainstorming session, once you've handed out the assignment but while you're still talking about it with them. They haven't really had a chance to think through the full assignment yet, so you can't expect them to have a full strategy on how to solve it yet, but you can ask them about their ideas of how to proceed to coming up with a strategy.
I tend to do this with my boss when I'm getting assignments. I do it on my initiative, because I find it frustrating to find I've gone a completely wrong direction on a project. I also tend to do it with my boss when talking about the assignments my coworkers have that I'm going to need to mentor them on.
This is more about figuring out what kind of project result would be acceptable than coming out with a concrete plan.
Attitude is important; they're not doing this to annoy you, so keep calm.
Explain as much of the problem as you can when you give the assignment or they're asking for help, and after they've produced a solution, try to get them to run through scenarios to show where it fails, so they understand they can do that.
Also, when giving the problem at first, try to get them to talk about their initial ideas for how to possibly solve it, to reinforce that you're interested in their ideas rather than just having them be your hands.