ABORDAGEM DAS REAS DE ENGENHARIA DE REQUISITOS E ENGENHARIA DE PROCESSOS DE NEGCIO COM NFASE NAS RELAES PERCEBIDAS ENTRE O LEVANTAMENTO

E ANLISE DE REQUISITOS E A MODELAGEM DE PROCESSOS DE NEGCIO, AMBOS, APOIANDO O DESENVOLVIMENTO DOS SISTEMAS DE INFORMAO. Andr de Oliveira Clovandi Renato Cesar da Silva

RESUMO As organizaes tm cada vez mais, buscado aprimorar suas atividades com vistas ao mercado ou ao bem pblico. Para isso, os sistemas de informao tm ocupado um lugar de destaque colaborando com a sua funo de automatizar e tornar as organizaes cada vez mais capazes e eficientes para o cumprimento de suas necessidades. Com relao a isso, observou-se, aliada aos sistemas, a necessidade do aprimoramento dos processos de negcio nas organizaes buscando sua melhor definio para s ento tentar levantar as necessidades e solues informatizadas. Este artigo aborda as reas de Engenharia de Processo de Negcios e Engenharia de Requisitos, focando nas relaes que se podem observar entre a modelagem de processo de negcio e o levantamento e elicitao de requisitos com a finalidade de se obter um produto final, ou seja, um sistema ideal para a organizao. Palavras-chave: Engenharia de Requisitos. Engenharia de Processos de Negcio. Processos de Negcio. Modelagem de Processos. Levantamento de Requisitos.

Abstract Organizations have increasingly sought meliorate its activities with a view to the market or the public good. Therefore, the information systems have occupied a prominent place, collaborating with its function to automate and make organizations increasingly capable and efficient for the fulfilment of their needs. With relation to that, observed, together with the systems, the need for the improvement of business processes in organizations looking for a better definition for only then try raise the needs and solutions computerized. This article addresses the areas of process engineering business requirements and Engineering focusing in relations to be observed between process modeling of business and the lifting and elicitation requirements in order to obtain a final product, that is, an ideal system for the organization. Keywords: Engineering of requirements. Engineering of Business processes. Business processes. Processes Modeling. Galtering of requirements.

E-mail: clovandi@gmail.com E-mail: renatocesaranjo@gmail.com

1 INTRODUO

Partir do princpio de que a organizao, que se pretende automatizar com um Sistema de Informaes, est sadia simplesmente usando a observao e a vivncia, ou pressupor que tal automatizao sozinha tornar a empresa saudvel no que se refere ao seu funcionamento, pode ser desastroso, tanto para o software que se pretende produzir quanto para o processo de funcionamento da empresa ou organizao. O processo de anlise e desenvolvimento de software composto por vrias etapas que devem ser gerenciadas e bem definidas com o intuito de prover um produto final de qualidade. Para tanto, de incio, importante refletir sobre o processo da organizao que se quer automatizar, para s ento tentar levantar as necessidades e solues informatizadas. Esses dois aspectos so o objeto central desse artigo, ou seja, a pretenso estudar as correlaes entre a Engenharia de Processos de Negcios e a Engenharia de Requisitos, focando especificamente em observar e analisar os resultados percebidos quando a modelagem de processos de negcio utilizada na tarefa de levantamento e elicitao de requisitos de um Sistema de Informaes. Dessa forma, podemos considerar, em primeiro plano, a Engenharia de Processos de Negcio como um fator de fundamental importncia para o software, pois, com ela procura-se entender ou mapear como uma organizao ou um conjunto delas opera, como se realizam os processos, como as informaes fluem atravs desses processos, suas interfaces, os recursos utilizados, as atividades desempenhadas, permitindo compreender as cadeias de valores existentes (CAMEIRA E CAULLIRAUX 2000, p.1 apud CARVALHO, 2009, p.21). No entanto, para alcanar o objetivo de um Sistema de Informao consolidado com o funcionamento da empresa no basta apenas ter processos bem definidos, deve-se traduzi-los em funcionalidades condizentes com a realidade da empresa. Nesse momento passa a ser indispensvel o uso da Engenharia de Requisitos que segundo Sommerville (2007) consiste no processo de descobrir, analisar, documentar, e verificar as funes e restries do sistema. Ou seja, os dois conceitos se relacionam de diversas maneiras e podem ser estudados partindo do princpio de que ambos possuem real importncia em suas finalidades especialmente quando utilizados, um completando o outro. Tomando como base o exposto, podemos ressaltar que o principal objetivo do estudo analisar as conseqncias benficas para os procedimentos correlatos Engenharia de Requisitos quando temos como base insumos gerados pela Engenharia de Processos de 2

Negcios. Essa direo foi tomada visando contribuir para a conscientizao da importncia dos levantamentos e releituras de processos de negcio que apiam, com reais ganhos, para a anlise e implementao do software que ir automatizar o processo e, naturalmente, ir trazer ganhos para a organizao. Para alcanar maior clareza e resultados para a pesquisa, decidiu-se investir em um estudo de caso que aborda um projeto que visa gerir completamente o processo licitatrio de uma Companhia de Saneamento Brasileira. Tal projeto iniciou-se com o levantamento completo dos processos de negcios. Foram identificados pontos a serem melhorados e aps a concluso do mapeamento o material foi submetido aos gestores dos processos para aprovao e conseqente uso nas reunies de levantamento das funcionalidades do sistema. Atualmente o projeto encontra-se em processo de elicitao e anlise de requisitos. Partindo desse referencial, resolveu-se embasar o estudo de caso na observao e anlise dos trabalhos de levantamento de requisitos com o uso dos diagramas de processo e nas opinies e crticas oferecidas por todos os profissionais envolvidos (stackholders)1 no desenvolvimento do Sistema de Informao mencionado. Com isso, considera-se indispensvel construir o conhecimento a respeito do assunto baseados no Referencial Terico a respeito da Engenharia de Requisitos e da Engenharia de Processos de Negcios, e nos mtodos de observao e coleta de informao a respeito do objeto do Estudo de Caso. Cruzando tais informaes possvel referenciar a viso da importncia da juno dessas duas reas to fundamentais para a construo de Sistemas de Informao mais prximos do ideal.

Pessoas interessadas no entendimento e desenvolvimento do sistema.

2 REFERENCIAL TERICO

Para embasar o estudo faz-se necessrio abordar o referencial terico das duas principais bases do estudo: A Engenharia de Processos de Negcios e a Engenharia de Requisitos. O Estudo das reas ser dirigido com o intuito de prover informaes essenciais para o cumprimento do objetivo do trabalho que se embasa em abordar as relaes entre essas reas dando nfase na anlise e na percepo dos resultados percebidos quando o Mapeamento de Processos de Negcios serve como um dos subsdios para cumprir a elicitao de requisitos de um Sistema de Informaes. No pretenso desse artigo esgotar os assuntos e sim cumprir o objetivo proposto.

2.1 ENGENHARIA DE PROCESSOS DE NEGCIOS

As relaes empresariais, atualmente, encontram-se cada vez mais competitivas e especialmente desafiantes. No h tempo para perder com entraves e burocratizao.

Alcanar o sucesso significa realizar as atividades negociais com agilidade e competncia pensando sempre na melhoria do processo e nas oportunidades advindas desse aperfeioamento. Essa dinmica tem sido uma obrigao para que as empresas se mantenham no mercado e alcem novos horizontes. No entanto, preciso analisar os aspectos da empresa com critrio, observando com cuidado suas deficincias e potencialidades para ento alicerar o conhecimento e montar o processo de funcionamento ideal. Nesta linha se enquadra este tpico que busca, baseado em um referencial terico, analisar os conceitos e caractersticas principais afetos a Engenharia de Processos de Negcio mostrando-se competente para abordar e dar subsdios visando resolver os aspectos mencionados.

2.1.1 DEFINIO

Para fornecer um referencial terico a respeito da Engenharia de Processos de Negcios (EPN), importante, no primeiro momento, buscar definies que juntas apontem para formar um conceito alinhado com o objetivo do artigo. Segundo Santos (2002, p.1) a Engenharia de Processos , a priori, entendida, como uma arquitetura (framework)2 para entendimento, anlise e melhoria dos processos dentro e entre organizaes. Outra definio dada por Cameira e Caulliraux (2000, p.1 apud CARVALHO, 2009, p.21), j citada anteriormente na introduo, diz que
[...] uma tcnica muito utilizada quando se deseja entender ou mapear como uma parte de uma organizao, uma organizao ou, at, um conjunto de organizaes(uma cadeia de suprimento, por exemplo) opera, como so realizados os processos,como a informao flui atravs desses processos, suas interfaces, quais os recursos so utilizados, quem realiza as diversas atividades etc., permitindo entender as cadeias de valor existentes.

Analisando os dois conceitos observa-se que ambos se completam, uma vez que o primeiro fornece uma viso geral que procura objetivar a compreenso da EPN, enquanto o segundo busca detalhar e completar o sentido do primeiro. Essa unio se alinha definitivamente ao foco buscado pela pesquisa e contribuir a seu tempo para alcanar os objetivos do trabalho.

2.1.2 OBJETIVOS DA ENGENHARIA DE PROCESSOS DE NEGCIOS

