O Guia Mais Completo para Gerenciamento de Requisitos e Rastreabilidade

Os requisitos devem possuir qualidade para que o projeto seja bem-sucedido. Ao definir padrões e condições, as equipes podem avaliar seu progresso para atingir essas metas. As métricas usadas serão diferentes dependendo do trabalho que está sendo feito; no entanto, alguns indicadores gerais para requisitos de rastreamento incluem:

Cobertura de teste - Quantas das funções de cada sistema foram testadas?
Precisão da avaliação - Existe um alto grau de correção nas especificações?
Integralidade da Funcionalidade – Todas as áreas de funcionalidade estão especificadas com detalhes suficientes?
Clareza dos Critérios de Aceitação - Os critérios de aceitação do usuário podem ser facilmente identificados na documentação?
Pedidos de mudança - Quantos pedidos de mudança foram arquivados desde que as especificações foram escritas?

Ao medir regularmente esses fatores qualitativos, você poderá identificar onde sua equipe precisa concentrar seus esforços e melhorar a qualidade de seus projetos.

Como Medir a Qualidade dos Requisitos

Por que é importante avaliar a qualidade dos requisitos?

Devemos primeiro determinar se temos um problema de requisitos e quão grande é um problema para calcular com precisão a quantidade de esforço necessária para transformar nossos recursos insuficientes em recursos satisfatórios.
Como supervisores, nos esforçamos para garantir que nossa equipe esteja trabalhando de forma produtiva ao construir uma especificação de requisitos ou conduzir uma análise de requisitos. Eles estão atingindo seus objetivos?
Levando em consideração os diversos cenários, estabelecemos um benchmark para nossas especificações de requisitos quanto ao valor de uma métrica de critérios de qualidade. Definimos quatro valores para refletir cada situação, respectivamente:
- Elaborar um romance original em um ambiente difícil não é tarefa fácil.
- Elaborar uma narrativa inovadora sem qualquer pressão ou limitação.
- desenvolvimento mundano
- Aquisição de itens não relacionados ao desenvolvimento
Para garantir a mais alta qualidade para nossos projetos, estabelecemos uma referência para entradas de Revisão de Requisitos de Sistema e Revisão de Requisitos de Software.

Quando se trata de métricas de engenharia, uma métrica de qualidade de requisitos é uma das ferramentas mais poderosas disponíveis. Afinal, historicamente falando, desenvolver algo diferente do que se pretendia inicialmente tem sido um problema comum para os engenheiros. Embora o uso de um padrão objetivo não garanta sempre resultados perfeitos, ele pode reduzir drasticamente os possíveis riscos e falhas no produto final.

Tamanho do produto

Compreender o número de requisitos em um projeto é essencial. Isso pode ser feito por meio de casos de uso, requisitos funcionais, histórias de usuários, descrições de recursos, tabelas de resposta a eventos ou modelos de análise. No entanto, a escolha de sua equipe para representar esses requisitos não afeta de forma alguma sua função principal – implementar comportamentos do sistema com base em condições específicas e necessidades funcionais.

Comece seu processo de avaliação de requisitos contando os requisitos funcionais individuais alocados para um lançamento de produto ou iteração de desenvolvimento. Se vários indivíduos não conseguem obter resultados semelhantes quando contam, é essencial levar em consideração outros tipos de mal-entendidos e ambiguidades que possam surgir no futuro. Você precisa estar ciente do número de requisitos que compõem um release para acompanhar com precisão o progresso de sua equipe. Sem esse conhecimento, você não terá como avaliar quando terminar o projeto! Ficar de olho em quanto trabalho ainda resta em sua lista de pendências garante que todos entendam o que precisa acontecer antes da conclusão.

Para garantir que seus requisitos funcionais sejam uma medida precisa do tamanho do sistema, é essencial que os analistas os criem em um nível consistente de detalhes. Uma ótima maneira de fazer isso é dividir os requisitos de alto nível em componentes filhos menores que podem ser testados individualmente. Em outras palavras, os testadores devem projetar testes simples que estabelecerão se cada requisito foi implementado corretamente ou não. Isso garante que todas as tarefas exijam a mesma quantidade de esforço de implementação e teste, independentemente de sua complexidade. Para garantir que os desenvolvedores e testadores possam implementar e testar adequadamente cada requisito, é importante acompanhar quantos requisitos filhos existem. Outros métodos de dimensionamento alternativos incluem pontos de caso de uso e pontos de história, que medem o esforço estimado necessário para um pedaço de funcionalidade particularmente definido.

