Atividades e práticas da avaliação de necessidades
Needs assessment
flexM4I > abordagens e práticas > Atividades e práticas da avaliação de necessidades(versão 1.0)
Autoria: Henrique Rozenfeld ([email protected]) com apoio do chatGPT (leia mais)
Introdução
Avaliação de necessidades é uma tradução usual do termo em inglês, needs assessment. No entanto, em português pode trazer uma conotação que estamos avaliando algo que já foi identificado. No contexto de análise de negócio (business analysis – BA) esse termo abrange tanto a identificação quanto a análise inicial das necessidades.
A avaliação de necessidades consiste em descobrir, compreender e documentar problemas ou oportunidades na forma de necessidades de alto nível, considerando o ambiente de negócios e as expectativas dos stakeholders. Essa análise estratégica alinha a visão do que se pretende resolver ou conquistar, validando as motivações e a relevância do que será empreendido, além de mapear dores ou oportunidades de mercado, sem ainda definir requisitos específicos.
Esta seção é um complemento da seção principal “Gestão de requisitos”, que apresenta:
- as definições de requisitos, necessidades, engenharia & gestão de requisitos;
- quando e por que você deveria utilizar a essa abordagem;
- resistências à gestão de requisitos e como mitigá-las
- características da gestão de requisitos
| Recomendamos que você leia a seção principal “Gestão de requisitos” antes de ler a seção atual. |
A seção principal apresenta ainda uma visão geral da gestão de requisitos, integrada com a gestão de stakeholders e avaliação de necessidades e com um resumo das principais atividades dessas três abordagens.
Essa visão geral é repetida na seção atual para manter a referência. Em seguida as atividades da análise de necessidades são detalhadas.
Além disso, esta seção cita práticas (métodos e ferramentas) que apoiam a realização dessas atividades.
Seções da flexM4i relacionadas com a gestão de requisitos
A flexM4i apresenta algumas seções que tratam da gestão de requisitos, como ilustra a próxima figura.
Figura 1327: seções que tratam da gestão de requisitos (clique na figura para abrir o PDF em outra aba e assim baixar como um mapa de conteúdo da flexM4i com os links das seções)
Esta seção apresenta uma visão geral da articulação entre gestão de requisitos, gestão de stakeholders e avaliação de necessidades, que são detalhadas em três seções correspondentes, como ilustra a figura.
Na seção “Abordagens e metodologias que incorporam a gestão de requisitos” consideramos os seguintes tópicos:
- Gestão de requisitos na gestão de projetos, programas e portfólio
- Gestão de requisitos na análise de negócio (business analysis)
- Gestão de requisitos na Engenharia de Sistemas (SEBoK - INCOSE)
- Processos de desenvolvimento de produtos e a gestão de requisitos
- Engenharia de requisitos (norma ISO/IEC/IEEE 29148:2011)
- Gestão de requisitos no modelo CMMI (Capability Maturity Model Integration)
- Gestão de requisitos no SWEBOK (Software Engineering Body of Knowledge)
- Gestão de requisitos na gestão de mudanças de engenharia
- Gestão de requisitos na gestão de riscos
- Gestão de requisitos na agilidade (scrum, SAFe, LESS e XP)
- Convergências e diferenças entre as abordagens
Veja que no lado esquerdo da figura há uma caixa, que indica o link do repositório de “Abordagens de práticas de inovação” com a instrução para você encontrar seções da flexM4i inserindo o tag “requisitos” na busca. Assim, além das seções citadas na figura, você encontrará seções com métodos e ferramentas específicas (práticas) utilizadas nas atividades da gestão de requisitos. Indicamos dessa forma porque este conteúdo é dinâmico e sempre crescente.
Conheça também a seção da flexM4i com um checklist de requisitos de produtos e serviços que possui 31 categorias de requisitos. Os requisitos estão colocados na forma de questões. Ele está representado na caixa à direita em baixo.
A caixa acima da anterior tem o link para a metodologia de engenharia de requisitos para um Sistema Produto-Serviço (PSS), que resume um e-book sobre o mesmo assunto e traz alguns casos de desenvolvimento de requisitos para PSS
Visão geral da gestão de requisitos, integrada com a gestão de stakeholders e avaliação de necessidades
A gestão de requisitos envolve várias atividades para garantir o alinhamento dos objetivos do projeto com as expectativas dos stakeholders. Ela pode ser integrada em diferentes abordagens, cada uma com seu foco e escopo específico.
A próxima figura ilustra que a gestão de stakeholders e a avaliação de necessidades devem ser tratadas de forma integrada com a gestão de requisitos.
Figura 1320: gestão de stakeholders e avaliação de necessidades integradas com a gestão de requisitos
Modelos
Podemos utilizar modelos para representar os requisitos em todas as atividades, apesar que o primeiro modelo formal é utilizado na atividade de “Análise - práticas de documentação e especificação”.
Uma lista dos modelos de representação mais utilizados encontra-se no tópico que descreve essa atividade na seção de detalhamento das “Atividades e práticas da gestão de requisitos".
Atividades
A próxima figura detalha a figura anterior, ao listar as atividades da gestão de stakeholders, avaliação de necessidades e engenharia & gestão de requisitos.
Figura 1321: Atividades da gestão de stakeholders, avaliação de necessidades (needs assessment) e engenharia & gestão de requisitos
Necessidades como entrada para a elicitação de requisitos
A elicitação de requisitos corresponde à primeira atividade formal da gestão de requisitos. Ela aprofunda as informações levantadas na avaliação de necessidades ao traduzi-las em requisitos concretos (ainda que muitas vezes sejam inicialmente imprecisos ou incompletos). Aqui, o analista de negócios vai além de uma mera coleta, pois envolve a facilitação de discussões, a investigação de problemas e oportunidades, e a articulação dos desejos e necessidades dos stakeholders em requisitos estruturados.
|
Veja nas definições, a diferença entre necessidades e requisitos.
Observe ainda, que a definição de requisitos depende da existência de um conceito do produto ou serviço |
Na avaliação de necessidades (needs assessment), costuma-se operar em um patamar estratégico, identificando e priorizando problemas, dores, oportunidades e, em última instância, as necessidades que justificam o lançamento de um projeto ou iniciativa. É um momento em que ainda não há clareza sobre a solução, nem requisitos definidos.
Na gestão de requisitos, o foco é refinar e controlar o escopo, traduzindo necessidades, desejos e expectativas em requisitos específicos, rastreáveis e testáveis. Embora existam sobreposições entre descobrir necessidades e documentá-las como requisitos, a essência da gestão de requisitos está em garantir que essas definições sejam formalmente registradas e alinhadas com os stakeholders, bem como geridas ao longo do ciclo de desenvolvimento.
A avaliação de necessidades é sempre necessária antes da elicitação de requisitos?
Já vimos que “alguns clientes já conseguem especificar requisitos logo no início de um desenvolvimento”.
Mesmo que ainda, em alguns casos, o cliente “adiante” requisitos, a avaliação de necessidades pode ser realizada de uma forma reduzida ou ser parcialmente incorporada à gestão de requisitos.
Para manter a robustez no delineamento das soluções, a etapa de entender as motivações e o contexto estratégico (avaliação de necessidades) não deve ser ignorada.
| Os guias de business analysis e de engenharia & gestão de requisitos tratam do levantamento de necessidades de forma separada, como um conjunto de atividades que ocorrem antes, como apresentamos anteriormente. |
Depende do grau de novidade?
Uma distinção entre Avaliação de Necessidades e Gestão de Requisitos não se limita ao grau de novidade (radical ou incremental). De fato, tende a existir um contínuo entre inovação incremental e radical, mas os dois conceitos (necessidades versus requisitos) costumam coexistir em maior ou menor intensidade, independentemente do tipo de inovação.
- Em inovações mais radicais, a incerteza sobre o que realmente se pretende alcançar costuma ser maior, o que reforça a importância de uma fase robusta de Avaliação de Necessidades. Nesses cenários, inclusive, podem surgir necessidades latentes, não explicitadas inicialmente pelos stakeholders.
- Em inovações incrementais, pode haver mais clareza sobre o que o mercado ou a organização necessita, mas ainda assim vale a pena estruturar e validar essas necessidades de forma metódica para assegurar que o esforço incremental esteja alinhado com objetivos estratégicos.
Devemos sempre procurar obter uma compreensão aprofundada das necessidades antes de consolidar requisitos.
|
As necessidades podem ser consideradas como uma síntese de diversas possíveis entradas para inovação. A identificação de necessidades pode partir tanto de aspectos negativos (as “dores”, problemas, fraquezas ou ameaças) quanto de aspectos positivos (ganhos, oportunidades, forças) que se deseja potencializar. Em muitos casos, a necessidade é justamente o que se busca alcançar para mitigar uma dor ou aproveitar uma oportunidade. Logo, a necessidade pode ser entendida como a “essência” ou o “objetivo-chave” por trás de um desafio ou uma oportunidade de inovação, que são os dois dos conceitos que a flexM4i utiliza como síntese das entradas para inovação. A “necessidade” é o enunciado que amarra tanto o lado que se quer mitigar (fraquezas/ameaças) quanto o que se quer potencializar (oportunidades/ganhos/forças). |
Porém, para produtos mais simples, quando partimos de um conceito estabelecido e temos segurança sobre as necessidades, podemos partir diretamente para a elicitação de requisitos, sem realizar a avaliação de necessidades.
Atividades e práticas da avaliação de necessidades
Apesar desta seção ser um detalhamento da gestão de requisitos, este tópico apresenta o que pode ocorrer antes da elicitação de requisitos, como discutimos no tópico anterior.
A avaliação de requisitos ocorre antes do ciclo de vida do projeto e tem como objetivo analisar problemas de negócios ou necessidades estratégicas da organização. Esse processo é essencial para garantir que os requisitos identificados estejam alinhados aos objetivos estratégicos e proporcionem valor ao negócio.
No entanto, o próprio levantamento das necessidades pode ser um projeto em si ou pode fazer parte do escopo inicial de um projeto.
| Não necessariamente a avaliação de necessidades, no nível em que está detalhado neste tópico, devem ser realizadas antes da elicitação de requisitos, como discutimos anteriormente.
A seguir, são apresentadas as principais atividades da avaliação de requisitos, seguidas das práticas aplicáveis a cada uma.
| Na versão atual, as práticas são somente citadas. |
Identificar problema ou oportunidade
Esta atividade visa formar um entendimento claro da situação que a organização deseja abordar, garantindo que a solução escolhida seja adequada para resolver o problema ou explorar a oportunidade identificada. Para isso, é necessário evitar a definição precoce de uma solução e focar na análise do contexto organizacional. O resultado é uma declaração de situação, validada por stakeholders, que servirá de base para as próximas etapas.
Práticas recomendadas:
- Análise comparativa
- Análise da concorrência
- Análise de documentos
- Entrevistas
- Observação
- Análise de mercado
- Experimentação, prototipagem e testes (normalmente, em associação com alguma abordagem ou metodologia, entre as citadas no próximo quadro)
| Esta atividade está normalmente associada aos processos iniciais da inovação. Por isso, ela pode estar integrada com as seguintes abordagens ou metodologias: – Design thinking – Processo de discovery – Front-end of innovation – Roadmapping Na flexM4i, no contexto da gestão da inovação, definimos com uma generalização de todas as possíveis entradas os conceitos (termos): oportunidade, desafio ou ideia, conforme explicamos em “Oportunidades, desafios e ideias como síntese das entradas para inovação”. |
Avaliar a situação (estado) atual
O objetivo dessa atividade é compreender o ambiente atual da organização, identificando fatores internos e externos que possam estar causando o problema ou influenciando a oportunidade. Isso permite determinar quais elementos da situação atual devem permanecer inalterados e quais devem ser modificados para alcançar a situação futura desejada.
|
Frequentemente, avaliamos a situação atual antes da identificação do problema, quando estivermos buscando novas oportunidades ou desafios (inovações mais radicais). A descrição tradicional desta atividade, após a definição do problema, considera: |
Práticas recomendadas:
As mesmas práticas da atividade anterior podem ser utilizadas para a avaliar a situação atual. No caso do detalhamento do entendimento do “problema”, podemos ainda utilizar.
- Análise mais detalhada de documentos
- Entrevistas mais focadas baseadas em questões fechadas com a possibilidade de realização de surveys (se houver uma amostra significativa)
- Observação focada na ocorrência do “problema”
- Diagramas de Pareto para focar no que for mais relevante
- Análise de causa raiz (são vários métodos e ferramentas) quando o “problema” identificado precisar ser analisado
- Fluxos de processo para obter um contexto no qual o “problema” ocorre.
Determinar a situação futura
Esta atividade consiste em definir as mudanças necessárias para transformar a organização da situação atual para a desejada, garantindo que os problemas sejam resolvidos ou as oportunidades exploradas. O processo envolve a identificação de novas capabiliidades organizacionais e a priorização de mudanças estratégicas.
| Esta atividade tem um viés de melhoria de processo. No desenvolvimento de novas soluções, o escopo da situação futura envolve a própria inovação. Portanto, encare esta atividade como uma referência que pode extrapolar um projeto de inovação incremental, no qual é “mais fácil” determinar a situação futura. |
Práticas recomendadas:
- Diagramas de afinidade para agrupar ideias e percepções em categorias que mostrem padrões e oportunidades de melhoria no estado futuro.
- Benchmarking para comparar práticas, produtos ou processos da organização com referências externas, identificando padrões e inspirações para a situação futura.
- Tabela de capacidades (Capability Table)
- Brainstorming (Brainstorming)
- Oficinas facilitadas (Facilitated Workshops)
- Modelo de funcionalidades (Feature Model)
- Análise de lacunas (Gap Analysis)
- Modelo de Kano para priorização dos requisitos
- Modelo de alinhamento de propósito (Purpose Alignment Model)
- Matriz de capacidades da solução (Solution Capability Matrix)
| A determinação da situação futura já pode envolver o design de novas soluções (inovação) e extrapola o escopo da avaliação de necessidades. |
Determinar opções viáveis e recomendações
Nesta atividade, são aplicadas técnicas analíticas para examinar possíveis soluções para o problema identificado. A atividade envolve a identificação de opções viáveis, a realização de análises de viabilidade e a recomendação da solução mais adequada com base em critérios estratégicos.
Práticas recomendadas:
- Análise comparativa (Benchmarking)
- Análise de custo-benefício (Cost-Benefit Analysis)
- Técnicas de elicitação (Elicitation Techniques)
- Injeção de funcionalidades (Feature Injection)
- Técnicas de decisão em grupo (Group Decision-Making Techniques)
- Técnicas de avaliação de valor (Valuation Techniques)
- Classificação ponderada (Weighted Ranking)
| Como na atividade anterior, a determinação de opções viáveis e recomendações já pode envolver o design de novas soluções (inovação) e extrapola o escopo da avaliação de necessidades. |
Desenvolver o roadmap do produto
O roadmap de produto fornece uma visão estratégica da evolução do produto ao longo do tempo, ajudando a alinhar o desenvolvimento do produto com os objetivos organizacionais e permitindo um planejamento estruturado de entregas futuras.
Práticas recomendadas:
- Oficinas facilitadas (Facilitated Workshops)
- Modelo de funcionalidades (Feature Model)
- Definição da visão do produto (Product Visioning)
- Mapeamento de histórias (Story Mapping)
|
Observe, que, necessariamente, a construção do roadmap já necessita do conceito de um produto. Por isso, esta atividade está associada a melhoria ou inovações incrementais de produtos existentes. Para a criação de soluções mais inovadoras, conheça a seção da flexM4i que descreve o “processo” de discovery. Esta atividade, para produtos mais inovadores, recebe input não somente das atividades anteriores da avaliação de necessidades, mas também do processo de discovery ou outro semelhante. |
Determinar o Business Case
Esta atividade reúne informações analisadas para apoiar a seleção das melhores iniciativas organizacionais, garantindo que a justificativa do projeto esteja bem fundamentada e seja economicamente viável. O Business Case estabelece os benefícios esperados, a viabilidade financeira e o alinhamento estratégico da solução proposta.
Práticas recomendadas:
- Análise de documentos (Document Analysis)
- Oficinas facilitadas (Facilitated Workshops)
- Glossário
- Definição da visão do produto (Product Visioning)
- Mapeamento de histórias (Story Mapping)
|
Muitas vezes as informações sobre o produto obtidas até aqui não são suficientes para se estabelecer um business case preciso. |
Procedimentos e apoio do chatGPT
Este tópico é comum para as quatro seções que foram criadas sobre gestão de requisitos, conforme explicamos a seguir.
A elaboração desta seção foi um processo iterativo e estruturado, baseado exclusivamente nas referências citadas, sem recorrer a conhecimentos gerais do ChatGPT. Foram realizadas mais de 200 interações ao longo de quatro semanas para organizar, estruturar e revisar o conteúdo.
Inicialmente, o Sávio Aleixo criou uma versão baseada na sua dissertação de mestrado (Aleixo, 2021).
Em seguida, o segundo autor, analisou o conteúdo, estudou as referências citadas inicialmente e acrescentou outras, chegando a 28 referências, sendo 5 livros e 2 corpos de conhecimentos (BOKs) específicos sobre gestão de requisitos. Mais 3 BOKs foram adicionados sobre business analysis, que é uma abordagem, cujo pilar central é a gestão de requisitos.
Um novo sumário foi estruturado e depois da leitura e estudo das referências, foram extraídos trechos das publicações relacionadas aos tópicos do sumário.
Esses trechos foram passados para o chaGPT 4.o para que fossem resumidos. Nesse processo, o sumário foi modificado muitas vezes. Os autores avaliaram cada resumo criado pelo chatGPT 4.0, que foram editados para manter uma estrutura alinhada com um fluxo.
Em um certo momento, resolvemos integrar a gestão de stakeholders e avaliação de necessidades (needs assessment), que era a proposta tanto do BOK de gestão de requisitos do PMI (2016), como do BABOK (IIAB, 2015) e outras publicações.
Conforme o conteúdo foi crescido, decidiu-se criar duas seções separadas:
- As atividades e práticas de avaliação de necessidades (needs assessment) - sem explicar com detalhes as práticas (só citando)
- As atividades e prática da gestão de requisitos - que inclui a engenharia de requisitos (que integramos com a gestão de requisitos, como explicamos na seção principal). Nesta seção, os detalhes das atividades e das práticas foram expandidos. Foi ainda criado um tópico sobre as ferramentas de software.
Como na flexM4i já existia uma seção sobre gestão de stakeholders, ela foi associada à gestão de requisitos, e o resumo do processo de gestão de stakeholders foi inserido na seção principal da gestão de requisitos.
Nessa reestruturação, o chatGPT 1.o e o 4.5 foram utilizados para avaliar possíveis redundâncias. Ao invés de pedir para o chatGPT gerar o texto, no prompt pedimos para ele detectar os pontos, fazer propostas de melhorias pontuais, que foram analisadas e editadas pelo autor para complementar e/o mudar os tópicos dessas seções.
Com o tempo, baseado nas leituras, observamos que a gestão de requisitos é integrada com diversas abordagens e metodologias de desenvolvimento de soluções e inovação.
Na flexM4i, a gestão de requisitos é considerada um processo de apoio da gestão da inovação. O mesmo ocorre com diversos outros processos, alguns dos quais foram citados na publicação de Hood et al. (2008). Decidimos criar uma outra seção, voltada às pessoas interessadas no nível de detalhamento de treinamento e avançado:
A criação dessa nova seção exigiu um estudo das publicações mais relevantes relacionadas com cada uma dessas abordagens e metodologias. O chatGPT 1.o foi utilizado para resumir a descrição dessas abordagens e metodologias, assim como a discussão sobre a integração com a gestão de requisitos. Essa fase foi demorada, para encontrar essas relações.
Basicamente, essas quatro novas seções estavam “prontas”. Neste momento, além da experiência dos autores, conversamos com praticantes da gestão de requisitos para discutir aspectos que iriamos apresentar. Essa discussão demorou um tempo elevado e chegamos na versão final.
Ai o chatGPT 4.o realizou uma análise crítica sobre essas seções para verificar novamente redundâncias e o fluxo do texto.
Com base nos resultados da análise crítica, todas as quatro seções foram novamente reeditadas pelos autores.
Criamos então a figura “Seções relacionadas com a gestão de requisitos na flexM4i”, apresentada no início de cada uma dessas quatro seções, que se tornou um mapa de conteúdo da flexM4i. Nela associamos outras seções da flexM4i relacionadas com a gestão de requisitos.
Essa versão que publicamos pode ainda sofrer ajustes, conforme recebermos feedback de praticantes, como todo o conteúdo da flexM4i. Por este motivo, gerenciamos o versionamento das seções da flexM4i.
O ChatGPT foi utilizado como ferramenta de apoio para sintetizar informações, sugerir formas de organização dos tópicos e revisar a coerência do material. O processo envolveu múltiplas rodadas de ajustes, garantindo que a seção refletisse com precisão os conceitos extraídos das fontes.
Em momentos específicos, o ChatGPT-4.o foi utilizado para revisões mais detalhadas, enquanto o ChatGPT-01 foi acionado para auxiliar em raciocínios mais complexos. Todas as decisões finais e a curadoria do conteúdo foram feitas pelo autor, garantindo alinhamento conceitual e coerência no texto.
Referências
Hood, C., Wiedemann, S., Fichtinger, S., & Pautz, U. (2008). Requirements management: The interface between requirements development and all other systems engineering processes. Springer Science & Business Media.
PMI (2015). Business analysis for practitioners: A practice guide. Project Management Institute Inc. Newtown Square, Pennsylvania.
PMI (2016). Requirements management: a practice guide. Project Management Institute, Inc. Newtown Square, Pennsylvania.