Engenharia de Requisitos by 46CZmY

VIEWS: 51 PAGES: 75

									Engenharia de Requisitos

    Alexandre Vasconcelos
      (amlv@cin.ufpe.br)



                            1
Objetivos
   Descrever as principais atividades da
    engenharia de requisitos
   Introduzir técnicas para a elicitação
    e análise de requisitos
   Descrever validação de requisitos
   Discutir o gerenciamento de
    requisitos

                                        2
   O Processo da Engenharia de
   Requisitos
Estudo de      Elicitação de
viabilidade    requisitos e
                  análise
                               Especificação
                               de requisitos
                                                Validação
Relatório de                                   de requisitos
viabilidade


                               Requisitos do
                               usuário e do
                                 sistema


               Modelos do                      Documento de
                sistema                          requisitos

                                                               3
Elicitação de requisitos e
análise
   Esta atividade divide-se em dois
    esforços maiores:
       Elicitação dos requisitos em si
            Técnicas de elicitação
       Análise do que foi elicitado
            Processo de análise




                                          22
Que é um requisito?
   Tanto pode ser
       Uma declaração abstrata de alto nível de
        um serviço
       Como uma restrição do sistema
   Quanto uma especificação funcional
    matemática detalhada



                                             23
Elicitação de Requisitos
   Também denominada de descoberta de
    requisitos
   Envolve pessoal objetivando descobrir o
    domínio de aplicação, serviços que devem
    ser fornecidos bem como restrições
   Deve envolver usuários finais, gerentes,
    pessoal envolvido na manutenção,
    especialistas no domínio, etc.
    (Stakeholders).
                                               24
Visão dos Requisitos
   Requisitos do Usuário
       Declarações em linguagem natural com
        diagramas de serviços que o sistema
        deve oferecer e suas restrições
        operacionais. Escrito para os clientes
   Requisitos do Sistema
       Documento estruturado com descrições
        detalhadas sobre os serviços do sistema.
        Contrato entre cliente e fornecedor

                                                 25
Tipos de Requisitos
   Requisitos Funcionais

   Requisitos Não-Funcionais

   Requisitos de Domínio



                                26
Requisitos Funcionais
   Descreve funcionalidade e serviços do
    sistema
   Depende do
       Tipo do software
       Usuários esperados
       Tipo do sistema onde o software é usado



                                            27
Exemplos de R.F.
   [RF001] Usuário pode pesquisar todo ou um
    sub-conjunto do banco de dados
   [RF002] Sistema deve oferecer
    visualizadores apropriados para o usuário
    ler documentos armazenados
   [RF003] A todo pedido deve ser associado
    um identificador único (PID), o qual o
    usuário pode copiar para a área de
    armazenamento permanente da conta
                                          28
Requisitos Não-Funcionais
   Definem propriedades e restrições do
    sistema (tempo, espaço, etc)
   Requisitos de processo também podem
    especificar o uso de determinadas
    linguagens de programação, método de
    desenvolvimento
   Requisitos não-funcionais podem ser mais
    críticos que requisitos funcionais. Não
    satisfaz, sistema inútil.
                                           30
Requisitos Não-Funcionais
   Devido à sua própria definição,
    requisitos não-funcionais são
    esperados mensuráveis
   Assim, deve-se associar forma de
    medida/referência a cada requisito
    não-funcional elicitado



                                         31
           Medidas de Requisitos
           (Não-Funcionais)
Propriedade          Medida
Velocidade           Transações processadas/seg
                     Tempo de resposta do usuário/evento
Tamanho              K bytes
                     No de chips de RAM
Facilidade de uso    Tempo de treinamento
                     No de quadros de ajuda
Confiabilidade       Tempo médio de falhas
                     Probabilidade de indisponibilidade
                     Taxa de ocorrência de falhas
Robustez             Tempo de reinício após falha
                     Percentual de eventos causando falhas
                     Probabilidade de corrupção de dados após falha
Portabilidade        Percentual de declarações dependentes do destino
                     No de sistemas destino
                                                               32
