Uma Proposta de Elicitao e Anlise de Requisitos no Contexto de Mdias e Pequenas Empresas de Desenvolvimento de Software

Cristiano Ferreira de Souza, Victor F. A. Santander Universidade Estadual do Oeste do Paran (UNIOESTE), Cascavel PR Brasil xikaun@hotmail.com, vfasantander@unioeste.br

Resumo. Na literatura da rea de Engenharia de Requisitos apresentam-se diversas mtricas de elicitao, anlise, documentao e gerncia de requisitos, sempre tendo como condutor o engenheiro de requisitos. Acredita-se que outra abordagem efetiva consiste em tornar o usurio/cliente como protagonista do processo de engenharia de requisitos. Mais especificamente, neste trabalho prope-se uma abordagem alternativa a qual permite j nas primeiras fases do processo de engenharia de requisitos elicitar o maior nmero de requisitos sob a perspectiva e direta conduo do usurio e/ou cliente. A proposta apoiada por uma ferramenta computacional a qual tambm brevemente apresentada e utilizada em um estudo de caso. Palavras chave: Elicitao de Requisitos, Desenvolvimento de Software, Ferramenta Computacional.

1. Introduo
A engenharia de requisitos tem um papel fundamental no processo de desenvolvimento de software. Particular ateno deve ser dedicada ao processo e tcnicas utilizados para gerar especificaes de requisitos no ambguas, consistentes e completas. Contudo, o que ocorre que no raramente negligencia-se o processo de elicitao, anlise, validao e documentao de requisitos. Isto ocorre por inmeros motivos tais como falta de um processo de engenharia de requisitos bem definido, falta de comprometimento ou valorizao dos envolvidos em relao a etapa de engenharia de requisitos, uso de tcnicas e estratgias de engenharia de requisitos inadequadas ao contexto organizacional que norteia os trabalhos de engenheiros de requisitos e clientes, presso do cliente para entrega rpida de uma verso do sistema, entre outros aspectos. O que se obtm como consequncia uso de prticas que levam ao desenvolvimento de sistemas computacionais que no atendem em sua plenitude aos anseios dos seus clientes e usurios. Se levarmos esta problemtica ao contexto de pequenas e mdias empresas (PMEs) de desenvolvimento de software nas quais os recursos tanto humanos quanto financeiros so limitados, o problema torna-se mais grave e evidente. Estas empresas que representam cerca de 73% das empresas desenvolvedoras em nvel nacional [9] se defrontam diariamente com situaes que envolvem o desenvolvimento de novos sistemas ou a evoluo de sistemas existentes em condies que incluem pouco tempo disponvel do cliente, necessidade de entender um novo domnio de problema, falta de convico do prprio cliente em relao ao que est solicitando, tempo limitado para levar a cabo

