O orçamento já foi consumido como se 90% do trabalho estivesse concluído, quando ainda restam 50% a fazer.
O negócio identifica uma necessidade, cuja solução passa por investir em soluções de software. Após uma espera e investimentos, priorizados em detrimento de outras iniciativas, o software é entregue. No entanto, não atende plenamente.Fosse identificado cedo, menos mal; mais facilmente haveria tempo e recursos dentro do orçamento e prazo originais para corrigir os rumos. O maior problema é descobrir apenas quando de seu teste de aceitação ou mesmo em sua transição para produção.
Esse atraso traz graves consequências para o desenvolvimento, que pode ser cancelado por não mais se justificar. Também, é uma das experiências mais frustrantes para os profissionais de TI envolvidos, para os usuários não atendidos e para os gestores afetados em diferentes esferas do negócio.
Estar próximo à metade do caminho quando acredita-se concluído: soluções de software, que incluem o desenvolvimento dos requisitos como parte de seu escopo de atividades, apresentam esse fenômeno de forma mais comum do que se pode imaginar. Poderia se pensar, em um primeiro momento, que Isso é motivado por uma mudança no escopo original.
O escopo em termos específicos é produto, não um insumo.
Tenta-se justificar atrasos por motivos de mudança no escopo quando trata-se de falha na Engenharia de Requisitos. O escopo em termos específicos é produto, não um insumo que limite a Engenharia de Requisitos. O escopo que limita a Engenharia de Requisitos são áreas funcionais, processos em mais alto nível e partes interessadas chave que afetam ou são afetados pelo desenvolvimento.
Livro EREQ
DADOS TÉCNICOS
Editora: Editora Brasport Livros Técnicos e Digitais
ISBN: 978-85-7452-790-1
Ano: 2016
Edição: 01
Número de páginas: 328 páginas
Este livro é direcionado tanto para estudantes com interesse em desenvolvimento de sistemas, quanto para profissionais envolvidos em projetos de software que desejam melhorar suas habilidades com requisitos. Buscamos escrever tanto para aqueles que atuam do lado cliente do projeto (gestores, analistas de negócio, gerente de sistemas) quanto do lado fornecedor (analistas de requisitos, analistas de sistemas, analistas de testes, gerente de projetos e desenvolvedores). Propõe-se a apresentar a importância da engenharia de requisitos, seus conceitos, atividades e diversas técnicas úteis, de forma que esse conhecimento possa ser aplicado a qualquer metodologia de desenvolvimento de software disponível no mercado.
Cada metodologia dita os momentos em que ocorre o trabalho de requisitos, a ordem das atividades, a relação com as outras disciplinas da engenharia de software, as técnicas a se empregar, os artefatos a serem produzidos. Acreditamos que este conteúdo seja útil para aqueles que trabalham tanto com metodologias ágeis, quanto as metodologias tradicionais. Tanto para um processo iterativo-incremental, quanto um processo sequencial (ou cascata). Tanto para projetos grandes quanto pequenos. Tanto para desenvolvimento de novos produtos de software, quanto para manutenção de softwares legados.
A publicação é fruto de experiência profissional dos autores e da pesquisa bibliográfica que teve como insumo principal o Corpo de Conhecimento da Análise de Negócio (BABOK) do Instituto Internacional de Análise de Negócio (IIBA). Identificamos a Análise de Negócios, como definido pela IIBA, como a ligação crucial do negócio para o desenvolvimento de software. Ela é mais abrangente que a Engenharia de Requisitos; possui objetivos mais amplos. Ao longo das diversas ações de consultoria e na condução de treinamentos, percebemos que a Análise de Negócio ser abordada em toda a sua extensão por um único perfil profissional é, ainda, uma visão de futuro. Por isso, sentimos a necessidade de aprofundar os tópicos da Análise de Negócio referentes à Engenharia de Requisitos, mas sem nunca perder de vista as interfaces e a manutenção de um vínculo de comunicação contínuo relacionando o projeto de software à motivação para o conjunto de mudanças no qual ele está inserido e às mudanças nesse domínio.
Foi um processo gradual e nele, fomos incorporando ao conteúdo desta obra a nossa experiência profissional em projetos de software; o feedback recebido nas diferentes ações de treinamento e consultoria; as práticas de gerenciamento de projetos usadas no SCRUM; o corpo de conhecimento de gerência de projetos (PMBoK) do PMI (Project Management Institute), o Processo Unificado da Rational da IBM (RUP), o guia prático do PMI para os práticos da Análise de Negócio, os modelos de maturidade para desenvolvimento e aquisição CMMI e MPS.BR; e também a visão de vários outros autores do tema, incluindo os livros de Karl Wiegers e Ian Sommerville.
Buscamos também cobrir toda a ementa da certificação CPRE-FL (Certified Professional for Requirements Engineering – Foundation Level), do IREB (International Requirements Engineering Board). Buscamos escrever esta obra de maneira que o leitor sinta-se confortável em lê-la tanto de maneira sequencial quanto por capítulos separado. Estruturamos o assunto de modo que a abordagem sequencial seja a mais didática possível para aqueles que estão tendo o primeiro contato com o tema. Tão importante quanto o conteúdo teórico são os exercícios e os estudos de casos propostos, onde o leitor terá a oportunidade de praticar e refletir de maneira crítica sobre os temas apresentados. Cada capítulo contém ao final um conjunto de exercícios sobre o tema apresentado.
