Gerenciamento de Requisitos e suas Etapas (Parte 2)

Nesta parte 2 de nosso artigo, vamos detalhar a elicitação de requisitos e suas técnicas. Confira a parte 1 aqui neste link.

O processo de elicitação é mais do que coletar e reunir requisitos. Os requisitos não estão “prontos” nas mentes das partes interessadas ou em outros documentos, esperando para serem coletados e reunidos. É necessário um esforço para transformar desejos e necessidades em requisitos claramente elicitados.
Alguns fatores contribuem para o sucesso de um processo de elicitação de requisitos, particularmente um bom planejamento e preparação da elicitação, o engajamento ativo dos envolvidos, clareza na definição da necessidade de negócio e conhecimento do assunto por parte dos envolvidos na elicitação.
Uma ampla gama de técnicas está disponível. Essas técnicas podem ser utilizadas isoladamente ou em conjunto para se alcançar o resultado desejado. Algumas técnicas comumente utilizadas são:

• Análise de Documentação. Várias informações podem ser obtidas por meio de revisão e análise de documentação existente. Essa documentação pode incluir planos estratégicos e de negócios, fluxogramas de processos, termo de abertura do projeto, documento de visão, registros de questões ou problemas, normas, regulamentos, políticas, procedimentos e outros documentos que ajudem a descobrir requisitos. Essa técnica pode funcionar como um ponto de partida na elicitação e uma preparação para aplicação de outras técnicas que a complementem.

 

• Entrevistas. Uma entrevista é uma abordagem metódica utilizada para elicitar informações de partes interessadas por meio da realização de perguntas relevantes e da documentação das respostas obtidas. Durante a entrevista, perguntas são feitas a partes interessadas do projeto para identificar funções e outras capacidades que deverão estar presentes no produto. A entrevista pode ser conduzida de forma mais estruturada, com perguntas tendo sido preparadas de antemão, ou mais desestruturada, onde perguntas são feitas de maneira mais livre, baseadas nas próprias respostas dadas pelos participantes.

 

• Workshops com Facilitação. Esses eventos reúnem partes interessadas chaves ou times multidisciplinares numa sessão estruturada conduzida por um facilitador para identificar requisitos, reconciliar abordagens diferentes e obter consenso entre os participantes.

 

• Grupos de Foco. Essas reuniões envolvem participantes pré-qualificados, como especialistas em certos temas ou no uso de certos produtos, para compartilhar suas expectativas e atitudes a respeito do produto a ser desenvolvido. Os membros do grupo manifestam suas opiniões e esclarecem tópicos específicos.

 

• Brainstorming. Consiste numa técnica altamente criativa e sinérgica para obtenção de informações (neste caso, requisitos), onde não se impõe qualquer tipo de restrição aos participantes e não se busca qualquer tipo de consenso a priori.

 

• Questionários e Pesquisas. Essas ferramentas são usadas para solicitar e obter informações rapidamente de um grupo grande de partes interessadas. As questões são preparadas para elicitar dados subjetivos e demográficos dos respondentes. As respostas são analisadas para se extraírem requisitos ou se obterem insumos para outras técnicas de elicitação. Questionários e pesquisas são mais eficazes quando se desejam respostas mais rápidas de partes interessadas geograficamente dispersas.

 

• Protótipos. A utilização de protótipos é uma forma de se obter feedback antecipado sobre as características de um modelo funcional de um produto, antes de seu desenvolvimento real. O contato do cliente com o protótipo permite a elicitação de necessidades sobre o uso do produto e a posterior documentação de requisitos.

 

• Observação. Essa técnica, também conhecida como “job shadowing”, permite que se observem pessoas diretamente em seus ambientes de trabalho para que se veja como realizam suas atividades. É particularmente útil para elicitar requisitos tácitos, difíceis de verbalizar.

 
Quem elicita requisitos deve empregar escuta ativa para tentar capturar toda a informação que chega com cada resposta. Escuta ativa é o ato de ouvir completamente “com todos os sentidos”. Uma boa prática é parafrasear ou repetir o que foi dito pelo entrevistado para garantir um entendimento acurado do que foi comunicado. Isso envolve suspender todo o julgamento sobre o que está sendo ouvido, para que a informação possa fluir livremente.
 
