ResumoHoje em dia, o <strong>de</strong>senvolvimento <strong>de</strong> softwares complexos e <strong>de</strong> baixo custo é um gran<strong>de</strong><strong>de</strong>safio para a Computação, em especial para a área <strong>de</strong> Engenharia <strong>de</strong> Software. Geralmenteos requisitos <strong>de</strong> software são mal analisados e especificados, o que resulta em programas <strong>de</strong>baixa qualida<strong>de</strong>. No entanto, observa-se que o trabalho da Engenharia <strong>de</strong> Requisitos po<strong>de</strong> sermelhorado se mo<strong>de</strong>larmos aspectos organizacionais visando enten<strong>de</strong>r melhor as intenções emotivações organizacionais que incorporam o <strong>de</strong>sejo do <strong>de</strong>senvolvimento <strong>de</strong> um sistemacomputacional. Verifica-se nesse contexto a necessida<strong>de</strong> <strong>de</strong> realizar um estudo comparativoentre técnicas <strong>de</strong> mo<strong>de</strong>lagem organizacional existentes, <strong>de</strong> forma a apresentar uma avaliaçãodas mesmas, <strong>de</strong>stacando as suas principais características e qualida<strong>de</strong>s no processo <strong>de</strong>elicitação <strong>de</strong> requisitos <strong>de</strong> software. Para tanto, neste trabalho realiza-se uma avaliação <strong>de</strong>stastécnicas utilizando princípios da Engenharia <strong>de</strong> Software Experimental. Como resultado,obtém-se uma análise crítica dos mo<strong>de</strong>los organizacionais estudados, visando apoiarengenheiros <strong>de</strong> requisitos em uma melhor escolha da técnica a ser aplicada. A técnica i* po<strong>de</strong>ser consi<strong>de</strong>rada a que mais se <strong>de</strong>stacou na avaliação realizada, permitindo, <strong>de</strong> formaabrangente, representar vários aspectos do contexto organizacional, além <strong>de</strong> possibilitar aalocação <strong>de</strong> responsabilida<strong>de</strong>s ao sistema computacional inserido como um novo ator namo<strong>de</strong>lagem da organização.Palavras-chave: Engenharia <strong>de</strong> Requisitos, Mo<strong>de</strong>lagem <strong>Organizacional</strong>, Desenvolvimento <strong>de</strong>Software.xiii
Capítulo 1IntroduçãoEsse capítulo tem como objetivo a apresentação do trabalho, indicando as motivações parao seu <strong>de</strong>senvolvimento, bem como a sua estruturação. Inicialmente, na Seção 1.1, a proposta écontextualizada no escopo da Engenharia <strong>de</strong> Software, <strong>de</strong>stacando a importância do processo<strong>de</strong> Engenharia <strong>de</strong> Requisitos na obtenção <strong>de</strong> produtos <strong>de</strong> software <strong>de</strong> qualida<strong>de</strong>. Na Seção 1.2,são <strong>de</strong>scritas as principais motivações que levaram a execução <strong>de</strong>ste estudo. Na Seção 1.3, aproposta em si é explanada, bem como seus principais objetivos. Já na Seção 1.4, sãorelatadas as contribuições esperadas com o <strong>de</strong>senvolvimento do presente trabalho. Por fim, naSeção 1.5 a organização <strong>de</strong>sse documento é apresentada.1.1 ContextoAtualmente, o <strong>de</strong>senvolvimento <strong>de</strong> softwares cada vez mais complexos, passíveis <strong>de</strong>certificação e com menor custo possível, é um <strong>de</strong>safio constante para a comunida<strong>de</strong> <strong>de</strong>Engenharia <strong>de</strong> Software (ES) (Santan<strong>de</strong>r e Silva, 2006).Nota-se que muitas pessoas envolvidas na área <strong>de</strong> <strong>de</strong>senvolvimento <strong>de</strong> software ainda nãoestão amadurecidas o suficiente para lidar com sistemas complexos e <strong>de</strong> gran<strong>de</strong> porte,utilizando muitas vezes técnicas que não são apropriadas para esses tipos <strong>de</strong> sistemas. Comoresultado, obtém-se uma série <strong>de</strong> problemas, que vão <strong>de</strong>s<strong>de</strong> a estimativa equivocada doscustos envolvidos e cronogramas mal planejados, até a baixa produtivida<strong>de</strong> e, principalmente,a baixa qualida<strong>de</strong> dos produtos.Diversas técnicas e ferramentas vêm sendo propostas com o intuito <strong>de</strong> suportar e auxiliar aprodução <strong>de</strong> software <strong>de</strong> qualida<strong>de</strong>.Neste contexto, uma das etapas mais críticas está relacionada à Engenharia <strong>de</strong> Requisitos(ER), cujo processo é <strong>de</strong>finido por (Kotonya e Sommerville, 1998), como sendo “um1
- 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 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 40 and 41: Essa análise deve ser conduzida an
- 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