SlideShare uma empresa Scribd logo
Engenharia de Software

    Aula 3 – Engenharia de Requisitos
              Profa. Dra. Judith Pavón
    Universidade Salvador – UNIFACS
                                  2012
Objetivo da aula
O objetivo desta aula é apresentar os
conceitos básicos de Engenharia de
Requisitos.




                                        2
Conteúdo
1.   Introdução

2.   Importância dos requisitos

3.   Processo de Engenharia de Requisitos

4.   Classificação dos requisitos



                                            3
Introdução

   Um processo de engenharia de
    requisitos eficiente    evita     uma
    compreensão incorreta dos requisitos.




                                            4
Introdução
   Requisitos são importantes para projetos de
    desenvolvimento de software, pois são a base
    para :
    ­   Análise de contratos;
    ­   Elaboração / análise de propostas;
    ­   Planejamento;
    ­   Estimativas;
    ­   Análise de riscos;
    ­   Gestão e controle;
    ­   Modelagem do sistema;
    ­   Desenvolvimento;
    ­   Testes.
                                              5
Introdução

   Problemas com requisitos levam a:
    ­    Clientes insatisfeitos;
    ­    Altos custos;
    ­    Perda de reputação;
    ­    Compreensão do “problema incorreto”;
    ­       Efeito cascata nas demais fases     de
        desenvolvimento de software.




                                                     6
Importância dos requisitos

   CMMI-SE/SW              (Capability       Maturity       Model
    Integration)
    ­   Modelo de melhoria de processo de desenvolvimento de
        software.
    ­   Modelo seguindo 5 níveis de maturidade.
    ­   Capacidade de um processo de software:
         
             faixa de resultados esperados dentro de uma margem de
             probabilidade.

    ­   Maturidade do processo:
         
             reflete em que medida ele pode ser definido, gerenciado,
             medido, controlado e executado de maneira eficaz.
                                                                  7
Importância dos requisitos
   CMMI-SE/SW (Capability Maturity Model
    Integration)
                                                                                           5.
                                                                                    OTIMIZADO


                                                              4. GERENCIADO
                                                                                       5. Processo focado na
                                                            QUANTITATIVAMENTE          melhoria contínua


                                                 3.
                                              DEFINIDO              4. Processo medido e
                                                                    controlado
                               2.
                           GERENCIADO          3. Processo orientado à
                                               organização e proativo

              1.
                            2. Processo orientado a
           INICIAL
                            projetos e geralmente
                            reativo

    1. Processo
    imprevisível, pouco
    controlado e reativo




                                                                                                           8
Importância dos requisitos
        Níveis de Maturidade - CMMI-SE/SW




                                            9
Importância dos requisitos
 Processo de Engenharia de Requisitos (PER) no modelo CMMI

                                              nível 3. definido
                                               PER baseado
                                            em melhores práticas;
                                             melhoria contínua


                       nível 2. repetível
                       PER obedecendo
                           a normas


    nível 1. inicial
     PER adhoc




                                                                    10
Importância dos requisitos

                 Ciclo de Vida de Software (SWEBOK, 2004)

Levantamento
                      Projeto de    Implementação        Teste de            Manutenção de
 e Definição
                       Software       de Software        Software              Software
de Requisitos

 Elicitação de
 Requisitos

 Análise de
 Requisitos

 Especificação
 de Requisitos                                                                         ri   co
                                                                                e   né
                                                                         el o G
 Validação                                                           d
 de Requisitos                                                  Mo

 Gerenciamento
 de Requisitos



                     SWEBOK – Guide to the Software Engineering Body of Knowledge (IEEE)
                                                                                                 11
Importância dos requisitos
   56% dos erros em um sistema associam-se a problemas na
    fase de identificação dos requisitos (Fonte: “Extra time
    saves money” Warren Kuffel).

   Erros mais comuns: uso de fatos incorretos, omissão,
    inconsistência e ambigüidade.
                        Distribuição de Defeitos




                 56%
                                                         Requisitos
                                                   27%
                                                         Projeto

                         7%       10%                    Outros
                                                         Codificação
Importância dos requisitos
Clássicas falhas de sistemas por problemas de
  requisitos

   Aeroporto de Denver: mais de US$ 50 milhões perdidos em
    função de erros no sistema de controle de bagagens
    (Flower).

   Sistema de Ambulâncias de Londres: o sistema foi
    desativado um dia após o início de suas operações com
    causa de seus erros e falhas de segurança, confiabilidade
    e usabilidade (Flower).

   Foguete do Satélite Ariane 5: a trajetória do foguete era
    controlada por um sistema de computador, que falhou junto
    com seu sistema backup. Comandos de diagnóstico foram
    enviados para os motores, fazendo com que o foguete
    mudasse para uma trajetória instável (Nuseibeh).


                                                                13
Conceitos Básicos
Requisito

   Uma especificação do que deve ser implementado.
    Descrição de como o sistema deve se comportar, ou uma
    propriedade ou atributo do sistema. Pode ser uma
    restrição no processo de desenvolvimento do sistema.
    (Sommerville & Sawyer)

   Uma condição ou capacidade que o sistema deve
    contemplar (Pressman)

   Uma necessidade do usuário ou característica, função ou
    atributo de um sistema que pode ser percebido de uma
    posição externa ao sistema. (Davis)



                                                              14
Conceitos Básicos

Engenharia de Requisitos

   A Engenharia de Requisitos é um processo que envolve
    todas as atividades necessárias para criar e manter um
    Documento       de   Especificação    de     Requisitos
    (Sommerville).

   A Engenharia de Requisitos é uma sub-área da
    Engenharia de Software que estuda o processo de
    definição de requisitos que o software deverá atender
    (Sampaio).

   A Engenharia de Requisitos tem como objetivo prover ao
    profissional de métodos, técnicas e ferramentas que
    auxiliem o processo de compreensão e registro dos
    requisitos que o sistema deve atender (Sampaio).
                                                              15
Processo de Engenharia de Requisitos
Processo
 É um conjunto organizado de atividades que transforma entradas em

  saídas (Pressman).

Atividades do Processo                de    Engenharia        de    Requisitos
   (Sommerville &
Kontoya)
 Elicitação de Requisitos
    ­   Os requisitos são descobertos por meio das consultas com as partes
        interessadas.
   Análise e Negociação de Requisitos
    ­   Requisitos são analisados e conflitos são resolvidos por meio da
        negociação.
   Documentação de Requisitos
    ­   Um documento de requisitos é produzido.
   Validação de Requisitos
    ­   É checada a consistência, completude e outros atributos de qualidade do
        documento de requisitos.
   Gerenciamento de Requisitos
    ­   Consiste no controle de mudanças dos requisitos dentro do ciclo de vida do
                                                                               16
        software.
Processo de Engenharia de Requisitos


                          Análise




   Elicitação          Documentaç                 Validação
                           ão




                Gerenciamento de Requisitos



                                         Fonte: Sommerville & Sawyer, 2000
                                                                     17
Processo de Engenharia de Requisitos


    Elicitar Requisitos                            Controlar Mudanças



   Analisar Requisitos                             Rastreabilidade



                                  Requisitos
Documentar Requisitos                               Gerenciar Configuração



                                                    Gerenciar Qualidade
    Validar Requisitos
                                                    de Requisitos



  Desenvolvimento de Requisitos                Gerenciamento de Requisitos




                                                                      18
Processo de Engenharia de Requisitos
 sistemas      Processo de Engenharia de Requisitos
 existentes             (Entradas e Saídas)

necessidades
    dos
  usuários
   normas       processo de                  requisitos
     da        engenharia de                 aprovados
organização      requisitos
                                               Documento
                                                   de
regulamentos                                   Requisitos
informação
     do                          Fonte: Kotonya & Sommerville, 1998
  domínio
                                                              19
