Processos da Engenharia de Requisitos

A criação e atualização de um documento contendo a relação de todos os requisitos é parte fundamental e objetivo principal do processo existente na engenharia de requisitos (SOMMERVILLE, 2007).

Conforme descrito por Sommerville (2007), o processo de definição de requisitos pode ser dividido em quatro subprocessos (Figura 17) relacionados à avaliação da utilidade e adequação para a empresa: (i) estudo de viabilidade; (ii) análise e elicitação de requisitos; (iii) especificação; e (iv) validação do software.

Figura 17. Etapas presentes no processo de engenharia de requisitos.

Fonte: Adaptado de UNESP (2006).

Estas etapas estão inseridas em um processo evolutivo e contínuo ao longo do ciclo de vida do software, já que na prática as alterações nos requisitos podem se tornar constantes, necessitando gerenciar estas mudanças para obter ao final de cada etapa um artefato reunindo as informações coletadas.

2.2.3.1 Estudo de viabilidade

Na maioria dos projetos de software, deve-se inicialmente realizar um estudo das necessidades e avaliar como o software auxiliará nos processos da empresa através de resultados obtidos em relatórios. Assim é possível verificar se sua elaboração é capaz de atingir os objetivos desejados ou se será necessário realizar alterações de orçamentos, escopo e prazos anteriormente definidos (SOMMERVILLE, 2007).

Ainda como fontes de estudo, é necessário verificar se o sistema poderá ser implementado utilizando a tecnologia atual, dentro do orçamento existente e se poderá ser integrado a outros sistemas já em operação (UNESP, 2006).

Para Sommerville (2007), a realização de um estudo de viabilidade é formada basicamente por perguntas, coleta e avaliação de informações, abordando quais seriam as contribuições oferecidas à solução proposta, ou seja, se as respostas não forem satisfatórias, deve-se recomendar o não prosseguimento do desenvolvimento, restando como conclusão que o software não irá agregar valores reais para a empresa.

Entre as pessoas envolvidas no estudo de viabilidade, podem ser citados, gerentes de departamento, funcionários, especialistas em tecnologia e demais pessoas familiarizadas com os processos e regras de negócio.

Alguns questionamentos básicos, segundo UNESP (2006), são:

• Existem problemas nos processos utilizados atualmente? Qual o impacto causado se o sistema não fosse implementado?

• Como o sistema auxiliará as atividades do cotidiano?

• Que tecnologias e habilidades serão necessárias à implementação do sistema? Estão dentro das restrições definidas de custo e prazo?

2.2.3.2 Elicitação e análise de requisitos

Como segunda etapa, os engenheiros de software e a equipe técnica realizam reuniões com os clientes e stakeholders com a finalidade de descobrir maiores detalhes sobre o domínio da aplicação, desempenho e hardware necessários.

Os stakeholders, segundo Sommerville (2007), são todas as pessoas envolvidas que possuem influência direta ou indireta sobre os requisitos do sistema, com isto diversos problemas são encontrados devido a várias razões:

• Normalmente os usuários e stakeholders possuem requisitos conflitantes e freqüentemente não sabem definir exatamente o que desejam que o sistema realize, expressando as funcionalidades em termos gerais;

• Utilizam linguagem natural e conhecimento implícito do trabalho que dificultam a identificação dos requisitos, necessitando definir os pontos em comum e avaliar quem são as potenciais fontes de requisitos; e

• Como o ambiente econômico e negócios são dinâmicos, os requisitos são modificados naturalmente, além de existirem fatores políticos que podem ser influenciados durante o processo de análise.

2.2.3.3 Especificação de Requisitos

Parte do processo responsável por definir e traduzir as informações coletadas durante o levantamento de requisitos, que compreende e define os serviços exigidos para fornecer uma base estável para o projeto do software (SOMMERVILLE, 2007). Esta etapa pode ser considerada uma das mais críticas, já que a má especificação pode resultar em erros nos estágios posteriores.

Algumas técnicas podem ser utilizadas para especificar os requisitos de software, que variam de acordo com a necessidade e com as melhores abordagens para identificar e facilitar sua obtenção.

2.2.3.3.1 Levantamento baseado em ponto de vista

Através de entrevistas realizadas com diferentes stakeholders, é possível identificar as perspectivas, classificando e descobrindo os conflitos entre as fontes de requisitos. Estas entrevistas consistem na formulação de perguntas sobre o sistema utilizado e o sistema a ser desenvolvido (SOMMERVILLE, 2007).

Ainda para Sommerville (2007), basicamente os pontos de vista podem ser divididos em três grupos genéricos:

• Pontos de vista de iteração: Responsáveis por representar todas as pessoas envolvidas direta ou indiretamente com o sistema fornecendo detalhes a respeito das características e interfaces;

• Pontos de vista indiretos: Representam os stakeholders que não utilizam o sistema, mas acabam por influenciar seus requisitos e restrições organizacionais; e

