sao realizadas durante a historia do projeto;Apresentar modelos de percepcao e tomadas de decisao da mente humana e demonstrar como tudo o que percebemos da realidade depende da forma como as informacoes chegam e sao armazendas em nossa mente (ja discuti que o "Mapa Nao e o Territorio" num post anterior);Apresentar conceitos e praticas que comprovam que a comunicacao escrita pode ser utilizada de forma eficaz quando se tem consciencia de que ela e um mapa que orienta a navegacao durante nossa jornada (requisitos, por exemplo) e nao o objetivo da jornada em si (o software, por exemplo);Demonstrar que a origem de muitos requisitos de produto e projeto de software pode estar associada a riscos quando sua essencia esta relacionada a necessidades basicas de seguranca e reconhecimento do ser humano (piramide de Maslow) e nao a melhoria do processo de negocio em si;Demonstrar que a origem de muitos requisitos de produto e projeto de software pode estar associada a riscos devido a crencas e valores limitantes que sustentam incapacidades e comportamentos indevidos do ser humano;Demonstrar que, em ambientes empresariais, todo e qualquer projeto faz parte da realizacao de uma estrategia de transformacao de um processo organizacional, e que um produto de software deve sustentar essa transformacao, motivo pelo qual os profissionais que atuam com requisitos devem conhecer os elementos do processo de negocio;Demonstrar como a transformacao do processo de negocio pode ser descrita de forma sintetizada, utilizando um modelo de raciocinio baseado na resolucao de problemas (Project Story);Demonstrar como as atividades do processo de negocio (Temas) podem ser alvo de analise na decomposicao do problema, simplificando o calculo do retorno de investimento em projetos de software;Demonstrar como o entendimento dos cinco principios do pensamento enxuto (Valor, Fluxo de Valor, Fluxo Continuo, Producao Puxada e Perfeicao) pode mudar completamente a forma como desenvolvemos e gerenciamos os requisitos de software e justificar a utilizacao das User Stories;Apresentar as User Stories como um modelo de informacoes que permite o registro dos requisitos de software de forma aderente ao pensamento enxuto, garantindo a criacao de mapas simplificados que nos conduzem ao verdadeiro destino de forma objetiva e segura (planejamento quantitativo e validacao objetiva do trabalho realizado);Demosntrar como esse modelo de informacoes pode ser utilizado de forma efetiva em atividades de planejamento e controle de projetos de software; Demonstrar como podemos nos beneficiar da mudanca de percepcao sobre as atividades de gerenciamento de requisitos, passando a atuar no controle de estoques e na eliminacao do trabalho inacabado em todas as fases de desenvolvimento de produto.Ou seja, adotei uma estrategia top-down que inicia na mente humana, passa pela compreensao dos elementos do processo de negocio, avalia as necessidades de transformacao dos resultados organizacionais, ressalta a importancia da criacao de anticorpos em nosso organismo para atuarem contra requisitos descabidos, e simplifica a compreensao do que deve ser documentado e mantido em nossos estoques de requisitos. O resultado tem sido o reconhecimento de que a cultura agil tem fundamentos fortes e deve ser adotada por qualquer organizacao que almeje niveis superiores de qualidade e produtividade em suas equipes de software.Para