Ap i unidade 3 - levantamento de requisitos

2,114 views
1,840 views

Published on

Published in: Design
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,114
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
85
Comments
0
Likes
0
Embeds 0
No embeds

No notes for 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.

×