Ap i   unidade 3 - levantamento de requisitos
Upcoming SlideShare
Loading in...5
×
 

Ap i unidade 3 - levantamento de requisitos

on

  • 1,745 views

 

Statistics

Views

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

Actions

Likes
0
Downloads
58
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

Ap i   unidade 3 - levantamento de requisitos Ap i unidade 3 - levantamento de requisitos Presentation Transcript

  • 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 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.
  • 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").
  • 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.
  • 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.
  • 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
  • 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...”
  • 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.
  • 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
  • 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.
  • 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.
  • 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".
  • 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
  •  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
  • 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
  • Atividade Considerando o Bloco de Notas – descreva os requisitos funcionais e não- funcionais para a criação do sistema.