transformaÇÃo de um modelo de empresa em um modelo de casos de uso seguindo os conceitos de...

FBIO LEVY SIQUEIRA

TRANSFORMAO DE UM MODELO DE EMPRESA EM UM MODELO DE CASOS DE USO SEGUINDO OS CONCEITOS DE

ENGENHARIA DIRIGIDA POR MODELOS

SO PAULO 2011

Tese de Doutorado apresentada Escola Politcnica da Universidade de So Paulo

SO PAULO 2011

FBIO LEVY SIQUEIRA

TRANSFORMAO DE UM MODELO DE EMPRESA EM UM MODELO DE CASOS DE USO SEGUINDO OS CONCEITOS DE

ENGENHARIA DIRIGIDA POR MODELOS

Tese de Doutorado apresentada Escola Politcnica da Universidade de So Paulo

rea de concentrao: Sistemas Digitais Orientador: Prof. Dr. Paulo Srgio Muniz Silva

FICHA CATALOGRFICA

Siqueira, Fbio Levy Transformao de um modelo de empresa em um modelo de

casos de uso seguindo os conceitos de engenharia dirigida por modelos / F.L. Siqueira. -- So Paulo, 2011.

256 p.

Tese (Doutorado) - Escola Politcnica da Universidade de So Paulo. Departamento de Engenharia de Computao e Sis-temas Digitais.

1. Engenharia de requisitos 2. Engenharia dirigida por modelos 3. Engenharia de software I. Universidade de So Paulo. Es-cola Politcnica. Departamento de Engenharia de Computao e Sistemas Digitais II. t.

i

AGRADECIMENTOS

Ao Prof. Dr. Paulo Srgio Muniz Silva pela amizade e pelos 10 anos de orientao, desde o trabalho de concluso da graduao a at o doutorado. Mesmo depois de todo esse tempo, ainda tenho muito a aprender com ele.

banca de qualificao, composta pelo Prof. Dr. Jaelson Castro e pela Profa. Dra. Selma Shin Shimizu Melnikoff, pelos valiosos comentrios e crticas.

Ao Prof. Dr. Kechi Hirama por permitir a realizao do experimento em sua disciplina.

Aos meus pais, Anita e Gustavo, e s minhas irms, Mnica e Karina, pelo amor e apoio incondicional durante todos esses anos.

Aos meus amigos Alex, Andr, Ivan, Sylvio e Tarcsio pelo companheirismo e pelos momentos de descontrao.

Fundao de Amparo Pesquisa do Estado de So Paulo (FAPESP) por ter fomentado, parcialmente, este doutorado atravs da bolsa nmero 2007/58489-4.

A todos que contriburam de alguma forma para a realizao deste trabalho.

ii

RESUMO

Uma das principais responsabilidades da rea de Engenharia de Requisitos refinar requisitos em especificaes. Em sistemas empresariais esse refinamento deve considerar o contexto empresarial no qual o sistema far parte. Apesar de existirem algumas abordagens para refinar requisitos algumas delas at mesmo considerando o contexto empresarial essa tarefa realizada manualmente. Baseado em conceitos de Engenharia Dirigida por Modelos, este trabalho prope uma transformao semiautomtica usando um modelo da empresa como modelo dos requisitos e um modelo de casos de uso como modelo das especificaes. Para isso, considera-se que ao usar um modelo de empresa como origem dessa transformao possvel representar tanto os requisitos quanto os conhecimentos de domnio necessrios para obter especificaes atravs de uma transformao. Com isso, este trabalho apresenta os metamodelos de origem e de destino, um conjunto de regras de transformao e uma ferramenta que permite executar a transformao. Por fim, este trabalho tambm discute um experimento que foi executado para analisar alguns aspectos desta proposta.

Palavras-chave: engenharia de requisitos, engenharia dirigida por modelos, requisito, especificao, transformao, modelo empresarial, caso de uso.

iii

ABSTRACT

One of the key responsibilities of Requirements Engineering is to refine requirements into specifications. For enterprise systems, this refinement must consider the enterprise context where the system will be deployed. Although there are some approaches for requirements refinement, some of them even considering the enterprise context, this task is executed manually. Based on Model-Driven Engineering concepts, this study proposes a semi-automatic transformation using an enterprise model as a requirements model and a use case model as a specifications model. For that, this work considers that using an enterprise model as a source it is possible to represent both the requirements and the domain knowledge that are necessary to obtain specifications through a transformation. Therefore, this study presents the source and target meta-models, a set of transformation rules, and a tool to support the transformation. Finally, this study also discusses an experiment executed to analyze some aspects of this proposal.

Keywords: requirements engineering, model-driven engineering, requirement, specification, transformation, enterprise model, use case.

iv

LISTA DE FIGURAS

Figura 1.1: Mtodo empregado para a realizao da tese. ........................................ 7

Figura 3.1: O modelo WRSPM, evidenciando os cinco artefatos por ele definidos (GUNTER et al., 2000). ........................................................................................ 19

Figura 3.2: Parte do metamodelo da UML a respeito do caso de uso (OMG, 2011b). ............................................................................................................................. 43

Figura 4.1: Modelo de domnio de uma biblioteca e o metamodelo usado. .............. 60

Figura 4.2: A relao entre os elementos do metamodelo usado no exemplo da Figura 4.1 e o seu metametamodelo. .................................................................. 61

Figura 4.3: Representao de um espao tecnolgico com trs nveis de modelagem, segundo Bzivin (2006). .................................................................. 63

Figura 4.4: Os modelos envolvidos em uma transformao de modelos e a relao entre eles. ............................................................................................................ 66

Figura 5.1: Relao entre o ambiente, o sistema e a empresa. ............................... 71

Figura 5.2: A relao entre os requisitos e a empresa, considerando o ambiente e o sistema. ................................................................................................................ 73

Figura 5.3: A restrio do espao da soluo, considerando alguns momentos especficos, at se obter o sistema construdo. ................................................... 85

Figura 6.1: Representao dos Espaos Tcnicos e as transformaes entre os modelos para o caso de trs Espaos Tcnicos. ............................................... 101

Figura 6.2: A relao entre os modelos do MDA e o cdigo................................... 103

Figura 6.3: A transformao proposta. ................................................................... 109

Figura 6.4: A sintaxe abstrata da viso da estrutura organizacional. ..................... 116

Figura 6.5: Restries nas metaclasses da viso estrutura organizacional. .......... 116

v

Figura 6.6: A sintaxe abstrata do metamodelo de empresa referente viso de ambiente fsico. .................................................................................................. 117

Figura 6.7: Restrio na metaclasse Layout da viso de ambiente fsico. ............. 117

Figura 6.8: A sintaxe abstrata do metamodelo de empresa referente viso de documento. ........................................................................................................ 118

Figura 6.9: Restries nas metaclasses da viso de documentos. ........................ 118

Figura 6.10: A sintaxe abstrata do metamodelo de empresa referente viso motivacional, baseado no BMM (OMG, 2008a). ................................................ 119

Figura 6.11: Parte da sintaxe abstrata do metamodelo de empresa referente viso processual, baseado no BPDM (OMG, 2008b) (OMG, 2008c). ......................... 122

Figura 6.12: Relaes entre os elementos definidos pelas 5 vises do metamodelo de empresa. ....................................................................................................... 123

Figura 6.13: Restrio entre as vises de processo e organizacional. ................... 123

Figura 6.14: A relao da organizao com os demais elementos do metamodelo de empresa. ............................................................................................................ 124

Figura 6.15: A sintaxe abstrata do metamodelo de caso de uso. ........................... 137

Figura 6.16: Restries em OCL (OMG, 2006b) da sintaxe abstrata do metamodelo de caso de uso. .................................................................................................. 138

Figura 6.17: Gabarito como sintaxe concreta do metamodelo de caso de uso. ..... 140

Figura 6.18: Mtodo para obteno das regras de refinamento, descrito em BPMN (OMG, 2011a). ................................................................................................... 145

Figura 6.19: As transformaes entre os modelos do GMF e do EMF para obter cdigo fonte Java de um plug-in grfico (baseado no GMF dashboard (THE ECLIPSE FOUNDATION, 2011a)). .................................................................... 152

Figura 6.20: A parte central do mapeamento. ........................................................ 155

vi

Figura 6.21: Detalhe do mapeamento activity2Action. ........................................... 156

Figura 6.22: Detalhe do mapeamento gateway2Statement. ................................... 157

Figura 6.23: Viso geral da ferramenta EMUCase. ................................................ 158

Figura 6.24: A edio de um diagrama de estrutura organizacional na ferramenta EMUCase. .......................................................................................................... 159

Figura 6.25: O primeiro passo do assistente para a transformao dos modelos de empresa em casos de uso. ................................................................................ 159

Figura 6.26: Validao dos modelos de entrada e sada da transformao. .......... 162

Figura 7.1: O projeto do experimento. .................................................................... 168

Figura 7.2: As atividades realizadas no experimento, descritas usando BPMN (OMG, 2011a). ............................................................................................................... 176

Figura 7.3: Grfico boxplot para as notas do escopo ATM. .................................... 181

Figura 7.4: Grfico boxplot para as notas do escopo Locadora. ............................ 182

Figura 7.5: Respostas dos questionrios finais dos sujeitos que executaram um tratamento com a tcnica de criao de caso de uso Transformao. .............. 186

vii

LISTA DE TABELAS

Tabela 3.1: Viso geral da relao entre o escopo e o nvel de detalhamento do caso de uso e as informaes que eles representam. ......................................... 39

Tabela 3.2: Fatores de qualidade propostos por (PHALP; VINCENT; COX, 2007a). ............................................................................................................................. 54

Tabela 6.1: Comparao entre os Espaos Tcnicos do MDA, XML e EMF. ......... 107

Tabela 6.2: Simplificaes feitas no metamodelo do BPDM. .................................. 121

Tabela 6.3: Sintaxe concreta da viso organizacional. ........................................... 126

Tabela 6.4: Sintaxe concreta da viso de ambiente fsico. ..................................... 126

Tabela 6.5: Sintaxe concreta da viso motivacional. .............................................. 127

Tabela 6.6: Sintaxe concreta da viso de documento. ........................................... 128

