O levantamento de requisitos é umas das partes mais importantes do processo que resultará no desenvolvimento de um sistema. Entender aquilo que o cliente deseja ou o que o cliente acredita que precisa e as regras do negócio ou processos do negócio. Isso é o cerne que move essa importante função que faz parte da engenharia de requisitos.
Aliado ao levantamento de requisitos, existe o mapeamento dos processos que é de vital importância para a melhoria dos resultados obtidos pelo levantamento de requisitos.
Muitos sistemas são retardados em seu prazo estipulado na fase de definição do escopo do projeto ou até mesmo morrem durante seu percurso, pois a etapa de levantamento de requisitos é negligenciada ou simplesmente feita de forma ineficaz.
Existe também um personagem, que é constantemente deixado em segundo plano no mapeamento de processos, o especialista do domínio ou especialista do negócio.
O especialista do negócio é aquele profissional que possui experiência no ramo ou nicho de mercado do negócio para qual o sistema atenderá em suas funcionalidades. Um sistema de vendas, por exemplo, pode contar com um especialista do negócio que seja gerente de vendas, que já tenha sido vendedor com anos de experiência.
Algumas fábricas de software procuram analistas de sistemas que sejam especialistas no ramo de negócio do sistema que vão desenvolver. Mas esbarram em um sério problema – a dificuldade de encontrar esses profissionais, que são difíceis de encontrar.
Outra forma é usar um profissional do próprio contratante do sistema a ser desenvolvido, mas isso pode deixar à vista do cliente os problemas que ocorrem em todo o projeto. Por isso as fábricas driblam esse fato, procurando analistas de sistemas que possuam conhecimentos genéricos de negócios, bom relacionamento com equipe de trabalho e experiência em coordenar ou gerenciar projetos.
Sério? Sério!
E por quê? Porque esse profissional que vai lidar com programadores e também com especialistas de negócio que não possuem conhecimento de sistemas. Gerenciar tudo isto junto é muito, muito importante e requer habilidades especiais de gestão de negócios.
Então levantar requisitos não é função solitária? Ao contrário de que alguns acreditam, não. E a vivência em gerência de projetos é cada vez mais exigida.
Um estudo baseado em 6.700 sistemas desenvolvidos em 1997 (fonte: Jones, Carpen – 1997, Applied Software Measurement) demonstrou que os custos resultantes da má realização da etapa de levantamento de requisitos podem levar os sistemas a custar duzentas vezes mais que o necessário.
Imagine a qualidade desses sistemas? Custo alto não quer dizer qualidade.
Para desenvolver sistemas profissionais e de qualidade, precisamos levantar os requisitos de forma eficaz e com seriedade. É necessário ter bons profissionais em diversas áreas no ciclo de desenvolvimento (como analistas de requisitos, analistas de processos, analistas de testes, gerentes de projetos, programadores e analistas de qualidade) de acordo com a necessidade específica de cada projeto.
Claro que sua empresa poderá reaproveitar seus profissionais para atuar em várias etapas ou funções durante o projeto, mas com critério. Sua empresa não pode colocar o programador como analista de testes, pois dificilmente ele será imparcial na hora de avaliar a própria criação. O mesmo acontece com outras funções.
Outro fato importante é o mapeamento prévio de processos. Particularmente não acredito em um bom levantamento de requisitos desacompanhado de um mapeamento de processos. Já tive a oportunidade de ver na prática sistemas desenvolvidos sobre processos inadequados, onde o analista de requisitos considerou processos com base em entrevista com o funcionário que executava de forma inadequada um processo.
Acredito seriamente na importância do levantamento de processos, mapeamento e melhoria dos processos de negócios.
Deixo aqui minha visão sobre levantamento de requisitos e mapeamento de processos, sem esgotar o assunto que é extenso e muito interessante. Espero esse breve artigo deixe a semente plantada entre os leitores sobre a importância de levantar requisitos, processos e gerenciar projetos.
Até a próxima, dúvidas, sugestões e críticas são bem-vindas. [Webinsider]
.
Ricardo Veríssimo
Ricardo Veríssimo (ricardo@rverissimo.com.br), é escritor, palestrante e presidente da RVeríssimo Suporte e Tecnologia. Membro do Conselho de Jovens Empresários da Firjan e da rede de empreendimentos Iniciativa Jovem. Autor do livro "20 Regras de Sucesso do Pequeno Empreendedor".
20 respostas
Uma correção…
*difamado 😛
[]s
Sempre defendi o levantamento de requisitos como o alicerce de qualquer projeto bem caminhado. E concordo que sem um mapeamento bem feito as coisas não se conectam como deveriam.
O que acho triste é ainda estarmos num ponto de discussão (com nossos contratantes) a importância ou não de aplicar devidamente os processos.
Deveriamos estar num ponto de maturidade em que a discussão seria no intuito de evoluir o processo e não de aplicá-lo, concordam? Isso não deveria ser feito apenas por bitolados em gestão de projetos mas sim fazer parte da cultura, pelo menos dos líderes, responsáveis por adequar processos às suas equipes e vice-versa.
Bom, aproveitando o ensejo… gostaria de comentar sobre um ponto específico citado no artigo:
“Algumas fábricas de software procuram analistas de sistemas que sejam especialistas no ramo de negócio do sistema que vão desenvolver. Mas esbarram em um sério problema – a dificuldade de encontrar esses profissionais, que são difíceis de encontrar. ”
Lê-se: não querem pagar o preço. Ou então, quando dispostos, contratam o especialista a preço de ouro, achando que todos os seus problemas estarão resolvidos.
E muitas vezes se esquecem da cultura inexistente de planejamento e gestão de projetos na empresa que o acolhe.
O resultado é lastimável: pagam caro pra um profissional que não tem liberdade pra aplicar seus conhecimentos e métodos, pois não se encaixa nos processos falhos da empresa.
O projeto não se sustenta, do ponto de vista de monitoramento e controle.
O produto final pffff… qualidade passou longe.
E claro… no final das contas, esse profissional é descartado. E o pior: defamado.
Ou então simplesmente tem sua breve passagem ignorada pelos demais… que pelo processo falho, nem compreenderam o que aquele SER fazia ali, no cantinho dele mexendo o tempo todo com planilhas e afins.
No Blog do Ricardo Cavallini (que escreve aqui também) tem um artigo do Bruno Mendonça que comenta sobre algo parecido, mas perfis, necessidades e serviços um pouco diferentes.
Pra vocês verem como o problema com a especialização é generalizado.
http://www.coxacreme.com.br/2010/10/13/vamos-digitalizar-nossa-agencia/
Parabens pelo artigo. Pena que não sou tão otimista quanto a “plantar a semente”, pois quem deveria estar lendo isso, é justamente quem não se preocupa nem um pouco em abrir a mente (pelo menos não enquanto está lucrando, mesmo aos trancos e barrancos)…
Caros, o post em questão deixa muito claro qual é o nosso papel, realmente muito bom o texto, porém seria interessante se alguém tivesse um GABARITO para a criação de sistemas, alguém conheça algum WIZARD, ficaremos todos gratos!
Obrigado,
Fantástico o post.
Elucida claramente a visão que nós, analistas de negócios, temos que ter.
Capacidade para trabalhar em qualquer segmento e atingir a necessidade do cliente.
Posso dizer que isso é um “perfil profissional”. O portador deste perfil é apto a se entregar aos mais diversos campos onde se faz necessário a elaboração de um software.
Achei muito legal a matéria porque aborda uma questão primordial que é o conhecimento do negócio, ou seja as regras do negócio com o conhecimento dos processos é fundamental para o inicio do projeto.
BELAS PALAVRAS
Ricardo Veríssimo,era esatamente o que eu estava prucurando para melhor entender sobre levantamento de requisitos.
Achei oportuno o artigo ja que no meu estado quase não existem profissionais que atendam a demanda das empresas locais.
gostei muito do comentário que voçê fez sobre essa etapa que é muito importante para o bom desenvolvimento de um software, realmente o levantamento de requisitos nos ajuda e muito a ter uma visão ampla do sistema e de certa forma ver o que o cliente está pensando.
peço-lhe que me envie mais informações sobrs esse assunto,
grata Edwiges
Concordo plenamente com vc, Ricardo, pois o levantamento de requisitos é uma etapa fundamental para o bom desenvolvimento de um sistema seguro que atenda realmente as necessidades do cliente.
Como eu sou aluna, gostaria de ter mais informações sobre o assunto.
Parabéns pelo artigo ! Descreveu com clareza os problemas que enfrentamnos diariamente :
– Empresas que não levantam processos;
– Processos mapeados incompletos;
– Requisitos levantados superficialmente.
Estes itens juntos causam atrasos constantes e em alguns casos causam o cancelamento do projeto por completo.
No Brasil, nós conhecemos bem isso pelo dito popular: Esta lei não pegou , porque ?
– Os requisitos e os processos não estavam bem claros, bem definidos e não participaram os envolvidos e conhecedores do negócio.
Abraços !!!!
Segue abaixo um bom material de referência a Eng. de Requisitos para aqueles que desejam se aprofundar no estudo.
Kotonya e Sommerville (1998). Requirements Engineering: Processes and Techniques. Gerald Kotonya, Ian Sommerville. Wiley. 1998.
Sommerville (2001). Software Engineering. Ian Sommerville. Addison Wesley. 2001.
Thayer e Dorfman (1993). Software Requirements Engineering. R. H. Thayer, M. Dorfman. IEEE Computer Society Press. 1993.
Soares (2005). Introdução, Identificação e Análise em Engenharia de Requisitos. António Lucas Soares. 2005.
Obtido em http://pt.wikipedia.org/wiki/Engenharia_de_requisitos
Bem, considero o artigo ineteressante o comentário sobre um projeto realizado em cima de um processo indequado é o alerta do negócio, o uso de sistemas complicados é outro. Em 18 anos anos no ramo industrial e especialista na área da qualidade tive a oportunidade de experimentar as variáveis que existem desde o chão de fábrica até a Alta Direção. O segredo do negócio de desenvolver softs de sistemas é segurança da equipe atrávés do domínio das áreas envolvidas. Muitos profissionais das empresas não tem visão geral do sistema e nem como atender requisitos das normas de Gestão sére ISO/TS e como integrá-las, geralmente estão limitados a seu campo de atuação e do outro lado a Gerência geral não tem conhecimento dos detalhes que os usuários necessitam podendo criar excessivos campos de preenchimento,como também, campos faltantes ou criando burocracias de sistema e consequentemente encarecendo o projeto.
A grande realidade é que os usuário esperam que trabalhando em cima dos passos (fluxo)adotado pelo sistema não haverá não-conformidades detectadas durante o processo de auditoria e haverá aumento de produtividade que é o requisito claro para se vender um soft, rápido retorno ( depreciação do investimento)e segurança das informações.
Bem, um soft é como arte que
os artistas vivem e inspiram os que sonham.
Marcio
Prezado Ricardo,
Bom Dia.
O começo é a parte mais importante do trabalho
Platão
Bem começado…metade feito
Aristoteles
Se eles já sabiam disto, por que é tão dificil o pessoal entender.
Cordialmente,
Arnaldo
axei muito importante o artigo me esclareceu muitas duvidas!!!
eu estou procurando artigos ou qualquer conteudo que fala sobre os requisitos funcionais, não funcionais, sistema, usuario e de dominio para um trabalho…
ficarei agradecido se alguem tiver me mandar por email…
joelmartyns@yahoo.com.br
Só para esclarecer,
do ponto de vista da análise de negócio todos os requisitos são de negócio, tanto os funcionais quanto os não funcionais.
Quanto à definição de cliente e usuário, estou me baseando no ITIL que define cliente como quem compra (paga) o sistema e usuário aquele que efetivamente o utiliza.
Os interesses desses dois grupos são diferentes e devem ser tratados em momentos diferentes. Quem manda nos requisitos é o cliente, quem opina na usabilidade é o usuário.
Requisitos funcionais são uma coisa, usabilidade é outra. Primeiro identificamos os requisitos funcionais e isso pode ser feito só com o cliente, sem usuário algum por perto.
O usuário não possui poder de escolha sobre os requisitos funcionais, e sim o cliente. Os requisitos focam o o quê, focam benefícios, objetivos, resultados, quem mede isso é o cliente.
A usabilidade, depois de definido esse o quê, vai trabalhar junto aos usuários, o melhor como possível.
Cada coisa ao seu tempo.
Muito bem redigido o trecho onde foi escrito :
onde o analista de requisitos considerou processos com base em entrevista com o funcionário que executava de forma inadequada um processo. ´
Isso já aconteceu comigo, onde os profissionais que desenvolviam os processos acreditavam que estavam seguindo corretamente o processo que a metodologia determinava. E na prática, após o desenvolvimento do sistema foram descobertas diversas adaptações que eles realizaram, devida a complexidade do trabalho e a falta de um sistema automatizado, que comprometia o processo e os resultados.
EMAIL DE RESPOSTA AO COMENTÁRIO DO FABRÍCIO
Bom que você gostou do comentário, Ricardo. Seria legal colocar essas
explicações num outro comentário após o meu para enriquecer o artigo
ainda mais.
Vou acompanhar o WebInsider para ler seu próximo texto, quando for publicado.
Obrigado pela atenção.
—
Fabrício Marchezini
Em 23/11/07, Ricardo Verissimo escreveu:
Fabricio,
Obrigado por ler meu artigo.
Você está correto a visão do usuário é importantíssima. Como o artigo fala sobre BPM e Requisitos na visão interna do sistema, mas a visão externa do sistema é importante e pretendo escrever um artigo próximo exatamente sobre isso a relação entre Requisitos usando UML que faz exatamente isso dá a visão de quem interage com o sistema e BPM.
Mais uma vez obrigado.
Artigo conciso, muito bem escrito. Realmente, identificar as necessidades do cliente/contratante é fundamental para o projeto de concepção e desenvolvimento de um sistema.
Mas achei estranho o autor não citar um outro fator importantíssimo nessa história: os usuários. Se o sistema tem uma ou mais interfaces que serão manipuladas por alguém, não é possível produzir algo usável se não forem levados em conta, durante todo o processo (inclusive no estabelecimento de requisitos) as necessidades específicas, limitações e até preferências desses sujeitos.
Se um sistema é difícil, inadequado ou desagradável, as pessoas vão evitá-lo. Isso também pode determinar o sucesso ou fracasso do projeto.
Eu imaginava que design centrado no usuário e usabilidade já eram assuntos, pelo menos teoricamente, bem disseminados e aceitos no meio de tecnologia da informação.
Estou enganado?
Fico muito feliz em ler este artigo Ricardo.
Estamos trabalhando no sentido de definir um profissional responsável pela análise dos processos do negócio e pela definição do escopo dos projetos de software.
Este profissional se chama Analista de Negócios. Trabalha em um nível mais alto de abstração entre o sistema e o negócio.
Sua função se divide em duas: Modelagem do negócio e Engenharia de Requisitos.
A referência sobre este assunto é Paulo Vasconcellos e mais informações podem ser encontradas no seu blog http://finito-log.blogspot.com .
Dado percentual enorme de falhas em projetos devido a problemas de escopo, acredito que este profissional será o melhor amigo do gerente de projetos. Aqui na empresa já é.