CPRE-FL (Fundamentos da Engenharia de Requisitos)

1. Introdução e Fundamentos
1. Melhora da comunicação de requisitos resultou na - redução de falha de projetos, - cumprimento de prazos e - satisfação dos clientes;
2. Qnto + tarde identificar erro de requisito > será o custo para sua correção
3. Requisito (IEEE Standard 610.12 -1990)
  1. (1) é uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo;
  2. (2) é uma condição ou capacidade que deve estar presente em um sistema para satisfazer um contrato, norma, especificação ou outro documento formalmente imposto;
  3. (3) uma representação documentada de uma condição ou capacidade com em (1) e (2);
4. Stakeholders - Fonte de requisitos; pessoas ou organizações que tem algum impacto (direto ou indiretamente);
5. Engenharia de Requisitos (ER)
  1. 2 objetivos:
    1. 1) Conhecer os req. relevantes, estabelecer um consenso entre os stakeholders, documentar e gerenciar;
    2. 2) Compreender e documentar as expectativas e necessidades dos stakeholders, minimizando o risco da entrega ser incompatível as expectativas e necessidades;
  2. 4 atividades centrais:
    1. 1) Elicitação - obter em detalhes os requisitos das fontes;
    2. 2) Documentação - documentar os req. da forma mais adequada (linguagem natural e / ou modelos conceituais)
    3. 3) Validação e Negociação
    4. 4) Gerenciamento - medidas para estruturar req. e atividades para assegurar sua implementação
  3. Modelos de Processos
    1. Modelos Pesados
      1. Waterfall / Cascata (Royce, 1987)
      2. V (V-Modell, 2004)
        Elicitar e documentar os req. em fase incial; ER finita e restrita no tempo;
    2. Modelos Leves
      1. Extreme Programming - XP (Beck,1999)
        ER como um processo contínuo e abrangente; integra todas as fases do desenv. de sistemas
6. Fundamentos da Teoria de Comunicação - Fatores que contribuem para transmissão dos requisitos
  1. A linguagem como meio de comunicação de req.
  2. Tipo de meio de comunicação (verbal ou técnica escrita)
  3. Acomodação linguística
  4. Conhecimento implícito anterior ao tema
7. 1.3 Características de um Engenheiro de Requisitos
  1. 1) Raciocínio Analítico - familiarizar-se com domínios para compreender necessidades dos stakeholders
  2. 2) Empatia - boa intuição e empatia para compreender as necessidades;
  3. 3) Competência comunicativa
  4. 4) Resolução de conflitos
  5. 5) Moderação - liderar discussões ;)
  6. 6) Auto-confiança - capacidade de se defender em meio as críticas que irão surgir por estar no centro do processo
  7. 7) Persuasão - consolidar opiniões divergentes e facilitar tomada de decisões
8. 1.4 Tipos de Requisitos
  1. 1. Req. Funcionais - resultado de um comportamento a ser fornecido por uma função do sistema;
  2. 2. Req. de Qualidade ou Req. não funcionais - definem desempenho, disponibilidade , confiabilidade, escalabilidade, portabilidade de um sistema. Relacionados a atributos de arquitetura do sistema
    1. 1.5 Importância e Categorização dos Req. de Qualidade
      1. - ser objetivos e verificáveis;
      2. - devem ser documentados separadamente dos req. funcionais;
  3. 3. Restrições - uma condição do projeto que deve ser cumprida. Ex.: prazo.
