Please enable JavaScript.
Coggle requires JavaScript to display documents.
UE 7 Validar e Acordar Requisitos (N2) (Técnicas de validação de…
UE 7 Validar e Acordar Requisitos (N2)
Validar e Negociar Requisitos
Possui o propósito de assegurar que os requisitos documentados atendem os critérios de qualidade previamente determinados
Fundamentos da Validação de Requisitos
Os requisitos são apresentados aos stakeholders com o propósito de identificar desvios entre os requisitos definidos e os desejos e necessidades reais dos stakeholders
Após a apresentação, se os requisitos forem aprovados serão usados nas demais atividades de desenvolvimento
O objetivo da validação de requisitos é descobrir erros nos requisitos documentados
Fundamentos da negociação de requisitos
Se não houver consenso entre os stakeholders a respeito dos requisitos, e se consequentemente os requisitos não puderem ser implementados coletivamente no sistema
Cria-se um conflito não somente entre os requisitos contraditórios, mas também entre os stakeholders que exigem requisitos contraditórios
A aceitação do sistema é ameaçada por conflitos não resolvidos, pois tais conflitos fazem com que os requisitos de pelo menos um grupo de stakeholders não possam ser implementados
Esses conflitos podem também servir de oportunidade para a engenharia de requisitos, pois conflitos entre stakeholders exigem uma solução que tem o potencial de ajudar a revelar novas ideias e apresentar diferentes opções para o desenvolvimento
O objetivo da negociação é chegar a uma compreensão comum e acordada dos requisitos do sistema a ser desenvolvido entre todos os stakeholders
A validação e negociação de requisitos é uma atividade a ser realizada (em graus variados de intensidade) ao longo de todos o processo de engenharia de requisitos
Aspectos de qualidade dos requisitos
Objetivos da validação:
Conteúdo
Todos os requisitos foram elicitados e documentados com o nível apropriado de detalhamento?
Documentação
Todos os requisitos foram documentados em conformidade com as diretrizes de documentação e especificação previamente determinadas?
Acordo
Todos os stakeholders concordam com os requisitos documentados e todos os conflitos conhecidos foram resolvidos?
Aspectos de qualidade
Conteúdo
A validação dos requisitos com respeito ao aspecto de qualidade "conteúdo" será considerada bem-sucedida uma vez aplicada nos seguintes tipos de erros sem que falhas significativas tenham sido detectadas
Completude (conjunto de todos os requisitos)
Todos os requisitos relevantes para a release foram documentados?
Completude (requisitos individuais)
Cada requisito contém todas as informações necessárias?
Rastreabilidade
Todos os relacionamentos relevantes de rastreabilidade foram definidos?
Exatidão/adequação
Os requisitos refletem acuradamente os desejos e necessidades dos stakeholders
Consistência
É possível implementar todos os requisitos definidos para o sistema conjuntamente? Não há contradições?
Nenhuma decisão de design prematura
Existem decisões antecipadas de design presentes nos requisitos que não sejam decorrentes de restrições?
Verificabilidade
É possível definir critérios de aceitação e teste com base nos requisitos? Os critérios foram definidos?
Necessidade
Cada requisito contribui para o cumprimento dos objetivos propostos
Documentação
Ignorar as diretrizes de documentação pode levar aos seguintes riscos, entre outros
Conformidade com o formato da documentação
Os requisitos estão documentados nos formatos previamente determinados?
Conformidade com a estrutura da documentação
A estrutura da documentação foi mantida?
Inteligibilidade
Todos os requisitos documentados podem ser compreendidos no contexto dado?
Não-ambiguidade
A documentação de requisitos permite uma única interpretação?
Conformidade com as regras de documentação
As regras e diretrizes de documentação previamente acordadas foram cumpridas?
Acordo
Abrange a verificação de eventual falta de acordo entre os stakeholders a respeito dos requisitos
Acordado
Todos os stakeholders relevantes estão de acordo com cada requisito?
Acordado após alteração
Todos os stakeholders estão de acordo com cada requisito após o mesmo ter sido alterado?
Conflitos resolvidos
Todos os conflitos conhecidos com respeito a requisitos foram resolvidos?
Princípios de validação de requisitos
Esses princípios asseguram que o maior número possível de erros nos requisitos possa ser identificados durante a validação
Envolvimento dos stakeholders corretos
A escolha depende dos objetivos da validação bem como dos requisitos a serem auditados
Recomenda-se evitar que o autor de um requisito também seja a pessoa a validar o requisito
Separação da busca de falhas da correção de defeito
Medidas para corrigir os erros somente serão tomadas depois que as medias de identificação tiverem sido concluídas
Dessa forma, os recursos disponíveis para a correção de erros podem ser utilizados de forma eficaz
A identificação prematura de erros não causa erros adicionais e nenhum erro é corrigido sem que haja necessidade para tal
Validação a partir de pontos de vista diversos
Os requisitos são validados e acordados por pessoas diferentes
Mudança adequada do tipo de documentação
Utiliza os pontos fortes de um tipo de documentação para compensar os pontos fracos de outros tipos de documentação
Transcrever um requisito já documentado em outro formato de documentação simplifica a identificação de erros
Construção de artefatos de desenvolvimento
Serve de base para criação de artefatos do projeto, artefatos de teste ou manual do usuário
Ao longo da validação, as atividades geralmente realizadas em fases subsequentes para construir os respectivos artefatos de desenvolvimento são executadas com pequenas amostras
Revalidação de requisitos
A validação de requisitos deveria ser realizada várias vezes nos seguintes casos
Grande quantidade de ideias e tecnologias inovadoras usadas no sistema
Acréscimo significativo de conhecimento durante a engenharia de requisitos
Projetos de longa duração
Validação de requisitos realizada muito cedo
Domínio desconhecido
Reutilização de requisitos
Técnicas de validação de requisitos
Essas técnicas podem ser parcialmente utilizadas em conjunto para validar da maneira mais ampla possível os requisitos, a partir de critérios de qualidade específicos
Parecer de especialista
O autor entrega seus requisitos para outra pessoa
A outra pessoa revisa o requisito com o objetivo de identificar problemas que prejudicam a qualidade do requisito, conforme critérios de qualidade previamente determinados
Inspeção
É realizada para verificar sistematicamente a presença de erros em artefatos de desenvolvimento através da aplicação de um processo rigoroso
Observação estrita do processo de inspeção previamente determinado
Preparação individual dos participantes
Separação entre identificação e correção de erros
Walkthrough
É menos severo do que uma inspeção e os papéis que o processo envolve são menos diferenciados entre si
Identificar falhas de qualidade nos requisitos por meio de um processo compartilhado, e proporcionar um conhecimento compartilhado dos requisitos entre todas as pessoas envolvidas
Logo após o walkthrough do documento de especificação de requisitos, está previsto realizar um walkthrough do protótipo de interface do usuário descrito no estudo de viabilidade do projeto
As técnicas acima podem fazer uso das seguintes técnicas adicionais
Leitura baseada em perspectiva
Os requisitos são verificados a partir de diferentes perspectivas
Perspectiva do usuário/cliente
Perspectiva do arquiteto de software
Perspectiva do testador
3 aspectos de qualidade também apresentam 3 possíveis perspectivas
Perspectiva do conteúdo
Perspectiva da documentação
Perspectiva do acordo
Validação por protótipos
Experimentar requisitos diretamente através de protótipos é o método mais eficaz para identificar erros em requisitos
Utilização de checklists
É um conjunto de perguntas e/ou afirmações sobre determinada circunstância
Pode ser aplicada sempre que muitos aspectos precisam ser considerados em um ambiente completo e que nenhum aspecto possa ser omitido
Recomenda-se elaborar a lista de verificação de tal forma que ela não seja mais longa do que uma página
Negociar requisitos
Para alcançar um acordo sobre os requisitos de um sistema a ser desenvolvido, é necessário identificar eventuais conflitos e resolver esses conflitos
Identificação de conflitos
Conflitos podem surgir ao longo de todas as atividades de engenharia de requisitos
Análise de conflitos
Durante esta fase, diversos tipos de conflitos de requisitos são identificados, sendo que cada um requer uma estratégia de resolução específica
Conflito de interesses
É caracterizado por interesses ou objetivos subjetiva e objetivamente diferentes entre stakeholders
Conflito de conteúdo
É caracterizado por uma falta de informações, por informações equivocadas ou por interpretações diferentes de alguma informação entre dois ou mais stakeholders
Conflito de valores
É caracterizado por divergências relacionadas a valores fundamentais entre os stakeholders
Conflito de relacionamento
É caracterizado por fortes emoções, conceitos estereotipados de relacionamentos, comunicação deficiente ou conduta interpessoal negativa entre stakeholders
Conflito estrutural
É caracterizado por níveis distintos de autoridade ou poder entre os stakeholders
Resolução de conflitos
A resolução de conflitos tem forte influência na disposição das pessoas envolvidas de continuarem a trabalhar juntos no projeto
É essencial envolver todos os stakeholders relevantes para a resolução de conflitos
Acordo
Todas as partes em conflito negociam uma solução para o conflito
Troca de informações, argumentos e opiniões entre si
Compromisso
Todas as partes envolvidas no conflito procuram chegar a um compromisso entre soluções alternativas
Consiste em uma composição de diferentes partes das soluções alternativas
Votação
Todas as partes envolvidas no conflito votam sobre soluções alternativas
Análise de alternativas
O sistema é desenvolvido de forma a permitir a definição de alternativas pela derivação de variantes, pela seleção de parâmetros que definem as variantes do sistema, ou pela seleção de propriedades variáveis de sistema
Manda quem pode
Um conflito é resolvido pela organização hierárquica
Isso significa que a parte do conflito em posição hierárquica superior ganha o conflito ao rejeitar as objeções das partes organizacionais inferiores
Obter mais informações
Todos os fatores influentes são investigados, de modo a coletar o máximo de informações possíveis sobre o conflito
Com base nos resultados dessa técnica, pode-se utilizar a técnica de resolução de conflitos "Análise de repercussões"
Análise de repercussões
Todas as repercussões positivas e negativas de uma determinada alternativa de solução são investigadas, permitindo assim sua avaliação
Matriz de decisão
Cria-se uma tabela com as soluções alternativas nas colunas e todos os respectivos critérios de decisão nas linhas
Para cada cruzamento entre um critério e uma solução alternativa, é feita uma avaliação com uma pontuação
A alternativa com a soma mais alta é considera a decisão
Documentação da resolução de conflitos
Uma resolução de conflito deve sempre ser documentada de forma rastreável
Enfrentar repetidamente os mesmos conflitos
Sem documentação apropriada da resolução do conflito, ele precisará ser novamente analisado e resolvido
Resolução inapropriada de conflitos
Sem documentação apropriada, informações relevantes que foram analisadas nas análises e resoluções iniciais correm o risco de serem esquecidas
Resumo
É necessário validar os requisitos com respeito a seu conteúdo e documentação
Determinar se os diferentes stakeholders chegaram a um acordo a respeito dos requisitos
Garantir que os requisitos atendam adequadamente aos desejos e ideias dos stakeholders
Pra validação de requisitos, é necessário identificar conflitos entre stakeholders, bem como analisar e resolver os mesmos de modo adequado