Para melhor compreender a Engenharia de Processos de Negcios fundamental entender quais objetivos fazem parte de seu escopo. Na literatura, podemos encontrar a contribuio dada por Grover e Kettinger (2000, apud CARVALHO, 2009, p.22) que diz que a Engenharia de Processos pode ser entendida como uma disposio para entendimento, anlise e melhoria dos processos dentro e entre organizaes com os seguintes objetivos apresentados:

Frameworks ou arcabouo uma infra-estrutura do esqueleto de implementao especifica para o trabalho de projeto.

a) uniformizao do entendimento da forma de trabalho, gerando integrao (cultura); b) anlise e melhoria do fluxo de informaes; c) explicitao do conhecimento sobre os processos, armazenando, assim, o know how3 organizacional; d) realizao de anlises organizacionais e de indicadores; e) realizao de simulaes, apoiando a tomada de decises; f) gesto da organizao.

Trazendo a viso desses objetivos para a pesquisa podemos dizer que, para o foco buscado, se enquadram, mais especificamente, o segundo e terceiro tpicos. A anlise e melhoria das informaes e know how organizacional trazem real benefcio para a Tecnologia da Informao e por conseqncia ao produto que neste caso o software.

2.1.3 DETALHAMENTO DOS CONCEITOS

Alm de entender a definio e de expor os objetivos da Engenharia de Processos de Negcios, importante entender alguns conceitos de forma detalhada. Tais conceitos, dentro da rea de EPN, so fundamentais e se destacam quando tentamos suprir a necessidade imposta pelos objetivos deste artigo, como ser visto a seguir:

2.1.3.1 PROCESSO DE NEGCIO

Objetivando definir um conceito claro a respeito de Processo de Negcio, podemos observar na literatura vrias definies que concorrero para formar uma idia geral e necessria para atender o estudo. Desta forma, Nagel e Rosemann (1999, apud CARVALHO, 2009, p.23) definem processos de negcios como ordenaes temporais e lgicas (seriadas ou paralelizadas) de atividades executadas para transformar um objeto de negcio, tendo

Conhecimento tcnico e experincia em campo especializado, conhecimento do negcio.

como objetivo a finalizao de certa tarefa. No entanto, Hammer e Champy (1994 apud CARVALHO, 2009, p.23) afirmam que um processo de negcio um grupo de atividades que so realizadas numa seqncia lgica com o objetivo de produzir um bem ou um servio de valor para um grupo especfico de clientes. Apresentando um conceito mais detalhado, Zarifian (apud CARVALHO, 2009, p. 23) define processo de negcio como:
uma cooperao de atividades distintas para a realizao de um objetivo global, orientado para o cliente final que lhes comum. Um processo repetido de maneira recorrente dentro da empresa. A um processo correspondem: um desempenho (performance), que formaliza o seu objetivo global (um nvel de qualidade, um prazo de entrega etc.); uma organizao que materializa e estrutura transversalmente a interdependncia das atividades do processo, durante sua durao; uma coresponsabilidade local de cada grupo de atores ao nvel de sua prpria atividade.

Cabe aqui destacar que todos os conceitos apresentados colaboram para o entendimento a respeito de Processos de Negcio, formando uma idia ampla e consistente desta matria. No entanto, para a nfase que se deseja alcanar no trabalho necessrio adotar uma definio mais objetiva, neste caso citada por Davenport (1994, p.7, apud CARVALHO, 2009, p.23-24) que conceitua dizendo que Um processo [...] uma ordenao especfica das atividades de trabalho no tempo e no espao, com um comeo, um fim, e inputs4 e outputs5 claramente identificados [...]. Eriksson e Penker (2000, apud CARVALHO, 2009, p.25-26) abordam o conceito de processo de negcio e conjuntamente fazem meno de um relacionamento deste com outros conceitos apresentados na forma de atributos de: descrio e medio. No primeiro ocorre a representao grfica ou textual do processo, ou seja, neste momento so apresentadas as maneiras como o processo executado e quais so os seus insumos (entradas processadas e consumidas pelo processo) e os produtos (sadas). J no segundo atributo podemos ver as mtricas na forma de indicadores do processo, considerando tempo, custo, qualidade, entre outros. Outro aspecto importante levantado pelo mesmo autor o dos subprocessos que nada mais so do que nveis de detalhamento dos processos. Outro aspecto importante o de como so formados os processos. Eriksson e Penker (2000, apud CARVALHO, 2009, p.25-26) definem esse aspecto dizendo que os processos so formados por uma ou mais atividades executadas por pessoas ou sistemas, regidos por regras de negcio, iniciados a partir de eventos externos ou internos a organizao e finalizados por algum evento que aponte para o alcance do objetivo visado.
4 5

Refere-se entrada de dados para processamento. Obteno de dados como resultado de um processamento.

Com base nessa literatura podemos averiguar a importncia dos processos de negcio dentro da EPN. O uso dos processos traz como benefcio o fato de proporcionar uma compreenso da organizao como um todo, focando inclusive em possveis melhorias.

2.1.3.2 MODELAGEM DE PROCESSOS DE NEGCIOS

Um dos conceitos mais fundamentais para dar sustentao EPN a Modelagem de Processos de Negcios. Segundo Dvalos (2010)
para permitir a integrao nas empresas preciso que todos os elementos que a compem, sejam eles homens, mquinas e sistemas computacionais, entre outros, possam trocar informaes entre si numa profundidade alm da simples troca fsica de dados. E esta integrao passa necessariamente pela considerao de uma viso holstica, que traduzida no desenvolvimento de uma imagem nica. Um dos mecanismos existentes para auxiliar na obteno desta imagem so os Modelos de Processos de Negcio.

Ou seja, ainda segundo o autor, Modelos de Processos de Negcio so representaes de uma organizao real que servem como referncia comum para todos os seus membros, sejam eles pessoas, sistemas ou recursos e formam uma infra-estrutura de comunicao. Outra definio de Nuseibeh (2000, apud CARVALHO, 2009, p.129) diz que a modelagem de processos compreende o entendimento da estrutura organizacional, das regras de negcio que afetam a operao, dos objetivos, das atividades e responsabilidades dos envolvidos, bem como dos dados manipulados. Segundo Vernadat (1996), as empresas alcanam a excelncia operacional quando se concentram em dois pontos essenciais: a otimizao do modelo existente e a redefinio das operaes existentes. Adicionando maior contedo, o mesmo autor contribui com um desdobramento das finalidades da modelagem de processos, ou seja: uniformizao do entendimento da forma de trabalho, gerando integrao; anlise e melhoria do fluxo de informaes; explicitao do conhecimento sobre os processos, armazenando, assim, o know how organizacional; realizao de anlises organizacionais e de indicadores (processos, financeiros e outros); realizao de simulaes, apoiando tomada de decises; e gesto da organizao. Os processos quando so mapeados, produzem modelos de processos, os quais possuem finalidades bsicas que, segundo Santos (et al., 2002, apud CARVALHO, 2009,

p.23-24) so: representao, anlise e melhoria da forma que o trabalho realizado nas organizaes, horizontalmente, orientado para produtos, clientes e mercados. Para melhor compreender a modelagem de processos de negcio necessrio analisar alguns princpios que devem ser seguidos e tornam-se essenciais segundo Santos (2002). Um conjunto de princpios, vistos na literatura, o proposto por Rosemmann (apud CARVALHO, 2009, p.32-34): a) aderncia - princpio que guia o entendimento sobre a proximidade do modelo estrutura e ao funcionamento da realidade modelada; b) relevncia ou suficincia - cada objeto representado no modelo deve ter um propsito, assim, um modelo no deve conter mais informaes do que o necessrio. No entanto, deve-se usar de cautela para definir o que ou no relevante; c) custo/benefcio - nesse princpio preciso analisar a quantidade de trabalho necessria para criar o modelo versus utilidade do mesmo versus quanto tempo o modelo ser usado; d) clareza - esse princpio considerado um dos mais importantes em funo da prpria definio do que um modelo capaz de ser entendido e usado pelos usurios (PIDD, 1999, apud CARVALHO, 2009, p.34); e) comparabilidade - princpio que direciona a comparao entre diferentes processos, logo, tendo como necessrios os seguintes aspectos: a aplicao do mesmo mtodo para diferentes modelos com a utilizao dos mesmos objetos, a

correo/uniformizao na nomenclatura e a homogeneidade dos nveis de detalhamento; e f) estruturao sistemtica - princpio relacionado capacidade de integrar modelos, representando diversos aspectos da realidade e capacidade desses modelos se estruturarem metodologicamente. Para o presente artigo deve ser relevada a importncia da modelagem de processos de negcio quando relacionados aos sistemas de informao. Segundo Eriksson e Penker (2000, apud CARVALHO, 2009, p.27), pode-se perceber que o processo de negcio envolve direta ou indiretamente recursos como informao, que, por sua vez, pode ter sua existncia materializada em sistemas de informao que automatizam ou apiam as atividades dos processos.

2.1.3.3 REGRAS DE NEGCIO

