I've been asked about developing a simple multi choice quiz to be used on a touch screen. It'll be offline too. The quiz part is fine, record the answers, save the data locally via SharedObjects and then they can get the data out at the end of the day, but I'm not sure about the touch screen part.
Is there anything I should bear in mind in particular? I think there's no such thing as a rollover effect, I seem to recall Arsis saying somewhere. Any thoughts or warnings would be appreciated 
Not many really, just the following:
Hide the cursor
Make any buttons quite big and not too close to each other.
No rollovers but make sure the button changes or something happens on screen once a button has been pressed so the user know they have done something.
I tend to always use a custom made screensaver saying something along the lines of 'touch screen to start' to prolong the life of the screen and to make sure the software goes back to the start and the quiz answers are cleared if someone leaves the touch screen and to explain what to do (it's amazing that some people still don't know what to do with a touch screen!) Make sure the screensaver always has everything moving on it at some point)
Think that's about it.
If you are dealing with the computer that will control the touch screen make sure the power options are set up right but I doubt you will be. I presume you just have to supply the software and not install it?
Will there be someone manning the touch screen? i.e. what is the plan t prompt users to actually use the system?
Some notes from the Snepo 'Flashing in Public' presentation:
If the system is unmanned you will need some kind of attractor animation. A call t action that simply states that the screen is interactive and that users need to touch it to use it. After a period of time (3-5 minutes) reset that application back into its 'attract' state.
Unlike web UIs users are generally unsure as to what to do. Make sure to brake the process down into simple steps that include clear instructions as to what to do.
Always instruct the users as to where they are in the process. e.g. 'Stage 1 of 4' or '20% complete'... better still use a crumb system.
No such thing as a roll over.
Consider using a mouse down over mouse up or click in order to give feedback as soon as the user touches (as opposed to a mouse up which will only occur when the user moves their finger away).
Consider using audio to make the interaction feedback even more obvious.
Keep buttons nice and large so that they are easily pressed (fat finger rule).
Hide the mouse cursor. It has no purpose and can confuse users.
If this is public facing you will need to consider some of the basic accessibility requirements. Either build your nav at the bottom or offer an option to shuffle the nav to the bottom s that people in wheelchairs can use it. Also consider running your design through colour checkers in order to establish a design and palette that suits the visually impaired.
Take note of the environment in which the touchscreen will sit. Consider things like the level of ambient light, potential spot light reflection and ambient sound.
Some other things to think about:
What happens when something goes wrong? how easy will it be to fix the application and/or reboot the machine. Considering that it will probably be in some kind of enclosure you will need to make sure that either someone is there that knows what to do or you can access the box remotely.
Make sure your touchscreen is calibrated correctly, and if possible, recalibrate frequently (daily).
Make sure that the user is not able to get outside of the application. It may be possible to access the OS or the touchscreen hardware menus (we had a case where someone was able to get into our screen menu and turn all the displays upside down... we thought it was funny but the client didn't).
... and what Suzy said.
Also, extend the hotspot of the buttons beyond their graphical representation (using a shape with a0 alpha).
if you're using as3, make sure your button events are fired on MouseEvent.MOUSE_DOWN, not MouseEvent.CLICK. I got buggered with that one a while ago, and it's not fun searching through an entire project replacing the event listeners 
thanks guys, that's some great info there!