Engenharia de requisitos é uma área de TI que tem como objetivo cuidar das necessidades do cliente na construção do software.

Você sabia que quando um projeto não executa corretamente essa fase, a chance de acontecer falhas é alta?

Você faz ideia de quais são os maiores benefícios que a engenharia de requisitos pode oferecer ao projeto de software?

Se não, acompanhe-me nessa leitura. Você vai ver muita coisa interessante por aqui.

Engenharia de Requisitos

Em resumo, a engenharia de requisitos é uma disciplina da Engenharia de Software que utiliza técnicas específicas para obter, documentar e fazer a manutenção de um conjunto de requisitos para um determinado software/app.

O propósito dessas técnicas sistemáticas é fazer com que o projeto alcance as metas e objetivos do plano de negócios.

Com isso, um dos maiores benefícios da engenharia de requisitos é a entrega de valor e qualidade já que ela se inclina às necesssidades do cliente.

Engenharia de Software 

Sabemos que a engenharia de requisitos está inserida no conjunto de disciplinas da Engenharia de Software, certo? Mas o que é a Engenharia de Software?

De acordo com a ISO (2010), a Engenharia de Software trata da aplicação sistemática do conhecimento tecnológico e científico, de métodos e experiência ao projeto, implementação, teste e documentação de software.

Tanto nas graduações quanto nas pós-graduações, não existe um padrão de disciplinas, ficando ao encargo das Instituições decidirem quais querem colocar em seu plano de curso.

Porém, geralmente, essas disciplinas se dividem em:

• Modelagem de negócio
• Engenharia de requisitos
• Análise e projeto
• Implementação
• Engenharia de testes
• Implantação
• Gerência de projetos

Portanto, a engenharia de requisitos é fundamental para dar continuidade as demais disciplinas.

Qual o propósito da engenharia de requisitos?

Seu propósito é identificar e entender as necessidades do cliente. 

Sendo assim, ela analisa e descreve tarefas, técnicas, orientações e responsabilidades que estão de total acordo com os interesses do cliente.

O que faz um analista de requisitos?

De acordo com a Catho, esse profissional faz o levantamento de requisitos e especificações de projetos de TI. Ele desenvolve soluções para processos, mapeamento e análise de negócios.

Também elabora a documentação técnica de especificação de requisitos de softwares e status report para a gestão de projetos. 

Resumindo, é o profissional que levanta, documenta, valida e gerencia requisitos de software.

Tá, mas o que é um requisito?

Muitos autores e profissionais da área de TI consideram que o termo requisito se refere à documentação.

Embora o requisito não se restrinja apenas à documentação, o que seria ele?

De acordo com o dicionário, um requisito é uma condição básica e necessária para se alcançar um determinado objetivo ou propósito.

Ou seja, nada mais é do que o desejo, vontade, objetivos, exigências.

Em outras palavras, é uma condição ou capacidade necessária por um usuário para resolver um problema ou alcançar um objetivo(ISO/IEC/IEEE, 2010).

Assim como também é uma condição ou capacidade que deve ser atingida ou possuída por um sistema ou componente para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto (ISO/IEC/IEEE, 2010).

Sendo assim, os requisitos incluem as necessidades identificadas, quantificadas e documentadas, além dos desejos e expectativas do cliente, da empresa e de todos os outros envolvidos no projeto.

Especificação de Requisitos

Em primeiro lugar, a especificação de requisitos é como um contrato entre o cliente e a empresa/equipe desenvolvedora do projeto.

Nesse documento, deve constar aos interessados, todo o trabalho que a equipe irá fazer. E após isso, ser validado e aprovado pelo cliente. 

Somente após esse processo o desenvolvimento do software se inicia. Por isso, o primeiro objetivo da especificação de requisitos é documentar todas as necessidades do cliente e obter sua aprovação.

O segundo objetivo da especificação é contribuir para que a equipe realmente compreenda a realidade do cliente e entenda suas necessidades corretamente.

Portanto, compreender o que o cliente realmente deseja é o grande objetivo da especificação de requisitos.

Quais as áreas da especificação de requisitos?

A especificação é composta por um conjunto de tópicos, são eles:

