Bom planejamento de requisitos

Então, o que é um bom requisito? Um bom requisito deve ser valioso e acionável; deve definir uma necessidade, bem como fornecer um caminho para uma solução. Todos na equipe devem entender o que isso significa. Os requisitos variam em complexidade.

Um bom Documento de Requisitos pode fazer parte de um grupo com requisitos de alto nível divididos em sub-requisitos.
Eles também podem incluir especificações muito detalhadas que incluem um conjunto de requisitos funcionais que descrevem o comportamento ou componentes do produto final.
Bons requisitos precisam ser concisos e específicos e devem responder à pergunta: "do que precisamos?" Em vez de "como podemos atender a uma necessidade?"
Os bons requisitos garantem que todas as partes interessadas entendam sua parte do plano; se as peças não estiverem claras ou forem mal interpretadas, o produto final pode estar com defeito ou falhar.

A prevenção de falhas ou má interpretação dos requisitos pode ser auxiliada pelo recebimento de feedback da equipe continuamente ao longo do processo, conforme os requisitos evoluem. Colaboração contínua e adesão de todos são a chave para o sucesso.

Coleta e Análise de Requisitos

Um requisito é uma condição ou capacidade necessária para uma parte interessada resolver um problema ou atingir um objetivo organizacional; uma condição ou capacidade que deve ser cumprida ou possuída por um sistema.

A análise de requisitos em engenharia de software cobre as tarefas que vão para determinar as necessidades ou condições para atender a um produto novo ou alterado, levando em consideração os possíveis requisitos conflitantes de várias partes interessadas, analisando, documentando, validando e gerenciando requisitos de software ou sistema.

Os requisitos devem ser -

Documented
Actionable
Measurable
Testable
Traceable

Os requisitos devem estar relacionados às necessidades ou oportunidades de negócios identificadas e definidos com um nível de detalhe suficiente para o design do sistema.

Um analista de negócios reúne informações através da observação dos sistemas existentes, estudando os procedimentos existentes, discussões com os clientes e usuários finais. O analista também deve ter habilidades imaginativas e criativas na ausência de um sistema funcional. Analisar os requisitos coletados para encontrar os links ausentes é a análise de requisitos.

Abordagem de Elicitação

Para eliciar os objetivos, pergunte ao especialista de negócios, ao gerente de desenvolvimento e ao patrocinador do projeto as seguintes perguntas -

Que objetivos de negócios da empresa este projeto ajudará a alcançar?
Por que estamos fazendo este projeto agora?
O que acontecerá se fizermos isso mais tarde?
E se não fizermos nada?
Quem se beneficiará com este projeto?
As pessoas que se beneficiarão com isso consideram a melhoria mais importante que pode ser feita neste momento?
Deveríamos estar fazendo um projeto diferente em vez disso?

Os objetivos possíveis podem ser reduzir custos, melhorar o atendimento ao cliente, simplificar o fluxo de trabalho, substituir tecnologia obsoleta, testar uma nova tecnologia e muitos outros. Além disso, certifique-se de entender exatamente como o projeto proposto ajudará a cumprir o objetivo declarado.

Diferentes tipos de requisitos

Os tipos mais comuns de requisitos pelos quais um analista de negócios está interessado são os seguintes -

Requisitos de negócio

Os requisitos de negócios são as atividades críticas de uma empresa que devem ser realizadas para atender aos objetivos organizacionais enquanto permanece independente da solução. Um documento de requisitos de negócios (BRD) detalha a solução de negócios para um projeto, incluindo a documentação das necessidades e expectativas do cliente.

Requisitos do usuário

Os requisitos do usuário devem especificar os requisitos específicos que o usuário espera / deseja do software a ser construído a partir do projeto de software. Um requisito do usuário deve ser verificável, claro e conciso, completo, consistente, rastreável, viável.

O documento de requisitos do usuário (URD) ou especificação de requisitos do usuário é um documento geralmente usado na engenharia de software que especifica o que o usuário espera que o software seja capaz de fazer.

Requisitos de sistema

Os requisitos do sistema tratam da definição dos requisitos e pré-requisitos de recursos de software que precisam ser instalados em um computador para fornecer o funcionamento ideal de um aplicativo.

Requisitos funcionais

Os requisitos funcionais capturam e especificam o comportamento pretendido específico do sistema que está sendo desenvolvido. Eles definem coisas como cálculos do sistema, manipulação e processamento de dados, interface do usuário e interação com o aplicativo e outras funcionalidades específicas que mostram como os requisitos do usuário são satisfeitos. Atribua um número de identificação exclusivo para cada requisito.

Requisitos não Funcionais

Requisito não funcional é aquele que especifica critérios que podem ser usados para julgar a operação de um sistema ao invés de comportamentos específicos. A arquitetura do sistema fala sobre o plano de implementação de requisitos não funcionais.

Os requisitos não funcionais falam sobre como o sistema deve ser ou podem ser mencionados como “o sistema deve ser”. Os requisitos não funcionais são chamados de qualidades do sistema.

Requisitos de transição

Os requisitos de transição descrevem os recursos que a solução deve cumprir para facilitar a transição do estado atual da empresa para um estado futuro desejado, mas que não serão necessários depois que a transição for concluída.

