We're creating a draft of those requirements to be reviewed and tweaked with the state. One of the sections is "availability." We want to specify something reasonably high, but not so high that any unexpected problem will get us (or a competitor) penalized.
I question the ethics of trying to impose requirements on a potential customer. It just doesn't seem right to me. Perhaps rather than trying to come up with specific requirements to be "reviewed and tweaked", you should be eliciting requirements from the customer from day one. Customer involvement will help you understand the domain and be able to build a system that adds value, and customers will be more likely to purchase a system that adds value..
How do we decide what's reasonable for availability requirements?
A good rule is that no new system should have a lower availability than an existing system. If there are any existing systems (and they don't have to be software systems, either, but any combination of hardware, software, and people) in place, start there as a point of reference. Otherwise, I would expect the customer to have some idea of the minimum availability that they would need to function.
Also, you don't need to simply specify uptime in terms of percent of a year. You can give ranged value. Perhaps during certain times of the year, you need a higher uptime. Or during business hours, you need a higher uptime than nights, weekends, and holidays.