processo de engenharia de requisitos, entre outros fatores. Contudo, consensual tanto para a comunidade acadmica quanto para industrial que reduzir a incompletude, inconsistncia, e ambiguidade dos requisitos j no incio de projetos de software uma estratgia eficaz para reduzir custos no desenvolvimento, bem como para produzir sistemas computacionais que atendam aos requisitos funcionais e no-funcionais propostos [5], [6]. Neste contexto entendemos que o ponto inicial para reduzir os problemas j relatados passa pela necessidade de utilizar estratgias que permitam elicitar e analisar requisitos da forma mais efetiva possvel considerando particularmente o usurio/cliente como maior detentor do conhecimento necessrio a especificao e descrio de uma necessidade apontada pelo mesmo. Contudo, sabe-se que elicitar informaes sobre necessidades de usurios em relao a sistemas computacionais no um processo trivial, pois geralmente o usurio possui uma viso simplificada da situao, na qual, na maioria das vezes no se tem claro os resultados esperados [7]. Uma possvel soluo que diminui consideravelmente os problemas neste processo de elicitao e anlise fazer com que o usurio/cliente seja considerado como protagonista do processo e o trabalho do engenheiro de requisitos seja orientado sob esta perspectiva. Quando se descreve algum requisito, seja ele funcional ou no-funcional, o envolvido na escrita assume um compromisso maior com o processo e as avaliaes do que se est escrevendo, o que ocorre quase que instintivamente. Assim, com o envolvimento do usurio no processo como elemento fundamental do mesmo, garante-se maior credibilidade, pois as informaes sero mais concisas e os resultados esperados definidos corretamente. Considerando este contexto surge a motivao para a presente proposta, a qual inclui um novo conceito de abertura de chamados tendo o usurio como protagonista. O termo abertura de chamado aqui utilizado como sinnimo de solicitao do cliente em relao a uma necessidade de soluo computacional que encaminhada a uma empresa de desenvolvimento de software categorizada como PME. Cabe ressaltar que este cenrio de abertura de chamados foi constatado a partir da observao das necessidades identificadas em empresas de desenvolvimento de software de mdio e pequeno porte da regio Oeste do Paran, bem como particularmente na ineficcia presente na abertura de chamados de projetos realizada em muitos casos via e-mail ou telefone, as quais claramente mostram-se inadequadas para a realizao de uma correta elicitao e anlise de requisitos. Alm disso, percebe-se nas empresas investigadas que quando um chamado aberto e as informaes so insuficientes, existe a necessidade de um novo contato por parte de um analista da empresa de software buscando sanar as deficincias encontradas e na maioria das vezes este processo precisa ser reiniciado devido a total inconsistncia das informaes obtidas inicialmente. Assim, neste trabalho prope-se um novo modelo de abertura de chamados, ou seja, o registro da inteno do cliente em requerer uma soluo de software para um problema existente. A soluo proposta constitui-se de um processo bem definido para esta situao, bem como de uma ferramenta computacional que apia engenheiros de requisitos na adoo da proposta no atendimento de abertura de chamados tendo o usurio como protagonista. Visando validar a presente proposta aplica-se a mesma a uma abertura de chamado de desenvolvimento de sistema computacional realizada por uma empresa do ramo do agronegcio. Cabe destacar que entre as vantagens inicialmente percebidas na adoo da proposta esto uma reduo no tempo de elicitao e anlise de requisitos, obteno de informaes mais consistentes j que as mesmas so expostas e avaliadas pelo prprio usurio, percepo da complexidade do projeto por parte do prprio cliente e conscientizao do mesmo em relao ao impacto dessa complexidade no tempo e

esforos necessrios a implementao do sistema solicitado, obteno de maior preciso no planejamento do projeto e mais especificamente na estimativa de tempo e esforo necessrios para implementar o sistema solicitado, entre outros aspectos. O presente artigo est estruturado da seguinte forma: na seo 2 apresenta-se a problemtica identificada em um cenrio clssico no contexto de uma empresa desenvolvedora de software categorizada como PME. Cabe salientar que consideramos que este cenrio repete-se em muitas empresas desta categoria em mbito nacional. Na seo 3 apresentada a abordagem proposta para diminuir o impacto da coleta de informaes junto ao cliente e na seo 4 a proposta aplicada a um estudo de caso real. Na seo 5 apresenta-se uma anlise detalhada dos resultados obtidos com a realizao de um estudo de caso. Na seo 6 so realizadas as consideraes finais do trabalho bem como so relatados possveis trabalhos futuros.

2. Apresentando um Cenrio Clssico comum a Vrias PMEs desenvolvedoras de software