2. Os Limites do Sistema e do Contexto
1. Na ER o objetivo de definir os limites para identificar a parte do ambiente que influencia nos requisitos do sistema a ser desenvolvido
2. 2.1 Contexto do Sistema
  1. Parte da realidade que é relevante para os requisitos de um sistema
    1. Exemplos: Pessoas, Sistemas em operação, Processos, Eventos, Documentos e Leis.
  2. Definir o Limite do Sistema
    1. Quais aspectos fazem parte do sistema a ser desenvolvido e quais fazem parte do contexto do sistema?
      1. é obrigatório esclarecer a zona cinzenta entre o sistema e o limite do sistema
      2. Uma vez definidos os limites do sistema estará determinado o:
        ESCOPO
        engloba os aspectos que podem ser modificados e projetados durante o desenvolvimento
        apresenta as restrições para o sistema a ser desenvolvido
  3. Definir o Limite do Contexto
    1. Quais aspectos tem alguma relação com o sistema a ser desenvolvido e quais fazem parte do ambiente irrelevante?
      1. não é necessário e é impossível uma definição completa e precisa do limite do do contexto , ou seja, determinar se aspectos isolados do ambiente influenciam ou são influenciados pelo sistema
  4. Identificar interfaces (interações) do sistema com seu ambiente
    1. Fontes - fornecem dados de entrada (inputs) ao sistema. Ex.: grupos de stakeholders;
    2. Destinos - recebem dados de saída (outputs) . Ex.: processos e sistemas;
  5. Zona cinzenta
    1. frenquentemente o limite do sistema não é definido até o final da ER
    2. limite do sistema e o contexto não está claro
  6. Documentar o Contexto do Sistema
    1. 1. Diagrama de Casos de Uso (Jacobson, 1992)
    2. 2. Diagrama de Fluxo de Dados (DeMarco, 1978)
    3. 3. Diagrama de Classes UML (OMG 2007)
3. Elicitar Requisitos
1. Fontes de Requisitos
  1. 1. Stakeholders
    1. Gerenciar stakeholders mantendo uma planilha com dados referentes a pessoa e ao projeto
    2. Transformar stakeholders que antes eram apenas afetados pelo projeto em colaboradores
    3. Acordos individuais - permite contornar situações desgastantes e formalizar acordos, responsabilidades, canais para feedback
  2. 2. Documentos
  3. 3. Sistemas em operação
2. 3.1.2 Lidar com os Stakeholders no Projeto
  1. Direitos e deveres do Engenheiro de Requisitos:
    1. 1. Falar a linguagem dos stakeholders;
    2. 2. Familiarizar-se inteiramente com o domínio da aplicação;
    3. 3. Criar documento de requisitos;
    4. 4. Ser capaz de apresentar resultados de trabalho (diagramas; gráficos);
    5. 5. Manter um relacionamento respeitoso com os stakeholders;
    6. 6. Apresentar suas ideias e alternativas bem como seus resultados;
    7. 7. Permitir que os stakeholders demandem propriedades do sistema que venham a simplificar e facilitar a utilização;
    8. 8. Assegurar que o sistema atenda as exigências funcionais e de qualidade dos stakeholders;
    9. 9. Planejar e organizar os canais de comunicação;
    10. 10. Elaborar cronograma com as atividades de requisitos junto com os stakeholders;
  2. Direitos e deveres dos Stakeholders
    1. 1. Introduzir o Engenheiro de Req. no domínio da aplicação;
    2. 2. Suprir o Engenheiro de req. com requisitos;
    3. 3. Documentar cuidadosamente os requisitos;
    4. 4. Tomar decisões em tempo hábil; (HA-HA-HA)
    5. 5. Respeitar as estimativas de custo e viabilidade feitas pelo Engenheiro de Req;
    6. 6. Priorizar requisitos;
    7. 7. Inspecionar os requisitos que o Engenheiro de Req. documentou;
    8. 8. Comunicar imediatamente a mudança de requisitos;
    9. 9. Aderir ao processo de mudança previamente determinado;
    10. 10. Respeitar o processo de ER implantado;
3. 3.2 Categorização de Requisitos conforme o Modelo de Kano
  1. (1) Fatores BÁSICOS de satisfação (dissatisfiers) - conhecimentos subconscientes
    1. São propriedades evidentes e pressupostas que o sistema deve ter e sem as quais o cliente ficará insatisfeito
    2. Técnicas de observação e centradas em documentos
  2. (2) Fatores ESPERADOS de satisfação (satisfiers) - conhecimento consciente
    1. São propriedades explicitamente exigidas do sistema.
    2. Técnicas de Pesquisa
  3. (3) Fatores INESPERADOS de satisfação (delighters) - conhecimento inconsciente
    1. o stakeholder surpreende-se positivamente ao utilizar o sistema
    2. Técnicas de criatividade