Processo de Engenharia de Requisitos


    Características Principais da Engenharia de Requisitos
       O processo de engenharia de requisitos é estruturado como um
        conjunto de atividades que leva a produção do documento de
        requisitos.
       As entradas do processo de engenharia de requisitos são as
        informações existentes dos sistemas, necessidade das pessoas
        interessadas     (stakeholders),     padrões    organizacionais,
        regulamentações e informações do domínio.
       Os processos de engenharia de requisitos variam radicalmente entre
        empresas. A maioria dos processos incluem a elicitação de requisitos,
        análise e negociação, a documentação e a validação dos requisitos.
       A atividade de gerenciamento de requisitos é uma atividade
        complementar que auxilia no controle das mudanças dos requisitos.



                                                                        20
Stakeholders


  Atores no Processo de Engenharia de Requisitos:
    Stakeholders

     Quem são os “interessados no sistema”?
      São as pessoas que serão afetadas pelo sistema e que
      têm uma influência direta ou indireta na elaboração dos
      requisitos:
          ­   usuários finais, gestores e outros envolvidos nos processos
              organizacionais que o sistema influencia, responsáveis pelo
              desenvolvimento e manutenção do sistema, clientes da
              organização que possam vir a usar o sistema, organismos de
              regulação e certificação, etc.




                                                                    21
Stakeholders


  Alguns exemplos de partes interessadas
    (stakeholders):

     Gestor do sistema;
     Usuários finais;
     Gestores de sistemas impactados;
     Funcionários;
     Clientes do banco;
     Especialistas no negócio;
     Órgãos reguladores;
     Parceiros.


                                           22
Conceito de
Rastreabilidade
   Técnica usada para prover relacionamento entre requisitos, projeto e
    implementação final do sistema (Edwards).
   É uma técnica que permite que os requisitos sejam claramente
    ligados às suas fontes e aos artefatos criados durante o ciclo
    de vida de desenvolvimento do sistema (Ramesh).
   Habilidade de permitir que mudanças em qualquer artefato – requisitos,
    especificação e implementação– sejam rastreadas através do sistema
    (Greenspan).

                                                        Rastreabilidad
          Domínio do
          Problema                   Necessidades             e


                                 Macro-Requisitos

           Domínio da                Requisitos
           Solução

                              Projeto e Documentações



                                                                         23
Conceito de
  Rastreabilidade
    Uma especificação de requisitos é rastreável se permite a fácil
     determinação dos antecedentes e conseqüências de todos os
     requisitos.
    Rastreabilidade para Trás:
      ­   Deve ser possível localizar a origem de cada requisito.
      ­   Deve-se saber por que existe cada requisito, e quem ou o que o originou.
 Isso é importante para que se possa avaliar o impacto da mudança daquele
                requisito, e dirimir dúvidas de interpretação.


    Rastreabilidade para Frente:
      ­   Deve ser possível localizar quais os resultados do desenvolvimento que serão afetados por
          cada requisito.
 Isso é importante para garantir que os itens de análise, modelagem, código e
teste abranjam todos os requisitos, e para localizar os itens que serão afetados
                      por uma mudança nos requisitos.

                                                                                                 24
Conceito de
Rastreabilidade
   Os usuários comunicaram uma série de
    mudanças nas regras de negócio do
    Sistema de Contabilidade. Quanto você
    acha que vamos levar para alterar o
    sistema?
   Cara, vai dar um trabalhão. A lógica do
    cálculo dos impostos está espalhado por
    todo o sistema. Vamos gastar um tempão
    só para localizar todos os lugares que
    teremos de mexer.


                                              25
Conceito de
Rastreabilidade
   A gestão de requisitos deve prover meios
    para que seja possível fazer um
    rastreamento entre os requisitos.
   Devem ser criados e mantidos entre
    requisitos, desde os requisitos de negócio
    até os requisitos de implementação, de
    testes e de documentação.
   Deve ser possível seguir estes vínculos
    nas duas direções.


                                                 26
Motivos para fazer
    Rastreabilidade
   Certificação – demonstração de que todos os
    requisitos foram implementados.

   Análise de impacto – cálculo do custo, tempo e risco
    de uma mudança.

   Manutenção – Indicação dos lugares onde deverão
    ser feitas as alterações solicitadas.

   Acompanhamento do projeto – aferição do progresso
    de um projeto de desenvolvimento ou manutenção.



                                                           27
Motivos para fazer Rastreabilidade
   Reengenharia – vínculo entre as funções do velho
    sistema e o local em que as mesmas estão
    implementadas no novo sistema.

   Reutilização – identificação de pacotes reutilizáveis de
    requisitos, design, código e testes.

   Redução de riscos – redução do impacto causado pela
    perda de um membro da equipe que mantém
    conhecimento essencial sobre o projeto.

   Testes – apoio na identificação dos locais onde pode
    estar o defeito detectado.



                                                               28
Classificação de Requisitos




                              29
Classificação de Requisitos
   Níveis de Requisitos
       Nível de negócio
       Nível de sistema
   Tipos de Requisitos
         ­   Nível de negócio
              ­   Requisitos de usuário (negócio)
              ­   Regras de negócio
         ­   Nível de sistema
              ­   Requisitos Funcionais
              ­   Requisitos Não Funcionais;
              ­   Requisitos Inversos;
                                                    30
Níveis de Requisitos
   Existem basicamente                  dois     níveis     de
    requisitos:
    ­   Nível de negócio:
         
             Considera-se um nível macro, onde o foco principal é
             o negócio, independente do sistema.

    ­   Nível de sistema:
         
             Considera-se um nível mais micro, onde a
             preocupação é identificar todos os requisitos
             necessários para o negócio, que devem ser
             contemplados no sistema.
                                                              31
Nível de Negócio
   Existem dois tipos de requisitos neste nível:
    ­   Requisitos de negócio:
            São as necessidades do negócio que são expressas pelos
             usuários ou clientes do sistema.
            São declarações, em linguagem natural ou em diagramas
             sobre o que o negócio exige que seja desenvolvido. Os
             requisitos de negócio devem se concentrar no que o
             sistema deve atender e não no como.

    ­   Regras de negócio:
            São restrições sobre dados ou processos de negócio.


                                                                   32
Regras de Negócios
   Uma regra de negócio descrevem, restringem
    ou controlam os dados ou atividades de um
    processo de negócio.
   Um processo de negócio é um conjunto de um
    ou mais procedimentos, os quais coletivamente
    realizam um objetivo de negócio, normalmente
    dentro do contexto de uma estrutura
    organizacional.




                                              33
Regras de Negócios
   Uma organização ou empresa opera de acordo com um conjunto
    de regras de negócio, tais como, regras jurídicas, regras de
    venda, regras de interação com o cliente, entre outras.

   As regras expressam aspectos estáticos e dinâmicos do negócio.

   A automatização dos processos de negócio exige                  a
    automatização das regras que regem estes processos.

   As regras são representadas em uma linguagem processável,
    com a finalidade de automatizá-las em um sistema.




                                                               34
Exemplo
Regra:       O gerente designado para atender a um
cliente deve estar lotado em uma agência onde o cliente
possui conta corrente.


                         Está lotado
           Gerente                      Agência

                Atende                 Pertence



                           Possui        Conta
            Cliente
                                        Corrente


                                                     35
Nível de Sistema
­   Requisitos de sistema:
     
         Estabelecem detalhadamente as funções e as
         restrições de sistema. O documento de requisitos de
         sistema, algumas vezes chamado de especificação
         funcional é gerado neste nível. Ele pode servir como
         um contrato entre o comprador do sistema e o
         desenvolvedor de software.




                                                          36
Tipos de Requisitos de Sistema
   Requisitos Funcionais
    ­   Descrevem os serviços que se espera que o sistema
        deve oferecer.
    ­   Especificam as funcionalidades do sistema.
   Requisitos Não Funcionais
    ­   Descrevem aspectos de qualidade que o software deverá
        apresentar, ou as restrições a serem atendidas.
    ­   Os requisitos não funcionais referem-se às condições
        nas quais deve funcionar o sistema.
    ­   Podem estar relacionados a propriedades do sistema, tais como,
        confiabilidade, desempenho, etc.
   Requisitos Inversos
    ­   Referem-se ao que o sistema não fará. Descrevem as funções e
        restrições que não serão consideradas na abrangência do sistema.
    ­   São declarações do que o sistema não deve fazer ou de
        condições que nunca devem ocorrer durante o uso do
        sistema.


                                                                    37
