crescimento dos custos para correcoes ao decorrer do progresso de um projeto.Figura 1: Custos para correcao de erros.Para diminuir os custos com as mudancas e correcoes, o ideal e refinar os requisitos do projeto o quanto antes possivel. Para isso, varias tecnicas podem ser usadas e o feedback do cliente nas fases iniciais e de extrema importancia para evitar que problemas sejam detectados em fases muito avancadas da producao acarretando em custos e riscos elevados.O fato 25 trata de algo interessante para refletir, que sao os requisitos omitidos de software. Segundo o autor, um dos erros de requisitos mais dificeis de serem corrigidos e o de requisitos ausentes. Existem diversas tecnicas de testes dos requisitos para identificar se eles correspondem ao que se espera do software, porem, um requisito nao levantado, consequentemente tambem nao sera testado, porque teoricamente ele nao existe.Requisitos sao levantados de diversas formas, mas de forma geral, o processo de levantamento de requisitos se baseia em interacoes de pessoas e analises de documentos. Devido a alta subjetividade dessas atividades, o risco de que algum requisito do cliente seja desconsiderado no levantamento esta sempre presente. Segundo o estudo realizado pelo autor, 30% dos erros de software sao oriundos de logicas omitidas de programacao. Esse tipo de omissao e geralmente causada por requisitos nao levantados. Testes geralmente baseiam-se em requisitos presentes no projeto, portanto, esses erros acabam passando despercebidos nos testes. A dificuldade de identificacao desse tipo de erro acaba tornando-os dificeis de serem corrigidos.Para tornar a analise de requisitos mais eficiente, o levantamento deve ser feito de forma iterativa, pois dessa forma a ideia sobre o problema principal a ser resolvido ficara mais madura e consequentemente os analistas passam a ter uma visao mais critica sobre o problema, identificando os requisitos mais facilmente assim. A interacao entre os analistas tambem e muito importante, pois a troca de informacoes entre diferentes pontos de vista pode tambem aumentar essa visao critica de todos envolvidos.ControversiaExistem poucas controversias sobre o fato 23. Antigamente a controversia principal a ele era com relacao ao congelamento dos requisitos. Hoje e raro encontrar quem discorde de que o congelamento de requisitos e sinonimo de falhas no projeto.Atualmente a principal controversia ao fato 23 gira em torno da utilizacao de metodos formais para especificacao de software. Na pratica eles sao pouco utilizados pelos profissionais de software, porem a academia ainda defende a eficiencia de sua aplicacao. Como o fato 24 e um consenso geral, praticamente nao existem controversias ao seu respeito. As unicas divergencias ao fato 24 sao relacionadas as formas de evitar que erros demorem a ser detectados. Existem diversas maneiras de fazer isso, porem dependendo da funcao que determinada pessoa exerce no processo de desenvolvimento, elas tendem a optar por metodos especificos relacionados a tal funcao. A dificuldade para identificar e distinguir entre os tipos de erros cometidos acaba gerando poucas controversias sobre o fato 25. Referencias[1] Glass, R. Facts and Fallacies of Software Engineering. Addison Wesley. October 2002.[2] SOMMERVILLE, I. Software Engineering, 5th edn, Addison-Wesley Publishing Company, Wokingham England. 1996.[3] GUIMARAES, E. C. F. O uso