• Pontos de vista de domínio: Representam características e restrições de domínio que acabam influenciando os requisitos do sistema.

2.2.3.3.2 Casos de uso

Para Larman (2004), um caso de uso nada mais é que uma forma de aplicar e descrever um requisito que será realizado pelo software, além de serem mecanismos centrais para a descoberta e definição de outros requisitos do sistema. Sua finalidade é expressar a maneira com que elementos externos interagem com as funcionalidades disponíveis no sistema.

Os diagramas de casos de uso são elementos textuais da UML, geralmente representados em forma de diagramas, para permitir uma melhor visualização e entendimento. Para Medeiros (2004) um caso de uso é uma atividade responsável por representar a execução de determinada tarefa em um software através do relacionamento e interação entre os casos de uso e atores.

Figura 18. Exemplo de um diagrama de caso de uso.

Na Figura 18 é apresentado um exemplo de diagrama de caso de uso para um sistema de controle de usuários. Neste modelo existe um ator, o administrador do sistema, que possui acesso a duas funcionalidades principais representadas pelos casos de uso UC 02.01, para manipular e cadastrar usuários e o caso de uso UC 02.02, para gerenciar grupos de usuários. O UC 02.03 possui a funcionalidade de manipular permissões para o grupo de usuários e está relacionado através de uma extensão ao UC 02.02.

Para Booch, Rumbaugh e Jacobson (2006) um caso de uso define um comportamento específico esperado pelo sistema, sem levar em consideração as ações e aspectos necessários a sua implementação dentro do software.

Para Larman (2004), existe uma forte relação entre os requisitos funcionais e os casos de uso. A principal diferença é que os casos de uso descrevem de forma mais detalhada como uma ação será executada pelo software durante a implementação, sendo este um dos principais mecanismos utilizados em diversos processos de software, para a descoberta e definição de requisitos.

2.2.3.4 Documentação

Durante as fases da engenharia de requisitos, armazenar e organizar as informações são tarefas extremamente importantes, pois permite utilizá-las como documento oficial da especificação do sistema para clientes, desenvolvedores e usuários (PETERS; PEDRYCZ, 2001).

Denominada de Especificação de Requisitos de Software (ERS) são escritas utilizando uma linguagem natural variando o grau de detalhamento de acordo com o público alvo podendo incluir diagramas, tabelas e demais artefatos para facilitar seu entendimento (SOARES; FARIA, 2008).

Segundo Peters e Pedrycz (2001), a ERS é responsável por descrever as propriedades, restrições e funções executadas dentro de um produto de software, geralmente são escritas durante todo o processo de engenharia de requisitos.

Para Soares e Faria (2008) os seguintes tópicos são encontrados em um documento de ERS:

• Visão geral do sistema, benefícios do desenvolvimento, glossário com termos técnicos;

• Definição dos serviços, requisitos, propriedades do sistema; e

• Restrições de operação, definição do ambiente em que o sistema será executado e integração com outros sistemas.

Ao realizar a descrição dos requisitos devem ser observados os seguintes fatores (PETERS;

PEDRYCZ, 2001):

• Funcionalidade: As tarefas que o software deverá realizar, suas funções e estados;

• Interface externa: Interação do software com o ambiente, pessoas, hardware e outros software;

• Desempenho: Velocidade, disponibilidade, tempo de resposta;

• Atributos: Portabilidade, rastreabilidade, manutenibilidade, qualidade, estabilidade, segurança; e

• Restrições: Padrões de qualidade, linguagens de codificação, recursos, orçamento, ambiente.

2.2.3.4.1 Especificação de requisitos de software segundo IEEE 830-1998

Dentre as diversas abordagens e modelos disponíveis para serem utilizados como modelo de ERS, destaca-se a especificação proposta pelo IEEE (Institute of Electrical and Electronics Engineers - Instituto dos Engenheiros Elétricos e Eletrônicos), responsável por definir boas práticas para a especificação de requisitos proveniente de resultados obtidos de diversos processos da engenharia de software (PETERS; PEDRYCZ, 2001).

Esta subseção foi escrita baseada na recomendação proposta pelo IEEE, foram extraídos do documento as principais características que devem estar presentes na especificação de requisitos, para servir como base na modelagem e desenvolvimento desta atividade na ferramenta WebCASE.

Considerando algumas das informações necessárias que devem estar presentes no escopo da ERS abaixo são detalhadas de maneira sucinta, explicando o porquê de sua utilização (IEEE, 1998).

Característica da ERS

• Correta: Uma ERS está correta se, e somente se, todos os requisitos atendem as necessidades do software, podendo ser avaliada pelos usuários se ela está correta e reflete os objetivos (ibidem).

• Sem ambigüidade: Nenhum requisito deve possuir mais de uma interpretação e que no mínimo cada requisito é descrito utilizando um único termo. Uma forma de representar os requisitos é através da utilização de ferramentas para auxiliar sua descrição através de uma linguagem própria onde muitas vezes são utilizados diagramas para auxiliar este processo (ibidem).

