“... definem tarefas que levam a um entendimento de qual ser´ao impacto do software sobre o negócio, o que o cliente quer e como os usuários finais irão interagir com o software.” (Pressman, 2011)

Prof. Elias Ferreira

Engenheiros de software (algumas vezes conhecidos no mundo da TI como

engenheiros de sistemas ou “analistas”) e outros interessados no projeto (gerentes,

clientes, usuários finais), todos participam da engenharia de requisitos

DEFINIÇÃO

Também conhecida como: Análise de requisitos;

Análise de sistemas.

É a área responsável pela descoberta: Das reais necessidades dos clientes.

Do comportamento externo de uma solução que atenda a estas necessidades.

Domínio do Problema

Domínio da Solução

Projetar e construir um programa de computador elegante que resolva o problema

errado não atende as necessidades de ninguém....

Segundo Brooks[5], a ER é a atividade maisimportante da construção de um software, pois determina:

Fonte: [2]

Fonte: [2]

MOTIVAÇÃO

ER também é

uma atividade

essencialmente

e acidentalmente

difícil [4]:

88Fonte: [3]

9

São aquelas inerentes à atividade em si, por exemplo:

Clientes não estarem convencidos da necessidade de um novo software;

Clientes não sabem exatamente o que querem.

Clientes com dificuldades para esclarecer seus objetivos.

9

Clientes dispersos, numerosos;

Clientes com

Objetivos conflitantes,

Perspectivas diferentes,

Formações distintas;

Volatilidade dos requisitos;10

10

Tipos de requisitos voláteis:

Mutáveis

Originados a partir de mudanças no ambiente.

Emergentes

Surgem durante o desenvolvimento.

1111

São oriundas da falta de controle sobre aquilo que precisa ser construído, por exemplo:

Pouco esforço despendido no levantamento de informações junto ao usuário;

Documentação pobre sobre os requisitos obtidos;

Pouca revisão dos requisitos obtidos;

1212

Especificações incorretas dos requisitos;

Tendência em iniciar logo o processo de desenvolvimento do software;

Não existir tempo adequado para a elicitação;

Preparação inadequada dos engenheiros.

1313

MOTIVAÇÃO

Nenhuma outra parte do desenvolvimento causa tantos prejuízos se feita de forma errada.

Corrigir um produto após sua implementação pode custar 100x mais.

1414

15

PERSPECTIVAS

Perspectiva de domínio

Perspectiva tecnológica

Perspectiva temporal

15

16

PERSPECTIVA DE DOMÍNIO

Domínio do problemaExploração detalhada de um problema particular para determinar as necessidades de automação do usuário.

Domínio da soluçãoEspecificação do comportamento externo de um sistema.

16

17

PERSPECTIVA TECNOLÓGICA

Existem vários mecanismos de especificação:Linguagem natural;

UML;

Prototipação;

Métodos formais, etc.

17

18

PERSPECTIVA TEMPORAL

É uma das atividades iniciais da engenharia de software.

Resulta no criação de um documento de Especificação de Requisitos de Software (ERS).

Este documento deve ser atualizado constantemente para obtenção de mais conhecimento sobre o problema.

18

• Descrições • De serviços fornecidos pelo sistema

• De restrições destes serviços

• Podem ser especificado formalmente

• Engenharia de Requisitos • Processo de descobrir, analisar, documentar e verificar requisitos Ti

• “Uma condição ou capacidade que um usuário necessita para resolver um problema ou alcançar um objetivo. Uma condição ou capacidade que deve ser satisfeita por um sistema para satisfazer um contrato ou um padrão”. IEEE – Institute of Eletrical and Eletronics Engineers

• “Os requisitos para um sistema de software estabelecem o que o sistema deve fazer e definem restrições sobre sua operação e implementação”. Sommerville

• “Condição necessária para obtenção de certo objetivo ou para o preenchimento de certo fim”. Dicionário Aurélio.

Em software:

“É a CARACTERIZAÇÃO do que o sistema deverá fazer.”

Existem vários tipos de requisitos que devem ser analisados…

2121

• Para que o proceso de desenvolvimento de software seja bem sucedido é fundamental que haja uma compreensão completa dos requisitos de software.

