Levantamento de   RequisitosFEAPAAnálise e Projeto de Sistemas 1Prof. Osiel Marlon
Levantamento de Requisitos  REQUISITOS: Objetivos ou restrições estabelecidas por clientes e   usuários do sistema que d...
Engenharia de Requisitos   É um ramo da [Engenharia de Software] que se dedica    ao estudo de soluções para levantamento...
Engenharia de Requisitos   Os requisitos devem ser mensuráveis (a sua cobertura),    testáveis, relacionados com necessid...
Requisitos do usuário, do sistema edo software [Sommerville, 2004]   Requisitos do usuário   – Declarações, em linguagem...
Problemas Comuns   Os envolvidos* não sabem o que eles realmente    querem.   Se expressam num vocabulário diferente dos...
DIFICULDADES DE COMUNICAÇÃO:  “Sei que você acredita que entendeu o que acha que eu  disse, mas não estou certo de que per...
Os projetos de SI fracassam mais freqüentemente por resolveremcerto o problema errado do que propriamente resolver errado ...
Importância do Levantamento de Requisitos: Projeto e codificação perfeitos são de pouco usoquando existem erros nos requi...
Como descrever os requisitos?   A especificação dos requisitos deve ser:    –  Completa – deve descrever tudo o que é   ...
Requisitos funcionais   Descrição das diversas funções que clientes e    usuários querem ou precisam que o software    of...
Requisitos não-funcionais   Propriedades de um software, como manutenibilidade,    usabilidade, desempenho, custos e vári...
TIPOS DE REQUISITOS (revisão)   Requisitos funcionais – dizem o que o sistema deve    fazer. Exs.:            Suporte a ...
   Tipos de requisitos não funcionais       Requisitos de dados       Requisitos ambientais            Ambiente físico...
CUIDADOS NA ANÁLISE DE REQUISITOS.  Se perguntar não sobre COMO deve ser feita alguma    tarefa para construir o sistema,...
Atividade   Considerando o Bloco de Notas –    descreva os requisitos funcionais e não-    funcionais para a criação do s...
Ap i   unidade 3 - levantamento de requisitos
Próximos SlideShares
Carregando em…5
×

Ap i unidade 3 - levantamento de requisitos

2.498 visualizações

Publicada em