Classificação de R. N. F.
   Requisitos do Produto
       Produto deve comportar-se de forma particular
        (velocidade de execução, confiabilidade, etc.)
   Requisitos Organizacionais
       Conseqüência de políticas e procedimentos
        organizacionais (padrões de processo usados,
        requisitos de implementação, etc.)
   Requisitos Externos
       Conseqüência de fatores externos ao sistema e
        ao processo de desenvolvimento (legislação,
        etc.)


                                                       33
Exemplos de R. N. F.
   Requisitos do Produto
       [RNF001] Toda consulta ao B.D., baseada em
        código de barras, deve resultar em até 5 s
   Requisitos Organizacionais
       [RNF002] Todos os documentos entregues
        devem seguir o padrão de relatórios XYZ-00
   Requisitos Externos
       [RNF003] Informações pessoais do usuário não
        devem ser vistas pelos operadores do sistema

                                                     34
Requisitos de Domínio
   Derivados do domínio da aplicação e
    descrevem características do sistema e
    qualidades que refletem o domínio
   Podem ser requisitos funcionais novos,
    restrições sobre requisitos existentes ou
    computações específicas
   Se requisitos de domínio não forem
    satisfeitos, o sistema pode tornar-se
    impraticável
                                            36
Requisitos de Domínio
(Problemas)
   Entendimento
       Requisitos são descritos na linguagem do
        domínio da aplicação
       Não é entendido pelos engenheiros de
        software que vão desenvolver a aplicação
   Implicitude
       Especialistas no domínio entendem a área
        tão bem que não tornam todos os
        requisitos de domínio explícitos

                                             37
    Requisitos
                      Requisitos

                Usuário      Sistema



Funcionais          Não-funcionais            Domínio



      Produto        Organização        Externo

                                                    40
Técnicas de Elicitação
   Entrevistas
   Questionários
   Casos de Uso
   Jogo de Funções
   Brainstorming
   Workshop de Requisitos


                             41
  Análise de Requisitos
                   Definição e
                                                      Documento
                  especificação
                                                     de requisitos
                  de requisitos
                                7                    8

                                      Validação
                                    dos requisitos
             Entendimento                        6
                                                               Atrib. Prioridade
              do domínio
Entrada do                  1
 processo                                                  5

                            2                              4
              Coleta de                                         Resolução
              requisitos                                        de conflito
                                                 3

                                    Classificação
                                                                               52
Entendimento do Domínio
   Desenvolver sistemas envolve
    domínios além de software e
    hardware
   Podemos ter que entender sobre
       Contabilidade
       Saúde
       Supermercados
       Etc.
                                     53
Coleta de Requisitos
   Como vimos anteriormente, a coleta
    de requisitos é feita através de
    técnicas
   Nesta etapa, os requisitos são
    simplesmente documentados à medida
    que são coletados
   Resulta em documento preliminar
    (draft)
                                    54
Classificação dos Requisitos
   Esta etapa consiste basicamente em
    agrupar os diversos requisitos
    coletados em categorias (clusters)
    bem-definidos
   Por exemplo
       Deve ser possível consultar o preço de
        uma mercadoria
            A consulta deve retornar uma resposta em no
             máximo 5s
                                                    55
Problema da Análise de
Requisitos
   Stakeholders em geral não sabem o
    que querem
   Stakeholders expressam requisitos
    em sua terminologia
   Stakeholders diferentes podem gerar
    requisitos conflitantes


                                    56
Problema da Análise de
Requisitos
   Fatores políticos e organizacionais
    podem influenciar os requisitos do
    sistema
   Requisitos mudam durante o processo
    de análise. Stakeholders novos podem
    surgir e o ambiente de trabalho
    mudar

                                      57
Resolução de Conflitos
   É normal que ocorram requisitos
    conflitantes
   Por exemplo
       R-23: O sistema deve ...
       R-45: O sistema não deve ...
   Cliente/usuário deve ser consultado
    para resolver conflitos
    (ambigüidades)

                                          58
Atribuição de Prioridade
   Alguns requisitos são mais urgentes
    que outros
   É essencial determinar a prioridade
    dos requisitos junto ao cliente
   Requisitos de maior prioridade são
    considerados em primeiro lugar


                                          59
Prioridade
   Requisitos podem ser vistos em três
    classes distintas
       Essenciais
       Importantes
       Desejáveis
   Em princípio, sistema deve resolver
    todos os requisitos de essenciais para
    desejáveis

                                       60
