I have some background in requirements engineering, though for these kind of unsharp requirements it is in my opinion required to take a different view on on the requirements. There are various methods for requirements elicitation, grouping, analyzing, refining etc.
There is however a common pattern to most methods and practices: You need to take different views and perspectives to the same requirements, in such way that your stakeholders (and yourself) understand and agree on requirements. You're not yet in that state, thus you need to get more info - or make assumptions.
In the mid-size company I'm working for right now, where there is little knowledge about requirements engineering in general, I choose a simple 3-step model to discuss my assumptions and define / agree requirements with the stakeholder:
Business goals are the most important requirements. They drive everything, and give you reason (and your company money or other value) for any development task. Business goals need to answer the question: Why are doing this?
=> According to what and how you describe your situation, it seems to be unclear to you and maybe also to the business guys in your company.
Is it that some important customer just complained that the joystick is too slow, and you'll loose him if that isn't improved? Or is it your competitors have an overall more responsive system, and you need to keep up with the competition? If for example the latter is the case, you'd have to compare your own system against the competition, and derive technical requirements from this comparison.
I'd put a question mark to the stated goal "make the system faster". Somebody had probably good intentions requiring you to do so, but it should be your job as "requirements engineer" to make assumptions and make reason from a business perspective.
Depending on where you work and how your organization looks, it may or may not be a good idea to ask directly for a reason or business goal to your task. That can make a negative impression. Rather, make a clearly worded own assumption for the business goal, and make it clear that your assumption will be what drives your technical requirements analysis and definition. Often enough this will indirectly lead to debates in the business department, because it's likely the business goal isn't really that clear. Which is then a business task to refine the goals.
Even though you're not a requirements engineer officially (thus I put that in quotes above), you should take that position to some degree. Because a) somebody may put blame on you later for whatever reason, because it's easy to claim that you didn't understand the task with no further background or actual business goal provided. The business guys know that. Though that's about playing tricks, but knowing these things make you a part of the solution also.
Product requirements should give answer to the question: What needs to be done. It should also fit to the product vision.
That part seems defined (implement or reimplement some module within your product). Though without background, I do not understand the reason. Probably you know. If not, you should also ask for the broader picture, and how your changes are supposed to improve the product.
Finally, at the very last and from business perspective least important (not for you of course), system requirements answer the question: How should it be done / implemented?
I believe you know how to define this. And this will be the least problem for you, after you gathered business and product requirements.
You also don't necessarily need to prove or disprove anything - just give well worded and clear own assumptions. Give your assumptions together with your defined requirements to your boss and your stakeholders. Agree with them on both, your assumptions as well as your defined requirements.
It's the job of whoever "owns" a requirement (or has a stake in it) to disprove you'r assumption. Provide your assumptions and requirements to all it may concern, and your chances that it will be a success will significantly increase.