Hoje terminei o treinamento sobre Requisitos de Software com o Luiz Parzianello, que ao meu ver e um dos "CARAS" de requisitos no brasil.O objetivo do post e falar um pouco do porque resolvi estudar requisitos e algumas dicas para quem esta comecando a estudar sobre isso. MotivacaoE um assunto abordado de forma muito pobre nas faculdadesExiste muita gente(inclusive eu) definindo requisitos baseado na experiencia(empirico), sem fundamento teorico.E nitido os problemas que requisitos errados e/ou inconsistentes geram nos projetos.1) Entenda o que um projeto de software representaE importante entender que os investimentos realizdados em projetos de software sao para realizar transformacao entre o cenario atual e um cenario desejado. Significa que o patrocinador do projeto busca eficiencia, eficacia e novas oportunidades.A figura abaixo exemplifica como entender o "AS IS" e o "TO BE". Obvio nao?2) Levantamento de requisitos nao e descrever solucao...Entendido que projeto de software faz parte da transformacao do "AS IS" para o "TO BE", precisamos explorar o "AS IS", ou seja, o PROBLEMA!!!!Ir para no cliente fazer levantamento de requisitos nao significa emitir pedidos, mas sim explorar o cenario atual. Nao va falar com o cliente esperando que ele diga: Faca a tela X, importe os arquivos e comunique com webservices. Isso sao solucoes.Levantamento de requisitos = DesbravamentoRealizar o levantamento de requisitos e entender o cenario atual, compreender os problemas existentes, identificar os objetivos de negocio com o projeto e especificar os requisitos de usuario e software necessarios para atingi-los.3) Descricao do ProblemaQuando voce for entender/descrever os problemas que precisa resolver, tenha em mente que deve utlizar uma estrutura NARRATIVA, ou seja, voce vai contar fatos que acontecem hoje.A descricao do problema pode ser composta porTexto narrativo:Ex: atualmente o gerente utilizar uma planilha para... Resultados do cenario atualEx: estamos perdendo clientes pelos motivos... Possiveis causasO fato de o cliente nao ter acesso ao nosso sistema.. 4) Descricao da VisaoAte agora escrevi sobre o objetivo dos projetos e que requisitos nao comecam com definicao das solucoes. Passei algumas dicas para escrever o que o projeto deve resolver.Antes de comecar a identificar funcionalidades e acoes dos usuarios, precisamos ter uma visao claro de o que o cliente espera do projeto.Para isso podemos descrever qual a visao (projecao, expectativa, etc) do cliente.Essa descricao pode conter:Texto descrevendo a expectativa sobre projetoResultados esperados: reducao de 50% do tempo de... , aumento de producao no...Beneficios esperados: aumento na captacao de clientes, etc.Recursos necessarios: utlizar um sistema para fazer isso, ter acesso ao notebook, etc..5) Requisitos de negocioCuidado! Requisitos de negocio devem estar associados VALORES DE NEGOCIO, ou seja, eficiencias, eficacias e oportunidades.Este e o mindset:Requisito de Negocio = Cenario atual(perdas de oportunidades, ineficiencias) + Cenario Desejado (objetivos, conformidades, etc.)A analise de requisitos nao para por aqui. Na verdade ela so para nos requisitos de software (features), mas isso e assunto para outro post.O importante e o entendimento de como pensar requisitos.Ainda existem muitos outros aspectos abortados no curso de requistios que fiz. Este e so um pedacinho..O curso de requisitos de software que fiz vale a pena!!! Pra mim deve ser PRE-REQUISTITO para qualquer um