A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

1 A importância da Análise de Requisitos Profa.MS. Sandra R. Costa Fantinato 19 de agosto de 2010.

Apresentações semelhantes


Apresentação em tema: "1 A importância da Análise de Requisitos Profa.MS. Sandra R. Costa Fantinato 19 de agosto de 2010."— Transcrição da apresentação:

1 1 A importância da Análise de Requisitos Profa.MS. Sandra R. Costa Fantinato 19 de agosto de 2010.

2 Fatores de sucesso no desenvolvimento de software: Envolvimento do usuário no projeto Suporte da alta direção Definição clara dos requisitos 2

3 3

4 4 Princípios da Análise de Sistemas: O domínio do problema deve ser compreendido. O domínio da informação deve ser bem definido. O escopo do sistema deve ser definido levando-se em conta possíveis restrições. Usuário Analista Regras do negócio

5 Importância da análise de sistemas Estudo do problema e de suas possibilidades de solução Interação com o usuário final para adequação do sistema as suas necessidades Especificação da solução mais indicada Avaliação prévia do custo-benefício Análise da viabilidade de implantação Flexibilidade para desvios de rota sem grandes prejuízos Documentação de todo o processo 5

6 Pessoas envolvidas na Análise Usuários: pessoas para quem o sistema está sendo construído –operadores –supervisores –executivos Analistas de Sistemas: pessoas responsáveis pela especificação do sistema Programadores: pessoas responsáveis pela implementação, em uma linguagem de programação específica, da especificação gerada pelos Analistas de Sistemas Administradores de Dados: Responsáveis pela gestão dos dados da aplicação 6

7 O Analista de Sistemas Participa do processo de Desenvolvimento de Software Interage diretamente com o usuário, levantando as suas necessidades Especifica O QUE DEVE ser feito Deve estudar e entender o negócio e a missão da empresa Capacidade de absorver fatos pertinentes a partir de fontes conflitantes ou confusas Capacidade de se comunicar bem de forma escrita e verbal Capacidade de "ver a floresta ao invés das árvores É o responsável pelo desenvolvimento de uma Especificação de Requisitos de Software e participa de todas as revisões Estuda a viabilidade do sistema –Técnica, Financeira, Prazos (Viabilidade Técnica, Viabilidade Econômica, Definição de Cronograma, Alternativas) 7

8 Perfil do analista 8

9 Conhecimentos Técnicos do Analista Metodologias de Análise Modelagem de Dados Planejamento e Gerência de Projetos Engenharia de Software Administração Tecnologias Emergentes 9

10 10 Princípios da Análise de Sistemas Modelos que descrevam a informação, função e comportamento do sistema devem ser produzidos. Os modelos devem ser divididos em partições. Controlar Vendas Registrar produtos Registrar cliente Atualizar estoque Emitir Nota Fiscal Registrar venda

11 11 Princípios da Análise de Sistemas Objetivo dos modelos: ajudam o analista a compreender o sistema; facilitam a determinação da inteireza e consistência da especificação; base para o projeto. O processo de análise deve mover-se da informação essencial para os detalhes de implementação (projeto). Métodos de análise => métodos de modelagem.

12 12 Métodos de Análise de Requisitos: A Análise Estruturada Principais Desenvolvedores: Tom de Marco 1979, Chris Gane 1982; Princípios: problemas devem ser particionados; gráficos devem ser utilizados; requisitos lógicos (essenciais) devem ser diferenciados dos físicos (implementação); ferramentas para descrever a lógica e os procedimentos. Base: modelos de fluxo de informação; representar dados e os processos que os transformam.

13 13 A Análise Estruturada: Notação Notação básica utilizada no DFD: Entidade Externa Envia ou recebe informações do sistema. Fora dos limites do sistema Processo Transformador de informações interno aos limites do sistema. Fluxo de dado Depósito de Dados Armazenamento de dados no sistema.