Dependendo da área de aplicação do produto que será desenvolvido, vários métodos de modelagem visual podem ser utilizados como auxílio na elicitação de requisitos, tais como, Diagramas de Caso de Uso, Wireframes, Diagramas de Contexto entre outros.

Quando se aplicam técnicas que envolvem interação com as partes interessadas, é importante que o responsável pela elicitação prepare-se adequadamente para a sessão. Essa preparação deve envolver uma definição clara dos objetivos que se pretendem alcançar com a sessão de elicitação, a definição dos participantes e a preparação de perguntas a serem feitas para os entrevistados.

A respeito das perguntas a serem feitas numa sessão de elicitação, é importante notar que não há uma pergunta “certa” que fornecerá a informação exata que gerará a solução perfeita. A pergunta certa não é conhecida até que a pergunta seja respondida e a resposta analisada. Em muitos casos, informações que levam a soluções perfeitas chegam aos pedaços a partir de várias perguntas feitas a vários participantes. De maneira geral, quanto mais questões são perguntadas, maior a chance de se fazer a pergunta certa.

Uma ferramenta interessante para gerar ideias sobre perguntas a serem feitas é adotar uma espécie de “checklist” de espécies de requisitos, particularmente para os requisitos não-funcionais, conforme apresentado adiante.
É importante lembrar que nem todas as perguntas são planejadas. Boa parte da conversa durante uma elicitação de requisitos é espontânea, ainda que direcionada e investigativa por natureza. A seguir é apresentado um exemplo de notas de preparação para uma sessão de elicitação para discutir uma mudança de escritório:
​

Um aspecto também importante durante a elicitação é a consideração dos requisitos não-funcionais (ver definição na parte 1 deste artigo). Estes descrevem certas condições ambientais ou atributos requeridos para garantir que o produto funcione efetivamente, e podem ser subdivididos em várias espécies, como as apresentadas a seguir, que podem servir como um checklist de apoio ao processo de elicitação:
​

• Requisitos de Desempenho. Requisitos que definem algum desempenho necessário do produto precisam ser alcançáveis, mensuráveis e especificados em termos operacionais, sempre que for possível. Podem ser subdivididos em:

 

• Requisitos de Níveis de Serviço. Cenários que possam implicar em diferentes níveis aceitáveis de serviço (ex.: se o desempenho do produto em horário comercial será diferente em relação ao período noturno e fins de semana, se as condições de utilização do produto em caso de demanda máxima serão muito diferentes das condições de utilização em caso de demanda média ou mínima).

 

• Requisitos de Confiabilidade e Disponibilidade. Requisitos de confiabilidade incluem, por exemplo, tempo médio entre falhas (MTBF – Mean Time Between Failure). Requisitos de disponibilidade incluem, por exemplo, percentual de tempo em que o produto estará disponível em funcionamento normal e em funcionamento de emergência.

 

• Requisitos de Modularidade. Referem-se à habilidade de componentes de hardware e de software serem ampliados ou melhorados sem requerer mudanças em outros componentes além daqueles que estão sendo ampliados ou melhorados.

 

• Requisitos de Escalabilidade. Requisitos relacionados à capacidade de o produto operar em várias faixas.

 

• Requisitos Físicos. Referem-se à integração de uma solução no ambiente físico. É muito provável que requisitos relacionados à integração física não se apliquem aos casos em que o produto do projeto seja um serviço, a não ser que equipamentos ou instalações sejam adquiridos para suportar tal serviço.

 

• Requisitos de Interface. Interfaces necessárias entre o novo produto e processos, sistemas, equipamentos ou instalações, novos ou existentes, com os quais o novo produto terá de interagir, física ou funcionalmente.

 

• Requisitos de Normas & Regulamentos. Normas ou regulamentos a que o produto precisará atender.

 

• Requisitos relacionados a Fatores Humanos.

 

• Requisitos de Interface entre o Produto e o Ser Humano. Tipicamente, esses requisitos servem para garantir que o produto seja apropriado para ser utilizado, operado e mantido por pessoas.

 