Embora os requisitos funcionais sejam essenciais, os não funcionais também não podem ser negligenciados. Essas demandas específicas exigem uma maior quantidade de esforço para projetar e implementar de forma eficaz. Certas funcionalidades dependem das necessidades não funcionais listadas, como questões de segurança, que devem ser representadas no tamanho estimado para recursos funcionais. No entanto, todos os desejos não funcionais não aparecerão aqui - é fundamental levar em consideração a influência deles em sua estimativa! Considere as seguintes situações:

Fornecer vários caminhos para usar um determinado recurso aprimora a experiência do usuário; no entanto, tal empreendimento requer mais tempo e energia dos desenvolvedores do que se apenas um método de acesso estivesse disponível.
Mesmo se você não estiver implementando novos recursos de produto, restrições de design e implementação forçadas, como interfaces externas para acomodar um ambiente operacional existente, podem aumentar significativamente a quantidade de trabalho de interface necessária.
Para garantir o desempenho máximo, algoritmo meticuloso e trabalho de design de banco de dados podem ser necessários para garantir respostas rápidas.
Para atender a requisitos rigorosos de disponibilidade e confiabilidade, é necessário construir mecanismos de failover e recuperação de dados que podem ser demorados. Além disso, a arquitetura do sistema que você escolher também pode ser afetada por essas demandas.

Ao acompanhar o aumento dos requisitos ao longo do tempo, independentemente da métrica de tamanho usada, você obterá insights úteis. Meu cliente percebeu que seus projetos geralmente aumentavam cerca de XNUMX% antes da entrega. Além disso, a maioria de seus projetos durou pelo menos XNUMX% a mais do que o esperado! Nenhuma coincidência aqui - é claro que há uma conexão entre essas duas tendências.

Requisitos Qualidade

Reserve algum tempo para medir a qualidade de seus requisitos realizando inspeções neles. Documente todos os defeitos que encontrar e divida-os em diferentes categorias, como requisitos ausentes, incorretos, desnecessários, imprecisos etc. Depois, analise esses tipos de defeitos junto com sua causa raiz para que as solicitações futuras sejam feitas corretamente do início ao fim. Use esses dados como uma oportunidade de melhoria para aumentar a eficiência do seu processo de requisitos! Por exemplo, se você determinar que os requisitos ausentes geralmente são um problema recorrente, seus métodos de elicitação precisam ser alterados. É possível que seus analistas de negócios não estejam perguntando o suficiente ou as perguntas corretas, ou talvez você precise envolver representantes de usuários ainda mais adequados no processo de desenvolvimento de necessidades.

Se a equipe sentir falta de tempo ao examinar toda a documentação de requisitos, uma opção mais eficiente é inspecionar algumas páginas e calcular a densidade média de defeitos – o número de defeitos por página de especificação. Supondo que essa amostra reflita com precisão todo o documento (o que pode ser uma suposição e tanto), multiplicá-la por páginas não inspecionadas pode nos dar uma estimativa de quantos bugs ocultos podem permanecer em nossas especificações. Inspetores inexperientes podem não ser capazes de detectar todos os defeitos, portanto, use o número estimado de falhas não detectadas como uma estimativa mínima. Ao usar a amostragem de inspeção, você pode avaliar a qualidade do documento e decidir se é financeiramente viável inspecionar o restante da especificação de requisitos – o que, sem dúvida, será sim!

Além disso, os defeitos de requisitos de registro descobertos após o estabelecimento da linha de base. Esses problemas teriam passado despercebidos durante o controle de qualidade durante o desenvolvimento dos requisitos. Calcule a taxa de sucesso de sua equipe em encontrar esses erros neste estágio inicial – será muito mais econômico do que tentar corrigi-los quando o design e a codificação já tiverem sido concluídos!

Os dados de inspeção podem fornecer duas métricas altamente valiosas: eficiência e eficácia. A eficiência quantifica o número médio de defeitos detectados por hora de trabalho, enquanto a eficácia indica a proporção de todas as falhas existentes que foram identificadas por meio de inspeção – uma medida que dá uma indicação do sucesso de suas inspeções (ou outras práticas de garantia de qualidade). A eficiência permite estimar o custo de descobrir um defeito por meio de inspeção. Você pode pesar esse custo em relação ao valor gasto no tratamento de defeitos em requisitos que são encontrados posteriormente no desenvolvimento ou após a entrega, permitindo determinar se a melhoria da qualidade de seus requisitos vale a pena financeiramente.

