Canvas Req: Levantamento de requisitos de software com Canvas

Como fazer o Levantamento de Requisitos de um Software

A entrega de um software desalinhado perante as necessidades ou expectativas de seu mercado/cliente devido à falta de um bom levantamento de requisitos ainda é um problema recorrente na indústria de tecnologia da informação. Apesar de problemas no levantamento de requisitos gerarem diversos contratempos que vão desde a perda de um cliente até a geração de altíssimos custos, percebe-se que ainda é comum encontrar empresas de software lidando com as dificuldades inerentes à compreensão das reais necessidades e desejos de seus clientes.

Relacionado: Levantamento de requisitos: Planejando uma aplicação de lembretes

Desde meados dos anos 1980, inúmeros estudos foram realizados com o intuito de mapear os custos e atrasos ocasionados por uma produção não alinhada com as reais necessidades de um produto ou serviço. Estima-se que o custo de manutenção, reparo e substituição de módulos de um software comercial durante sua execução sejam 100 vezes maiores na etapa de construção e 10 vezes maiores na sua etapa de concepção, do que seriam em sua etapa de planejamento inicial.

Tendo em vista que em torno de 50% a 60% do tempo investido no desenvolvimento de uma ferramenta tecnológica seja dedicado à sua manutenção, a análise de requisitos, quando bem posicionada e aplicada de forma pragmática no projeto apresenta serventia não somente como ferramenta de satisfação e eficiência, mas também como uma significativa redutora de custos.

Assim, durante a venda e planejamento de software, é importante que o processo de levantamento de requisitos seja realizado com o intuito de identificar as necessidades do produto. O processo de levantamento de requisitos é fundamental para o desenvolvimento de software. Estas técnicas trazem meios importantes para a extração da informação, mas muitas vezes remetem a um trabalho procedimental, extenso e cansativo de entrevistas envolvendo perguntas e respostas, que nem sempre captam “o lado humano” das necessidades do cliente e tão pouco proporcionam uma “motivação” adequada ao cliente para que o processo seja completo de forma eficaz. Tal cenário, muitas vezes acaba por comprometer o resultado do levantamento, assim como a sinergia entre as equipes (fornecedor e cliente). Ou seja, para executar um levantamento dentro das normas e ainda oferecer um processo mais participativo, verifica-se a necessidade de conectar o cliente, as características de seu core business e sua proposta de valor aos requisitos levantados pelo profissional e a equipe de desenvolvimento.

Desta maneira, é inserido o Canvas Business Model como uma alternativa de rápida capacitação, processos curtos e metodologia não-burocrática que estão aptas a solucionar a necessidade de levantamento de requisitos durante o processo de construção e venda do software.

Sendo assim, tem-se como objetivo deste trabalho a construção, apresentação e aplicação de um método de levantamento de requisitos para sistemas de TI, capaz de atender as necessidades técnicas ao mesmo tempo em que mantém a simplicidade de uma ferramenta visual e aceita pelo mercado, o Canvas, visto que este tem o preenchimento intuitivo, de rápida aplicação, baixo custo e baixo tempo de capacitação.

Os processos para definição de requisitos

Os principais processos de definição de requisitos são a análise de requisitos e o processo de definição dos requisitos do stakeholder. Ao longo desta seção veremos de forma mais abrangente o processo de obtenção e definição de requisitos do stakeholder, maior ênfase de construção de requisitos utilizada na fundação do Canvas Req. É importante salientar que o processo de levantamento de requisitos do stakeholder é amplamente utilizado por empresas de diversos ramos de atividade, sendo inclusive o foco da norma internacional ISO/IEC/IEE 29148, apresentando diretrizes que servem como guias para o levantamento de requisitos além de listar os itens, conteúdos e formato das informações que devem ser produzidos durante a implementação dos processos de requisitos.

Análise de Requisitos

