Elicitação ou coleta de requisitos pode ser denominada como a prática de fazer pesquisas sobre requisitos para um sistema com os usuários, clientes e outras partes interessadas. Para uma equipe de projeto, algumas das tarefas mais importantes que um Analista de Negócios (BA) realiza incluem adquirir, reunir, registrar e revisar as especificações do projeto. Os BAs usam essa abordagem principalmente durante o planejamento e precisam coletar feedback e fornecer informações importantes bem como organizar e facilitar a execução eficaz dos requisitos.
A seguir estão as diretrizes essenciais que devem ser atendidas durante a Elicitação de Requisitos antes do início do projeto:
Quando organizar a sua programação, tenha definido o que você espera alcançar realizando as sessões de reunião e elicitação de requisitos. Você deve ter objetivos claramente definidos para explicar aos demais o que você está buscando. As partes interessadas devem ter uma compreensão clara do motivo pelo qual foram convidadas e porque precisam ajudá-lo a entender, e contribuir com os requisitos do projeto.
Deve-se coletar o requisito de todos os stakeholders envolvidos, especialistas no produto e no setor dentro da empresa, gerente do setor e possivelmente de outros setores também e, se necessário, coletar a perspectiva do usuário/cliente. Os comentários do usuário operacional são importantes, pois serão relevantes na entrega de um produto, sistema ou serviços.
Engenharia reversa também é uma opção, onde novos requisitos podem ser usados para descobrir requisitos de sistemas legados que podem não estar documentados. No entanto, com muitas mudanças nas atividades dos investidores, uma compilação contínua de especificações e revisões, se torna necessária para garantir que os requisitos fundamentais sejam identificados e avaliações de capacidade subsequentes sejam realizadas avaliando a próxima iteração de requisitos devido à mudança, maior clareza na necessidade, ou uma abordagem escalonada para a implementação.
Pode ser difícil categorizar e coordenar a maioria dos critérios. Conforme o processo amadurece, os atributos dos requisitos precisam ser documentados e mantidos atualizados para permanecer rastreáveis durante o teste, validação e verificação. Este processo ajuda a definir critérios que são inconsistentes, incompletos e conflitantes (essas especificações são os atributos rastreados com mais frequência).
Frequentemente, há partes interessadas ocultas dentro de um projeto. Portanto, é muito importante aprender a identificá-las. Nas reuniões iniciais, faça perguntas para descobrir quem são os usuários reais. Muitas vezes, esses indivíduos não são os principais tomadores de decisão, mas sua adesão é vital para um projeto bem-sucedido. Usuários insatisfeitos que são obrigados a usar todos os dias um programa que foi criado sem seu conhecimento, são um ingrediente-chave para um projeto fracassado.
É necessário transparência na fase de elicitação de requisitos, e moldá-los com eficiência antes de explicá-los aos outros membros da equipe e partes interessadas. Essa transparência não apenas ajuda a garantir que todos estejam na mesma página, mas também promove um sentimento de concordância do cliente ao longo de todo o projeto, começando com os requisitos de negócios.
Não assuma que você entendeu tudo, embora pareça aparentemente claro. Mesmo um requisito aparentemente simples pode mascarar todos os tipos de pressupostos, e requisitos disfarçados. Se alguém faz suposições com base em seu conhecimento, experiência ou fatos disponíveis, há uma tendência para incidentes e situações imprevistas que surgirão durante o desenvolvimento do projeto.
As suposições podem até ser verdadeiras, mas nem sempre. Às vezes podem se revelar falsas, o que pode ter um impacto significativo em seu projeto e contribuem com riscos, pois podem não ser fiéis ao projeto. Portanto, é preciso ser específico sobre os requisitos do projeto e analisá-los com cuidado.
As empresas buscam um Produto Mínimo Viável (MVP) em uma abordagem ágil que encapsula a menor quantidade de recursos para qualificar o lançamento de um produto como um sucesso. Mesmo que você não siga uma metodologia ágil, ao coletar requisitos, priorizar é mandatório. É fácil transformar sessões de reunião em uma lista de desejos, onde os investidores dizem ao Papai Noel tudo o que querem. A ideia não é desconsiderar esse conhecimento (na verdade, se você estiver usando a Escuta Ativa, muitas vezes mostra expectativas e suposições), mas sim priorizar de forma simples e transparente o que você está ouvindo e o que está no contexto do lançamento inicial e o que não está. Sendo assim, você realmente deve registrar os itens da lista de desejos, mas a priorização permite que você concentre sua atenção e torne as coisas mais eficientes para o projeto.
É necessário criar o escopo de capacidade que fornece uma estrutura para o projeto e orienta o processo de coleta de requisitos. É a primeira fonte de informação gerada antes do lançamento de qualquer produto.
As avaliações de escopo não se limitam à fase de requisitos. Estes são frequentemente usados ??para incluir operações de construção do início ao fim, atividades específicas (por exemplo, pilotos e testes) e papéis menores em projetos maiores. Escopos de recursos são criados conforme necessário.
Há certas coisas que precisam ser cuidadas durante essa fase. Vamos dar uma olhada em todos eles.
Deve haver planejamento para realizar uma reunião de avaliação ao final do processo de coleta de requisitos, com a presença dos participantes que enviaram requisitos. Quando possível, envolva membros da equipe do projeto. Frequentemente, mudanças de última hora nos requisitos são necessárias para chegar a um acordo de que estão completos e corretos. Os requisitos estão chegando na “linha de base”, e serão “bloqueados” ou “congelados” nesse ponto.
Mas é preciso ter cuidado, a flexibilidade é necessária ao longo do projeto para garantir que o desenvolvimento e implementação do programa não tente apenas satisfazer o conjunto exaustivo de requisitos quando é possível alcançar uma produção mais rápida ou talvez custos reduzidos, razão pela qual a fase de definições de prioridade seja tão crítica.
Muito do trabalho futuro do projeto será determinado pelo plano de design e especificações. Peça aos revisores que identifiquem os recursos dos requisitos, para revisá-los antes que a especificação seja aprovada. Os bons requisitos são únicos e distintos, viáveis, consistentes, abrangentes, rastreáveis, testáveis, implementáveis, alcançáveis, inequívocos e verificáveis. Pode ser necessário alterar ou remover requisitos “ruins” e seus dependentes. Requisitos dependentes são requisitos relacionados, muitas vezes implícitos ou resultantes de um requisito funcional.