4. 3.3 Técnicas de Elicitação
  1. Influenciam na escolha da técnica de elicitação:
    1. 1. a distinção entre req. conscientes, subconscientes e inconscientes a serem elicitados;
    2. 2. as restrições referentes a tempo, orçamento e disponibilidade dos stakeholders;
    3. 3. a experiência do Engenheiro de Req. com a técnica;
    4. 4. oportunidades e riscos do projeto;
  2. Técnicas de Pesquisa
    1. 1. Entrevista - o Engenheiro de Req. faz perguntas e documenta as respostas;
      1. Prós: perguntas bem pensadas são capazes de revelar req. subconscientes e extraí respostas completas para requisitos;
      2. Contras: muito tempo consumido;
    2. 2. Questionário - útil quando há um grande nº de participantes;
      1. Prós: podem elicitar grande nº de informações em curto tempo e baixo custo;
      2. Contras: exige elevado domínio sobre o assunto e não permite retroalimentação imediata para adaptar e corrigir perguntas mal formuladas;
  3. Técnicas de Criatividade
    1. Servem para desenvolver req. inovadores ou esboçar uma visão inicial e fatores inesperados de satisfação
    2. 1. Brainstorming (recomendada para grupos) - coletar ideias -> documentar -> discutir -> analisar
      1. Prós: permite o surgimento de soluções e coletar muitas ideias em curto tempo;
      2. Contras: não é tão eficaz qndo a dinâmica é confusa ou os participantes muito dominantes
    3. 2. Brainwriting / 6-3-5 ( + eficaz quando há pessoas muito dominantes)
      1. Seis participantes escrevem 3 ideias em uma folhas -> folha repassada -> participantes comentam e desenvolvem as ideias -> processo se repete 5 vezes;
    4. 3. Brainstorming Paradox
      1. Identifica riscos e medidas preventivas através de ideias coletadas sobre eventos que não devem acontecer
    5. 4. Mudança de Perspectiva (ex.: Método dos 6 chapéus) - abordar o problema dobre diferentes perspectivas
      1. Prós: benéfico qndo o stakeholder está preso a opiniões;
      2. Contras: se os requisitos exigem elevado grau de detalhamento a utilização dessa técnica torna o processo exaustivo
    6. 5. Técnica de Analogia (biônica/ bissociação)
      1. problemas do projeto são comparados a uma situação análoga que acontece na natureza (biônico) ou não (bissociação)
      2. Contras: exigem muito tempo e conhecimento sobre o tema sobre o qual a analogia será feito
  4. Técnicas Baseadas em Documentos
    1. permite elicitar sistemas legados e deve ser combinada co m outras técnicas para identificar novos requisitos
    2. 1. Arqueologia do Sistema - pode ser feita a partir de doc. ou códigos do sistema legado
      1. Prós: permite identificar funcionalidade do sistema legado
      2. Contras: exige muito trabalho e tempo
    3. 2. Leitura baseada em perspectiva - um qndo documentos exigem uma perspectiva específica (ex: de um testador)
    4. 3. Reutilização - req. previamente compilados e atualizados conforme um padrão
  5. Técnicas de Observação
    1. Prós: próprias para stakeholders sem disponibilidade ou que não conseguem se expressar de forma clara; facilita a proposta de melhorias; elicitar fatores básicos de satisfação e facilita o conhecimento da linguagem
    2. 1. Observação de Campo - o Engenherio de Req. acompanha e documenta os processos observados, formulando, em seguida, os requisitos;
    3. 2. Aprprenciting - o Engenheiro de req. atua como um aprendiz do stakeholder
  6. Técnicas de Apoio
    1. compensam eventuais pontos fracos da técnica selecionada
    2. 1. Mapas mentais para Braisntormings;
    3. 2. Workshops;
    4. 3. Class Responsability Collaboration (CRC) - fichas de arquivo
    5. 4. Gravações de áudio e vídeo
    6. 5. Modelagem de casos de uso
    7. 6. Protótipos
