A Engenharia de Requisitos
O principal objetivo da Engenharia de Requisitos é criar e manter documentos de requisitos de sistemas, chamado de Documento de
Especificação de Requisitos de Software (DERS) [2]. O processo de engenharia de requisitos, como um todo, contém cinco grandes subprocessos que são: em quais aspectos o sistema é útil ao negócio (estudo de viabilidade); descoberta de requisitos (elicitação e
análise); conversão de tais requisitos em um formato padrão (especificação); checagem se os requisitos estão bem descritos e
condizentes com a função que realizará no sistema após sua implementação (verificação); e descoberta se tais requisitos realmente
definem o sistema tal como o usuário deseja (validação).
Todo o trabalho feito nas fases iniciais de Engenharia de Requisitos (viabilidade, elicitação, análise e especificação) gera como resultado
o DERS. O DERS é o documento oficial do que deverá ser implementado pelos desenvolvedores do sistema [2].
O Documento de Especificação de Requisitos de Software
O DERS, segundo o IEEE (Institute of Electrical and Electronics Engineers), deve ser completo e não ambíguo, sendo responsável por
auxiliar os clientes de software a descrever com precisão o que eles desejam obter, e desenvolvedores de software a entender
exatamente o que o cliente deseja.
Ainda segundo o IEEE, para os clientes, desenvolvedores e outros indivíduos ligados ao projeto, um bom DERS deve prover diver sos
benefícios, tais como:
- Estabelecer a base de acordo entre os clientes e a empresa fornecedora sobre o que o software irá fazer;
- Reduzir o esforço de desenvolvimento;
- Prover uma base para estimativas de custo e prazos;
- Prover uma base para validação e verificação do produto;
- Facilitar a manutenção do produto de software final.
Um DERS conta com alguns padrões indicados para sua elaboração. O IEEE elaborou um documento que contém padrões e práticas
recomendadas para a criação do DERS chamado IEEE Recommended Practice for Software Requirements Specification - Práticas
Recomendadas para a Especificação de Requisitos de Software. Segundo essas práticas, o DERS deve ter uma estrutura tal como
mostrada na Figura abaixo.
As seções devem, então, ser preenchidas da seguinte maneira:
- Propósito (1.1): deve delinear o propósito particular deste DERS e especificar para quem está sendo feito esse documento.
- Escopo (1.2): deve especificar o produto software a ser produzido, nomeando-o; explicar o que o produto irá fazer e, se necessário, o
que não irá fazer, descrever as aplicações do software que está sendo especificado, incluindo benefícios, objetivos e metas relevantes.
- Definições, siglas e abreviaturas (1.3): deve prover a definição de todos os termos, siglas e abreviaturas que são necessárias para
entender este DERS.
- Referências (1.4): deve prover uma lista de todos os documentos que forem referenciados em outros locais do DERS, identificando cada
um por autor, título, data, editora, organização, e outros atributos quando aplicáveis.
- Visão Global (1.5): deve apresentar de forma sucinta e resumida o que os capítulos restantes do DERS irão tratar.
- Perspectiva do produto (2.1): deve colocar o produto na perspectiva de outros produtos relacionados. Se é um produto independente,
isso deve ser dito aqui. Caso contrário, se é um componente de um sistema maior, o que ocorre frequentemente, então esta subseção
deve relatar as interfaces entre esse software e o sistema, além dos requisitos do sistema maior para a funcionalidade deste software.
- Funções do produto (2.2): deve prover um índice das principais funções que o software irá executar.
- Características do usuário (2.3): deve descrever as características gerais dos usuários do produto.
- Restrições (2.4): deve descrever qualquer outro item que limite as opções do produto, tais como políticas de controle, limitações de
hardware, interface com outras aplicações, controles de segurança, entre outros itens que forem relevantes.
- Pressupostos e Dependências (2.5): deve listar todos os fatores que afetem os requisitos definidos.
- Requisitos Específicos (3): contém a definição dos requisitos de software. É o principal capítulo do DERS, pois é nesta seção que os
requisitos funcionais e não funcionais estarão definidos.
Esse modelo apresentado é o padrão que o IEEE indica. Cockburn (2005) apresenta uma complementação a este modelo, onde utiliza
um modelo semelhante ao modelo do IEEE, acrescido de um capítulo para descrição de casos de uso que implementem os requisitos
funcionais especificados. Casos de uso representam a interação do sistema com seus usuários e servem como um meio de comunicação
entre os envolvidos no projeto e são geralmente descritos em forma textual, embora possam ser descritos de outra maneira, tal como
fluxogramas, diagramas, entre outras. Assim, utilizando casos de uso, o usuário revê os diagramas e as especificações para determinar
se o analista realmente capturou os requisitos do sistema. Por este motivo, é essencial que os diagramas e as especificações mostrem ao
usuário os aspectos essenciais para que o software seja desenvolvido. Dessa forma, o modelo do IEEE ganha um capítulo para facilitar a
fase de validação junto aos stakeholders.
Boas Práticas para Construção do DERS
De acordo com o modelo apresentado na Figura acina, os itens 1 e 2 abordam outros aspectos do software e do projeto de software que
não são, por si só, requisitos do software.
Esses dois itens devem ser escritos obedecendo as orientações do IEEE e as especificações da empresa. O item 3, conforme
apresentado na Figura 3, configura-se então como o capítulo mais importante, pois será através deste item que o software será
especificado e é com base neste item que o cliente irá validar o produto. Os itens 4 e 5 também são importantes, pois são uma maneira
de mostrar aos stakeholders a primeira visão do projeto.
Requisitos Específicos
No item de Requisitos Específicos (item 3 conforme modelo apresentado na Figura acima) do DERS devem-se descrever os requisitos
de software, que serão funcionais e não-funcionais.
Os requisitos funcionais são aqueles que dizem respeito à funcionalidade do software, o que ele deve fazer. Esses requisitos descrevem
como o sistema deve reagir a particulares entradas e saídas e como deve agir em determinadas situações. Se necessário, também
podem ser incluídos requisitos que expliquem o que o sistema não será capaz de fazer. Os requisitos não-funcionais são restrições aos
serviços e funções oferecidos pelo sistema. Geralmente se aplicam ao sistema como um todo e não são, geralmente, aplicados
individualmente a uma característica ou serviço do sistema. Entre esses requisitos se encontram, por exemplo, os requisitos de
desempenho, de segurança, de entrada e saída, entre outros.
Descrever bem estes requisitos é fundamental para que o DERS se torne um bom DERS, pois serão estes os requisitos implementados
pelos casos de uso que serão diagramados e desenhados nos diagramas e especificações dos casos de uso (itens 4 e 5 conforme
modelo apresentado na Figura acima). Entretanto, nem sempre é fácil descrever tais requisitos e sua forma depende muito do software
que está sendo descrito [2]. É difícil então escolher um padrão geral para criação destes requisitos.
Porém, apesar das diferenças entre cada projeto de software, que irão gerar requisitos muito diferentes em cada DERS, o IEEE apresenta
algumas características que devem ser comuns a todos os requisitos. O IEEE recomenda que um requisito deve ser correto, não
ambíguo, completo, consistente, verificável, modificável e rastreável. Ainda é recomendável que os requisitos sejam organizados
de forma a facilitar a leitura do documento. Isso pode ser feito agrupando requisitos que tenham alguma funcionalidade em comum.
Exemplo:
Considere o minimundo vídeo-locadora:
CÓDIGO
ATOR
NOME
DESCRIÇÃO
RF01
Funcionário
Manter cliente
O funcionário mantém (cadastra, pesquisa, atualiza e exclui) o cliente do sistema.
RF02
Funcionário
Manter filme
RF03
Funcionário
Registrar aluguel
RF04
Funcionário
Registrar pagamento
O funcionário mantém (cadastra, pesquisa, atualiza e exclui) o filme do sistema.
O funcionário registra o aluguel de um filme do sistema.
O funcionário registra o pagamento de aluguel de um filme do sistema.
de aluguel
RF05
Funcionário
Imprimir histórico
RF06
Cliente
Consultar filme
O funcionário imprime o histórico de alugueis registrados no sistema.
O cliente consulta um filme no sistema.
A Inspeção do DERS
A inspeção do DERS é muito importante para o sucesso do DERS e deve avaliar o documento como um todo em busca de defeitos antes
da validação junto ao cliente e usuários. Os erros encontrados em um DERS podem ser:
- Omissão: é todo erro relativo a alguma informação que não foi descrita, ou seja, que não está presente no DERS. Pode ser algum
requisito que não foi incluído, falta de resposta do sistema a alguma situação, falta da definição de termos, entre outras omissões.
- Ambigüidade: ocorre sempre que alguma informação estiver descrita de forma a poder causa confusão ou dúvida.
- Inconsistência: é alguma sentença que contradiz algo que foi dito anteriormente no documento.
- Fato Incorreto: é quando um fato descrito no DERS não é verdadeiro ou não pode ser executado, de acordo com as condições
especificadas no domínio da aplicação.
- Informação Estranha: são as informações que não pertencem ao DERS, não sendo necessárias para o entendimento do mesmo. Esse
problema também contempla as informações que são passadas, mas não são utilizadas em nenhum momento no DERS.
É altamente recomendável que a inspeção do DERS seja feita por outro profissional, que não o responsável por criar o DERS.
Conclusão:
A Engenharia de Requisitos tem como um de seus objetivos a criação do Documento de Especificação de Requisitos de Software
(DERS). O DERS é construído com o intuito de conseguir descrever o que o usuário deseja antes de começar a implementar o projeto.
Quando um DERS é bem construído, através de sua avaliação junto aos stakeholders do projeto, é possível descobrir se os interes ses
dos mesmos foram corretamente entendidos, fazendo as necessárias correções a um custo muito inferior se comparado a custos em
outras etapas do projeto.
Criar um bom DERS nem sempre é fácil, mas seguindo algumas diretrizes, como as do IEEE, pode-se criar um DERS consistente e
completo. Adicionando casos de uso ao DERS ainda é possível chegar mais próximo aos stakeholders, pois trata-se de uma linguagem
de entendimento mais fácil.
Algumas boas práticas facilitam a criação de um caso de uso eficaz, que será capaz de fornecer aos interessados no projeto todas as
informações que estes precisam, de maneira objetiva e completa.
Com um DERS completo, não ambíguo e objetivo, um projeto tem maiores chances de chegar ao resultado esperado pelos stakeholders,
ou seja, ter sucesso.
Referências Bibliográficas:
DIAS, N.K.B at all., Boas práticas na Engenharia de Requisitos., Revista Engenharia de Software, Edição Nº 27, 2010.