A análise de requisitos é um conjunto de técnicas que visa levantar, classificar e adequar as necessidades reais de um software em conjunto com cliente ou consumidor final, visando melhor focar os esforços relacionados à sua composição e compreender o que realmente deve ser feito durante a execução do projeto. Assim, a análise de requisitos pode ser definida como uma atividade de, através de visão holística e estratégica, aplicar perguntas bem direcionadas em uma comunicação efetiva e pautada por experiência empírica, procurando caracterizar de forma clara o real problema que deve ser solucionado pelo software e como tal solução se conecta à empresa e/ou à visão, produtos e público alvo do cliente. O processo genérico de levantamento e análise é composto por seis atividades básicas (vide Figura 1):

1. Compreensão do domínio: os analistas devem desenvolver sua compreensão do domínio da aplicação;
2. Coleta de requisitos: é o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade;
3. Classificação: essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes;
4. Resolução de conflitos: quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos;
5. Definição das prioridades: em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes;
6. Verificação de requisitos: os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.

Portanto, nota-se que a análise de requisitos é um processo amplo que deve ser realizado antes da construção do software, como medida de redução de custos e, principalmente, medida estratégica para evitar o retrabalho durante o ciclo de vida do produto tecnológico.

A aplicação da análise de requisitos, além disso, busca ainda proporcionar um maior alinhamento à proposta de valor e, principalmente, às necessidades do cliente em questão, estabelecendo melhores canais de comunicação para o desenvolvimento do produto final e maiores possibilidades de novos empreendimentos e upsales.

Processo de definição dos requisitos do stakeholder

O propósito de elencar os requisitos do stakeholder consiste na definição dos quesitos para um sistema que possa prover os serviços necessitados pelos usuários e outros stakeholders em um ambiente definido.

Identificam-se então os devidos stakeholders, ou classes do mesmo, envolvidos com o sistema ao longo de seu ciclo de vida, suas necessidades, expectativas e desejos. Os requisitos são então analisados e transformados em um conjunto comum de requisitos do stakeholder, que expressam a interação desejada do sistema com seu ambiente operacional e suas referências.

Como um resultado de implementação bem sucedido do processo de levantamento dos requisitos do stakeholder, obtemos, entre outros resultados: (i) as características requeridas do Sistema e seu contexto de uso e funções do produto e serviços, assim como conceitos operacionais especificados; (ii) as restrições na solução buscada pelo sistema são definidas; (iii) a ligação dos requisitos de stakeholder a stakeholder e suas respectivas necessidades é obtida e; (iv) os requisitos do stakeholder são definidos e identificados.

Deste modo, torna-se importante clarificar as maneiras e principais indicadores utilizados na obtenção de tais necessidades.

Principais indicadores no levantamento de requisitos do stakeholder

Além dos requisitos definidos na engenharia de requisitos, também é necessário abordar de forma mais profunda os requisitos diretamente ligados ao stakeholder. Estes são melhor descritos a seguir:

• Objetivos: o termo objetivo, do inglês Goal (às vezes tido como preocupação de negócios, ou fator crítico de sucesso) refere-se aos objetivos gerais de alto nível do sistema;
• Missão: como o sistema irá cumprir sua missão? Como o sistema será capaz de contribuir para as operações organizacionais?;
• Cenário operacional: definições que envolvem o alcance do produto e com quais plataformas e outros produtos o mesmo terá interações;
• Ambiente operacional e contexto de uso: definições que envolvam restrições de uso ou contexto ao sistema, como horários de funcionamento ou nível crítico de operação;
• Inserção operacional: caso o produto seja uma continuação, ou parte dos produtos de um escopo maior, tal definição demonstra em que ponto do produto do cliente será inserido;
• Performance: parâmetros essenciais na garantia do cumprimento da missão do sistema;
• Efetividade: definição de quão efetivo deveria ser o sistema atuando em sua missão, assim como quais seriam as maneiras de medir sua eficiência;
• Ciclo de vida operacional: qual será o tempo de vida do sistema? Por quanto tempo ele deve ser estável e, principalmente, ainda cumprir sua missão?;
• Características do usuário e operador: definição de quem são os usuários do sistema, quais serão seus papéis, nível de habilidade ou carga de trabalho.

