Notícias > Artigos de opinión

Definição e Gestão de Requisitos, fator-chave no sucesso dos projetos de negócio

25 Maio, 2016

Por Javier de la Plaza, Head of UX Services

Grande parte dos projetos que envolvem desenvolvimento de software, acabam sendo entregues fora de prazo, com sobrecusto ou com carências funcionais em relação às expectativas iniciais dos usuários. Em alguns casos, esses projetos terminam sendo cancelados, gerando nas empresas e em seus profissionais uma grande frustração devido ao tempo e recursos malgastados.

Num ambiente tão dinâmico e tão competitivo como o atual, as empresas não podem se dar ao luxo de começar iniciativas sem ter antes tudo bem amarrado. É necessário pensar e planejar com calma, o que não implica necessariamente ter que atrasar o projeto, mas fazê‑lo com plenas garantias de sucesso.

O professor James Martin, em sua obra “An Information Systems Manifesto”, afirma que 56% dos defeitos detectados no software são decorrentes de problemas relacionados com a definição e/ou gestão dos requisitos: requisitos incompletos, mal definidos, requisitos desnecessários… Nessa mesma obra, destaca que a correção de defeitos resultantes de uma Engenharia de Requisitos deficiente representa a maior parte do esforço com retrabalho (82%).

Se levamos em consideração esses dados, fica claro que a Engenharia de Requisitos ‑ como encarregada de definir os objetivos do projeto e estabelecer uma base comum de comunicação entre as diferentes equipes envolvidas no mesmo ‑ é a disciplina do ciclo de vida de desenvolvimento do software que influi de forma mais direta no sucesso ou no fracasso final de qualquer tipo de projeto.

Satisfação do usuário e redução de custos

A Engenharia de Requisitos tem também um impacto direto nos principais indicadores do negócio. Particularmente, apresenta dois grandes benefícios: em primeiro lugar, o aumento da satisfação do usuário, garantindo que os sistemas de informação cumpram todas suas expectativas e necessidades. Algo importante se consideramos que a satisfação do usuário deveria ser o principal indicador de qualidade de um sistema.

O segundo grande benefício está relacionado com a redução de custos na construção e manutenção de um sistema. Assim, a maturidade do processo de requisitos condiciona o nível de retrabalho necessário para que um sistema cumpra as expectativas do usuário. Se definirmos e gerenciarmos corretamente os requisitos, construiremos o sistema correto já na primeira vez, o que repercutirá em uma maior previsibilidade em termos de esforço e tempo, assim como em uma redução do custo total do sistema.

Mas que fatores seriam necessários levar em conta na hora de estabelecer uma correta gestão e definição de requisitos? Em primeiro lugar deveríamos trabalhar para melhorar a comunicação entre os departamentos de Negócio e de Tecnologia de cada empresa. Se Tecnologia não entende as necessidades do usuário, entregará um sistema sem utilidade. Se Negócio não entende como se comportará a solução, serão criadas expectativas que não são realistas e que, portanto, não serão satisfeitas pelo sistema entregue.

A comunicação entre Negócio e Tecnologia deve ser otimizada e, para isso, é necessário aplicar técnicas de Engenharia de Requisitos testadas que possam ser utilizadas nas atividades de Captura e Validação de Requisitos, de acordo com a tipologia do projeto que será realizado (evolutivo, corretivo, migração…) ou do sistema que será construído.

Por outro lado, as empresas acham que a engenharia de requisitos consiste simplesmente em expressar ou captar necessidades e documentá‑las. Existe uma tendência a pensar que todo o mundo sabe expressar uma necessidade e também escrevê‑la, mas captar as necessidades de cada um dos interessados em um sistema é uma tarefa complexa que deve ser realizada utilizando uma série de técnicas e aplicando habilidades interpessoais. Assim, um dos problemas mais habituais de qualquer empresa é a baixa qualidade com a que são redigidos os requisitos.

Se estamos de acordo em que o objetivo principal na hora de escrever os requisitos é precisamente que eles sejam entendidos por todas as partes, o ideal seria garantir o desenvolvimento de algumas boas práticas referentes à escrita das especificações, como por exemplo, a criação de planilhas para identificar todas as informações necessárias e para organizá-las, ou etiquetar e definir um estilo para as seções, subseções e requisitos individuais de forma consistente.

A necessária especialização

Neste ponto, é preciso reconhecer que a falta de especialização na área de serviços relacionados com a Engenharia de Requisitos atualmente chega a ser alarmante. Há fornecedores que se dedicam à melhoria de processos de desenvolvimento baseados em modelos de maturidade, mas que não possuem o conhecimento necessário para ajudar as empresas a melhorar nas áreas de processo de Gestão e Definição de Requisitos.

Também existem empresas que têm a tendência a solucionar qualquer problema comprando ferramentas. Na área de requisitos, uma ferramenta não só não é a resposta, como pode aumentar os problemas. As ferramentas são imprescindíveis quando o processo está maduro, já foram introduzidas as técnicas adequadas para cada atividade do mesmo e o pessoal já adquiriu os conhecimentos e habilidades necessários. Quando uma ferramenta é introduzida sem levar em conta os fatores anteriores, o resultado é que será utilizada uma ferramenta muito mais complexa do a que realmente era necessária ou que acabarão sendo utilizadas ferramentas muito mais simples e não especializadas em requisitos. Ambos os cenários são pouco desejáveis.

Quando a viabilidade do negócio depende do correto desenvolvimento e produção de um aplicativo, colocar a carroça antes dos bois pode ser muito arriscado. Vale a pena parar e buscar a ajuda de um especialista capaz de estabelecer determinadas bases, determinados requisitos de qualidade que possam ser entendidos por todas as partes envolvidas e que deixem claro o que o sistema será capaz de fazer. Desta forma, economizaremos tempo, dinheiro e dissabores. Parece uma coisa sensata. 

Share