Surge uma ideia de negócio, cuja solução passa por investir em software. Após um período de espera e de investimentos, priorizados em detrimento de outras iniciativas, o software é entregue. No entanto, não atende plenamente às necessidades de negócio.
O orçamento já foi consumido como se 90% do trabalho estivesse concluído, quando ainda restam 50% a fazer.
Fosse essa situação identificada 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 já se acredita ter chegado ao final
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
Desenvolvimentos, que incluem os 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.
A declaração de escopo ou o backlog inicial não deve limitar quais sejam os requisitos da solução que são um dos mais importantes produtos do desenvolvimento; não um de seus insumos. Por isso, a descoberta desses requisitos mais específicos é uma revelação própria do esforço de Engenharia de Requisitos e ele não deve ser visto como uma mudança ou causa que explique ou justifique o fenômeno descrito.
Parece, então, um paradoxo pela contradição implícita. O paradoxo se desfaz quando se esclarece qual o marco utilizado para avaliar os 50% concluídos e qual o outro marco para avaliar os 100% (ou, mais frequentemente, 90%): o último considera o atendimento ao escopo identificado, enquanto o outro considera um escopo necessário para atender plenamente o propósito para o qual o projeto foi iniciado.
A Engenharia de Requisitos e o desenvolvimento Ágil
Há muitos profissionais de TI, que associam a Engenharia de Requisitos à elaboração de Casos de Uso. Não apenas isso, mas também à prática equivocada de se tentar capturar em Casos de Uso o comportamento dinâmico da interação entre usuário e software em um nível além dos requisitos e já abordando decisões de desenho ou implementação.
Ou seja, esses profissionais atribuem às práticas de Engenharia de Requisitos ou à utilização de Casos de Uso a consequência do uso de uma chave de fenda ao invés de um alicate.
Eles associam a Engenharia de Requisitos à burocracia de especificações com o único propósito de ˜reter conhecimento” e não como uma ferramenta para definir e manter atualizado um horizonte de solução realista para atender às necessidades de negócio. Observe que esse horizonte não se refere ao “detalhamento” sobre o comportamento de uma transação em particular, mas do próprio escopo da solução para atender ao negócio!
O ponto de partida para o Scrum, por exemplo, é o backlog de produto. E a Engenharia de Requisitos, com um conjunto de ferramentas diferente e utilizadas de maneira diferente de um desenvolvimento sequencial, permite chegar ao escopo inicial da solução em termos de histórias do usuário como itens de backlog.
Para algumas dessas histórias, é possível que seja adequado Casos de Usos para melhor desenvolvê-las antes de iniciar sua prototipação; mas isso não é uma necessidade universal. Os detalhes dessa interação podem, e devem, ser desenvolvidos por meio de prototipação, uma das ferramentas na Engenharia de Requisitos. Os requisitos nesse nível de detalhe são capturados, não em casos de uso, mas em protótipos.
A Engenharia de Requisitos facilitando a integração do desenvolvimento ágil com as necessidades de Governança Corporativa
O desenvolvimento Ágil ou a simples adoção do Scrum resolve esse problema? Em parte. Os ciclos curtos propiciados pelos sprints permitem a experimentação, feedback e aprendizado também em ciclos mais curtos; no entanto, é muito fácil perder a perspectiva dos objetivos mais altos e consumir o orçamento sem atingir esses objetivos.
A aplicabilidade da Engenharia de Requisitos no desenvolvimento Ágil permite mais facilmente chegar a Backlogs de diferentes níveis, porque diferentes níveis são necessários quando se trabalha em uma corporação com várias equipes de desenvolvimento:
- Conforme se desenha um roadmap do produto com as próximas features;
- No detalhamento de como uma ou mais features se traduzem em termos mais específicos como novas histórias do usuário e itens voltados à atender requisitos não funcionais em um backlog de produto;
- Na distribuição e sincronização do trabalho entre o backlog de diferentes squads.
