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.
Palavras-chave: Engenharia de Requisitos, Alicerce de Engenharia de Software, Satisfação do Cliente,
Apoio: Larissa Ibiapina, ESD.
Artigo aceito e publicado no portal abramti.org.br. Estou muito feliz por essa conquista :)
ResponderExcluirhttp://www.abramti.org.br/node/115