Status de requisitos

Para ficar por dentro do projeto, acompanhe cada requisito ao longo de sua vida útil. Você pode até atribuir um valor de atributo para armazenar essas informações para maior segurança e precisão. Esse tipo de rastreamento de status ajudará a reduzir o dilema comum com projetos de software – alegando falsamente que está “noventa por cento pronto”. Cada requisito deve ter um destes status durante um determinado período de tempo:

Defendeu (alguém apoiou vigorosamente)
O processo de aprovação foi bem-sucedido e a alocação foi colocada em uma linha de base.
Depois de elaborar, criar scripts e testar cuidadosamente o código, nós o implementamos.
Uma vez que o requisito foi submetido e aprovado em seus testes, verificou-se a integração bem-sucedida no produto.
Este requisito será cumprido em uma data posterior.
Você decide apagá-lo e não implementá-lo.
Dispensado (o conceito nunca recebeu luz verde)

Além das opções de status mencionadas, outros status podem ser considerados. Alguns podem optar por um status “Revisado” para validar seus requisitos antes de adicioná-los às configurações de linha de base. Como alternativa, as organizações podem usar “Entregue ao cliente” como um meio de verificar se liberaram o requisito intacto e correto.

Se você perguntar sobre o progresso de um desenvolvedor, ele pode responder que existem 87 requisitos para esse projeto específico. 61 já foram confirmados e 9 estão em vigor, mas ainda pendentes de verificação, enquanto 17 ainda precisam ser finalizados. No entanto, é importante observar que nem todas essas solicitações coincidem quando se trata de tamanho ou efeito na satisfação do cliente; eles também podem exigir diferentes quantidades de esforço. Como gerente de projeto, não tenho dúvidas de que tínhamos um entendimento preciso do tamanho do subsistema e de quão próximo ele estava da conclusão. Isso é muito mais eficaz do que simplesmente dizer “Estou cerca de noventa por cento pronto”. Com uma visão geral do progresso, posso dizer com confiança “está ótimo!”

Pedidos de mudança

Para obter um gerenciamento de requisitos bem-sucedido, sua organização deve atender a cada adição, exclusão e modificação de requisitos. Isso permitirá que você acompanhe o status, bem como as implicações de todas as solicitações de mudança. Você também pode usar esses dados para responder a várias perguntas de consulta, como:

Quantos pedidos de alteração foram feitos dentro do prazo designado?
Quantos dos pedidos foram atendidos e quantos permanecem sem solução?
Qual foi a taxa de aprovação dos pedidos e qual foi o percentual recusado?
Até que ponto a equipe gastou energia para executar cada modificação autorizada?
Qual é o período de tempo típico em que as solicitações permanecem abertas?
Em média, quantos itens (por exemplo, requisitos ou artefatos) são afetados por cada solicitação de mudança enviada?

Certifique-se de acompanhar todas as alterações feitas durante o processo de desenvolvimento após definir uma linha de base para cada versão. Lembre-se, uma solicitação de mudança pode afetar vários requisitos de diferentes tipos (orientados ao usuário, funcionais e não funcionais). Para avaliar quantas mudanças foram realizadas em um determinado período de tempo, divida o número de modificações pela quantidade total de requisitos anteriores a esse período (como ao definir sua linha de base).

Não queremos eliminar totalmente a volatilidade dos requisitos. Afinal, muitas vezes há uma justificativa legítima para alterá-los. Mas, ao mesmo tempo, temos que garantir que nosso projeto possa lidar com alterações e ainda cumprir suas obrigações. Aproximar-se da conclusão acarreta custos adicionais quando as alterações são feitas com frequência; isso torna difícil determinar quando você lançará seu produto no mundo! À medida que o desenvolvimento avança, a maioria dos projetos deve se tornar mais resiliente às mudanças; em outras palavras, a taxa de aceitação da mudança deve diminuir gradativamente até chegar a zero quando o release for finalizado. Uma abordagem iterativa oferece às equipes várias chances de incorporar melhorias em iterações posteriores, mantendo o controle da linha do tempo de cada ciclo.

