O cliente: trabalhar com ele e não para ele. Comunicar Requisitos em Projetos de Software.

Neste artigo será realizada uma análise à comunicação de requisitos entre uma entidade-cliente e a equipa, sendo que na equipa poderá existir alguém diretamente responsável pela recolha das necessidades do cliente, comummente denominado de Analista de Negócio (AN) ou Business Analyst, ou Engenheiro de Requisitos (ER). São referidas três possíveis “vias” para a comunicação dos requisitos: 1) A comunicação das necessidades pelo Cliente ao AN/ER; 2) A comunicação dos requisitos recolhidos pelo AN/ER ao Cliente para validação; 3) A comunicação dos requisitos recolhidos pelo AN/ER à equipa de desenvolvimento.

Critérios para sucesso/insucesso

Finalizado um projeto, realizam-se sessões de lições aprendidas. O projeto foi bem ou mal sucedido? Para a organização, a definição do sucesso/insucesso pode basear-se nos critérios:

  • Produto/protótipo/serviço com qualidade;
  • Cliente ficou satisfeito;
  • Cliente regressa;
  • Produto/protótipo/serviço fiável;
  • Lucro;
  • Organização/gestão de topo ficou satisfeita;
  • Boa reputação para a organização.

Mais do que perceber se o projeto foi bem ou mal sucedido, interessa também compreender as circunstâncias que levaram a esse sucesso/insucesso. Para esse efeito, o relatório anual CHAOS Report do Standish Group [1] é uma referência que define os fatores de sucesso de um projeto. Do ponto de vista  da análise de requisitos, o fator que surge no topo deste relatório é o  envolvimento do cliente. Este relaciona-se sobretudo com a comunicação, ter o cliente “perto” da equipa de desenvolvimento e envolvê-lo em todo o processo. O envolvimento relaciona-se com o sucesso do projeto na medida em que, se o cliente está a par do projeto, sabe exatamente o resultado que lhe será entregue e pode comunicar atempadamente alguma mudança que queira propor.

O cliente deve ter espaço para ouvir e ser ouvido, deve ser tratado como parceiro (trabalhar com ele e não para ele).

 

O “envolvimento” surge no topo da lista do CHAOS Report muito devido à gestão das expectativas durante o projeto. Gerir as expectativas do cliente é garantir que os pressupostos detidos por este, num projeto de software, são realistas e consistentes com a entrega de software. Sendo o processo de requisitos um canal primordial entre o cliente e a equipa, poderá existir uma relação entre a gestão de expectativas e a forma como os requisitos são comunicados? E como definir então a comunicação de requisitos para potenciar o sucesso do projeto?

 

“A problem well stated is a problem half solved.”

Charles F. Kettering

 

Um requisito retrata uma condição ou capacidade que é necessária para satisfazer um objetivo ou necessidade. A comunicação das necessidades, através da definição de requisitos, possui elevada importância para desenvolvimento da solução a que a equipa se propôs. Os requisitos são transversais a qualquer projeto de engenharia, seja tratando-se de projetos de software, eletrónica, mecânica, civil, etc. Cada projeto de engenharia deve contemplar tarefas de requisitos, seja relacionados com o levantamento, documentação, negociação, validação, comunicação, entre outros [2]. A comunicação (verbal ou escrita, formal ou informal) é o meio para a passagem de informação entre o cliente e a equipa de desenvolvimento. Um dos problemas mais críticos relativos a requisitos é que depende fortemente da interpretação de quem os levanta ou documenta. As pesquisas sobre problemas em requisitos remete-nos para a seguinte ilustração:

 

cartoon_projetos-01

Fonte img: projectcartoon

 

“The most important single aspect of software development is to be clear about what you are trying to build.”
Bjarne Stroustrup

 

 A comunicação das necessidades pelo Cliente ao AN/ER

O Business Analysis Body of Knowledge (BABoK) [3], da IIBA®, um guia de referência para requisitos, categoriza requisitos em: negócio (Business Requirements); stakeholders (Stakeholders Requirements) e solução (Solution Requirements).

O BABoK, bem como o Guide to the Software Engineering Body of Knowledge (SWEBoK), apresentam as seguintes técnicas de levantamento de requisitos:

  • Brainstorming
  • Análise documental
  • Grupos de foco
  • Análise de interfaces
  • Entrevistas
  • Observação
  • Prototipagem
  • Workshops de requisitos
  • Questionários

Todas estas técnicas têm vantagens e desvantagens, e são mais adequadas em determinadas circunstâncias do que outras (não serão aqui descritas, dado a extensão do número de técnicas, pelo que o BABoK descreve detalhadamente essas situações para cada técnica no seu capítulo “Techniques”), pelo que o processo de (comunicação dos) requisitos a adotar depende da especificidade de cada projeto. Deve-se ter em atenção quem participa, quantos participam, os processos a suportar, entre outros. Por exemplo, uma entrevista é vantajosa no sentido do contacto direto, permitindo uma obtenção de respostas mais pessoais, bem como a observação de gestos ou o tom de voz. Por outro lado, se o número de participantes for elevado, então a opção mais vantajosa é a realização de questionários. Se a ideia se focar muito nos fluxos e em tarefas sequenciais, a observação dos processos é a mais adequada.

A comunicação dos requisitos recolhidos pelo AN/ER ao Cliente para validação