Ao definir cenários, é realizada a construção de um conjunto que represente as sequências de atividade para identificar todos os serviços requeridos para o produto que podem envolver o ambiente, o sistema, as interfaces, as plataformas e outros fatores gerais que podem impactar o desenvolvimento e andamento do projeto. Cenários ajudam na identificação de requisitos que podem, por questões diversas, serem ignorados ou não capturados no processo, além de estabelecer milestones críticas para parâmetros de performance que são essenciais ao sucesso do sistema, por exemplo.

Além disso, dentro da etapa de descoberta e listagem de requisitos do stakeholder, é importante abordar as restrições que envolvem o sistema e sua construção, cenários de execução e aplicações de casos de uso. Diversos fatores podem gerar restrições ao sistema, tais como consequências de decisões e acordos contratuais, organizações externas, sistemas externos ou legados, atividades de outra fase do ciclo do sistema, restrições orçamentárias e estratégicas de aplicação e vendas ou ainda questões legais diversas.

O Business Model Canvas

Pode-se elencar como um dos principais, senão principal resultado esperado do levantamento de requisitos, a busca por erradicar ao máximo os desalinhamentos entre o que o cliente quer, o que o cliente precisa, e o que o cliente recebe ao fim do projeto.

Porém, o cliente possui uma linguagem e tem visões de TI e de software, que não necessariamente refletem as mesmas visões de engenheiros ou arquitetos de software por quem o levantamento é conduzido. Além disso, nem sempre a interação entre ambos necessariamente consegue captar a essência de alguns pontos críticos ao produto, como atividades que são interconectadas e/ou interdependentes, mesmo quando o software já esteja ou não em estado avançado de desenvolvimento.

Sendo assim, a composição de uma imagem verossímil do negócio de uma empresa é de suma importância ao processo de análise de requisitos. A modelagem de negócios torna-se um fator chave dentro do processo de criação e levantamento de requisitos do sistema. O processo geral de modelagem de negócio consiste de, através de diagramas, diálogos e reflexões, obter uma versão, geralmente gráfica, de todas as características de um produto, empresa ou empreendimento.

A composição de um modelo gráfico representativo sobre o negócio em foco é capaz de orientar e educar o profissional de forma lúdica e holística, servindo não somente como guia, porém também como agente validador de propostas futuras e ações planejadas.

Dentre as diferentes técnicas de modelagem, como BPMN (Business Process Model and Notation) e ESSO (Environment-Strategy-Structure-Operations), este artigo opta pelo CBM Canvas Business Model como solução para o problema de modelagens burocráticas ou custosas.

Características do Business Model Canvas

O Business Model Canvas foi escolhido para este artigo devido à sua flexibilidade, velocidade de composição e capacitação e possibilidade de adaptação a cenários e negócios diversos. Aplicado por diversas empresas do cenário mundial como a Intel, Ericsson, Oracle, NASA entre outras, o modelo de negócios Canvas consiste em uma maneira simples e gráfica de descobrir, conciliar e conectar conceitos e características importantes de um negócio, seja este um produto, uma empresa preste a ser lançada no mercado, ou uma grande empresa á consolidada, mantendo a mesma eficiência independentemente do tamanho do escopo ao qual ele é aplicado.

O funcionamento do Modelo Canvas baseia-se em nove blocos (Figura 2) onde cada qual descreve e conecta os pontos chaves de interesse de uma “faceta” específica do empreendimento, sendo estes: (i) parceiros chave: que impactam e aceleram resultados; (ii) atividades chave: que devem ser executadas durante o projeto; (iii) recursos chave: recursos, tanto humanos quanto financeiros e abstratos disponíveis; (iv) proposta de valor: valor agregado vendido pelo produto ou ideia; (v) relacionamento com consumidor: canais de comunicação e interação entre o produto e consumidor final; (vi) segmentos de consumidor: segmentos que definem o público alvo do produto; (vii) canais: como o produto chega ao consumidor; (viii) custo de estrutura: custos necessários iniciais do projeto e; (ix) fluxo de receita: componentes que agregam receita ao projeto.

Após finalizado o modelo, torna-se muito mais simples observar, ajustar e compreender a essência de um negócio e como uma solução computacional se conectaria ao mesmo. Dessa forma, por condensar em um único documento os principais pontos chave de um plano de negócios, o Canvas consegue realizar uma abordagem de forma menos complexa sendo ao mesmo tempo mais intuitiva, que pode ser utilizada com mais frequência no dia a dia da empresa e alterada durante a execução do projeto.