Tipos de Requisitos de Sistema
   Exemplos de Requisitos Funcionais:
     ­   O sistema deve permitir o cálculo dos gastos diários,
         semanais, mensais e anuais com o pessoal.
     ­   O sistema deve permitir consultar informações
         gerenciais operacionais da empresa.
   Exemplos de Requisitos Não Funcionais:
     ­   O tempo de resposta do sistema não deve ultrapassar
         30 segundos.
     ­   O software deve ser operacionalizado no sistema Linux..
     ­   O sistema deve ter uma disponibilidade 24x7.
   Exemplos de Requisitos Inversos:
     ­   A integração com o banco central, contabilidade e
         recursos humanos não fazem parte deste sistema.
                                                             38
Requisitos Funcionais
 Como especificar requisitos funcionais?
  Linguagem Natural

     ­   Os requisitos funcionais podem ser descritos em linguagem
         natural em nível macro.
    Casos de uso
     ­   Um modelo de casos de uso é utilizado para representar as
         funcionalidades do sistema de forma detalhada.
     ­   Um modelo de casos de uso identifica quem ou o que
         interage com o sistema e o que sistema deve fazer.
     ­   Casos de uso são técnicas baseadas em cenários onde são
         identificados atores e sua interação com o sistema.




                                                                     39
Requisitos Não Funcionais


   TIPOS DE REQUISITOS NÃO FUNCIONAIS (Sommerville)
     Requisitos de produtos
       ­   São os requisitos que especificam o comportamento do produto.
       ­   Exemplo: requisitos de desempenho, que especificam com que rapidez o
           sistema deve operar.
      Requisitos organizacionais
       ­   São procedentes de políticas e procedimentos nas organizações do cliente e do
           desenvolvedor.
       ­   Entre os exemplos estão os padrões de processos que devem ser utilizados, os
           requisitos de implementação, como a linguagem de programação ou a
           metodologia de processo de desenvolvimento.
      Requisitos externos
       ­   Abrange todos os requisitos procedentes de fatores externos ao sistema e ao
           seu processo de desenvolvimento.
       ­   Exemplo: requisitos de interoperabilidade, requisitos legais, requisitos éticos.




                                                                                     40
Requisitos Não Funcionais

                                           Requisitos
                                         não-funcionais



                       Produto           Organizacionais                 Externos



                                                    Interoperabilidade    Éticos
     Eficiência    Confiabilidade Portabilidade


                                                                                    Legislativos
Facilidade
  de uso                         Entrega Implementação Padrões



                                                                  Privacidade       Segurança
Desempenho        Espaço




                                                                                          41
Requisitos Não Funcionais
    Usabilidade (facilidade de uso)
      ­ Definição: A facilidade de aprendizado e operação do software pelos potenciais
        usuários.
      ­ Métrica: Tempo de treinamento
                 Habilidades do usuário / unidade de tempo
                 Recursos de ajuda on-line
      ­ Exemplo:
          
             Um balconista treinado deve ser capaz de cadastrar um cliente em no
             máximo 5 minutos.
          
             Novos usuários do internet banking devem ser capazes de encontrar o
             serviço de recarga de celulares no máximo em duas tentativas.

    Eficiência (performance)
      ­  Definição: medida de velocidade e eficiência do sistema em execução.
      ­  Métrica: Throughput (quantidade de transações/unidade de tempo)
                  Tempo de resposta ao usuário/evento
                            Capacidade (quantidade de usuários usando o sistema
         simultaneamente)

      ­   Exemplo:
           
             O tempo de resposta do serviço “saldo da conta” deve ser no máximo 4
             segundos.


                                                                                         42
Requisitos Não Funcionais




                            43
Requisitos Não Funcionais
    Portabilidade
      ­ Definição: A habilidade do software de se adaptar a diferentes ambientes
        pré-definidos.
      ­ Métrica: Número de sistemas-alvo
                 Porcentagem de declarações dependentes de sistemas-alvo
      ­ Exemplo:
           O sistema deverá ser capaz de operar em Windows e Linux.

    Confiabilidade
      ­ Definição: A habilidade do software de se comportar consistentemente de
        forma aceitável pelo usuário.
      ­ Métrica: Taxa de ocorrências de falhas
                 Probabilidade de indisponibilidade (downtime)
                 Disponibilidade
      ­ Exemplo:
           O sistema deverá estar disponível 24x7.

                                                                            44
Requisitos Não Funcionais
   Interoperabilidade
     ­ Definição: capacidade de interação com outros produtos especificados.
     ­ Métrica: Produtos com os quais o sistema deve se comunicar
     ­ Exemplo:
         
           O sistema deverá permitir exportar os relatórios para Excel.

   Segurança
     ­ Definição: resistência ao acesso não-autorizado e à perda de
       informações. Se preocupa pela privacidade dos dados.
     ­ Métrica: Restrições de acesso
          Definição de perfis de usuários

         
           Procedimentos de segurança dos dados
     ­ Exemplo:
         
           Duas cópias de segurança dos dados do sistema serão feitas
           diariamente e pelo menos uma delas deve ser armazenada em
           local externo.
                                                                         45
Requisitos Não Funcionais
    Requisitos de entrega
      ­ Definição: indicam restrições de prazos e forma de entrega dos produtos a
        serem elaborados.
      ­ Métrica: Data de Entrega
                  Formato de entrega de artefatos
      ­ Exemplo:
           O módulo referente a empréstimos deve ser entregue até dia 20 de
            janeiro de 2008.

    Requisitos de implementação
      ­ Definição: indicam restrições quanto ao uso de ferramentas ou linguagens
        de programação.
      ­ Métrica: Lista de ferramentas
                 Definição de padrões
      ­ Exemplo:
           O sistema será desenvolvido utilizando a linguagem de programação
            Java e o SGBD PostgreSQL.
                                                                             46
Requisitos Não Funcionais
    Requisitos relativos a padrões
      ­ Definição: indica a necessidade de obedecer métodos, normas e padrões
        institucionais.
      ­ Métrica: Lista de padrões
                  Definição de métodos
      ­ Exemplo:
            O sistema será desenvolvido seguindo o modelo de processo de
             desenvolvimento RUP.

    Requisitos éticos
      ­ Definição: abordam a prevenção da divulgação não autorizada de
        informações pessoais e o respeito aos indivíduos como cidadãos.
      ­ Métrica: Regras éticas
                  Normas de comportamento do usuário
      ­ Exemplo:
           O sistema deverá possuir meios de impedir a cópia e divulgação de
            listas de clientes para pessoas não autorizadas.
                                                                         47
Requisitos Não Funcionais
   Requisitos legais
    ­   Definição:     indica  a   necessidade de
        conformidade com determinações legais e
        regulatórias.
    ­   Métrica: Leis vigentes
                  Normas da empresa
    ­   Exemplo:
           O sistema deverá permitir o fornecimento dos dados
            pessoais sobre os clientes quando a gerencia solicitar
            os mesmos.


                                                               48
Importância dos Requisitos
Não Funcionais
   Todos os Requisitos Funcionais devem ser satisfeitos, mas
    se os Requisitos Não-Funcionais forem negligenciados, o
    sistema falhará.
Exercícios de Revisão
 Identificação de Tipos de Requisitos
   Verifique se as sentenças abaixo são requisitos verificáveis.
   Caso não sejam verificáveis, há uma forma melhor de defini-los?
   Caso sejam requisitos verificáveis, indicar o tipo de requisito.
    a) Todo funcionário deve possuir um cartão de identificação da empresa.
    b) O downtime do sistema é 2 horas no período da madrugada de domingo.
    c) O sistema deve permitir aos professores realizar uma reserva de
    equipamentos por meio de uma aplicação web.
    d) As janelas do sistema devem ter uma interface que permita aos usuários
    utilizar o sistema de forma intuitiva.
    e) O sistema deverá estar preparado para usuários com deficiências físicas.
    f) O sistema deve permitir a criação de um menu de opções de equipamentos
    que possam ser reservados.
    g) O sistema deverá ser desenvolvido na linguagem de programação Java.
    h) O sistema deve exportar dados de uma forma clara e precisa.
    i) A reserva de um equipamento deve ser realizada no máximo 24 horas antes
    do evento marcado.
    j) O sistema deve ter a capacidade de suportar 2500 usuários simultaneamente.
    k) O sistema deverá ser finalizado antes do final do ano.
