Noções de Engenharia de Requisitos

Este artigo é o Capítulo II da minha monografia de Especialização em Engenharia de Software. Embora seja um referencial teórico e não acrescente nada de novo, espero que o possa ser útil de alguma forma para o leitor.

Introdução

Este capítulo apresenta noções sobre a engenharia de requisitos. Os requisitos são a base para a atividade de estimação do software, pois fornecem a abstração necessária do problema para que os engenheiros software executem a devida análise do problema.

No contexto de uma organização, um requisito normalmente tem sua origem em uma necessidade de negócio. A ideia de se desenvolver um software surge quando há um conjunto de necessidades específicas a serem atendidas, as quais devem ser traduzidas em requisitos.

Este processo inclui uma série de dificuldades e desafios. Problemas de comunicação, entendimento e complexidade são alguns dos fatores que contribuem para isso.

Os próximos tópicos apresentam diferentes abordagens e conceitos sobre os requisitos que causam impacto direto na estimação de um software.

Definição de requisito

Sommerville (2003, p. 82) identifica duas visões distintas sobre o termo requisito. Este pode ser “uma visão abstrata, de alto nível, de uma função que o sistema deve fornecer ou de uma restrição do sistema” ou, em outro extremo, “uma definição detalhada, matematicamente formal, de uma função do sistema”.

O autor ainda destaca diferentes níveis de detalhamento dos requisitos:

• Requisitos do usuário: declarações em linguagem natural sobre as funções que o sistema deve fornecer.
• Requisitos do sistema: detalhamentos das funções e restrições do sistema, podendo ser usados no contrato de desenvolvimento de software.
• Especificação de projeto de software: descrição abstrata do projeto de software, acrescentando mais detalhes sobre a solução aos requisitos do sistema.

Os requisitos são a base para o desenvolvimento de uma solução para o problema. Com o entendimento dos requisitos num determinado momento do projeto se constrói o respectivo modelo de análise. A estimação do software pode ser feita com nesse modelo, que contém os elementos da solução do problema que serão desenvolvidos.

O nível de detalhamento e a maneira formal ou abstrata de especificação dos requisitos é uma escolha a ser feita de acordo com o projeto. Porém, cedo ou tarde, uma especificação matematicamente formal dos requisitos terá que ser criada como parte do programa de computador, seja através de documentação ou diretamente no código-fonte. A compreensão sobre o problema e a experiência da equipe no tipo de problema são critérios que podem definir essa questão. A necessidade de estimar em maior ou menor grau de detalhe também influencia na decisão.

Tipos de requisitos

Os requisitos podem ser classificados em funcionais e não funcionais (Sommerville, 2003, p. 83). Requisitos funcionais são aqueles ligados diretamente às funções ou reações que o sistema deve apresentar. Requisitos não funcionais são restrições impostas ao funcionamento do sistema, tais como restrições de tempo, de orçamento, do processo de desenvolvimento, políticas organizacionais, padrões que devem ser adotados, entre outros. Existem ainda requisitos de domínio, ou seja, aqueles originados do domínio da aplicação, podendo estes ser funcionais ou não funcionais.

A distinção entre os tipos de requisitos é relevante no sentido de contribuir para o gerenciamento de prioridades. Se não há tempo ou recursos suficientes para desenvolver todos os requisitos, geralmente priorizam-se os requisitos funcionais.

Os requisitos funcionais são os componentes principais das estimativas. Em geral, eles são mapeados diretamente a funcionalidades ou elementos do sistema de software. Em decorrência disso, a qualidade dos requisitos funcionais tem grande efeito sobre a qualidade das estimativas.

Requisitos não funcionais afetam as estimativas em graus diferentes, dependendo da natureza de cada um. As técnicas e modelos de estimação possuem fatores de ajuste e calibragem que incluem restrições técnicas, complexidade do problema, ferramentas de desenvolvimento, etc. Portanto, esses tipos de requisitos também afetam a qualidade das estimativas.

Mutabilidade dos requisitos