4. Documentar Requisitos
1. Objetivos
  1. 1. Estruturar a vasta qtdade de requisitos
  2. 2. Facilitar a compreensão para a vasta compreensão para não envolvidos no projeto
  3. 3. Facilitar a localização e mudança de requisitos
2. perspectivas dos requisitos
  1. 1. Perspectiva estrutural
    1. - dados de entrada e saída
    2. - relações de dependência entre o sistema e o contexto
  2. 2. Perspectiva Funcional
    1. - dados que são recebidos e processados;
    2. - ordem de execução das funções
  3. 3. Perspectiva Comportamental
    1. - reações do sistema frente a eventos
    2. - condições que justificam transições de estados
3. Documentação de Req. usando Linguagem Natural
  1. é mais usada na prática; prosa livre
  2. Prós: fácil compreensão pelo stakeholder; pode ser usada para diferentes finalidades;
  3. Contras: pode resultar em ambiguidade; dificulta separa os tipos de requisitos
4. Documentação de Req. usando Modelos Conceituais
  1. Prós: + compacto; compreensão fácil; menor grau de ambiguidade;
  2. Contras: exigem conhecimento específico da modelagem ; não podem ser utilizados universalmente; retratam somente uma perspectiva;
5. Tipos de diagramas importantes
  1. 1. Diagrama de casos de uso - visão geral das funções do sistema
  2. 2. Diagramas de Classes - modelagem estrutural dos dados
  3. 3. Diagrama de Atividades - sequência de atividades
  4. 4. Diagrama de estados - transição de estados desencadeados por eventos
6. Documentação híbrida de requisitos
  1. combinação da linguagem natural e modelos conceituais para amparar as desvantagens e a associar as vantagens
7. Estrutura Padronizada de Documento (3 + amplamente utilizadas)
  1. Rational Unified Process (RUP)
    1. método orientado a objetos
    2. utilizada estrutura de especificação de requisitos (SRS)
  2. IEEE Standard 830 - 1998
    1. estrutura padrão sugere dividir o doc. em 3 capítulos:
      1. Introdução - ex.: metas do sistema / limites do sistema
      2. Descrição Geral - ex.: características dos usuários restrições do desenvolvimento;
      3. Requisitos Específicos - ex.: requisitos funcionais, de qualidade;
  3. Modelo V - define diferentes estruturas de acordo com o autor do documento de requisitos
    1. Especificação de Req. do Cliente ou Caderno de Encargos - é criado pelo contratante e descreve :
      1. O que é feito.
      2. Para que algo é feito.
    2. Especificação de Req. do Sistema ou Caderno de Obrigações - se baseia no caderno de encargos e descreve como concretizar os requisitos e as restrições do caderno de encargos.
8. Uso do documento de requisitos
  1. 1. Planejamento (definição de marcos)
  2. 2. Projeto arquitetônico
  3. 3. Implementação
  4. 6. Gerenciamento do Contrato
  5. 4. Teste
  6. 5. Gerenciamento da Mudança
  7. 7. Uso e Manutenção do Sistema
9. Critérios de Qualidade para Documento de Requisitos
  1. 1. Não ambiguidade e consistência (IEEE 830) - não contradição dos req. individuais
  2. 2. Estrutura clara / leitura seletiva
  3. 3. Modificabilidade e extensibilidade (IEEE 830) - conteúdo e estrutura devem facilitar mudanças
  4. 4. Completude (IEEE 830) - inputs, fluxos de exceção, req. de qualidade, gráficos, referências contribuem para a completude
  5. 5. Rastreabilidade (IEEE 830)
10. Critérios Formais (IEEE 830) e critérios que aumentam a aceitação por parte do leitor
  1. 1. Acordado - validado pelo stakeholddder
  2. 2. Priorizado (IEEE 830)
  3. 3. Não ambíguo (IEEE 830)
  4. 4. Válido e atualizado
  5. 5. Correto (IEEE 830) - assegurar a compreensão do stakeholder
  6. 6. Consistente (IEEE 830) - não se contradiz
  7. 7. Verificável (IEEE 830) - pode ser testado ou mensurado
  8. 8. Realizável - desenvolvedor participa da definição do req.
  9. 9. Rastreável (IEEE 830)
  10. 10. Completo (IEEE 830)
  11. 11. Compreensível