Dúvidas




          51

Mais conteúdo relacionado

Mais procurados

Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
Cloves da Rocha
 
Introdução à Gerência de configuração de Software
Introdução à Gerência de configuração de SoftwareIntrodução à Gerência de configuração de Software
Introdução à Gerência de configuração de Software
Lucas Amaral
 
Testes de Software
Testes de SoftwareTestes de Software
Testes de Software
Capgemini
 
Aula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareAula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de Software
Cloves da Rocha
 
Aula4 levantamento requisitos
Aula4 levantamento requisitosAula4 levantamento requisitos
Aula4 levantamento requisitos
Computação Depressão
 
engenharia-de-requisitos
engenharia-de-requisitosengenharia-de-requisitos
engenharia-de-requisitos
Fábio Nogueira de Lucena
 
Fundamentos da Engenharia de Software
Fundamentos da Engenharia de SoftwareFundamentos da Engenharia de Software
Fundamentos da Engenharia de Software
Álvaro Farias Pinheiro
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
Mailson Queiroz
 
Aula 7 - Modelagem de Software
Aula 7 - Modelagem de SoftwareAula 7 - Modelagem de Software
Aula 7 - Modelagem de Software
Leinylson Fontinele
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
Nécio de Lima Veras
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
Tiago Antônio da Silva
 
Aula 04 coneitos de auditoria de sistemas
Aula 04   coneitos de auditoria de sistemasAula 04   coneitos de auditoria de sistemas
Aula 04 coneitos de auditoria de sistemas
sorayaNadja
 
Arquitetura de Software Visão Geral
Arquitetura de Software Visão GeralArquitetura de Software Visão Geral
Arquitetura de Software Visão Geral
sergiocrespo
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
eros.viggiano
 
Capitulo 02 sommerville
Capitulo 02 sommervilleCapitulo 02 sommerville
Capitulo 02 sommerville
Fabricio Schlag
 
Comandos CMD
Comandos CMDComandos CMD
Comandos CMD
Joao Andre Picao
 
UML
UMLUML
Modelo de documento para levantamento de requisitos de software
Modelo de documento para levantamento de requisitos de softwareModelo de documento para levantamento de requisitos de software
Modelo de documento para levantamento de requisitos de software
Francilvio Roberto Alff
 
Banco de questões qualidade de software
Banco de questões qualidade de softwareBanco de questões qualidade de software
Banco de questões qualidade de software
Bruno Nascimento
 
Gerência de Configuração
Gerência de ConfiguraçãoGerência de Configuração
Gerência de Configuração
Wagner Zaparoli
 

Mais procurados (20)

Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Introdução à Gerência de configuração de Software
Introdução à Gerência de configuração de SoftwareIntrodução à Gerência de configuração de Software
Introdução à Gerência de configuração de Software
 
Testes de Software
Testes de SoftwareTestes de Software
Testes de Software
 
Aula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareAula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de Software
 
Aula4 levantamento requisitos
Aula4 levantamento requisitosAula4 levantamento requisitos
Aula4 levantamento requisitos
 
engenharia-de-requisitos
engenharia-de-requisitosengenharia-de-requisitos
engenharia-de-requisitos
 
Fundamentos da Engenharia de Software
Fundamentos da Engenharia de SoftwareFundamentos da Engenharia de Software
Fundamentos da Engenharia de Software
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
 
Aula 7 - Modelagem de Software
Aula 7 - Modelagem de SoftwareAula 7 - Modelagem de Software
Aula 7 - Modelagem de Software
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
 
Aula 04 coneitos de auditoria de sistemas
Aula 04   coneitos de auditoria de sistemasAula 04   coneitos de auditoria de sistemas
Aula 04 coneitos de auditoria de sistemas
 
Arquitetura de Software Visão Geral
Arquitetura de Software Visão GeralArquitetura de Software Visão Geral
Arquitetura de Software Visão Geral
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Capitulo 02 sommerville
Capitulo 02 sommervilleCapitulo 02 sommerville
Capitulo 02 sommerville
 
Comandos CMD
Comandos CMDComandos CMD
Comandos CMD
 
UML
UMLUML
UML
 
Modelo de documento para levantamento de requisitos de software
Modelo de documento para levantamento de requisitos de softwareModelo de documento para levantamento de requisitos de software
Modelo de documento para levantamento de requisitos de software
 
Banco de questões qualidade de software
Banco de questões qualidade de softwareBanco de questões qualidade de software
Banco de questões qualidade de software
 
Gerência de Configuração
Gerência de ConfiguraçãoGerência de Configuração
Gerência de Configuração
 

Destaque

Requisitos Nao Funcionais
Requisitos Nao FuncionaisRequisitos Nao Funcionais
Requisitos Nao Funcionais
guesta36ce2
 
Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
Rildo (@rildosan) Santos
 
Especificação de requisitos
Especificação de requisitosEspecificação de requisitos
Especificação de requisitos
Fernando Palma
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de Software
Ralph Rassweiler
 
Eng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. RequisitosEng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. Requisitos
Manuel Menezes de Sequeira
 
Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?
Priscilla Aguiar
 
Identificação de necessidades e estabelecimento de requisitos
Identificação de necessidades e estabelecimento de requisitosIdentificação de necessidades e estabelecimento de requisitos
Identificação de necessidades e estabelecimento de requisitos
ptbr
 
Prototype
PrototypePrototype
Prototype
tceufrasio1
 
Documento de visao SCCI - Grupo ACCER
Documento de visao SCCI - Grupo ACCERDocumento de visao SCCI - Grupo ACCER
Documento de visao SCCI - Grupo ACCER
accer-scci
 
Ap i unidade 3 - levantamento de requisitos
Ap i   unidade 3 - levantamento de requisitosAp i   unidade 3 - levantamento de requisitos
Ap i unidade 3 - levantamento de requisitos
Glauber Aquino
 
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Rosanete Grassiani dos Santos
 
Engenharia de software apostila analise de requisitos i
Engenharia de software   apostila analise de requisitos iEngenharia de software   apostila analise de requisitos i
Engenharia de software apostila analise de requisitos i
robinhoct
 
Metodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de SoftwareMetodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de Software
Álvaro Farias Pinheiro
 
Requisitos de software
Requisitos de softwareRequisitos de software
Requisitos de software
Marcelo Yamaguti
 
Eng.ª do Software - 3. Processos da engenharia de requisitos
Eng.ª do Software - 3. Processos da engenharia de requisitosEng.ª do Software - 3. Processos da engenharia de requisitos
Eng.ª do Software - 3. Processos da engenharia de requisitos
Manuel Menezes de Sequeira
 
Processadores
ProcessadoresProcessadores
Processadores
Daniela Oura
 

Destaque (16)

Requisitos Nao Funcionais
Requisitos Nao FuncionaisRequisitos Nao Funcionais
Requisitos Nao Funcionais
 
Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
 
Especificação de requisitos
Especificação de requisitosEspecificação de requisitos
Especificação de requisitos
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de Software
 
Eng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. RequisitosEng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. Requisitos
 
Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?
 
Identificação de necessidades e estabelecimento de requisitos
Identificação de necessidades e estabelecimento de requisitosIdentificação de necessidades e estabelecimento de requisitos
Identificação de necessidades e estabelecimento de requisitos
 
Prototype
PrototypePrototype
Prototype
 
Documento de visao SCCI - Grupo ACCER
Documento de visao SCCI - Grupo ACCERDocumento de visao SCCI - Grupo ACCER
Documento de visao SCCI - Grupo ACCER
 
Ap i unidade 3 - levantamento de requisitos
Ap i   unidade 3 - levantamento de requisitosAp i   unidade 3 - levantamento de requisitos
Ap i unidade 3 - levantamento de requisitos
 
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
 
Engenharia de software apostila analise de requisitos i
Engenharia de software   apostila analise de requisitos iEngenharia de software   apostila analise de requisitos i
Engenharia de software apostila analise de requisitos i
 
Metodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de SoftwareMetodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de Software
 
Requisitos de software
Requisitos de softwareRequisitos de software
Requisitos de software
 
Eng.ª do Software - 3. Processos da engenharia de requisitos
Eng.ª do Software - 3. Processos da engenharia de requisitosEng.ª do Software - 3. Processos da engenharia de requisitos
Eng.ª do Software - 3. Processos da engenharia de requisitos
 
Processadores
ProcessadoresProcessadores
Processadores
 

Semelhante a Aula3 engenharia requisitos

CMM e CMMI
CMM e CMMICMM e CMMI
CMM e CMMI
felipegaraujo
 
CMM e CMMI
CMM e CMMICMM e CMMI
Análise e Design Orientado a Objetos.ppt
Análise e Design Orientado a Objetos.pptAnálise e Design Orientado a Objetos.ppt
Análise e Design Orientado a Objetos.ppt
TzveDyor
 
Engenharia de software apostila analise de requisitos ii
Engenharia de software   apostila analise de requisitos iiEngenharia de software   apostila analise de requisitos ii
Engenharia de software apostila analise de requisitos ii
robinhoct
 
Utilização da Engenharia de Requisitos: Onde, quando e como utilizar
Utilização da Engenharia de Requisitos: Onde, quando e como utilizarUtilização da Engenharia de Requisitos: Onde, quando e como utilizar
Utilização da Engenharia de Requisitos: Onde, quando e como utilizar
Opencadd Advanced Technology
 
Testes de software
Testes de softwareTestes de software
Testes de software
Fernando Palma
 
Apres. eng. de software
Apres. eng. de softwareApres. eng. de software
Apres. eng. de software
William Gomes
 
3 engenharia de software
3   engenharia de software3   engenharia de software
3 engenharia de software
Felipe Bugov
 
Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2
Fernando Vargas
 
X-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de SoftwareX-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de Software
AlexandreBartie
 
Visão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOKVisão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOK
Mário Pravato Junior
 
CMMI 7
CMMI 7CMMI 7
CMMI 7
Aleh Santos
 
Gerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptxGerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptx
Roberto Nunes
 
Aula 02
Aula 02Aula 02
CMM – Capability Maturity Model
CMM – Capability Maturity Model CMM – Capability Maturity Model
CMM – Capability Maturity Model
alef menezes
 
4 engenharia de software
4   engenharia de software4   engenharia de software
4 engenharia de software
Felipe Bugov
 
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Marcelo Schumacher
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Cris Fidelix
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
testedesoftwarepe
 
Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1
Fernando Palma
 

Semelhante a Aula3 engenharia requisitos (20)

CMM e CMMI
CMM e CMMICMM e CMMI
CMM e CMMI
 
CMM e CMMI
CMM e CMMICMM e CMMI
CMM e CMMI
 
Análise e Design Orientado a Objetos.ppt
Análise e Design Orientado a Objetos.pptAnálise e Design Orientado a Objetos.ppt
Análise e Design Orientado a Objetos.ppt
 
Engenharia de software apostila analise de requisitos ii
Engenharia de software   apostila analise de requisitos iiEngenharia de software   apostila analise de requisitos ii
Engenharia de software apostila analise de requisitos ii
 
Utilização da Engenharia de Requisitos: Onde, quando e como utilizar
Utilização da Engenharia de Requisitos: Onde, quando e como utilizarUtilização da Engenharia de Requisitos: Onde, quando e como utilizar
Utilização da Engenharia de Requisitos: Onde, quando e como utilizar
 
Testes de software
Testes de softwareTestes de software
Testes de software
 
Apres. eng. de software
Apres. eng. de softwareApres. eng. de software
Apres. eng. de software
 
3 engenharia de software
3   engenharia de software3   engenharia de software
3 engenharia de software
 
Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2
 
X-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de SoftwareX-Zone - Garantia da Qualidade de Software
X-Zone - Garantia da Qualidade de Software
 
Visão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOKVisão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOK
 
CMMI 7
CMMI 7CMMI 7
CMMI 7
 
Gerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptxGerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptx
 
Aula 02
Aula 02Aula 02
Aula 02
 
CMM – Capability Maturity Model
CMM – Capability Maturity Model CMM – Capability Maturity Model
CMM – Capability Maturity Model
 
4 engenharia de software
4   engenharia de software4   engenharia de software
4 engenharia de software
 
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
 
Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1Validação e Testes de Software - MOD1
Validação e Testes de Software - MOD1
 

Mais de Computação Depressão

Sd08 (si) sistemas de arquivos distribuídos
Sd08 (si)   sistemas de arquivos distribuídosSd08 (si)   sistemas de arquivos distribuídos
Sd08 (si) sistemas de arquivos distribuídos
Computação Depressão
 
Sd06 (si) exclusão mútua
Sd06 (si)   exclusão mútuaSd06 (si)   exclusão mútua
Sd06 (si) exclusão mútua
Computação Depressão
 
Sd05 (si) relógios e sincronização
Sd05 (si)   relógios e sincronizaçãoSd05 (si)   relógios e sincronização
Sd05 (si) relógios e sincronização
Computação Depressão
 
Sd04 (si) comunicação em sd
Sd04 (si)   comunicação em sdSd04 (si)   comunicação em sd
Sd04 (si) comunicação em sd
Computação Depressão
 
Sd03 (si) conceitos básicos de sd
Sd03 (si)   conceitos básicos de sdSd03 (si)   conceitos básicos de sd
Sd03 (si) conceitos básicos de sd
Computação Depressão
 
Sd02 (si) gerenciamento de entrada e saída
Sd02 (si)   gerenciamento de entrada e saídaSd02 (si)   gerenciamento de entrada e saída
Sd02 (si) gerenciamento de entrada e saída
Computação Depressão
 
Sd01 (si) sistemas de arquivos
Sd01 (si)   sistemas de arquivosSd01 (si)   sistemas de arquivos
Sd01 (si) sistemas de arquivos
Computação Depressão
 
Sd07 (si) eleição
Sd07 (si)   eleiçãoSd07 (si)   eleição
Sd07 (si) eleição
Computação Depressão
 
Ufbamat2013
Ufbamat2013Ufbamat2013
Ufbaingles2013
Ufbaingles2013Ufbaingles2013
Ufbaingles2013
Computação Depressão
 
Ufbagab mat 2013
Ufbagab mat 2013Ufbagab mat 2013
Ufbagab mat 2013
Computação Depressão
 
Ufbagab ingles2013
Ufbagab ingles2013Ufbagab ingles2013
Ufbagab ingles2013
Computação Depressão
 
Ufbagab fis 2013
Ufbagab fis 2013Ufbagab fis 2013
Ufbagab fis 2013
Computação Depressão
 
Ufbafisqui2013
Ufbafisqui2013Ufbafisqui2013
Ufbafisqui2013
Computação Depressão
 
Ufbagab qui 2013
Ufbagab qui 2013Ufbagab qui 2013
Ufbagab qui 2013
Computação Depressão
 
Questesdetecnologia ano2002
Questesdetecnologia ano2002Questesdetecnologia ano2002
Questesdetecnologia ano2002
Computação Depressão
 
Questesdematemtica ano2003
Questesdematemtica ano2003Questesdematemtica ano2003
Questesdematemtica ano2003
Computação Depressão
 
Questesdematemtica ano2002
Questesdematemtica ano2002Questesdematemtica ano2002
Questesdematemtica ano2002
Computação Depressão
 
Questesdefundamentos ano2002
Questesdefundamentos ano2002Questesdefundamentos ano2002
Questesdefundamentos ano2002
Computação Depressão
 

Mais de Computação Depressão (20)

Sd08 (si) sistemas de arquivos distribuídos
Sd08 (si)   sistemas de arquivos distribuídosSd08 (si)   sistemas de arquivos distribuídos
Sd08 (si) sistemas de arquivos distribuídos
 
Sd06 (si) exclusão mútua
Sd06 (si)   exclusão mútuaSd06 (si)   exclusão mútua
Sd06 (si) exclusão mútua
 
