Introdução

Quando falamos das aplicações de BPM no post “Para que serve BPM?”, nós falamos que um dos motivos que levam as empresas a se interessarem pelas iniciativas de BPM é a ideia de automatizar seus processos. Mas você sabe por que uma empresa que está interessada em desenvolver ou contratar um sistema de informação para automatizar os seus processos precisa investir em iniciativas de BPM? 

Para desenvolver ou contratar um sistema é necessário conhecer os requisitos que esse sistema deve atender, ou seja, o que é necessário que o sistema faça, qual é o seu escopo e quais são as funcionalidades que devem estar contidas no sistema. Mas como definir isso de um sistema que ainda é desconhecido? Devemos olhar tipicamente para o processo de negócio porque precisamos entender como esse sistema vai dar apoio tecnológico, ou seja, quais são as atividades do processo que serão automatizadas por esse sistema.

Mapeamento de Sistemas

Quando temos o objetivo de entender um processo, nós precisamos fazer o trabalho de levantamento, modelagem e validação. Quando se modela o processo sabendo que o objetivo é o desenvolvimento de um sistema há a necessidade de um olhar diferente para esse processo: vamos nos preocupar em saber, por exemplo, quais outros sistemas são utilizados hoje nesse processo, se há sistemas legados que serão substituídos e quais integrações serão necessárias. Então, para extrair requisitos a partir de processos temos que nos preocupar em mapear os sistemas que já participam daquele processo.

Mapeamento de Dados

Além de mapear os sistemas, também devemos nos preocupar em mapear dados, ou seja, identificar quais são as informações que entram e saem de cada atividade. Dessa forma, podemos compreender claramente o que cada atividade utiliza de informação e o que ela produz. Esse entendimento nos leva a mapear os dados e informações relativos àquele processo de forma mais precisa e abrangente. Em muitos casos, pode ser criado até mesmo um modelo conceitual de dados para o novo sistema a partir do processo e dos seus termos de negócio constantes no glossário.

Mapeamento de Regras de Negócio

“Uma regra de negócios é uma condição que deve ser satisfeita quando uma atividade de negócios está sendo executada. Uma regra pode impor uma política de negócios, tomar uma decisão ou inferir novos dados a partir de dados existentes.” – IBM Knowledge Center

Outro ponto importante durante o levantamento de processos para extrair requisitos de sistema é o mapeamento das regras de negócio. Ou seja, temos que compreender quais são as regras de negócio relacionadas com o processo que o sistema irá implementar.

Extrair requisitos a partir de processos

Uma vez que se entenda o processo e tenha todas essas informações mapeadas se inicia a etapa seguinte onde um analista de requisitos começa a extrair ou derivar os requisitos de negócio a partir desse processo.

Sabendo quais são as atividades envolvidas no processo, o que essas atividades usam como informação de entrada e saída, quais são as regras de negócio, quem executa essas atividades e como essas atividades devem ser feitas, então é possível saber como o sistema novo que vai ser desenvolvido ou contratado terá que implementar esse processo. Para cada atividade deve ser analisada a sua necessidade de automação e, se aplicável, descritos os seus requisitos de negócio pertinentes.

A descrição destes requisitos deve seguir o padrão adotado pela organização e estar alinhada às boas práticas de mercado. Não existe um número mágico de quantos requisitos (no mínimo ou no máximo) devem existir em cada atividade.

Alinhamento das equipes de processos e de requisitos

Em alguns casos, quando há duas equipes envolvidas no projeto, sendo uma equipe de processos e uma equipe de requisitos, é recomendado que as duas equipes atuem em conjunto. Se houver alguma questão específica que a equipe de requisitos queira levantar, já se aproveita a interação com o cliente e evita-se repetidas voltas no cliente para fazer perguntas similares. Essa relação entre as equipes também é importante para que ambos os times mantenham-se alinhados a todas as definições, evitando problemas de comunicação.

Extrair requisitos de sistema a partir de processos é uma novidade?

Será que a extração de requisitos a partir de processos é uma novidade? Não! O framework do RUP (Rational Unified Process), criado nos anos 90, já apresentava a abordagem de primeiro pensar nos processos de negócio para depois pensar nos requisitos do sistema. Entretanto, até hoje existem muitos casos de empresas que iniciam o desenvolvimento ou contratação de sistemas sem olhar para o processo. 

Temos um caso interessante de um cliente que uma vez nos pediu ajuda porque ele foi ao mercado buscar uma solução de software, enviou a especificação para o mercado e recebeu 10 propostas diferentes variando entre 50 mil e 1 milhão de reais. Como você decidiria qual empresa contratar?

O que aconteceu nesse caso foi que os requisitos não estavam bem especificados e os fornecedores entenderam estes requisitos de maneiras muito diferentes. Algumas entenderam como algo muito simples e outras entenderam como algo muito complexo. Por isso, houve uma variação de preço tão grande. Neste caso vemos que ele não conseguiu detalhar os requisitos nessa especificação que lançou ao mercado. Ele não entendia bem o escopo do sistema porque ele não conhecia o processo de negócio que estava por trás. Por outro lado, os fornecedores também tentaram estimar um desenvolvimento sem compreender exatamente o que o sistema iria fazer.

A partir deste e de muitos outros casos percebemos que existem muitas empresas que ainda não olham para os processos antes de pensar em sistemas, ou seja, não aproximaram negócio e TI o que causa diversos problemas como esse e pode culminar em sistemas desenvolvidos com funcionalidades desnecessárias e outras faltando.

Conclusão

Um modelo de processos é um instrumento muito rico. Veja quantas coisas ele pode nos oferecer em relação ao levantamento de requisitos de sistema: requisitos de negócio, regras de negócio e modelo conceitual de dados.

Gostou do assunto e gostaria de mais informações sobre ele? Nós temos um curso na dheka que é o derivação de requisitos a partir de modelos de processos de negócios, onde detalhamos  uma abordagem passo a passo sobre como representar cada elemento e como você levanta cada um desses itens que auxiliam na extração dos requisitos de um sistema.