Engenharia de Software Cap. 3: Requisitos

Engenharia de Software Cap. 3: Requisitos

1. Requisitos

   • Requisitos Funcionais
     • "o que um sistema deve fazer"
     • Especificados em linguagem natural
     • Exemplo: Abrir e fechar conta, Realizar transferência, Realizar saque, etc
   • Requisitos Não-Funcionais
     • "sob que restrições"
     • Especificados de forma quantitativa usando-se métricas
     • Exemplos:
       • Desempenho: Transações por segundo, tempo de resposta,
       • Disponibilidade: estar no ar 99.99% do tempo
       • Segurança: criptografar dados trocados com as agências
       • Privacidade: não armazenar localização dos usuários
     • Podem afetar a arquitetura geral de um sistema em vez de apenas componentes individuais;
     • São restrições aos serviços ou funções oferecidas pelo sistema. Aplicam-se ao sistema como um todo.
   • O que um sistema deve fazer e sob que restrições
   • Requisitos de usuário
     • São requisitos de mais alto nível, escritos por usuários, normalmente em linguagem natural e sem entrar em detalhes técnicos.
   • Requisitos de sistema
     • São técnicos, precisos e escritos pelos próprios desenvolvedores.
   • Requisitos são a ponte que liga um problema do mundo real a um sistema de software que o soluciona.

2. "A parte mais difícil da construção de um software é a definição do que se deve construir." - Fred Brooks