• Tanto o desenvolvedor como o cliente desempenham um papel ativo na análise e especificação dos requisitos.

• Existem dois tipos de classificação de requisitos, são eles:

• Requisitos Funcionais (RF)

• Requisitos Não-Funcionais (RNF).

• Os requisitos funcionais referem-se sobre o que o sistema deve fazer, ou seja, suas funções e informações. Os requisitos não funcionais referem-se aos critérios que qualificam os requisitos funcionais. Esses critérios podem ser de qualidade para o software, ou seja, os requisitos de performance, usabilidade, confiabilidade, robustez, etc. Ou então, os critérios podem ser quanto a qualidade para o processo de software, ou seja, requisitos de entrega, implementação, etc.

Evidentemente que as prioridades podem variar conforme a natureza do software. Isso quer dizer que um software para uma plataforma de celular terá diferentes requisitos de um software que roda num browser na web. Assim como um software de tempo real que precisa ser executado em 0.01 segundo é diferente de outro software que pode ter um tempo maior para execução de uma determinada tarefa.

Portanto, requisitos funcionais preocupam-se com a funcionalidade e os serviços do sistema, ou seja, as funções que o sistema deve fornecer para o cliente e como o sistema se comportará em determinadas situações.

[RF001] O Sistema deve cadastrar médicos profissionais (entrada)

[RF002] O Sistema deve emitir um relatório de clientes (saída)

[RF003] O Sistema deve passar um cliente da situação "em consulta" para "consultado" quando o cliente terminar de ser atendido (mudança de estado)

[RF004] O cliente pode consultar seus dados no sistema

Por fim, os definem propriedades e restrições do sistema como tempo, espaço, linguagens de programação, versões do compilador, SGBD, Sistema Operacional, método de desenvolvimento, etc. Uma dica importante é que os requisitos não funcionais são geralmente mensuráveis e assim devemos preferencialmente associar uma medida ou referência para cada requisito não funcional.

Propriedade Métrica

Velocidade Transações processadas por segundo.Tempo de resposta ao usuário/evento.Tempo de atualização da tela.

Tamanho Kbytes.Número de chips de RAM.

Facilidade de Uso Tempo de treinamento.Número de telas de ajuda.

Confiabilidade Tempo médio para falhar.Probabilidade de indisponibilidade.Taxa de ocorrência de falhas.Disponibilidade.

Robutez Tempo de reinício após falha.Porcentagem de eventos que causam falhas.Probabilidade de que os dados sejam corrompidos por falhas.

Portabilidade Porcentagem de declarações dependentes de sistema-alvo.Número de sistemas-alvo.

Segue abaixo alguns exemplos de requisitos não funcionais:

[RNF001] O sistema deve imprimir o relatório em até 5 segundos.

[RNF002] Todos os relatórios devem seguir o padrão de relatórios especificado pelo setor XYZ.

[RNF003] O sistema deve ser implementado em Java.

Defina, o que são requisitos?

Quais os tipos de requisitos existentes?

Escreva os requisitos necessários para um software de locação de filmes.

Cada requisito deve ser enumerado

Devem ser registrados 10 requisitos

Pode ser realizado em grupo: até 3 pessoas

[1] Pressman, Roger. Engenharia de Software. 6ª Edição.

[2] Lucena, F. N. Requisitos de Software: Eliciar, Registrar e Ser bem-sucedido. Disponível em http://www.inf.ufg.br/~fabio

[3] Queiróz, R. Silva, J. Eliciação e comunicação de requisitos em domínios disjuntos: estudo de caso para automação na área médica. Disponível em http://www.scielo.br/scielo.php?pid=S0103-17592009000400014&script=sci_arttext. Acessado em Set/12.

[4] Brooks, Fred P. (1986). "No Silver Bullet — Essence and Accident in Software Engineering". Proceedings of the IFIP Tenth World Computing Conference: 1069–1076.

[5] Sommerville, Ian. Engenharia de Software, 8ª Edição. São Paulo: Pearson Addison-Wesley, 2007.

http://www.devmedia.com.br/introducao-a-requisitos-de-software/29580

http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-de-requisitos/8034

http://www.devmedia.com.br/engenharia-de-software-2-tecnicas-para-levantamento-de-requisitos/9151