Para expressar melhor a proposta, apresenta-se a seguir um cenrio clssico de uma das empresas de desenvolvimento de software investigadas. importante salientar que a empresa observada faz parte da APL Iguassu IT em um total de 50 empresas afiliadas [10]. O cenrio descrito comum a maioria das empresas de software observadas e acreditamos que tambm faz parte da realidade de outras empresas em nvel nacional. A empresa cujo cenrio descrito a seguir atua no desenvolvimento, suporte e consultoria em software com foco em empresas do ramo do agronegcio, cooperativas, cerealistas, etc. A empresa possui uma sistemtica bem definida de atendimento ao cliente. Inicialmente um dos profissionais no setor de Service Desk, o qual um analista de suporte nvel 1, responsvel pelo primeiro contato com o cliente efetuando a abertura do projeto com os dados repassados pelo mesmo via e-mail ou telefone. Na sequncia, aps a abertura do chamado, este profissional repassa estas informaes a um analista de suporte nvel 2 que encarrega-se de efetuar a identificao do problema e elicitao dos requisitos de acordo com a massa de dados inicialmente repassada pelo cliente. Aps estes procedimentos esta demanda repassada a um analista de produtos que avalia a viabilidade do projeto e define as diretrizes quanto ao desenvolvimento. Na sequencia em caso de um projeto com previso de mais de 12 horas para desenvolvimento este chamado encaminhado para um analista de negcios que fica responsvel pela confeco da ECU Especificao de Caso de Uso, que aps valid-la com o analista de produto verificando se a mesma atende as diretrizes definidas, encaminha o projeto a um analista de sistemas que a partir da ECU efetua a realizao dos casos de uso definindo tambm as diretrizes de codificao. A partir deste ponto segue-se o curso tradicional de codificao, testes e implantao. Atualmente a porta de entrada de abertura de projetos de software pode vir por duas vias: 1 a partir de consultoria a clientes realizada por um analista de negcios, na qual os requisitos so elicitados de imediato juntamente ao usurio e a demanda levada para a empresa. No ambiente da empresa de desenvolvimento prossegue-se com os seguintes passos: especificao funcional a qual inclui a especificao dos casos de uso, realizao dos casos de uso e elaborao de outros diagramas UML pelo analista de sistemas, desenvolvimento pelo programador, realizao de testes pelo analista de testes ou um testador, versionamento pela engenharia de configurao e entrega do projeto ao cliente.

2 o cliente, por telefone ou e-mail, repassa as informaes para um analista de suporte Junior (Nvel 1) que efetuar a abertura da solicitao (Chamado) e ser encaminhada para um analista de suporte pleno ou snior (Nvel 2) que efetuar a anlise inicial e o levantamento dos requisitos. Estes requisitos sero especificados resultando na gerao de um artefato para esse fim e o mesmo ser encaminhado para o analista de negcios que procede com o processo conforme apresentado na 1 via. Atualmente o meio mais utilizado para o incio de projetos a 2 via, sendo nesta estratgia que se identifica o maior problema na abertura dos projetos. Como j mencionando anteriormente, as descries apresentadas pelos clientes neste ponto so absurdamente nebulosas, no apresentando os detalhes necessrios para o entendimento claro da solicitao. Alguns e-mails solicitando a abertura de projetos de software so enviados com textos similares a descrio conforme segue: Desenvolver um sistema para controle de ICMS sobre despesas de frota prpria. Assim, no contexto da segunda via de solicitao de projetos, o perodo de trabalho adicional mencionado entre o analista de suporte de Nvel 1 e o de Nvel 2 utilizado para tentar levantar o mximo de informaes que foram omitidas inicialmente ou por conhecimento tcito ou por falta de um processo mais sistemtico e eficaz de elicitao. Sem essas informaes torna-se impossvel dar prosseguimento ao atendimento da solicitao de forma adequada. Contudo, detecta-se no modelo atual que em mdia despende-se neste processo de elicitao pelo analista de suporte nvel 2, mais de 10 vezes tempo do que o gasto na abertura do projeto pelo analista nvel 1, conforme informaes extradas em relatrio de horas do sistema de BI da empresa objeto de estudo. Com a utilizao da nova sistemtica proposta neste trabalho, na qual o usurio ter que avaliar a real necessidade do projeto respondendo um conjunto de perguntas direcionadas, bem como avaliar a clareza e completude de sua solicitao, estabelece-se uma maior possibilidade de que o trabalho intermedirio do Analista de Negcios, que a pessoa que se utiliza das informaes coesas para desenvolver as especificaes funcionais, seja reduzido significativamente, acarretando menor custo de horas ao projeto, maior qualidade e maior clareza. importante ressaltar que na abertura de chamado de projeto atravs da 1 via, a utilizao da sistemtica proposta neste artigo auxiliar a padronizar as aberturas de projeto. Tambm estabelece-se uma situao na qual o cliente se depara antecipadamente com questionamentos que auxiliaro o analista de negcios na elicitao e analise de requisitos, obtendo um ganho significativo de tempo de execuo do projeto ou mesmo quando o cliente no efetuar um registro prvio antes da visita do analista de negcios o mesmo pode utilizar o sistema para guia-lo nos questionamentos de forma a criar uma linha de raciocnio mais definida na identificao do problema e da possvel soluo. Outra vantagem desta sistemtica a padronizao da abertura do projeto e o registro da mesma como base histrica no sistema. Assim, o preenchimento das informaes nesta situao auxiliar tanto o cliente quanto o analista de negcios a entender o problema em questo, nesta via do processo o analista de suporte no interage. Assim, o foco deste trabalho est na especificao mais clara do problema a ser solucionado, tendo como meta principal reconhecer os elementos bsicos deste problema sob a perspectiva e direta participao do cliente. Saber o que se quer resolver com uma soluo computacional o primeiro passo para a definio do escopo de trabalho, pois, sabendo exatamente qual o problema que se deve atacar inicia-se o processo de anlise para definir as solues de software possveis.

