Por que eu devo ler este artigo:Um dos grandes problemas relacionados ao fracasso de projetos de software está relacionado com requisitos. Na grande maioria dos casos estes são incompletos, inconsistentes ou não são claros o suficiente para se obter o entendimento da necessidade do cliente.

Com base nisso, este artigo tem por objetivo apresentar a importância da rastreabilidade de requisitos de software por meio de uma abrangente revisão teórica e também, por meio de um caso prático aplicado.
Autores: Sérgio Barriviera Miguel e Vanessa Miguel

Nestes últimos anos, a fim de garantir sua competitividade no mercado de trabalho, muitas corporações têm investido em seus processos de negócio e em seus produtos de software, gerando oportunidades na área da tecnologia.

Os principais motivadores de tais esforços certamente são prazo, preço e qualidade. Esta, por sua vez, não destacada no momento da contratação de um serviço de desenvolvimento de software, mas principalmente na entrega do projeto, sendo considerada como imprescindível para que o produto possa ser utilizado por seus usuários.

Nesse cenário, ser um provedor de soluções eficiente, reconhecido por um mercado em constante transformação, não é uma tarefa fácil, somando-se ainda ao fato que os sistemas de software, em muitos casos, sofrem mudanças antes mesmo de começarem a serem modelados.

Assim, a adoção e a utilização de procedimentos com ferramentas de trabalho adequadas podem complementar e fortalecer a base estratégica de uma organização provedora de soluções de software.

A adequação da seleção destes meios depende dos motivadores do investimento nessa base estratégica e dos requisitos do projeto, resultando em um grande impacto no software e auxiliando na customização e qualidade no processo de desenvolvimento.

Para que tudo isso faça sentido, consideramos que os seguintes fatores são essenciais para o sucesso no projeto de desenvolvimento de software:

· Trabalhar de forma harmônica com o aumento do tamanho e da complexidade dos sistemas de software: significa que é necessário ter um controle total de seus requisitos e demais artefatos, além de documentos elaborados a partir do mesmo, como: casos de uso, casos de teste e componentes (entendidos nesse caso como os códigos de um sistema);

· Reduzir o tempo, o custo de desenvolvimento e a manutenção de sistemas de software: os quais são elevados principalmente em virtude do retrabalho, aonde na grande maioria dos casos pode significar mais que 60% do tempo de projeto, sendo então essencial garantir que os itens produzidos ao longo de uma fase do projeto (saídas) estejam aderentes e consistentes para serem enviados para a próxima fase (entradas);

· Ser eficaz e assertivo na identificação dos requisitos, bem como, em sua respectiva gestão: talvez seja este um dos mais complexos dos fatores mencionados, pois se faz necessário conhecer a essência do projeto, ou seja, seus objetivos de negócio, para que sejam mais bem detalhados nos requisitos de negócio.

Ao garantir que todos os requisitos de negócio estão sendo atendidos, é possível garantir que o sistema produzido está alinhado com os objetivos da organização. Porém, ainda existem outras questões importantes a serem consideradas em um projeto de desenvolvimento de software e que interferem na qualidade de seu resultado, por exemplo:

· Como saber se a solução que está sendo construída está conforme o desejo do cliente?

· Como saber se a solução atende a todos os requisitos informados pelo cliente?

· Como saber se a análise da necessidade do cliente não deixou de atender algum requisito?

· Como saber se o processo de análise, entendido aqui como a etapa do projeto em que o modelo lógico do software é desenvolvido, não deixou de atender algum requisito?

· Como saber se todos os componentes (códigos) da solução executam tarefas que serão realizadas por seus principais usuários? (Em alguns casos, funcionalidades são adicionadas à solução sem que exista um requisito responsável por sua implementação, tendo como consequência uma abrangência desnecessariamente maior do sistema, assim como os riscos envolvidos);

· Como estimar o prazo e o impacto para uma determinada mudança no sistema?

De posse de todas essas informações e sabendo que os maiores problemas relacionados com a produção de um novo software estão associados com requisitos, este artigo tem por objetivo apresentar a importância da rastreabilidade de requisitos sob a ótica do processo de desenvolvimento e gerenciamento de requisitos, de acordo com os principais guias e modelos de maturidade utilizados pelo mercado de trabalho.

Assim, este documento apresentará uma breve revisão bibliográfica, a fim de apresentar os principais conceitos e fontes de informação relacionadas ao tema abordado, inicialmente tratando sobre Requisitos e em um segundo momento, Rastreabilidade, correlacionando os conceitos com um Caso Prático.

Requisitos

Para que possamos entender o que é requisito e sua importância em um projeto de software, se faz necessário defini-lo e contextualizar suas relações com o ciclo de desenvolvimento de software.

Dentre as definições existentes, o IEEE Standard Glossary of Software Engineering Terminology, por exemplo, define requisito como uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo.

De forma geral, pode ser definido como uma condição ou capacidade com a qual o sistema deve estar de acordo. Seu estudo compreende sua especificação, sua documentação e sua validação mediante todos os envolvidos no projeto de software e é conhecido como Engenharia de Requisitos, uma disciplina da Engenharia de Software.

A Engenharia de requisitos

A Engenharia de Requisitos define requisitos como um processo, ou um conjunto de medidas, no qual para se atingir um objetivo (no caso, desenvolvimento de um software) devem ser adotadas etapas de elicitar, modelar e analisar esses requisitos.

Para que essas etapas ocorram, deve haver compreensão de diferentes pontos de vista da equipe envolvida e usar uma combinação de métodos e ferramentas. Admite-se que este processo acontece num contexto previamente definido, a que chamamos de Universo de Informações, no qual o software deverá ser desenvolvido e operado.

Trata-se do ambiente que contém todas as fontes de informação e todas as pessoas relacionadas com o sistema de software.

De acordo com Sommerville, Engenharia de Requisitos é definida como o processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema e pode ser dividida em dois grupos de atividades relacionados, o Desenvolvimento de Requisitos e o Gerenciamento de Requisitos, apresentados na Figura 1.

Figura 1. Representação da Engenharia de Requisitos e seus grupos.

Os dois tópicos seguintes detalham os grupos de atividades relacionados da Engenharia de Requisitos.

Desenvolvimento de requisitos

De acordo com o SWEBOK (Software Engineering Body of Knowledge), o Desenvolvimento de Requisitos inclui os seguintes passos:

· Elicitação de requisitos: identificação de forma proativa dos requisitos;

· Análise e negociação de requisitos: exame dos requisitos coletados e negociação com os envolvidos, caso haja requisitos conflitantes;

· Especificação e modelagem dos requisitos: documentação e criação de modelos dos requisitos com o propósito de obter uma melhor compreensão do problema a ser solucionado;

· Validação de requisitos: exame da especificação para garantir que inconsistências, omissões e ambiguidades tenham sido detectadas e corrigidas.

Gerenciamento de requisitos

A partir do momento em que os requisitos foram elicitados, analisados, especificados e validados pelo cliente, estes precisam ser gerenciados, pois o desejo de mudar os requisitos persiste ao longo do ciclo de vida de um sistema de software, seja motivado por um conjunto de melhorias ou então, porque o pr ...

Quer ler esse conteúdo completo? Tenha acesso completo