Tabela 6.7: Resultados do levantamento realizado nas bases de artigos cientficos. ........................................................................................................................... 129

Tabela 6.8: Frequncia dos elementos nos trabalhos analisados, evidenciando os mais comuns. ..................................................................................................... 132

Tabela 6.9: Frequncia dos subelementos nos trabalhos analisados, evidenciando os mais comuns. ................................................................................................ 134

Tabela 6.10: O posicionamento dos trabalhos em relao organizao dos passos. ........................................................................................................................... 135

Tabela 6.11: Regras obtidas atravs da anlise dos trabalhos relacionados. ........ 142

Tabela 6.12: As regras de refinamento obtidas ao aplicar o mtodo no exemplo da biblioteca. ........................................................................................................... 149

Tabela 6.13: As regras sintticas obtidas ao aplicar o mtodo no exemplo da biblioteca. ........................................................................................................... 149

viii

Tabela 7.1: As variveis independentes e como elas foram tratadas pelo experimento (abordagem): fator, randomizada ou fixa....................................... 167

Tabela 7.2: Nmero de sujeitos para cada um dos tratamentos. ............................ 179

Tabela 7.3: As notas e os tempos obtidos no experimento. ................................... 180

Tabela 7.4: Valores para o teste da hiptese HE1. ................................................. 183



Tabela 7.7: Valores ao analisar os tempos ao empregar a tcnica Modelo da Empresa e Diretamente. .................................................................................... 185

Tabela 7.8: Regras usadas por sujeito. .................................................................. 188

ix

LISTA DE ABREVIATURAS E SIGLAS

ATL Atlas Transformation Language

BMM Business Motivation Model

BPDM Business Process Definition Metamodel

BPMN Business Process Modeling Notation

B-SCP Business Strategy, Context, and Process

CIM Computation Independent Model

DTD Document Type Definition

EKD Enterprise Knowledge Development

EMF Eclipse Modeling Framework

GMF Graphical Modeling Framework

GORE Engenharia de Requisitos orientada por metas (Goal Oriented Requirements Engineering)

i* Intencionalidade Distribuda

KAOS Knowledge Acquisition in Automated Specification ou Keep All Objectives Satisfied

Map Intention/Strategy Map

MDA Arquitetura Dirigida por Modelos (Model Driven Architecture) MDE Engenharia Dirigida por Modelos (Model Driven Engineering) MOF Meta Object Facility O&M Organizao e Mtodos (ou Organizao, Sistemas e Mtodos) OCL Object Constraint Language PIM Platform Independent Model

PSM Platform Specific Model

QVT Query/View/Transformation

x

TI Tecnologia da Informao

TOGAF The Open Group Architecture Framework

TS Espao Tcnico (ou Espao Tecnolgico) (Technical Space) UML Unified Modeling Language

WRSPM World, Requirement, Specification, Platform e Machine

XMI XML Metadata Interchange

XML Linguagem de Marcao Extensvel (Extensible Markup Language) XSLT Extensible Stylesheet Language Transformations

xi

SUMRIO

1 INTRODUO .......................................................................................................... 1

1.1 Motivao ...................................................................................................... 1

1.2 Objetivo ......................................................................................................... 3 1.3 Justificativa .................................................................................................. 4

1.4 Escopo .......................................................................................................... 5

1.5 Hipteses consideradas .............................................................................. 5

1.6 Mtodo .......................................................................................................... 6

1.7 Organizao do trabalho ............................................................................. 8

2 REPRESENTAO DE UMA EMPRESA ......................................................................... 9

2.1 Arquitetura empresarial ............................................................................. 12

2.2 Organizao e Mtodos ............................................................................. 15

2.3 Concluso ................................................................................................... 17

3 REQUISITO, ESPECIFICAO E SUAS REPRESENTAES ........................................... 18

3.1 Definies ................................................................................................... 18

3.2 Engenharia de Requisitos ......................................................................... 25

3.3 Engenharia de Requisitos orientada por metas ...................................... 27

3.3.1 Abordagens orientadas por metas ......................................................... 29

3.3.2 Vantagens e desvantagens de abordagens GORE ............................... 33

3.4 Representao dos requisitos .................................................................. 34

3.5 Caso de uso ................................................................................................ 36

3.5.1 Vantagens e limitaes do caso de uso ................................................ 39

3.5.2 Caso de uso na UML ............................................................................. 41

3.5.3 Representao textual do caso de uso .................................................. 49

3.5.4 Avaliao da qualidade de um caso de uso .......................................... 51

xii

3.6 Concluso ................................................................................................... 54

4 ENGENHARIA DIRIGIDA POR MODELOS (MDE) .......................................................... 56 4.1 Modelo ......................................................................................................... 56

4.2 Viso geral da MDE .................................................................................... 58

4.3 Transformao de modelos ...................................................................... 63

4.4 Formas de representao de metamodelos ............................................ 66

4.5 Concluso ................................................................................................... 68

5 MODELO DA EMPRESA E A TRANSFORMAO DE REQUISITOS EM ESPECIFICAES ..... 69

5.1 Modelo da empresa, requisitos e especificaes ................................... 69

5.1.1 Relao entre o ambiente, a empresa e o sistema................................ 70

5.1.2 Relao entre a empresa e os requisitos .............................................. 72

5.1.3 Modelo da empresa e os modelos dos requisitos e das especificaes 74

5.1.4 Modelo da empresa e sistemas de automao de processos ............... 78

5.2 Transformao de requisitos em especificaes ................................... 80

5.2.1 Limitaes da transformao ................................................................. 83

5.3 Trabalhos relacionados ............................................................................. 86

5.3.1 Abordagens orientadas por metas ......................................................... 86

5.3.2 Abordagens que empregam casos de uso ............................................ 90

5.3.3 Abordagens de transformao seguindo a MDA ................................... 93

5.3.4 Outras abordagens ................................................................................ 96

5.4 Concluso ................................................................................................... 98

6 TRANSFORMAO DO MODELO DA EMPRESA EM MODELO DE CASO DE USO ............. 100

6.1 Escolha do Espao Tcnico .................................................................... 101

6.1.1 Arquitetura Dirigida por Modelos (MDA) .............................................. 102 6.1.2 Eclipse Modeling Framework (EMF) .................................................... 104 6.1.3 Linguagem de marcao extensvel (XML) ......................................... 105

xiii

6.1.4 Anlise dos Espaos Tcnicos ............................................................ 106

6.2 Metamodelo de empresa ......................................................................... 109

6.2.1 Anlise ................................................................................................. 112

6.2.2 Sintaxe abstrata ................................................................................... 115

6.2.3 Semntica ............................................................................................ 124

6.2.4 Sintaxe concreta .................................................................................. 126

6.3 Metamodelo de caso de uso ................................................................... 128

6.3.1 Anlise ................................................................................................. 128

6.3.2 Sintaxe abstrata ................................................................................... 136

6.3.3 Semntica ............................................................................................ 138

6.3.4 Sintaxe concreta .................................................................................. 139

6.4 Regras de transformao ........................................................................ 140

6.4.1 Mtodo para obteno de regras de refinamento ................................ 144

6.4.2 Aplicao do mtodo e as regras de refinamento................................ 147

6.4.3 Problemas e limitaes do mtodo ...................................................... 150

6.5 Ferramenta ................................................................................................ 151

6.5.1 Roteiro da transformao .................................................................... 153

6.5.2 Projetor para o TS do XML .................................................................. 157 6.5.3 Viso geral da ferramenta EMUCase .................................................. 157

6.6 Problemas e limitaes da transformao ............................................ 160

6.7 Concluso ................................................................................................. 162

7 EXPERIMENTO ..................................................................................................... 163

7.1 Declarao do problema .......................................................................... 163

7.2 Planejamento do experimento ................................................................ 164 7.2.1 Ambiente do experimento .................................................................... 165

7.2.2 Variveis e fatores ............................................................................... 166

xiv

7.2.3 Projeto do experimento ........................................................................ 168 7.2.4 Estratgia de anlise dos dados .......................................................... 169

7.2.5 Validade dos resultados ...................................................................... 172

7.3 Operao do experimento ....................................................................... 176

7.4 Anlise e interpretao dos dados ......................................................... 180

7.4.1 Hiptese HE1....................................................................................... 182

7.4.2 Hiptese HE2....................................................................................... 183

7.4.3 Hiptese HE3....................................................................................... 184

7.4.4 Questionrio final ................................................................................. 185

7.4.5 Outras anlises .................................................................................... 187

7.5 Discusso e concluses .......................................................................... 188

8 CONCLUSO ....................................................................................................... 191

8.1 Contribuies ........................................................................................... 192

8.2 Trabalhos futuros ..................................................................................... 192

8.3 Artigos publicados ................................................................................... 194

REFERNCIAS ........................................................................................................... 196

GLOSSRIO ............................................................................................................... 213

APNDICE A ELEMENTOS DE REPRESENTAES DA EMPRESA ................................ 217 APNDICE B SINTAXE CONCRETA EM XML DO METAMODELO DE CASO DE USO ........ 221 APNDICE C MODELO AS-IS E TO-BE DO EXEMPLO DA BIBLIOTECA .......................... 224

C.1. Modelo as-is ............................................................................................. 224

C.2. Modelo to-be ............................................................................................. 228

APNDICE D MODELO DE CASO DE USO IDEAL PARA A BIBLIOTECA ......................... 232 APNDICE E RESULTADO DA TRANSFORMAO PARA O EXEMPLO DA BIBLIOTECA USANDO AS REGRAS INICIAIS ...................................................................................... 237

APNDICE F FORMATO DO CASO DE USO CRUD DA REGRA RR8 ............................ 239

xv

APNDICE G CRITRIOS PARA AVALIAO DE CASOS DE USO ................................. 240 APNDICE H QUESTIONRIOS APLICADOS NO EXPERIMENTO .................................. 242

H.1. Questionrio Inicial .................................................................................. 242

H.2. Questionrio final ..................................................................................... 243

APNDICE I ENUNCIADOS DOS EXERCCIOS USADOS NO EXPERIMENTO .................... 245 I.1. Criao do caso de uso para a ATM ....................................................... 245