O passo seguinte na tarefa do AN/ER é de registar o que foi levantado na interação cliente–>AN/RE anterior. A este registo é dado o nome de documentação dos requisitos, e refere-se a um conjunto de informação documental que vai servir de evidência no “contrato” celebrado entre cliente e equipa. A documentação dos requisitos serve dois propósitos. 1. A validação de requisitos com o cliente; 2. Passar a informação à equipa de desenvolvimento para a implementação da solução (as últimas duas “vias” que são referidas no inicio deste artigo). Este último propósito, não constituindo uma comunicação cliente-equipa, não é analisado a fundo neste artigo.

A documentação de requisitos mais direcionados para os clientes seguem formatos mais de alto-nível e sem informação mais técnica. Os exemplos mais significativos são: diagramas UML (casos de uso e atividades), user stories, prototipagem (através de wireframes ou mockups).

É sobre o conjunto de requisitos documentados que se baseia a segunda “via” possível relatada neste artigo, a comunicação AN/RE –> cliente. Neste caso, a comunicação não está associada ao levantamento dos requisitos e das necessidades, mas sim em validar a informação que foi recolhida nas interações anteriores. Este tipo de comunicação é de grande relevância no já referido envolvimento do cliente, pois a forma (bem como a frequência) como esta interação é realizada possui implicações diretas na gestão das expectativas do cliente. Aqui, também o BABoK e o SWEBoK propõe técnicas idênticas para a validação de requisitos, sendo que, ao contrário da interação anterior, o AN/ER pode utilizar complementarmente:

  • Revisão dos requisitos (Structured Walkthrough)
  • Prototipagem
  • Indicadores de desempenho
  • Análise de riscos

Note-se que não existe grandes vantagens em comunicar requisitos demasiado técnicos ao cliente, uma vez que esta “linguagem” nem sempre é percetível pelo mesmo. A documentação mais técnica deve ser direcionada para a equipa de desenvolvimento, em que a comunicação dos requisitos é efetuada numa ótica de “passagem de conhecimento” adquirida na interações anteriores (cliente–>AN/RE–>cliente). Os exemplos mais significativos são: diagramas UML (classes, componentes, deployment, sequência), user stories quando acompanhados de detalhes técnicos e testes de aceitação, user stories técnicas (technical user stories, i.e., histórias que derivam diretamente de questões de implementação ou da arquitetura da solução e não de funcionalidades).

Importa reter…

A maturidade dos processos adotados no âmbito de requisitos (ou qualquer outro) reflete-se sempre na eficiência organizacional desses processos num projeto. Em relação aos critérios apresentados no início deste artigo, a forma como os processos são executados  possui implicações diretas na apresentação de produto/protótipo/serviço com qualidade e fiável, satisfação da organização/gestão de topo e no lucro. No entanto, as especificidades de cada projeto não sugerem a implementação de um processo único (“one size fits all”), mas sim ter em consideração um conjunto de critérios para “modelar” o processo de requisitos conforme o contexto onde atua.

Por outro lado, o processo de requisitos deve contemplar interações com cliente, através de comunicação verbal ou escrita, formal ou informal. Uma boa comunicação com o cliente não pode ser vista apenas numa perspetiva de “boas-práticas”. Deve sim fazer parte integrante da visão organizacional, com vista à eficiência do processo de requisitos, pois a gestão das expectativas tem implicações, não só no sucesso do projeto, relativamente à satisfação e fidelização do cliente, como também na reputação e notoriedade da organização.


Referências:

[1]         Standish Group, “CHAOS Report 2014,” 2014.

[2]         J. M. Fernandes and R. J. Machado, Requirements in Engineering Projects. Springer International Publishing, 2016.

[3]         IIBA, A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0. 2009.

 


nuno_santos2

Nuno Santos | Investigador D.I.A EPMQ “Engineering Process Maturity and Quality” @CCG

  • Investigador e Analista no CCG: Centro do Computação Gráfica no D.I.A EPMQ e grupo SEMAG, Nuno Santos é formado em Tecnologias e Sistemas de Informação.  Atualmente frequenta o PhD TSI (PDTSI) na Universidade do Minho, com a tese “Adoção de Arquiteturas Lógicas em Métodos Ágeis”. Encontra-se, igualmente em processo de certificação “Certification of Competency in Business Analysis – CCBA®”. Os seus interesses de investigação centram-se na gestão de processos de negócios, modelação de negócio, análise de requisitos, e arquiteturas de software.

 

There are 2 Comments

  1. Posted by Teresa Marta

    Estimado Nuno Santos, após 13 anos a gerir uma empresa de IT, este seu artigo fez-me recordar as “lutas” entre produção/equipa comercial e cliente! A velha questão da relação entre o que eu digo, o que o outro ouve e aquilo que afinal percepcionou.
    Muito pertinente, muito actual, muito real. Parabéns!

    • Posted by Nuno Santos

      Cara Teresa Marta, fico grato que tenha apreciado o artigo. Também eu já sofri dessas “lutas” e verifiquei que, dentro dessas lutas, como função de “mediador”, haveria aspetos a melhorar. Tendo verificado que a mesma fórmula não funcionava para todas as situações (se assim fosse, o trabalho de análise não seria tão desafiante!), o facto de possuir um conjunto de sugestões, para atacar consoante o contexto, já é grande ajuda. Cumprimentos, Nuno Santos