Os requisitos de software não podem ser definidos estaticamente no decorrer do projeto. A definição de um requisito representa um instantâneo, mas não as mudanças que ele sofre no decorrer do tempo. Pressman (2006, p. 39) afirma que “hoje em dia, o trabalho de software é em ritmo rápido e sujeito a uma torrente sem fim de modificações (de características, funções e conteúdo da informação)”.

McConnell (1996) afirma que, em média, os requisitos mudam 25% desde a fase em que deveriam estar definidos até a primeira versão do software. Essa estimativa demonstra a natureza mutante dos requisitos e consiste num dos motivos pelos quais o software e as estimativas também não são estáticos.

Engenharia de requisitos

A engenharia de requisitos é uma atividade da Engenharia de Software que busca o entendimento do sistema a ser construído (Pressman, 2006, p. 117). Ela não é uma ciência exata, mas oferece uma abordagem sólida para enfrentar os desafios de comunicação e complexidade encontrados no início do projeto de software.

Além disso, os requisitos devem ser identificados e gerenciados no decorrer do projeto de forma que reflitam as reais necessidades dos clientes. O entendimento do sistema deve aumentar com o passar do tempo e os requisitos devem refletir este aprofundamento.

Pressman (2006, p. 117) afirma que é importante identificar corretamente os requisitos durante as fases de análise e modelagem. Ele contradiz os autores que defendem a prática de iniciar o desenvolvimento do software precipitadamente. Segundo esses autores, não valeria a pena gastar tempo com os requisitos iniciais devido às inevitáveis mudanças, de modo que as iterações iniciais tornariam as necessidades do cliente mais claras. Pressman afirma que a complexidade que surge no decorrer do projeto logo derruba esses argumentos.

Pressman (2006, p. 118) define as seguintes fases para a atividade de engenharia de requisitos:

• Concepção: fase inicial onde os engenheiros perguntam uma séria de questões livres de contexto para estabelecer um entendimento básico do problema e alguns fatores que influenciam no projeto.
• Levantamento: são feitas perguntas específicas sobre os objetivos do sistema, a meta a ser atingida, como o software será usado no dia-a-dia e assim por diante. Nesta fase, podem surgir problemas como:
  • Escopo: os limites do sistema não estão estabelecidos ou o cliente entra em detalhes técnicos desnecessários que dificultam o entendimento dos requisitos ao invés de esclarecê-los.
  • Entendimento: o cliente e os usuários não tem certeza do que é necessário, tem pouca compreensão do ambiente computacional, não tem entendimento do domínio do problema, omitem informações, apresentam necessidades conflitantes e assim por diante.
  • Volatilidade (ou mutabilidade): os requisitos mudam ao longo do tempo.
• Elaboração: procuram-se eliminar os problemas das fases anteriores, tentando estabelecer um modelo refinado dos requisitos que consiste num modelo de análise e contém cenários de uso e a descrição de como o usuário irá interagir com o sistema.
• Negociação: os requisitos propostos pelo cliente ou pelos usuários que são conflitantes, desnecessários, de alto risco ou inatingíveis por características do projeto, domínio ou por outro motivo precisam ser discutidos e negociados com o cliente desde o início do projeto, em cada iteração.
• Validação: uma análise da qualidade dos requisitos é realizada para garantir que não existem mais ambiguidades, inconsistências, omissões e erros através de uma revisão técnicas pelos engenheiros, clientes, usuários e outros interessados.

A estimação relaciona-se diretamente em como as atividades de engenharia de requisitos são realizadas. Quanto mais cedo forem geradas estimativas, menos detalhes serão obtidos e a margem de erro é maior. Quanto melhores habilidades e maior a experiência dos envolvidos no processo de elicitação de requisitos, maiores são as chances das estimativas serem confiáveis.

Gestão de requisitos

Os requisitos mudam e precisam ser monitorados, rastreados e gerenciados. A engenharia de requisitos é uma atividade executada durante todo o projeto. A princípio ela é mais intensamente executada para que todos os requisitos sejam elicitados, mas provavelmente diminuirá de intensidade no decorrer do tempo na medida em os requisitos forem mais conhecidos, desenvolvidos e atenderem às expectativas dos usuários.