• Completa: Uma especificação somente poderá ser dita completa se todos os seus requisitos significantes estiverem disponíveis, até mesmo os relacionados à performance, funcionalidades e interfaces externas (ibidem).

• Consistência: Para que uma ERS seja considerada consistente é necessário que ela não possua conflito com outros requisitos, por exemplo, um requisito informa que um estado

“a” deve ser seguido por um estado “b”, já em outro requisitos a ocorrência de “a”ou “b”

podem acontecer simultaneamente (ibidem).

• Classificação por importância e estabilidade: Em uma ERS os requisitos devem conter indicadores particulares de importância e estabilidade. Como nem sempre os requisitos possuem a mesma importância, alguns podem ser especiais, essenciais ou críticos, enquanto outros podem ser apenas desejáveis, sendo esta diferença clara e explícita. Já na classificação por necessidade um requisito pode ser distinguido de três formas: (i) Essencial: definem implicações que afetam diretamente o sistema e se não cumpridos podem acarretar na sua não utilização; (ii) Condicional: responsáveis por melhorar e adicionar características ao software, mas não farão que ele seja rejeitado; e (iii) Opcional: características que podem não ter tanta importância e servem para aprimorar ou adicionar funcionalidades presentes na ERS (ibidem).

• Estabilidade: A estabilidade pode ser expressa com base no número de modificações esperadas, na experiência e conhecimento de eventos que possam afetar a organização

• Verificável: Toda ERS deve ser verificável, ou seja, se um requisito puder ser testado com um custo efetivo através de uma pessoa ou máquina e não for ambíguo, então ele estará cumprindo a especificação do produto. Alguns requisitos que não podem ser verificados incluem “funcionamento adequado”, “boa interface humana”, “deve ocorrer usualmente” já que teoricamente o teste de qualidade é impossível por existirem fatores externos (e.g., configuração de software, hardware, rede) que podem afetar seu perfeito funcionamento (ibidem).

• Modificável: Toda e qualquer modificação deverá ser fácil, completa e consistente mantendo a estrutura proposta. Para isto é necessário haver coerência e uma maneira fácil de organizar os requisitos (e.g., índices, tabelas, cruzamentos explícitos), e assim verificar que não existem requisitos redundantes e em conflito, garantindo a propriedade modificável a ERS. Vale lembrar que redundâncias nem sempre são erros, mas podem acarretar erros facilmente (ibidem).

• Rastreável: Para que uma ERS seja rastreável, deverá existir uma maneira clara e fácil para referenciar cada requisito em futuras modificações e aprimoramentos na documentação. Basicamente existem duas formas de realizar um rastreamento, uma através de referências para os requisitos anteriores e outra através da atribuição de um nome ou identificador único para cada requisito (ibidem).

Preparação conjunta da ERS

Clientes e fornecedores nem sempre estão capacitados a escrever uma especificação de software sozinhos, assim, é necessário trabalhar em conjunto para definir e concordar com as funcionalidades propostas pelo software e permitir que uma documentação bem estruturada e facilmente entendida seja criada (ibidem).

Evolução da ERS

Como nem sempre é possível descobrir completamente os detalhes nas fases iniciais do projeto, é necessário que a evolução da ERS avance juntamente com o progresso do software, documentando as modificações e deficiências que possam surgir com os novos requisitos. Duas considerações importantes nesta etapa devem ser consideradas: (i) os requisitos devem ser especificados completamente e na hora em que são descobertos, se por algum motivo estiverem incompletos devem ser marcados para revisões posteriores; e (ii) um processo de modificação

formal deve ser iniciado para identificar, controlar e reportar mudanças no projeto, as mudanças aceitas devem ser incorporadas a ERS. (ibidem).

2.2.3.5 Validação de requisitos

Como etapa final do processo de engenharia de requisitos, a validação permite verificar se os requisitos não possuem problemas e atendem as definições propostas pelo usuário. O custo de correção dos requisitos pode ser muito inferior e diminuir o retrabalho se identificados nesta fase, já que isto normalmente significa mudanças no projeto, na implementação e na realização de novos testes para avaliar os requisitos necessários.

Algumas das verificações que devem ser realizadas segundo SOMMERVILLE (2007) incluem:

• Validade: Avaliar se o sistema fornece as funções necessárias para desempenhar os requisitos propostos pelos stakeholders, isto se torna necessário devido à existência de diversos pontos de vista.

• Consistência: Responsável por verificar se os requisitos possuem conflitos ou estão em contradição para a realização de uma tarefa.

• Completeza: Avaliar se os requisitos necessários estão incluídos e definidos para a realização dos objetivos.

• Realismo: Responsável por verificar se os requisitos propostos estão de acordo com as tecnologias existentes, orçamentos e prazos propostos.

• Facilidade de verificação: Com o objetivo de testar e validar o sistema é necessário que os requisitos possam ser testados, verificando sua confiabilidade e demonstrando seu real funcionamento.