11. 2 regras fundamentais que aprimoram a legibilidade dos requisitos
  1. 1. Frases e parágrafos curtos (até 7 frases)
  2. 2. Formular 1 req. por frase - voz ativa
12. Glossário - é uma coleção de definições para termos apresentando os seguintes elementos:
  1. Termos técnicos específicos do contexto;
  2. Abreviações e acrônimos;
  3. Conceitos do dia-a-dia com sentido específico no dado contexto;
  4. sinônimos - termos que possuem mesmo significado
  5. homônimos - idêntico mas com sentidos diferentes
5. Documentar Requisitos usando Linguagem Natural
1. Prós: não exige (supostamente) tempo de preparo para ser lido e compreendido; Aplicação universal;
2. Contras: não tem estrutura formal; podem gerar ambiguidade devido a interpretações motivadas pelas diferentes 'bases de conhecimento' de cada leitor.
  1. Para minimizar essas desvantagens devem ser usados templates de requisitos e observar os efeitos transformacionais da linguagem nos requisitos
    1. 5 Efeitos transformacionais + relevantes para ER
      1. 1. Nominalização - termo resumido de um processo complexo;
      2. 2. Substantivos sem indicador de referência - ex.: o sistema deve apresentar os dados de faturamento para o usuário - quais dados? que usuário?
      3. 3. Quantificadores universais - ex.: o sistema deverá mostrar todos os conjuntos de dados em cada menu;
      4. 4. Condições específicas de forma incompleta - qndo é especificado somente o comportamento para caso a condição seja atendida e é esquecida o tratamento para a exceção
      5. 5. Verbos de processo especificados de forma incompleta - deve ser detalhada as condições necessárias para atendimento do processo e evitar a voz passiva. Ex.:Para logar um usuário os dados de login são inseridos. Deveria ser: o sistema deverá permitir ao usuário inserir login e senha usando o teclado do terminal.
6. Documentar Requisitos Usando Modelos
1. Prós: compreensão mais rápida devido as descrições gráficas (imagens);
2. Modelos - para cada perspectiva existe a linguagem de modelo conceitual adequada
7. Validar e Negociar Requisitos
1. Assegurar que os requisitos documentados atendam aos critérios de qualidade previamente determinados
2. Técnicas para validação de requisitos
  1. 1. Parecer de especialista - revisão de um colega;
  2. 2. Inspeção - processo rigoroso com papéis determinados;
  3. 3. Walkthrought - mais 'light' que inspeção, discussão das falhas de qualidade identificadas em uma sessão em grupo
  4. 4. Leitura baseada em perspectiva
  5. 5. Validação por protótipos
  6. 6. Checklist
8. Gerenciar Requisitos
1. Objetivos
  1. 1. Assegurar a constante disponibilidade de req. e informações relevantes durante todo o ciclo de vida do produto
  2. 2. Estrutura as informações relevantes de forma apropriada
  3. 3. Assegurar o acesso seletivo a essas informações
2. Técnicas das seguintes categorias
  1. 1. Designar atributos aos requisitos;
  2. 2. Priorizar requisitos;
  3. 3. Rasteabilidade de requisitos;
  4. 4. Versionamento de Requisitos
  5. 5. Gerenciamento das mudanças de Requisitos
9. Apoio por Ferramenta
1. Ferramentas apoiam a tarefa do ER de armazenar as informações de forma a satisfazer os critérios de qualidade para o gerenciamento de requisitos.
2. Se diferenciam de acordo com as funcionalidade oferecidas
  1. 1. Ferramentas profissionais pra gerenciamento de requisitos;
    1. A escolha deve ser cuidadosa para não impactar desnecessariamente o processo de introdução da ferramenta
  2. 2. Ferramentas de modelagem e padrão de escritório (ex.: word e excel)

Next up

CPRE-FL (Fundamentos da Engenharia de Requisitos)

Description

Resource summary

Similar

	Created by Marcia Alvarenga about 7 years ago