Esta seo aborda um dos assuntos da EPN mais importantes para este trabalho, as Regras de Negcio. Junto com os processos de negcio, este conceito providencia uma aproximao, pretendida pelo estudo, com os requisitos de sistemas de informao. Para isso fundamental discorrer sobre sua definio terica. Segundo Von Halle (2002, apud CARVALHO, 2009, p.45-46) o termo regra de negcio reflete as regras ou polticas do negcio, uma vez que elas guiam as atividades do mesmo. Ainda segundo o autor esse termo no tem uma definio padro no contexto empresarial. Entretanto, algumas definies so encontradas na literatura. Bell et al. (1990, apud CARVALHO, 2009, p.46) definem regra de negcio como declaraes que apresentam a maneira como o negcio est sendo feito, alm das diretrizes e restries com respeito a estados e processos em uma organizao. Outra definio encontrada a de Ross e Lam (2000, apud CARVALHO, 2009, p.46) que afirmam que regra de negcio uma parte atmica da lgica de negcio reutilizvel, especificada declarativamente. BRG6 (2000, apud CARVALHO, 2009, p.46) define regra de negcio como uma frase/enunciado que define ou restringe algum aspecto do negcio, ou seja, expressa, controla ou influencia o comportamento do negcio. Essa ltima definio se enquadra mais adequadamente ao estudo proposto. A meno de declaraes, frases ou enunciados permeia as definies junto com a idia de controle e influncia sobre o comportamento do negcio. Esses aspectos colaboram e estreitam relaes entre os sistemas de informao e o recurso humano das organizaes. Esta idia evidenciada por Gottesdiener (1997, apud CARVALHO, 2009, p.49) que explica que as regras de negcio promovem a verdadeira integrao entre as pessoas do negcio e a tecnologia, pois aquelas posicionam os membros da organizao com elementos centrais da atividade de software7.

Business Rules Group (BRG) um grupo dedicado a padronizar os termos relacionados ao conceito de regra de negcio. 7 Consiste em algoritmos (instrues detalhadas que dizem como fazer algo) e suas representaes no computador, o que chamamos de programas.

10

2.2 ENGENHARIA DE REQUISITOS

Aps descrever as principais caractersticas da rea de Engenharia de Processos de Negcio, faz-se necessrio abordar a outra base de estudo, fundamental para a compreenso do trabalho em seus objetivos.

2.2.1 REQUISITO

Ao abordar a rea de Engenharia de Requisitos devemos ter em mente que em primeiro lugar o produto deve atender o mximo possvel as necessidades dos envolvidos, como explicitado na literatura sobre requisitos uma das primeiras medidas do sucesso de um sistema de software verificar se ele atende s necessidades dos stakeholders. (NUSEIBEH e EASTERBROOK, 2000, apud ALVES, 2001, p.46) Segundo Bell e Thayer (1976 apud ALVES, 2001, p.46) vrios requisitos se apresentam inadequados, inconsistentes, incompletos e ambguos tendo um grande impacto na qualidade do produto final, o software. A concluso de suas observaes foi a de que os requisitos para um dado sistema no podem ser levantados naturalmente, ao contrrio eles precisam ser projetados e necessitam de contnuas revises. Com o intuito de melhor compreender os requisitos, elencamos duas definies que melhor se enquadram para dar subsdios ao estudo. Dessa forma segundo Sommerville (2007) os requisitos de um sistema so descries dos servios fornecidos pelo sistema e as suas restries operacionais. Entretanto, Filho (2009) define que a disciplina de Requisitos rene as atividades que visam a obter o enunciado completo, claro e preciso dos requisitos de um software. De posse dos conceitos expostos, cabe complementar a idia de requisitos expondo sua classificao conforme indicado por Sommerville (2007): a) requisitos funcionais - So as declaraes de servios que o sistema deve fornecer, como o sistema deve reagir a entradas especficas e como o sistema deve se comportar em determinadas situaes. Em alguns casos, os requisitos funcionais podem tambm estabelecer explicitamente o que o sistema no deve saber.

11

b) requisitos no funcionais - So restries sobre os servios ou as funes oferecidos pelo sistema. Eles incluem restries de timing, restries sobre o processo de desenvolvimento e padres. Os requisitos no funcionais aplicam-se, freqentemente, ao sistema como um todo. Em geral, eles no se aplicam as caractersticas ou servios individuais de sistema. c) requisitos de usurio - [...] devem descrever os requisitos funcionais e no funcionais, de modo que eles sejam compreensveis pelos usurios do sistema que no possuem conhecimento tcnico detalhado. Eles devem especificar apenas o comportamento externo do sistema e evitar, sempre que possvel, caractersticas de projeto do sistema. d) requisitos de sistema - [...] so verses expandidas dos requisitos de usurio usados pelos engenheiros de software como ponto de partida para o projeto do sistema. Eles adicionam detalhes e explicam como os requisitos de usurio devem ser fornecidos pelo sistema.

2.2.2 VISO GERAL DA ENGENHARIA DE REQUISITOS

Aps obter o embasamento necessrio a respeito do conceito de requisitos, pode-se abordar a rea de Engenharia de Requisitos de forma geral, com o intuito de referenciar o estudo. Para isso, podemos em primeiro lugar citar na literatura a definio de Filho (2009, p.165) que conceitua a Engenharia de Requisitos como O conjunto de tcnicas empregadas para levantar, detalhar, documentar e validar os requisitos de um produto [...]. Outra colaborao importante encontrada como referencial a de Sommerville (2007, p.81) que analisa a Engenharia de Requisitos a partir dos requisitos em si. Para ele, os requisitos so descries de servios oferecidos por um sistema e suas restries operacionais. Usando esse conceito, o autor aborda a Engenharia de Requisitos como O processo de descobrir, analisar, documentar e verificar esses servios e restries [...]. Procurando melhor compreender a Engenharia de Requisitos, podemos ainda citar o conceito oferecido por Pressman (2006) que a define como uma rea que ajuda os engenheiros de software a compreender melhor problemas que vo trabalhar para resolver, ou seja, um conjunto de tarefas que buscam o entendimento das conseqncias que o software

12

trar sobre o negcio, das necessidades do cliente e da interao dos usurios finais tero com o software.

2.2.3 PROCESSO DE ENGENHARIA DE REQUISITOS

O processo de Engenharia de Requisitos visto de vrias maneiras na literatura. Para formar um conceito e revelar diferentes caractersticas e aspectos a respeito do assunto, indispensvel traar o perfil oferecido pelo referencial terico adotado. Dentre vrios autores que abordam o assunto, atenderam melhor ao estudo: Sommerville (2007) e Pressman (2006), pelo fato de possurem maiores particularidades e afinidades com o objetivo do estudo. Dessa forma, o processo de Engenharia de Requisitos tem com objetivo criar e manter uma documentao sobre requisitos de um sistema. Para isso, o processo dividido em quatro subprocessos de alto nvel. Estes processos esto relacionados com a utilidade do sistema para a organizao (viabilidade), obteno dos requisitos (elicitao), converso dos requisitos em um padro (especificao) e a verificao do atendimento das necessidades do cliente com o sistema (validao) (SOMMERVILLE, 2007). Para entender cada um desses subprocessos, cabe aqui defini-los sinteticamente como a seguir: a) viabilidade um estudo onde recomendado o prosseguimento ou no do processo de engenharia de requisitos. Consiste em um conjunto de requisitos que tem a finalidade de mostrar um esboo do sistema e como ele pode apoiar os processos de negcios; b) elicitao e anlise uma atividade em que os engenheiros de software, apoiados pelos stakeholders, aprendem sobre o domnio do sistema, quais servios sero fornecidos e o desempenho esperado e etc. Este subprocesso ser descrito com mais detalhes na prxima seo por ocasio da necessidade evidenciada como objetivo do artigo; c) especificao descreve os requisitos funcionais e no funcionais mais

detalhadamente. Um ponto de partida para padres de especificao de requisitos o padro do IEEE; d) validao o momento em que os requisitos definidos demonstram o sistema que o usurio solicitou. A validao se mostra importante pelo fato de evidenciar erros 13

ainda na documentao de requisitos, ou seja, antes do desenvolvimento do sistema, evitando o retrabalho e o custo elevado do sistema.

Seguindo outra linha a respeito do Processo de Engenharia de Requisitos, Pressman (2006), o caracteriza por meio da realizao de sete funes distintas: concepo, levantamento, elaborao, negociao, especificao, validao e gesto, todas definidas resumidamente a seguir: a) concepo o momento em que os engenheiros de software formulam uma srie de questes livres de contexto com a inteno de estabelecer um entendimento bsico do problema, surgindo comunicao e colaborao preliminares entre cliente e desenvolvedor; b) levantamento a fase em que os envolvidos no processo so indagado quanto aos objetivos do sistema, o que precisa ser conseguido, como o sistema cabe nas necessidades do negcio e como ser usado no cotidiano. Com o intuito de traar um paralelo com a elicitao e anlise de requisitos de Sommerville (2007), este tpico tambm ser melhor detalhado na prxima seo; c) elaborao atividade que tem a prerrogativa de desenvolver um modelo tcnico refinado das funes, caractersticas e restries do software; d) negociao os interessados so solicitados a definir a ordem de prioridade para os requisitos e o engenheiro de requisitos usa um processo de negociao para deixar claras as prioridades que surgem com os conflitos de prioridades; e) especificao produto final produzido por um engenheiro de requisitos. Esse produto serve como fundamento s atividades de engenharia de software subseqentes. Tem a finalidade de descrever a funo e o desempenho de um sistema baseado em computador e suas restries no direcionamento do desenvolvimento; f) validao examina a especificao para garantir que todos os requisitos do software no tenham um entendimento ambguo e as inconsistncias, omisses e erros tenham sido detectados e corrigidos de acordo com o que foi definido para o processo e o sistema; g) gesto atividades que auxiliam a equipe de projeto a identificar, controlar e rastrear requisitos e modificaes de requisitos, em qualquer momento, ao longo do projeto.