I.2. Criao do modelo as-is e to-be para a ATM ......................................... 246

I.3. Criao do caso de uso para a locadora ................................................ 248

I.4. Criao do modelo as-is e to-be para a locadora .................................. 249

I.5. Legenda .................................................................................................... 250

APNDICE J GABARITOS USADOS NO EXPERIMENTO .............................................. 252 J.1. Alugar filme .............................................................................................. 252

J.2. Sacar dinheiro .......................................................................................... 252

APNDICE K RESULTADOS DOS EXPERIMENTOS .................................................... 254

1

1 INTRODUO

Atualmente os sistemas computacionais so fundamentais para que as empresas possam atuar nos mercados cada vez mais competitivos. Eles no somente auxiliam os funcionrios e outras partes envolvidas a realizar algumas de suas atividades, como em alguns casos as automatizam completamente sejam elas atividades simples e repetitivas, ou mesmo to complexas que um grupo de pessoas no conseguiria execut-las com a mesma qualidade e no mesmo tempo. Dessa maneira, os sistemas computacionais auxiliam direta ou indiretamente as empresas a atender s necessidades de seus clientes e, em geral, com um custo menor do que se as atividades fossem realizadas completamente de forma manual.

Apesar de sua importncia, uma empresa no feita somente de sistemas computacionais. Existem diversos outros elementos que a constituem, sejam eles fsicos ou no: os funcionrios, as ferramentas usadas, as atividades executadas, os artefatos gerados como resultados das atividades, os processos executados, os objetivos estabelecidos, as misses definidas, a cultura organizacional existente, entre diversos outros elementos. Cada empresa uma organizao particular devido a esses diversos elementos que a regem coletivamente.

Como o sistema computacional apenas mais um elemento da empresa, a sua criao precisa considerar o contexto empresarial em que ele far parte. Se isso no for feito, o sistema possivelmente no conseguir corresponder s expectativas que motivaram a sua construo podendo at mesmo no ser usado.

1.1 Motivao

Uma das principais responsabilidades da Engenharia de Requisitos levantar o que os clientes desejam do sistema, ou seja, elicitar os requisitos. Os requisitos obtidos atravs desse levantamento devem descrever o ambiente no qual o sistema computacional dever operar evitando, assim, descrever detalhes internos do sistema (ZAVE; JACKSON, 1997). No caso de sistemas empresariais, esse ambiente envolve o contexto empresarial que motivou o desenvolvimento do sistema e no qual o sistema ir operar.

2

Algumas abordagens de elicitao de requisitos consideram o contexto empresarial de forma indireta, como, por exemplo, ao realizar entrevistas, workshops de requisitos, brainstorming e storyboarding. Nessas tcnicas, por mais que os diversos elementos da empresa relacionados ao sistema no sejam explicitados, as partes envolvidas naturalmente levam em considerao essas informaes. Em outras abordagens, so considerados apenas alguns tipos de elementos da empresa e/ou uma abstrao deles para elicitar os requisitos, como, por exemplo, i* (YU, 1995), Tropos (BRESCIANI et al., 2004), B-SCP (BLEISTEIN et al., 2006), e KAOS (VAN LAMSWEERDE, 2009). Por outro lado, algumas abordagens usam especificamente modelos de empresa para a elicitao de requisitos como, por exemplo, EKD (BUBENKO JR. et al., 1998) e em (DE LA VARA; SANCHEZ; PASTOR, 2008) e (MOLINA et al., 2000).

Porm, os requisitos obtidos durante a elicitao ainda no esto expressos de uma forma adequada para que sejam empregados pelas demais atividades de desenvolvimento de sistemas (anlise, projeto, implementao e teste). Alguns deles precisam ser detalhados para que possam ser realizados ou garantidos pelo sistema (ZAVE; JACKSON, 1997), o que pode envolver a seleo entre alternativas. Por exemplo, um requisito de que "um funcionrio deve ser avisado sobre o trmino de uma atividade" ainda impreciso: esse aviso pode ser feito de diversas formas, seja por e-mail, pelo envio de SMS, por uma mensagem disponvel na Intranet etc. A escolha de qual dessas alternativas a mais apropriada depende de informaes do contexto no qual o sistema est inserido, o que envolve o contexto empresarial. Como exemplo disso, se houver uma poltica empresarial afirmando que o e-mail a forma padro de divulgao de informaes coorporativas, ela pode ser suficiente para que seja escolhido o aviso por e-mail.

Apesar da necessidade de detalhamento dos requisitos obtendo o que chamado neste trabalho de especificaes algumas abordagens de Engenharia de Requisitos ou de desenvolvimento de sistemas computacionais no discutem como isso pode ser feito. Em outras, a representao de uma dessas informaes omitida, sendo considerado apenas os requisitos ou as especificaes. O mais frequente no existir uma separao clara entre os requisitos e as especificaes. Entretanto, os requisitos e as especificaes representam diferentes informaes: um representa o que os clientes desejam do sistema e outro o que deve ser

3

construdo. A obteno das especificaes a partir dos requisitos propensa a erros, j que podem ser tomadas decises inadequadas. Mas, alm disso, uma mudana nos requisitos ou no ambiente principalmente ao considerar um contexto empresarial , pode ter impacto direto nas decises tomadas durante esse detalhamento. Em alguns casos essa mudana impacta os requisitos, sendo necessrio revisitar o detalhamento realizado; em outros a mudana no impacta os requisitos, mas as decises tomadas no detalhamento realizado; e em outros a mudana impacta apenas as especificaes no sendo necessrio rever o detalhamento realizado. Dessa maneira, importante representar tanto os requisitos quanto as especificaes, alm das decises tomadas durante o detalhamento. Caso os requisitos no sejam representados, o sistema pode ser restrito de forma inadequada, enquanto que se as especificaes no forem representadas, haver dificuldades para executar as demais atividades de desenvolvimento (MAIDEN, 2008).

1.2 Objetivo

Dada a importncia da obteno das especificaes a partir dos requisitos, o objetivo deste trabalho propor a transformao de um modelo dos requisitos, descrito atravs de um modelo da empresa, em um modelo das especificaes, descrito atravs de um modelo de caso de uso, seguindo os conceitos de Engenharia Dirigida por Modelos. Ao propor essa transformao pretende-se simplificar a execuo de uma das atividades centrais da Engenharia de Requisitos.

Para que essa transformao possa ser executada, este trabalho possui trs objetivos secundrios:

Definir metamodelos de empresa e de casos de uso; Propor regras para a transformao; e Construir uma ferramenta.

Os metamodelos permitem descrever os modelos de entrada e de sada da transformao, ou seja, os modelos de empresa e de casos de uso, respectivamente. As regras concretizam a transformao ao definir como obter as especificaes a partir dos requisitos. Por fim, para executar essa transformao foi

4

construda a ferramenta EMUCase que permite criar o modelo da empresa e transform-lo em um modelo de caso de uso empregando as regras de transformao.

1.3 Justificativa

Existem diversos trabalhos que propem abordagens para a obteno das especificaes a partir dos requisitos, algumas vezes at mesmo empregando modelos de empresa. As abordagens de Engenharia de Requisitos orientadas por metas, como i* (YU, 1995), Tropos (BRESCIANI et al., 2004), B-SCP (BLEISTEIN et al., 2006), e KAOS (VAN LAMSWEERDE, 2009), propem formas para obter especificaes a partir de uma abstrao do ambiente centrada na representao do que chamado de meta. A obteno das especificaes feita manualmente atravs de um processo de refinamento que detalha essas metas e algumas outras informaes relacionadas.

Outros trabalhos propem transformaes envolvendo requisitos e/ou especificaes. Trabalhos como (DIETZ, 2003), (DIJKMAN; JOOSTEN, 2002a), (DIJKMAN; JOOSTEN, 2002b) e (STOLFA; RADECK, 2004) propem transformaes de uma representao do ambiente atual em um modelo dos requisitos descritos atravs de casos de uso. Outros trabalhos, como (DIAS et al., 2006), (ROBINSON; ELOFSON, 2004) e (RODRGUEZ; FERNNDEZ-MEDINA; PIATTINI, 2007), propem transformaes entre diferentes representaes dos requisitos sem obter especificaes (ou seja, fazendo apenas uma mudana de representao). Similarmente, em (DECREUS; SNOECK; POELS, 2009) e (KOLIADIS et al., 2006) so discutidas transformaes entre vises da empresa, consideradas por este trabalho como partes do modelo dos requisitos. Por outro lado, em (SANTANDER; CASTRO, 2002) proposta uma transformao que trata da mudana de representao de especificaes, no caso obtendo como resultado um modelo de caso de uso. Outros trabalhos, como (DE LA VARA; SANCHEZ; PASTOR, 2008) e (MOLINA et al., 2000), abordam a transformaes de requisitos, representados por diferentes vises da empresa, em especificaes, representadas por casos de uso.

5

Apesar de esses trabalhos apresentarem diversas similaridades com esta proposta, poucos consideram explicitamente o contexto empresarial para detalhar os requisitos em especificaes. Alm disso, nessas abordagens as especificaes so obtidas manualmente a partir dos requisitos. Em contraposio, uma transformao semiautomtica de requisitos em especificaes ajudaria a evitar alguns erros durante o detalhamento dos requisitos. Mais que isso, ela facilitaria a absoro de mudanas nos requisitos, o que essencial em um ambiente dinmico, como o caso do ambiente empresarial. Nesse sentido, a existncia de uma ferramenta que executa a transformao e que permite a alterao de um modelo j criado contribui tanto para a absoro de mudanas nos requisitos (durante o desenvolvimento ou mesmo durante a manuteno) como para a realizao semiautomtica da transformao. Alm disso, do ponto de vista terico, a definio de tal transformao tambm ajuda a melhorar o entendimento da diferena entre requisitos e especificaes.

1.4 Escopo

A transformao de requisitos em especificaes proposta considera apenas os requisitos funcionais, portanto, no tratando de requisitos no funcionais e restries de projeto. Alm disso, a transformao limitada a sistemas com as seguintes caractersticas, que sero chamados de sistemas de automao de processos:

Automatizam processos de negcio, com foco no fluxo de trabalho; e So internos a uma empresa, mas podem possuir algumas interfaces com

outros participantes. Essas caractersticas permitem simplificar a transformao, seja ao facilitar a criao das regras de transformao, ou mesmo ao evidenciar a presena dos requisitos em um modelo da empresa. Alm disso, esse escopo permite evidenciar as vantagens da transformao, deixando clara a passagem de requisitos em especificaes.

1.5 Hipteses consideradas

A transformao de requisitos em especificaes proposta por este trabalho centrada em quatro hipteses:

6

H1. Um modelo da empresa do ponto de vista organizacional representa requisitos funcionais de sistemas de automao de processos.

H2. Em projetos em que no h uma reengenharia completa da empresa, o modelo as-is da empresa possui parte do conhecimento de domnio necessrio para se refinar requisitos em especificaes.

H3. Em sistemas de automao de processos possvel automatizar a transformao de requisitos presentes em um modelo da empresa em especificaes.

H4. Em sistemas de automao de processo, o modelo da empresa as-is pode ser usado como referncia para decises de refinamento.

A hiptese H1 considera, no contexto de sistemas de automao de processo, que um modelo da empresa consegue representar os requisitos funcionais de modo a ser visto como um modelo dos requisitos. De forma similar, a hiptese H2 considera que uma parte do modelo da empresa, o modelo do ambiente atual (as-is), representa parte do conhecimento de domnio. Baseada nessa hiptese, a hiptese H4 considera que o modelo da empresa as-is possui alternativas de refinamento adequadas, uma vez que no h uma reengenharia completa da empresa. Por fim, a hiptese H3 a hiptese central deste trabalho, considerando que possvel transformar requisitos presentes em um modelo da empresa em especificaes.

Dessas hipteses, apenas a hiptese H3 ser analisada atravs de um experimento (apresentado no captulo 7), cabendo a trabalhos futuros analisar as demais hipteses.

1.6 Mtodo

Para atingir os objetivos propostos aplicou-se um mtodo hipottico-dedutivo, descrito na Figura 1.1, usando BPMN (OMG, 2011a). O projeto se iniciou com uma pesquisa bibliogrfica exploratria, considerando uma proposta bsica de obteno de requisitos atravs de informaes do ambiente. Devido abrangncia dessa proposta bsica, a pesquisa bibliogrfica enfatizou o uso de processos de negcio como origem dos requisitos. Em seguida o problema foi definido, o que levou a pesquisas bibliogrficas mais especficas: a representao da empresa, a

7

representao (e definio) de requistos e o estudo da rea de Engenharia Dirigida por Modelos. Essas pesquisas levaram definio do objetivo deste trabalho.

Figura 1.1: Mtodo empregado para a realizao da tese.

A partir do objetivo, foram definidos os metamodelos que servem de base para a transformao, criando uma verso inicial de uma ferramenta para executar a transformao proposta e realizando um teste da transformao. Em paralelo, foram analisados os trabalhos relacionados e as implicaes da proposta. Aps essas atividades, foram definidas as regras de transformao o que envolveu a definio de um mtodo. A verso inicial da ferramenta foi ento atualizada, absorvendo as regras de transformao e implementando outros detalhes necessrios. Por fim, realizou-se um experimento para avaliar a principal hiptese deste trabalho, a hiptese H3.

Pesquisa inicial

Definio do problema

Pesquisa sobre a representao da

empresa

Pesquisa sobre a representao de

requisitos

Pesquisa sobreEngenharia Dirigida

por Modelos

Anlise dos trabalhos

relacionadosDefinio dos metamodelos

Definio do objetivo

Criao de uma verso inicial da

ferramenta

Concluso da ferramenta

Definio das regras de

transformao

Realizao de um teste inicial

Execuo do experimento

8

1.7 Organizao do trabalho

Para atingir o objetivo definido, este trabalho est organizado da seguinte forma: Captulo 2 Representao de uma empresa: define o que empresa para

este trabalho e alguns conceitos relacionados, discutindo duas reas que propem a criao de modelos de empresa abrangentes.

Captulo 3 Requisito, especificao e suas representaes: apresenta as definies de requisitos e de especificaes usando um modelo como quadro de referncia e contextualizando essas definies na rea de Engenharia de Requisitos e em relao s abordagens de Engenharia de Requisitos orientadas por metas. Tambm discute formas de representao de requisitos, enfatizando o caso de uso.

Captulo 4 Engenharia dirigida por modelos (MDE): apresenta as linhas gerais do paradigma da Engenharia Dirigida por Modelos, tratando do conceito de modelo, metamodelo, metametamodelo, Espao Tcnico e de uma operao especfica, a transformao.

Captulo 5 Modelo da empresa e a transformao de requisitos em especificaes: discute a possibilidade de usar o modelo da empresa como modelo dos requisitos e apresenta a proposta deste trabalho, de transformar requisitos em especificaes usando conceitos de MDE. Tambm apresenta os trabalhos relacionados.

Captulo 6 Transformao do modelo da empresa em modelo de caso de uso: apresenta os detalhes da transformao proposta, analisando e definindo o Espao Tcnico a ser usado, os metamodelos empregados, as regras de transformao criadas e a ferramenta implementada.

Captulo 7 Experimento: apresenta o experimento realizado para analisar a hiptese central deste trabalho.

Captulo 8 Concluso: apresenta a concluso deste trabalho, discutindo as contribuies e trabalhos futuros, alm de apresentar os trabalhos publicados.

9

2 REPRESENTAO DE UMA EMPRESA

A empresa uma organizao, ou seja, um sistema social que organizado para alcanar um tipo particular de meta (PARSONS, 1960, p.56). Seguindo a definio de organizao, alguns trabalhos afirmam que uma das principais metas a serem alcanadas por uma empresa o lucro, como o caso de (CHIAVENATO, 2000), (MAXIMIANO, 2007) e (VERNADAT, 1996). Essa caracterstica evidenciada na definio de empresa apresentada por esses trabalhos, como o caso de Vernadat (1996, p.22) que define empresa como "uma organizao socioeconmica criada para produzir produtos ou oferecer servios e para obter lucro". Dessa maneira, de acordo com Maximiano (2007) existem dois outros tipos principais de organizao alm da empresa: o governo e organizaes do terceiro setor.

Para outros trabalhos a empresa algo mais geral, englobando alguns tipos de organizaes governamentais e do terceiro setor. Ao invs do lucro, esses trabalhos evidenciam a existncia de atividade econmica ao definir empresa. Por exemplo, Kwasnicka (2004) divide empresa em privada, pblica ou mista, sendo que nem mesmo a empresa privada necessariamente almeja o lucro (como, por exemplo, no caso de uma cooperativa). De forma similar, Daft (2005) apresenta trs tipos de empresa seguindo um ponto de vista jurdico: a empresa individual, a sociedade e a sociedade annima. Desses trs tipos, a sociedade no necessariamente almeja o lucro. Essa mesma nfase atividade econmica seguida pela definio de empresa presente no cdigo de direito civil brasileiro. Nele, a empresa pode ser vista como uma sociedade empresria, a qual "tem por objeto o exerccio de atividade prpria de empresrio sujeito a registro" (BRASIL, 2002, art.982). Nesse contexto, o empresrio "quem exerce profissionalmente atividade econmica organizada para a produo ou a circulao de bens ou de servios" (BRASIL, 2002, art.966). Ou seja, no necessariamente a empresa almeja o lucro.

Este trabalho segue essa viso mais abrangente de empresa, definindo empresa como (BRASIL, 2002):

Uma organizao que realiza atividade econmica para a produo ou a circulao de bens ou de servios.

10

Uma empresa pode ser representada atravs de diversos modelos1, como o modelo dos processos de negcio executados, da planta baixa de suas unidades, da hierarquia de cargos existentes, do balano patrimonial, entre outras possibilidades. Cada um desses modelos representa a empresa de uma forma diferente, sendo til dependendo das necessidades e dos objetivos de quem o usa. Por exemplo, para entender a relao entre os cargos da empresa, um organograma mais til que um balano patrimonial.

Para tratar do projeto ou do reprojeto do funcionamento da empresa, um modelo importante o que trata dos processos empresariais. De acordo com Davenport (1994), os processos permitem observar uma empresa horizontalmente, ao considerar as atividades realizadas pelas diversas unidades funcionais envolvidas em um determinado trabalho; em contraposio, uma viso vertical considera uma nica unidade funcional da empresa, no permitindo observar o trabalho como um todo. Segundo Cury (2007), essa viso horizontal permite observar o cliente, o produto e o fluxo de trabalho de uma forma mais clara, alm de permitir o entendimento de como o trabalho realmente feito na empresa e evidenciar os relacionamentos existentes entre as diversas partes da empresa.

De uma forma geral, o processo empresarial definido como um conjunto ordenado de atividades que transformam entradas em sadas (CHASE; JACOBS; AQUILANO, 2006) (CRUZ, 2005) (DAVENPORT, 1994) (HAMMER; CHAMPY, 1994) (HARRINGTON, 1993) (VERNADAT, 1996). Em algumas definies so evidenciados outros conceitos importantes para o processo, como o valor que a sada gerada deve prover para a organizao (CHASE; JACOBS; AQUILANO, 2006) (CRUZ, 2005) (HAMMER; CHAMPY, 1994) (HARRINGTON, 1993), o objetivo que o processo deve possuir (VERNADAT, 1996), a existncia de um cliente (CRUZ, 2005) (HAMMER; CHAMPY, 1994) e o fato de um processo cruzar as fronteiras funcionais (LLEWELLYN; ARMISTEAD, 2000), entre outros. Alguns desses conceitos importantes para o processo so considerados por trabalhos, como, por exemplo, (CRUZ, 2005) e (DAVENPORT, 1994), para definir os elementos de um processo, sendo usado para criar uma representao dele. Dada a importncia do processo, alm desses trabalhos tambm existem alguns padres, como, por exemplo, o ISO

1 A definio de modelo apresentada na seo 4.1.

11

5807 (ISO, 1985), o IDEF3 (MAYER et al., 1995) e o BPDM (Business Process Definition Metamodel) (OMG, 2008b) que definem formas de represent-lo.

