Engenharia de Requisitos: 
o alicerce da
Engenharia de Software

Engenharia de requisitos é o alicerce da engenharia de software porque quando os requisitos são completos o software estará na margem alta de aceitação.

Requisitos completos são requisitos de qualidade, claros e objetivos de maneira que seja compreendido pelas partes afetadas (equipe de desenvolvimento, stakeholders, usuários). Requisitos completos são aqueles que atendem às necessidades do cliente e proporcionam uma satisfação pelo produto.

Imagine uma construção de um prédio de 10 andares; nesse tipo de projeto existem várias fases como: 1. Planejamento, Análise, Estudo e Modelagem, que são feitas pelos arquitetos e engenheiros; 2. Decoração, realizada pelo designer; e 3. Construção propriamente dita, que é feita pelos pedreiros.

Os pedreiros trabalham na construção de acordo com os requisitos e solicitações entregues pelos engenheiros e arquitetos. A primeira tarefa de construção do prédio é o alicerce, se o alicerce não for bem construído e bem firmado o prédio certamente ficará ameaçado de desmoronamento.

Fazendo uma analogia entre a construção do prédio e construção de um software encontram-se muitas semelhanças. Na construção de um software também precisamos de arquitetos, engenheiros, designs e desenvolvedores. Nesse caso, os desenvolvedores seriam relativos aos pedreiros, entretanto, com liberdade para usar sua criatividade na construção do software, não sendo menos importantes que os demais. Uma das grandes diferenças entre prédio e software é que o segundo é intangível e o acompanhamento do seu growing é bem mais difícil, enquanto a construção de um prédio pode ser facilmente visualizada e acompanhada.

Entretanto, se o alicerce (requisitos) não for bem definido o risco do software é o mesmo risco do prédio, apesar de o desmoronamento não ser percebido visualmente ele é percebido financeiramente.

A fase de engenharia de requisitos é a fase mais difícil da engenharia de software porque lida diretamente com o cliente, com comportamentos, culturas, necessidades e desejos que, na maioria das vezes, são inconstantes. O que a torna mais difícil é que além de adaptação ao cliente os requisitos precisam ser explícitos de forma simples e clara e para se obter um resultado simples muitas vezes existe complexidade no seu processo de produção.

Os requisitos precisam ser documentados, seja com uma documentação engessada, ou uma documentação ágil, ou uma documentação no próprio código fonte, ou com documentação em artefatos. Não importa onde e como, mas é muito importante sua documentação de maneira que esteja acessível às pessoas comprometidas com o projeto.

A forma de documentação varia de acordo com a cultura e metodologia utilizada no processo de desenvolvimento de software, entretanto um problema que ainda hoje se percebe é que as algumas pessoas acham que documentar é tempo perdido, isso é um grande mito, porque tempo perdido com documentação é documentar o que não é necessário, isto é, quando se documenta requisitos principais, necessários e úteis o tempo investido na documentação terá retorno na fase de construção, validação, aceitação e manutenção do software.

A tendência está caminhando para uma documentação ágil, pois os processos ágeis estão ganhando cada vez mais admiradores pelas suas vantagens e valores que uma metodologia ágil agrega a um produto/serviço/projeto.

A documentação de requisitos deve ser atualizada e acordada com os clientes (stakeholders) a cada mudança considerável que há no projeto, assim os riscos de apresentar um sistema diferente do que foi solicitado são reduzidos consideravelmente. O ideal é que haja uma padronização na documentação, isso facilita entendimento, manutenção e navegação dos requisitos no documento.

O ponto crucial de uma documentação de requisitos é estar coerente com os requisitos liberados pelos clientes, pois os requisitos são a base do projeto a ser apresentado para o cliente, se não estiverem bem definidos e bem firmados, certamente seu cliente ficará insatisfeito.

Consequências de requisitos incompletos

Alexsandra Sousóliver

Publicações em:
Abramti.org

Palavras-chave: Engenharia de Requisitos, Alicerce de Engenharia de Software, Satisfação do Cliente, 

Apoio: Larissa Ibiapina, ESD.