Qualidade dos Requisitos de Software

A qualidade dos requisitos é uma questão de discussão entre os profissionais de requisitos de software. Aqui estão quatro visões consideradas sobre a qualidade dos requisitos de software. um bom requisito ou um bom conjunto de requisitos.

Por que a qualidade dos requisitos é importante?

Muitas vezes é útil olhar as coisas ao contrário. Pergunte a si mesmo: qual é o impacto de ter requisitos inadequados? Este gráfico ilustra que há um aumento não linear no retrabalho causado por requisitos inadequados.

O custo dos requisitos de software de baixa qualidade na geração de retrabalho
Uma comparação de atributos de qualidade dos requisitos de acordo com diferentes fontes:

Nossa visão

Recomendamos algo muito próximo do IIBA BABOK como segue

  • Claro: significado funcional inequívoco.
  • Conciso: não contém conteúdo estranho e desnecessário.
  • Orientado ao usuário: concentra-se no que o usuário precisa alcançar.
  • Completo: ambos concluídos internamente (todas as etapas funcionais dentro de um requisito) e como um conjunto, todos os eventos CRUD cobertos
  • Consistente: os nomes de usuários e objetos são consistentes em todo um conjunto de requisitos
  • Mensurável: pode ser dimensionado em pontos de função COSMIC
  • Testável: Se for mensurável, geralmente também é testável.
  • De valor : é necessário para fornecer recursos essenciais ao usuário.
  • Sem design: exclui “como” deve ser implementado.
  • Exclusivo: nenhuma funcionalidade duplicada em todo o conjunto de requisitos

E a visão geral do IIBA sobre qualidade de requisitos diz o seguinte:

Embora a qualidade seja, em última análise, determinada pelas necessidades das partes interessadas que utilizarão os requisitos ou os projetos, os requisitos de qualidade aceitáveis apresentam muitas das seguintes características”

  • Atômico: independente e capaz de ser compreendido independentemente de outros requisitos ou designs.
  • Completo: suficiente para orientar o trabalho futuro e no nível de detalhe apropriado para que o trabalho continue. O nível de integralidade exigido difere com base na perspectiva ou metodologia, bem como no ponto do ciclo de vida em que o requisito está sendo examinado ou representado.
  • Consistente: alinhado com as necessidades identificadas das partes interessadas e não conflitante com outros requisitos.
  • Conciso: não contém conteúdo estranho e desnecessário.
  • Viável: razoável e possível dentro do risco, cronograma e orçamento acordados, ou considerado viável o suficiente para investigação adicional por meio de experimentos ou protótipos.
  • Inequívoco: o requisito deve ser claramente declarado de forma a deixar claro se uma solução atende ou não à necessidade associada.
  • Testável: capaz de verificar se o requisito ou projeto foi atendido. Os níveis aceitáveis de verificação do cumprimento dependem do nível de abstração do requisito ou design.
  • Priorizado: classificado, agrupado ou negociado em termos de importância e valor em relação a todos os outros requisitos.
  • Compreensível: representado usando terminologia comum do público.

A seção 4.3 da IEEE Std 830 fornece uma lista de atributos de qualidade desejados de uma especificação de software, que são:

“Um SRS deve ser:

  1.  Correto;
  2. Inequívoco;
  3. Completo;
  4. Consistente;
  5. Classificado por importância e/ou estabilidade;
  6. Verificável
  7.  Modificável;
  8. Rastreável.”

Características dos Requisitos Testáveis Para que os requisitos sejam considerados testáveis, os requisitos idealmente devem ter todas as seguintes características: Visão Geral dos Testes Baseados em Requisitos 8

1. Determinístico: Dado um estado inicial do sistema e um conjunto de entradas, você deve ser capaz de prever exatamente quais serão as saídas.

2. Inequívoco: Todos os membros do projeto devem obter o mesmo significado dos requisitos; caso contrário, eles são ambíguos.

3. Correto: As relações entre causas e efeitos estão descritas corretamente.

4. Completo: Todos os requisitos estão incluídos. Não há omissões.

5. Não redundante: Assim como o modelo de dados fornece um conjunto de dados não redundante, os requisitos devem fornecer um conjunto não redundante de funções e eventos.

6. Presta-se ao controle de mudanças: Os requisitos, como todas as outras entregas de um projeto, devem ser colocados sob controle de mudanças.

7. Rastreável: Os requisitos devem ser rastreáveis uns aos outros, aos objetivos, ao design, aos casos de teste e ao código.