Apesar da importncia dos processos para projetos e reprojetos do funcionamento da empresa (incluindo melhoria e a reengenharia de processos2), alguns trabalhos consideram modelos que incluem outras informaes alm do processo. Alguns desses modelos so constitudos de diversos submodelos que proveem diferentes vises e que so de alguma forma integrados (VERNADAT, 1996) (WHITMAN; RAMACHANDRAN; KETKAR, 2001). Por exemplo, de acordo com Hammer e Champy (1994) a empresa pode ser representada atravs de seus processos de negcio, seus cargos e estruturas, seus sistemas de gesto e avaliao e seus valores e crenas. Essas quatro vises esto inter-relacionadas: o processo determina os cargos e as estruturas necessrias para a empresa; a partir dessas estruturas definem-se como os funcionrios sero recrutados, avaliados e remunerados, definindo os sistemas de gesto e avaliao; esses sistemas de gesto e avaliao so a principal fonte para a definio de valores e crenas da empresa; e finalmente, o tipo de cultura organizacional influenciar os processos que precisam existir.

Alguns desses modelos mais abrangentes da empresa que tratam de seu funcionamento so criados para outros fins, alm do projeto e do reprojeto da empresa, como, por exemplo, para (KOUBARAKIS; PLEXOUSAKIS, 1999) (VERNADAT, 1996) (WHITMAN; HUFF, 2001) (WHITMAN; RAMACHANDRAN; KETKAR, 2001):

Analisar a empresa; Construir um sistema ou um equipamento caro; Melhorar o gerenciamento da empresa; Permitir a integrao da empresa; Ganhar aprovao das partes envolvidas; Comunicar o entendimento comum da empresa; e Ser uma ferramenta de documentao para outros esforos.

2 Segundo Davenport (1994), a melhoria de processo busca melhorar a eficincia e eficcia de um

processo j existente, enquanto que a reengenharia uma mudana radical da forma como o trabalho realizado, definindo os processos sem base-los nos existentes.

12

Um desses usos para auxiliar a construo de sistemas computacionais, existindo abordagens que usam representaes da empresa para auxiliar a definio dos requisitos de um sistema computacional3.

A seguir so discutidas abordagens de duas reas que tratam da representao de modelos empresariais mais abrangentes, mas com objetivos distintos: a rea de Arquitetura Empresarial e a de Organizao e Mtodos.

2.1 Arquitetura empresarial

Segundo um levantamento realizado por Schenherr (2009), o termo arquitetura empresarial comeou a ser utilizado com mais frequncia em publicaes acadmicas a partir de 2003 e, pouco depois, por empresas que o relacionam a produtos e a estratgias. Como se pode esperar de um conceito recente, ainda no existe uma terminologia comum sobre o assunto at mesmo para definir o que significa arquitetura empresarial (SCHENHERR, 2009).

Algumas definies de arquitetura empresarial, como as apresentadas por (LEIST; ZELLNER, 2006), (ROOD, 1994), (SHAH; KOURDI, 2007) e (WHITMAN; RAMACHANDRAN; KETKAR, 2001), seguem o conceito de arquitetura, empregando-o no contexto da empresa. Seguindo o padro ISO/IEC 42010 (ISO, 2007, p.3) que trata de sistemas intensivos de software, a arquitetura " a organizao fundamental de um sistema abrangendo seus componentes, suas relaes entre si e com o ambiente e os princpios que guiam seu projeto e a sua evoluo". Dessa maneira, a arquitetura empresarial permite representar os elementos essenciais da empresa, sendo, portanto, um modelo especfico dela. Por exemplo, Rood (1994, p.106) define arquitetura empresarial como "um arcabouo conceitual que descreve como uma empresa est construda ao definir os componentes primrios e as relaes entre esses componentes".

Mas, em geral, as definies de arquitetura empresarial possuem uma nfase na Tecnologia da Informao (TI), seja ao apresentar uma definio orientada a

3 Na seo 5.1 so discutidos mais detalhes sobre o uso de modelos da empresa nas atividades de

Engenharia de Requisitos.

13

tecnologia ou ao considerar uma viso da arquitetura especfica que trata da TI (SCHENHERR, 2009). Segundo Laudon e Laudon (2007, p.9) Tecnologia da Informao "todo software e todo hardware de que uma empresa necessita para atingir seus objetivos organizacionais". A importncia da TI para a arquitetura empresarial fica evidente em alguns trabalhos como o de Lankhorst (2009) que afirma que a arquitetura empresarial captura tanto a essncia do negcio quanto a essncia da TI. Para esse autor, arquitetura empresarial "um conjunto coerente de princpios, mtodos e modelos que so usados no projeto e na realizao da estrutura organizacional, do processo de negcio, dos sistemas de informao e da infraestrutura da empresa" (LANKHORST, 2009, p.3). Mesmo nos trabalhos que definem arquitetura empresarial apenas seguindo o conceito de arquitetura, existe uma relao prxima entre arquitetura empresarial e a TI. Em alguns casos, essa relao discreta, como, por exemplo, em (ROOD, 1994) que somente enfatiza a importncia da viso de TI ao apresentar os componentes de uma arquitetura empresarial. Em outros, a TI um elemento central, como, por exemplo, para Shah e Kourdi (2007) que afirmam que a arquitetura empresarial a lgica que organiza os processos de negcio e a infraestrutura de TI.

Em alguns trabalhos a importncia da arquitetura empresarial para a TI tanta que a definio de arquitetura empresarial voltada para a rea de sistemas de informao. Por exemplo, Armour, Kaisler e Liu (1999, p.35) definem arquitetura empresarial como "uma planta para criar sistemas de informao que tratam de toda a empresa". Mesmo no considerando apenas a TI, Lindstrm et al. (2006) afirmam que a arquitetura empresarial tem como a principal parte envolvida o CIO (Chief of Information Officer) da empresa executivo responsvel pela rea de tecnologia de informao e, por outro lado, o CIO tem como principal ferramenta a arquitetura empresarial.

Considerando a relao entre a arquitetura empresarial e a rea de TI, diversas das motivaes para se construir uma arquitetura empresarial tratam de seu uso para a TI, mas tambm existem motivaes para a empresa de uma forma geral (ARMOUR; KAISLER; LIU, 1999) (LANKHORST, 2009) (ROOD, 1994) (SHAH; KOURDI, 2007):

Auxilia o alinhamento entre o negcio e a TI;

14

Facilita a comunicao sobre investimentos de TI; Permite uma viso integrada sobre os recursos de informao; Permite descrever novos sistemas de informao ou estratgias para

modernizar sistemas existentes; Facilita a identificao e desenvolvimento de padres de informao e de

sistemas de informao; Identifica e remove redundncias tecnolgicas e nos processos de negcio; Permite a reviso e a reengenharia de processos; Permite traduzir metas da empresa em operaes; Captura o conhecimento de empregados e de consultores; Auxilia a tomada de deciso e o planejamento empresarial; Permite uma comunicao efetiva sobre a empresa; e necessria ou til para atender leis e regulamentaes (como os atos

Clinger-Cohen ou Sarbanes-Oxley).

Para construir uma arquitetura empresarial em geral seguido um arcabouo de arquitetura empresarial. Esses arcabouos facilitam a criao de uma arquitetura empresarial, segundo Armour, Kaisler e Liu (1999, p.37), ao prover "um conjunto de modelos, princpios, servios, abordagens, padres, conceitos de projeto, componentes e configuraes". Alguns desses arcabouos so especficos para determinados domnios de aplicao, como o caso do Computer-Integrated Manufacturing Open Systems Architecture CIMOSA (VERNADAT, 1996), que voltado para a manufatura, ou mesmo para determinadas organizaes, como o DoD Architecture Framework DoDAF (DOD, 2010), usado pelo departamento de Defesa dos Estados Unidos da Amrica, e o Federal Enterprise Framework FEA (THE EXECUTIVE OFFICE OF THE PRESIDENT OF THE UNITED STATES, 2007), usado pelo Governo Federal dos Estados Unidos da Amrica. Outros so independentes do domnio de aplicao e de organizao, como o caso do The Open Group Architecture Framework (TOGAF) (THE OPEN GROUP, 2009) e o arcabouo de Zachman (SOWA; ZACHMAN, 1992) (ZACHMAN, 1987).

15

2.2 Organizao e Mtodos

Na rea de conhecimento da administrao, a rea de Organizao e Mtodos4 (O&M) a tradicionalmente responsvel pela institucionalizao da infraestrutura necessria para a empresa atingir seus objetivos e pela definio e redefinio dos processos e dos mtodos de trabalho (CURY, 2007). Para realizar essas atribuies fundamental a existncia de um modelo da empresa, seja como um meio para realizar as atividades de melhoria dos processos e dos mtodos administrativos, ou como o resultado a ser obtido ao se criar um manual administrativo. Diferentemente dos arcabouos empresariais, o modelo da empresa empregado no contexto da O&M no considera os sistemas computacionais como um elemento central, tendo uma viso mais geral da empresa.

No contexto da melhoria dos processos e dos mtodos administrativos, o modelo da empresa criado durante o levantamento da situao atual da empresa, que serve como base para as demais atividades de melhoria. Em cada trabalho de O&M apresentado um mtodo diferente para realizar a melhoria, propondo diferentes maneiras para levantar a situao atual e, consequentemente, obter diferentes modelos de empresa. Por exemplo, Oliveira (1994) sugere o seguinte mtodo:

1. Seleo e reconhecimento do que ser analisado; 2. Estudo da viabilidade e alternativas; 3. Levantamento e anlise da situao atual; 4. Delineamento e estruturao do novo sistema; 5. Detalhamento do novo sistema; 6. Treinamento, teste e implantao; e 7. Acompanhamento, avaliao e atualizao.

De uma forma geral, o levantamento da situao atual da empresa envolve a anlise da documentao existente na empresa, a aplicao de questionrios, a realizao de entrevistas e a observao do trabalho executado (CURY, 2007), (LERNER, 1992) (OLIVEIRA, 1994). Um exemplo de resultado obtido por esse levantamento, segundo Oliveira (1994), so as polticas e diretrizes existentes, os organogramas