Eles são diferenciados de outros tipos de requisitos porque são sempre de natureza temporária e não podem ser desenvolvidos até que uma solução existente e uma nova sejam definidas. Eles normalmente cobrem a conversão de dados de sistemas existentes, lacunas de habilidades que devem ser abordadas e outras mudanças relacionadas para atingir o estado futuro desejado. Eles são desenvolvidos e definidos por meio de avaliação e validação da solução.

Rastreabilidade e gerenciamento de mudanças

A rastreabilidade de requisitos é uma forma de organizar, documentar e controlar todos os seus requisitos, desde a geração da ideia inicial até a fase de teste.

A matriz de capacidade de rastreamento de requisitos (RTM) fornece um método para rastrear os requisitos funcionais e sua implementação durante o processo de desenvolvimento. Cada requisito é incluído na matriz junto com seu número de seção associado.

Conforme o projeto avança, o RIM é atualizado para refletir o status de cada requisito. Quando o produto está pronto para o teste do sistema, a matriz lista cada requisito, qual componente do produto o atende e qual teste verifica se ele foi implementado corretamente

Incluir colunas para cada um dos seguintes no RTM -

Descrição do requisito
Referência de requisito no FRD
Método de verificação
Referência de requisitos no plano de teste

Example- Conectar os pontos para identificar as relações entre os itens em seu projeto. É um conector de fluxo a jusante comum.

Objetivos de negócios do teste de design de requisitos de ideia

Você deve ser capaz de rastrear cada um de seus requisitos de volta ao seu objetivo de negócios original.

Ao rastrear os requisitos, você é capaz de identificar o efeito cascata das mudanças, ver se um requisito foi concluído e se está sendo testado corretamente. A rastreabilidade e o gerenciamento de mudanças fornecem aos gerentes tranquilidade e a visibilidade necessária para antecipar problemas e garantir a qualidade contínua.

Garantia da Qualidade

Obter os requisitos entregues da maneira certa na primeira vez pode significar melhor qualidade, ciclos de desenvolvimento mais rápidos e maior satisfação do cliente com o produto. O gerenciamento de requisitos não apenas ajuda você a acertar, mas também ajuda sua equipe a economizar dinheiro e muitas dores de cabeça durante o processo de desenvolvimento.

Requisitos concisos e específicos podem ajudá-lo a detectar e corrigir problemas antecipadamente, em vez de posteriormente, quando é muito mais caro corrigir. Além disso, pode custar até100 times mais para corrigir um defeito posteriormente no processo de desenvolvimento, depois que ele foi codificado, do que corrigir logo no início enquanto um requisito.

Ao integrar o gerenciamento de requisitos em seu processo de garantia de qualidade, você pode ajudar sua equipe a aumentar a eficiência e eliminar o retrabalho. Além disso, o retrabalho é onde ocorre a maioria dos problemas de custo.

Em outras palavras, as equipes de desenvolvimento estão desperdiçando a maior parte de seus orçamentos em esforços que não são executados corretamente na primeira vez. Por exemplo, um desenvolvedor codifica um recurso com base em um documento de especificação antigo, apenas para saber mais tarde, que os requisitos para aquele recurso mudaram. Esses tipos de problemas podem ser evitados com as melhores práticas de gerenciamento de requisitos eficazes.

Em resumo, o gerenciamento de requisitos pode soar como uma disciplina complexa, mas quando você o reduz a um conceito simples - trata-se de ajudar as equipes a responder à pergunta: "Todos entendem o que estamos construindo e por quê?" De analistas de negócios, gerentes de produto e líderes de projeto aos desenvolvedores, gerentes de QA e testadores, junto com as partes interessadas e clientes envolvidos - muitas vezes, a causa raiz do fracasso do projeto é um mal-entendido do escopo do projeto.

Quando todos estão colaborando e têm total contexto e visibilidade para as discussões, decisões e mudanças envolvidas com os requisitos ao longo do ciclo de vida do projeto, é quando o sucesso acontece de forma consistente e você mantém a qualidade contínua. Além disso, o processo é mais suave, com menos atrito e frustração para todos os envolvidos.

Note- A pesquisa mostrou que as equipes de projeto podem eliminar 50-80% dos defeitos do projeto gerenciando os requisitos com eficácia. De acordo com o instituto de engenharia de software Carnegie Mellon, “60-80 por cento do custo de desenvolvimento de software está em retrabalho”.

Obtendo a aprovação dos requisitos

A aprovação de requisitos formaliza o acordo das partes interessadas do projeto de que o conteúdo e a apresentação dos requisitos, conforme documentado, são precisos e completos. O acordo formal reduz o risco de que, durante ou após a implementação, uma parte interessada introduza um novo requisito (anteriormente não encontrado).

A obtenção da aprovação dos requisitos normalmente envolve uma revisão final face a face dos requisitos, conforme documentado, com cada parte interessada do projeto. Ao final de cada revisão, a parte interessada é solicitada a aprovar formalmente o documento de requisitos revisado. Esta aprovação pode ser registrada fisicamente ou eletronicamente.

A obtenção da aprovação dos requisitos é normalmente a tarefa final na Comunicação de Requisitos. O Analista de Negócios exigirá a saída da (s) Revisão (ões) de Requisitos Formais, incluindo acomodação de quaisquer comentários ou objeções que foram levantados durante o processo de revisão.