8. Legível por todos os membros da equipe do projeto: As partes interessadas do projeto, incluindo os usuários, desenvolvedores e testadores, devem chegar ao mesmo entendimento dos requisitos.

9. Escritos em um estilo consistente: Os requisitos devem ser escritos em um estilo consistente para facilitar sua compreensão.

10. As regras de processamento refletem padrões consistentes: As regras de processamento devem ser escritas de maneira consistente para facilitar sua compreensão.

11. Explícito: Os requisitos nunca devem estar implícitos.

12. Logicamente consistente: Não deve haver erros lógicos nas relações entre causas e efeitos.

13. Permite reutilização: Bons requisitos podem ser reutilizados em projetos futuros.

14. Conciso: Os requisitos devem ser escritos de forma breve, com o mínimo de palavras possível.

15. Anotado quanto à criticidade: Nem todos os requisitos são críticos. Cada requisito deve observar o grau de impacto que um defeito teria na produção. Dessa forma, a prioridade de cada requisito pode ser determinada e a ênfase adequada colocada no desenvolvimento e teste de cada requisito. Não precisamos de defeito zero na maioria dos sistemas. Precisamos de testes bons o suficiente.

16. Viável: Se o design do software não for capaz de atender aos requisitos, então os requisitos não são viáveis.

Extraído da visão geral do processo de teste baseado em requisitos

A sigla “INVEST” pode lembrar que boas histórias são:

  • EU – Independente
  • N – Negociável
  • V - De valor
  • E – Estimável
  • S - Pequeno
  • T - Testável

Não existe um padrão único para o que constitui um requisito de software de boa qualidade. Além disso, o que pode ser considerado um bom requisito para software aplicativo provavelmente será diferente de um bom software de sistemas requerimento.

Atributos de qualidade dos requisitos

Garantia de Qualidade de Requisitos Automatizada

Requisitos de testes do ScopeMaster. Como SonarQube para requisitos, o ScopeMaster examina cada requisito (ou história de usuário) para detectar a intenção funcional e avalia cada requisito em relação aos critérios de qualidade listados acima. Ele não consegue detectar todas as falhas, mas pode encontrar cerca de 50% delas. Depois de analisar os requisitos individualmente, examina-os no contexto do conjunto de requisitos. Isso fornece informações que simplesmente não são possíveis com ferramentas como Jira e Azure DevOps, ScopeMaster interpreta e analisa requisitos, ele não apenas os armazena. Isso libera seu tempo para considerar outros aspectos importantes de suas necessidades. Isso torna seu trabalho de melhoria da qualidade dos requisitos mais rápido e fácil. Ele faz o trabalho duro para você.

Requisitos Qualidade em resumo
Testa os resultados da história do usuário de login

Na tabela mostrada, as colunas significam:

  1. O índice de qualidade do teste de exigência individual (com alguma consideração ao contexto) para mais de 350 palavras, frases e padrões linguísticos para maior clareza.
  2. Claro e funcional Contém declarações inequívocas de funcionalidade (descrição de movimentos de dados).
  3. Orientado ao usuário Um usuário é identificado como sujeito do requisito, realizando uma ação com os dados.
  4. Conciso a proporção de palavras em relação ao tamanho funcional, dentro de limites razoáveis
  5. Mensurável e testável Se a intenção funcional for detectada, então ela é mensurável e testável, mais uma vez estamos determinando se houve uma intenção funcional clara.
  6. Completo (dentro do conjunto) significa tipos de objetos identificados neste requisito que possuem ações CRUD complementares para garantir um conjunto completo de atividades de manutenção em todo o conjunto de requisitos.
  7. Completo (funcionalidade enterrada) funcionalidade detectada nas notas/critérios de aceitação que deveriam estar no próprio requisito.
  8. Benefícios Houve um esforço para descrever os benefícios ou o valor deste requisito?

Pontuação de qualidade

O ScopeMaster reconhece que os requisitos não existem por si só. Isto entende o contexto de um conjunto de requisitos e assim determina índices de qualidade em dois níveis:

  1. Índice de qualidade para cada exigência individual
  2. Índice de qualidade para um conjunto de requisitos

O ScopeMaster realiza centenas de testes estáticos e potencialmente milhares de testes dinâmicos em cada requisito e fornece feedback imediato ao autor. Então você aprenda a escrever requisitos melhores Enquanto vais.

Pontuação de qualidade de requisitos