Sd05 (si) relógios e sincronização
Sd05 (si)   relógios e sincronizaçãoSd05 (si)   relógios e sincronização
Sd05 (si) relógios e sincronização
 
Sd04 (si) comunicação em sd
Sd04 (si)   comunicação em sdSd04 (si)   comunicação em sd
Sd04 (si) comunicação em sd
 
Sd03 (si) conceitos básicos de sd
Sd03 (si)   conceitos básicos de sdSd03 (si)   conceitos básicos de sd
Sd03 (si) conceitos básicos de sd
 
Sd02 (si) gerenciamento de entrada e saída
Sd02 (si)   gerenciamento de entrada e saídaSd02 (si)   gerenciamento de entrada e saída
Sd02 (si) gerenciamento de entrada e saída
 
Sd01 (si) sistemas de arquivos
Sd01 (si)   sistemas de arquivosSd01 (si)   sistemas de arquivos
Sd01 (si) sistemas de arquivos
 
Sd07 (si) eleição
Sd07 (si)   eleiçãoSd07 (si)   eleição
Sd07 (si) eleição
 
Ufbamat2013
Ufbamat2013Ufbamat2013
Ufbamat2013
 
Ufbaingles2013
Ufbaingles2013Ufbaingles2013
Ufbaingles2013
 
Ufbagab mat 2013
Ufbagab mat 2013Ufbagab mat 2013
Ufbagab mat 2013
 
Ufbagab ingles2013
Ufbagab ingles2013Ufbagab ingles2013
Ufbagab ingles2013
 
Ufbagab fis 2013
Ufbagab fis 2013Ufbagab fis 2013
Ufbagab fis 2013
 
Ufbafisqui2013
Ufbafisqui2013Ufbafisqui2013
Ufbafisqui2013
 
Ufbagab qui 2013
Ufbagab qui 2013Ufbagab qui 2013
Ufbagab qui 2013
 
Questesdetecnologia ano2002
Questesdetecnologia ano2002Questesdetecnologia ano2002
Questesdetecnologia ano2002
 
Questesdematemtica ano2003
Questesdematemtica ano2003Questesdematemtica ano2003
Questesdematemtica ano2003
 
Questesdematemtica ano2002
Questesdematemtica ano2002Questesdematemtica ano2002
Questesdematemtica ano2002
 
Questesdefundamentos ano2003
Questesdefundamentos ano2003Questesdefundamentos ano2003
Questesdefundamentos ano2003
 
Questesdefundamentos ano2002
Questesdefundamentos ano2002Questesdefundamentos ano2002
Questesdefundamentos ano2002
 