3. A Abordagem Proposta
A ideia central deste estudo efetuar uma abordagem de anlise de problema e elicitao de requisitos voltada ao stakeholder mais importante do processo, o cliente. Sob esta perspectiva a partir das necessidades do cliente que surge um projeto de software. Vrios trabalhos realizados na rea de engenharia de requisitos tais como [1], apresentam modelos de elicitao nos quais o cliente ou deve estar comprometido com uma viso de TI mais aprofundada. A presente proposta refora esta perspectiva na qual o cliente deve se comprometer com a informao por meio da tomada de iniciativa, interagindo com um sistema computacional que o guiar no processo inicial de estabelecimento de suas necessidades. Assim prope-se um sistema computacional que atravs de perguntas bem direcionadas ao que de fato quer se elicitar permite integrar o cliente no processo de elicitao de requisitos de forma direta reduzindo a obteno de informaes ambguas e incompletas. Na figura 1 apresenta-se a interface do sistema computacional com algumas das questes que permitem apoiar clientes no processo de realizao de chamados para um projeto de software e mais especificamente para o detalhamento do problema. Nesta figura so apresentados os elementos: breve descrio da necessidade, no qual solicita-se uma explicao com maior riqueza de detalhes sobre o processo de negcio a ser gerido computacionalmente; o elemento Funcionamento atual, no qual solicita-se uma descrio de como o processo em questo controlado atualmente e o elemento Dependncias do Processo no qual solicita-se a verificao quanto a dependncia de informaes existentes no processo em relao a outros atores, sistemas ou stakeholders.

Fig. 1. Identificao do problema Alm das questes apresentadas na figura 1 o sistema dispe de um numero maior de questes. Na primeira tela do sistema que no foi inserida neste trabalho por questes de

espao, requerida do usurio no momento da abertura do projeto, a identificao do solicitante contento os seguintes elementos: Cliente, ou seja, a empresa solicitante do servio, Contato que seria a pessoa responsvel pela abertura do projeto, Produto indicando o produto a ser desenvolvido e caso seja solicitada a alterao de um produto j existente indicar a qual se refere, Objetivo do Projeto que seria a ideia principal do desenvolvimento, Usurios chave envolvidos que solicitam as informaes dos stakeholders envolvidos no projeto, Dados a serem armazenados que correspondem aos dados que devem ser registrados no sistema, Relatrios que indicam informaes que com determinada frequncia sejam tabuladas e Frequncia de utilizao do sistema que reflete a frequncia de utilizao do sistema dando um indicativo da importncia do mesmo. Na ultima tela a ser preenchida h algumas verificaes tais como saber se o contato definido na tela inicial a pessoa de contato em caso de duvidas e caso no seja indicar o nome e o setor onde este contato trabalha. Outra questo importante saber qual o impacto da no implementao da soluo, e por fim, um ltimo campo disponvel para preenchimento dedicado a qualquer informao adicional que queira ser registrada. O sistema tambm possui um conjunto mnimo de informaes para a coleta de dados em torno do problema com a preocupao de no torn-lo burocrtico demais. Este um aspecto crtico se considerarmos, por exemplo, a via 2 de solicitao de projetos expressa na seo 2. Nesta situao, a partir de um contexto inicial de um envio de um e-mail ou um telefonema prosseguia-se com a execuo do restante do projeto de software. Com a adoo da proposta passa-se para uma situao em que essa agilidade na abertura dos chamados no ser uma realidade e o preenchimento do formulrio ser uma necessidade. O cliente dever se convencer das vantagens desta nova forma de abertura de projetos. Est claro, considerando as boas prticas da engenharia de requisitos [7], que a suposta agilidade anteriormente verificada com o envio de e-mail ou realizao de telefonema era nada mais nada menos que isentar o prprio cliente do desconforto de uma anlise mais aprofundada sobre o problema. Esta falsa agilidade pode ser percebida pelas inmeras falhas, inconsistncias e esforo extra detectados na empresa exemplificada na seo 2, bem como nas demais empresas de desenvolvimento de software que adotam a mesma prtica.