14 14 A Análise Estruturada Ferramentas de modelagem: DFD - Diagrama de Fluxo de Dados: representa fluxo de informação e transformações. Ferramentas de apoio: dicionário de dados e descrição de processos (português estruturado, árvores ou tabela de decisão). Matricular Aluno dados_matrícula Matrículas comprovante Cursos

15 15 Paciente Diagrama de Contexto marcação- consulta dados_pessoais Paciente nota_ consultas info_pagto Médico dados_médico escala valor_consulta ficha_paciente Sistema de Controle de Atendimento Médico

16 16 Controlar Consultas 1 Paciente Figura 0 - Controle de Atendimento Médico marcação- consulta Consultas Pacientes nome dados_pessoais Gerenciar Médicos 3 Controlar Pagamentos 2 Paciente nota_ consultas info_pagto Consultas total_ paciente pagto Médico dados_médico escala valor_consulta ficha_paciente valor Médicos especialidade horário_semana disponibilidade horários

17 17 A Análise Estruturada: Diagrama de Contexto Representação Inicial: a função global do sistema é representada como uma única transformação de informação. Sistema de Controle Escolar A B C Diagrama de Contexto - Figura de Nível 0

18 18 A Análise Estruturada A partir do Diagrama de Contexto, novas figuras são produzidas, representando explosões (refinamentos) das figuras de nível anterior. O DFD é organizado por níveis. Os processos mais primitivos, do último nível da explosão, devem ser descritos. É gerada então a especificação de processos.

19 19 A Análise Estruturada: Especificação de Processos A especificação de processos representa o algoritmo de transformação do processos. Deve ser gerada para os processos do último nível de refinamento do DFD. Primeiro passo para o projeto: especificação de programas. Podem ser usadas ferramentas textuais (texto narrativo, português estruturado) ou gráficas (tabelas de decisão, árvores de decisão).

20 20 A Análise Estruturada: Dicionário de Dados Análise do domínio da informação. Cada fluxo de dados representa um ou mais itens de informação. Cada depósito de dados é uma coleção de de itens de dados individuais. Descreve: fluxos de dados, depósitos de dados, estruturas de dados e elementos de dados.

21 21 Métodos de Análise: A Análise Essencial Principais Desenvolvedores: McMenamim e Palmer, Princípios: especificação de requisitos funcionais através da essência do sistema; introduz o conceito de eventos e atividades essenciais. Ferramentas: diagramas de eventos (declaração de eventos + DFD), diagrama de contexto, DFD expandido, memória essencial (DER).

22 22 A Análise Essencial Eventos: Aluno solicita matrícula. Matricular Aluno dados_matrícula Matrículas comprovante Cursos

23 23 A Análise Essencial Eventos: É hora de gerar a Folha de Pagamentos. Emitir Folha de Pagamento Recursos Humanos Descontos folha_pagtoFuncionários Abonos

24 24 A Análise Essencial Memória Essencial do Sistema: DER - Diagrama de Entidades e Relacionamentos Aluno cursa Disciplina Curso (1,1) (1,N) envolve (1,N) (0,N)

25 25 Métodos de Análise: A Análise Orientada a Objetos Principais Desenvolvedores: Coad e Yourdon, 1990; Rumbaugh, Booch e Jacobson - UML Princípios: utilização do mesmo formalismo, conceito de objeto e classe, ao longo de todo o ciclo de vida de desenvolvimento; unifica dados e funções em uma única entidade de modelagem.

26 26 A Análise Orientada a Objetos A Classe: ALUNO matrícula nome endereço matricular(); alterarEndereço(); trancarMatrícula(); Atributos Operações/ Métodos

27 27 A Análise Orientada a Objetos Principal Linguagem: UML - The Unified Modeling Language Principais ferramentas de modelagem: Diagramas de Classe, Diagramas de Casos de Uso e Diagramas de Interação (operações).

28 28 Diagrama de Classe Mais importante diagrama da UML. Reflete a Estrutura Estática do sistema. Elemento principal: a Classe. nome: string dtNascimento:date Pessoa mostrarIdade() verificarPrimNome() Empresa CGC: string endereço: string obterCGC() atualizarEndereço() 1..* *

