Engenharia de Requisitos

Transcrição

1 Engenharia de Requisitos Criado: mar/2001 Atualizado: set/2005

2 Tópicos Definição de Requisitos Participantes Processo Documento de Requisitos (SRS) Evolução dos Requisitos 2

3 Referência I.Sommerville. Sw Engineering, 6ª ed, 2001 D.H.Rombach. Sw Specification: a Framework. SEI-CM , jan/

4 Requisitos Definição de requisito: condição necessária para obtenção de certo objetivo ou para o preenchimento de certo fim [Aurélio Buarque de Holanda Ferreira 1986] em se tratando de sw... 4

5 Requisitos 1Condição ou capacitação que o usuário necessita para resolver um problema ou atingir um dado objetivo 2Condição ou capacitação necessária a um (componente de um) sistema para satisfazer um determinado padrão/contrato/especificação/documento formal [IEEE Std. Glossary of Sw Eng. Terminology 1983] 3Quaisquer funções, restrições ou propriedades que o sistema deve realizar, obedecer ou satisfazer de forma a realizar o que seus usuários desejam [R.J.Abott, An Integrated Approach to Sw Development. John Wiley,1986] 5

6 Requisitos Estabelecem o quê o sistema pode fazer Requisitos funcionais: serviços ou funções ex.: cadastrar usuários; obter desconto de IR na fonte; Requisitos não funcionais (ou propriedades): restrições impostas ao sistema (produto) ou ao processo ex.: eficiência Requisitos de domínio: características do domínio do problema. Podem ser funcionais ou não funcionais. 6

7 Requisitos não funcionais Requisitos não funcionais Requisitos do produto Requisitos da organização Requisitos externos Características de qualidade Ex.: ISO/IEC 9126 Requisitos de entrega Requisitos de implementação Requisitos de interoperabilidade Requisitos de padronização Requisitos legais Requisitos de ética [Sommerville01, c5.1.2] Requisitos de segurança Requisitos de privacidade 7

8 Tipos de requisitos não funcionais Requisitos de produto Restrições de qualidade (exemplo dado baseado Requisitos na ISO9126). Devem Requisitos ser expressos de processo em termos quantitativos externos Funcionalidade Confiabilidade Usabilidade Portabilidade Manutenibilidade 8

9 Métricas para especificar requisitos de produto Propriedade Medida Desempenho Facilidade de uso Robustez Confiabilidade Nº transações/segundo Tempo de resposta Tempo de treinamento Nº de quadros de ajuda Tempo para reiniciar após falha (fault) % de eventos que causam defeitos (failure) Probabilidade dos dados serem corrompidos em caso de defeito Tempo médio para um defeito (MTTF) Disponibilidade Taxa de defeitos 9

10 Tipos de requisitos não funcionais Requisitos de produto Requisitos de processo Conseqüência de políticas e procedimentos Requisitos internos da empresa externos fornecedora ou cliente Padrões de desenvolvimento Restrições de Projeto Restrições de Entrega/Instalação 10

11 Tipos de requisitos não funcionais Requisitos de produto Requisitos de processo Requisitos externos Ex.: linguagem de desenvolvimento método de projeto Padrões de desenvolvimento Restrições de Projeto Restrições de Entrega/Instalação 11

12 Tipos de requisitos não funcionais Requisitos de produto Requisitos de processo Ex.: prazos para entrega do sw e da documentação Requisitos externos Padrões de desenvolvimento Restrições de Projeto Restrições de Entrega/Instalação 12

13 Tipos de requisitos não funcionais Surgem devido a fatores Requisitos externos ao sistema e seu Requisitos de processo produtode desenvolvimento processo Requisitos externos Restrições de Interoperabilidade Restrições de Ética Restrições da Legislação 13