Fig. 2. Expectativas do projeto

O sistema tambm apresenta outras importantes questes direcionadas expectativa do projeto por parte do cliente e informaes adicionais necessrias, conforme pode ser visualizado nas figuras 2 e 3, respectivamente. Assim, os campos que devem ser preenchidos so os que definiro caractersticas do projeto tais como data de entrega, riscos da no implementao do software, entre outras informaes relevantes ao direcionamento do projeto, e identificao das expectativas do cliente. Desta forma, observando o contexto do cenrio clssico apresentado na seo 2, no qual permite-se utilizar duas vias de abertura de chamado, seguem algumas consideraes no que tange a melhoria do processo de elicitao no referido cenrio utilizando nossa proposta.

Fig. 3. Informaes adicionais A abordagem proposta neste trabalho vem ao encontro da necessidade de que o cliente possa formular com mais clareza, consistncia e completude suas ideias iniciais sobre um novo projeto de software e/ou modificao de um projeto j existente. Tambm vale observar que na maioria das vezes a pessoa responsvel por encaminhar a solicitao de abertura de chamado, que pode ser o responsvel pela rea de TI na empresa ou outro representante do cliente, no detm todo o conhecimento e informaes necessrias para a abertura do projeto. Nesta situao bastante comum e considerando nossa proposta, este contato induzido atravs de perguntas objetivas a consultar os usurios chaves na empresa visando obter a informao necessria, bem como melhorar o entendimento do problema por todos os stakeholders. Desta forma, uma equipe acaba se formando e se

envolvendo com o processo por parte do cliente solicitante, melhorando assim todo o processo de engenharia de requisitos. Considerando essa base de informaes descritas pelo cliente, as dificuldades inerentes primeira reunio entre engenheiro de requisitos e cliente/usurio so bastante reduzidas. Assim, o engenheiro de requisitos poder formular suas perguntas antes da reunio de forma muito mais precisa e o cliente ter o processo bem definido em mente para responder os questionamentos. Cabe ressaltar que esta abordagem de elicitao de informaes sobre as demandas de um projeto traz tona o desconhecimento de muitos usurios em relao ao que esperam de um projeto. Quando os mesmos se defrontam com um sistema computacional que apresenta formulrios com questes bem dirigidas sobre quais informaes so necessrias a abertura de um projeto e/ou modificao do mesmo, inicia-se um processo que permite usurios buscar meios para expressar adequadamente o que desejam solicitar. Assim, com esta nova viso tenta-se fazer com que o cliente realize uma descrio mais aprofundada do problema que quer solucionar, incentivando o mesmo a envolver sua equipe no projeto podendo mensurar com mais preciso a complexidade do trabalho a ser desenvolvido e conseqentemente entender e valorizar o trabalho de engenharia necessrio para elaborar uma soluo computacional para esse problema. Com a grande possibilidade do envolvimento do cliente no processo h dados iniciais concisos e com qualidade, os quais possibilitam reduzir os contatos posteriores com usurios e clientes, permitindo desta forma, focar os esforos no desenvolvimento do projeto nas fases posteriores.

4. Aplicando a Proposta a um Projeto Real

