Engenheiros de software (algumas vezes conhecidos no mundo da TI como engenheiros de sistemas ou analistas ) e outros interessados no projeto

Transcrição

1 ... 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

2 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

3 DEFINIÇÃO Domínio do Problema 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 da Solução

4 Projetar e construir um programa de computador elegante que resolva o problema errado não atende as necessidades de ninguém...

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

6 Fonte: [2]

7 Fonte: [2]

8 MOTIVAÇÃO ER também é uma atividade essencialmente e acidentalmente difícil [4]: Fonte: [3] 8 8

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 9

10 Clientes dispersos, numerosos; Clientes com Objetivos conflitantes, Perspectivas diferentes, Formações distintas; Volatilidade dos requisitos; 10 10

11 Tipos de requisitos voláteis: Mutáveis Originados a partir de mudanças no ambiente. Emergentes Surgem durante o desenvolvimento

12 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; 12 12

13 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

14 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

15 PERSPECTIVAS Perspectiva de domínio Perspectiva tecnológica Perspectiva temporal 15 15

16 PERSPECTIVA DE DOMÍNIO Domínio do problema Exploração detalhada de um problema particular para determinar as necessidades de automação do usuário. Domínio da solução Especificação do comportamento externo de um sistema

17 PERSPECTIVA TECNOLÓGICA Existem vários mecanismos de especificação: Linguagem natural; UML; Prototipação; Métodos formais, etc

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

19 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

20 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.

21 Em software: É a CARACTERIZAÇÃO do que o sistema deverá fazer. Existem vários tipos de requisitos que devem ser analisados 21 21

22 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.

23 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.

24 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.

25 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.

26 [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

27 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.

28 Propriedade Velocidade Métrica Transações processadas por segundo. Tempo de resposta ao usuário/evento. Tempo de atualização da tela. Tamanho Facilidade de Uso Confiabilidade Robutez Portabilidade Kbytes. Número de chips de RAM. Tempo de treinamento. Número de telas de ajuda. Tempo médio para falhar. Probabilidade de indisponibilidade. Taxa de ocorrência de falhas. Disponibilidade. Tempo de reinício após falha. Porcentagem de eventos que causam falhas. Probabilidade de que os dados sejam corrompidos por falhas. Porcentagem de declarações dependentes de sistema-alvo. Número de sistemas-alvo.

29 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.

30 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

31 [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 [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 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: [5] Sommerville, Ian. Engenharia de Software, 8ª Edição. São Paulo: Pearson Addison-Wesley, 2007.

32