Porém, cada mudança de requisito pode afetar vários elementos do projeto, tais como outros requisitos, funcionalidades e interfaces do sistema. A fim de gerenciar o encadeamento de mudanças utilizam-se técnicas de rastreabilidade, ou seja, identificação dos relacionamentos do requisito com os demais elementos do projeto.

Pressman (2006, p. 121) lista alguns tipos de tabelas de rastreabilidade que podem ser usadas quando há preocupação em identificar o impacto da mudança em um determinado requisito:

• Tabela de rastreamento de características: mostra relação do requisito com características importantes do sistema.
• Tabela de rastreamento de fontes: identifica a fonte de cada requisito.
• Tabela de rastreamento de dependência: relaciona os requisitos uns com os outros.
• Tabela de rastreamento de interfaces: mostra relação do requisito com as interfaces internas e externas do sistema.

Após a mudança em um requisito e a devida atualização dos elementos afetados, as estimativas de todos esses elementos também são afetadas e devem ser atualizadas. Isso permite analisar o impacto e a viabilidade da mudança no contexto do projeto.

Atividades da engenharia de requisitos

Durante o início do processo de engenharia de requisitos, na fase de concepção, Pressman (2006, p. 122) indica alguns passos necessários para colocar o projeto em andamento:

• Identificação dos interessados: um interessado é “quem quer que se beneficie de modo direto ou indireto do sistema que está sendo desenvolvido” (Pressman, 206, p. 122), tais como gerentes de negócio, gerentes de produto, engenheiros de software, engenheiros de suporte. Essas pessoas fornecerão entradas para os requisitos de usuário.
• Reconhecimento de diversos pontos de vista: os requisitos de usuário iniciais são explorados através de questões e comparações dos diversos pontos de vista dos interessados e precisam ser compostos para formar um conjunto consistente de requisitos.
• Trabalho em busca de colaboração: é necessário buscar a colaboração de todos os interessados no sistema, evitando conflitos entre as partes.
• Formulação das questões iniciais: definir questões livres de contexto para o cliente e os demais interessados no projeto.

Depois disso, na fase de levantamento de requisitos formais, Pressman (2006, p. 124) fornece as seguintes abordagens:

• Coleta colaborativa de requisitos: os interessados no projeto se reúnem e discutem a necessidade e a justificativa do novo produto, cada um expõe uma lista de objetivos que consideram importantes para o sistema, os quais são discutidos e combinados para formar uma lista geral, que então seria usada para derivar os requisitos do sistema.
• Implantação da função de qualidade: a Quality Function Deployment (QFD) é uma técnica que procura traduzir as necessidades dos clientes em requisitos que enfatizam o que possui mais valor para o cliente. Esta técnica cobre todo o processo de Engenharia de Software, mas é muito bem aplicada na engenharia de requisitos. Um ponto importante é sua classificação de requisitos em:
  • Requisitos formais: refletem objetivos e metas para o produto que garantem a satisfação do cliente.
  • Requisitos esperados: requisitos implícitos no produto, que o cliente pode não fazer deixar óbvio, mas sua falta geraria insatisfação.
  • Requisitos excitantes: requisitos que vão além das expectativas do cliente.
• Cenários de usuário: consiste na criação de um conjunto de cenários de uso que descrevam como o software será usado.

A estimação do software depende do resultado das atividades de engenharia de requisitos. Alguns produtos de trabalho comumente gerados e que podem ser usados na estimação são:

• lista de clientes, usuários e outros interessados;
• descrição do ambiente técnico do sistema;
• lista dos requisitos e restrições;
• conjunto de cenários de uso;
• protótipo desenvolvido para definir melhor os requisitos.

Modelo de análise

Segundo Pressman (2006, p. 134), “o modelo de análise é um instantâneo dos requisitos em um determinado tempo”. Quando é necessário obter uma posição atualizada do projeto ele deve ser atualizado para refletir as mudanças dos requisitos. Um modelo de análise inicial correto fornece uma base sólida para o restante do projeto, embora mudanças sejam certas.

