Essa análise <strong>de</strong>ve ser conduzida antes da aquisição do sistema, pois o resultado terá reflexoem todo o processo <strong>de</strong> implantação, tendo consequências no tempo <strong>de</strong> duração daimplantação, na contratação <strong>de</strong> consultoria externa, nas customizações a serem realizadas, naprofundida<strong>de</strong> da mudança, no treinamento dos usuários e, principalmente, no custo final doprojeto (Trova, 2004).Neste contexto, existem pesquisas que <strong>de</strong>stacam a importância do uso das metas donegócio para impulsionar o <strong>de</strong>senvolvimento <strong>de</strong> um produto <strong>de</strong> software (Estrada et al.,2002).Muitas técnicas tradicionalmente aplicadas no <strong>de</strong>senvolvimento <strong>de</strong> software tratam <strong>de</strong>aspectos relacionados à funcionalida<strong>de</strong> do sistema, à <strong>de</strong>scrição <strong>de</strong> ativida<strong>de</strong>s e entida<strong>de</strong>s, àsentradas que <strong>de</strong>verão ser transformadas e às saídas que <strong>de</strong>verão ser produzidas. Porém, nãoconsi<strong>de</strong>ram aspectos mais amplos como: os objetivos da organização, as regras <strong>de</strong> negócio, asrestrições, os aspectos não funcionais relacionados à qualida<strong>de</strong>, à confiabilida<strong>de</strong> e àusabilida<strong>de</strong> (Pádua, Cazarini e Inamasu, 2004).De acordo com Alencar (1999), essas técnicas não ajudam, portanto, a buscar soluçõesalternativas para problemas da organização, não adicionam valor ao negócio e, na maioria dasvezes, os processos manuais são automatizados sem nenhuma modificação. Esses mo<strong>de</strong>lostêm como objetivo a <strong>de</strong>scrição <strong>de</strong> sistemas técnicos, em vez <strong>de</strong> fornecer <strong>de</strong>scrições mais ricassobre as organizações sócio humanas.Dessa forma, o que se tem são técnicas capazes <strong>de</strong> obter requisitos funcionais <strong>de</strong> umsistema, <strong>de</strong> <strong>de</strong>screver ativida<strong>de</strong>s e entida<strong>de</strong>s, porém, sem consi<strong>de</strong>rar aspectos importantes daorganização, como os seus objetivos, suas estratégias, sua política, suas restrições, etc. Assim,faz-se necessário uma abordagem mais rica, que facilite os esforços da Engenharia <strong>de</strong>Requisitos para obter uma melhor compreensão sobre os relacionamentos da organizaçãoentre os vários atores do sistema, e enten<strong>de</strong>r as razões envolvidas nos processos <strong>de</strong> <strong>de</strong>cisões.O analista <strong>de</strong> sistemas tem habilida<strong>de</strong> para <strong>de</strong>screver a empresa em termos <strong>de</strong> estrutura <strong>de</strong>dados que esta utiliza e a organização das funções que realiza, mas ten<strong>de</strong>m a negligenciar asrestrições com as quais a organização opera (BRG, 1997). Os requisitos organizacionais não<strong>de</strong>vem ser consi<strong>de</strong>rados como uma simples <strong>de</strong>scrição da funcionalida<strong>de</strong> do sistema, poistratam do domínio no qual o sistema está inserido e das restrições que po<strong>de</strong>m existir noambiente, no sistema e no <strong>de</strong>senvolvimento, diminuindo ambiguida<strong>de</strong>s e incertezas.26
Para garantir que os sistemas cumpram com sua finalida<strong>de</strong>, os <strong>de</strong>senvolvedores <strong>de</strong>vempossuir uma compreensão mais aprofundada sobre a organização. O mo<strong>de</strong>lo organizacional éuma representação da estrutura, das ativida<strong>de</strong>s, dos processos, das informações, dos recursos,do pessoal, do comportamento, dos objetivos e das restrições das empresas comerciais,governamentais ou <strong>de</strong> outra natureza (Pádua, Cazarini e Inamasu, 2004).Segundo Santan<strong>de</strong>r e Castro (2000), a i<strong>de</strong>ia é subsidiar os engenheiros <strong>de</strong> requisitos commetas estratégicas <strong>de</strong> negócios na organização as quais <strong>de</strong>vem ser analisadas e pon<strong>de</strong>radas nomomento do <strong>de</strong>senvolvimento <strong>de</strong> um sistema computacional. Além disso, também permitirque engenheiros <strong>de</strong> requisitos, a partir <strong>de</strong> uma observação mais <strong>de</strong>talhada dos mo<strong>de</strong>losorganizacionais, possam optar pela melhor alternativa para o <strong>de</strong>senvolvimento do software.Para Bubenko Jr. e Wangler (1993), um bom sistema <strong>de</strong> informação <strong>de</strong>ve aten<strong>de</strong>r àsnecessida<strong>de</strong>s do negócio, caso contrário, o sistema estará impedindo o <strong>de</strong>senvolvimento donegócio. Este é o motivo do início <strong>de</strong> um novo paradigma, que muda da engenharia dainformação orientada à tecnologia e abordagens orientadas a objetos, para estruturas quefocam em mo<strong>de</strong>lagem <strong>de</strong> regras do negócio.Segundo Alencar (1999), o principal obstáculo à captura correta dos requisitos <strong>de</strong> umsistema tem sido a dificulda<strong>de</strong> em se obter uma compreensão mais aprofundada do domínioda aplicação. Neste contexto, a mo<strong>de</strong>lagem organizacional facilita a compreensão doambiente empresarial e é reconhecida como ativida<strong>de</strong> valiosa pela Engenharia <strong>de</strong> Requisitos.Para a autora, a mo<strong>de</strong>lagem organizacional possui o objetivo <strong>de</strong>:a) fornecer um objeto, que seja uma representação compartilhável e reusável da ca<strong>de</strong>ia <strong>de</strong>fornecimento <strong>de</strong> informação e conhecimento;b) suportar tarefas da ca<strong>de</strong>ia <strong>de</strong> fornecimento, pela habilitação <strong>de</strong> respostas aquestionamentos, que não estão explicitamente representados no mo<strong>de</strong>lo;c) <strong>de</strong>finir os objetos <strong>de</strong> maneira precisa, <strong>de</strong> forma que sejam consistentemente aplicados,por meio dos domínios e interpretados pelos usuários;d) suportar visualização do mo<strong>de</strong>lo, <strong>de</strong> forma intuitiva, simples e consistente.Existem diversas técnicas <strong>de</strong> mo<strong>de</strong>lagem organizacional. Algumas <strong>de</strong>las são realizadascom múltiplas visões, analisando metas e objetivos da organização (Bubenko Jr. e Kirikova,1994). A organização, segundo os autores, é representada por meio <strong>de</strong> mo<strong>de</strong>los, que facilitama realização <strong>de</strong> especificações <strong>de</strong> requisitos mais próximas à realida<strong>de</strong> da organização.27
- Page 2 and 3: FERNANDO LUIZ GRANDOAVALIANDO TÉCN
- Page 4 and 5: DEDICATÓRIAAos meus pais e minha i
- Page 6 and 7: AGRADECIMENTOSA Deus, pela saúde e
- Page 8 and 9: 3.24: Notações básicas para Caso
- Page 10 and 11: Lista de Abreviaturas e SiglasB2BBP
- Page 12 and 13: SumárioLista de Figuras ..........
- Page 14 and 15: ResumoHoje em dia, o desenvolviment
- Page 16 and 17: conjunto estruturado de atividades
- Page 18 and 19: forma de satisfação de objetivos,
- Page 20 and 21: será inserido não foi modelado e
- Page 22 and 23: Já no Capítulo 4 o estudo compara
- Page 24 and 25: Uma incorreta identificação de re
- Page 26 and 27: a) Requisitos Funcionais (RF): são
- Page 28 and 29: Kotonya e Sommerville (1998) descre
- Page 30 and 31: Já Alencar (1999), propõe diretri
- Page 32 and 33: Informações mais completas a resp
- Page 34 and 35: confirmar teorias ou validar medida
- Page 36 and 37: Sendo o GQM orientado a objetivos o
- Page 38 and 39: No próximo capítulo são apresent
- Page 42 and 43: Nas seções seguintes, serão apre
- Page 44 and 45: Figura 3.2: Parte de um MO de uma B
- Page 46 and 47: a) Entidade: é alguma coisa do dom
- Page 48 and 49: componentes do Modelo de Objetivos;
- Page 50 and 51: Figura 3.7: Exemplo de parte de um
- Page 52 and 53: mesmo tempo seja capaz de lidar com
- Page 54 and 55: Swimlanes (raias) (Tabela 3.3): fun
- Page 56 and 57: Um exemplo de segmento de processo
- Page 58 and 59: 3.4 A Técnica i*A técnica i*, pro
- Page 60 and 61: Na dependência de tarefa, o Depend
- Page 62 and 63: 3.4.2 O Modelo de Razões Estratég
- Page 64 and 65: observa nas dependências do tipo o
- Page 66 and 67: Os principais elementos do modelo s
- Page 68 and 69: egras refletem políticas do negóc
- Page 70 and 71: IFTHENELSE(sinistro é assegurado p
- Page 72 and 73: alcançar o objetivo-alvo “Realiz
- Page 74 and 75: A especificação de um caso de uso
- Page 76 and 77: Analisando brevemente algumas das t
- Page 78 and 79: Capítulo 4Estudo Comparativo e Ava
- Page 80 and 81: Figura 4.1: Ciclo de vida de projet
- Page 82 and 83: solução: desenvolver um sistema d
- Page 84 and 85: M09: As respostas coletadas de um g
- Page 86 and 87: Figura 4.2: Diagrama BPMN para o m
- Page 88 and 89: Figura 4.4: Diagrama SR para o mód
- Page 90 and 91:
Figura 4.6: Diagrama SR para o mód
- Page 92 and 93:
Regra de Negócio 04: REALIZAR PEDI
- Page 94 and 95:
Figura 4.9: Diagrama de Casos de Us
- Page 96 and 97:
No Modelo de Conceitos podem ser vi
- Page 98 and 99:
formuladas, com o intuito de fornec
- Page 100 and 101:
possibilitando também a divisão d
- Page 102 and 103:
sendo inserido. Kaabi, Souveyet e R
- Page 104 and 105:
Para o estudo comparativo foi utili
- Page 106 and 107:
Capítulo 5Considerações FinaisAp
- Page 108 and 109:
de Uso de Negócio não consegue re
- Page 110 and 111:
BIDER, I., JOHANNESSON, P. Tutorial
- Page 112 and 113:
ESTRADA, H., MARTÍNEZ, A., PASTOR,
- Page 114 and 115:
PENADÉS, M. C., CANÓS, J. H., SÁ
- Page 116:
WHITE, S. Business Process Modeling