Para avaliar a aplicabilidade da proposta apresentada neste trabalho, a mesma foi utilizada na elaborao de um projeto de mdio porte no contexto de uma empresa desenvolvedora de software integrada a APL Iguassu IT (Ver seo 2). A via de entrada de dados para projeto conforme apresentado na seo 2 foi a via 1, na qual o analista de negcios foi at o cliente para elicitar as informaes necessrias guiando-se pelas questes abordadas no sistema proposto para o levantamento das necessidades. Em contato com a empresa avaliada, verificou-se que o cliente desejava solicitar a alterao nas regras de um modulo do ERP (Enterprise Resource Planning), o qual responsvel pelo processamento de vendas efetuadas pelos produtores rurais e que proporciona a recuperao de ICMS de insumos utilizados na produo de produtos agrcolas. A empresa cliente atua no ramo do agronegcio comercializando produtos agrcolas e insumos para seus parceiros e associados. Na visita efetuada pelo analista de negcios foi inicialmente contactado o responsvel pela rea de TI e na sequencia em conjunto com o usurio responsvel pelo gerenciamento das informaes do modulo a ser alterado, foram coletadas as informaes e sanadas as duvidas quando ao processo. Essas informaes foram coletadas e catalogadas seguindo os questionamentos existentes no sistema computacional proposto para esse fim. De acordo com o que foi avaliado pelo analista de negcios alguns complementos e alteraes no sistema computacional proposto foram efetuados, entre os quais destacamse a possibilidade de gravar qualquer registro digitado em qualquer momento, bem como a retirada da obrigatoriedade de preenchimento das questes anteriormente consideradas como obrigatrias. Estas alteraes se fizeram necessrias, pois o tempo para formular cada resposta pode-se estender provocando interrupes relativamente longas, bem como o texto digitado pelo responsvel pela abertura do projeto pode atingir dimenses que

exigem parar e recomear o trabalho em momentos diferentes. Assim para evitar a perda de dados possibilitou-se gravar os dados em qualquer momento, podendo na sequncia retomar o processo para complementao, concluso ou alterao. A proposta visa o envolvimento do usurio com o entendimento do problema. Desta forma um projeto no ser necessariamente aberto com rapidez. O usurio pode ter a necessidade de consultar a outras pessoas e/ou documentos e isso pode fazer com que o mesmo pare com a abertura por alguns instantes retomando-a na sequncia. Depois de efetuadas as alteraes no modelo, o analista de negcios guiou-se pelo formulrio contido no sistema e gerou uma documentao de 8 pginas. Essa mesma documentao foi apresentada a um analista de sistemas que a definiu como suficiente para estimar o prazo do projeto, que de acordo com sua anlise somente para desenvolvimento seriam necessrias em torno de 180 horas. Alm destas horas ainda foram estimadas mais 40 horas para realizao de testes, estimando o projeto total em 220 horas.

Fig. 4. Tela de detalhamento do problema preenchida Esta estimativa inicial gerada para o projeto considerou como base as informaes elicitadas atravs da nossa proposta. Cabe ressaltar que o tempo dedicado ao processo de elicitao inicial foi de aproximadamente 11 horas representando aproximadamente 5% do tempo total do projeto. Na figura 4, que representa a tela de detalhamento do problema abordado na referida organizao, podem ser observadas as consultas de informaes referentes ao cadastramento do projeto no sistema. Foi identificado que a linha de raciocnio criada a partir da sequncia dos questionamentos auxilia significativamente na coleta dos dados de forma a agilizar o procedimento.

5. Anlise dos Resultados considerando o Estudo de Caso Realizado

Todo esforo despendido por parte das empresas desenvolvedoras de sistemas inclui custos diretamente ligados a quantia de horas trabalhadas no projeto. Por isso o entendimento do problema nos momentos iniciais do projeto torna-se crucial para o bom andamento e atendimento das expectativas quanto ao mesmo. Os requisitos devem estar claros para todos os envolvidos no processo, de forma a institucionalizar as solues junto aos envolvidos. O comprometimento do cliente facilita o levantamento de requisitos e diminui o custo do projeto e o emprego de tcnicas de elicitao em conjunto com ferramentas torna-se um grande aliado neste processo. O cliente tem de entender o problema. O analista ou engenheiro de requisitos, na falta de alguma informao substancial, deve estar apto a efetuar questionamentos que sejam precisos para o bom entendimento do projeto.

3,3

9,88
HELP DESK COOPERATBC HELP DESK COOPERATE DEMAIS SETORES