Exemplo de Prioridade
   [RF001] Consulta X ao B.D. deve retornar
    dados A, B, C
       Prioridade: Essencial
   [RNF001] Consulta X ao B.D. deve visualizar
    dados segundo padrão Y
       Prioridade: Importante
   [RNF010] Consulta X ao B.D. deve usar
    cores azuis nos resultados
       Prioridade: Desejável


                                            61
Validação dos Requisitos
   Será que realmente entendi o que o
    cliente deseja?
   Devo me certificar de que não houve
    falha em nossa interação
    (comunicação)
   Há diversas técnicas de validação


                                      62
Validação de Requisitos
   Demonstrar que os requisitos definem
    o sistema que o cliente realmente
    deseja
   Custos com erros de requisitos são
    altos
       Consertar um erro de requisitos após
        entrega do sistema pode custar mais de
        100 vezes o custo de um erro de
        implementação
                                            63
Técnicas de Validação de
Requisitos
   Revisões de Requisitos
       Análise manual sistemática dos requisitos
   Prototipação
       Uso de modelo executável do sistema para
        avaliar requisitos
   Geração de Casos de Teste
       Desenvolver testes específicos para os
        requisitos para avaliá-los
   Análise de Consistência Automática
       Avaliar uma especificação dos requisitos

                                                    64
Gerenciamento de Requisitos
   Gerenciamento de requisitos é o
    processo de controlar as mudanças
    dos requisitos durante
       O processo da engenharia de requisitos
       E desenvolvimento do sistema




                                             65
Gerenciamento de Requisitos
   Requisitos são inevitavelmente incompletos
    e inconsistentes
       Requisitos novos surgem durante o processo de
        acordo com mudanças nas necessidades do
        negócio e um entendimento melhor do sistema é
        desenvolvido
       Diferentes pontos de vista têm diferentes
        requisitos e esses geralmente são
        contraditórios


                                                  66
Rastreamento
   Responsável por dependências entre
    requisitos, suas origens e projeto do
    sistema
   Rastreamento de Origem
       Associação entre requisitos e
        stakeholders que propuseram tais
        requisitos


                                           67
Rastreamento
   Rastreamento de Requisitos
       Associação entre requisitos dependentes
   Rastreamento de Projeto
       Associação dos requisitos com o projeto
   Usar hipertexto ou referência
    cruzada
       Ou matriz de rastreamento

                                             68
         Rastreamento
                                              1.Rastrear requisitos do
     Requisitos                                 usuário nos do sistema
      Produto
  (Características)
                       Req A
                                              2.Rastrear requisitos no
                                                projeto
                         1                    3.Rastrear requisitos
                                                nos procedimentos de
  Requisitos
  Detalhados          Req B                     teste
(Casos de Uso)                                4.Rastrear requisitos do
                 2       3           4          usuário no plano

      Projeto            Teste           Doc. Usuário

      Modelos         Suítes Teste         Plano
                                                                   69
        Rastreamento: Análise de
        Impacto
Req A antes              Req A depois
“if return value > $5”   “if return value > $2”


        Req B                    Req B


             Req C                   Req C


    Links dos requisitos devem ser marcados como
     “revisar”
    Links “revisar” devem ser analisados
                                                    70
Documento de Requisitos
   Fonte: IEEE/ANSI (830-1998)
   1. Introdução
       1.1 Propósito do documento
       1.2 Escopo do sistema
       1.3 Definições, acrônimos e abreviaturas
       1.4 Referências
       1.5 Descrição do resto do documento


                                              71
Documento de Requisitos
   Fonte: IEEE/ANSI (830-1998)
   2. Descrição geral
       2.1 Perspectiva do produto
       2.2 Funções do produto
       2.3 Características dos usuários
       2.4 Restrições gerais
       2.5 Assertivas e dependências


                                           72
Documento de Requisitos
   Fonte: IEEE/ANSI (830-1998)
   3. Requisitos específicos
       requisitos funcionais, não-funcionais,
        GUI com o usuário:
          funcionalidade, interfaces externas,

           desempenho, restrições, atributos do
           sistema, caract. qualidade, ...
   Apêndices
   Índice
                                             73
