com o dominio do problema e nao comsolucoes tecnicas para este problema. Os modelos construidos nesta fase saoelaborados para obter uma maior e melhor compreensao acerca do sistema que seradesenvolvido e podem ser construidos para representar diferentes perspectivas,como: Perspectiva estrutural: busca modelar osconceitos, propriedades e relacoes do dominio que sao relevantes para o sistemaem desenvolvimento. Prove uma visao estatica das informacoes que o sistemanecessita tratar e, portanto, refere-se as representacoes que o sistema tera deprover para abstrair entidades do mundo real. Diagramas de classes sao usadospara modelar esta perspectiva.Perspectiva comportamental: visa modelar ocomportamento geral do sistema, de uma de suas funcionalidades ou de uma entidadeespecifica ao longo do tempo. Prove uma visao do comportamento do sistema ou deuma parcela do sistema. Diagramas de casos de uso, diagramas de atividades, diagramasde estados e diagramas de interacao podem ser utilizados para modelar essa visao. PRESSMAN (2011) cita que os objetivos destes modelos estaoem ajudar os analistas a entender a informacao, a funcao e o comportamento dosistema, tornando a tarefa de analise de requisitos mais facil e sistematica.Alem do entendimento, os modelos sao tambem, um ponto focal para a revisao e,portanto, chave para a determinacao da consistencia da especificacao. Destaforma, os modelos sao capazes de prover uma base para o entendimento econcordancia entre clientes e desenvolvedores acerca do que o sistema fara e,tambem, prove uma especificacao que serve como guia para os desenvolvedores nasdemais etapas de desenvolvimento do sistema.Por fim, e nesta etapa que sao identificados problemas econflitos nos requisitos elicitados, e estes, devem ser eliminados totalmenteantes de ir para a proxima etapa de engenharia de requisitos. 3.3 Documentacao de RequisitosOs documentos de requisitos, tambem chamado de documento deespecificacao de requisitos de software e a declaracao oficial do que osdesenvolvedores de sistema devem implementar (SOMMERVILLE, 2011; PRESSMAN,2011). Considerando que os requisitos de usuarios e os requisitosde sistemas possuem propositos e publicos diferentes, e util descrever odocumento de requisitos de maneira diferente, podendo ser: Documento de definicao de requisitos: deve serescrito de forma que o cliente[2]possa entender, deixando claro o que o cliente espera que o software faca. Estedocumento representa um consenso entre o cliente e o desenvolvedor na definicaodo escopo do software. Documento de especificacao de requisitos:redefini os requisitos de usuarios em termos tecnicos, apropriados para odesenvolvimento do software, sendo produzido por analistas de requisitos.Ambos os documentos podem ter uma correspondencia direta, podendo,o documento de definicao de requisitos complementar e ser complementado pelodocumento de especificacao de requisitos.A composicao dos itens do documento de especificacao derequisitos pode variar de acordo com o padrao e modelo de desenvolvimento queesta sendo seguido pela equipe de desenvolvimento.A IEEE cita que uma boa documentacao fornecemuitos beneficios, como: (i) facilita a comunicacao dos requisitos; (ii) reduzo esforco de desenvolvimento, pois sua preparacao forca usuarios e clientes a consideraros requisitos atentamente, evitando retrabalho nas fases posteriores; (iii) forneceuma base realistica para estimativas; (iv) fornece uma base para verificacao e validacao;(v) facilita a transferencia do software para novos usuarios e/ou maquinas e (vi)serve como base para futuras manutencoes ou incremento de novasfuncionalidades.3.4 Verificacao & Validacao de RequisitosAs atividades de Verificacao & Validacao (V&V)