Publicada em: Design
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
2.498
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
92
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Ap i unidade 3 - levantamento de requisitos

  1. 1. Levantamento de RequisitosFEAPAAnálise e Projeto de Sistemas 1Prof. Osiel Marlon
  2. 2. Levantamento de Requisitos REQUISITOS: Objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema Condição ou capacidade necessária que o software deve possuir:– para que o usuário possa resolver um problema ou atingir um objetivo– para atender as necessidades ou restrições da organização ou de outros componentes do sistema.
  3. 3. Engenharia de Requisitos É um ramo da [Engenharia de Software] que se dedica ao estudo de soluções para levantamento, desambiguação, análise e especificação de requisitos para projetos de desenvolvimento de software. O levantamento e análise de requisitos engloba aquelas tarefas que procuram determinar as necessidades ou condições para que um determinado produto (de software) Seja construído ou alterado. Será necessário lidar com requisitos conflituosos ou contraditórios e os interesses de cada pessoa com interesse no projeto ("stakeholders").
  4. 4. Engenharia de Requisitos Os requisitos devem ser mensuráveis (a sua cobertura), testáveis, relacionados com necessidades identificadas do negócio ou domínio de aplicação, e definidos a um nível de detalhe suficiente para serem usados nas ulteriores atividades da engenharia de software.
  5. 5. Requisitos do usuário, do sistema edo software [Sommerville, 2004] Requisitos do usuário – Declarações, em linguagem natural e diagramas, sobre os serviços que o sistema oferece e as restrições para a sua operação. Escrito para os clientes. Requisitos do sistema – Estabelecem detalhadamente as funções e restrições do sistema. O documento de requisitos, chamado de especificação funcional, pode servir como um contrato entre cliente e desenvolvedor. Especificação de software – Especificação abstrata e precisa do software, indicando o que ele deve fazer (sem dizer como) que serve de base para o design e implementação. Acrescenta mais detalhes à especificação funcional e é escrito para a equipe de desenvolvimento.
  6. 6. Problemas Comuns Os envolvidos* não sabem o que eles realmente querem. Se expressam num vocabulário diferente dos desenvolvedores. Os envolvidos podem ter requisitos conflitantes. Fatores organizacionais e políticos podem influenciar os requisitos. Novos requisitos podem surgir durante o processo de levantamento/análise/especificação. Novos envolvidos podem vir a participar do process. Podem haver mudanças externas – ambiente ou regras de negócios. *Stakeholders: Envolvidos ou partes interessadas
  7. 7. DIFICULDADES DE COMUNICAÇÃO: “Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer...”
  8. 8. Os projetos de SI fracassam mais freqüentemente por resolveremcerto o problema errado do que propriamente resolver errado oproblema certo. Levantamento de Requisitos Uma compreensão completa dos requisitos do SI é fundamental para um bem-sucedido desenvolvimento.
  9. 9. Importância do Levantamento de Requisitos: Projeto e codificação perfeitos são de pouco usoquando existem erros nos requisitos. O analista formaliza as necessidades do usuário,atuando como ponte entre ele e os implementadores do sistema. Custo da Ambiguidade: Fase em que se encontra Proporção do custo Requisitos 1 Projeto 3-6 Codificação 10 Testes de desenvolvimento 15-40 Testes de aceitação 30-70 Operação 40-1000
  10. 10. Como descrever os requisitos? A especificação dos requisitos deve ser: – Completa – deve descrever tudo o que é necessário  – Consistente – não deve haver conflitos e contradições  – Não-ambígua – não deve levar a interpretações diferentes por desenvolvedores e usuários. • Depende da precisão da linguagem utilizada – Linguagem natural, informal – apropriada para os requisitos do usuário e do sistema.  – Linguagens gráficas, semi-formais – apropriada para os requisitos do sistema e do software.  – Linguagens formais – apropriada para uma especificação formal de software em métodos formais.
  11. 11. Requisitos funcionais Descrição das diversas funções que clientes e usuários querem ou precisam que o software ofereça. • Exemplos: – "o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal". – "o software deve emitir relatórios de compras a cada quinze dias" – "os usuários devem poder obter o número de aprovações,reprovações e trancamentos em todas as disciplinas por um determinado período de tempo.
  12. 12. Requisitos não-funcionais Propriedades de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras São exemplos de requisitos não-funcionais:  "a base de dados deve ser protegida para acesso apenas de usuários autorizados".  "o tempo de resposta do sistema não deve ultrapassar 30 segundos".  "o software deve ser operacionalizado no sistema Linux"  "o tempo de desenvolvimento não deve ultrapassar seis meses".
  13. 13. TIPOS DE REQUISITOS (revisão) Requisitos funcionais – dizem o que o sistema deve fazer. Exs.:  Suporte a formatações  Formatação por parágrafo  Formatação por caractere  Requisitos não-funcionais – indicam as limitações no sistema e em seu desenvolvimento  Ser executado em várias plataformas  Funcionar em um computador com 64 Mb de RAM  Estar pronto em seis meses
  14. 14.  Tipos de requisitos não funcionais  Requisitos de dados  Requisitos ambientais  Ambiente físico  Ambiente social  Ambiente organizacional  Ambiente técnico  Requisitos do usuário  Requisitos de usabilidade
  15. 15. CUIDADOS NA ANÁLISE DE REQUISITOS.  Se perguntar não sobre COMO deve ser feita alguma tarefa para construir o sistema, mas sobre O QUE é exigido  Estar preparado para ambiguidades:  “sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer…”  Etapasque antes eram construídas posteriormente devem ser pensadas em conjunto com a análise:  Construção do manual do usuário  Plano dos testes de usabilidade
  16. 16. Atividade Considerando o Bloco de Notas – descreva os requisitos funcionais e não- funcionais para a criação do sistema.

×