• Visão geral: delimita os objetivos do projeto, as partes interessadas e uma breve descrição das funções que o sistema deverá ter
• Glossário: termos técnicos utilizados no documento
• Modelos do sistema: exemplificam o relacionamento entre os componentes do sistema e entre o sistema e seu ambiente. (Ex: diagrama de casos de uso)
• Lista de requisitos funcionais: descreve tarefas e serviços que serão fornecidos pelo sistema aos seus usuários.
• Lista de requisitos não-funcionais: descrevem as restrições impostas sobre o software e as relaciona aos requisitos funcionais.
• Especificação detalhada dos requisitos: detalha os requisitos funcionais.

(VAZQUEZ, 2016)

Quem lê a especificação de requisitos?

Os leitores da especificação de requisitos, geralmente são os clientes e membros da equipe de desenvolvimento do software.

Sendo assim, o gerente de projeto, por exemplo, usa a especificação para construir o planejamento do projeto. O arquiteto de software usa para elaborar a arquitetura do software, e assim por diante.

Dessa forma, além de a especificação de requisitos servir como base e o norte para a equipe do projeto, ela também serve como base para a manutenibilidade futura do software.

Por que a engenharia de requisitos é tão importante?

Como você já viu nos tópicos anteriores, a engenharia de requisitos é parte fundamental da engenharia de software. Mas não é só por isso que ela é importante.

Quando não executada, as consequências negativas em um projeto são severas. Ou seja, os transtornos variam desde o atraso no cronograma e custo adicional até falhas gravíssimas no software, que podem comprometer seu funcionamento. 

Exemplos de como a engenharia de requisitos é importante

Sonda espacial Mars Climate Orbiter

A Mars Climate Orbiter foi uma sonda espacial dos Estados Unidos que deveria ter estudado o clima de Marte. 

Tudo correu bem no lançamento até chegar à Marte. Ao entrar na sua órbita, a sonda espacial foi destruída na atmosfera por causa de um erro de cálculo.

Nesse caso, o problema foi o fato de que o software desenvolvido por um fornecedor não estava adequado ao sistema de medida da NASA. 

Esse fornecedor produzia softwares no sistema imperial britânico (pound-seconds). Contudo, a NASA trabalhava com o sistema de medida métrico universal (newton-seconds).

Um erro de milhões por bobeira, não é?

Foguete Ariane 5

4 de junho de 1996 será para sempre lembrado como um dia sombrio para a Agência Espacial Europeia. O primeiro voo não tripulado do foguete Ariane 5, que decolou carregando quatro satélites científicos caríssimos, acabou 39 segundos depois do lançamento, em uma horrível bola de fogo e fumaça. Estima-se que a explosão causou um prejuízo de US $370 milhões. (BBC)

Pela manchete da notícia já deu para perceber que os danos não foram poucos, não é? Mas você sabe por que o foguete explodiu?

De acordo com a BBC, o foguete não caiu por falha mecânica e nem por sabotagem. Ele explodiu porque houve um bug no seu software. O sistema ficou sobrecarregado e não conseguiu fazer os cálculos corretamente.

Você pode ler a notícia aqui.

Certo, mas o que esses exemplos têm a ver com a engenharia de requisitos?

Tanto a Mars Climate Orbiter quanto o Ariane 5 falharam na especificação dos requisitos.

Se a engenharia de requisitos da sonda de Marte tivesse sido mais especificada, a diferença entre o sistema de medidas britânico e a da NASA seria identificada, não é? 

Eles teriam readaptado o software às medidas que a NASA usava como padrão. 

Por outro lado, o foguete Ariane 5 compartilhou do mesmo software utilizado no foguete Ariane 4.

Contudo, os dois foguetes tinham suas particularidades. O Ariane 5, por exemplo, foi projetado para levar mais carga do que o seu anterior. 

Assim, o erro da equipe foi não ter adaptado o software a este novo objetivo do foguete. 

Você percebe agora o quanto é importante a engenharia de requisitos em um projeto?

Com essa documentação bem feita a equipe pode prever falhas catastróficas. Sem ela, qualquer desastre pode acontecer.

Por que os projetos fracassam?

Com base na análise do PMI, 47% dos projetos fracassam porque não fazem a engenharia de requisitos corretamente.

Quando o projeto da construção de uma ponte dá errado, a gente consegue perceber facilmente, pois ou ela cai ou ela não conecta uma ponta à outra.

Porém, em relação ao software, as falhas são mais difíceis de se perceber. Muitas vezes, é apenas nas mãos do usuário que o cliente e a equipe desenvolvedora identificam os problemas.

