Análise de Negócios - Gerenciamento de Requisitos

Reunir os requisitos de software é a base de todo o projeto de desenvolvimento de software. Solicitar e reunir requisitos de negócios é uma primeira etapa crítica para cada projeto. A fim de preencher a lacuna entre os requisitos de negócios e técnicos, os analistas de negócios devem entender totalmente as necessidades de negócios dentro do contexto dado, alinhar essas necessidades com os objetivos de negócios e comunicar adequadamente as necessidades aos interessados e à equipe de desenvolvimento.

Os principais interessados desejam que alguém possa explicar os requisitos do cliente / cliente em inglês simples. Isso os beneficiará com a compreensão do valor em alto nível? Esta será a área de foco principal, pois eles tentarão mapear a documentação com os requisitos e como o BA poderia se comunicar da melhor maneira possível.

Por que os projetos falham

Existem muitas razões pelas quais os projetos falham, mas algumas das áreas comuns incluem o seguinte -

Falha de mercado e estratégia
Falhas Organizacionais e de Planejamento
Falhas de qualidade
Falhas de liderança e governança
Falhas de habilidades, conhecimento e competência
Falhas de engajamento, trabalho em equipe e comunicação

O cerne da questão é que os projetos estão cada vez mais complexos, as mudanças ocorrem e a comunicação é um desafio.

Por que equipes de sucesso fazem gerenciamento de requisitos

O gerenciamento de requisitos é manter sua equipe in-sync e fornecendo visibility para o que está acontecendo dentro de um projeto.

É fundamental para o sucesso de seus projetos que toda a equipe entenda o que você está construindo e por quê - é assim que definimos o gerenciamento de requisitos. O “porquê” é importante porque fornece contexto para os objetivos, feedback e decisões que estão sendo tomadas sobre os requisitos.

Isso aumenta a previsibilidade de sucessos futuros e problemas potenciais, permitindo que sua equipe corrija rapidamente quaisquer problemas e conclua com sucesso seu projeto no prazo e dentro do orçamento. Como ponto de partida, é importante que todos os envolvidos tenham um entendimento básico do que são os requisitos e como gerenciá-los.

Vamos começar com o básico

Um requisito é uma condição ou capacidade necessária para uma parte interessada resolver um problema ou atingir um objetivo. Uma condição ou capacidade que deve ser atendida ou possuída por um sistema ou sistema. Componente para satisfazer um contrato, padrão, especificação ou outros documentos impostos formalmente.

Um requisito pode ser expresso com texto, esboços, maquetes ou modelos detalhados, qualquer informação que melhor comunique a um engenheiro o que construir e a um gerente de QA o que testar. Dependendo do seu processo de desenvolvimento, você pode usar terminologia diferente para capturar os requisitos.

Requisitos de alto nível às vezes são chamados simplesmente de needs ou goals. Dentro das práticas de desenvolvimento de software, os requisitos podem ser chamados de “casos de uso”, “recursos” ou “requisitos funcionais”. Ainda mais especificamente dentro de metodologias de desenvolvimento ágil, os requisitos são frequentemente capturados comoepics e stories.

Independentemente de como sua equipe os chama ou do processo que você usa; requisitos são essenciais para o desenvolvimento de todos os produtos. Sem definir claramente os requisitos, você pode produzir um produto incompleto ou com defeito. Ao longo do processo, pode haver muitas pessoas envolvidas na definição de requisitos.

Uma parte interessada pode solicitar um recurso que descreve como o produto agregará valor na solução de um problema. Um designer pode definir um requisito com base na aparência ou no desempenho do produto final do ponto de vista da usabilidade ou da interface do usuário.

Um analista de negócios pode criar um requisito de sistema que adere a restrições técnicas ou organizacionais específicas. Para os sofisticados produtos e aplicativos de software em construção de hoje, geralmente são necessários centenas ou milhares de requisitos para definir suficientemente o escopo de um projeto ou lançamento. Assim, é imperativo que a equipe seja capaz de acessar, colaborar, atualizar e testar cada requisito até a conclusão, pois os requisitos mudam e evoluem naturalmente com o tempo durante o processo de desenvolvimento.

Agora que definimos o valor do gerenciamento de requisitos em alto nível, vamos nos aprofundar nos quatro fundamentos que cada membro da equipe e todas as partes interessadas podem se beneficiar ao compreender -

Planejando bons requisitos: “O que diabos estamos construindo?”
Colaboração e adesão: “Basta aprovar a especificação, já!”
Rastreabilidade e gerenciamento de mudanças: “Espere, os desenvolvedores sabem que isso mudou?”
Garantia de qualidade: “Olá, alguém testou isso?”

Todos sabem o que estamos construindo e por quê? Esse é o valor do gerenciamento de requisitos.

Colaboração e aceitação das partes interessadas

Todos estão por dentro? Temos aprovação sobre os requisitos para seguir em frente? Essas questões surgem durante os ciclos de desenvolvimento. Seria ótimo se todos pudessem concordar com os requisitos, mas para grandes projetos com muitos stakeholders, isso geralmente não acontece. Tentar fazer com que todos concordem pode fazer com que as decisões sejam atrasadas ou, pior, nem mesmo tomadas. Obter consenso sobre todas as decisões nem sempre é fácil.

Na prática, você não quer necessariamente “consenso”, você quer “adesão” do grupo e a aprovação daqueles que estão no controle para que você possa levar o projeto adiante. Com o consenso, você está tentando fazer com que todos se comprometam e concordem com a decisão. Com a adesão, você está tentando fazer com que as pessoas apoiem a melhor solução, tomem uma decisão inteligente e façam o que é necessário para seguir em frente.

Você não precisa que todos concordem que a decisão é a melhor. Você precisa de todos para apoiar a decisão. A colaboração da equipe pode ajudar a receber suporte nas decisões e no planejamento de bons requisitos.

As equipes colaborativas trabalham muito para garantir que todos tenham interesse nos projetos e forneçam feedback. As equipes colaborativas compartilham ideias continuamente, normalmente têm uma comunicação melhor e tendem a apoiar as decisões tomadas porque há um senso compartilhado de comprometimento e compreensão dos objetivos do projeto.

É quando os desenvolvedores, testadores ou outras partes interessadas se sentem "fora do circuito" que surgem os problemas de comunicação, as pessoas ficam frustradas e os projetos atrasam. Uma vez que todos tenham aderido ao escopo de trabalho, é imperativo que os requisitos sejam claros e bem documentados. Manter o controle de todos os requisitos é onde as coisas ficam complicadas.

Imagine ter uma lista de tarefas de uma milha de comprimento que envolve a colaboração de várias pessoas para ser concluída. Como você manteria todos esses itens em ordem? Como você rastrearia como uma mudança em um item afetaria o resto do projeto? É aqui que a rastreabilidade e o gerenciamento de mudanças agregam valor.