O modelo de análise pode se basear em diferentes elementos, tais como cenários, classes, comportamentos e fluxo. Linguagens como a UML (Unified Modeling Language), com seus diversos diagramas, são utilizadas para descrever os diferentes elemento e aspectos do sistema (Pressman, 2006, p. 153).

Em um processo de desenvolvimento tradicional, o modelo de análise é o ponto de partida para a tarefa de estimação do projeto de software. Os elementos da análise servem como entrada para os modelos e técnicas de estimação.

Histórias de usuário

Os modelos ágeis utilizam histórias de usuário para capturar as necessidades dos clientes em um projeto de software. Uma história de usuário é uma descrição em primeira pessoa e em alto nível de uma ação que o usuário efetua no sistema (Cohn, 2004).

Histórias de usuário são escritas em primeira pessoa e em linguagem simples com a finalidade de melhorar o entendimento entre a equipe de desenvolvimento e o cliente, pois uma das maiores barreiras no entendimento do problema é na comunicação (Cohn, 2004). Portanto, ao invés de documentos técnicos e formais, as histórias de usuário enfatizam a forma verbal de comunicação.

Ao escrever uma história de usuário evitam-se detalhes considerados desnecessários e inconvenientes (Koskella, 2008, p. 326). Isso significa que ela deve ser escrita em poucas palavras e evitando abranger mais de uma funcionalidade. Em alguns casos, quando uma funcionalidade é complexa por natureza, várias histórias de usuário podem refletir cenários específicos dela. Além disso, uma história muito detalhada poderia prescrever tecnicamente uma solução, isto é, influenciando demasiadamente em como o desenvolvedor irá fazer sua implementação.

Backlog

O backlog é uma lista do que ainda é necessário fazer para concluir o produto ou uma iteração (Schwaber, 2004). Em geral, o backlog é composto pelo conjunto de histórias de usuário necessárias para concluir o produto ou pelo conjunto de atividades necessárias para concluir as histórias de usuário selecionadas e estimadas para a iteração. Schwaber (2004) define os dois tipos de backlog:

• Backlog do produto: a lista de histórias necessárias para concluir o produto, incluindo as estimativas para cada uma delas.
• Backlog do sprint: a lista de tarefas necessárias para completar as histórias de usuário selecionadas para a entrega do próximo incremento funcional do produto.

O backlog pode ser mantido em ordem de importância ou prioridade para facilitar o planejamento das próximas iterações e o controle da iteração atual.

As estimativas de conclusão da iteração, conclusão do produto e velocidade da equipe são derivadas do gerenciamento do backlog. O gerente ajusta as estimativas na medida em que os dados reais de tempo são coletados durante a execução das atividades.

Conclusão

A engenharia de requisitos propõe abordagens para lidar com a inevitável dificuldade em definir os requisitos de um sistema de software e construir e manter o modelo de análise, ou seja, a definição do que será construído.

Entretanto, é necessário talento, experiência e esforço para obter requisitos adequados nesse processo devido a barreiras relacionadas à comunicação, escopo e mutabilidade.

Com lista inicial de requisitos, pode ser realizada a estimação inicial do software e então criado um cronograma baseado nas funcionalidades.

Porém, o processo de desenvolvimento de software executado no projeto afetará o cronograma. O projeto não é constituído apenas de tarefas de programação sequencialmente executadas. Cada processo é composto de atividades de desenvolvimento e gerenciamento que incluem aspectos além do software em si, demandando atividades extras, dividindo o desenvolvimento em fases e iterações, fornecendo atividades de ajuste e artefatos de saída que permitam o gerenciamento do projeto. Portanto, a atividade de estimação deve considerar o processo para ajustar as estimativas geradas.

No próximo capítulo são apresentados modelos de processos de desenvolvimento de software e gerenciamento de projetos que foram propostos para organizar o desenvolvimento de software.