Aula3 engenharia requisitos

  • 1. Engenharia de Software Aula 3 – Engenharia de Requisitos Profa. Dra. Judith Pavón Universidade Salvador – UNIFACS 2012
  • 2. Objetivo da aula O objetivo desta aula é apresentar os conceitos básicos de Engenharia de Requisitos. 2
  • 3. Conteúdo 1. Introdução 2. Importância dos requisitos 3. Processo de Engenharia de Requisitos 4. Classificação dos requisitos 3
  • 4. Introdução  Um processo de engenharia de requisitos eficiente evita uma compreensão incorreta dos requisitos. 4
  • 5. Introdução  Requisitos são importantes para projetos de desenvolvimento de software, pois são a base para : ­ Análise de contratos; ­ Elaboração / análise de propostas; ­ Planejamento; ­ Estimativas; ­ Análise de riscos; ­ Gestão e controle; ­ Modelagem do sistema; ­ Desenvolvimento; ­ Testes. 5
  • 6. Introdução  Problemas com requisitos levam a: ­ Clientes insatisfeitos; ­ Altos custos; ­ Perda de reputação; ­ Compreensão do “problema incorreto”; ­ Efeito cascata nas demais fases de desenvolvimento de software. 6
  • 7. Importância dos requisitos  CMMI-SE/SW (Capability Maturity Model Integration) ­ Modelo de melhoria de processo de desenvolvimento de software. ­ Modelo seguindo 5 níveis de maturidade. ­ Capacidade de um processo de software:  faixa de resultados esperados dentro de uma margem de probabilidade. ­ Maturidade do processo:  reflete em que medida ele pode ser definido, gerenciado, medido, controlado e executado de maneira eficaz. 7
  • 8. Importância dos requisitos  CMMI-SE/SW (Capability Maturity Model Integration) 5. OTIMIZADO 4. GERENCIADO 5. Processo focado na QUANTITATIVAMENTE melhoria contínua 3. DEFINIDO 4. Processo medido e controlado 2. GERENCIADO 3. Processo orientado à organização e proativo 1. 2. Processo orientado a INICIAL projetos e geralmente reativo 1. Processo imprevisível, pouco controlado e reativo 8
  • 9. Importância dos requisitos Níveis de Maturidade - CMMI-SE/SW 9
  • 10. Importância dos requisitos Processo de Engenharia de Requisitos (PER) no modelo CMMI nível 3. definido PER baseado em melhores práticas; melhoria contínua nível 2. repetível PER obedecendo a normas nível 1. inicial PER adhoc 10
  • 11. Importância dos requisitos Ciclo de Vida de Software (SWEBOK, 2004) Levantamento Projeto de Implementação Teste de Manutenção de e Definição Software de Software Software Software de Requisitos Elicitação de Requisitos Análise de Requisitos Especificação de Requisitos ri co e né el o G Validação d de Requisitos Mo Gerenciamento de Requisitos SWEBOK – Guide to the Software Engineering Body of Knowledge (IEEE) 11
  • 12. Importância dos requisitos  56% dos erros em um sistema associam-se a problemas na fase de identificação dos requisitos (Fonte: “Extra time saves money” Warren Kuffel).  Erros mais comuns: uso de fatos incorretos, omissão, inconsistência e ambigüidade. Distribuição de Defeitos 56% Requisitos 27% Projeto 7% 10% Outros Codificação
  • 13. Importância dos requisitos Clássicas falhas de sistemas por problemas de requisitos  Aeroporto de Denver: mais de US$ 50 milhões perdidos em função de erros no sistema de controle de bagagens (Flower).  Sistema de Ambulâncias de Londres: o sistema foi desativado um dia após o início de suas operações com causa de seus erros e falhas de segurança, confiabilidade e usabilidade (Flower).  Foguete do Satélite Ariane 5: a trajetória do foguete era controlada por um sistema de computador, que falhou junto com seu sistema backup. Comandos de diagnóstico foram enviados para os motores, fazendo com que o foguete mudasse para uma trajetória instável (Nuseibeh). 13
  • 14. Conceitos Básicos Requisito  Uma especificação do que deve ser implementado. Descrição de como o sistema deve se comportar, ou uma propriedade ou atributo do sistema. Pode ser uma restrição no processo de desenvolvimento do sistema. (Sommerville & Sawyer)  Uma condição ou capacidade que o sistema deve contemplar (Pressman)  Uma necessidade do usuário ou característica, função ou atributo de um sistema que pode ser percebido de uma posição externa ao sistema. (Davis) 14
  • 15. Conceitos Básicos Engenharia de Requisitos  A Engenharia de Requisitos é um processo que envolve todas as atividades necessárias para criar e manter um Documento de Especificação de Requisitos (Sommerville).  A Engenharia de Requisitos é uma sub-área da Engenharia de Software que estuda o processo de definição de requisitos que o software deverá atender (Sampaio).  A Engenharia de Requisitos tem como objetivo prover ao profissional de métodos, técnicas e ferramentas que auxiliem o processo de compreensão e registro dos requisitos que o sistema deve atender (Sampaio). 15
  • 16. Processo de Engenharia de Requisitos Processo  É um conjunto organizado de atividades que transforma entradas em saídas (Pressman). Atividades do Processo de Engenharia de Requisitos (Sommerville & Kontoya)  Elicitação de Requisitos ­ Os requisitos são descobertos por meio das consultas com as partes interessadas.  Análise e Negociação de Requisitos ­ Requisitos são analisados e conflitos são resolvidos por meio da negociação.  Documentação de Requisitos ­ Um documento de requisitos é produzido.  Validação de Requisitos ­ É checada a consistência, completude e outros atributos de qualidade do documento de requisitos.  Gerenciamento de Requisitos ­ Consiste no controle de mudanças dos requisitos dentro do ciclo de vida do 16 software.
  • 17. Processo de Engenharia de Requisitos Análise Elicitação Documentaç Validação ão Gerenciamento de Requisitos Fonte: Sommerville & Sawyer, 2000 17
  • 18. Processo de Engenharia de Requisitos Elicitar Requisitos Controlar Mudanças Analisar Requisitos Rastreabilidade Requisitos Documentar Requisitos Gerenciar Configuração Gerenciar Qualidade Validar Requisitos de Requisitos Desenvolvimento de Requisitos Gerenciamento de Requisitos 18
  • 19. Processo de Engenharia de Requisitos sistemas Processo de Engenharia de Requisitos existentes (Entradas e Saídas) necessidades dos usuários normas processo de requisitos da engenharia de aprovados organização requisitos Documento de regulamentos Requisitos informação do Fonte: Kotonya & Sommerville, 1998 domínio 19
  • 20. Processo de Engenharia de Requisitos Características Principais da Engenharia de Requisitos  O processo de engenharia de requisitos é estruturado como um conjunto de atividades que leva a produção do documento de requisitos.  As entradas do processo de engenharia de requisitos são as informações existentes dos sistemas, necessidade das pessoas interessadas (stakeholders), padrões organizacionais, regulamentações e informações do domínio.  Os processos de engenharia de requisitos variam radicalmente entre empresas. A maioria dos processos incluem a elicitação de requisitos, análise e negociação, a documentação e a validação dos requisitos.  A atividade de gerenciamento de requisitos é uma atividade complementar que auxilia no controle das mudanças dos requisitos. 20
  • 21. Stakeholders Atores no Processo de Engenharia de Requisitos: Stakeholders  Quem são os “interessados no sistema”? São as pessoas que serão afetadas pelo sistema e que têm uma influência direta ou indireta na elaboração dos requisitos: ­ usuários finais, gestores e outros envolvidos nos processos organizacionais que o sistema influencia, responsáveis pelo desenvolvimento e manutenção do sistema, clientes da organização que possam vir a usar o sistema, organismos de regulação e certificação, etc. 21
  • 22. Stakeholders Alguns exemplos de partes interessadas (stakeholders):  Gestor do sistema;  Usuários finais;  Gestores de sistemas impactados;  Funcionários;  Clientes do banco;  Especialistas no negócio;  Órgãos reguladores;  Parceiros. 22
  • 23. Conceito de Rastreabilidade  Técnica usada para prover relacionamento entre requisitos, projeto e implementação final do sistema (Edwards).  É uma técnica que permite que os requisitos sejam claramente ligados às suas fontes e aos artefatos criados durante o ciclo de vida de desenvolvimento do sistema (Ramesh).  Habilidade de permitir que mudanças em qualquer artefato – requisitos, especificação e implementação– sejam rastreadas através do sistema (Greenspan). Rastreabilidad Domínio do Problema Necessidades e Macro-Requisitos Domínio da Requisitos Solução Projeto e Documentações 23
  • 24. Conceito de Rastreabilidade  Uma especificação de requisitos é rastreável se permite a fácil determinação dos antecedentes e conseqüências de todos os requisitos.  Rastreabilidade para Trás: ­ Deve ser possível localizar a origem de cada requisito. ­ Deve-se saber por que existe cada requisito, e quem ou o que o originou. Isso é importante para que se possa avaliar o impacto da mudança daquele requisito, e dirimir dúvidas de interpretação.  Rastreabilidade para Frente: ­ Deve ser possível localizar quais os resultados do desenvolvimento que serão afetados por cada requisito. Isso é importante para garantir que os itens de análise, modelagem, código e teste abranjam todos os requisitos, e para localizar os itens que serão afetados por uma mudança nos requisitos. 24
  • 25. Conceito de Rastreabilidade  Os usuários comunicaram uma série de mudanças nas regras de negócio do Sistema de Contabilidade. Quanto você acha que vamos levar para alterar o sistema?  Cara, vai dar um trabalhão. A lógica do cálculo dos impostos está espalhado por todo o sistema. Vamos gastar um tempão só para localizar todos os lugares que teremos de mexer. 25
  • 26. Conceito de Rastreabilidade  A gestão de requisitos deve prover meios para que seja possível fazer um rastreamento entre os requisitos.  Devem ser criados e mantidos entre requisitos, desde os requisitos de negócio até os requisitos de implementação, de testes e de documentação.  Deve ser possível seguir estes vínculos nas duas direções. 26
  • 27. Motivos para fazer Rastreabilidade  Certificação – demonstração de que todos os requisitos foram implementados.  Análise de impacto – cálculo do custo, tempo e risco de uma mudança.  Manutenção – Indicação dos lugares onde deverão ser feitas as alterações solicitadas.  Acompanhamento do projeto – aferição do progresso de um projeto de desenvolvimento ou manutenção. 27
  • 28. Motivos para fazer Rastreabilidade  Reengenharia – vínculo entre as funções do velho sistema e o local em que as mesmas estão implementadas no novo sistema.  Reutilização – identificação de pacotes reutilizáveis de requisitos, design, código e testes.  Redução de riscos – redução do impacto causado pela perda de um membro da equipe que mantém conhecimento essencial sobre o projeto.  Testes – apoio na identificação dos locais onde pode estar o defeito detectado. 28
  • 30. Classificação de Requisitos  Níveis de Requisitos  Nível de negócio  Nível de sistema  Tipos de Requisitos ­ Nível de negócio ­ Requisitos de usuário (negócio) ­ Regras de negócio ­ Nível de sistema ­ Requisitos Funcionais ­ Requisitos Não Funcionais; ­ Requisitos Inversos; 30
  • 31. Níveis de Requisitos  Existem basicamente dois níveis de requisitos: ­ Nível de negócio:  Considera-se um nível macro, onde o foco principal é o negócio, independente do sistema. ­ Nível de sistema:  Considera-se um nível mais micro, onde a preocupação é identificar todos os requisitos necessários para o negócio, que devem ser contemplados no sistema. 31
  • 32. Nível de Negócio  Existem dois tipos de requisitos neste nível: ­ Requisitos de negócio:  São as necessidades do negócio que são expressas pelos usuários ou clientes do sistema.  São declarações, em linguagem natural ou em diagramas sobre o que o negócio exige que seja desenvolvido. Os requisitos de negócio devem se concentrar no que o sistema deve atender e não no como. ­ Regras de negócio:  São restrições sobre dados ou processos de negócio. 32
  • 33. Regras de Negócios  Uma regra de negócio descrevem, restringem ou controlam os dados ou atividades de um processo de negócio.  Um processo de negócio é um conjunto de um ou mais procedimentos, os quais coletivamente realizam um objetivo de negócio, normalmente dentro do contexto de uma estrutura organizacional. 33
  • 34. Regras de Negócios  Uma organização ou empresa opera de acordo com um conjunto de regras de negócio, tais como, regras jurídicas, regras de venda, regras de interação com o cliente, entre outras.  As regras expressam aspectos estáticos e dinâmicos do negócio.  A automatização dos processos de negócio exige a automatização das regras que regem estes processos.  As regras são representadas em uma linguagem processável, com a finalidade de automatizá-las em um sistema. 34
  • 35. Exemplo Regra: O gerente designado para atender a um cliente deve estar lotado em uma agência onde o cliente possui conta corrente. Está lotado Gerente Agência Atende Pertence Possui Conta Cliente Corrente 35
  • 36. Nível de Sistema ­ Requisitos de sistema:  Estabelecem detalhadamente as funções e as restrições de sistema. O documento de requisitos de sistema, algumas vezes chamado de especificação funcional é gerado neste nível. Ele pode servir como um contrato entre o comprador do sistema e o desenvolvedor de software. 36
  • 37. Tipos de Requisitos de Sistema  Requisitos Funcionais ­ Descrevem os serviços que se espera que o sistema deve oferecer. ­ Especificam as funcionalidades do sistema.  Requisitos Não Funcionais ­ Descrevem aspectos de qualidade que o software deverá apresentar, ou as restrições a serem atendidas. ­ Os requisitos não funcionais referem-se às condições nas quais deve funcionar o sistema. ­ Podem estar relacionados a propriedades do sistema, tais como, confiabilidade, desempenho, etc.  Requisitos Inversos ­ Referem-se ao que o sistema não fará. Descrevem as funções e restrições que não serão consideradas na abrangência do sistema. ­ São declarações do que o sistema não deve fazer ou de condições que nunca devem ocorrer durante o uso do sistema. 37
  • 38. Tipos de Requisitos de Sistema  Exemplos de Requisitos Funcionais: ­ O sistema deve permitir o cálculo dos gastos diários, semanais, mensais e anuais com o pessoal. ­ O sistema deve permitir consultar informações gerenciais operacionais da empresa.  Exemplos de Requisitos Não Funcionais: ­ O tempo de resposta do sistema não deve ultrapassar 30 segundos. ­ O software deve ser operacionalizado no sistema Linux.. ­ O sistema deve ter uma disponibilidade 24x7.  Exemplos de Requisitos Inversos: ­ A integração com o banco central, contabilidade e recursos humanos não fazem parte deste sistema. 38
  • 39. Requisitos Funcionais Como especificar requisitos funcionais?  Linguagem Natural ­ Os requisitos funcionais podem ser descritos em linguagem natural em nível macro.  Casos de uso ­ Um modelo de casos de uso é utilizado para representar as funcionalidades do sistema de forma detalhada. ­ Um modelo de casos de uso identifica quem ou o que interage com o sistema e o que sistema deve fazer. ­ Casos de uso são técnicas baseadas em cenários onde são identificados atores e sua interação com o sistema. 39
  • 40. Requisitos Não Funcionais TIPOS DE REQUISITOS NÃO FUNCIONAIS (Sommerville)  Requisitos de produtos ­ São os requisitos que especificam o comportamento do produto. ­ Exemplo: requisitos de desempenho, que especificam com que rapidez o sistema deve operar.  Requisitos organizacionais ­ São procedentes de políticas e procedimentos nas organizações do cliente e do desenvolvedor. ­ Entre os exemplos estão os padrões de processos que devem ser utilizados, os requisitos de implementação, como a linguagem de programação ou a metodologia de processo de desenvolvimento.  Requisitos externos ­ Abrange todos os requisitos procedentes de fatores externos ao sistema e ao seu processo de desenvolvimento. ­ Exemplo: requisitos de interoperabilidade, requisitos legais, requisitos éticos. 40
  • 41. Requisitos Não Funcionais Requisitos não-funcionais Produto Organizacionais Externos Interoperabilidade Éticos Eficiência Confiabilidade Portabilidade Legislativos Facilidade de uso Entrega Implementação Padrões Privacidade Segurança Desempenho Espaço 41
  • 42. Requisitos Não Funcionais  Usabilidade (facilidade de uso) ­ Definição: A facilidade de aprendizado e operação do software pelos potenciais usuários. ­ Métrica: Tempo de treinamento Habilidades do usuário / unidade de tempo Recursos de ajuda on-line ­ Exemplo:  Um balconista treinado deve ser capaz de cadastrar um cliente em no máximo 5 minutos.  Novos usuários do internet banking devem ser capazes de encontrar o serviço de recarga de celulares no máximo em duas tentativas.  Eficiência (performance) ­ Definição: medida de velocidade e eficiência do sistema em execução. ­ Métrica: Throughput (quantidade de transações/unidade de tempo) Tempo de resposta ao usuário/evento Capacidade (quantidade de usuários usando o sistema simultaneamente) ­ Exemplo:  O tempo de resposta do serviço “saldo da conta” deve ser no máximo 4 segundos. 42
  • 44. Requisitos Não Funcionais  Portabilidade ­ Definição: A habilidade do software de se adaptar a diferentes ambientes pré-definidos. ­ Métrica: Número de sistemas-alvo Porcentagem de declarações dependentes de sistemas-alvo ­ Exemplo:  O sistema deverá ser capaz de operar em Windows e Linux.  Confiabilidade ­ Definição: A habilidade do software de se comportar consistentemente de forma aceitável pelo usuário. ­ Métrica: Taxa de ocorrências de falhas Probabilidade de indisponibilidade (downtime) Disponibilidade ­ Exemplo:  O sistema deverá estar disponível 24x7. 44
  • 45. Requisitos Não Funcionais  Interoperabilidade ­ Definição: capacidade de interação com outros produtos especificados. ­ Métrica: Produtos com os quais o sistema deve se comunicar ­ Exemplo:  O sistema deverá permitir exportar os relatórios para Excel.  Segurança ­ Definição: resistência ao acesso não-autorizado e à perda de informações. Se preocupa pela privacidade dos dados. ­ Métrica: Restrições de acesso  Definição de perfis de usuários  Procedimentos de segurança dos dados ­ Exemplo:  Duas cópias de segurança dos dados do sistema serão feitas diariamente e pelo menos uma delas deve ser armazenada em local externo. 45
  • 46. Requisitos Não Funcionais  Requisitos de entrega ­ Definição: indicam restrições de prazos e forma de entrega dos produtos a serem elaborados. ­ Métrica: Data de Entrega Formato de entrega de artefatos ­ Exemplo:  O módulo referente a empréstimos deve ser entregue até dia 20 de janeiro de 2008.  Requisitos de implementação ­ Definição: indicam restrições quanto ao uso de ferramentas ou linguagens de programação. ­ Métrica: Lista de ferramentas Definição de padrões ­ Exemplo:  O sistema será desenvolvido utilizando a linguagem de programação Java e o SGBD PostgreSQL. 46
  • 47. Requisitos Não Funcionais  Requisitos relativos a padrões ­ Definição: indica a necessidade de obedecer métodos, normas e padrões institucionais. ­ Métrica: Lista de padrões Definição de métodos ­ Exemplo:  O sistema será desenvolvido seguindo o modelo de processo de desenvolvimento RUP.  Requisitos éticos ­ Definição: abordam a prevenção da divulgação não autorizada de informações pessoais e o respeito aos indivíduos como cidadãos. ­ Métrica: Regras éticas Normas de comportamento do usuário ­ Exemplo:  O sistema deverá possuir meios de impedir a cópia e divulgação de listas de clientes para pessoas não autorizadas. 47
  • 48. Requisitos Não Funcionais  Requisitos legais ­ Definição: indica a necessidade de conformidade com determinações legais e regulatórias. ­ Métrica: Leis vigentes Normas da empresa ­ Exemplo:  O sistema deverá permitir o fornecimento dos dados pessoais sobre os clientes quando a gerencia solicitar os mesmos. 48
  • 49. Importância dos Requisitos Não Funcionais  Todos os Requisitos Funcionais devem ser satisfeitos, mas se os Requisitos Não-Funcionais forem negligenciados, o sistema falhará.
  • 50. Exercícios de Revisão Identificação de Tipos de Requisitos  Verifique se as sentenças abaixo são requisitos verificáveis.  Caso não sejam verificáveis, há uma forma melhor de defini-los?  Caso sejam requisitos verificáveis, indicar o tipo de requisito. a) Todo funcionário deve possuir um cartão de identificação da empresa. b) O downtime do sistema é 2 horas no período da madrugada de domingo. c) O sistema deve permitir aos professores realizar uma reserva de equipamentos por meio de uma aplicação web. d) As janelas do sistema devem ter uma interface que permita aos usuários utilizar o sistema de forma intuitiva. e) O sistema deverá estar preparado para usuários com deficiências físicas. f) O sistema deve permitir a criação de um menu de opções de equipamentos que possam ser reservados. g) O sistema deverá ser desenvolvido na linguagem de programação Java. h) O sistema deve exportar dados de uma forma clara e precisa. i) A reserva de um equipamento deve ser realizada no máximo 24 horas antes do evento marcado. j) O sistema deve ter a capacidade de suportar 2500 usuários simultaneamente. k) O sistema deverá ser finalizado antes do final do ano.
  • 51. Dúvidas 51