4 Tambm chamada de Organizao, Sistemas e Mtodos (OSM).

16

da empresa, os fluxogramas detalhados e os documentos e formulrios existentes que, assim, constituem um modelo da empresa5.

Normalmente o mesmo mtodo usado para realizar o levantamento da situao atual da empresa tambm usado pela atividade de criao de um manual administrativo. Esse manual contm as normas definidas pela empresa e que formalizam o seu funcionamento (ANDERSON, 1980) (CURY, 2007) (LERNER, 1992) (OLIVEIRA, 1994), podendo ser visto como um modelo da empresa. Dada a quantidade de informaes que ele prov, o manual pode ser organizado de diferentes formas dependendo do contexto e dos objetivos da empresa. Segundo Popper (1972), os principais manuais criados pelas empresas so:

Manual de instrues, que define as normas e polticas administrativas e os processos executados;

Manual de organizao, que define a estrutura organizacional e as responsabilidades dos funcionrios;

Manual de formulrios, que define a finalidade, o preenchimento, a distribuio e o uso dos formulrios;

Manual do funcionrio, que define os direitos e obrigaes dos funcionrios; e Manual didtico, que define as obrigaes e as tcnicas empregadas por um

determinado cargo. A criao desses manuais possui algumas vantagens para a empresa, como, por exemplo, facilitar o treinamento de novos funcionrios, ajudar os funcionrios a desempenhar suas funes (principalmente aps a sua implantao), promover uma uniformidade de entendimento do trabalho, ser usado como base para reviso dos procedimentos existentes e auxiliar os profissionais de O&M a levantar informaes em outras oportunidades (ANDERSON, 1980). Entretanto, para que esses manuais sejam teis, eles precisam ser atualizados com frequncia, representando o conhecimento atual da empresa, e criados por uma equipe com conhecimento do assunto, o que exige naturalmente tempo e dinheiro seja para cri-lo ou para mant-lo (ANDERSON, 1980).

5 Uma anlise mais detalhada do contedo dos modelos de empresa seguindo as abordagens de

O&M apresentada na seo 6.2.1.

17

Apesar das atribuies da O&M para a empresa, segundo um estudo realizado por Caldas (1999a) (1999b), essa rea est sendo extinta nas empresas e a oferta de empregos para atividades atribudas a ela est diminuindo. Os motivos para esse declnio da O&M, segundo o autor, so (CALDAS, 1999a):

A mudana nos modelos de gesto empresariais que no foram adequadamente absorvidas pela rea de O&M e por seus profissionais;

O desenvolvimento da tecnologia de informao que absorveu parte das atribuies da O&M e deu acesso direto s informaes e ferramentas que dependiam da Organizao e Mtodos para serem acessadas;

O aumento do ritmo de mudanas na empresa (causadas pelo aumento de competitividade do mercado) que no conseguiu ser controlado pelas reas de O&M; e

A autodeteriorao da Organizao e Mtodos devido centralizao de suas atribuies, ao seu embasamento em modelos de gesto incompatveis com o novo ambiente de negcio e falha em se adaptar s mudanas.

Com isso, essas atividades foram absorvidas pelas reas de computao, recursos humanos e qualidade dentro da empresa e por consultores externos a ela (Caldas, 1999b).

2.3 Concluso

Uma empresa pode ser representada atravs de diferentes modelos que cobrem as informaes relevantes sobre a empresa seguindo uma viso especfica. Um desses modelos, a arquitetura empresarial, trata tanto de aspectos do negcio quanto de aspectos de Tecnologia de Informao. Na rea de Organizao e Mtodos definido um modelo da empresa com enfoque organizacional, que no considera detalhes sobre os sistemas de informao existentes.

Este trabalho usa um modelo da empresa como modelo dos requisitos. Com isso, no captulo seguinte ser discutido o que requisito, alm de apresentar o quadro de referncia de requisitos que usado.

18

3 REQUISITO, ESPECIFICAO E SUAS REPRESENTAES

Uma empresa pode ser vista como um sistema (CHIAVENATO, 2000), ou seja, uma "combinao de elementos que interagem organizados para atingir um ou mais propsitos declarados" (ISO, 2008). Os propsitos declarados so aqueles estabelecidos por sua misso; os elementos so seus funcionrios, suas instalaes, suas mquinas, seus processos etc.

Ao planejar a substituio de qualquer um dos elementos da empresa preciso entender o que ser necessrio para o novo elemento e tambm analisar o impacto que essa mudana causa no sistema como um todo principalmente ao considerar a misso definida. Quando a substituio envolve a automao de processos empresariais atravs de sistemas computacionais, essas atividades de planejamento so comumente realizadas no contexto da disciplina de Engenharia de Requisitos. O principal resultado das atividades dessa disciplina, e que precisa ser continuamente gerenciado, um conjunto de requisitos que buscam expressar o que necessrio para o sistema computacional a ser construdo6.

3.1 Definies

Existem diversos termos que buscam representar as mltiplas vises do que um requisito e tambm diferenciar outras informaes relevantes para a disciplina de Engenharia de Requisitos. Com isso, definem-se termos como especificao, funcionalidade, funo, necessidade, conhecimento do domnio, entre outros, alm de requisito. Conforme a necessidade alguns desses termos sero definidos no decorrer deste trabalho, entretanto dois deles sero mais bem detalhados, uma vez que os conceitos que eles representam so fundamentais para o objetivo do trabalho: requisito e especificao.

Dentre os diversos significados de requisito e de especificao, este trabalho diferenciar esses dois termos seguindo as ideias apresentadas por Jackson e Zave

6 Como o foco principal deste trabalho so sistemas computacionais, ser usado o termo sistema

significando sistema computacional, enquanto que o termo sistemas em geral ser usado para se referir a sistema do ponto de vista da (ISO, 2008).

19

(JACKSON, 1995) (JACKSON, 1997) (JACKSON, ZAVE; 1995) (ZAVE; JACKSON, 1997), seguindo como quadro de referncia o modelo WRSPM (chamado assim pelo nome dos artefatos definidos: World, Requirement, Specification, Platform e Machine)7 (GUNTER et al., 2000), apresentado na Figura 3.1. Esse modelo tem como objetivo definir uma base comum para discutir os atributos e as relaes entre cinco artefatos e para isso os agrupa considerando a sua relevncia ao ambiente, a parte do mundo em que o sistema ir interagir e na qual os efeitos do sistema sero observados e avaliados (JACKSON, 1997), ou ao sistema. Esses artefatos so:

O conhecimento do domnio que possui informaes conhecidas e assumidas sobre o ambiente;

Os requisitos que indicam o que os clientes desejam do sistema, descrito na forma de efeitos no ambiente;

A especificao que permite que o sistema seja construdo satisfazendo os requisitos;

O programa que implementa a especificao; e A plataforma que permite programar o sistema.

Figura 3.1: O modelo WRSPM, evidenciando os cinco artefatos por ele definidos (GUNTER et al., 2000).

Cada um desses artefatos pode ser visto como uma descrio que usa um vocabulrio especfico de diferentes termos primitivos. Entretanto, alguns desses termos so compartilhados entre os artefatos, uma vez que os fenmenos que eles buscam denotar tambm o so. Esses fenmenos representados como pontos na figura representam estados, eventos e indivduos e so organizados em 4 classes pelo modelo: os que pertencem ao ambiente e so visveis ou invisveis ao sistema

7 O modelo WRSPM apresenta algumas diferenas em relao aos demais trabalhos de Jackson e

Zave, apesar de seguirem a mesma viso a respeito de requisito e de especificao. Duas dessas diferenas so importantes para este trabalho: o fato do WRSPM tratar de artefatos ao invs de afirmaes e o emprego de uma terminologia mais elaborada (j que ele pretende ser um modelo de referncia). Como neste trabalho se pretende tratar de afirmaes e ainda assim empregar a terminologia do WRSPM, o modelo aqui adaptado.

Ambiente Sistema

Requisito Programa PlataformaConhecimentodo domnio

Especificao

20

e, da mesma forma, os que pertencem ao sistema e so visveis ou invisveis ao ambiente. Seguindo essa diviso, apenas os fenmenos visveis so compartilhados entre o ambiente e o sistema. Por exemplo, em um sistema computacional de controle de venda de uma livraria, o fenmeno do ambiente invisvel ao sistema a chegada de novos livros na livraria; um fenmeno do ambiente visvel a digitao da nova quantidade de um determinado livro; um fenmeno do sistema visvel ao ambiente a alterao da quantidade disponvel de livros; e por fim, um fenmeno do sistema invisvel a mudana do valor de um registro no banco de dados referente quantidade de livros.

Dadas essas classes de fenmenos, o artefato "conhecimento do domnio" restringe os fenmenos que pertencem ao ambiente, o que permite definir o ambiente em si. Alm disso, ele tambm pode restringir a relao entre fenmenos que pertencem ao ambiente e aqueles que pertencem ao sistema e so visveis ao ambiente (GUNTER et al., 2000), como, no caso de um sistema de controle de venda de uma livraria, a restrio de que ao vender o livro, a quantidade de livros disponveis diminui. O artefato "requisito" adiciona outras restries quelas definidas pelo artefato "conhecimento do domnio" ao considerar o que os clientes desejam ou seja, os requisitos so decididos pelo cliente (JACKSON; ZAVE, 1995). Usando novamente o sistema de controle de vendas de uma livraria como exemplo, uma restrio de o cliente comprar no mximo 10 livros por vez faria parte do artefato "requisito". No outro extremo, o artefato "plataforma" restringe os fenmenos que podem ser realizados pelo sistema enquanto que o artefato "programa" descreve uma classe de possveis fenmenos do sistema considerando o programa em si. Entre o ambiente e o sistema existe o artefato "especificao" que usa o vocabulrio comum entre os dois para definir o que o sistema deve realizar considerando o ambiente. A partir dessas ideias o modelo WRSPM define um conjunto de propriedades, relacionando formalmente esses artefatos.

