O Guia Mais Completo para Gerenciamento de Requisitos e Rastreabilidade
O que fazer e o que não fazer para requisitos de escrita
Conteúdo
Se você é como a maioria das pessoas, provavelmente não gosta de escrever requisitos. Não é a coisa mais excitante do mundo, mas é uma parte crítica do desenvolvimento do produto. Um documento de requisitos melhor pode economizar uma fortuna para sua organização com uma comunicação clara entre o desenvolvedor e as partes interessadas do produto. Isso, por sua vez, reflete em toda a organização, incluindo maior transparência, menos retrabalho e maior produtividade.
Embora cada organização tenha requisitos e metodologias diferentes, os fundamentos para escrever requisitos permanecem os mesmos. Neste artigo, compartilharemos algumas dicas que podem ajudá-lo a aprimorar suas habilidades de redação de requisitos e a escrever especificações de requisitos claras e nítidas.
O que é a especificação de requisitos?
A especificação de requisitos, também conhecida como documentação, é um processo de anotar todos os requisitos do sistema e do usuário na forma de um documento. Esses requisitos devem ser claros, completos, abrangentes e consistentes.
Durante a atividade de captura, reunimos todos os requisitos de várias fontes. Durante as atividades de análise e negociação, analisamos e entendemos esses requisitos. Agora, devemos preparar um documento formal explicando esses requisitos. Isso é o que é a especificação de requisitos. Para ser preciso, é o processo de documentar todas as necessidades e restrições do usuário e do sistema de maneira clara e precisa.
O que significam “Melhores Práticas” em Gerenciamento de Requisitos?
É tão interessante para mim que todos falam sobre querer treinamento em “melhores práticas”. Este termo é frequentemente usado para descrever o tipo de consultoria que podemos fornecer também. O que isso realmente significa? Acredito que todos nós alimentamos o mito de que as melhores práticas podem ser a base para treinar indivíduos. As melhores práticas não são treinadas, elas são experientes.
Se compararmos a abordagem de melhores práticas com a natureza, sabemos que não são apenas as espécies mais fortes, mas também as mais prolíficas que sobrevivem. Essa é uma das razões pelas quais é tão difícil mudar processos em uma organização. Pense nisso por um momento. Os mais fortes e prolíficos provavelmente descrevem a maioria dos indivíduos que você tem em praticamente qualquer grupo em sua organização. Tenho visto isso repetidamente no campo da Engenharia de Sistemas. Os engenheiros mais fortes e prolíficos costumam fazer seu trabalho há muitos anos e têm uma maneira específica de fazer esse trabalho. Pedir-lhes que experimentem novas técnicas e ferramentas muitas vezes é inútil, pois eles não sabem como isso vai melhorar o já maravilhoso trabalho que estão fazendo. A prática deles sobreviverá se continuarmos a impor uma abordagem de melhores práticas a eles.
Desafios ao escrever requisitos
Existem vários desafios que as pessoas enfrentam ao escrever requisitos.
Papelada ruim – Em algumas organizações, a documentação dos processos é inexistente ou inadequada. Nesse caso, a coleta de requisitos torna-se um processo de duas etapas: primeiro a engenharia reversa do processo existente e, em seguida, a identificação de áreas que precisam de melhoria e otimização. Para confirmar que os requisitos são detalhados e precisos, é fundamental identificar os principais interessados e especialistas no assunto, interagindo diretamente com eles. Desenhar mapas de processos de negócios e visualizar fluxos de trabalho são duas excelentes maneiras de fazer isso. Isso ajuda na eliminação de suposições incorretas, além de fornecer uma imagem completa. Desenhar mapas de processos e exibir processos são duas abordagens úteis para esse propósito.
Requisitos contraditórios – Quando as partes interessadas têm prioridades diferentes para seus objetivos de negócios, isso leva a requisitos que entram em conflito entre si. Em casos como esses, a responsabilidade de um analista de negócios é documentar detalhadamente todos os requisitos, identificar quais solicitações se opõem e permitir aos stakeholders a oportunidade de decidir o que é prioritário.
Você não pode tomar decisões sem ouvir a opinião das partes interessadas e, como analista de negócios, pode ter algumas ideias sobre o que deve ser priorizado. Ainda é crucial ouvir a perspectiva das partes interessadas. A criação de uma pesquisa pode ser um dos métodos para obter clareza sobre o que é mais importante para a maioria das partes interessadas.
Indisponibilidade de entrada do usuário – Alguns motivos podem contribuir para a indisponibilidade dos usuários finais, e cada um requer sua própria resolução. Por exemplo, às vezes os usuários finais estão tão preocupados com seu trabalho diário que não estão dispostos a participar de atividades de coleta de requisitos.
Nesses casos, o melhor que um analista de negócios pode fazer é limitar o número e a duração dos compromissos. Antes da reunião, fazer o máximo de pesquisa possível ajudará a tornar a discussão mais organizada e informativa. É quase como transformar a coleta de requisitos em sessões de validação de requisitos. definir grupos focais e identificar os usuários finais mais adequados para cada grupo
Focando na interface em vez da experiência – Muitas partes interessadas e usuários finais têm uma visão clara de como a nova solução deve aparecer, mas não sabem o que ela deve realizar. A interface de usuário de qualquer sistema é crucial, mas não deve definir ou interferir na funcionalidade.
Os analistas de negócios devem sempre se lembrar de manter o design e os requisitos funcionais separados em sua documentação. Ao usar ferramentas mais gerais, como diagramas, histórias de usuários ou protótipos de baixa fidelidade, em vez de rascunhos de design, eles podem manter o foco nos aspectos funcionais da coleta de requisitos.
Entradas das Partes Interessadas – Quando as partes interessadas ou usuários finais tentam dizer aos projetistas como o sistema deve funcionar em vez do que o sistema deve fazer, isso pode levar a projetos abaixo do ideal. Para evitar isso, valide cada 'falso requisito' em potencial perguntando 'por quê?' até chegar ao problema real que precisa ser resolvido.
Problemas de comunicação – Entre os problemas que podem levar à falta de comunicação entre um analista de negócios e outras partes estão as barreiras linguísticas, suposições erradas, vocabulário insuficientemente explicado e uso excessivo de termos técnicos.
A abordagem ideal para evitar esse problema é interagir com frequência e desenvolver conversas bidirecionais. Documente as necessidades que você descobriu e submeta-as para revisão por pares e críticas a uma variedade de especialistas no assunto, crie um glossário de jargões e verifique as premissas.
10 O que fazer e o que não fazer ao escrever requisitos:
Faça #1. Um por vez – Cada requisito deve ser tratado como um caso de teste discreto. Conjunções como e, ou e assim por diante não devem ser usadas porque podem levar à perda de requisitos. Isso é particularmente crucial, pois termos como esses podem fazer com que desenvolvedores e testadores de software ignorem os requisitos. Dividir necessidades complicadas em partes menores até que cada uma possa ser testada separadamente é uma maneira de evitar que isso aconteça.
Não #1. Fale “o que” e não “como” – O foco deve estar no que o sistema fará, não em como ele o faz. Além disso, evite se aprofundar muito em tópicos de design, como nomes de campos, objetos de linguagem de programação e objetos de software. Se você estiver discutindo esses tópicos no Documento de Especificação de Requisitos, dê um passo para trás – isso provavelmente significa que você está sendo muito específico.
Faça #2. Rastreabilidade – A rastreabilidade no gerenciamento de projetos refere-se a garantir que os requisitos estejam vinculados a outros componentes do projeto. Isso permite que gerentes de projeto, desenvolvedores e partes interessadas acompanhem todo o ciclo de vida de um requisito do início ao fim em todas as direções, bem como com outras partes do sistema. Se você gerenciar a rastreabilidade corretamente, poderá evitar o código que não corresponde a nenhum requisito (código 'desviado') e garantir que cada caso de teste cubra pelo menos um requisito. Você pode tornar os requisitos rastreáveis rotulando-os com um identificador exclusivo e fornecendo informações sobre sua origem em um repositório central acessível a todos os membros da equipe.
Não #2. Sem exceções – Um requisito não deve ter uma cláusula de escape. Por exemplo, “O sistema deve determinar o número de tentativas de login, exceto quando o usuário digitou claramente um nome de usuário incorreto”.
Faça #3. Factível – Garantir que o orçamento e o cronograma do projeto sejam viáveis, juntamente com os recursos disponíveis. Se essa condição puder suportar o requisito, é possível seguir em frente com o plano.
Não #3. Diga não às cláusulas de “deixar sair” – Tente ficar longe de frases soltas como mas, exceto, e somente se necessário.
Faça #4. Consistência – Manter um nível consistente de detalhes. Por exemplo, para requisitos do usuário, um usuário final deve ser o assunto de cada frase. Da mesma forma, para requisitos de sistema, um sistema deve ser o assunto de cada sentença.
Não #4. Sem abreviações – Cada requisito deve ser uma frase completa, sem siglas ou jargões.
Faça #5. Voz ativa – Sempre escreva com voz ativa, certificando-se de que um dos atores seja o sujeito de cada frase.
Não #5. Não seja ambíguo – Não use termos ambíguos como aprox, etc, e mais termos como esse no documento de requisitos. Certifique-se de explicar os requisitos de forma que todos os envolvidos os entendam corretamente. Declarações vagas podem levar a interpretações errôneas e podem causar conflitos entre várias partes interessadas.
Faça #6. Sujeito e Predicado – Para cada requisito, deve haver um sujeito (usuário/sistema) e um predicado (resultado, ação ou condição pretendidos).
Não #6. Especulações podem causar danos – Não adivinhe; não faça listas de recursos que estão fora de questão. Dizer que você quer um sistema para lidar com todas as falhas inesperadas é pura fantasia, pois nenhum sistema jamais será 100% o que você deseja que seja. Evite duplicações e declarações contraditórias.
Faça #7. Verificável – Outra coisa a ter em mente ao organizar os requisitos é que eles devem sempre ser testáveis. Isso significa que precisa ser possível verificar se o sistema atende ao requisito em questão. Isso também está relacionado ao nosso próximo ponto – rastreabilidade. Se um requisito estiver cheio de termos vagos, fica mais difícil analisar e verificar se o sistema realmente atende a esses padrões em termos de desempenho. Portanto, tanto quanto possível, busque clareza e precisão em sua linguagem para que a coleta de requisitos não seja um processo ambíguo.
Não #7. Evitar opções – Não ofereça ideias ou opções. Você pode identificá-los em qualquer declaração que inclua as frases pode, pode, pode ou deve.
Faça #8. Correto – Certifique-se de que cada frase esteja completa e gramaticalmente correta com um sujeito, verbo e predicado adequados.
Não #8. Não fale no tempo futuro – Não se refira a um requisito ainda a ser definido. Seu objetivo é tornar o documento o mais agradável possível de ler.
Faça #9. Foco – Estabeleça o foco eliminando frases desconexas, longas demais e referências a documentos desatualizados.
Não #9. O que deve ser usado e onde? – “Deve” deve ser usado onde os requisitos estão sendo declarados, “Vontade” deve ser usado para representar declarações de fatos; & “Deveria” para representar uma meta a ser alcançada.
Faça #10. A papelada organizada faz maravilhas – Mantenha os requisitos organizados em um só lugar para melhorar a legibilidade do seu documento e evitar perder tempo com referências cruzadas de várias fontes.
Não #10. Não use termos desconhecidos – Não use termos desconhecidos como “amigável, versátil e robusto”, pois pode criar dificuldades ao tentar definir os casos de teste. Essas palavras geralmente carregam significados diferentes para pessoas diferentes.
Requisitos de Visão Plataforma ALM
O Visure é uma das plataformas de gerenciamento de ciclo de vida de aplicativos mais confiáveis, especializada em gerenciamento de requisitos para organizações de todos os tamanhos em todo o mundo. Os principais parceiros da Visure incluem empresas críticas para os negócios e para a segurança. A empresa integra todos os processos de gerenciamento do ciclo de vida do aplicativo, incluindo gerenciamento de riscos, rastreamento de problemas e defeitos, gerenciamento de rastreabilidade, gerenciamento de mudanças e várias outras áreas, como análise de qualidade, controle de versão de requisitos e relatórios poderosos.
Se você estiver procurando por uma ferramenta de gerenciamento de requisitos que o ajude com requisitos funcionais e não funcionais, confira Visure Requirements. Com esta plataforma, você pode facilmente criar, gerenciar e acompanhar todos os requisitos do seu projeto em um só lugar.
Conclusão
A especificação de requisitos é um processo crítico no desenvolvimento de software, mas pode ser desafiador escrever bons requisitos. As 20 dicas que fornecemos devem ajudá-lo a escrever requisitos melhores, tornando o processo mais tranquilo para todos os envolvidos. Se você deseja levar sua redação de requisitos para o próximo nível, considere o uso de uma ferramenta como Visure Requirements ALM Platform. Solicite um Teste gratuito do dia 30 hoje e veja como nossa plataforma pode ajudá-lo a simplificar seus processos de coleta e gerenciamento de requisitos.
Não se esqueça de compartilhar esta postagem!
