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.
Eu questiono a ética de tentar impor requisitos a um cliente em potencial. Isso simplesmente não parece certo para mim. Talvez, em vez de tentar criar requisitos específicos para serem "revisados e ajustados", você deve obter os requisitos do cliente desde o primeiro dia. O envolvimento do cliente ajudará você a entender o domínio e será capaz de criar um sistema que agregue valor, e os clientes estarão mais propensos a comprar um sistema que agregue valor.
How do we decide what's reasonable for availability requirements?
Uma boa regra é que nenhum novo sistema deve ter uma disponibilidade menor do que um sistema existente. Se houver algum sistema existente (e eles não precisam ser sistemas de software, mas qualquer combinação de hardware, software e pessoas) no local, comece como um ponto de referência. Caso contrário, esperaria que o cliente tivesse alguma ideia da disponibilidade mínima que precisariam para funcionar.
Além disso, você não precisa simplesmente especificar o tempo de atividade em termos de porcentagem de um ano. Você pode dar um valor à distância. Talvez durante certas épocas do ano, você precise de um tempo de atividade maior. Ou durante o horário comercial, você precisa de um tempo de atividade maior que as noites, fins de semana e feriados.