• Requisitos de Segurança e Saúde de Pessoas. Podem se referir a:

 

• Saúde e segurança daqueles que irão utilizar o produto (ex.: espaço adequado para manutenção, facilidade de acesso a componentes, manuseamento de materiais inflamáveis ou tóxicos, proteção contra queda, descarte de resíduos).

 

• Ambiente de operação (ex.: iluminação, saídas de emergência, temperatura, ruído, proteção contra incêndio, escadas de emergência).

 

• Detecção de mau funcionamento e desligamento automático de equipamentos de forma a evitar prejuízos à saúde ou riscos de acidentes com pessoas.

 

• Requisitos de Capacidades e Habilidades Especiais. Relacionados a capacidades específicas (físicas, de percepção, de conhecimento técnico) daqueles que irão operar, manter ou dar suporte ao produto. Por exemplo, a força de trabalho necessária, assim como suas habilidades requeridas (número de operadores por equipamento, habilidade ou proficiência de operadores/ mantenedores) e necessidades relacionadas a treinamento permanente do pessoal envolvido com o uso do produto.

 

• Requisitos de Segurança.

 

• Requisitos de Segurança Física. Relacionados à segurança das instalações durante a operação. A segurança das instalações refere-se à prevenção de acesso não autorizado a instalações (controle de acesso), propriedades e equipamentos, e à proteção contra sabotagem, espionagem e outras ameaças criminosas.

 

• Requisitos de Segurança da Informação. Relacionados a armazenamento, processamento ou transferência de dados e informações considerados sensíveis ou confidenciais, durante a operação do produto.

 

• Requisitos de Manutenção do Produto. Indicam necessidades a respeito de quem ou como a manutenção do produto será feita. Por exemplo: a manutenção preventiva não deve ser inferior a “x” vezes ao ano, reparos em garantia devem ser feitos em até “y” dias, a manutenção corretiva deve ser feita dentro de “z” horas.

 

• Requisitos de Suporte à Operação.

 

• Requisitos de Pessoal de Suporte. Pessoal necessário para trabalhar diretamente com a operação do produto.

 

• Requisitos de Material de Suporte. Relacionados à obtenção, catalogação, recebimento, armazenamento e disponibilização de materiais de suporte à operação do produto, como peças sobressalentes, por exemplo.

 

• Requisitos de Equipamentos de Suporte. Equipamentos e ferramentas necessários ao suporte das operações do produto

 

• Requisitos de Dados Técnicos para a Operação. Relacionados com o registro de informações, tais como manuais técnicos, especificações e desenhos, necessários à operação do produto.

 
Na próxima e última parte deste artigo, trataremos da documentação e análise dos requisitos elicitados, e de seu monitoramento e controle para entregar uma solução que atenda às partes interessadas.
 
Este artigo faz parte do Programa Esteiras de Gestão da Academia DC. Clique aqui, faça sua inscrição e acesse gratuitamente vários conteúdos online para aperfeiçoar suas habilidades gerenciais!


Referências bibliográficas:

• BORGES, Carlos; MERIGUETTI, Cezar; ROLLIM, Fabiano; Gerenciamento de Projetos Aplicado. 2ª ed. Rio de Janeiro: DC, 2024

 

• PROJECT MANAGEMENT INSTITUTE. Requirements Management: A Practice Guide. Newton Square: PMI, 2016.

 

• PROJECT MANAGEMENT INSTITUTE. Business Analysis for Practitioners: A Practice Guide. Newton Square: PMI, 2015.

 
Créditos das imagens:

• "Use Case Diagram.jpg" por Liridon, disponível sob a licença CC BY 3.0 em https://creativecommons.org/licenses/by-sa/3.0/deed.en.
• "Hatley-Pirbhai System Context Diagram.png" por Chrislk02, disponível sob a licença CC BY 3.0 em https://creativecommons.org/licenses/by-sa/3.0/deed.en.
• “Low-fidelity wireframe.jpg” por Junie Loftesnes, disponível sob a licença CC BY-ND 4.0 em https://creativecommons.org/licenses/by-nd/4.0/deed.no.