O que é levantamento de requisitos
Antes de falarmos sobre o levantamento de requisitos propriamente dito, é importante entendermos o que é um requisito no contexto do desenvolvimento de softwares. Sendo assim, um requisito é uma condição ou capacidade que deve ser alcançada pelo software que está sendo desenvolvido.
Em outras palavras, um requisito é algo que um sistema ou componente deve possuir para satisfazer o que foi negociado quando o cliente contratou sua solução tecnológica.
Na etapa de levantamento de requisitos, o time de desenvolvimento precisa entender o negócio que o sistema vai atender, pois isso é fundamental antes que se coloque a mão na massa. Esse levantamento é o ato de explorar as necessidades dos usuários em questão.
Agora que você já entendeu do que estamos falando, vamos nos aprofundar um pouco mais na ideia. Segue comigo!
Requisitos dos stakeholders
Toda a concepção e desenvolvimento da ideia de levantamento de requisitos tem como base as instruções da PMBOK, organização internacional que regula a qualidade da gestão de projetos. Essa sigla significa Project Management Of Knowledge (Gerenciamento de Projetos de Conhecimento), que é mais uma padronização do que uma metodologia.
Dentro dessa concepção, nós temos o conceito de stakeholder, que são todos os agentes envolvidos no projeto, direta ou indiretamente. Um stakeholder pode ser um desenvolvedor, um gerente, um concorrente, um cliente ou até mesmo o governo, que afinal de contas recebe tributos de toda organização empresarial.
Quem podem ser os stakeholders de um projeto?
Quem paga
Quem pede
Quem executa
Quem usufrui
Dessa forma, cada stakeholder possui seus próprios requisitos, o que nos leva ao próximo tópico, o das necessidades e expectativas.
Necessidades e expectativas
Muitas pessoas confundem os termos necessidades e expectativas. Mas eles não são a mesma coisa.
Quais as diferenças? Vejamos o exemplo abaixo:
Necessidades: O que o colaborador precisa para executar sua atividade? Recursos, matéria-prima, local de trabalho adequado, comunicação etc.
Expectativas: O que o colaborador espera da Empresa: remuneração justa, equipamentos de proteção (EPIs) em boas condições, incentivo à qualificação, possibilidades de crescimento etc.
No exemplo acima, estamos falando de uma relação trabalhista em que existem as necessidades para o colaborador executar suas atividades e as expectativas que esse trabalhador tem em relação às condições que a empresa vai fornecer.
Em um projeto de desenvolvimento de software, existem as necessidades que o cliente possui, que são as dores que o motivaram a contratar a solução, e as expectativas que esse cliente possui quanto ao funcionamento do software.
As duas coisas nem sempre vão caminhar juntas.
Requisitos funcionais e não funcionais
Requisitos funcionais são as funcionalidades que o sistema necessariamente deve ter, como um cadastro de clientes para uma loja ou uma consulta ao saldo da corrente corrente do aplicativo do banco, para citar dois exemplos.
Já os requisitos não funcionais são as características do sistema, como restrições de segurança, que não são itens essenciais, mas que tornam a aplicação mais robusta. Um exemplo de requisito não funcional é o tempo de carregamento de uma página. Outro bom exemplo são as políticas de segurança e as normas de acesso.
Vistos os requisitos funcionais e não funcionais, vamos falar sobre os requisitos de usuários, que são os stakeholders com menos domínio técnico no processo e, por isso, terão requisitos em uma linguagem comum.
Requisitos de Usuários
O primeiro aspecto claramente identificável nos requisitos de usuários, conforme eu adiantei no final do tópico anterior, é o linguajar natural, já que estamos falando de pessoas que não são desenvolvedores de software.
Dessa forma, como estamos falando de um tipo de stakeholder bem específico, o time de desenvolvimento precisa estar bem atento à comunicação para que não haja ruídos no processo de levantamento de requisitos.
Elicitação de requisitos
A elicitação de requisitos é a primeira atividade no processo de engenharia de requisitos, na qual se busca entender quais são as necessidades do usuário que devem ser atendidas pelo software que será desenvolvido.
Sendo assim, existem algumas técnicas para elicitar requisitos que podem deixar o processo mais fluido que podem ser condensadas em quatro etapas. Veja abaixo:
Entrevista/Questionário: nesta etapa da elicitação, o time de desenvolvimento vai coletar todas as informações necessárias para entender não somente o que motivou o cliente a buscar a solução, mas também para entender o que ele pretende melhorar após a finalização do serviço (lembra das diferenças entre necessidades e expectativas?);
Visita/Observação no local de execução da atividade: não basta ouvir o que o cliente tem a dizer, é preciso ver in loco. Por isso, a segunda etapa é conhecer de perto a realidade do negócio do seu cliente. Se é uma fábrica, como é o processo industrial, como as equipes se organizam, como os futuros usuários fazem as coisas agora? Se é uma loja, em que local fica o escritório, os vendedores que terão acesso à solução são os mesmos do caixa, ou são profissionais diferentes? E por aí vai.
Dinâmicas em grupo/JAD (Joint Application Design): Joint Application Design - JAD (Projeto de Aplicação Conjunta em português) é um processo que visa coletar requisitos de negócios durante o desenvolvimento de um software.
Através de workshops JAD, os trabalhadores do conhecimento e especialistas de TI são capazes de resolver quaisquer dificuldades ou diferenças entre as duas partes em relação ao novo sistema de informação.
Protótipos: trata-se do modelo que vai servir de base para o lançamento da aplicação completa, ou seja, uma espécie de “rascunho” do projeto.
Esse é o passo a passo do processo de elicitação de requisitos.
Diferenças entre Requisitos do negócio, do usuário e de sistema
Conforme eu já adiantei um pouco acima, existe uma diferença comunicacional entre os diferentes stakeholders do projeto.
Vamos analisar brevemente as diferenças entre Requisitos do negócio, do usuário e de sistema, cada um com suas peculiaridades técnicas.
Requisitos do negócio
Requisitos do usuário
Requisitos de sistema
Requisitos do negócio
Trata-se das características do negócio que está contratando o software em questão.
Os desenvolvedores precisam primeiro entender como é a dinâmica desse negócio para depois desenvolver o sistema com base nisso, nunca o oposto.
Requisitos do usuário
Conforme eu disse mais acima, os requisitos do usuário são os que menos possuem um grau de tecnicidade em sua descrição, pois estamos falando de indivíduos leigos no jargão de TI.
Por isso, os desenvolvedores precisam redobrar a atenção, a fim de interpretarem o que o usuário está pedindo e transcreverem para um linguajar técnico sem ruídos.
Requisitos de sistema
Ao contrário dos requisitos do usuário, os requisitos de sistema terão o linguajar mais técnico do processo.
Aqui, os desenvolvedores “estão em casa”. Mas cuidado com o excesso de autoconfiança!
Para finalizar
Esse artigo é apenas uma introdução ao tema. Sugiro que se aprofunde sobre cada ponto que foi abordado aqui para entender realmente do que eu estava falando.
Nos vemos no próximo artigo.
Um abraço!
Davi Valukas - Alpha EdTech