14

2.2.3.1 ELICITAO E ANLISE DE REQUISITOS

Levando em considerao o que ofereceu a seo anterior, cabe nesse momento observar mais de perto um dos subprocessos ou assuntos constantes do processo de engenharia de requisitos. Isso se faz necessrio e fundamental para o estudo, j que o assunto se relaciona definitivamente com os fins objetivados pelo artigo. Na literatura so encontradas inmeras vises relacionadas a esse conceito, mas com o intuito de trazer aspectos claros e objetivos e ao mesmo tempo abordar vises distintas, foram selecionadas para isso as anlises de Sommerville (2007) e Pressman (2006), que abordam as caractersticas da elicitao e anlise de requisitos ou, em outros termos, levantamento de requisitos, agregando valor e, principalmente, construindo um conceito adequado ao estudo.

Partindo da idia de que os dois autores abordam o assunto, importante nesse momento falar sobre o objeto dessa seo separadamente, um autor do outro, j que seguem linhas de anlise relativamente diferentes.

Com isso, para Sommerville (2007) o assunto abordado se intitula elicitao e anlise de requisitos, e se trata, segundo ele, de um subprocesso ou estgio do processo de engenharia de requisitos em que os engenheiros de software se relacionam diretamente com os clientes e usurios finais do sistema. Aqui o principal objetivo aprender sobre o domnio da aplicao, quais servios devero ser oferecidos pelo sistema, o desempenho esperado, restries de hardware entre outros. Seguindo pela anlise do autor, cabe relevar a necessidade de envolvimento de vrias pessoas da organizao nessa atividade. A essas pessoas imputado o termo stakeholder que definem qualquer pessoa ou grupo afetado pelo sistema, direta ou indiretamente. Conforme a FIGURA 1 podemos ver um modelo de elicitao e anlise de requisitos bastante genrico apresentado por Sommerville (2007, p.98). Resguardadas as peculiaridades de cada organizao, segundo o autor, [...] voc pode pensar nessas atividades como um espiral, de modo que as atividades se intercalem medida que o processo progrida da parte interna da espiral para a externa.

15

FIGURA 1 - Processo de elicitao e anlise de requisitos.

Com isso, cabe apontar e detalhar as atividades contempladas na anlise de Sommerville (2007), conforme a seguir: a) obteno de requisitos representa um processo de interao com os stakeholders para coletar os requisitos; b) classificao e organizao de requisitos. Nesta atividade os requisitos ainda no estruturados so envolvidos, ou seja, neste ponto eles so relacionados e agrupados em grupos coerentes; c) priorizao e negociao de requisitos. Quando vrios stakeholders participam do processo, inevitavelmente, os requisitos sero conflitantes. Aqui ocorre a priorizao dos requisitos por meio de resoluo de conflitos por meio de negociao; d) documentao dos requisitos, representa requisitos documentados e posicionados na prxima volta do espiral FIGURA 1. Nessa atividade podem ser produzidos documentos formais e informais. O autor ainda aborda a obteno de requisitos de maneira diferenciada, dando maior foco a essa atividade por entender ser fundamental ao restante do processo de elicitao e anlise de requisitos. Seguindo essa linha, cabe ressaltar alguns aspectos importantes dessa atividade, conforme indica o autor.

16

Com isso, a obteno de requisitos, um processo que visa reunir informaes sobre o sistema proposto e os existentes com a finalidade de obter os requisitos. Constam dessas informaes documentao, stakeholders de sistema e especificaes de sistemas similares. O contato com os stakeholders feito atravs de reunies com uso de entrevistas e observaes. Ainda conforme o autor, os requisitos podem ser provenientes do domnio da aplicao e de outros sistemas que interagem com o que se est especificando. As diversas fontes de requisitos, segundo o autor, (stakeholders, domnio e sistemas) podem ser representadas atravs de pontos de vistas, representando assim, cada ponto de vista, um subconjunto de requisitos do sistema. Tais pontos de vista podem ser usados, segundo o autor, como forma de classificao de stakeholders alm de outras fontes de requisitos. Outro aspecto abordado por Sommerville (2007) a entrevista, analisada de maneira destacada em sua obra. Para o autor, a entrevista um artifcio usado de forma que a equipe de engenharia elabora questes para os stakeholders a respeito do sistema a ser desenvolvido ou de um existente, caso exista. Nesse caso os requisitos derivam das respostas dadas ao questionrio. Sommerville (2007) destaca dois tipos de entrevistas: entrevistas fechadas, em que os stakeholders respondem a perguntas elaboradas anteriormente pelos analistas e entrevistas abertas nas quais no existem tais predefinies de perguntas e os engenheiros exploram os assuntos conforme a necessidade. Segundo o autor as entrevistas so geralmente a combinao desses dois tipos. Partindo para a abordagem dada por Pressman (2006) referente ao assunto, cabe ressaltar que, em seu trabalho, o autor prefere analisar o objeto dessa seo usando a nomenclatura Levantamento de Requisitos. Para ele um trabalho mais detalhado nesse sentido em que se prev soluo de problemas, elaborao, negociao e especificao comea com uma coleta colaborativa de requisitos. O autor define essa etapa como um trabalho em que uma equipe de interessados e analistas age conjuntamente identificando problemas e solues, negociando diferentes vises para ento especificar um conjunto preliminar de requisitos da soluo (ZAHNISER, 1990, apud PRESSMAN, 2006, p.124-125). Para que acontea tal coleta colaborativa de requisitos o autor prope algumas diretrizes bsicas que devem ser aplicadas as reunies, conforme a seguir: a) as reunies devem ser conduzidas e apoiadas por profissionais engenheiros de softwares e clientes. Devem ser estabelecidas regras para preparao e participao.

17

Uma agenda formal com os pontos importantes a serem cobertos, mas que seja tambm suficientemente informal para encorajar as idias; b) deve existir a figura do facilitador. Algum que controle a reunio; c) um Mecanismo de definio. Qualquer meio fsico como folhas de rascunho, flip charts, etc.; e d) dever ser adotada a meta de identificar o problema, propor soluo, negociar diferentes vises e, por fim, identificar um conjunto preliminar de requisitos. Segundo Pressman (2006), dever ser realizada, previamente, uma lista de objetos que fazem parte do ambiente do sistema, redigida por cada participante. Uma vez iniciada a reunio todos devem concordar sobre a necessidade e justificativa do novo produto e ento cada participante apresenta sua lista para discusso. Por conseqncia, ainda segundo o autor, uma lista combinada dever ser criada pelo grupo eliminando redundncias e adicionando novas idias. O objetivo criar uma lista de consenso em cada assunto como objetos, servios, restries e desempenho. Com as listas de consenso so criadas subdivises da equipe para desenvolver miniespecificaes para uma ou mais entradas das listas. As equipes apresentam seu produto equipe para discusso. Feitas as adequaes cada participante faz uma lista de critrios de validao para o produto/sistema para apresentar a equipe. Para a produo do rascunho completo da especificao um ou mais participantes so nomeados. Seguindo a anlise de levantamentos de requisitos proposta por Pressman (2006, p.127) o que se segue a implantao da funo de qualidade (IFQ) que, segundo ele, uma tcnica que traduz as necessidades do cliente para requisitos tcnicos do software. Conforme Zultner (1992, p.28-41, apud PRESSMAN, 2006, p.127) a IFQ concentra-se em maximizar a satisfao do cliente a partir do processo de engenharia de software. Partindo desse conceito Pressman (2006) entende que a IFQ enfatiza o entendimento do que tem valor para os clientes e posteriormente aplica esses valores atravs do processo de engenharia de software. Para ele a IFQ identifica trs tipos de requisitos: a) requisitos normais refletem as metas e objetivos traados para um produto ou sistema durante as reunies com os clientes. Existe a satisfao do cliente quando esses requisitos esto presentes; b) requisitos esperados esto implcitos no produto ou sistema, podendo ser fundamentais a ponto do cliente no se referir explicitamente. A ausncia desses requisitos seria causa de insatisfao significativa; e c) requisitos excitantes que vo alm da expectativa do cliente, mostrando serem muito satisfatrios quando presentes. 18

Conforme identificado por Pressman (2006) a IFQ utiliza entrevistas com o cliente e a observao, levantamentos e exame de dados histricos como dados brutos para o levantamento de requisitos. Os dados ento, so traduzidos em uma tabela de requisitos denominada tabela de voz do cliente. Outra abordagem dada por Pressman (2006, p.129) para o levantamento de requisitos a questo relacionada ao cenrio de usurios. Conforme o autor medida que os requisitos so coletados, uma viso geral das funes e caractersticas do sistema comea a se materializar. Com isso ele relata que ser complicado avanar para atividades mais tcnicas enquanto a equipe de software no entender como as funes e caractersticas sero utilizadas por diferentes tipos de usurios finais. O intuito, para o autor, produzir um conjunto de cenrios que identifiquem uma linha de uso para o sistema. Esses cenrios, frequentemente sero chamados de casos de uso (JACOBSON, 1992 , apud PRESSMAN, 2006, p.129) fornecendo uma descrio de como o sistema ser utilizado. Conforme o tamanho do sistema ou do produto, Pressman (2006) relaciona os produtos de trabalho produzidos por ocasio do levantamento de requisitos, incluindo: a) declarao da necessidade de viabilidade; b) afirmao limitada do escopo do sistema ou do produto; c) lista de clientes, usurios e outros interessados que participam do levantamento de requisitos; d) descrio do ambiente tcnico do sistema; e) lista de requisitos e as restries de domnio que se aplicam a cada um deles; f) conjunto de cenrios de uso que fornecem informaes sobre o uso do sistema ou do produto sob diferentes condies de operao; e g) quaisquer prottipos desenvolvidos para definir melhor os requisitos. As anlises apresentadas pelos autores que contriburam para esta seo foram conciliadas, em geral, por aspectos semelhantes que visam em sua essncia, resguardadas suas aplicaes, procurar entender a necessidade do cliente e providenciar uma srie de medidas que colaboram para a obteno de requisitos capazes de produzir um produto que atenda os objetivos propostos com mxima preciso. Esses conceitos e aplicaes colaboram definitivamente para a direo e embasamento pretendidas para o artigo.