Em vez de tratar especificamente dos artefatos "conhecimento do domnio", "requisito" e "especificao" propostos pelo modelo WRSPM, este trabalho aborda o contedo deles. Cada artefato considerado aqui como composto de um conjunto de afirmaes, chamadas de conhecimentos do domnio para o artefato "conhecimento do domnio", requisitos para o artefato "requisito" e especificaes para o artefato "especificao". Considerando a importncia do artefato

21

"especificao" e buscando evitar ambiguidades, ele ser daqui em diante chamado de "especificao de requisitos". Dessa maneira, os requisitos so restries sobre os fenmenos do ambiente, enquanto que as especificaes so um tipo especfico de requisitos, considerando apenas os fenmenos compartilhados entre o ambiente e o sistema (JACKSON, 1995). Com isso os requisitos so definidos como afirmaes que descrevem "o ambiente como gostaramos que ele fosse e como esperamos que ele seja quando mquina estiver conectada com o ambiente" (ZAVE; JACKSON, 1997, p.7), o que so as afirmaes no modo optativo 8 . Uma consequncia dessa definio que os requisitos devem tratar apenas do ambiente e nada mais que isso (ZAVE; JACKSON, 1997) , o que fica claro no modelo WRSPM. Essa afirmao segue a ideia de que os requisitos e a especificao no devem tratar de uma soluo computacional especfica, mas do propsito do sistema ao considerar o domnio de aplicao e o uso pretendido (JACKSON, 1995). A especificao deve permitir que a equipe de desenvolvimento escolha a forma mais adequada para implementar o sistema, sem restringi-lo desnecessariamente (GILB, 1997) (IEEE, 1998) (LEFFINGWELL; WIDRIG, 2003) (WIEGERS, 2003) (ZAVE; JACKSON, 1997).

Por mais que os requisitos e as especificaes devam seguir a ideia de tratar apenas do propsito do sistema, nem sempre possvel fazer com que eles se limitem ao ambiente. Segundo Kotonya e Sommerville (1998) algumas vezes necessrio que os requisitos tratem de como o sistema ser implementado por trs motivos principais: (1) porque as declaraes do problema podem ser abstratas demais para que os leitores dos requisitos as entendam, (2) porque o sistema precisa ser compatvel com outros sistemas em geral existentes, estar em conformidade com outros sistemas em geral e considerar algumas preocupaes organizacionais e (3) porque como geralmente os especificadores so especialistas do domnio de aplicao, os requisitos podem ser definidos como descries de como realizar a computao usando dados do domnio de aplicao. Um exemplo disso a existncia de uma poltica na empresa que obriga a usar uma determinada linguagem de programao em todos os seus softwares como era o caso do

8 Alm das afirmaes sobre o ambiente no modo optativo, Zave e Jackson tambm definem as

afirmaes no modo indicativo que descrevem o ambiente como ele na ausncia da mquina e sem considerar as aes da mquina (1997, p.7). Esse tipo de afirmao representaria os fatos assumidos, ou conhecimento do domnio.

22

departamento de defesa dos Estados Unidos da Amrica que obrigava o uso da linguagem Ada at o fim da dcada de 1990 (LEFFINGWELL; WIDRIG, 2003). De alguma forma essa poltica deve ser considerada como um requisito, j que o sistema a ser construdo precisa obrigatoriamente atend-la. Devido sua diferena de natureza, alguns autores chegam a classificar esse tipo de restrio como um outro tipo de requisito: restries de projeto (LEFFINGWELL; WIDRIG, 2003) ou restries de soluo (ROBERTSON; ROBERTSON, 2006). Independente de como essas restries so chamadas, o relevante para este trabalho que os requisitos tratam do ambiente e do sistema, mesmo que o foco deva ser no ambiente. Por causa disso, a definio de requisitos usada neste trabalho tambm considera essas restries, ainda que seguindo a filosofia do modelo WRSPM. Com isso requisito definido seguindo a definio proposta pela IEEE (1990, p.172)9:

a) Uma condio ou capacidade necessria por um usurio para resolver um problema ou atingir um objetivo.

b) Uma condio ou capacidade que deve ser cumprida ou possuda por um sistema ou componente do sistema para satisfazer um contrato, padro, especificao, ou outros documentos formalmente impostos.

Por mais que essa definio trate das origens e das fontes dos requisitos e no do ambiente em si, h uma relao direta dessa definio com a viso de requisito seguida pelo modelo WRSPM. Na clusula (a) as condies ou capacidades representam afirmaes sobre o ambiente sob a perspectiva dos usurios, considerando seus objetivos e as formas para resolver seus problemas. Ainda que o termo usurio denote a presena de um sistema, o seu uso pode ser interpretado como apenas uma forma de delimitar o ambiente considerado, sem fazer afirmaes especficas sobre o sistema em si. Em compensao, na clusula (b) da definio, o sistema em si explicitado: so condies ou capacidades do sistema ou de seus componentes. Mesmo que isso ainda possa ser usado para definir o ambiente pretendido, tambm possvel descrever aspectos especficos da soluo

9 Na definio da IEEE (1990) existe ainda uma outra interpretao de requisito que no foi

considerada: uma representao documentada de uma condio ou capacidade como em (a) ou (b) (IEEE, 1990, p.172). O problema dessa interpretao que ela confunde o conceito de requisito com a representao dele. Para evitar essa ambiguidade, neste trabalho ser empregado o termo representao de requisitos para designar o termo requisito segundo essa interpretao presente na norma.

23

computacional, permitindo tratar das restries que tambm devem ser consideradas como requisitos.

Considerando a definio de requisito, preferiu-se adotar uma definio de especificao mais ampla, que no referencia diretamente a fronteira entre o ambiente e a mquina uma vez que os requisitos tambm podem representar condies ou capacidades internas ao sistema. Dessa forma, a especificao definida aqui como (JACKSON; ZAVE, 1995):

Um tipo de requisito refinado ao remover todas as caractersticas que impedem que ele seja implementado.

A especificao , portanto, um requisito que no necessita de nenhuma informao adicional para que a equipe de desenvolvimento o utilize para as prximas atividades do processo adotado (como, por exemplo, as atividades de anlise, projeto, implementao etc.). Ela descreve caractersticas do sistema desejado no ambiente (JACKSON; ZAVE, 1995), tratando de fenmenos compartilhados entre o ambiente e o sistema, alm de considerando a definio de requisitos adotada detalhes internos do sistema.

Os requisitos que tratam de detalhes internos do sistema so, por essa definio, especificaes. Mas alm deles, alguns outros requisitos podem j estar em um nvel de detalhamento suficiente para que eles sejam vistos como especificaes. Outros requisitos, entretanto, precisam ser detalhados em especificaes, o que feito em um processo chamado de refinamento (JACKSON; ZAVE, 1995) (JIN, 2006) (ZAVE; JACKSON, 1997). Esse processo consiste em dois passos: "(1) identificar os aspectos de um requisito que no podem ser garantidos ou efetuados por um computador sozinho e (2) detalh-los ou troc-los at que sejam completamente implementveis" (ZAVE; JACKSON, 1997, p.19). Em relao ao primeiro passo, segundo Zave e Jackson (1997) existe trs razes principais para no considerar um requisito como especificao:

Eles restringem fenmenos controlados pelo ambiente, ao invs de restringir fenmenos controlados pelo sistema;

Eles so descritos em termos de fenmenos no compartilhados (no visveis ao sistema); e

Eles so descritos em termos do futuro.

24

Para esses trs casos, a soluo para obter especificaes envolve o emprego do conhecimento do domnio, de diferentes formas. O emprego desse conhecimento permite delimitar melhor o espao do problema, definindo a fronteira entre o ambiente e o sistema. Entretanto, de uma forma geral no se tem uma nica opo de refinamento possvel, mas diversas alternativas. Cada alternativa pode causar um impacto diferente no sistema pretendido, influenciando de diferentes formas os resultados desejados (de negcio ou tcnicos) (MYLOPOLOUS et al., 2001) ou mesmo afetando o projeto em si (o tempo, o custo ou a equipe necessria). Por mais que cada alternativa possa restringir de forma diferente o espao de soluo, elas representam opes diferentes de o que o sistema deve fazer. Dessa forma, as alternativas devem ser discutidas com as partes envolvidas, avaliadas frente aos resultados desejados estabelecidos e negociados com os tomadores de deciso (VAN LAMSWEERDE, 2009). Segundo Mylopoulos et al. (2001), uma maneira de capturar e avaliar alternativas nos requisitos empregar tcnicas de anlise orientadas por metas (discutidas na seo 3.3).

Um exemplo de alternativas de detalhamento pode ser visto em (MAIDEN, 2008), durante a discusso sobre a diferena entre requisitos e especificaes. Um requisito descrito textualmente seria: "um usurio de um sistema de aprendizado baseado em trabalho deve ser capaz de localizar uma pessoa que responsvel por um documento" (MAIDEN, 2008, p.90). Por mais que esse requisito seja o que as partes envolvidas esperam do sistema, para a implementao essa afirmao ainda vaga. O sistema pode localizar a pessoa de diversas formas, por exemplo, ao informar um telefone, uma sala, ou at mesmo atravs de um mapa que apresenta a localizao de onde a pessoa est naquele momento. Ainda que essas trs opes sejam vlidas considerando esse requisito, o mapa poderia afetar negativamente a privacidade das pessoas (que pode ser um outro requisito), ou a sala poderia ser vista como uma soluo imprecisa demais. Com isso, o requisito poderia ser detalhado para algo como "o sistema de aprendizado baseado em trabalho deve retornar o nome e os dados de contato da pessoa responsvel por um determinado documento" (MAIDEN, 2008, p.90). interessante notar que mesmo esse detalhamento pode ser ainda vago, j que o termo dados de contato pode ser ainda impreciso. Caso no haja um conhecimento do domnio que defina o que isso exatamente significa para esse contexto, a afirmao ainda um requisito e no

25

uma especificao. Ou seja, possvel ter diferentes nveis de detalhamento de um requisito, sendo que a especificao o nvel de detalhamento em que no existem mais alternativas, permitindo seu uso pelas prximas atividades de desenvolvimento.