Diagramas de Casos de Uso

    Alexandre Vasconcelos
      (amlv@cin.ufpe.br)



                            74
Objetivos
   Introduzir conceitos de use case,
    ator e fluxo de eventos
   Apresentar sub-fluxos de eventos
   Discutir sobre identificação, evolução
    e organização de use cases
   Apresentar notação UML para reusar
    atores e use cases

                                        75
Use Case
                             Seqüência de
                              ações, executada
                              pelo sistema, que
                              gera um resultado
                                 De valor observável
  Função                         E para ator
                                  particular



Procedimento computacional/algorítmico atômico
                                                  76
   Use Case e Ator
                      Alguém ou alguma
                       coisa (fora do
                       sistema) que
                       interage com o
                       sistema

Emissor/Receptor




                                      77
Use Case e Ator
   A descrição de um use case define o
    que o sistema faz quando o use case é
    realizado
   A funcionalidade do sistema é
    definida por um conjunto de use
    cases, cada um representando um
    fluxo de eventos específico

                                       79
   Use Case e Ator
          Descrição



                      Passo 1
                      Passo 2
                      …
                      Passo N

Emissor
                      Função
                                80
Exemplo de Use Case e Ator
   Cliente de banco pode usar um caixa
    automático para
       sacar dinheiro, transferir dinheiro ou
        consultar o saldo da conta
   Ator: Cliente
   Use cases: Sacar dinheiro, transferir
    dinheiro e consultar saldo

                                                 81
       Exemplo de Use Case e Ator
  Valor de
 resultado
observável

                Transferir
                 dinheiro




    Sacar                    Consultar
   dinheiro                    saldo

                 Cliente             82
Identificando Use Cases
   Em geral, difícil decidir entre um ou
    vários use cases
   Por exemplo, seriam use cases
       Inserir cartão em um Caixa Automático?
       Entrar com a senha?
       Receber o cartão de volta?



                                            83
Identificando Use Cases
   Representar valor observável para
    ator
   Pode-se determinar
       De interações (seqüência de ações) com o
        sistema que resultam valores para atores
       Satisfaz um objetivo particular de um
        ator que o sistema deve prover


                                             84
Reuso em Use Cases
   Comportamento comum a mais de dois
    use cases (ou forma parte
    independente)
       Pode-se modelar como use case para ser
        reusado
   Há três possibilidades
       Inclusão
       Extensão
       Generalização/Especialização
                                            91
Inclusão
   Vários use cases possuem texto de
    fluxo de eventos
       Comum/idêntico
       Sempre usado
   Equivalente a fatoração feita em
    programação através de sub-
    programas
       #include da linguagem C
                                        92
Inclusão
   Como exemplo, tanto “Sacar dinheiro”
    quanto “Consultar saldo” necessitam da
    senha
       Pode-se criar novo use case “Autenticar
        usuário” e incluí-lo
   Mas atenção
       NÃO SE DEVE CRIAR USE CASES MÍNIMOS
       Deve haver ganho no reuso




                                                  93
Inclusão


                  Autenticar
  << include >>                << include >>
                   usuário




 Sacar                             Consultar
dinheiro                             saldo

                                               94
Inclusão
   Descrição de Consultar saldo
       Fluxo de Eventos Principal:
            include (Autenticar usuário). Sistema pede a
             Cliente que selecione tipo de conta (corrente,
             etc). ...




                                                       95
Extensão
   Use case pode ser estendido por
    outro
       Extensão de funcionalidade/Caso
        excepcional
   Extensão ocorre em pontos
    específicos
       Pontos de extensão


                                          96
Extensão
   Há também inclusão de texto (fluxo
    de eventos)
       Porém sob condições particulares
   Pode ser usada para
       Simplificar fluxos de eventos complexos
       Representar comportamentos opcionais
       Lidar com exceções


                                             97
    Extensão

              << extend >>
                (urgente)




Atendimento                     Atendimento
de urgência
                             Pontos de extensão
                                  urgente



                                              98
Extensão
   Descrição de Atendimento
       Fluxo de Eventos Principal:
            Colete os itens do pedido. (urgente).
             Submeta pedido para processamento.




                                                     99
