[Seminário] Boas Práticas na Engenharia de Requisitos

Engenharia de Requisitos

• A Engenharia de Software surgiu com o objetivo de definir e aplicar métodos que pudessem ajudar no processo de construção, manutenção e implantação de software.
• A Engenharia de Requisitos pode ser vista como uma sub-área da Engenharia de Software, cujo principal objetivo é a obtenção de uma especificação correta e completa dos requisitos.

Objetivo

• 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).
• O processo de engenharia de requisitos, contém quatro grandes sub-processos que são:
-Estudo de viabilidade
-Elicitação e análise
-Especificação
-Validação

Ciclo de Vida Clássico

Definição:

• É um método sistemático e seqüencial, em que o resultado de uma fase se constitui na entrada da outra fase.
• Foi modelado de acordo com o ciclo da engenharia convencional e abrange as seguintes fases:
- Análise de Requisitos do software
- Projeto
- Implementação ou Codificação
- Testes
- Manutenção

• Análise de Requisitos de Software: Constitui a modelagem lógica do
sistema. Nessa fase, os requisitos levantados são transformados em modelos os quais representam o sistema em nível conceitual.

• Projeto: Nessa fase, os modelos conceituais são transformados em modelos físicos, os quais devem estar mais próximos da implementação.

• Implementação ou codificação: Tradução do projeto em uma forma que seja legível pela máquina.

• Testes: Os testes são realizados após a implementação. Os testes são feitos internamente a um módulo, linha a linha, e também são feitos testes de integração dos módulos.

• Manutenção/Suporte: A fase de manutenção pode ser:

- Corretiva: Erros podem ser encontrados durante o funcionamento do sistema.

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. Segundo o IEEE, um bom DERS deve prover diversos 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 custos 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 com práticas recomendadas para especificação de requisitos de software, segundo essas práticas o DERS deve ter uma estrutura da seguinte forma:

- Propósito: Deve delinear o propósito particular deste DERS e especificar para quem está sendo feito esse documento.

- Escopo: 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: Deve prover a definição de todos os termos, siglas e abreviaturas que são necessárias para entender este DERS.

- Referencias: Deve prover uma lista de todos os documentos que forem referenciados em outros locais do DERS, identificando cada um por autor, titulo, data, editora, organização, e outros atributos quando aplicáveis.

- Visão Global: Deve apresentar de forma sucinta e resumida o que os capítulos restantes do DERS irão tratar.

- Perspectiva do produto: Deve colocar o produto na perspectiva de outros produtos relacionados. Se é um produto independente, isso deve ser dito na hora. Caso contrario, se é um componente de um sistema maior, o que ocorre freqüentemente, então esta subseção deve relatar as interfaces entre esse software e o sistema, alem dos requisitos do sistema maior para a funcionalidade deste software.

- Funções do produto: Deve prover um índice das principais funções que o software irá executar.
- Características do Usuário: Deve descrever as características gerais do usuário do produto.

- Restrições: 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: Deve listar todos os fatores que afetem os requisitos definidos.

- Requisitos Específicos: Contem a definição dos requisitos de software. É o principal capitulo do DERS, pois é nesta seção que os requisitos funcionais e não funcionais estarão definidos.

• Com essa analise, podemos facilmente detectar que boas praticas de engenharia de requisitos que procurem evitar a propagação de falhas para outras fases podem trazer benefícios como a redução de custo do projeto. Entre as boas práticas estão a padronização, a inspeção e a revisão do DERS.

- Requisitos Específicos: Descreve os requisitos de software que serão funcionais e não-funcionais.

- Requisitos Funcionais: São aqueles que descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem que ser feito pelo sistema. São o cérebro do projeto, já que descrevem as funcionalidades que o sistema deve dispor.

- Requisitos não-funcionais: são aqueles que expressam como deve ser feito. Em geral se relacionam com padrões de qualidade como confiabilidade, desempenho, robustez, etc. São muito importantes, pois definem se o sistema será eficiente para a tarefa que se propõe a fazer ou não. Um sistema ineficiente certamente não será usado. Neles também são apresentados restrições e especificações de uso para os requisitos funcionais.

• Diagrama de Casos de Uso