Por fim, considerando que especificao tambm um requisito, neste trabalho usado o termo requisito para representar o termo geral, englobando tambm a especificao. Para representar os requisitos sem considerar as especificaes, ser empregado o termo requisitos no refinados. Alguns autores chamam os conceitos aqui referidos como requisito no refinado e especificao por outros nomes como, por exemplo, requisitos do usurio e requisitos de sistema (ou de software) (GOTTESDIENER, 2008) (MAIDEN, 2008) (WIEGERS, 2003), metas e requisitos (VAN LAMSWEERDE, 2009), requisitos de alto-nvel e requisitos de negcio e tecnolgicos (ROBERTSON; ROBERTSON, 2006). Alm disso, em alguns trabalhos o termo especificao se refere documentao dos requisitos (IEEE, 1990) (LEFFINGWELL; WIDRIG, 2003) (VAN LAMSWEERDE, 2009), muitas vezes possuindo um ponto de vista mais formal (seja de linguagens formais ou de acordo com as partes envolvidas).

3.2 Engenharia de Requisitos

Os requisitos e as especificaes so tratados, em geral, por atividades que fazem parte da disciplina de Engenharia de Requisitos. Em especial no contexto dessa disciplina que os requisitos so elicitados e posteriormente refinados em especificaes. Dentre as diversas definies de Engenharia de Requisitos e de quais so suas responsabilidades, comum evidenciar a importncia do ponto de vista prtico, sistemtico e repetvel a ela necessrio como feito nas definies apresentadas por (HSIA; DAVIS; KUNG, 1993), (GILB, 1997) (SOMMERVILLE; SAWYER, 1997) e (VAN LAMSWEERDE, 2009) , o que faz essa disciplina ser uma Engenharia. Na definio apresentada por Hsia, Davis e Kung (1993, p.75), por exemplo, Engenharia de Requisitos definida como "a aplicao disciplinada de princpios, mtodos, ferramentas e notaes provadas para descrever o comportamento pretendido do sistema proposto e suas restries associadas".

26

Em alguns outros trabalhos, como (BUBENKO JR., 1995), (VAN LAMSWEERDE, 2009) e (ZAVE, 1997), a definio de Engenharia de Requisitos evidencia a importncia do ambiente, reforando a ideia de requisito. Zave (1997, p.315), por exemplo, define Engenharia de Requisitos como "um ramo de engenharia de software preocupada com as metas do mundo real para funes e restries de sistemas de software. Ela tambm est preocupada com o relacionamento desses fatores com a especificao precisa do comportamento do software e a sua evoluo no tempo e atravs de famlias de software".

Outras definies tratam das responsabilidades envolvidas na Engenharia de Requisitos, algumas vezes de forma superficial. Por exemplo, na definio apresentada por Wiegers (2003, p.488), Engenharia de Requisitos "o domnio que abrange todas as atividades do ciclo de vida de um projeto associadas com o entendimento das capacidades e dos atributos necessrios ao produto". Em outras definies as responsabilidades so mais detalhadas, como, por exemplo, na definio apresentada por van Lamsweerde (2009, p.6) em que Engenharia de Requisitos "um conjunto coordenado de atividades para explorar, avaliar, documentar, consolidar, revisar e adaptar os objetivos, capacidades, qualidades, restries e fatos assumidos que o sistema a ser construdo (to-be) deve satisfazer baseado em problemas levantados pelo sistema atual (as-is) e oportunidades providas por novas tecnologias".

Neste trabalho ser usada a definio apresentada por Sommerville e Sawyer (1997, p.5), na qual Engenharia de Requisitos :

A disciplina que cobre "todas as atividades envolvidas em descobrir, documentar e manter um conjunto de requisitos para um sistema baseado em computador".

No h um consenso em quais so exatamente essas atividades, mas em geral as seguintes atividades esto presentes (HSIA; DAVIS; KUNG, 1993) (KAVAKLI; LOUCOPOULOS, 2005) (NUSEIBEH; EASTERBROOK, 2000) (SOMMERVILLE; SAWYER, 1997) (VAN LAMSWEERDE, 2009):

Elicitao: trata da descoberta dos requisitos, podendo ser realizada ao aplicar diferentes tcnicas, como, por exemplo, a aplicao de questionrios, prototipao ou anlise do ambiente (NUSEIBEH; EASTERBROOK, 2000);

27

Anlise e negociao: trata da anlise dos requisitos elicitados considerando conflitos, riscos, alternativas e prioridades (VAN LAMSWEERDE, 2009) e a negociao dos requisitos com as partes envolvidas, em busca de um acordo.

Documentao: trata da criao do documento de especificao de requisitos, que serve como uma declarao oficial para as partes envolvidas de quais so as especificaes (SOMMERVILLE; SAWYER, 1997); e

Consolidao: trata da verificao dos requisitos definidos e da validao deles com as partes envolvidas.

Considerando o quadro de referncia de requisitos considerado por este trabalho, o modelo WRSPM, durante a atividade de anlise e negociao que as especificaes so obtidas a partir dos requisitos.

Alm dessas atividades que esto inseridas no processo de desenvolvimento de sistemas, tambm existe a Gerncia dos Requisitos (CMMI PRODUCT TEAM, 2010) (SOMMERVILLE; SAWYER, 1997). Ela um processo executado em paralelo que gerencia as mudanas nos requisitos, tratando de sua evoluo.

3.3 Engenharia de Requisitos orientada por metas

Nos projetos em que o sistema computacional faz parte de um ambiente organizacional, os requisitos no devem ser afirmaes sobre o ambiente atual, mas do ambiente que se pretende obter. Com isso, antes de definir os requisitos do sistema computacional necessrio projetar esse novo ambiente, definindo de alguma forma as responsabilidades dos diversos elementos que faro parte dele. Algumas abordagens de Engenharia de Requisitos adotam uma premissa que a definio desse novo ambiente, em especial as responsabilidades do sistema computacional a ser construdo, de responsabilidade da Engenharia de Requisitos (KAVAKLI; LOUCOPOULOS, 2005) (VAN LAMSWEERDE, 2001). Antes de elicitar os requisitos, alguma atividade deve considerar como o sistema pretendido atinge os resultados organizacionais desejados, entendendo o como e, principalmente, o porqu dos requisitos obtidos (YU, 1995). Com isso seria possvel obter requisitos mais significativos (ROLLAND; SALINESI, 2005), que representariam de forma mais apropriada as necessidades pretendidas do novo ambiente. Para isso, essas abordagens de Engenharia de Requisitos propem a modelagem de metas, sendo

28

que o uso de metas para realizar as atividades Engenharia de Requisitos o que se chama de Engenharia de Requisitos orientada por metas (GORE Goal Oriented Requirements Engineering) (VAN LAMSWEERDE, 2009).

Uma meta nesse contexto "um objetivo que o sistema sob considerao deveria atingir" (VAN LAMSWEERDE, 2001, p.250)10 . Dessa forma, uma meta pode se referir desde a objetivos organizacionais e resultados estratgicos a serem obtidos (em metas de alto nvel) a at detalhes tcnicos que uma determinada parte do sistema deve atender (ROLLAND; SALINESI, 2005) (VAN LAMSWEERDE, 2009). Mesmo as metas de mais baixo nvel no definem como elas sero atingidas, podendo assim existir diversas alternativas a serem consideradas (YU, 1995). Dependendo da meta pode at ser difcil avaliar se uma determinada alternativa realmente a satisfaz essas metas que no tm um critrio claro de satisfao so chamadas de metas flexveis (softgoals), em contraposio a metas concretas (hardgoals) (BRESCIANI et al., 2004) (YU, 1995).

Para satisfazer uma meta necessria a cooperao de diversos agentes (DARDENNE; VAN LAMSWEERDE; FICKAS, 1993). Um agente "um componente ativo do sistema realizando um papel especfico na satisfao de uma meta" (VAN LAMSWEERDE, 2009, p.260), podendo assim representar uma pessoa, um software ou um sistema em geral. Para obter especificaes a partir das metas necessrio refinar as metas de mais alto nvel, o que feito atravs de rvores E/OU (ROLLAND; SALINESI, 2005) (VAN LAMSWEERDE, 2009), que tambm podem ser vistas como diagramas de metas. Essas rvores representam relaes entre as metas, sendo que as metas podem ser decompostas de forma que todas as metas de mais baixo nvel precisam ser satisfeitas para que a meta de mais alto nvel seja satisfeita (decomposio E), ou que apenas uma das metas de baixo nvel precise ser satisfeita para que a meta de mais alto nvel seja satisfeita (decomposio OU). Essas decomposies presentes nos diagramas de metas permitem representar as alternativas de refinamento dos requisitos, enquanto que informaes de correlao entre as metas permitem analisar como as alternativas tratam das metas envolvidas

10 A definio de meta seguida por mtodos GORE no a mesma seguida por alguns modelos com

ponto de vista de negcio, como o BMM (OMG, 2008a). A fim de evitar ambiguidades e ainda seguir os termos usados pelas abordagens GORE, nesta seo ser usado apenas o termo meta, mas no restante do trabalho se usar o termo meta GORE para referenciar o conceito de meta nesse tipo de abordagem.

29

(MYLOPOULOS et al., 2001). Uma outra forma de representar as alternativas na atribuio das metas a agentes, representando os possveis agentes que podem ser responsveis por uma determinada meta (VAN LAMSWEERDE, 2009).

Como apenas a relao de decomposio entre as metas pode ser insuficiente para o uso nas atividades de Engenharia de Requisitos, como, por exemplo, para a anlise de alternativas, os diagramas de metas representam alguns outros elementos e outras formas de relacionamentos entre eles (YAMAMOTO et al., 2006). Esses elementos e relacionamentos, assim como a forma de refinamento das metas, variam dependendo da abordagem GORE empregada.

3.3.1 Abordagens orientadas por metas

Entre as abordagens orientadas por metas pode-se citar KAOS, i*, Tropos, B-SCP, Map e EKD.

KAOS11 um mtodo GORE para "elicitar, especificar e analisar metas, requisitos, cenrios e atribuies de responsabilidades" (VAN LAMSWEERDE, 2001, p.8). Para isso ele possui trs componentes (DARDENNE; VAN LAMSWEERDE;

transformaÇÃo de um modelo de empresa em um modelo de casos de uso seguindo os conceitos de...

Documents