29 29 Diagrama de Use Case Mostra atores externos ao sistema e funcionalidades requeridas pelos mesmos representadas através de casos de uso. Solicita Extrato Consulta Saldo Caixa Eletrônico Cliente

30 30 Ferramentas CASE CASE - Computer Aided Software Engineering (Engenharia de Software auxiliada por computador) Ferramentas de engenharia de software voltadas para apoiar os desenvolvedores (analistas/projetistas) nas atividades de modelagem e construção. Automatiza as atividades manuais e aumenta a qualidade da informação.

31 31 Ferramentas CASE Exemplos de funções de uma ferramenta CASE (System Architect - versão 3.0): Diagrama, modela, especifica informações e dados dos sistemas; Verifica a exatidão e integridade dos diagramas; Automatiza e padroniza a documentação dos sistemas.

32 Requisito Algo que se deseja ou precisa Uma característica que o usuário necessita para resolver um problema ou atingir um objetivo Uma característica que o sistema deve possuir ou atingir para satisfazer um contrato padrão ou outro documento formal Sua especificação é feita através de um documento contendo uma descrição completa do que o sistema deverá fazer sem conter informações de como será feito. Análise do negócio O QUE X COMO 32

33 Análise de Requisitos 33 Processo de descobrir, analisar, documentar e verificar serviços requeridos para um sistema e suas restrições operacionais.

34 Tipos de requisitos Requisitos de usuário –Declarações em linguagem natural mais diagramas de serviços que o sistema fornece e suas restrições operacionais. Escritos para os usuários. Requisitos de sistema –Um documento estruturado estabelecendo descrições detalhadas das funções, serviços e restrições operacionais do sistema. Define o que deve ser implementado e assim, pode ser parte de um contrato entre o cliente e o desenvolvedor. 34

35 Requisitos funcionais e não funcionais Requisitos funcionais –Declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. Requisitos não funcionais –Restrições sobre serviços ou funções oferecidos pelo sistema tais como restrições de timing, restrições sobre o processo de desenvolvimento, padrões, etc. 35

36 Requisitos funcionais Descrevem a funcionalidade ou serviços de sistema. Dependem do tipo de software, dos usuários esperados e o tipo de sistema onde o software é usado. Requisitos funcionais de usuário podem ser declarações de alto nível do que o sistema deve fazer mas os requisitos funcionais de sistema devem descrever os serviços de sistema em detalhe. 36

37 Exemplos de requisitos funcionais O usuário deve ser capaz de pesquisar em todo o conjunto inicial de banco de dados ou selecionar um subconjunto a partir dele. O sistema deve fornecer telas apropriadas para o usuário ler os documentos no repositório de documentos. Para todo pedido deve ser alocado um identificador único (ORDER_ID) no qual o usuário deve ser capaz de copiar para a área de armazenamento permanente da sua conta. 37

38 Mais Exemplos de Requisitos Funcionais O sistema deve ser capaz de armazenar todas as informações sobre seus clientes(RG, CPF, Nome, data de nascimento e endereço) no banco de dados. O sistema deverá atribuir um identificador único (código) para cada pedido de produtos. O sistema deverá cancelar automaticamente um orçamento que tenha sido feito há mais de 30 dias e não tenha sido transformado em venda. 38

39 Requisitos não funcionais Estes definem propriedades e restrições de sistema, por exemplo, confiabilidade, tempo de resposta e requisitos de armazenamento. Restrições são capacidade de dispositivos de E/S, representações de sistema, etc. Podem ainda estar relacionados a portabilidade, de SO, de BD, etc. Requisitos de processo podem também ser especificados impondo uma ferramenta CASE particular, linguagem de programação ou método de desenvolvimento. Requisitos não funcionais podem ser mais críticos do que os requisitos funcionais. Se estes não forem atendidos, o sistema é inútil. 39

40 Exemplos de requisitos não funcionais 40


Carregar ppt "1 A importância da Análise de Requisitos Profa.MS. Sandra R. Costa Fantinato 19 de agosto de 2010."

Apresentações semelhantes


Anúncios Google