Alguns dos motivos de porque os projetos fracassam

• Erro no cálculo/estimativa do orçamento
• O produto não satisfaz o cliente
• A equipe desenvolve requisitos não necessários ou que não estavam previstos
• O produto não apresenta os requisitos essenciais do projeto

Principais dificuldades de engenharia de requisitos

Consequentemente, não é tão simples elaborar um documento de requisitos que contenha todas as necessidades do cliente de forma abrangente e detalhada.

Existem, é claro, situações que dificultam esse processo, veja só:

Falha na comunicação

O principal objetivo de uma boa comunicação entre os envolvidos no projeto, é compreender quais são as verdadeiras necessidades do cliente. E para isso, é imprescindível que haja uma comunicação sensível e aberta entre eles.

Falta de acesso com o cliente

Como é possível fazer um levantamento de requisitos sem a proximidade com o cliente? 

De fato, há clientes inacessíveis e com isso, a equipe não tem outra opção senão estudar por conta própria a realidade e especular quais seriam as necessidades desse cliente.

Usuário/Cliente indeciso

Realmente, um usuário ou cliente indeciso no que quer pode prejudicar a equipe de desenvolvimento. Por isso é extremamente importante que haja comunicação entre as partes e que a equipe se esforce para compreender o que o cliente quer.

É correto afirmar que em muitos casos, nem eles sabem o que de fato querem. Mas com muito diálogo e uma equipe sensível às suas necessidades, logo chega-se a um entendimento.

Mudanças constantes

Assim como um cliente não saber o que realmente quer pode prejudicar um projeto, mudar constantemente os requisitos também é prejudicial.

Pense comigo: os desenvolvedores do projeto acabaram de terminar o código de um site inteiro e na hora de apresentar o resultado para o cliente, ele resolveu fazer algumas mudanças no layout. 

Embora tenham levado em consideração todos os requisitos, no fim o cliente resolveu modificar o projeto. Esses contratempos são muito comuns nos projetos de software.

Contudo, não podemos negar que essas mudanças prejudicam, pois além de aumentar o orçamento ainda ultrapassa o prazo combinado.

Tipos de requisitos

Agora que você já compreendeu um pouco mais sobre a engenharia de requisitos, vamos conversar agora a respeito dos requisitos.

Existem vários tipos de requisitos e nesse tópico, você vai compreender um pouquinho de cada um deles.

Requisitos das partes interessadas

Você deve se lembrar que as partes interessadas são as pessoas que participam do projeto, certo?

Portanto, os requisitos das partes interessadas são os feedbacks quanto a compreensão das necessidades do projeto.

Requisitos da solução

Quando as partes interessadas se unem para chegar a um consenso de quais são os requisitos do projeto, há divergências, conflitos e falta de informação.

É justamente nessa parte que os requisitos de solução entram. Esses requisitos são definitivamente a solução aos problemas encontrados.

Requisitos de transição

Vou usar o exemplo que o Carlos Eduardo Vazquez deu no seu livro Engenharia de Requisitos:

Ao levantar um edifício, os operários construíram também um vestiário e um refeitório para que eles pudessem usar no dia a dia. Porém, quando a obra terminar, tanto o vestiário como o refeitório vão ser desmontados.

Assim, eles só foram necessários apenas durante a construção do edifício. Da mesma forma é com os requisitos de transição. 

Com isso, os requisitos de transição permitem que uma nova solução possa funcionar. São apoios, funções que permitem desenvolver um requisito e então, são descartados do projeto.

Requisitos funcionais

Esses requisitos descrevem o comportamento que as funcionalidades do software devem ter.

Requisitos não-funcionais

De certa forma eles complementam os requisitos funcionais. Estão relacionados ao uso da aplicação em relação ao desempenho, usabilidade, segurança, confiabilidade, disponibilidade, manutenibilidade e tecnologias envolvidas.

Concluindo

Agora você já tem uma base do que é a engenharia de requisitos não é? Você viu aqui no post o que é a engenharia de software, quais são os benefícios e as consequências de se não fazer uma análise de requisitos adequada.

Eu também te mostrei o que é um requisito e quais são os principais na área de engenharia de requisitos.

Para escrever esse post, eu usei esse livro aqui. Eu o recomendo fortemente se você quiser se aprofundar no assunto.

Até o próximo post.

---

engenharia de requisitos engenharia de software gestão de software

Last modified: 9 de dezembro de 2023