86,82
Fig. 5. Percentual de horas Trabalhadas por setor [Fonte: Datacoper Software]. Na figura 5 apresenta-se um grfico gerado a partir do software de BI (Business Intelligence) da prpria empresa objeto de estudo, que contm a apurao de esforo empregado em projetos de software na referida empresa. Este relatrio apresenta o esforo dividido por setores da empresa. Extraindo no relatrio as informaes pertinentes ao foco deste trabalho, verifica-se que nos projetos de software a elicitao inicial dos requisitos, que efetuada pelo setor de Help-Desk, est tomando 9,88% e 3,3% do tempo, totalizando um percentual de 13,18% do tempo total utilizado nos projetos de software. Estes tempos so gastos apenas para a identificao do problema e a elicitao inicial dos requisitos. Este entendimento efetuado por meio de inmeros contatos com o cliente para garimpar as informaes de forma informal e no metdica. No grfico apresentado na figura 6 tambm gerado pelo software de BI, h a representao de retrabalhos de projetos de software que representam um 8,42% em relao ao volume de chamados baixados no perodo, em que na sua maioria se deu por requisitos mal elicitados, levando a uma conduo errnea de desenvolvimento.

8,42%
SOLICITAES BAIXADAS

91,58%

RETRABALHOS

Fig. 6. Solicitaes baixadas e retrabalhos [Fonte: Datacoper Software].

O percentual de retrabalhos em projetos de software na empresa objeto de estudo maior do que est sendo apresentado no grfico apresentado. Esta falta de informao coesa ocorre pela dificuldade na identificao dos retrabalhos ou mesmo por falha operacional no cadastramento dos chamados. Aps avaliao do cenrio atual da empresa, foi submetido o trabalho em questo para avaliao por parte da gerente de projetos, de dois desenvolvedores, um analista de negcios, um analista de suporte e uma analista de produto da empresa objeto do estudo. Os profissionais avaliaram alguns pontos referentes proposta de elicitao e expressaram que o impacto inicial ao cliente significativo, visualizando que o comprador tem uma tendncia a simplificar o processo de abertura de projeto. Tambm o dispndio de tempo na leitura dos cenrios pode ser algo que para alguns usurios no seja comum, muitas vezes por falta de comprometimento com o processo. Quando se visualiza a proposta por outro ngulo, sob a perspectiva da burocracia gerada pela quantidade de questes e pelos cenrios, a gerente de projetos identificou que o modelo atende s necessidades bsicas dos projetos de software incluindo a identificao do problema, forando o cliente a entender o projeto que pretende iniciar: visualizao das suas necessidades de prazo, injeo de capital e expectativas de soluo, bem como identificao das implicaes da no implementao do projeto validando os gaps existentes. Os desenvolvedores e o analista de produto que avaliaram a ferramenta apresentaram que a soluo se torna interessante por padronizar a abertura de projetos e por procurar levantar junto ao usurio o mximo de informao possvel, garantindo maior eficcia nas solues tcnicas propostas. No entendimento da proposta de elicitao foi esclarecido que ela no ir eliminar o contato do analista de requisitos com o cliente. A utilizao de cenrios, perguntas diretas e questes livres de contexto daro mais qualidade nos questionamentos a serem efetuados, e uma viso contextualizada do problema tanto para o cliente quanto para o analista. Na utilizao do modelo na pratica ao contexto do problema da empresa no controle de ICMS Rural, verificou-se um ganho significativo de tempo, porem entende-se na organizao que h necessidade de aplicar a proposta a outros projetos para consolidar os resultados positivos obtidos at o momento. Contudo este estudo inicial j indica uma maior eficincia e reduo de tempo durante o processo de elicitao anlise e especificao de requisitos. Assim torna-se sem duvida interessante avaliar os resultados e efetuar uma comparao, verificando que no formato anterior tinha-se um volume aproximado de 14% de dispndio de trabalho para o levantamento das necessidades e com a nova abordagem este percentual foi reduzido para cerca de 5% do total do esforo dispendido no projeto.

6. Consideraes Finais e Trabalhos Futuros

Neste trabalho apresentou-se uma abordagem de elicitao de requisitos cujo foco est em estabelecer o usurio/cliente como protagonista do processo. Para apoiar a proposta, uma ferramenta computacional foi desenvolvida e aplicada a uma empresa de desenvolvimento de software, cujos principais profissionais integrados equipe de desenvolvimento e usurios/clientes da referida organizao avaliaram a proposta. Alguns trabalhos na rea de requisitos similares abordagem sugerida neste trabalho apresentam a necessidade de se gerenciar os requisitos de software e o quanto os mesmos so importantes para o processo de desenvolvimento.

