• Like
  • Save
Análise de Requisitos
Upcoming SlideShare
Loading in...5
×
 

Análise de Requisitos

on

  • 1,096 views

 

Statistics

Views

Total Views
1,096
Views on SlideShare
1,096
Embed Views
0

Actions

Likes
1
Downloads
39
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Análise de Requisitos Análise de Requisitos Presentation Transcript

    • Análise de Requisitos Profa. Renata de Freitas GóisParte deste material retirado de notas de aula da Profa. Renata Fortin – ICMC –USP 1
    • Fases dos Modelos de ATIVIDADES DE Processo de APOIO • Controle eSoftware Acompanhamento do Projeto de Análise de Sistema Software DEFINIÇÃO Planejamento • Revisões Técnicas Análise de Requisitos Formais • Garantia de Qualidade de Software Projeto • Gerenciamento de CONSTRUÇÃO Codificação Configuração de Teste Software • Preparação e Produção de Documentos Entendimento • Gerenciamento de Modificação ReusabilidadeMANUTENÇÃO Revalidação • Medidas • Gerenciamento de Riscos 2
    • Requisitos:s Definição: – (1) Uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo. – (2) Uma condição ou uma capacidade que deve ser alcançada ou estar presente em um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto.s O documento que descreve todos os requisitos de um software, usualmente num formato ou linguagem inteligível pelo cliente, é a Descrição de Requisitos.s O documento que especifica estes requisitos, utilizando um formato mais apropriado para a implementação, é a Especificação de Requisitos.s Geralmente, ambos os documentos (descrição e especificação de requisitos) descrevem o que o software proposto deve fazer sem se preocupar em como deve ser feito. 3
    • Requisitos: Funcionais x Não-Funcionaiss Requisitos Funcionais: – Descrevem uma interação entre o sistema e seu meio ambiente. – Funcionalidades do sistema conforme percebidas pelos atores externos (usuários).s Requisitos Não-Funcionais: – Ou restrições, descrevem uma restrição para o sistema que limita as possíveis escolhas de solução para o problema. – Normalmente conhecidos como Requisitos de Qualidade de uma aplicação. – Devem ser detalhados em uma seção da documentação do Software. 4
    • Requisitos: Importância e Qualidades Uma Especificação de Requisitos é importante porque: – Estabelece uma base de concordância entre o cliente e o fornecedor sobre o que o software fará. – Mapeia o problema. – Uma especificação de requisitos de alta qualidade é um pré- requisito para um software de alta qualidade.s Qualidade: –Critérios de qualidade para uma especificação de requisitos: »Corretude – reflete fielmente a realidade e Evite focar na necessidades dos usuários e cliente; corretude »Consistência – informações em diferentes locais como o único não são contraditórias; critério de »Clareza – sem ambigüidades, possibilita sua qualidade!!! verificação; »Completude – não há nenhuma informação necessária ou importante para os usuários e cliente que esteja omitida; »Coesão – descreve exatamente o que é necessário para o cliente, sem acrescentar informações desnecessárias. 5
    • s Uma compreensão completa dos Requisitos do Software é fundamental para obter um software e um processo de desenvolvimento com alta qualidades Não importa quão bem projetado ou codificado está um programa, se ele for mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor 6
    • Definição: Requisitos eEspecificaçãos Glossário de Engenharia de Software (IEEE) e do Aurélios Requisito (IEEE) – Uma condição ou capacidade necessitada por um usuário 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 7
    • ANÁLISE DE REQUISITOS Representação de Especificação 1- O formato de representação e o conteúdo devem ser pertinentes ao problema 2- As informações contidas na especificaçãoDIRETRIZES devem ser apresentadas em nível 3- Diagramas e outras formas notacionais devem ser restritos quanto ao número e consistentes em relação ao uso 4- As representações devem ser revisáveis 8
    • ANÁLISE DE REQUISITOS : Formato daEspecificação de Requisitos de Software s I. INTRODUÇÃO – Declara as metas e os objetivos do software, descrevendo-os no contexto do sistema baseado em computador s II. DESCRIÇÃO DA INFORMAÇÃO – Apresenta uma descrição detalhada do problema que o software deve resolver 9
    • ANÁLISE DE REQUISITOS : Formato daEspecificação de Requisitos de Software s III. DESCRIÇÃO FUNCIONAL – Engloga uma descrição de cada função exigida para resolver o problema s IV. DESCRIÇÃO COMPORTAMENTAL – Examina a operação do software como uma sequência de eventos 10
    • ANÁLISE DE REQUISITOS : Formato daEspecificação de Requisitos de Software s V. CRITÉRIOS DE VALIDAÇÃO – Designam classes de testes que devem ser efetuadas para validar a função, o desempenho e as restrições. Seção muito importante, porém negligenciada. s VI. BIBLIOGRAFIA – Contém referências a todos os documentos que se relacionam com o software. 11
    • Dilema do Engenheiro deSoftwareDeclaração de um cliente anônimo: “Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de que percebe que aquilo queouviu não é o que eu pretendia dizer ... ” 12
    • ATIVIDADES de ANÁLISE:1 - reconhecimento do problema2 - avaliação do problema esíntese da solução (Modelagem)3-especificação dos requisitos do softwa4 - revisão 13
    • Atividade 1 Reconhecimento do ProblemaA meta é o reconhecimento dos elementos básicos do problema, conforme percebidos pelo cliente. Administrador do projeto analista desenvolvedores clientes Plano de projeto Espec. requisitos protótipo de software de software 14
    • Atividade 2Avaliação do Problema e Sínteseda Soluçãos Avaliar os problemas na situação atuals Principal Foco para o novo sistema: O QUE e não COMO: - qual o fluxo e o conteúdo de informação - quais as funções do sistema - quais dados que o sistema produz e consome - qual o comportamento do sistema - qual as características de interface - quais são as restrições do projeto 15
    • Atividade 3Especificação de Requisitos Definição de Especificação: descrição rigorosa e minuciosa das características que um material, uma obra ou um serviço deverão apresentar– descrição do fluxo e estrutura da informação– refinamento detalhado de todas as funções do software– estabelecimento das características de interface– identificação das restrições de projeto– especificação dos critérios de validação 16
    • Atividade 4 RevisõesDevem ser efetuadas revisões técnicas e revisões no Plano de Projeto de Software  as revisões são conduzidas pelo Cliente e pelo Desenvolvedor  a base para a revisão são os documentos produzidos na Especificação dos RequisitosO Plano de Projeto do Software deve ser revisto devido ao conhecimento adquirido durante a análise. 17
    • •Engenheiro de Sistemas•Projetista de sistemas-chefe•Programador/Analista
    • Características do Analista de Sistemas1- Capacidade para compreender conceitos abstratos, reorganizar esses conceitos em divisões lógicas e sintetizar "soluções" baseado em cada divisão.2- Capacidade de absorver fatos pertinentes a partir de fontes conflitantes ou confusas.4- Capacidade de se comunicar bem de forma escrita e verbal.5- Capacidade de "ver a floresta ao invés das árvores”  (não se perder nos detalhes) 19
    • Papel do Analista de Sistemas1- Coordenar cada uma das atividades da Análise de Requisitos de Software - comunicação com cliente - convoca pessoal de desenvolvimento durante avaliação e síntese2- Responsável pelo desenvolvimento do documento de Especificação de Requisitos do Software e participa de todas as revisões 20
    • Áreas Problemas1. Aquisição da Informação2. Tamanho do Sistema T(complexidade dos problemas)3. Alterações (mudanças que ocorrem durante e após a análise) 21
    • Áreas Problemas1. Aquisição da informação – que informação deve ser coletada e como ela deve ser representada? – quem fornece as informações? – que técnicas e ferramentas estão disponíveis para facilitar a coleta de informações? 22
    • Áreas Problemas2. Tamanho do sistema – como eliminar inconsistências na especificação de grandes sistemas? – é possível detectar omissões? – pode um grande sistema ser efetivamente particionado para que se torne intelectualmente administrável? 23
    • Áreas Problemas3. Alterações – como as alterações efetuadas em outros elementos do software são coordenadas com os requisitos do software? – como se determina o impacto de uma alteração em outras partes do software aparentemente não relacionadas? – como se corrige erros na especificação para que não se gere efeitos colaterias? 24
    • Causas dos Problemas² comunicação ineficiente² técnicas e ferramentas inadequadas (especificação inadequada e imprecisa)² tendências de se eliminar a tarefa de Especificação dos Requisitos² falhas ao considerar alternativas antes que o software seja especificado 25
    • Abordagem de Engenharia deSoftwares Aplicação de técnicas de comunicação sólidass Princípios de análise fundamentaiss Métodos de análise sistemáticos reduzirão o impacto dos problemas 26
    • Responde ao pedido de ajuda do clienteProblema cuja solução é baseada 27em computador
    • Princípios de uma boa especificação (Balzer e Goldman)1. Separe funcionalidade de implementação2. É necessária uma linguagem de especificação de sistemas orientada ao processo3. A especificação deve abranger o sistema do qual o software é um componente4. Uma especificação deve abranger o ambiente no qual o sistema opera5. Uma especificação de sistema deve ser um modelo cognitivo6. Uma especificação deve ser operacional7. A especificação do sistema deve ser tolerante com a não completitude e ser expansível8. Uma especificação deve ser localizada e fracamente acoplada. 28
    • A Especificação pode seracompanhada de um PROTÓTIPOexecutável (ou em papel) e/ou um MANUAL PRELIMINAR DE USUÁRIO. 29
    • Análise de Requisitos Conclusãos Logo que a Revisão for concluída, a Especificação de Requisitos de Software é "assinada" pelo cliente e pelo desenvolvedors A especificação torna-se um "contrato" de desenvolvimento de software.s Mudanças solicitadas depois que a Espec. for concluída serão consideradas, porém cada mudança posterior pode aumentar o custo e/ou alongar o prazo de entregas Mesmo com os melhores procedimentos de revisão em andamento, uma série de problemas de especificação ainda persiste 30