Aplicando o Canvas Req em uma reunião de projetos

Apesar da ferramenta poder ser aplicada de forma livre e em qualquer ferramenta computacional, os seguintes passos são sugeridos ao se utilizar o Canvas Req na extração dos requisitos de um projeto.

Preenchendo os blocos

O Canvas-Req é composto por blocos de conteúdo, assim como o Canvas Original. A Tabela 1 correlaciona os blocos do modelo original aos seus respectivos correspondentes no Canvas-Req, apresentados e descritos em seu conteúdo essencial nos tópicos a seguir.

Atividades

Este bloco denota quais são as atividades chave, necessárias para o cumprimento da missão do sistema (ponto elaborado pelo próprio padrão definido na literatura e neste trabalho). Sendo assim, tem-se desde a frequência de reuniões, atividades de planejamento à Scrum meetings. Neste item define-se quais são as funções necessárias à equipe, ou seja, dentro dos requisitos do produto, e quais são os componentes necessários quando traduzidos em atividades concretas a serem realizadas na construção do software.

Recursos chave

Recursos, pelo ponto de vista do Canvas-Req, englobam tudo que está à disposição da equipe, tanto client-side como company-side, a fim de ser utilizado na construção da solução. Tais recursos denotam pessoas chave específicas em ambos os recursos humanos, parceiros internos e externos, e todo e qualquer recurso corporativo que possa facilitar a realização dos objetivos finais do produto.

Diferencial

Pode-se compreender que o bloco de propostas de valor engloba todos os pontos que diferenciam, valorizam e justificam a existência dessa solução. A título de exemplo, podemos, dentro da metodologia 5W2H (Where, When, Who, Why, Where, How and How much), definir a etapa de leitura de propostas de valor do trabalho como o Why do produto.

O preenchimento deste bloco deve, de forma simples, ser capaz de definir porque o cliente precisa dessa ferramenta e porque a mesma é melhor do que as demais em relação ao mercado, estado da arte e, principalmente, às suas necessidades.

Ainda assim, faz-se importante realçar que ao demonstrar que uma solução é eficiente, tal ponto não necessariamente garante que esta seja necessária ao problema do cliente. Deste modo, torna-se imperativo a capacidade de compreender que a solução como requisito é a mais adequada aos gaps apresentados pelo comprador. Permanece então como foco de que o ponto principal é de que o cliente não necessariamente adquire o produto porque o mesmo é mais rápido, ou porque é mais versátil, mas sim porque ele resolve da melhor forma possível o problema proposto.

Canais

Tratam-se dos canais de comunicação entre o analista de requisitos e o cliente, ao passo que canais de comunicação entre o cliente o usuário final são responsabilidades alheias ao Canvas-Req e da própria análise de requisitos.

Desta forma, deve-se abordar neste bloco quais são as maneiras de garantia de transmissão clara e efetiva de informações entre empresa e equipe de produção.

Receita

Este bloco demonstra o que faz com que o aplicativo seja viável de fato, ou seja, não necessariamente receita de capital, mas a receita proposta pelo software e seu sucesso. Pontos como, por exemplo, o valor agregado de mercado adicionado à uma empresa na execução de um programa ou o aumento de vendas de um produto conectado fazem partes dos requisitos no projeto de uma solução tecnológica.

Parceiros chave

Deve-se abordar no bloco de parceiros chave todo e qualquer recurso que possa agir como multiplicador ao resultado final, porém não necessariamente compõe um elemento essencial à construção do sistema. Deste modo, os requisitos compostos neste bloco unem pessoas e recursos que farão com que ele supere os dados descritos no bloco objetivo.

Consumidor final

Este bloco define quais são os desejos e perfil geral do consumidor final da solução a ser desenvolvida. O ponto principal de existência e um dos diferenciais deste bloco no modelo é o fato de possibilitar ao analista e ao cliente a capacidade de estudar o cliente e suas necessidades, assim como sua conexão com as necessidades da ferramenta.

Objetivo