Entre os trabalhos relacionados pode-se destacar a proposta apresentada em [8], a qual apresenta um prottipo de sistema computacional para elicitao de requisitos. A diferena dessa proposta em relao ao nosso trabalho est em que o foco est no engenheiro de requisitos, sem exigir do usurio/cliente um comprometimento formal como expresso na nossa abordagem. Outro trabalho relacionado apresentado em [1], o qual apresenta um sistema de gerenciamento de requisitos baseado em cenrios conforme definido na metodologia ERACE. Esta ferramenta se apresenta como uma forte aliada de engenheiros de requisitos de forma a suportar a especificao das interaes e modelagem de cenrios. Outro trabalho relacionado est associado ao projeto SIGERAR [3], o qual um projeto voltado para a gesto dos artefatos de requisitos, controlando as interaes e dependncias entre artefatos de requisitos. Entre os trabalhos futuros pode-se destacar a evoluo da ferramenta incluindo novas necessidades percebidas no dia a dia de sua utilizao, bem como aplicar a proposta a outros projetos da empresa considerada neste artigo e tambm a outras empresas que compem a APL Iguassu IT [10]. Tambm pretende-se investigar como a presente proposta pode ser integrada ao trabalho apresentado em [8], melhorando o processo de elicitao e anlise de requisitos a partir da construo de modelos organizacionais [11] que possam derivar modelos funcionais tais como casos de uso.

Referencias
1. Caldas Junior, Joo. Masiero, Paulo., ERACE-TOOL Uma Ferramenta Baseada em Cenrios para a Engenharia de Requisitos. Anais do WER98 - Workshop em Engenharia de Requisitos, Maring-PR, Brasil, Outubro 12, 1998, pp 70-78 2. Brito, Regiane Andrade. Vasconcelos, Alexandre., Integrando Groupware e gerenciamento de requisitos no suporte a engenharia de requisitos distribuda. Anais do WER06 Workshop em Engenharia de Requisitos, Rio de Janeiro, RJ, Brasil, Julho 13-14, 2006, pp 84-92. 3. Grande, Jos. Martins, Luiz., SIGERAR Uma ferramenta para Gerenciamento de Requisitos. Anais do WER06 - Workshop em Engenharia de Requisitos, Rio de Janeiro, RJ, Brasil, Julho 13-14, 2006, pp 75-83. 4. Pressman, Roger., Engenharia de Software, cap. 11, Editora McGraW-Hill, Rio de Janeiro, 5 Edio, 2002, p. 265 a 292. 5. Gastaldo, Denise. Midorikawa, Edson., Processo de Engenharia de Requisitos Aplicado a Requisitos no Funcionais. Anais do WER03 - Workshop em Engenharia de Requisitos, Piracicaba-SP, Brasil, Novembro 27-28, 2003, pp 302-316. 6. Macedo, Nstor. Leite, Julio., Elicit@99 um Prottipo de Ferramenta para Elicitao de Requisitos, Anais do WER99 - Workshop em Engenharia de Requisitos, Buenos Aires, Argentina, Setembro 9-10, 1999, pp 45-55. 7. Kotonya, G., Somerville, I., Requirements Engineering: Processes and Techniques, John Wiley & Sons, (1997). 8. Santander, V. F., Castro, J.F., Deriving Use Cases from Organizational Modeling, In: IEEE Joint International Requirements Engineering Conference, RE02, University of Essen, Germany, September, 9-13, (2002), pp. 32 39. 9. Kalinowski, Marcos. Santos, Gleison, Reinehr, Sheila. Montoni, Mariano. Rocha, Ana Regina. Weber, Kival Chaves. Travassos, Guilherme Horta. MPS.BR: Promovendo a Adoo de Boas Prticas de Engenharia de Software pela Indstria Brasileira. In: XIII Congresso IberoAmericano em Software Engineering, Cuenca, Equador 2010. p. 57-62. 10. APL Iguassu-IT: http://www.iguassu-it.org.br/ 11.Yu, E., Modelling Strategic Relationships for Process Reengineering, Phd Thesis, University of Toronto, (1995).