Here's the problem I'm facing:


Quote From Project Manager:

Hey Spark, I'm assigning you the task of developing a framework that could be used for many different iOS applications. Here are the requirements:


It should be able to detect the thickness of the thumb or fingers being used to manipulate the UI.
With this information, all elements of the UI should be arranged & sized automatically.
For a larger thumb, elements should be arranged nearer the center of the screen.
For a smaller thumb, elements should be arranged nearer the corners of the screen.
For a larger thumb, all fonts should be smaller. (We're assuming an adult in this case.)
For a smaller thumb, all fonts should be larger. (We're assuming a younger person in this case.)


Summary: 

This framework is required for creating user-friendly user interfaces programmatically. The framework should be developed in such a way that we can use for as many projects as needed, so it must also be very developer-friendly.



I am the developer given this task, so my questions are as follows:


How can I explain that these requirements are a little ridiculous?
How can I explain that it would be better to concentrate on developing actual projects?
How can I explain that even if this were possible, I wouldn't recommended developing such a thing?
How do I say NO to this project politely, gently, and respectfully?
How can I explain that even for a developer with 3 years of experience, this might not be possible?


If you get a set of requirements that are physically impossible to implement as the device does not support and cannot support the wanted functionality, you need to explain this to the person creating the requirements.

You should be respectful and explain why the requirements are not possible to implement (i.e. the touch screen cannot distinguish between a thumb, finger or stylus. It does not have enough resolution in order to detect finger width.) - keep things factual, pointing to existing documentation if there is any.

Do not go into any sort of emotional argument and keep cool and professional. Saying to anyone that their requirements are silly is never a winning strategy.

See if you can get an understanding of the actual goals for the feature - why it is seen as a requirement. This could lead you to a different, better feature that will solve the need. (thanks @spoike)

@DarkStar33 suggests in the comments to do the research and provide an actual estimate of how much the project will cost and how long it will take, with the assumption that the result will be too expensive and lengthy to be worth it. Being armed with numbers and the data to back them up can certainly help your case, though I would still look at the business goals to see if they can be met (even partially) in another fashion.