Se sua equipe é inundada com solicitações de mudança, é provável que o processo de elicitação não tenha sido abrangente ou que as ideias continuem a surgir à medida que o projeto avança. Como tal, é essencial acompanhar de onde essas mudanças vêm de marketing, usuários, vendedores, equipes de gerenciamento, etc. Manter o controle dessas informações ajudará você a determinar quem e o que precisa de atenção para minimizar os requisitos negligenciados e evitar falhas de comunicação no caminho.

Quando as solicitações de alteração permanecem sem solução por um longo período de tempo, é uma indicação clara de que seu processo de gerenciamento de alterações precisa de alguma atenção. Eu testemunhei pessoalmente uma organização que tinha solicitações de aprimoramentos de vários anos e ainda pendentes. Para fazer com que o gerente de projeto priorize sua energia nos itens mais importantes do backlog, essa equipe deve atribuir solicitações abertas específicas a liberações de manutenção planejada e converter outras alterações adiadas de longo prazo em rejeitadas. Dessa forma, eles podem abordar com mais facilidade o que é essencial e urgente primeiro, antes de abordar assuntos menos urgentes.

Tempo e esforço

Para garantir o desempenho ideal, sugerimos fortemente que você registre a quantidade de tempo que sua equipe gasta em tarefas de engenharia de requisitos. Isso inclui elaborar requisitos de qualidade e gerenciar mudanças, acompanhar o progresso, criar dados de rastreabilidade e outras atividades relacionadas a esse processo.

Muitas vezes as pessoas me perguntam quanto tempo e energia devem ser dedicados às necessidades de um projeto. Essa resposta depende muito do tamanho, da equipe, da organização que a está construindo e de sua finalidade. Manter o controle de seus esforços investidos em tarefas críticas para projetos como esses pode ajudá-lo a planejar melhor os futuros com estimativas precisas.

Se sua equipe já concluiu um projeto e alocou 10% de seu tempo para os requisitos, refletindo, você deve ter notado que a qualidade desses requisitos poderia ser muito melhorada. Se confrontado com outro projeto semelhante, seria sensato para o gerente de projeto garantir mais esforço para criar especificações completas - mais de dez por cento do total de recursos disponíveis deve ser suficiente!

Conforme você coleta e analisa os dados, compare o esforço de desenvolvimento do projeto com uma medida do tamanho do produto. Seus requisitos documentados darão uma ideia de seu tamanho geral. Para ser mais preciso, você pode correlacionar o esforço para contar especificações individuais testáveis, pontos de caso de uso ou pontos de função – o que for proporcional às medições do seu produto. A referência à Figura 1 neste contexto fornece uma medida para avaliar os recursos de sua equipe de desenvolvimento, o que ajuda ainda mais a prever o conteúdo do lançamento, bem como o escopo com precisão! Ao coletar dados relacionados ao tamanho do seu produto e observar o esforço de implementação associado, você pode formular estimativas precisas em preparação para projetos futuros semelhantes.

O medo pode permanecer na mente de muitos; medo de que o desenvolvimento de um programa de medição de software roube um tempo valioso de tarefas essenciais. Pelo contrário, implementar um sistema métrico eficiente e direcionado não requer muito esforço ou energia. Tudo o que você precisa fazer é construir uma infraestrutura básica para coletar e analisar dados, além de incentivar os membros de sua equipe a registrar alguns detalhes relevantes sobre suas atividades de trabalho. Quando você cria uma cultura baseada em métricas dentro da sua empresa, é incrível o que se pode aprender com esse método!

Conclusão

A elicitação e análise de requisitos são componentes essenciais do desenvolvimento de software. Sem eles, um projeto pode falhar devido a especificações ausentes ou incorretas, levando a retrabalho dispendioso e resultados potencialmente insatisfatórios. Portanto, é importante garantir que você tenha um processo eficiente para coletar requisitos e verificar a precisão ao longo do cronograma do projeto. Com um gerenciamento adequado, as equipes podem obter sucesso criando requisitos detalhados que descrevem com precisão todas as funcionalidades desejadas, garantindo que nada seja esquecido. Ao avaliar os processos e métricas existentes regularmente em cada empreendimento, as equipes poderão entender melhor o que funciona melhor para elas ao buscar feedback do usuário durante os ciclos de desenvolvimento. Isso ajudará a manter os projetos no caminho certo e contribuir para resultados de maior qualidade.

Não se esqueça de compartilhar esta postagem!