Classificar Requisitos do Utilizador


O processo de recolha de requisitos é interativo sendo aprofundado à medida que as diversas partes interessadas vão transmitindo as suas necessidades. Uma ferramenta útil, e que nos permite avaliar se o processo de recolha de requisitos está mais ou menos completa, consiste na catalogação dos requisitos por tipo de acordo com aquilo que podemos chamar a roda de requisitos.

Esta classificação não garante que, a um dado momento do projeto, os requisitos estejam completos, isso depende de muitos outros fatores, nomeadamente de uma correta identificação das partes interessadas no projeto e da utilização correta das diversas ferramentas que estão ao dispor do gestor de projeto e da sua equipa para a coleta dos requisitos do projeto e do produto ou serviço que se pretende criar.


Por diversas razões nas quais se inclui natureza muitas vezes pouco explicita do conhecimento em poder dos indivíduos (ver artigo sobre a natureza do conhecimento nas organizações), não podemos esperar que os utilizadores nos forneçam informação sucinta, completa e bem organizada. A classificação dos requisitos coletados permite ter uma noção mais concreta do trabalho realizado e alerta-nos para eventuais défices ou falhas nos requisitos recolhidos.

A Roda dos Requisitos não é mais do que a identificação dos tipos de requisitos que habitualmente estão presentes nos projetos e nos produtos ou serviços que criamos. O gestor de projetos deve ir catalogando os requisitos que captura de acordo com a tipologia proposta. A um dado momento pode avaliar se os requisitos recolhidos já abarcam totalidade dos tipos identificados na Roda dos Requisitos questionando-se, caso isso não aconteça, se a coleta de requisitos está completa ou se ainda são necessários aprofundamentos.

Qualquer projeto, produto ou serviço deve ter um ou mais requisitos associados à maioria dos tipos de requisitos abaixo especificados:

Requisitos de Negócio: Tudo o que descreva benefícios financeiros, de mercado, de negócio, que a organização ou os seus clientes pretendem obter com o produto. Frases como as que abaixo se apresentam retratam requisitos de negócio:
  • Aumentar a quota de mercado em X%;
  • Poupar Y% por ano em eletricidade que agora é desperdiçada;
  • Poupar Z% por ano em despesas de manutenção.
Casos de Uso e Cenários: São geralmente atividades de negócio que o utilizador executa. Reconhecem-se pedindo ao utilizador que descreva ou observando-o no decurso do seu trabalho diário. São geralmente apresentados de forma genérica e necessitam frequentemente de ser pormenorizados. Frases como as que abaixo se apresentam retratam casos de uso e cenários:
  • Necessito imprimir etiquetas para as encomendas;
  • Faço a gestão da lista de clientes para os diversos médicos;
  • Todas as semanas procedo à calibragem do sistema de controlo.
Regras de Negócio: Tudo o que seja questões fundamentais para o negócio. Em projetos de desenvolvimento ou implementação de software refere geralmente a questões que estão diretamente ligadas às funções que é necessário implementar no sistema. Frases como as que abaixo se apresentam retratam regras de negócio:
  • É necessário respeitar a norma X;
  • SE for verdadeira ENTÃO ;
  • Esta é a fórmula para calcular os juros a pagar.
Requisitos Funcionais: Descrevem comportamentos observáveis num determinado contexto. Descreve a forma como o sistema ou o produto se deve comportar / responder. Frases como as que abaixo se apresentam retratam requisitos funcionais:
  • Se a temperatura ultrapassar os 40 graus centígrados o sistema deve desligar;
  • Deve poder selecionar / ordenar por idades;
  • O Sistema deve enviar automaticamente um e-mail sempre que...

Atributos de Qualidade: Descrevem caraterísticas desejáveis do sistema. Geralmente são referidas pelos utilizadores de forma bastante genérica e recorrendo a adjetivos (rápido, Fácil, Seguro). O responsável pela coleta do requisito deve preocupar-se em aprofundar, concretizando, o que esses adjetivos querem dizer na prática.

Em relação aos atributos de qualidade visite a página sobre qualidade deste blog.

Requisitos de Interface: Descrevem as interligações entre o sistema, produto ou serviço que está a ser criado. Inclui-se aqui as ligações do sistema a outros sistemas e as ligações com os utilizadores humanos. Frases como as que abaixo se apresentam retratam requisitos de interface:
  • Deve informar-me por e-mail ou SMS aquando do recebimento de uma nova encomenda;
  • Deve poder ler ficheiros em formato Excel;
  • O aspeto deve ser conforme com o livro de estilo da organização

Constrangimentos: Descrevem questões que legitimamente restringem as opções dos técnicos. Os responsáveis pela coleta dos requisitos devem ter presentes que constrangimentos desnecessários inibem a obtenção da melhor solução pelo que a validade dos constrangimentos descritos pelos utilizadores deve ser questionada e avaliada de forma critica. Frases como as que abaixo se apresentam retratam constrangimentos:
  • O ficheiro submetido eletronicamente não pode exceder os 10 Mb;
  • O sistema de Base de Dados deve ser XXXXX;
  • Deve ser desenvolvido na linguagem YYY.
Definições de Dados: Sempre que o utilizador descreve formatos, tipos de dados, limites de valores aceitáveis ou valores de defeito. Ter em atenção que a maioria das definições de dados se traduz em constrangimentos aos quais se aplica o referido anteriormente sobre constrangimentos desnecessários. Muitas das definições de dados correspondem a requisitos funcionais. Frases como as que abaixo se apresentam retratam definições de dados:
  • Formato da informação para a morada dos clientes;
  • Formato para a numeração das ordens de encomenda.

Ideias / Soluções: Esteja atento às ideias e as possíveis soluções que lhe são apresentadas pelo utilizador no decurso da coleta de requisitos. Essas ideias, mesmo que a partida lhe pareçam inadequadas (os utilizadores raramente sabem expressar as ideias que têm de forma completamente entendível para quem faz a recolha do requisito), podem conter dentro de si a solução para um determinado problema ou um aspeto inovador que fará a diferença na solução que está a ser desenvolvida.

Postagens mais visitadas deste blog

PMBOK v6: 7.4 Controlar os Custos do Projeto

PMBOK: Tipos Contratos Preço Fixo