Mais do que "Necessário, Verificável, Atingível e Claro" um bom requisito deve ser Certo, Correto, Completo, Factível, Sem ambiguidade e ser Rastreável.

Além disso o requisito não deve ter, a princípio, frases negativas do que ele "não pode ter ou fazer". O requisito deve procurar sempre ser "positivo". Sempre que possível fazer frases curtas e utilizar da palavra "deve", ou seja, o que o sistema deve conter, mostrar, fazer, etc.

Em vez de se ter um requisito muito longo e que pode gerar mal entendidos ou interpretações errôneas ou incompletas: “O sistema deverá fornecer para o usuário a possibilidade de agendamento dos procedimentos solicitados pelos clientes e, se houver algum agendamento para aquele mesmo horário, o sistema deverá sinalizar o usuário de que o agendamento já existe e na sequência oferecer o horário mais próximo disponível.”

Poderíamos ter: Req. 1- O cliente deve ter a possibilidade de fazer o agendamento. Req. 2- O agendamento dever poder ser feito em sistemas Windows, Apple, Android e Mac OS. Req. 3- Agendamentos no mesmo horário deve ser sinalizado e informado ao cliente que fez a marcação de horário já ocupado. (tem espaço para melhorar esse requisito com uma frase melhor). Req. 4- Os agendamentos feitos em horarios já ocupados deverão ter um "botão" para mostrar os horários disponíveis.

Os requisitos devem ser escritos sempre pensando no que o sistema deve fazer. Nesse sentido, não se deve escrever os requisito pensando nas excessões, nas restrições, no que não seja permitido ou possível. Se a escrita dos requisitos for feita nesse sentido (do que é restritivo), o risco de não se conseguir atingir os objetivos da escrita dos requisitos e por fim, ter um sistema são muito grandes. Nem por isso, deve-se esquecer o que pedem as leis, regimentos, regras, boas práticas da empresa desenvolvedora ou do mercado.

Alguns requisitos tem requisitos filhos e "netos", assim a rastreabilidade de cada requisito é muito importante, desde o seu nascimento (lá nas primeiras entrevistas) até o produto final (talvez especificando o "clock" de um chip).

Outro ponto importante é que, dependendo do nível de complexidade de um sistema, pode-se ter um desmembramento de requisitos para um fornecedor. Acredito que não é o caso do exemplo desse curso mas acho que seria interessante citar que esse desmembramento pode ocorrer. Ou seja, poderia ocorrer um desmenbramento de alguns requisitos de desempenho para um fabricante de processadores para o desenvolvimento de um processador capaz de abrir uma tela em menos de um segundo. Esse fornecedor de processador não deveria e nem precisaria de saber da Maria Bonita, apenas dos requisitos que interessam aos requisitos de desempenho.

Por fim, é interessante ressaltar que é boa prática ter um "rationale" para cada requisito explicando de maneira um pouco mais informal por que aquele requisito existe. Além disso, um bom requisito geralmente não nasce pronto. É boa prática mostrar os requisitos para os colegas a fim de conseguir maior robustez do mesmo e isso não é Validação ainda, que está num passo mais a frente.

Espero ter contribuído.