19

3 RELEVNCIA

DOS

PROCESSOS

DE

NEGCIO

NA

ELICITAO

LEVANTAMENTO DE REQUISITOS

A partir das consideraes e anlises evidenciadas no referencial terico, importante para o momento caracterizar a relevncia e influncia que os Processos de Negcio tm sobre Elicitao e Anlise de Requisitos. Para que tal caracterizao seja realizada, necessrio apoiar-se em um contedo que referencie e atenda aos objetivos propostos por esta seo. A dissertao de mestrado intitulada Engenharia de Processos de Negcios e a Engenharia de Requisitos: Anlise e Comparaes de Abordagens e Mtodos de Elicitao de Requisitos de Sistema Orientada por Processos de Negcio apresentada por Elaine Alves de Carvalho em 2009 atende o objetivo abordando e analisando vrias referncias sobre o assunto. Para alcanar o objetivo proposto nesta seo, importante considerar os captulos 5 e 6 da dissertao mencionada. No captulo 5, Carvalho (2009) apresenta algumas abordagens de identificao de requisitos de sistemas a partir dos processos de negcio. O intuito bsico foi elencar trabalhos publicados que atendessem ao seu objetivo de pesquisa - elicitao de requisitos de sistemas do entendimento do conjunto de atividades de negcio seqenciadas lgico e temporalmente fortemente ligado ao objeto proposto nesse artigo. Para que a autora cumprisse o captulo 5 foram considerados trabalhos que se revelaram, em suas buscas bibliogrficas, como dito por Carvalho (2009), capazes de abordar e propor mtodos, tcnicas, ferramentas e heursticas para considerar as informaes obtidas atravs do entendimento do negcio como base para a elicitao de requisitos. No necessrio ou imprescindvel citar ou analisar, nesse artigo, cada uma das abordagens pesquisadas por Carvalho (2009). O intuito entender a inteno da autora que apresentou diversas abordagens no captulo 5 e promoveu no captulo 6 uma anlise mais sistemtica desses estudos atravs de critrios definidos sob a viso da Engenharia de Processos de Negcio. Dessa forma, o contedo que atende primariamente ao objetivo dessa seo est no captulo 6 do trabalho de Carvalho (2009). Nesse captulo foi desenvolvida uma anlise crtica das abordagens e mtodos de elicitao de requisitos a partir dos processos de negcio. Isso ajudar a caracterizar, no presente artigo, a relevncia dos processos de negcio quando se deseja elicitar e analisar requisitos de um sistemas de informao, ou seja, o intuito identificar nesse captulo pontos principais to necessrios para o estudo proposto por este artigo. 20

Partindo para a anlise do captulo 6, vale contextualizar, em primeiro lugar, a forma como a autora estruturou o pensamento para efetuar sua anlise crtica. Ou seja, os trabalhos abordados no captulo 5 foram estudados a partir de critrios orientados pelo referencial terico de EPN, proposto em seu captulo 3 e abordado nesse artigo com menos detalhe na seo 2.1. Dessa forma, segue a lista dos critrios apresentados por Carvalho (2009): a) Quanto ao emprego do conceito de processos de negcio segundo o arcabouo conceitual da EPN; b) Quanto adoo ou no da tcnica de modelagem de processos; c) Quanto sistematizao da modelagem dos processos atravs de metodologias calcadas no arcabouo conceitual da EPN; d) Quanto ao emprego de ferramentas apropriadas para a modelagem dos processos de negcios; e) Quanto ao nvel de detalhamento dos processos de negcio; f) Quanto abordagem do conceito de regras de negcio; e g) Quanto ao emprego de mtodos, tcnicas, notaes ou ferramentas para a representao dos requisitos de sistema. Dando prosseguimento, Carvalho (2009) descreveu e procurou mostrar os critrios individualmente, demonstrando atravs descries e quadros, em cada critrio, se os mtodos mencionados no captulo 5 atendem ou no o critrio analisado. Como fruto da anlise dos critrios a autora pde delinear encaminhamentos para futuras abordagens sobre a elicitao de requisitos a partir de processos de negcio. Essa seo do captulo 6 tem especial importncia para o objeto desse artigo, pois depreende as concluses da autora e projeta estudos futuros trazendo os ganhos necessrios para o objeto desse artigo. Para melhor entender e ligar tais estudos ao foco do artigo cabe analisar o quadro de Carvalho (2009) que estabelece um resumo das propostas dos autores, atendendo ou no aos critrios estabelecidos. Dessa forma, quando uma proposta aborda detalhadamente como o tema avaliado contribui com o processo de elicitao de requisitos de sistema, atribui-se a letra A(atende), do contrrio NA(no atende) e por fim AP(atende parcialmente) no caso em que o mtodo cita o tema avaliado, mas sem detalhamento para a elicitao de requisitos. Dessa forma, segue o quadro como a seguir:

21

Tabela 1: Quadro de Carvalho

Segundo a autora o primeiro critrio foi omitido da tabela por ser afeto ao conceito de processo de negcio, se mostrando redundante, pois foi o critrio usado para selecionar as propostas avaliadas em seu trabalho. As concluses tiradas pela autora, mediante sua metodologia, elegem as propostas de Vicente (2004), Cruz (2004) e Dias et. al. (2006) como as que melhor atendem os critrios estabelecidos em relao as outras e demonstra em nmeros percentuais um balano do atendimento de cada um dos critrios, relatando observaes pertinentes. Dentre os trs mtodos citados acima, Vicente (2004) o que se adqua melhor aos critrios, mas Carvalho (2009), chama a ateno para o fato de que h questes que precisam ser melhoradas em seu mtodo, questes estas mencionadas em seu trabalho. Alm disso, a autora, mediante suas anlises, considera de maneira geral orientaes para futuras proposies a respeito tarefa de elicitao de requisitos de sistema a partir dos processos de negcio. Baseados no estudo do captulo 5 e 6 de Carvalho (2009), temos a inferir, agora tendo em mente a proposio desse artigo, que a Engenharia de Processos de Negcio possui, de maneira determinante, material para a Engenharia de Requisitos, sobretudo para a elicitao e anlise de requisitos de sistemas e podem se relacionar conforme os mtodos citados por Carvalho (2009). Tais mtodos demonstram a interao entre as reas, mas, no entanto chamam considervel ateno para os aspectos deficientes dos mtodos que abordam a interao. Isso traz a mente a necessidade de preenchimento das lacunas existentes no relacionamento das duas reas, evidenciadas nas consideraes de Carvalho (2009) sobre o que se deve observar em futuras proposies de mtodos com esse propsito.

22

4 ESTUDO DE CASO: SISTEMA DE GESTO DE LICITAES

Com a viso de trazer para o estudo uma experincia mais concreta que reflita o contedo exposto anteriormente em algo mais prximo da prtica, faz-se necessrio abordar um estudo de caso denominado nesta pesquisa como: Sistema de Gesto de Licitaes. Tratase de um sistema de informao que tem como objetivo principal proporcionar, a uma empresa de saneamento brasileira, a automatizao e gerncia do processo licitatrio em suas diversas formas e fases. O objeto central do estudo de caso, no entanto, no engloba todo o processo e metodologia de desenvolvimento do sistema mencionado. A principal tarefa, na pesquisa, focar o processo de obteno das funcionalidades e necessidades do sistema, ou seja, o levantamento e elicitao de requisitos. Entretanto, como o prprio contedo do artigo prope, no se trata puramente de uma anlise da rea de requisitos da Engenharia de Software. O fundamento principal da pesquisa propor o estudo de tal levantamento de requisitos utilizando diagramas resultado da modelagem e redesenho de processos de negcio referentes gesto das licitaes da empresa. Para melhor referenciar o objeto de estudo, torna-se necessrio especificar as metodologias de redesenho e modelagem de processo e a de desenvolvimento de sistemas utilizadas no projeto. A metodologia de desenvolvimento de sistemas utilizada no objeto de estudo foi criada pela prpria empresa de saneamento, montada com base em artefatos e mtodos de outras metodologias com a finalidade de se adequar s necessidades da empresa. A metodologia usada para modelagem e redesenho dos processos a ARIS que, com a realizao de reunies com os gestores da rea de licitao, utilizou a Cadeia de Processos orientada por eventos EPC para representar os diagramas de processos de negcio. Com isso, respeitando as finalidades propostas pelo artigo, o estudo de caso procura se encaixar e auxiliar a pesquisa que, na sua essncia, busca evidenciar e avaliar as relaes de reciprocidade entre os diagramas de processo de negcio e os requisitos de software no momento do levantamento das funcionalidades do sistema.