3. Engenharia de Requisitos

   • É o conjunto de atividades relacionadas com a descoberta, análise, especificação e manutenção dos requisitos de um sistema.
   • Elicitação de Requisitos
     • Designa as interações dos desenvolvedores de um sistema com os seus stakeholders, com o objetivo, descobrir e entender os principais requisitos do sistema que se pretende construir.
     • Algumas técnicas para elicitação:
       • Entrevistas com stakeholders
       • Aplicação de questionários
       • Leitura de documentos e formulários da organização
       • Implementação de protótipos
       • Análise de cenários de uso
       • Estudos etnográficos
         • Designa o estudo de uma cultura em seu ambiente natural (etnos, em grego, significa povo ou cultura).
     • Após elicitados os requisitos devem ser
       • (1) documentados
         • No caso do desenvolvimento ágil é utilizado
           • Histórias do usuário
             • Sugerido por Ron Jeffries, Livro: Extreme Programming Installed, Outubro de 2000
             • Cartão
               • Usado pelos clientes para escrever em poucas sentenças, uma funcionalidade que esperam ver implementada no sistema.
               • É um lembrete do representante dos clientes para os desenvolvedores.
             • Conversas
               • Comunicação verbal entre cliente e time para entendimento de cada cartão;
             • Confirmação
               • Cenários que serão usados pelo PO para aceitar a implementação da história (escritos no verso do cartão)
               • Testes de aceitação
                 • Evitar o gold plating
                   • Situação na qual os desenvolvedores decidem, por conta própria, sofisticar a implementação de algumas histórias — ou requisitos, de forma mais genérica —, sem que isso tenha sido pedido pelos clientes.
             • Troca-se um documento de requisitos com centenas de páginas por conversas frequentes
             • Boas histórias devem ser INVEST
               • Independentes
                 • Não devem existir dependências entre duas histórias.
               • Abertas para negociação
                 • Desenvolvedores e clientes, devem estar abertos a ceder em suas opiniões durante essas conversas.
               • Agregar valor
                 • Histórias são propostas, escritas e priorizadas pelos clientes e de acordo com o valor que elas agregam ao seu negócio.
               • viável estimar
                 • Tamanho de uma história, quantos dias serão necessários para implementá-la.
               • sucintas
                 • Histórias do topo do backlog, devem ser sucintas e pequenas, para facilitar o entendimento e estimativa.
                 • Épicos
                   • Histórias complexas e grandes, ficam posicionadas no final do backlog, onde não se tem previsão de quando serão implementadas.
               • testáveis
                 • Devem ter critérios de aceitação objetivos
             • Product Owner (PO) é quem escreve as histórias
               • Workshop de escrita de histórias
                 • Realizado no início do projeto;
                 • Criar uma lista inicial de histórias;
                 • Reúne em uma sala representantes dos principais usuários do sistema
               • Antes de escrever deve-se definir os papéis dos usuários
                 • Principais usuários que vão interagir com o sistema.
             • Critérios para conclusão:
               • Qualidade externa:
                 • Testes não-funcionais (ex.: desempenho, usabilidade)
               • Qualidade interna:
                 • Testes de unidade;
                 • Revisão de código.
           • Documento de Especificação de Requisitos
             • Padrão IEEE 830
               • Década de 90
               • Padrão para Documentos de Especificação de Requisitos
               • Proposto no contexto de Processos Waterfall
         • Casos de Uso (use cases)
           • São uma técnica de descoberta de requisitos a qual identifica atores em uma interação, sendo esta, suplementada por outros modelos gráficos.
           • Eles são escritos pelos próprios desenvolvedores do sistema
           • Ator
             • Entidade externa ao sistema que deseja usar o sistema com um objetivo
             • Um caso de uso enumera os passos que um ator realiza em um sistema com um determinado objetivo.
           • Fluxo normal
             • São os passos necessários para concluir uma operação com sucesso.
             • Descreve um cenário em que tudo dá certo
           • Extensões do fluxo normal
             • Representam alternativas de execução de um passo normal ou então situações de erro.
             • Detalha algum passo do fluxo normal
             • Tratar erros, exceções, cancelamentos, etc.
           • Detalhes sobre os Casos de Uso
             • 1- Deve ter um nome
               • primeira palavra deve ser um verbo no infinitivo.
             • 2- Informar o ator principal
               • Pode também incluir um outro caso de uso
                 • Sintaxe: o nome do caso de uso a ser incluído deve estar sublinhado
                 • Semântica: todos os passos do caso de uso incluído devem ser executados antes de prosseguir
             • 3- Podem incluir seções adicionais:
               • (1) propósito do caso de uso;
               • (2) pré-condições
                 • o que deve ser verdadeiro antes da execução do caso de uso;
               • (3) pós-condições,
                 • o que deve ser verdadeiro após a execução do caso de uso;
               • (4) uma lista de casos de uso relacionados.
             • 4- Boas práticas para escrita de um Caso de Uso
               • As ações de um caso de uso devem ser escritas em uma linguagem simples e direta.
               • Devem ser pequenos, com poucos passos, principalmente no fluxo normal, para facilitar o entendimento.
                 • Alistair Cockburn autor do livro Writing Effective Use Cases recomenda:
                   • Casos de uso devem ter no máximo nove passos no fluxo normal
               • Casos de uso não são algoritmos
               • Não devem tratar de aspectos tecnológicos ou de design.
                 • O objetivo deve ser documentar "o que" o sistema deverá fazer e não como ele irá implementar os requisitos especificados.
               • Evite casos de uso muito simples
               • Padronize o vocabulário adotado
                 • David Thomas e Andrew Hunt no livro The Pragmatic Programmer recomendam:
                   • criação de um glossário, isto é, um documento que lista os termos e vocabulário usados em um projeto.
           • Diagrama de Casos de Uso
             • Ele representa os atores de um sistema (como pequenos bonecos) e os casos de uso (como elipses).
             • Relacionamentos:
               • (1) ligando ator com caso de uso, que indicam que um ator participa de um determinado caso de uso;
               • (2) ligando dois casos de uso, que indicam que um caso de uso inclui ou estende outro caso de uso.
         • Produto Mínimo Viável (MVP)
           • Popularizado no livro Lean Startup, de Eric Ries
             • Lean Startup é inspirado nos princípios de Manufatura Lean
             • Lean startup propõe um método sistemático e científico
               • construir
                 • Tem-se uma ideia de produto e então implementa-se um MVP para testá-la.
               • medir
                 • o MVP é disponibilizado para uso por clientes reais com o intuito de coletar dados sobre a sua viabilidade.
               • aprender
                 • as métricas coletadas são analisadas e geram o que se denomina de aprendizado validado (validated learning).
           • Consiste em implementar um sistema simples, com um conjunto de requisitos mínimos, mas que sejam suficientes para testar a viabilidade de continuar investindo no seu desenvolvimento.
           • Com o aprendizado obtido:
             • Pode-se concluir que ainda são necessários mais testes com o MVP, repetindo o ciclo, voltando para o passo construir.
             • Pode-se concluir que o teste foi bem sucedido e, portanto, achou-se um mercado para o sistema (um market fit)
             • Pode-se concluir que o MVP falhou, após várias tentativas. Restando:
               • (1) perecer, isto é, desistir do empreendimento
               • (2) realizar um pivô, isto é, abandonar a visão original e tentar um novo MVP com novos requisitos
           • Métricas
             • A partir dessas decisões pode surgir
               • Métricas de vaidade (vanity metrics)
                 • Essas são métricas superficiais que fazem bem para o ego dos desenvolvedores e gerentes de produto, mas que não ajudam a entender e aprimorar uma estratégia de mercado.
               • Métricas acionáveis (actionable metrics).
                 • São métricas que ajudam a tomar decisões sobre o futuro de um MVP a partir de análises da utilização do sistema e assim apresentando os dados para incorporação de novas funcionalidades ou atualizações
               • Métricas de funil (funnel metrics)
                 • Capturam o nível de interação dos usuários com um sistemas MVPs que incluem vendas de produtos ou serviços
                 • Aquisição: número de clientes que visitaram o seu sistema.
                 • Ativação: número de clientes que criaram uma conta no sistema.
                 • Retenção: clientes que retornaram ao sistema, após criarem uma conta.
                 • Receita: número de clientes que fizeram uma compra.
                 • Recomendação: clientes que recomendaram o sistema para terceiros.
           • Protótipo
             • Design Sprint
               • Proposto por Jake Knapp, John Zeratsky e Braden Kowitz
               • Testa e valida novos produtos por meio de protótipos, não necessariamente de software
               • não confundir com um sprint, de Scrum
               • Time-box.
                 • Objetivo: descobrir uma primeira solução para um problema rapidamente (duração de 5 dias).
               • Equipes pequenas e multidisciplinares.
                 • Deve reunir uma equipe de sete pessoas, fomentando discussões porém, procura-se evitar debates intermináveis. Participa representantes de todas as áreas envolvidas com o sistema, a equipe deve incluir um tomador de decisões
               • Objetivos e regras claras
               • Não é voltado apenas para definição de um protótipo de MVP.
           • Testes A/B (ou split tests)
             • São usados para escolher, dentre duas versões de um sistema, aquela que desperta maior interesse dos usuários.
             • Constituem uma abordagem dirigida por dados para seleção de requisitos (ou funcionalidades) que serão oferecidos em um sistema. O requisito vencedor será mantido no sistema e a versão com o requisito perdedor será descartada.
             • Versão de controle (sistema A)
               • Se tem a implementação de um algoritmo
             • uma implementa um requisito A e outra implementa um requisito B
             • Versão de tratamento (sistema B)
               • Taxa de conversão.
                 • Métrica para medir os ganhos obtidos com a versão de tratamento.
                 • A expectativa é que o novo algoritmo aumente esse percentual.
               • Consiste do mesmo sistema, mas com um algoritmo supostamente mais eficaz.
             • Determina quantos clientes deveremos testar com cada uma das versões.
             • Teste de Hipótese.
               • Hipótese Nula (H0)
                 • Representa o "status quo" do sistema
                 • assume que nada vai mudar e que, portanto, a versão B não é melhor do que a versão atual do sistema.
               • Hipótese Alternativa (H1)
                 • É a hipótese que muda o "status quo"
               • É um procedimento de decisão que parte do princípio de que H0 é verdadeira e, em seguida, tenta refutá-la.
               • Sempre trabalham com uma probabilidade de erro
                 • Erro do Tipo I ou um falso positivo
                   • Ex: concluímos indevidamente que a versão B é melhor do que a versão A.
                   • Nível de Significância (significance level)
                     • Representado pela letra grega α (alfa)
                     • Esse parâmetro define a probabilidade de ocorrência de erros do Tipo I.
       • (2) verificados e validados
         • Requisitos devem estar corretos
         • Requisitos devem ser precisos
           • Não devem ser ambíguos
         • Requisitos devem ser completos
           • Não podemos esquecer de especificar certos requisitos, principalmente se eles forem importantes.
         • Requisitos devem ser consistentes
         • Requisitos devem ser verificáveis
           • Deve ser possível testar se os requisitos estão sendo atendidos.
       • (3) Priorizados

Bilder und Dateien der Mindmap