- O diagrama de casos de uso deve mostrar, graficamente, todas as funções que um sistema precisará desempenhar e, para sua construção, deve obedecer aos padrões da UML (Unified Modeling Language).

• Objetivos

- Um diagrama de casos de uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário.

- O cliente deve ver no diagrama de casos de uso as principais funcionalidades de seu sistema.

• Descrição dos Casos de Uso

- Um caso de uso é escrito em linguagem natural e é constituído por uma seqüência de sentenças. Estes passos são compostos por ações simples, que descrevem o ator realizando uma tarefa ou passando informação para um outro ator. Um caso de uso tem normalmente, ao menos, dois finais possíveis, um de sucesso e outro de erro.

- Um caso de uso sempre será responsável por implementar, pelo menos, um requisito funcional do sistema. Todos os requisitos funcionais do sistema devem estar ligados a um ou mais casos de uso. Essas ligações entre casos de uso e requisitos são necessárias para permitir a rastreabilidade dos requisitos.
- Os fluxos são a partes principais do caso de uso. Um caso de uso deve conter todos os cenários, tanto de sucesso quanto de falha.
- Algumas boas práticas para escrever um caso de uso de forma eficaz:

a) Utilizar gramática simples, pois o principal objetivo do UC é mostrar de forma clara o que sistema faz.
b) Mostrar claramente quem são os atores.
c) Incluir todas as ações, ou seja, todas as de sucesso e de falha.
d) Validar, pois deixa claro que o sistema irá validar os dados inseridos de acordo com as regras de negócio e restrições para os valores.
e) Mencionar o tempo apenas opcionalmente.

1. A Inspeção do DERS (Documentos de Especificação de Requisitos de Software)
• É um fator muito importante para o sucesso do DERS, avaliando o documento como um todo em busca de defeitos antes da validação junto com os clientes e usuários.
• Alguns dos defeitos encontrados em um DERS:

- Omissão: é todo erro relativo a alguma informação que não foi descrita.
- Ambigüidade: ocorre sempre que alguma informação estiver descrita de poder causa dúvida ou confusão.
- 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.
- Informação Estranha: são as informações que não pertence ao DERS.

• Importante: é altamente recomendável que a inspeção seja feita por outro profissional e não pelo responsável pela criação do DERS.

2. Construção do DERS

• A seguir segue alguns exemplos referentes ao DERS:

Exemplo da descrição do caso de uso “Cadastrar Veículos”.

Exemplo 1

Nome do Caso de uso: Cadastrar Veículos
Descrição: O Diretor ou gerente solicita o cadastro de veículos liberados para locação, o funcionário faz o cadastro e libera o veículo para a disponibilidade de locação.
Atores Diretor/Gerente/Funcionário
Interessados: Empresa
Pré-Requisito: Usuário deve estar logado no sistema
Interação entre ator e sistema:
Ator Sistema
1. Usuário informa os dados do veículo a ser cadastrado.
2. O sistema exibe as informações a serem cadastradas.
3. Usuário verifica as informações e confirma;
4. O sistema salva as informações e exibe uma mensagem de sucesso no cadastro;

Fluxo Principal:
1. [EV] O usuário informa os dados do veículo a ser cadastrado;
2. [RS] O sistema exibe as informações a serem cadastradas;
3. [EV] Usuário verifica as informações confirmando-as;
4. [RS] O sistema armazena/exibindo uma mensagem de sucesso na operação;
Exceções:
1. Veículo cadastrado.
1.1. [EV] Usuário informa os dados do veículo a ser cadastrado;
1.2. [RS] O sistema exibe uma mensagem de veículo já cadastrado;
2. Veículo não cadastrado.
1.1 volta ao fluxo principal passo 1.

Exemplo do diagrama de casos de uso.

Exemplo 2





Considerações Finais

• Quando um DERS é bem construído, através de sua avaliação junto aos stakeholders do projeto, é possível descobrir se os interesses dos mesmos foram corretamente entendidos, pois algumas boas praticas 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.


Seminário de Boas Práticas de Engenharia de Software
Grupo:
Carlos Eduardo Momesso Raiz, RA:1801252209
Élica Regina de Oliveira, RA: 1801280001