23

4.1 METODOLOGIA DE PESQUISA

Para que o estudo de caso seja analisado com critrio necessria a proposio de uma metodologia que identifique pontos determinantes capazes de conceder concluses concernentes com os objetivos principais demonstrados ao longo do artigo. A metodologia aplicada ao estudo de caso prope duas frentes bsicas de anlise para formulao de uma concluso a respeito do problema que se resume em identificar os resultados percebidos no uso dos diagramas de processos de negcio quando se executa a tarefa de levantar e elicitar os requisitos do Sistema de Gesto de Licitaes. A primeira pretende analisar os resultados obtidos atravs do uso de questionrios que, para este caso especfico, sero criados e endereados a trs papis distintos identificados no mbito do objeto de pesquisa, sendo eles: Analistas de Requisitos, Analistas de Processos e Clientes Gestores da rea de Licitaes da Empresa. De posse dos questionrios respondidos, sero analisadas as respostas de forma quantitativa com o intuito de formular apontamentos concernentes em primeiro lugar ao estudo de caso e em segundo, de forma mais abrangente, ao objeto de pesquisa. A segunda frente de pesquisa prope a observao de reunies de levantamento e elicitao de requisitos do Sistema de Gesto de Licitaes, com o intuito de identificar pontos importantes relacionados ao estudo. Da observao proposta, ser gerado relatrio que apontar, de maneira objetiva, a metodologia utilizada na reunio. Com base nos aspectos e detalhes colhidos ser possvel analisar e aderir ao trabalho, sobretudo s suas concluses, informaes concretas a respeito da atividade prtica que foi observada, ou seja, ser possvel analisar qualitativamente os tpicos relacionados pesquisa.

24

4.2 ANLISE DOS RESULTADOS

Esta seo se prope a observar e analisar resultados obtidos atravs de documentos citados na metodologia proposta. O objetivo , em primeiro lugar, quantificar os resultados dos questionrios (Anexo A, Anexo B e Anexo C) para inferir em concluses correspondentes ao interesse pretendido com a formulao das perguntas feitas para cada grupo participante do projeto e desenvolvimento do Sistema de Gesto de Licitaes. Em seguida, para completar o objetivo, necessrio tirar outros resultados provenientes do relatrio de observao das reunies para levantamento de requisitos (Anexo D), sendo a inteno principal, analisar qualitativamente o teor das reunies tirando concluses a respeito dos mtodos utilizados para elicitar requisitos com o uso dos diagramas de processo de negcio. A aplicao dos questionrios foi realizada na primeira semana de novembro de 2010, direcionada a um grupo de 9 pessoas, sendo: 3 Clientes gestores da rea de Licitao da Empresa; 4 Analistas de Requisitos e 2 Analistas de Processo. As reunies, a que se referiram os questionrios, iniciaram-se em meados de 2010 e ainda esto sendo realizadas atualmente. Com isso, aps a aplicao dos referidos questionrios, avaliou-se os resultados de cada grupo que sero demonstrados, na forma de concluses prticas, como a seguir:

a) Analistas de Requisitos No existe na metodologia de desenvolvimento de sistemas da empresa um mtodo, definido e documentado, que contemple o uso de modelos de processos na tarefa de levantamento e elicitao de requisitos; Dos quatro analistas de requisitos questionados, trs indicaram um nvel mdio de dificuldade no uso dos diagramas de processo de negcio na tarefa de levantar e elicitar requisitos do Sistema de Gesto de Licitaes; Para todos os analistas, a presena dos diagramas de processo de negcio impactou completamente, de maneira positiva, na elicitao e levantamento de requisitos do Sistema de Gesto de Licitaes; Houve diviso entre os analistas para as alternativas mdio e alto, quando o assunto foi o nvel de objetividade e conhecimento do cliente no momento da tarefa de levantamento dos requisitos do Sistema de Licitaes. importante

25

frisar que os analistas tiveram como referncia outros trabalhos em que no utilizaram a modelagem de processos de negcio; A maioria dos analistas emitiu a opinio de que os diagramas de processo de negcio influenciaram completamente a tarefa de formao da lista de prioridades de desenvolvimento de requisitos do Sistema de Licitaes; Quanto capacidade dos diagramas de processo de negcio em apontar os requisitos do Sistema de Licitaes, houve diviso de opinies. Dois informaram que os diagramas foram completamente capazes e outros dois que foram parcialmente capazes. b) Analistas de Processos de Negcio Todos os analistas informaram que nas reunies de mapeamento de processos de licitao, foram levados em considerao os aspectos de um sistema de informao. Os analistas que participaram do questionrio dividiram as opinies entre mdio e baixo quando o assunto foi o nvel de percepo que eles observaram nos gestores em relacionar os processos de negcio com o futuro sistema de informao, durante as reunies de mapeamento. Todos os analistas de negcio opinaram positivamente quando o assunto foi: a anlise da compreenso demonstrada por parte dos gestores de licitaes, a respeito da afirmao de que a modelagem dos processos de negcio muito mais abrangente do que os sistemas de informao. Todos opinaram positivamente quanto a isso. Para todos os analistas houve a preocupao, por parte dos gestores de licitao, em redesenhar o processo, ou seja, propor melhorias antes de desenvolver o sistema de informao, impedindo uma automatizao precipitada. Todos os analistas afirmaram que houve a identificao, nas reunies, de requisitos macro para subsidiar o desenvolvimento do sistema de licitao. c) Clientes Gestores da rea de Licitaes da Empresa De acordo com os gestores de licitao os processos de negcio auxiliam completamente o levantamento das necessidades e funcionalidades do sistema de licitaes.

26

 Em sua totalidade, os clientes viram suas expectativas serem atendidas em um nvel alto quando houve o uso dos processos de negcio no objetivo de especificar o sistema de informaes . Todos os gestores de licitao envolvidos no questionrio acharam os processos de negcio determinantes para o levantamento das funcionalidades do sistema de licitaes. Os gestores de licitao identificaram como mdio o nvel de clareza com que possvel identificar, nos diagramas de processos de negcio, as funcionalidades e necessidades do sistema de informao. Segundo os gestores, existe um alto nvel de comprometimento, dos participantes das reunies, em se manter dentro do escopo dos processos de negcio na ocasio do levantamento das funcionalidades do Sistema de Licitaes. Aps a anlise dos resultados dos questionrios, cabe aqui analisar com maior detalhe o Relatrio de Observao da Reunio de Levantamento de Requisitos do Sistema de Gesto de Licitaes. Em princpio observou-se, com base no relatrio e na observao, que durante a reunio o processo de negcio bastante utilizado, ocorrendo vrias consultas visando diversas definies, tanto a respeito do negcio quanto a respeito do sistema de licitaes. Notou-se tambm que nas reunies existe grande envolvimento dos gestores de licitaes, auxiliados, em seu raciocnio, pelos processos de negcio. Com base nesse envolvimento, ocorre uma maior clareza das necessidades dos gestores, e isso colabora bastante para que os analistas de requisitos identifiquem com maior rapidez e objetividade as funcionalidades e necessidades requeridas para o sistema de licitaes. Observou-se tambm que a reunio segue basicamente o fluxo do processo, isso colabora claramente com a idia de se manter na linha de raciocnio, evitando possveis disperses e anlises prematuras. Outro aspecto importante a identificao de requisitos que fogem a deciso dos gestores e analistas presentes na reunio. Para esse caso, tais requisitos e outros tpicos so relacionados, e uma reunio especfica com chefes de licitao e da rea de tecnologia da empresa marcada. Neste caso, o que se observa novamente a ajuda dos processos de negcio na explicao dos requisitos e tpicos identificados. Para as duas formas de analisar os resultados, ou seja, tanto nos questionrio quanto no relatrio, foi identificada a real importncia dos processos de negcio na tarefa de especificar

27

o Sistema de Licitaes da Empresa, seja direcionando os trabalhos ou trazendo maior compreenso para o negcio levando, conseqentemente, a um levantamento de requisitos mais apurado e condizente com a realidade do sistema almejado pela assessoria de licitaes da empresa. Outra anlise importante, tirada dos resultados dos instrumentos da metodologia, foi o fato de no haver um mtodo definido e documentado na empresa para o uso dos processos de negcio no levantamento de requisitos. Mesmo com a falta desse mtodo, os processos se mostraram extremamente teis para o propsito de levantar as funcionalidades do sistema conforme externado durante esta anlise de resultados.

28

5 CONCLUSO