O foco deste bloco é a definição do problema à ser resolvido, ou seja, os objetivos da existência e construção do sistema em questão. Não somente a definição clara do problema a ser resolvido, ou da entrega à ser adicionada pela solução tecnológica, os elementos necessários ao resultado final do software devem ser elaborados e tratados como requisitos neste bloco.

Necessidades

Este bloco trata dos custos necessários à criação da ferramenta em si, não só dos capitais como recursos de forma geral. São consideradas reuniões específicas para obtenção de informações críticas, arquivos de planejamento, e toda e qualquer milestone concreta necessária para a obtenção dos recursos-chave.

Materiais para o levantamento

Assim como o conhecimento e domínio da ferramenta proposta, para o bom andamento do processo são necessários alguns materiais e componentes de recursos humanos para a melhor aplicação do Canvas-Req, analisados a seguir.

Componentes humanos

É sugerida a presença de dois representantes do desenvolvedor do produto, sendo estes: o analista de requisitos em si, responsável por conduzir, moderar e estimular a reunião de levantamento e; um analista auxiliar, responsável pelo preenchimento do modelo, garantia de que todos os pontos tenham sido registrados e abordados e inclusão de inputs durante o processo de criação.

Em casos específicos, a presença de apenas o consumidor do produto e o analista de requisitos é aceitável, porém é importante notar que a carga e trabalho adicional pode fazer com que o levantamento de dados e o foco nos indicadores sejam comprometidos.

Componentes materiais

Faz-se necessários os seguintes itens:

• Superfície grande onde possa ser reproduzida uma versão em branco do Canvas-Req;
• Cartões, post it’s ou outro material pequeno (preferencialmente em diferentes cores), onde os requisitos possam ser descritos; Fita adesiva ou outro item para fixar os cartões no modelo; Ambiente livre de ruído e em temperatura agradável, provido de água e qualquer outro recurso necessário para garantir a duração total da reunião.

Fluxo de processos para o levantamento de requisitos

Além dos requisitos embutidos na própria ferramenta, a relação entre os requisitos propostos pela literatura e o Canvas-Req pode ser encontrada na Tabela 2

Além do foco em como e qual indicador se extrair durante a reunião de levantamento de dados, o fluxo de ações (Figura 3) deve ser seguido da maneira mais próxima possível no intuito de garantir a melhor aplicação possível do modelo proposto.

Aplicativo ComunicaBrasil – Um estudo de caso

A metodologia descrita neste artigo para o levantamento de requisitos do stakeholder usando o Canvas-Req foi aplicada em um projeto dentro de uma empresa de desenvolvimento de software.

O aplicativo ComunicaBrasil, lançado como concorrente ao prêmio INOVApps promovido pelo Ministério das Comunicações, já havia sido planejado utilizando-se técnicas convencionais de análise e levantamento de requisitos. No entanto, com o objetivo de focar a qualidade do produto assim como o alinhamento do mesmo junto às necessidades dos usuários finais, o projeto do aplicativo passou por um replanejamento utilizando o foco do Canvas-Req apresentado neste artigo, conforme pode ser observado na Figura 4.

A diferença entre os dois sistemas, após a refatoração do projeto ficou bastante evidente, uma vez que, alguns pontos considerados como críticos pela equipe da empresa foram reformulados, afetando tanto o design da aplicação, como algumas de suas funcionalidades, uma vez que o raciocínio estratégico aplicado após a utilização da ferramenta mostrou que algumas funções e aspectos do aplicativo haviam tangenciado seu foco. Dessa forma, o Canvas-Req foi considerado pela equipe como um componente fundamental na correção e reposicionamento do aplicativo após avaliação.

Dentro da análise de requisitos, são descritos vários pontos necessários, assim como diferentes abordagens para obtê-los através de guias e padrões mundiais. Este artigo apresentou uma solução capaz de satisfazê-los sem sacrificar a interação humana e o diálogo simples e intuitivo com o cliente durante o processo.

Algumas dificuldades foram encontradas como, ainda que leves, resistências de profissionais quando já acostumados com métodos convencionais de levantamento de requisitos. Porém, o resultado final do estudo de caso mostrou-se acima das expectativas.