Please enable JavaScript.
Coggle requires JavaScript to display documents.
UE 8 - Gerenciar Requisitos (Gerenciamento de Mudanças de Requisitos…
UE 8 - Gerenciar Requisitos
O gerenciamento de requisitos refere-se tanto a requisitos individuais quanto a documentos completos
Designar atributos para requisitos
A documentação inclui: identificadores únicos, nome, autor e as fontes do requisito
Atributos para requisitos em linguagem natural e modelos
A maneira mais simples de definir atributos de requisito é através de uma estrutura tabelar (um template)
O template define as informações relevantes a serem documentadas
Esquema de atributos
É o conjunto de todos os atributos definidos para uma classe de requisitos
São geralmente customizados para atender às necessidades individuais do projeto
Tipos de atributos
Identificador único
Nome
Descrição
Estabilidade
Responsável
Origem
Autor
Prioridade
Versão
Criticalidade
Visualizações de requisitos
Para manter a complexidade dos requisitos dentro de limites manejáveis para os membros do projeto, é necessário acessar os requisitos de forma seletiva, dessa forma filtrando os requisitos de acordo com a tarefa atual
Visualizações seletivas da base de requisitos
Selecionar requisitos específicos
Ocultar certos atributos de requisitos
Combinar esses princípios de seleção de forma aleatória
Mostram um sub-conjunto de valores/atributos relacionados a requisitos selecionados a partir de critérios definidos
Visualizações consolidadas
Mostram informações consolidadas relacionadas a requisitos selecionados a partir de critérios definidos
Visualizações que contêm dados gerados ou consolidados
Podem ser definidas através da agregação de dados contidos na base de requisitos
Pode conter informações sobre o percentual de requisitos que se originam de uma fonte específica
Para avaliar determinada perspectiva não há mais necessidade de ler todo o documento
Não assegura que várias pessoas possam trabalhar com uma especificação ao mesmo tempo
Priorização de Requisitos
Os requisitos são priorizados em diferentes momentos, em diferentes atividades, e a partir de diferentes critérios
Método de Privatização de Requisitos
1 - Definir as metas e as restrições da priorização
2 - Definir os critérios de priorização
Curto de implementação
Risco
Prejuízo devido à implementação malsucedida
Volatilidade
Importância
Duração da implementação
3 - Determinar os stakeholders relevantes
Garante a disponibilidade do conhecimento especialista exigido durante o processo de priorização
4 - Selecionar os artefatos a serem priorizados
Os requisitos selecionados devem ser do mesmo nível de abstração
Técnicas de Privatização de Requisitos
Ranking
Diversos stakeholders selecionados ordenam os requisitos a serem priorizados de acordo com um critério específico
Top 10
Selecionam-se os "n" requisitos mais importantes para um critério definido
Classificação por critério único
Classificação de acordo com a importância da execução do requisito para o sucesso do sistema
Mandatory
Deve ser implementado a qualquer custo
Opcional
Não precisa necessariamente ser implementado
Nice-to-have
Não influenciam o sucesso do sistema se não forem implementados
Classificação Kano
DIssatisfiers (propriedades básicas de satisfação)
Obrigatoriamente deve possuir para ser lançado no mercado com sucesso
Satisfiers (propriedades esperadas de satisfação)
Determinam o grau de satisfação do cliente
Os clientes exigem de forma consciente a propriedade associada ao requisito
Delighters (propriedades inesperadas de satisfação)
Os clientes não exigem conscientemente determinada propriedade do sistema
A satisfação do cliente aumenta de forma exponencial
Matriz de priorização de Wiegers
É uma abordagem analítica
Determinar o peso ponderado do benefício, prejuízo, custo e risco
Determinar os requisitos a serem priorizados
Estimar o benefício relativo
Estimar o prejuízo relativo
Calcular os valores totais e percentuais de cada requisito
Estimar o custo relativo e calcular o percentual de custo de cada requisito
Calcular as propriedades dos requisitos individuais
Determinar a posição no ranking de prioridades de cada requisito
O grau de subjetividade nos resultados do processo de priorização pode ser significativamente reduzido
Rastreabilidade de requisitos
A rastreabilidade de um requisito é a possibilidade de rastrear os requisitos ao longo de todo o ciclo de vida do sistema
Vantagens
Verificabilidade
Verificar se um requisito foi implementado no sistema
Identificação de propriedades desnecessárias do sistema
Determinar se a propriedade contribui para a implementação de um determinado requisito no sistema
Identificação dos requisitos desnecessários
Requisitos que não contribuem para qualquer meta do sistema
Análise de impacto
Analisar os efeitos de eventuais mudanças nos requisitos
Reusabilidade
Artefatos de desenvolvimento que podem ser adaptados e/ou reutilizados no novo projeto de desenvolvimento
Determinação de responsabilidade
Permite a atribuição retroativa de esforços de desenvolvimento para um requisito
Manutenção
A causa e o efeito de falhas podem ser identificadas, os componentes do sistema que são afetados pela falha podem ser determinados e o esforço para corrigir o erro por trás da falha pode ser estimado
Rastreabilidade definida por finalidade
É praticamente inviável capturar todas as informações concebíveis que possibilitam a rastreabilidade dos requisitos ao longo do ciclo de vida do sistema
Somente as informações com um propósito claro para o desenvolvimento ou evolução do sistema devem ser registrados
Classificação de relacionamentos de rastreabilidade
Pré-especificação de requisitos
Abrange relacionamentos entre requisitos e aqueles artefatos que formam a base dos requisitos
Pós-especificação de requisitos
Envolve as informações entre requisitos e artefatos oriundos de atividades subsequentes de desenvolvimento
Entre requisitos
Envolve o mapeamento de dependências entre requisitos
Representação das rastreabilidades de requisitos
Referências textuais e hyperlinks
Consiste em anotar o artefato-alvo como uma referência textual no requisito ou estabelecer um hyperlink entre o artefato inicial e o artefato-alvo
Matrizes de rastreabilidade
Nas linhas constam artefatos inciais
Nas colunas os artefatos-alvo
Se existir um relacionamento entre os dois a célula em comum é marcada
São de difícil manutenção conforme aumenta o número de requisitos
Grafos de rastreabilidade
É um gráfico no qual todos os nós representam artefatos e todas as linhas representam relacionamentos entre artefatos
Versionamento de requisitos
Tem o objetivo de proporcionar acesso aos estados de desenvolvimento específicos de requisitos individuais ao longo do ciclo de vida do sistema
Versões de requisitos
Incremento: No caso de mudanças menores ao conteúdo, o número do incremento é aumentado por 1
Exemplo: 0.1 - 0.2
Versão: Se ocorrerem mudanças maiores, o número da versão é aumentado.
Exemplo: 1.3 - 2.0
É possível distinguir entre o identificador da versão, o identificador do incremento e identificador do sub-incremento (v1.2.12)
O número da versão de um requisito possui no mínimo 2 componentes
Configurações de requisitos
É um conjunto definido de requisitos logicamente conectados entre si
Não deve conter mais de uma versão de cada requisito
Dimensão "produto"
Lida com requisitos individuais dentro da base de requisitos
Dimensão "versão"
Considera os vários estados de desenvolvimento como parte do gerenciamento de versões dentro da dimensão "produto"
Não precisa conter uma versão de cada requisito sendo considerado na dimensão "produto"
Coesão lógica entre os requisitos
Os requisitos foram agrupados em uma configuração em comum, orientada para um objetivo específico
Consistência dos requisitos
Contém requisitos livres de contradições em suas respectivas versões
Identificação dos requisitos
Possui um identificador único
Inalterabilidade dos requisitos
Se ocorrer alguma mudança nos requisitos de uma configuração, o resultado será uma nova versão dos requisitos e possivelmente da configuração
Possibilidade de retorno a versões anteriores da base de requisitos (rollback)
As configurações oferecem a possibilidade de retornar os requisitos para uma versão específica dentro de uma configuração
Uma configuração correta de requisitos deve ocorrer a cada versão do requisito selecionado
Baselines de requisitos
Consistem de versões estáveis de requisitos, muitas vezes também definindo uma etapa de desenvolvimento de um sistema
São geralmente visíveis externamente
Base para o planejamento de releases
São configurações de requisitos "estáveis", especialmente marcados para o cliente
Estimativa do esforço envolvido com a implementação
Isso pode ser feito estimando o esforço parcial para implementar um requisito da baseline e somando o esforço total para o restante da baseline
Comparação com produtos concorrentes
Utilizados para comparar o sistema planejado com sistemas concorrentes
Gerenciamento de Mudanças de Requisitos
Requisitos mudam ao longo de todo o desenvolvimento e ciclo de vida do sistema
Isso significa que novos requisitos são acrescentados e requisitos existentes são modificados ou removidos
Mudanças nos requisitos
Derivam diretamente de erros nos requisitos ou de requisitos incompletos, a evolução do próprio contexto pode exigir a mudança de requisitos
Indica que os stakeholdes estão acompanhando o sistema atentamente e aprendendo cada vez mais sobre suas funções, qualidade e restrições
Uma alta frequência de mudanças é um indicativo de uma execução inadequada das atividades de engenharia de requisitos
Comitê de Controle de Mudanças
Tanto a avaliação de mudanças de requisitos quanto a decisão sobre a execução de determinada mudança são geralmente responsabilidade de um comitê de controle de mudanças
Estimar o esforço para executar a mudança
Avaliar solicitações de mudanças
Definir as mudanças de requisitos ou novos requisitos
Aceitar ou rejeitar as solicitações de mudanças
Classificar as solicitações de mudanças recebidas
Priorizar as solicitações de mudanças aceitas
Alocar as solicitações de mudanças aceitas para projetos de modificações
Composição do comitê
Gerente de mudanças (Coordenador)
Cliente
Arquiteto
Desenvolvedor
Gerente de configuração
Representante do cliente
Gerente do produto
Gerente do projeto
Representante da garantia de qualidade
Engenheiro de requisitos
A Solicitação de Mudança
Documenta a mudança desejada e contém informações adicionais para o gerenciamento da solicitação de mudança
Identificador
Título
Descrição
Justificativa
Data da solicitação
Solicitante
Prioridade
Classificação das solicitações de mudanças recebidas
Corretiva de requisito
Se for uma falha do sistema durante sua operação, sendo que essa falha pode ser atribuída a um erro nos requisitos
Implementadas de forma relativamente rápida
Adaptativa de requisito
Se uma mudança exige uma complementação ao sistema
São geralmente processadas em lotes, assim que a próxima release estiver iminente
Excepcional (hotfix)
Mudança precisa ser feita imediatamente a qualquer custo
Podem ser tanto corretivas quanto adaptativas
Método básico para mudanças corretivas e adaptativas
Todos os requisitos afetados pela mudança são selecionados
Os artefatos posteriores de desenvolvimento que eventualmente terão de ser modificados ou novamente desenvolvidos são identificados
Para cada artefato afetado o esforço para implementar a mudança é determinado, sendo o esforço total para a mudança calculado a partir da soma de todos os esforços parciais
Resumo
O gerenciamento de requisitos é uma atividade central da engenharia de requisitos
Assegura a constante disponibilidade dos requisitos documentados
Estrutura essas informações de forma apropriada
Assegura o acesso seletivo a essas informações
Técnicas do gerenciamento de requisitos
Designar atributos aos requisitos
Priorizar requisitos
Rastreabilidade dos requisitos
Versionamento de requisitos
Gerenciamento das mudanças de requisitos