1 / 159

Análise ou Especificação de Requisitos

Análise ou Especificação de Requisitos. Silvia Regina Vergilio - UFPR. 1) Objetivos. O escopo do projeto é refinado em detalhe e será produzid a uma especialização de requisitos . Objetivos Fornecer traduzida Projeto, dados

Download Presentation

Análise ou Especificação de Requisitos

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. Análise ou Especificação de Requisitos Silvia Regina Vergilio - UFPR

  2. 1) Objetivos • O escopo do projeto é refinado em detalhe e será produzida uma especialização de requisitos. • Objetivos Fornecer traduzida Projeto, dados informação  procedimentos, representações para arquitetura

  3. 1) Objetivos – Aspecto Fundamental • Comunicação com o Uusário “Eu sei que você acredita ter entendido o que você pensa que eu disse, mas não estou certo se você está ciente de que o que você ouviu não é o que eu queria dizer.” Cliente anônimo.

  4. 1) Objetivos - Documentos Gerados • Especificação de Requisitos de Software • Manual Preliminar do Usuário • Plano de Projeto do Software (revisto).

  5. 2) Extração de Requisitos • Requisito: condição necessária para a obtenção de certo objetivo ou para o preenchimento de certo fim • Requisito de software: requisitos que o produto a ser desenvolvido deve possuir

  6. 2) Extração de Requisitos • Requisitos funcionais: funcionalidade, o que o software deve fazer • Requisitos não funcionais: confiabilidade (disponibilidade, integridade, segurança), acurácia, desempenho, interface HM, portabilidade, etc. • Requisitos de desenvolvimento e manutenção, procedimentos de controle e qualidade

  7. 2) Extração de Requisitos – Engenharia de Requisitos Processo de transformação das idéias que estão na mente do usuário (entradas) em um documento formal (saída).

  8. 2) Extração de Requisitos – Dificuldades • Para conseguir informação pertinente. • Para lidar com a complexidade. (Tornar o problema manipulável; detectar omissões, inconsistências ) • Para acomodar mudanças. (Coordenar, avaliar impacto; corrigir defeitos sem gerar erros)

  9. 2) Extração de Requisitos – Principais Causas • 1. Deficiências na comunicação • 2. Técnicas e ferramentas inadequadas • 3. Desconsideração de alternativas. É necessário aplicar: -princípios fundamentais de análise -métodos sistemáticos de análise

  10. 2) Extração de Requisitos – O Analista • Absorver fatos a partir de fontes conflitantes ou confusas. • Entender os ambientes do usuário/cliente. • Comunicamos bem na forma verbal e escrita. • “ Enxergar a floresta apesar das árvores”

  11. 2) Extração de Requisitos – Engenharia de Requisitos Passos: • Entendimento do domínio de aplicação • Extração e análise de requisitos: classificação e organização • Especificação dos requisitos – modelos • Validação – necessidades do usuário

  12. 2) Extração de Requisitos – Tarefas • 1. Reconhecimento (identificação do problema ) • 2. Avaliação do problema e síntese de soluções gerais + critérios de validação. • 3. Representação dos requisitos => software • 4. Revisão da especificação reexame do Plano de Projeto de Software.

  13. 2) Extração de Requisitos – Quem participa • desenvolvedor • pessoal de apoio e documentação • usuários ou potenciais usuários • outras fontes de informações: pessoas e documentos

  14. 2) Extração de Requisitos – Procedimentos Genéricos • Perguntar – identificar o usuário • Observar e inferir – comportamento do usuário, inferir suas necessidades • Negociar a partir de um conjunto padrão de requisitos • Estudar e identificar problemas • Supor – se o produto é novo comparar com existentes

  15. 3) Técnicas de Extração de Requisitos - Entrevistas • Identificar candidatos • Preparação para entrevista • agendar • preparar questões • Condução da entrevista

  16. 3) Técnicas de Extração de Requisitos - Entrevistas • Condução da entrevista • apresentação e objetivos • esperar respostas incompletas • repetir frases do entrevistado com suas próprias palavras • perguntas do tipo sim/não – dúvidas • não se perder em detalhes • o entrevistado precisa ter o contexto

  17. 3) Técnicas de Extração de Requisitos - Entrevistas • Finalização tempo, resposta à todas as perguntas consolidar informações (5min), agradecimentos • Geração de um documento escrito, planejar próximos passos

  18. 3) Técnicas de Extração de Requisitos - Braimstorming • Técnica para geração de idéias • Reuniões entre desenvolvedores e usuários • Um líder é necessário • Geração e consolidação das idéias • Ausência de crítica e julgamento • Elimina dificuldades de comunicação

  19. 3) Técnicas de Extração de Requisitos - PIECES • Geralmente é aplicada na análise de produtos já existentes, mas pode ser adaptada • Fornece um conjunto de categorias de questões e de problemas para o desenvolvedor extrair os requisitos

  20. 3) Técnicas de Extração de Requisitos - PIECES Seis categorias: P - desempenho I - informação E - economia C - controle E - eficiência S - serviços

  21. 3) Técnicas de Extração de Requisitos - JAD JAD – Joint Application Design • Princípios básicos: • dinâmica de grupo • uso de técnicas visuais • manutenção do processo organizado e racional • utilização de documentação padrão • Etapas: planejamento e projeto

  22. 3) Técnicas de Extração de Requisitos - JAD Seis tipos de participantes • líder • engenheiro de requisitos • executor • representantes do usuário • representantes de produtos de sw • especialista

  23. Sessão Um ou mais Encontros requisitos desenvolvidos e documentados 3) Técnicas de Extração de Requisitos - JAD Adaptação Preparar Organizar Equipe e Material Finalização Converte a informação final em um documento

  24. 3) Técnicas de Extração de Requisitos - Prototipação 1. Determinar se o software é um bom candidato • Áreas de aplicação : interface, . . . • Complexidade : desenvolvimento de muito código inviabiliza a prototipação (particionável) • Característica do cliente e gerente 2. Representação Resumida de Requisitos => particionamento . 3. Um projeto rápido ( arquitetura e dados ).

  25. 3) Técnicas de Extração de Requisitos - Prototipação 4. Protótipo é criado e testado. • Técnicas de quarta geração • Reutilização de Software • Ferramentas de Videoconferência • Especialização formal + ambientes interativos. 5. Teste pelo usuário - sugestões (+importante). 6. Repetição de 4 e 5 até que todos os requisitos sejam formalizados; ou que o protótipo tenha evoluído.

  26. 4) Modelos para Especificação • Representam a realidade • Ajudam a organização e especificação mas não na extração • Utilizam os princípios de abstração e decomposição – lidar com complexidade • Existem diferentes tipos de especificação ao longo do desenvolvimento e em vários níveis.

  27. 4) Modelos para Especificação – Especificação pode ser • Especificação dos requisitos – cliente e desenvolvedor • Especificação de projeto geral – projetista e implementador • Especificação de módulos – programadores que utilizam e implementam os módulos

  28. 4) Modelos para Especificação Princípios - Boa Especificação • Separar funcionalidade de implementação • Deve abranger o sistema do qual o sw é um componente • Deve ser operacional (utilizável) • Tolerante a incompleteza • Consistente

  29. 4) Modelos para Especificação Princípios - Boa Especificação • Realista • Fracamente acoplada e localizada • localizada: para que um único elemento tenha que ser modificado • fracamente acoplada: permitir que adições e remoções sejam feitas facilmente

  30. 4) Modelos para Especificação • Permitem a aplicação dos princípios de ES. • Geralmente cobrem três dimensões do sistema • dados (que dados ele mantém) • funções (o que o sistema faz) • comportamento (como ele se comporta – estados e eventos)

  31. 5) Diagrama de Fluxo de Dados – Modelo de Função

  32. 5) Diagrama de Fluxo de Dados – Modelo de Função O DFD é um modelo que nos permite mostrar como a informação (dados) flui através de um sistema (ou seja, como ela vai sendo transformada ou organizada) • são recebidos • podem ser armazenados • podem fluir de um processo a outro • podem ser transferidos para o ambiente externo

  33. 5) Diagrama de Fluxo de Dados – Modelo de Função ______

  34. 5) Diagrama de Fluxo de Dados (DFD) - Exemplo Agente de Viagem Preparação de Bilhete Horário, dia, destino Dados do vôo Bilhete Sistema de Reserva Informação sem vôos Custo Sistema de Cobrança Cliente Conta Diretórios de vôo Dados contábeis Arquivo de Contabilidade

  35. 5) Diagrama de Fluxo de Dados (DFD) – Como construir

  36. 5) Diagrama de Fluxo de Dados (DFD) – Como construir

  37. 5) Diagrama de Fluxo de Dados (DFD) – Como construir • Particionar as funções em sub-funções: • uma bolha deve ser particionada por vez • rótulos dos fluxos, bolhas e arquivos devem ser significativos • a continuidade da informação deve ser mantida

  38. 5) Diagrama de Fluxo de Dados (DFD) – Como construir A B F x A f4 z B y x z y

  39. 5) Diagrama de Fluxo de Dados (DFD) – Quando parar • O DFD mostra as transformações de todas as entrada em saídas • Os sub-processos não particionados podem ser considerados elementares • Cada bolha está conectada corretamente ao resto da rede • As conexões foram minimizadas

  40. 5) Diagrama de Fluxo de Dados (DFD) O DFD não mostra: • descrição dos fluxos • nem mecanismos de sincoronização • comportamento

  41. 5) Diagrama de Fluxo de Dados – Extensão Tempo Real Fluxo de dados que não é contínuo temp - max  temp - medida. Transforma controle ou eventos. Representa eventos. Armazena itens de controle ou eventos.

  42. 5) Diagrama de Fluxo de Dados – Extensão Tempo Real Monitora ph Processo de Controle ph no nível desejado Inicia Pára Ativa/Desativa Muda ph ph ativa Controle da Válvula de entrada Mantém ph constante Ativa/Desativa

  43. 6) Modelo Entidade Relacionamento (MER) • Dados descrevem coisas do mundo real. • Itens de dados relacionados devem ser agrupados • Ex: nome, endereço, RG são informações do sistema relacionados a uma entidade do mundo real que é o cliente. • Ainda podemos ter relacionamentos entre entidades

  44. 6) Modelo Entidade Relacionamento (MER) DER – Diagrama Entidade Relacionamento

  45. 6) Modelo Entidade Relacionamento (MER) DER – Diagrama Entidade Relacionamento Exemplo

  46. 6) Modelo Entidade Relacionamento (MER) • Existem muitas ferramentas • Fácil de entender • Não diz como se forma o atributo CIC • Não fica claro

  47. 7) Máquina de Estados Finitos (MEF) • Os modelos de comportamento do sistema devem mostrar estados eventos que alteram esses estados • Eventos são condições e ações para se mudar de estado.

  48. 7) Máquina de Estados Finitos (MEF) Uma MEF é dada por: (S, s0, I, ), S – conjunto finito e não vazio de estados S0S – estado inicial I – conjunto finito de entradas (A (ações) e C (condições)) que podem ser nulas :SxI  S - função de transição de estados

  49. 7) Máquina de Estados Finitos Diagrama de Estados (DTE)

  50. 7) Máquina de Estados Finitos Diagrama de Estados (DTE)

More Related