A proposta para esta pesquisa se mostrou bastante desafiante. Adentrar nas amplas reas de Engenharia de Requisitos e Engenharia de Processos de Negcio deixou claro que, independente de suas relaes, existe uma contribuio inquestionvel para a sociedade e as organizaes que a compe. Entretanto, o objetivo foi alm, e a idia de relacionar essas duas grandes reas se mostrou bastante promissora. Dessa forma, antes de discutir e consolidar tal relacionamento, o estudo adotou a proposta de trazer um referencial terico amplo e ao mesmo tempo atento aos objetivos do trabalho, procurando elucidar o leitor a respeito das duas reas e ao mesmo tempo cumprindo a tarefa de limitar a pesquisa em seu carter mais essencial. Com isso, tal referencial procurou tratar as duas reas de maneira independente, mostrando os seus conceitos principais e trazendo em seguida os elementos especficos de cada rea necessrios para promover a base do artigo. Com a definio do referencial terico, o estudo se tornou apropriado para propor um relacionamento entre as reas. Tal relacionamento foi caracterizado a partir do foco na relevncia dos processos de negcio quando se deseja elicitar e levantar requisitos de um sistema de informao. Ao promover essa anlise, foram contemplados aspectos de fundamental importncia para o artigo, evidenciados a partir do trabalho desenvolvido por Carvalho (2009). Sua idia de buscar demonstrar diversas metodologias, presentes na literatura, a respeito das abordagens de identificao de requisitos de sistemas a partir de processos de negcio e analis-las criticamente, identificou a inexistncia, dentro do seu universo de pesquisa, de uma metodologia que atenda plenamente o objetivo de relacionar as reas. Isso mostra sensivelmente o quanto este aspecto novo e o quanto isso abre a possibilidade para novos trabalhos que aperfeioem e contemplem esta relao to til para os projetos de desenvolvimento de software. Embasados pelos estudos citados acima, partiu-se para a identificao de elementos que demonstrassem maior praticidade e proximidade com o objetivo do artigo. Este aspecto pde ser contemplado a partir da necessidade de um estudo de caso e de uma metodologia que emitisse resultados e uma anlise concisa e clara a respeito do objeto estudado. A anlise dos resultados evidenciada no mbito do projeto do sistema de informao, estudado a partir da metodologia, aponta para o fato de haver um ganho real no uso da modelagem de processos na elicitao e levantamento de requisitos de um sistema. Com o uso dos questionrios e relatrio de observao foi possvel ver que os envolvidos se mostraram satisfeitos com o uso 29

dos processos de negcio, mesmo sem possuir uma metodologia definida e documentada para extrair requisitos desses processos, executando tal tarefa de maneira um tanto quanto intuitiva ou de certa forma, amparada por uma maneira prpria de cumprir o objetivo. Esse fato retrata o trabalho elaborado por Carvalho (2009), mencionado acima. Tomando por base tudo que foi inferido na pesquisa, pode-se dizer que a modelagem de processos de negcio ajuda, segundo as informaes colhidas e analisadas no decorrer da pesquisa, na tarefa de levantamento e elicitao de requisitos de um sistema de informao. O aspecto de ajuda compe, basicamente, o papel de propor uma linha de raciocnio para os envolvidos, auxiliar a compreenso e objetividade dos gestores e analistas e, acima de tudo, contribuir junto com a Engenharia de Requisitos para um software o mais prximo do ideal para a organizao. fundamental ainda dizer que este aspecto de ajuda reflete a necessidade de um levantamento e anlise de requisitos dentro dos padres da engenharia de software, ou seja, para este caso os diagramas de processos de negcio atuam como um adereo a esta tarefa, sendo determinantes aqui os referenciais e mtodos da Engenharia de Requisitos. Os frutos provenientes dessa pesquisa so muitos. O estudo proporcionou, de incio, o crescimento do conhecimento dos autores, a disposio em contribuir para o meio acadmico e em sua essncia o papel de cumprir o objetivo do trabalho. evidente a possibilidade de continuidade da pesquisa em propor novos mtodos e formas para o levantamento de requisitos de sistemas de informao com o uso de processos de negcio, considerando assim, toda essa pesquisa e seus frutos, um instrumento til para o meio acadmico.

30

REFERNCIAS

AALST, W. et al. Business Process Management: models, techniques and empirical studies. Berlin: Springer, 2000.

ALVES, C. F. Seleo de produtos de software utilizando uma abordagem baseada em engenharia de requisitos. Recife, 2001.

BELL, J. et al. Re-Engineering Case Study analysis of business rules and recommendations for treatment of rules in a relational database environment. Bellevue Golden: US West Information Technologies Group, 1990.

BELL, T. E., THAYER, T. A. Software Requirements: Are They Really a Problem? Proceedings on 2nd International Conference on Software Engineering. San Francisco, 1976.

CAMEIRA, R.; CAULLIRAUX, H. Engenharia de Processos de Negcios: consideraes metodolgicas com vistas anlise e integrao de processos. In: 3 Simpsio de Administrao da Produo, Logstica e Operaes Internacionais. Anais Eletrnicos... So Paulo: FGV, 2000.

CARVALHO, E. A. Engenharia de processos de negcios e a engenharia de requisitos: anlise e comparaes de abordagens e mtodos de elicitao de requisitos de sistema orientada por processos de negcio. Rio de Janeiro, 2009.

DVALOS, R. V. Modelagem de processos: livro didtico. 4 ed. Palhoa, 2010.

DIAS, F. et al. Uma Abordagem para a Transformao Automtica do Modelo de Negcio em Modelo de Requisitos. In: Workshop em Engenharia de Requisitos (WER06). Anais pp. 51-60. Rio de Janeiro: PUC-Rio, 2006.

31

ERIKSSON, H. E., PENKER, M. Business Modeling with UML: business patterns at work. New York: Wiley Publishers, 2000.

FILHO, W. P. P. Engenharia de Software: fundamentos, mtodos e padres de software. 3 ed. Rio de Janeiro, 2009.

GOTTESDIENER, E. "Business Rules Show Power, Promise". Application Development Trends, v. 4, n.3, 1997.

GROVER, V., KETTINGER W.R. Process Think: winning perspectives for business change in the information age. Inglaterra: Idea Group, 2000.

HAMMER, M., CHAMPY, J. Reengenharia: repensando a empresa em funo dos clientes, da concorrncia e das grandes mudanas da gerncia. 1 ed. Rio de Janeiro: Campus, 1994.

JACOBSON, I. Object -Oriented Software Engineering. Addison-Wesley. 1992

NAGEL, C., ROSEMANN, M. ITN252, Process Engineering, Cadeira de psgraducacao distancia, Austrlia, Queensland, 1999.

NUSEIBEH, B., EASTERBROOK, S. Requirements Engineering: a roadmap. In: Conference on the Future of Software Engineering. Proceedings, pp. 35-46. Limerick (Ireland), 2000.

NUSEIBEH, B., EASTERBROOK, S. Requirements Engineering: A Roadmap. Proceedings of the 22nd International Conference on Software Engineering. Limerick, Ireland. Jun. 2000.

PIDD, M. Just Modeling Through: a rough guide to modeling. Lancaster (UK): Department of Management Science - The Management School - Lancaster University, 1999.

32

PINHO, Manoel Orlando de Morais. Dicionrio de Termos de Negcios: Portugus - Ingls / Inglesh - Portuguese. 2 ed. So Paulo. Atlas, 1997.

PRESSMAN, R. S. Engenharia de Software. 6 ed. So Paulo, 2006.

ROSS, R.G., LAM, G. S. W. The BRS Business Rule Methodology, Business Rule Solutions, 2000.

SANTOS, R. P. C. Engenharia de Processos: anlise do referencial terico-conceitual, instrumentos, aplicaes e casos. Dissertao (Mestrado em Engenharia de Produo) COPPE, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2002.

SANTOS, R. P. C. et al. Engenharia de Processos de Negcios: aplicaes e metodologias. In: XXII Encontro Nacional de Engenharia de Produo (ENEGEP). Anais Eletrnicos... Curitiba: ABEPRO, 2002.

SCHEER, W. ARIS Business Process Frameworks, 2 ed. Berlin: Springer Verlag, 1998.

SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Addison-Wesley, 2007.

TANENBAUM, Andrew S., MARQUES, Arlete Simele. ZUCCHI, Wagner. Organizao Estruturada de Computadores, 5 ed. So Paulo. Pearson Prentice Hall, 2007.

VERNADAT, F. B. Enterprise Modeling and Integration: principles and applications. 1 ed. London: Chapman & Hall, 1996.

VICENTE, L. S. S. Modelagem de Processos e Linguagem de Modelagem Unificada: uma anlise crtica. Dissertao (Mestrado em Engenharia de Produo) COPPE, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2004.

33

VON HALLE, B. Business Rules Applied. New York: John Wiley & Sons, 2002.

ZAHNISER, R. A. Building Software inGroups, Amaerican Programmer. v. 3. n. 7-8. jul/ago, 1990.

ZULTNER, R. Quality Function Deployment for Software: Satisfying Customers, American Programmer. p. 28-41. 1992.

34

ANEXO A QUESTIONRIO PARA ANALISTA DE REQUISITOS

Prezado(a), O presente questionrio parte integrante do trabalho de concluso do curso superior em Sistemas de Informao/Faculdade Projeo, e objetiva realizar uma pesquisa sobre as relaes de uso existentes entre a modelagem e diagramas dos processos de licitao e o levantamento das necessidades e funcionalidades do Sistema de Gesto de Licitaes da empresa, o qual os senhores(as) participam, atualmente, no papel de analistas de requisitos. fundamental que sua opinio seja emitida com absoluta autenticidade e liberdade para que os resultados sejam representativos e vlidos, possibilitando concluses depois de tabulados e classificados. A sua participao extremamente importante para este estudo. Os dados e resultados so de finalidade exclusivamente acadmica. Desde j agradecemos sua contribuio para esta pesquisa.

1 - Est definido e documentado na metodologia de desenvolvimento de sistemas, usada na concepo do Sistema de Licitaes, o mtodo de uso dos modelos de processos na tarefa de levantamento e elicitao de requisitos? ( ( )Sim )No