14 Requisitos de domínio Aplicam-se a todos os sistemas de um determinado domínio Resultam de exigências do domínio e não de necessidades de usuários de um sistema específico Podem ser tanto funcionais quanto propriedades Ex.: funcional: O acesso ao banco de dados se dará através de uma interface que deve ser baseada no padrão Z39.50 não-funcional: Devido a leis de direito autoralo sistema deve conter alguma delete-on-print facility a ser usado para certos tipos de documentos As páginas Web devem ser compatíveis com as Recomendações W3C ( Dificuldade: geralmente são expressos em jargão do domínio da aplicação, difíceis de entender para quem não é da área [Sommerville01, c.5] 14

15 Níveis de especificação de requisitos Requisitos do usuário Nível de abstração mais alto Requisitos do sistema Requisitos (do projeto) do software Nível de abstração mais baixo 15

16 Níveis de descrição - exemplo Requisito do usuário O sw deve fornecer os meios de representar e fazer acesso a arquivos externos criados por diferentes ferramentas. 19

17 Níveis de descrição - exemplo Requisitos do sistema O sistema deve oferecer ao usuário formas de definir os tipos de arquivos externos A cada arquivo externo deve ser associada uma ferramenta Cada arquivo externo deve ser representado por um ícone específico O sistema deve permitir que o usuário defina o ícone que melhor represente um tipo de arquivo externo Quando o usuário selecionar um ícone representando um tipo de arquivo externo, deverá ser acionada e associada ao arquivo selecionado a ferramenta correspondente ao tipo de arquivo externo 20

18 O processo de engenharia de requisitos Estudo de viabilidade Extração e análise dos requisitos Especificação dos requisitos Relato sobre a viabilidade Modelos do sistema Requisitos do usuário e do sistema Validação dos requisitos Documento de Requisitos do Sw (DRS) [Sommerville 2001] 22

19 Estudo sobre viabilidade Objetivo decidir sobre a utilidade do sistema Como decidir: o que acontece caso o sistema não seja implementado? quais os problemas do processo atual? como o sistema proposto vai ajudar a resolver estes problemas? o sistema pode ser integrado com outros já existentes? o uso de novas tecnologias é necessário? o que o novo sistema deve oferecer a seus usuários? 23

20 Extração e análise dos requisitos Objetivo: obter os requisitos do sistema Como obter: contatos com clientes, usuários potenciais, gerentes e outros através de entrevistas, reuniões, questionários, análise de tarefas realizadas pelo usuário,... Produto: modelos do sistema protótipos 24

21 Especificação dos requisitos Objetivo: definir requisitos de forma precisa e detalhada que sirva como base para o desenvolvimento é recomendável que esse detalhamento se dê em paralelo com o Projeto Preliminar (ou de Arquitetura) falhas na definição de requisitos corrigir documento de requisitos 25

22 Validação dos requisitos Objetivo: Mostrar que os requisitos realmente refletem o que o cliente (ou usuário) deseja Tipos de validação: Revisões do Documento de Especificação de Requisitos Revisão por pares; inspeção Construção de protótipos uso de modelos executáveis do sistema Geração de casos de teste Os requisitos devem ser testáveis Análise Verificação de modelos; análise estática 26

23 Documento de requisitos do sw Introdução Glossário Modelos do sistema Definição dos requisitos funcionais Definição dos requisitos não-funcionais Evolução do sistema Especificação de requisitos Critérios de validação Descreve o quê e o porquê 27

24 Documento de requisitos do sw Introdução Glossário Modelos Descrição: do sistema porquê o sistema é necessário. Definição Descrição dos requisitos das funções funcionais e interações com outros sistemas. Definição Descrição dos requisitos de como não-funcionais o sistema se enquadra nos negócios Evolução ou nos do sistema objetivos estratégicos do cliente. Especificação de requisitos Critérios de validação 28

25 Documento de requisitos do sw Introdução Glossário Modelos do sistema Definição dos requisitos funcionais Contém modelos (DFD, diagramas OO,...) Definição dos requisitos mostrando não-funcionais os componentes do sistema e as Evolução do sistema interações deste com o ambiente Especificação de requisitos Critérios de validação 29

26 Documento de requisitos do sw Introdução Glossário Modelos do sistema Definição dos requisitos funcionais Definição dos requisitos não-funcionais Evolução Descreve do sistema os serviços que o sistema deve prestar Especificação em linguagem de requisitos natural, diagramas ou outras notações que o cliente/usuário possa entender Critérios de validação 30

27 Documento de requisitos do sw Introdução Glossário Modelos do sistema Descreve hipóteses que serviram de base Definição dos requisitos para o desenvolvimento, funcionais bem como alterações previstas: evolução do hw, ou dos requisitos,... Definição dos requisitos não-funcionais Evolução do sistema Especificação de requisitos Critérios de validação 31

28 Documento de requisitos do sw Introdução Glossário Modelos do sistema Definição dos requisitos Descrição funcionais detalhada dos requisitos funcionais e não funcionais (descrição Definição dos requisitos detalhada não-funcionais das interfaces com usuário e outros sistemas, por exemplo). Evolução do sistema Especificação de requisitos Critérios de validação 32

29 Documento de requisitos do sw Introdução Glossário Modelos do sistema Definição dos requisitos funcionais Descrição de critérios usados para decidir se a implementação foi ou não Definição dos requisitos bem sucedida. não-funcionais Definição dos testes de Evolução do sistemavalidação de requisitos funcionais e nãofuncionais (desempenho, segurança,...). Especificação de requisitos Critérios de validação 33

30 Gerenciamento dos requisitos É o processo de compreender e controlar as modificações nos requisitos do sistema. Deve ser realizado ao longo de todo o processo de Engenharia de Requisitos, dado que requisitos, inevitavelmente, evoluem. 34

31 Evolução dos requisitos Porquê os requisitos evoluem: Compreensão inicial do problema Requisitos iniciais tempo 35

32 Evolução dos requisitos Porquê os requisitos evoluem: Compreensão inicial do problema Mudança na compreensão inicial do problema Requisitos iniciais tempo 36

33 Evolução dos requisitos Porquê os requisitos evoluem: Compreensão inicial do problema Requisitos iniciais Mudança na compreensão inicial do problema Mudança nos requisitos tempo 37

34 Evolução: classes de requisitos Estáveis: são o cerne das atividades da organização são derivados diretamente do domínio do problema ex.: em um sistema hospitalar os requisitos relativos a médicos, enfermeiras, pacientes, tratamentos 38

35 Evolução: classes de requisitos Estáveis Voláteis: são propensos a mudanças seja durante o desenvolvimento, seja em fase operacional ex.: em um sistema hospitalar os requisitos referentes a políticas de saúde 39

36 Evolução: classes de requisitos Estáveis Voláteis: mutáveis: podem mudar devido a mudanças ambientais ex.: no sistema hospitalar o paciente pode mudar de seguro-saúde informações a serem coletadas podem ser diferentes 40

37 Evolução: classes de requisitos Estáveis Voláteis: mutáveis emergentes: podem surgir na medida em que o conhecimento do cliente sobre o sistema vai evoluindo 41

38 Evolução: classes de requisitos Estáveis Voláteis: mutáveis emergentes decorrentes: resultam da introdução do sistema computacional na empresa mudanças nos processo da empresa 42

39 Evolução: classes de requisitos Estáveis Voláteis: mutáveis emergentes decorrentes de compatibilidade: dependem de sistemas ou processos de negócio específicos dentro da empresa 43

40 Evolução descontrolada Documento de Requisitos V.1 alterações nos requisitos Código do sistema V.1 Código do sistema V.2 44

41 Evolução controlada alterações nos requisitos Documento de Requisitos V.1 Documento de Requisitos V.2 Código do sistema V.1 Código do sistema V.2 45

42 Controlando a evolução Algumas sugestões para se ter uma evolução controlada: Antecipar possíveis evoluções no hw: são causas de mudanças nos requisitos não-funcionais evitar dependências com o hw o máximo possível Identificar e isolar partes dependentes de políticas organizacionais ou governamentais Organizar o documento de requisitos de forma a que este seja fácil de alterar: definir controle de alterações usar meio eletrônico para os documentos 46

43 Gerenciamento de Requisitos Além de controlar a evolução dos requisitos, é parte também desse processo a decisão a respeito dos seguintes pontos: Identificação dos requisitos: relativo à identificar de maneira unívoca os requisitos Gerenciamento de controle de modificações dos requisitos Políticas de rastreabilidade: definem como criar e manter as relações entre requisitos e entre estes e o projeto 47

44 Informação de rastreabilidade Os seguintes tipos de informação devem ser mantidos: Informação sobre a fonte: relação entre os requisitos e os participantes (stakeholders) que propuseram os requisitos e porquê. Informação sobre os requisitos: relação entre os requisitos dentro do DRS. É útil para determinar impacto de modificações dos requisitos. Informação sobre o projeto: relação entre os requisitos e os módulos ou componentes que o implementam. 48

45 Ferramenta de apoio O Gerenciamento de Requisitos é mais fácil com o uso de ferramenta de apoio. Tarefas mínimas que a ferramenta deve apoiar: Armazenamento dos requisitos Controle de modificações Controle da rastreabilidade Ex.IBM-Rational Requisite Pro www-306.ibm.com/software/awdtools/resources/reqpro.html 49

46 Sumário Complete com os principais pontos abordados: 50