1 / 72

Trabalho de Engenharia de Software

Trabalho de Engenharia de Software. Faculdade dos Guararapes Turma: 5NA Tema: Engenharia de Requisitos Alunos: Walter Fonseca Junior Paula Michelly v. Silva Raugil da Costa Junior Evangelisto Nascimento Filho. Elicitação de requisitos e análise. Estudo de viabilidade.

marlin
Download Presentation

Trabalho de Engenharia de Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Trabalho de Engenharia de Software Faculdade dos Guararapes Turma: 5NA Tema: Engenharia de Requisitos Alunos: Walter Fonseca Junior Paula Michelly v. Silva Raugil da Costa Junior Evangelisto Nascimento Filho

  2. Elicitação de requisitos e análise Estudo de viabilidade Especificação de requisitos Validação de requisitos Relatório de viabilidade Requisitos do usuário e do sistema Modelos do sistema Documento de requisitos O Processo da Engenharia de Requisitos

  3. Elicitação de requisitos e análise • Esta atividade divide-se em dois esforços maiores: • Elicitação dos requisitos em si • Técnicas de elicitação • Análise do que foi elicitado • Processo de análise

  4. Que é um requisito? • Tanto pode ser • Uma declaração abstrata de alto nível de um serviço • Como uma restrição do sistema • Quanto uma especificação funcional matemática detalhada

  5. Elicitação de Requisitos • Também denominada de descoberta de requisitos • Envolve pessoal objetivando descobrir o domínio de aplicação, serviços que devem ser fornecidos bem como restrições • Deve envolver usuários finais, gerentes, pessoal envolvido na manutenção, especialistas no domínio, etc. (Stakeholders).

  6. Visão dos Requisitos • Requisitos do Usuário • Declarações em linguagem natural com diagramas de serviços que o sistema deve oferecer e suas restrições operacionais. Escrito para os clientes • Requisitos do Sistema • Documento estruturado com descrições detalhadas sobre os serviços do sistema. Contrato entre cliente e fornecedor

  7. Tipos de Requisitos • Requisitos Funcionais • Requisitos Não-Funcionais • Requisitos de Domínio

  8. Requisitos Funcionais • Descreve funcionalidade e serviços do sistema • Depende do • Tipo do software • Usuários esperados • Tipo do sistema onde o software é usado

  9. Exemplos de R.F. • [RF001] Usuário pode pesquisar todo ou um sub-conjunto do banco de dados • [RF002] Sistema deve oferecer visualizadores apropriados para o usuário ler documentos armazenados • [RF003] A todo pedido deve ser associado um identificador único (PID), o qual o usuário pode copiar para a área de armazenamento permanente da conta

  10. Requisitos Não-Funcionais • Definem propriedades e restrições do sistema (tempo, espaço, etc) • Requisitos de processo também podem especificar o uso de determinadas linguagens de programação, método de desenvolvimento • Requisitos não-funcionais podem ser mais críticos que requisitos funcionais. Não satisfaz, sistema inútil.

  11. Requisitos Não-Funcionais • Devido à sua própria definição, requisitos não-funcionais são esperados mensuráveis • Assim, deve-se associar forma de medida/referência a cada requisito não-funcional elicitado

  12. Classificação de R. N. F. • Requisitos do Produto • Produto deve comportar-se de forma particular (velocidade de execução, confiabilidade, etc.) • Requisitos Organizacionais • Conseqüência de políticas e procedimentos organizacionais (padrões de processo usados, requisitos de implementação, etc.) • Requisitos Externos • Conseqüência de fatores externos ao sistema e ao processo de desenvolvimento (legislação, etc.)

  13. Exemplos de R. N. F. • Requisitos do Produto • [RNF001] Toda consulta ao B.D., baseada em código de barras, deve resultar em até 5 s • Requisitos Organizacionais • [RNF002] Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00 • Requisitos Externos • [RNF003] Informações pessoais do usuário não devem ser vistas pelos operadores do sistema

  14. Requisitos de Domínio • Derivados do domínio da aplicação e descrevem características do sistema e qualidades que refletem o domínio • Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas • Se requisitos de domínio não forem satisfeitos, o sistema pode tornar-se impraticável

  15. Requisitos de Domínio (Problemas) • Entendimento • Requisitos são descritos na linguagem do domínio da aplicação • Não é entendido pelos engenheiros de software que vão desenvolver a aplicação • Implicitude • Especialistas no domínio entendem a área tão bem que não tornam todos os requisitos de domínio explícitos

  16. Requisitos Requisitos Usuário Sistema  Domínio Funcionais Não-funcionais Produto Externo Organização

  17. Técnicas de Elicitação • Entrevistas • Questionários • Casos de Uso • Jogo de Funções • Brainstorming • Workshop de Requisitos

  18. Análise de Requisitos Definição e especificação de requisitos Documento de requisitos 7 8 Validação dos requisitos Entendimento do domínio 6 Atrib. Prioridade Entrada do processo 1 5 4 2 Coleta de requisitos Resolução de conflito 3 Classificação

  19. Entendimento do Domínio • Desenvolver sistemas envolve domínios além de software e hardware • Podemos ter que entender sobre • Contabilidade • Saúde • Supermercados • Etc.

  20. Coleta de Requisitos • Como vimos anteriormente, a coleta de requisitos é feita através de técnicas • Nesta etapa, os requisitos são simplesmente documentados à medida que são coletados • Resulta em documento preliminar (draft)

  21. Classificação dos Requisitos • Esta etapa consiste basicamente em agrupar os diversos requisitos coletados em categorias (clusters) bem-definidos • Por exemplo • Deve ser possível consultar o preço de uma mercadoria • A consulta deve retornar uma resposta em no máximo 5s

  22. Problema da Análise de Requisitos • Stakeholders em geral não sabem o que querem • Stakeholders expressam requisitos em sua terminologia • Stakeholders diferentes podem gerar requisitos conflitantes

  23. Problema da Análise de Requisitos • Fatores políticos e organizacionais podem influenciar os requisitos do sistema • Requisitos mudam durante o processo de análise. Stakeholders novos podem surgir e o ambiente de trabalho mudar

  24. Resolução de Conflitos • É normal que ocorram requisitos conflitantes • Por exemplo • R-23: O sistema deve ... • R-45: O sistema não deve ... • Cliente/usuário deve ser consultado para resolver conflitos (ambigüidades)

  25. Atribuição de Prioridade • Alguns requisitos são mais urgentes que outros • É essencial determinar a prioridade dos requisitos junto ao cliente • Requisitos de maior prioridade são considerados em primeiro lugar

  26. Prioridade • Requisitos podem ser vistos em três classes distintas • Essenciais • Importantes • Desejáveis • Em princípio, sistema deve resolver todos os requisitos de essenciais para desejáveis

  27. Exemplo de Prioridade • [RF001] Consulta X ao B.D. deve retornar dados A, B, C • Prioridade: Essencial • [RNF001] Consulta X ao B.D. deve visualizar dados segundo padrão Y • Prioridade: Importante • [RNF010] Consulta X ao B.D. deve usar cores azuis nos resultados • Prioridade: Desejável

  28. Validação dos Requisitos • Será que realmente entendi o que o cliente deseja? • Devo me certificar de que não houve falha em nossa interação (comunicação) • Há diversas técnicas de validação

  29. Validação de Requisitos • Demonstrar que os requisitos definem o sistema que o cliente realmente deseja • Custos com erros de requisitos são altos • Consertar um erro de requisitos após entrega do sistema pode custar mais de 100 vezes o custo de um erro de implementação

  30. Técnicas de Validação de Requisitos • Revisões de Requisitos • Análise manual sistemática dos requisitos • Prototipação • Uso de modelo executável do sistema para avaliar requisitos • Geração de Casos de Teste • Desenvolver testes específicos para os requisitos para avaliá-los • Análise de Consistência Automática • Avaliar uma especificação dos requisitos

  31. Gerenciamento de Requisitos • Gerenciamento de requisitos é o processo de controlar as mudanças dos requisitos durante • O processo da engenharia de requisitos • E desenvolvimento do sistema

  32. Gerenciamento de Requisitos • Requisitos são inevitavelmente incompletos e inconsistentes • Requisitos novos surgem durante o processo de acordo com mudanças nas necessidades do negócio e um entendimento melhor do sistema é desenvolvido • Diferentes pontos de vista têm diferentes requisitos e esses geralmente são contraditórios

  33. Rastreamento • Responsável por dependências entre requisitos, suas origens e projeto do sistema • Rastreamento de Origem • Associação entre requisitos e stakeholders que propuseram tais requisitos

  34. Rastreamento • Rastreamento de Requisitos • Associação entre requisitos dependentes • Rastreamento de Projeto • Associação dos requisitos com o projeto • Usar hipertexto ou referência cruzada • Ou matriz de rastreamento

  35. 1.Rastrear requisitos do usuário nos do sistema 2.Rastrear requisitos no projeto 3.Rastrear requisitos nos procedimentos de teste 4.Rastrear requisitos do usuário no plano Rastreamento Requisitos Produto (Características) Req A 1 Requisitos Detalhados(Casos de Uso) Req B 3 4 2 Projeto Teste Doc. Usuário Modelos Suítes Teste Plano

  36. Req A antes Req A depois “if return value > $2” “if return value > $5” Req B Req B Req C Req C Rastreamento: Análise de Impacto • Links dos requisitos devem ser marcados como “revisar” • Links “revisar” devem ser analisados

  37. Documento de Requisitos • Fonte: IEEE/ANSI (830-1998) • 1. Introdução • 1.1 Propósito do documento • 1.2 Escopo do sistema • 1.3 Definições, acrônimos e abreviaturas • 1.4 Referências • 1.5 Descrição do resto do documento

  38. Documento de Requisitos • Fonte: IEEE/ANSI (830-1998) • 2. Descrição geral • 2.1 Perspectiva do produto • 2.2 Funções do produto • 2.3 Características dos usuários • 2.4 Restrições gerais • 2.5 Assertivas e dependências

  39. Documento de Requisitos • Fonte: IEEE/ANSI (830-1998) • 3. Requisitos específicos • requisitos funcionais, não-funcionais, GUI com o usuário: • funcionalidade, interfaces externas, desempenho, restrições, atributos do sistema, caract. qualidade, ... • Apêndices • Índice

  40. Diagramas de Casos de Uso

  41. Procedimento computacional/algorítmico atômico Use Case • Seqüência de ações, executada pelo sistema, que gera um resultado • De valor observável • E para ator particular Função

  42. Use Case e Ator • Alguém ou alguma coisa (fora do sistema) que interage com o sistema Emissor/Receptor

  43. Use Case e Ator • A descrição de um use case define o que o sistema faz quando o use case é realizado • A funcionalidade do sistema é definida por um conjunto de use cases, cada um representando um fluxo de eventos específico

  44. Descrição Use Case e Ator Passo 1 Passo 2 … Passo N Emissor Função

  45. Exemplo de Use Case e Ator • Cliente de banco pode usar um caixa automático para • sacar dinheiro, transferir dinheiro ou consultar o saldo da conta • Ator: Cliente • Use cases: Sacar dinheiro, transferir dinheiro e consultar saldo

  46. Exemplo de Use Case e Ator Valor de resultado observável Transferir dinheiro Sacar dinheiro Consultar saldo Cliente

  47. Identificando Use Cases • Em geral, difícil decidir entre um ou vários use cases • Por exemplo, seriam use cases • Inserir cartão em um Caixa Automático? • Entrar com a senha? • Receber o cartão de volta?

  48. Identificando Use Cases • Representar valor observável para ator • Pode-se determinar • De interações (seqüência de ações) com o sistema que resultam valores para atores • Satisfaz um objetivo particular de um ator que o sistema deve prover

  49. Reuso em Use Cases • Comportamento comum a mais de dois use cases (ou forma parte independente) • Pode-se modelar como use case para ser reusado • Há três possibilidades • Inclusão • Extensão • Generalização/Especialização

  50. Inclusão • Vários use cases possuem texto de fluxo de eventos • Comum/idêntico • Sempre usado • Equivalente a fatoração feita em programação através de sub-programas • #include da linguagem C

More Related