2 - Indique o nvel de dificuldade do uso dos diagramas de processo de negcio no processo de levantamento de requisitos do Sistema de Licitaes. ( ( ( )Baixo )Mdio )Alto

3 - Indique na escala o quanto a presena dos diagramas de processo de negcio impactaram positivamente na elicitao e levantamento de requisitos do Sistema de Licitaes. ( ( ( )No impactou )Impactou parcialmente )Impactou completamente

35

4 - Indique o nvel de objetividade e conhecimento do cliente no momento da tarefa de levantamento dos requisitos do Sistema de Licitaes. Estabelea como diferencial o fato de se estar utilizando a modelagem de processos de negcio neste projeto, comparando com outros que no utilizaram. ( ( ( )Baixo )Mdio )Alto

5 - Indique o quanto os diagramas de processo de negcio influenciam a tarefa de formao da lista de prioridades de desenvolvimento dos requisitos do Sistema de Licitaes. ( ( ( )No influenciaram )Influenciaram parcialmente )Influenciaram completamente

6 - Indique o quanto os diagramas de processo de negcio so capazes de apontar os requisitos do Sistema de Licitaes. ( ( ( )No capaz )Parcialmente capaz )Completamente capaz

36

ANEXO B QUESTIONRIO PARA EQUIPE DE LEVANTAMENTO DE PROCESSOS DE NEGCIO Prezado(a), O presente questionrio parte integrante do trabalho de concluso do curso superior em Sistemas de Informao/Faculdade Projeo, e objetiva realizar uma pesquisa sobre as relaes de uso existentes entre a modelagem e diagramas dos processos de licitao e o levantamento das necessidades e funcionalidades do Sistema de Gesto de Licitaes da empresa, o qual os senhores(as) participam, atualmente, no papel de analistas de processo. fundamental que sua opinio seja emitida com absoluta autenticidade e liberdade para que os resultados sejam representativos e vlidos, possibilitando concluses depois de tabulados e classificados. A sua participao extremamente importante para este estudo. Os dados e resultados so de finalidade exclusivamente acadmica. Desde j agradecemos sua contribuio para esta pesquisa.

1 - Durante as reunies para mapeamento dos processos de negcio de licitao, foram levados em considerao os aspectos de um sistema de informao? ( ( )Sim )No

2 - Indique qual foi o nvel de percepo dos gestores de licitaes da empresa em relacionar, durante as reunies de mapeamento, os processos de negcio com o futuro sistema de informao. ( ( ( )Baixo )Mdio )Alto

3 - Classifique a compreenso que os gestores de licitaes demonstraram a respeito da afirmao que a modelagem dos processos de negcio muito mais abrangente do que os sistemas de informao. ( ( )Sim )No

37

4 - Existiu a preocupao por parte dos gestores de licitaes em redesenhar o processo, ou seja, propor melhorias, antes de desenvolver o sistema de informao, impedindo uma automatizao precipitada? ( ( )Sim )No

5 - Durante a modelagem dos processos de licitao foram identificados os requisitos macro para subsidiar o desenvolvimento do sistema de informao? ( ( )Sim )No

38

ANEXO C QUESTIONRIO PARA CLIENTES GESTORES DA REA DE LICITAES DA EMPRESA Prezado(a), O presente questionrio parte integrante do trabalho de concluso do curso superior em Sistemas de Informao/Faculdade Projeo, e objetiva realizar uma pesquisa sobre as relaes de uso existentes entre a modelagem e diagramas dos processos de licitao e o levantamento das necessidades e funcionalidades do Sistema de Gesto de Licitaes da empresa, o qual os senhores(as) participam, atualmente, no papel de clientes, gestores da rea de licitaes da empresa. fundamental que sua opinio seja emitida com absoluta autenticidade e liberdade para que os resultados sejam representativos e vlidos, possibilitando concluses depois de tabulados e classificados. A sua participao extremamente importante para este estudo. Os dados e resultados so de finalidade exclusivamente acadmica. Desde j agradecemos sua contribuio para esta pesquisa.

1 - Indique o quanto os processos de negcio tm auxiliado o levantamento das necessidades e funcionalidades do sistema de licitaes. ( ( ( )No auxilia )Auxilia parcialmente )Auxilia completamente

2 - Quanto ao levantamento das funcionalidades do sistema de licitaes, com o uso dos processos de negcio, indique o nvel do atendimento de suas expectativas quanto ao objetivo de especificar o sistema de informao? ( ( ( )Baixo )Mdio )Alto

3 - Tomando como base as funcionalidades j levantadas do Sistema de Licitaes, como voc entende a participao dos processos de negcio nesse levantamento? ( ( ( )Irrelevantes )Considerveis )Determinantes 39

4 - Indique o nvel de clareza com que possvel identificar, nos diagramas de processo de negcio, as funcionalidades e necessidades do sistema de licitaes. ( ( ( )Baixo )Mdio )Alto

5 - Na sua viso, qual o grau de comprometimento dos participantes das reunies para levantamento das funcionalidades do Sistema de Licitaes, em se manter dentro escopo dos processos de negcio. ( ( ( )Baixo )Mdio )Alto

40

ANEXO D - RELATRIO DE OBSERVAO DA REUNIO PARA LEVANTAMENTO DE REQUISITOS. ESTUDO DE CASO: SISTEMA DE GESTO DE LICITAES Com o intuito de melhor compreender o estudo de caso, tornou-se necessrio, alm dos questionrios, a participao dos pesquisadores nas reunies de elicitao e levantamento de requisitos do sistema, a fim de observar e construir conceitos importantes para os objetivos do artigo. Em primeiro lugar, necessria uma contextualizao com a funo de orientar e em segundo lugar o relatrio propriamente dito onde ser tratado o fluxo das reunies e seus objetivos.

Contextualizao Com a finalidade de melhor situar o leitor do relatrio, torna-se importante, em primeiro lugar, contextualiz-lo com o intuito de promover um melhor entendimento a respeito da observao retratada no relatrio em questo. At o momento da observao da reunio, j haviam sido feitas inmeras outras reunies. Um primeiro bloco de reunies teve como intuito, analisar e adequar, caso necessrio, os modelos de processos de negcio, modelos esses que refletissem com a maior preciso possvel a gesto de licitaes na empresa. Estas reunies foram lideradas pela equipe de analistas de processo e tiveram a participao dos analistas de requisitos e gestores da rea de licitao. O fruto dessas reunies foram os diagramas dos processos de licitaes da empresa. Um segundo bloco de reunies, lideradas pelos analistas de requisitos deram incio ao processo de levantamento e analise de requisitos do sistema. Nessas reunies, os diagramas de processos de negcio, relacionados preparao e desenvolvimento de licitaes com comisso permanente de licitaes, foram lidos juntamente com os gestores, e deles se extraiu uma primeira lista de requisitos, ainda sem nenhum detalhamento. Com essa lista, partiu-se para um terceiro bloco de reunies que, em um primeiro momento, somente detalharia os requisitos constantes da lista sem a necessidade de anlise dos processos, entretanto, novamente sentiu-se a necessidade de recorrer aos processos de negcio para direcionar, e fazer relembrar o fluxo, visando o principal foco dessas reunies que a tarefa de detalhar os requisitos. A observao proposta pelo relatrio a seguir referese exatamente a esse momento, ou seja, ocorre o detalhamento dos requisitos com o uso constante dos processos de negcio.

41

Relatrio A reunio se inicia buscando revisar o que foi tratado na reunio anterior. Para isso, o diagrama de processo de negcio atual aberto e com base nele so revisados alguns passos anteriores para situao no fluxo, requisitos j levantados e posterior retomada dos trabalhos. A partir da, todos os participantes seguem o andamento do fluxo do processo para identificao da prxima atividade que resultar em um ou mais requisitos do sistema. Identificada a atividade, inicia-se discusso entre os analistas e o gestor de licitaes para levantamento das funcionalidades possveis naquele momento, levando sempre em considerao o fluxo do processo. Nesse momento so sanadas vrias dvidas, sejam tcnicas ou processuais, tanto por parte do gestor quanto dos analistas de requisito e todas as observaes pertinentes a esse instante so anotadas para posterior documentao. Uma vez identificado um requisito, e mediante os argumentos da discusso anterior, passa-se a identificao de outros requisitos filhos que se relacionam com o identificado dando origem a um diagrama criado, no momento da reunio, por um dos analistas. De posse do diagrama, cada requisito analisado individualmente gerando um detalhamento composto pelos itens: descrio, atores, campos, observaes e critrio de priorizao. O detalhamento feito manualmente pelos analistas de requisitos e, em outro momento, so passados para o documento de concepo constante da metodologia de desenvolvimento da empresa. Tal documento servir como base para criar uma lista de priorizao das funcionalidades que sero especificadas posteriormente visando o desenvolvimento. Em alguns momentos, surgem necessidades de deciso, quanto aos requisitos, que escapam o poderio do grupo na reunio. Para esses casos, mantida uma lista que servir como base para um outro tipo de reunio em que so convidados chefes da rea de desenvolvimento de sistemas e os gestores da rea de licitaes da empresa que deliberaro sobre os assuntos listados. O processo de levantamento e elicitao dos requisitos, dessa forma, compreendido a partir do ciclo explicado acima cabendo aos analistas e aos gestores entenderem o processo de negcio e estabelecerem, em conjunto, as necessidades para automatiz-lo de maneira eficiente e objetiva.

42