Webinsider

Desenvolvimento - Planejamento

Levantar requisitos e mapear processos

20 de novembro de 2007, 16:51

Levantar corretamente os requisitos é umas das partes mais importantes no desenvolvimento de um sistema. Envolve o que o cliente precisa, as regras do negócio e o mapeamento de processos.

Por Ricardo Veríssimo

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]

.

Sobre o autor

Ricardo Veríssimo (ricardo@rverissimo.com.br) é consultor de tecnologia, sócio gerente da RVeríssimo Consultoria e Tecnologia Ltda e técnico de processamento de auditoria de sistemas e processos da Loudon Blomquist Auditores Independentes.

Apoio:

  • LayerDev Serviços de Webhosting Profissional

Palavras-chave relacionadas a este texto: [ programação ] [ pesquisa ]

Comentários

8 pessoas comentaram o artigo "Levantar requisitos e mapear processos"

Kerber Data: 21/11/2007 às 9:24 am

Atividade: Analista de Negócios de TI (ITBA)

Cidade: Florianópolis

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á é.

Fabrício Marchezini Data: 22/11/2007 às 1:25 pm

Atividade: Designer

Cidade: Belo Horizonte

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?

Ricardo Verissimo Data: 23/11/2007 às 10:04 am

Atividade: Auditor de Sistemas

Cidade: Rio de Janeiro / RJ

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.

Jefferson Petilo Data: 25/11/2007 às 1:36 pm

Atividade: Analista de Sistemas

Cidade: Salvador

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.

Kerber Data: 27/11/2007 às 3:17 pm

Atividade: Analista de Negócios de TI (ITBA)

Cidade: Florianópolis

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.

Kerber Data: 27/11/2007 às 4:12 pm

Atividade: Analista de Negócios de TI (ITBA)

Cidade: Florianópolis

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.

joel Data: 24/01/2008 às 5:52 pm

Atividade: estudante

Cidade: major vieira

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

Arnaldo Ramacciotti Junior Data: 13/05/2008 às 12:09 pm

Atividade: Analista de Requisitos

Cidade: São Paulo Capital

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

Avisos
Os ítens com asterisco ( * ) são campos de preenchimento obrigatório.
Todos os links inseridos nos comentários possuem o atributo rel="nofollow" para impedir com que user agents (como os mecanismos de busca) sigam os links inseridos para desestimular spammers.
Todos devem se identificar através de e-mail válido.
Os e-mails dos usuários não serão divulgados no site.
Comentários:

Preencha os dados abaixo e clique em enviar

Outrolado.com.br

Leia

Al Ries e o pensamento a longo prazo. Hein?Nosso amigo foi assistir palestra do famoso estrategista de marketing, que defende o conceito de paciência e o pensamento a longo prazo. Neste ponto ele não sensiblizou agências, anunciantes, veículos e produtoras. Por Ricardo Cavallini

É possível realmente fazer planejamento de carreira?Após cinco anos em uma empresa você já provou o que tinha que provar e deve avaliar se novos projetos trarão motivação e realização profissional; caso contrário, é hora de buscar outros horizontes.
Por Armando Terribili Filho

Boas práticas no desenvolvimento de websitesUma lista de pontos a observar que podem significar o sucesso do site que você está criando agora para o seu cliente, especialmente se orientado a vendas. Por Marcelo Mattei

Para que serve o profissional de usabilidadeA demanda por profissionais de usabilidade vem crescendo no Brasil entre as grandes empresas, que contratam consultorias para melhorar seus sites. Em algumas delas já é possível encontrar um especialista nas equipes de internet. Por Mercedes Sanchez

ITIL e Ética, mais do que um jogo de palavrasO que e Ética dos dicionários tem a ver com o framework para gestão de serviços de TI e seu conjunto de melhores práticas para operações e gerenciamento? Por Patricia de Aquino Mendes

O escritório de projetos no planejamento estratégicoO escritório de projetos montado dentro das empresas tem a missão de manter a visão integrada do plano estratégico em toda a cadeia de valor e garantir os prazos e os custos definidos. Por Clovis Bergamo Filho

O controle de qualidade em projetos web (final)Gastar tempo com Quality Assurance é evitar dores de cabeça e correrias desnecessárias ao publicar um projeto que “não funciona”. O custo deste erro é multiplicado quando há insatisfação por parte dos usuários. Por JC Rodrigues

Comércio eletrônico vai além da simples vendaExplique para o seu cliente: na maioria dos casos, o papel principal de um site não é o de vender online, mas sim o de ajudar a vender no mundo real. Por Sidney Benetti

Vicente Tardin

Em busca do contrato perfeito: um livro em capítulosO Webinsider apresenta em capítulos o livro de Carlos Nepomuceno sobre como redigir contratos e minutas rápidas cada vez mais bem feitos… e conquistar mais firmemente a confiança e a assinatura do cliente. Por Vicente Tardin

Sua loja transmite confiança ao usuário?Seu cliente tem bons produtos e uma loja funcionando direitinho. Mas será que a loja transmite uma boa sensação de segurança? É subjetivo mas nem tanto. Por Dailton Felipini

Como ampliar o Business Intelligence nas empresasUma das principais funções das ferramentas de BI é permitir que os funcionários respondam às suas próprias perguntas. Funcionam bem nas empresas onde a maioria se dispõe a pensar e a perguntar. Por Saulo Figueiredo

Procura-se: escreva aqui sua idéia web 2.0Ações de propaganda quando envolvem mídia social bem que poderiam ir além do “visite, escreva uma história, envie sua foto, vídeo, história e diga como vai ser o futuro”. Por JC Rodrigues

Gerenciar qualidade no desenvolvimento de sistemasAo incluir o gerenciamento da qualidade nos processos de desenvolvimento, mesmo de forma experimental, sua empresa vai obter resultados muito positivos no sistema e no ambiente de trabalho.
Por Ricardo Veríssimo

Webinsider