Especialização
   Use case pode especializar outro
       Adição/refinamento do fluxo de eventos
        original
   Especialização permite modelar
    comportamento de estruturas de
    aplicação em comum



                                           100
  Especialização




                   
Atendimento            Atendimento
de urgência




                       
  Cliente                Cliente
 comercial                           101
Fluxo de Eventos
   Parte mais importante de um use case
       Atividade de requisitos
   Define a seqüência de ações entre o
    ator e o sistema




                                      102
Fluxo de Eventos
   Geralmente em linguagem natural
       Uso preciso de termos definidos no
        glossário de acordo com o domínio do
        problema
   Também expresso formalmente
       Pré e pós-condições (ou pseudo-código)



                                               103
Exemplo de Fluxo de Eventos
        Um esboço inicial sobre Sacar
         dinheiro seria
    1.    O use case inicia quando o Cliente
          insere um cartão no CA. Sistema lê e
          valida informação do cartão
    2.    Sistema pede a senha. Cliente entra
          com a senha. Sistema valida a senha.
    3.    Sistema pede seleção do serviço.
          Cliente escolhe “Sacar dinheiro”

                                             104
Exemplo de Fluxo de Eventos
   Um esboço inicial sobre Sacar
    dinheiro seria
    4.   Sistema pede a quantia a sacar. Cliente
         informa.
    5.   Sistema pede seleção da conta
         (corrente, etc). Cliente informa.
    6.   Sistema comunica com a rede para
         validar a conta, senha e o valor a sacar.

                                               105
Exemplo de Fluxo de Eventos
    Um esboço inicial sobre Sacar
     dinheiro seria
    7.   Sistema pede remoção do cartão.
         Cliente remove.
    8.   Sistema entrega quantia solicitada.




                                               106
Fluxo de Eventos
   Na descrição do que o sistema faz
    através de fluxos de eventos
    completos
       Surgem caminhos alternativos
       Casos diferentes a considerar
       Efeitos/valores diferentes a produzir
   Eventualmente descreve todos esses
    caminhos possíveis
                                                108
Sub-fluxos de Eventos
   Fluxo de eventos visto como
       Vários sub-fluxos de eventos
   Sub-fluxos são descritos como
       Principal
       Alternativos/excepcionais
   Abordagem visa reuso de fluxos de
    eventos (sub-fluxos)

                                        109
Exemplo de Sub-fluxos
   Seja o use case Validar usuário
       Fluxo principal:
            O use case inicia quando o sistema pede ao Cliente a
             senha. Cliente entra com senha. Sistema verifica se a
             senha é válida. Se a senha é válida, sistema confirma e
             termina o use case.
       Fluxo excepcional:
            Cliente pode cancelar a transação a qualquer momento
             pressionando a tecla ESC, reiniciando o use case.
             Nenhuma modificação é feita na conta do Cliente.
       Fluxo excepcional:
            Se Cliente entra com senha inválida, o use case
             reinicia.
                                                               110
Diagrama de Atividades
   Descreve fluxo de tarefas
       Aspectos dinâmicos de um sistema
       Podem também ser usados para criar
        sistemas executáveis
           Depende do nível de detalhamento e grau de
            execução dos elementos usados
   Alternativa para modelar fluxos de
    eventos de casos de uso

                                                   111
Diagrama de atividades: exemplo




                                  112
Diagramas de Use Cases
   Caracterizar limites da funcionalidade
    do sistema
       Use cases são organizados dentro de um
        diagrama
   Em diagramas de use cases
       Atores são relacionados por
        generalização/especialização


                                           114
        Exemplo de Diagrama
                                     Sistema de validação
                                     de cartão de crédito

                                              Transação de
                                                 cartão

             Cliente                            Processa     Instituição
                                                 fatura      vendedora


                                                Reconcilia
                                                transações


  Cliente                Cliente
                                                 Gerencia
individual             corporativo                conta
                                                             Financeira

                                                                   115
Bibliografia
   Sommerville, I. Software Engineering
   Kruchten, P. The Rational Unified
    Process: An Introduction. 2nd Ed
   Booch, G. et al. The Unified Modeling
    Language User Guide.




                                      116

								
To top