Levantamento de
   Requisitos
FEAPA
Análise e Projeto de Sistemas 1
Prof. 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 e
do 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 resolverem
certo o problema errado do que propriamente resolver errado o
problema 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 uso
quando 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.

Ap i unidade 3 - levantamento de requisitos

  • 1.
    Levantamento de Requisitos FEAPA Análise e Projeto de Sistemas 1 Prof. Osiel Marlon
  • 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.
    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.
    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.
    Requisitos do usuário,do sistema e do 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.
    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.
    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.
    Os projetos deSI fracassam mais freqüentemente por resolverem certo o problema errado do que propriamente resolver errado o problema certo. Levantamento de Requisitos Uma compreensão completa dos requisitos do SI é fundamental para um bem-sucedido desenvolvimento.
  • 9.
    Importância do Levantamentode Requisitos:  Projeto e codificação perfeitos são de pouco uso quando 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.
    Como descrever osrequisitos?  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.
    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.
    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".
  • 14.
    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
  • 15.
    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
  • 16.
    CUIDADOS NA ANÁLISEDE 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
  • 17.
    Atividade  Considerando o Bloco de Notas – descreva os requisitos funcionais e não- funcionais para a criação do sistema.