VMEPWGALFNMD

UNIVERSIDADE METODISTA DE PIRACICABA
FACULDADE DE CINCIAS EXATAS E DA NATUREZA

PROGRAMA DE PS-GRADUAO EM CINCIA DA COMPUTAO
ESPECIFICAO E IMPLEMENTAO DE UMA FERRAMENTA PARA

ELICITAO DE REQUISITOS DE SOFTWARE BASEADA NA TEORIA DA
ATIVIDADE
SIMONE FRANCETO
ORIENTADOR: PROF. DR. LUIZ EDUARDO GALVO MARTINS
PIRACICABA, SP
2005
UNIVERSIDADE METODISTA DE PIRACICABA

FACULDADE DE CINCIAS EXATAS E DA NATUREZA
PROGRAMA DE PS-GRADUAO EM CINCIA DA COMPUTAO

ATIVIDADE
SIMONE FRANCETO
Dissertao apresentada ao Programa de PsGraduao em Cincia da Computao, da

Faculdade de Cincias Exatas e da Natureza, da
Universidade Metodista de Piracicaba UNIMEP,
como requisito para obteno do Ttulo de Mestre
em Cincia da Computao.
PIRACICABA, SP
2005
Franceto, Simone
Especificao e implementao de uma ferramenta para elicitao de
requisitos de software baseada na teoria da atividade / Simone Franceto.Piracicaba, SP, 2005.
Orientador : Luiz Eduardo Galvo Martins.
Dissertao (Mestrado) Universidade Metodista de Piracicaba, Faculdade
de Cincias Exatas e da Natureza, Programa de Ps-Graduao em Cincia da
Computao.
1. Elicitao de requisitos. 2. Teoria da atividade. 3. Engenharia de

requisitos. 4. Ferramenta automatizada. 5. Metodologia de elicitao de
requisitos de software baseado na teoria da atividade (META). I.
Martins, Luiz Eduardo Galvo. II. Universidade Metodista de
Piracicaba, Faculdade de Cincias Exatas e da Natureza, Programa de
Ps-Graduao em Cincia da Computao.

ATIVIDADE
AUTOR: SIMONE FRANCETO

Dissertao de Mestrado defendida em 20/12/2005, pela Banca Examinadora

constituda dos Professores:
Dr. Luiz
UNIMEP)
Eduardo
Galvo
Martins
(Orientador
Dr. Teresa Gonalves Kirner (UNIMEP)
Dr. Ariadne Maria Brito Rizzoni Carvalho (UNICAMP)

Meus
pais
pelo
amor,
pacincia
perseverana. Ao meu noivo, muito amor e compreenso.

Aos
Meus avs e todos os amigos prximos que
me ajudaram em todos os momentos para a finalizao deste trabalho.
AGRADECIMENTOS
A Deus primeiramente pela fora e luz ao longo de todo este

perodo.
Ao meu orientador, Dr. Luiz Eduardo Galvo Martins, pela ateno
concedida, pela orientao, pacincia e pela oportunidade e
confiana para o desenvolvimento desta dissertao de mestrado.
A meus pais e avs, pela confiana e apoio; sempre torceram e
oraram para que todos os meus objetivos fossem alcanados.
A meu noivo, pelo amor, carinho, pacincia, e por toda a fora e
apoio ao longo deste perodo.
A todos meus amigos, pela amizade, trocas de experincia e
compreenso.
Aos meus professores que muito me ajudaram no desenvolvimento
deste trabalho.
O futuro depender daquilo que fazemos no presente.

(Mahatma Gandhi, apstolo nacional e religioso da ndia, 1869 1948)
RESUMO
Uma Engenharia de Requisitos (ER) bem estruturada garante qualidade,

confiabilidade e integridade ao produto de software a ser desenvolvido. A ER
envolve um relacionamento com os futuros usurios do sistema, a descoberta
do que o sistema dever fazer e possveis restries do mesmo. Requisitos
precisam ser documentados pois podem mudar durante a anlise do processo.
Novos usurios podem aparecer durante o processo de elicitao, sendo que
fatores polticos e organizacionais tambm podem influenciar nos requisitos do
mesmo. Muitas metodologias e ferramentas automatizadas tm contribudo
para o avano da fase de elicitao de requisitos, o que demanda contato
direto com usurios no entendimento do domnio do problema. Este trabalho
apresenta o desenvolvimento de uma ferramenta de elicitao de requisitos
para apoiar a Metodologia de Elicitao de Requisitos de Software Baseada na
Teoria da Atividade (META). A ferramenta possui recursos para levantar e
armazenar dados, consultar os dados inseridos de forma grfica (diagrama de
Engestrm), atravs de consultas pela interface da ferramenta ou atravs da
emisso de relatrios, o que torna a META prtica, auxiliando os analistas de
requisitos nas fases posteriores da Engenharia de Requisitos, bem como no
desenvolvimento do futuro sistema de software. A ferramenta deve agilizar e
facilitar o uso da META, como tambm espera-se que contribuia para a
comunidade de Engenharia de Requisitos.
PALAVRAS-CHAVE: ELICITAO
DE
REQUISITOS, TEORIA
REQUISITOS, FERRAMENTA AUTOMATIZADA, METODOLOGIA

SOFTWARE BASEADO NA TEORIA DA ATIVIDADE (META).
DE
DA
ATIVIDADE, ENGENHARIA
ELICITAO
DE
REQUISITOS
DE
DE
ABSTRACT
A well structured Requirements Engineering (ER) guarantees quality,

trustworthiness and integrity to the software product to be developed. ER
involves a relationship with future users of the system, who must have a
thorough knowledge of it and may make constraints on a future system.
Requirements need to be registered because possible changes may occur
during the process analysis as new users can appear during process elicitation.
Political and organizational factors can also influence the requirements of the
future system. Many methodologies and automated tools have contributed to
the advance of the phase of requirements elicitation that demands direct
contact with users of the agreement to analyze the scope of the problem. This
study presents the development of a tool for requirements elicitation to support
the Methodology of Requirements Elicitation for Software Based on the Theory
of Activity (META). The tool has resources to access and store given data. In
addition, it can access inserted date graphical form (Diagram of Engestrom)
through viewing the interface of the tool. Another way to access this data is
through the emission of reports which become the practical META. This will
assist analysts of requirements in the later phases of the Requirements
Engineering and in the development of future software systems. This tool must
facilitate and supply agility. One expects that the use of this tool, supported by
(META) can provide an innovative contribution to the community of Engineering
Requirements.
KEYWORDS: REQUIREMENTS ELICITATION, ACTIVITY THEORY, SOFTWARE ENGINEERING,

AUTOMATED TOOL, METHODOLOGY
THE
THEORY OF ACTIVITY (META).
OF
REQUIREMENTS ELICITATION
FOR
SOFTWARE BASED
ON
SUMRIO
DR. ARIADNE MARIA BRITO RIZZONI CARVALHO (UNICAMP)...........................................III
RESUMO..................................................................................................................................................VII
ABSTRACT............................................................................................................................................VIII
1.1.METODOLOGIA DE TRABALHO........................................................................................................2
2.1.INTRODUO.............................................................................................................................5
LISTA DE ABREVIATURAS E SIGLAS

ACID
Atomicidade, Consistncia, Isolamento,Durabilidade
ER
Engenharia de Requisitos
ERS
Engenharia de Requisitos de Software
RF
Requisitos Funcionais
RNF
Requisitos No Funcionais
META
Metodologia de Elicitao de Requisitos de Software Baseado

na Teoria da Atividade
UML
Unified Modeling Language
UNIMEP
Universidade Metodista de Piracicaba
UNICAMP
Universidade Estadual de Campinas
LISTA DE FIGURAS
FIGURA 1
PROCESSO INTERATIVO DA ER...........................................................................
FIGURA 2
FASES DA ER....................................................................................................
15
FIGURA 3
EXEMPLO DE CASOS DE USO.............................................................................
26
FIGURA 4
DESCRIO DETALHADA DE CASOS DE USO........................................................
27
FIGURA 5
RESULTADO PARCIAL DA ANALISE DE REQUISITOS NO FUNCIONAL PARA UM SISTEMA DE APOIO

ESCRITRIO. (MYLOPOULOS ET AL., 1999).......................
FIGURA 6
29
FIGURA 7
ANALISE DE REQUISITOS FUNCIONAIS PARA UM SISTEMA DE APOIO ESCRITRIO

(MYLOPOULOS ET AL., 1999).........................................................................
RELACIONAMENTO MEDIADO ENTRE SUJEITO E OBJETO NO NVEL INDIVIDUAL (KUUTTI,
1996). .............................................................................................
FIGURA 8
ESTRUTURA BSICA DE UMA ATIVIDADE (KUUTTI, 1996)...................................
33
33
FIGURA 9
NVEIS HIERRQUICOS DE UMA ATIVIDADE (KUUTTI, 1996) ................................
35
FIGURA 10
ETAPAS DA METODOLOGIA DE ELICITAO PROPOSTA (MARTINS, 2001).............
42
FIGURA 11
DECOMPOSIO DA ETAPA DIVISO DO PROBLEMA EM ATIVIDADE (MARTINS,

2001) ..............................................................................................................
42
FIGURA 12
DECOMPOSIO DA ETAPA DELINEAMENTO DO CONTEXTO DA ATIVIDADE (MARTINS,

2001) ...........................................................................................
43
FIGURA 13
DECOMPOSIO DA ETAPA DESCRIO DA ESTRUTURA HIERRQUICA DA

(MARTINS, 2001). .........................................................................
43
FIGURA 14
RELACIONAMENTO ENTRE OS ELEMENTOS QUE FORMAM A ESTRUTURA

ATIVIDADE (MARTINS, 2001) ..................................................
FIGURA 15
RELACIONAMENTO ENTRE OS ELEMENTOS QUE FORMAM O CONTEXTO DA

(MARTINS, 2001). ..........................................................................
FIGURA 16
TIPOS DE RELACIONAMENTO REPRESENTADOS NO DIAGRAMA DE ENGESTRM......
53
FIGURA 17
DOCUMENTO DE REGISTRO DO PROTOCOLO DAS CHAMADAS TELEFNICAS...........
56
FIGURA 18
MODELO SISTMICO PARA A ATIVIDADE CRIAR PROTOCOLO...............................
61
FIGURA 19
MODELO SISTMICO PARA A ATIVIDADE CONSULTAR PROTOCOLO POR DATA......
61
FIGURA 20
ESTRUTURA DA ATIVIDADE {A1} LEVANTAR ATIVIDADES CANDIDATAS.................
71
FIGURA 21
ESTRUTURA DA ATIVIDADE {A2} SELECIONAR ATIVIDADES..................................
71
FIGURA 22
ESTRUTURA DA ATIVIDADE {A3} DESCREVER HISTRICO DAS ATIVIDADES

SELECIONADAS..................................................................................................
71
FIGURA 23
ESTRUTURA DA ATIVIDADE {A4} IDENTIFICAR OS MOTIVOS E RESULTADOS DAS

ATIVIDADES.......................................................................................................
71
ATIVIDADE
HIERRQUICA DA
ATIVIDADE
29
47
48
FIGURA 24
ESTRUTURA DA ATIVIDADE {A5} IDENTIFICAR OS ELEMENTOS NO NVEL

INDIVIDUAL........................................................................................................
71
FIGURA 25
ESTRUTURA DA ATIVIDADE {A6} IDENTIFICAR OS ELEMENTOS NO NVEL

SOCIAL.............................................................................................................
71
FIGURA 26
ESTRUTURA DA ATIVIDADE {A7} MODELAR A ATIVIDADE ATRAVS DO DIAGRAMA

ENGESTRM.................................................................................................
72
FIGURA 27
ESTRUTURA DA ATIVIDADE {A8} IDENTIFICAR AS AES E OPERAES DA

ATIVIDADE.........................................................................................................
72
FIGURA 28
ESTRUTURA DA ATIVIDADE {A9} DESCREVER AS METAS DAS AES...................
72
FIGURA 29
ESTRUTURA DA ATIVIDADE {A10} DESCREVER AS CONDIES DE REALIZAO

OPERAES...............................................................................................
FIGURA 30
MODELAGEM LGICA DA FERRAMENTA...............................................................
77
FIGURA 31
MODELAGEM
LGICA
DA
FERRAMENTA
ADICIONANDO
A
CLASSE
PROJETO..........................................................................................................
79
FIGURA 32
FIGURA 33
MODELO ARQUITETURAL DAS CLASSES IMPLEMENTADAS REFERENTE A DIVISO DO PROBLEMA

EM ATIVIDADES...........................................................................
83
FIGURA 34
MODELO ARQUITETURAL DAS CLASSES IMPLEMENTADAS REFERENTE

CONTEXTO DAS ATIVIDADES..................................................
85
FIGURA 35
MODELO ARQUITETURAL DAS CLASSES IMPLEMENTADAS REFERENTE

ESTRUTURA HIERRQUICA DA ATIVIDADE.....................................
FIGURA 36
REPRESENTAO FSICA DO BANCO DE DADOS DA FERRAMENTA.........................
89
FIGURA 37
INTERFACE: CADASTRO DE PROJETOS................................................................
92
FIGURA 38
INTERFACE: MENSAGEM COM DEFINIO DA ATIVIDADE CANDIDATA.....................
93
FIGURA 39
INTERFACE: CADASTRO DAS ATIVIDADES CANDIDATAS.........................................
93
FIGURA 40
INTERFACE: CADASTRO DAS ATIVIDADES SELECIONADAS.....................................
94
FIGURA 41
INTERFACE: CADASTRO DOS RESULTADOS DAS ATIVIDADES.................................
96
FIGURA 42
REPRESENTAO GRFICA DO DIAGRAMA DE ENGESTRM..................................
97
FIGURA 43
EXEMPLO DO RELATRIO GERADO PELA FERRAMENTA.......................................
98
FIGURA 44
EXEMPLO DO HELP DA FERRAMENTA..................................................................
99
CASOS
DE
USO
QUE
REPRESENTAM
INTERAO
DO
USURIO
NO
CONTEXTO
DE
DAS
FERRAMENTA.....................................................................................................
DA
DELINEAMENTO
DO
DESCRIO
DA
72
80
87
LISTA DE TABELAS
TABELA 1
GUIA DE PROCEDIMENTOS PARA AS FASES DE ENGENHARIA DE REQUISITOS..... ...
TABELA 2
PRINCIPAIS ETAPAS DA METODOLOGIA DE ELICITAO DE REQUISITOS

BASEADA NA TEORIA DA ATIVIDADE ...............................................
TABELA 3
GRUPOS DOS CONCEITOS RELATIVOS ATIVIDADE .............................................
44
TABELA 4
DESCRIO DA 1 ETAPA DA TEORIA DA ATIVIDADE ...........................................
49
TABELA 5
50
TABELA 6
TABELA 7
DEFINIES
TABELA 8
DESCRIO DO HISTRICO DAS ATIVIDADES ......................................................
58
TABELA 9
DESCRIO DOS MOTIVOS E RESULTADOS DAS ATIVIDADES ...............................
59
TABELA 10
DESCRIO DOS ELEMENTOS DAS ATIVIDADES NO NVEL INDIVIDUAL ....................
59
TABELA 11
DESCRIO DOS ELEMENTOS DAS ATIVIDADES NO NVEL SOCIAL .........................
60
TABELA 12
DESCRIO DAS AES E OPERAES DA ATIVIDADE .........................................
62
TABELA 13
DESCRIO DAS METAS DAS AES ..................................................................
62
TABELA 14
- DESCRIO
DE
17
SOFTWARE
53
TEORIA DA ATIVIDADE UTILIZADOS EM CADA ETAPA

METODOLOGIA ..........................................................................................
ATIVIDADE
E PRINCPIOS DA
DAS
CONDIES
DE
REALIZAO
DAS
OPERAES
DE
41
DA
CADA
.....................................................................................................
55
63
TABELA 15
DESCRIO DO HISTRICO DAS ATIVIDADES SELECIONADAS ..............................
66
TABELA 16
DESCRIO DOS MOTIVOS E RESULTADOS DAS ATIVIDADES SELECIONADAS .......
68
TABELA 17
DESCRIO DOS ELEMENTOS NO NVEL SOCIAL DAS ATIVIDADES SELECIONADAS
70
TABELA 18
DESCRIO DA ESTRUTURA HIERRQUICA DAS ATIVIDADES ...............................
73
TABELA 19
DOCUMENTO DE VALIDAO DA FERRAMENTA ...................................................
101
TABELA 20
ITENS ALTERADOS APS VALIDAO DA FERRAMENTA .......................................
103
1. INTRODUO
No processo de desenvolvimento de software, o levantamento de requisitos

compreensveis por todas as partes envolvidas no desenvolvimento do sistema
(clientes, analistas, desenvolvedores, etc.) um fator bsico e extremamente
importante, evitando falhas no entendimento do problema a ser solucionado.
A obteno de requisitos dentro do contexto da organizao deve ser realizada
de forma adequada, com mtodos, tcnicas e ferramentas que dem suporte
etapa do processo de desenvolvimento. Para isso, dentro do contexto de
Engenharia de Requisitos, a representao dos requisitos tem papel
fundamental na conduo das demais atividades desse processo.
A Engenharia de Requisitos auxilia na obteno de requisitos claros e
consistentes. Estudos tm comprovado que a qualidade do produto de
software est
diretamente relacionada qualidade do processo de
desenvolvimento (SOMMERVILLE e SAWYER, 1997).

Este trabalho tem como objetivo desenvolver uma ferramenta automatizada
que d suporte Metodologia de Elicitao de Requisitos Baseada na Teoria
da Atividade - META1, proposta por Martins, (2001). O conceito de atividade
utilizado est baseado na Teoria da Atividade (WERTSCH, 1998), o qual
fundamenta a ferramenta que foi desenvolvida. A Teoria da Atividade tem sido
muito estudada em pesquisas que abordam o entendimento da interao entre
o ser humano e o seu ambiente material, em um contexto scio-cultural
(ROCCO, 2002).
A ferramenta desenvolvida pretende deixar a META mais fcil de ser usada. As
informaes coletadas durante a fase de elicitao de requisitos facilmente
sero registradas e armazenadas em um banco de dados. As consultas das
informaes podero ser realizadas via relatrios ou por meio de consultas nas
telas da ferramenta.
META: Nome adotado neste trabalho para abreviar: Metodologia de Elicitao de Requisitos Baseada
na Teoria da Atividade, facilitando citaes.
Neste trabalho propomos uma ferramenta apoiada na META para auxiliar a

primeira fase da Engenharia de Requisitos, onde analistas de requisitos entram
em contato direto com as pessoas envolvidas no sistema organizacional.
Para isso requerida uma disciplina para a extrao de informaes referentes
s
atividades
realizadas
pelas
pessoas
envolvidas
no
sistema.
desenvolvimento da ferramenta tambm auxilia na documentao das

informaes coletadas.
De acordo com Rezende e Abreu (2000, p. 97),
[...] A informao nos dias de hoje tem um valor altamente
significativo e pode representar poder para quem a possui, seja
pessoa, seja instituio. Ela possui seu valor, pois est
presente em todas as atividades que envolvem pessoas,
processos, sistemas, tecnologias, etc.
A META apresenta um excelente desempenho na elicitao de requisitos para

grandes sistemas onde h muitas informaes para serem levantadas e
documentadas. A ferramenta por sua vez, auxiliar nas informaes
levantadas do ambiente em estudo, registrando-as e agilizando o processo de
elicitao de requisitos.
Documentar e armazenar informaes um fator chave no desenvolvimento

de um software, o qual possibilita o acesso rpido consulta aos dados, a
integridade e segurana das informaes, alm da reduo no tempo de
manuteno das informaes.
1.1.
METODOLOGIA DE TRABALHO
O desenvolvimento do trabalho foi realizado em seis etapas como apresentado

a seguir:
1. Reviso sobre a Engenharia de Requisitos e Teoria da Atividade: Nesta
fase foi realizada uma reviso bibliogrfica sobre a Engenharia de
Requisitos e a Teoria da Atividade, que so importantes para fundamentar

a ferramenta que foi desenvolvida.
2. Especificao das necessidades e domnio da aplicao do sistema:
Esta fase envolveu a especificao das necessidades do domnio da
aplicao do sistema. Foi realizado atravs da reviso bibliogrfica e
compreenso da Metodologia de Elicitao de Requisitos Baseada na
Teoria da Atividade.
3. Levantamento e Especificao dos Requisitos: As fases de Elicitao,
Anlise e Especificao de Requisitos foram trabalhadas com a prpria
Metodologia de Elicitao de Requisitos de Software Baseada na Teoria da
Atividade (META), proposta por Martins (2001).
4. Projeto de software: Foi dividido em Projeto Lgico (Estrutura de Dados
Modelagem) e Projeto de Interface com o Usurio.
No Projeto Lgico foi realizada a modelagem dos dados do sistema2, com os
diagramas de anlise da especificao UML, a partir dos documentos de
requisitos.
Escolheu-se UML (Unified Modeling Language - Linguagem de Modelagem
Unificada) por ser um conjunto de ferramentas (desenhos) que permitem
representar o modelo do sistema. uma linguagem padro para visualizar,
especificar, construir e documentar os artefatos para um sistema de software.
No Projeto de Interface com Usurio foram desenvolvidos prottipos de telas,
dando origem s telas da ferramenta.
5. Implementao do Software: Construo do Banco de Dados em MySQL
e codificao do programa em JAVA (ambiente aberto).
6. Validao do Software: Foi realizada em um ambiente real observando
toda a estrutura da ferramenta com o objetivo de reparar erros e corrigir
falhas operacionais, de aperfeioamento das telas e dos processos
desenvolvidos.
Sistema: contexto no qual est inserido o desenvolvimento da ferramenta de elicitao de requisitos de
software baseado na Teoria da Atividade.
O restante da dissertao est organizada da seguinte forma: No segundo

captulo apresentada uma reviso bibliogrfica sobre a Engenharia de
Requisitos. No terceiro captulo apresentada a reviso bibliogrfica sobre a
Teoria da Atividade abordando conceitos importantes que fundamentam a
META. No quarto captulo tem-se a reviso bibliogrfica da Metodologia de
Elicitao de Requisitos de Software Baseada na Teoria da Atividade, a qual a
ferramenta desenvolvida ir apoiar. No quinto captulo, Ferramenta de Apoio a
Elicitao de Requisitos Utilizando a META, registrado todo o processo de
levantamento de requisitos, modelagem de classe e de banco de dados da
ferramenta, alm do modelo arquitetural das classes implementadas, e
algumas interfaces implementadas. No sexto captulo apresentada a
Validao da Ferramenta, bem como o resultado do teste aps a
implementao da mesma. No stimo captulo, tem-se a Concluso do
trabalho e propostas para trabalhos futuros.
2. A ENGENHARIA DE REQUISITOS
2.1. INTRODUO
Durante o processo de desenvolvimento de software, definir e parametrizar
requisitos que sejam compreensveis por todas as partes envolvidas no
desenvolvimento (clientes, analistas, desenvolvedores, etc.), um fator bsico
e ao mesmo tempo um problema de difcil soluo. muito importante fazer
uma abordagem sistemtica da obteno dos requisitos que permita a sua
compreenso por parte do usurio e tambm a produo de um sistema
utilizvel a um custo aceitvel. Toda essa anlise e levantamento de dados
devem seguir princpios de engenharia, utilizando de forma adequada
mtodos, tcnicas e ferramentas que dem suporte a essa etapa do processo
de desenvolvimento. A Engenharia de Requisitos (ER) tem um papel
importante no planejamento de projeto de software e, devido alta
complexidade dos sistemas, muito importante um correto entendimento
antecipado dos mesmos, antes de um comprometimento de uma soluo para
o projeto em estudo. Apresentam-se a seguir, algumas definies encontradas
para ER:
Lamsweerde (2000, p. 5) define ER como:
[...] a identificao dos objetivos a serem atingidos pelo
futuro sistema, a operacionalizao3 de tais objetivos em
servios e restries, e a atribuio de responsabilidades
pelos requisitos resultantes a agentes humanos,
dispositivos e software.
Zave (1997, p. 315) define ER como:
[...] o ramo da engenharia de software que est
preocupado com os objetivos do mundo real para as
funes e restries aplicveis a sistemas de software.
Est tambm preocupado com o relacionamento destes
fatores para especificaes precisas do comportamento
do software e com sua evoluo no tempo e atravs de
famlias de produtos.
Esta palavra no existe na lngua portuguesa. Est sendo usada neste contexto para designar a transformao dos objetivos em
servios e restries do sistema. Ser utilizada no texto por ser comum no meio acadmico.
Em Kotonya e Sommerville (1998) encontra-se a definio da ER como sendo

a forma como escolhemos denominar as atividades desenvolvidas, no contexto
do ciclo de vida de software, relacionadas com a definio dos requisitos de
um sistema.
A ER est relacionada identificao de metas a serem atingidas pelo sistema
a ser desenvolvido, assim como operacionalizao de tais metas em servios
e restries. Essa rea tambm est interessada no relacionamento desses
fatores para fazer uma especificao do comportamento do software e sua
evoluo ao longo do tempo (ZAVE, 1997), e tambm com o processo de
aquisio, refinamento e verificao das necessidades do cliente, para um
sistema de software no sentido de se obter uma especificao completa e
correta dos requisitos de software.
A ER uma rea ampla e multidisciplinar, cujos aspectos sociais e humanos
desempenham
um
importante
papel
(ZAVE,
1997;
NUSEIBEH
EASTERBROOK, 2000). A ER foi criada para definir todas as atividades

envolvidas em descobrir, documentar e manter um conjunto de requisitos para
um projeto de sistema de software (SOMMERVILLE e SAWYER, 1997).
A ER estabelece o processo de definio de requisitos como um processo
onde, o que deve ser feito elicitado, modelado e analisado. Esse processo
deve
lidar com diferentes pontos de vista, e usar uma combinao de
mtodos, ferramentas e pessoal. O produto desse processo um modelo, a

partir do qual um
documento de
requisitos
produzido. Esse processo
acontece num contexto previamente definido o qual chamamos Universo de

Informao (LEITE, 1994).
Processo de ER Uma completa descrio do processo de ER deve incluir
quais atividades sero realizadas, a estrutura ou programao dessas
atividades, quem ser responsvel por cada uma das atividade, a entrada e
sada das mesmas e as ferramentas usadas para dar suporte ER. Uma boa
descrio desse processo fornecer uma direo para as pessoas envolvidas
e
reduzir
probabilidade
de
(SOMMERVILLE e SAWYER, 1997).
que
atividades
sejam
esquecidas
Para Kotonya e Sommerville (1997), o processo de ER pode ser considerado

um conjunto estruturado de atividades com o objetivo de derivar, validar e
manter um documento de requisitos.
Existem vrias propostas para modelos de processo de ER. Todavia, no
existe um processo considerado ideal. Este trabalho adota o modelo proposto
por Thayer e Dorfman (1997), que descreve as seguintes fases do processo
de requisitos:
Elicitao
Anlise;
Documentao (Especificao);
Verificao; e
Gerncia de Requisitos.
A Figura 1 mostra essas atividades representadas num modelo espiral, no qual

cada atividade do processo repetida at a tomada da deciso para que o
documento de requisitos seja aceito. Apesar dessas atividades serem
normalmente descritas independentemente e em uma ordem particular, na
prtica, consistem de processos interativos e inter-relacionados que podem
cobrir todo o ciclo de vida do desenvolvimento de sistemas de software
(NUSEIBEH e EASTERBROOK, 2000).
Nessa mesma figura, verifica-se o papel da gerncia de requisitos, tornando-se
indispensvel um acompanhamento em todas as fases do ciclo. Seu processo
iterativo e dinmico, todas as fases so desenvolvidas e necessitam ser
revistas sempre. O papel da gerncia ser fazer esse acompanhamento e a
cada fase realizada a manuteno deve ser constante, para que possveis
falhas dos requisitos sejam reparadas e os riscos minimizados.
Figura 1 Processo Interativo da ER.
2.2. DEFINIO DE REQUISITOS

De acordo com o Dicionrio Moderno da Lngua Portuguesa, requisito a
condio exigida para certo fim; exigncia legal; condio.
Uma outra definio foi apresentada por Leite (1994):
Requisitos: Condio necessria para a obteno de certo objetivo, ou para
o preenchimento de certo objetivo.
Requisitos so definidos durante as fases iniciais do desenvolvimento do
sistema como uma especificao do que deveria ser implementado. So
descries de como o sistema deveria comportar-se (SOMMERVILLE e
SAWYER, 1997).
Um conceito chave que garante uma boa consistncia no projeto de

desenvolvimento dos requisitos est na documentao clara e precisa dos
processos, a fim de compor um trabalho responsvel e eficiente.
Assim sendo, pode-se considerar que a ER uma das fases mais importantes
do processo de engenharia de software a fim de melhorar a qualidade dos
requisitos. Existem inmeras definies disponveis na literatura para o termo
requisitos. Segundo Kotonya e Sommerville (1997), um requisito pode
descrever.
Uma facilidade para o usurio; por exemplo, um corretor de gramtica e

ortografia;
Uma propriedade muito geral do sistema; por exemplo, o sigilo de

informaes;
Uma restrio especfica no sistema; por exemplo, o tempo de varredura

de um sensor;
Uma restrio no desenvolvimento do sistema; por exemplo, a

linguagem que dever ser utilizada para o desenvolvimento do sistema.
Uma definio simples para requisitos dada por Macauly (1996). Segundo o
autor, requisito simplesmente algo que o cliente necessita. Segundo Jackson
(1995), requisitos so fenmenos ou propriedades do domnio da aplicao
que devem ser executados, normalmente expressos em linguagem natural,
diagrama informal ou outra notao apropriada ao entendimento do cliente e
da equipe de desenvolvimento.
2.3. REQUISITOS FUNCIONAIS E NO FUNCIONAIS
A complexidade de um software determinada em parte, por sua

funcionalidade, ou seja, o que o sistema faz, denominados Requisitos
Funcionais (RF), e em parte por requisitos gerais que fazem parte do
desenvolvimento
do
software
como
custo,
performance,
segurana,
confiabilidade, manutenabilidade, portabilidade, custos operacionais entre

outros, denominados Requisitos No-Funcionais (RNF) (CHUNG et al., 2000).
Os RF descrevem o que o sistema deve fazer, ou seja, as transformaes a
serem realizadas nas entradas de um sistema, a fim de que se produzam
sadas (SOMMERVILLE e SAWYER, 1997).
J os RNF, tm um papel muito importante no desenvolvimento dos sistemas.
Uma vez realizada a elicitao de forma incorreta, torna-se um processo difcil
e caro de se corrigir, caso o sistema j esteja implementado.
Um RF determina o que o software realizar, e um RNF expressa as
caractersticas que este software vai apresentar. Por exemplo, um requisito
funcional dever afirmar que sistemas devero fornecer algumas facilidades
para autenticao da identificao de um usurio do sistema; um requisito no
funcional dever afirmar que o processo de autenticao dever ser
completado em quatro segundos ou menos (SOMMERVILLE e SAWYER,
1997).
2.4. REQUISITOS DE SISTEMA
Engenharia de Requisitos de Sistemas a cincia e disciplina interessada na
anlise e documentao dos requisitos do sistema. Transforma uma
necessidade operacional em uma descrio de sistemas, parmetros de
apresentao do sistema e em uma configurao do sistema. Isso realizado
atravs do uso de um processo interativo de anlise, projeto, estudos de tradeoff e prototipagem (THAYER e DORFMAN, 1997).
Requisitos de Sistemas so especificaes mais detalhadas dos requisitos que
podem ser expressas como um modelo abstrato do sistema. Pode ser um
modelo matemtico ou notaes baseadas em grficos, como diagramas de
fluxo de dados, objetos de classes hierrquicas, e etc. Esses modelos so

sempre anotados com descries em linguagens naturais (SOMMERVILLE e
SAWYER, 1997).
Requisitos de sistemas descrevem o comportamento do sistema como visto do
lado de fora, por exemplo, pelo usurio. Envolve um contexto mais amplo e
menos tcnico.
2.5. REQUISITOS DE SOFTWARE
uma descrio dos principais recursos de um produto de software, seu fluxo
de informaes,
comportamento e atributos. Em suma, um requisito de
software fornece uma estrutura bsica para o desenvolvimento de um produto

de software. O grau de entendimento, preciso e rigor da descrio fornecida
por um documento de requisitos de software tende a ser diretamente
proporcional ao grau de qualidade do produto resultante (PETERS e
PEDRYCZ, 2001).
A engenharia de Requisitos de Software analisa e documenta os requisitos de
software, dividindo os sistemas em subsistemas e tarefas, transformando
determinados requisitos de sistemas em uma descrio de requisitos de
software e parmetros de apresentao atravs do uso de um processo
interativo de anlise, projeto e prototipagem.
2.6. O PAPEL DA ENGENHARIA DE REQUISITOS
A ER tem um papel fundamental no desenvolvimento de um software de
qualidade. Sua funo gerar especificaes que descrevam de forma no
ambgua, consistente e completa, o comportamento do domnio de um
problema. Existem vrias tcnicas conhecidas para atingir esse objetivo:
Entrevistas, Prototipaes, ViewPoints, Cenrios, Soft Goal, Casos de Uso,
etc.
Na fase de anlise de requisitos realizado o processo de descoberta,

refinamento, modelagem e especificao. Nessa anlise e especificao dos
requisitos, o desenvolvedor e o cliente so participantes ativos do trabalho.
Pode-se pensar que essa tarefa seja simples, mas na verdade no , pois a
integridade da comunicao a palavra-chave e pode trazer muitas
complicaes para o desenvolvedor se tudo no estiver bem esclarecido, pois
duplas interpretaes podem ocorrer.
O papel da ER, parametrizar o conjunto de aes a serem analisadas no
processo de projeto de sistemas. Alguns problemas podem ocorrer durante o
processo de extrao de requisitos, como por exemplo:
a) Os requisitos podem no refletir a real necessidade do cliente para o
sistema;
b) Requisitos podem ser inconsistentes e/ou incompletos;
c) um processo caro para fazer mudanas aps ter sido
implementado;
d) Muitas vezes pode haver um desentendimento entre clientes,
desenvolvedores de requisitos e o desenvolvedor do produto, devido
a falta de conhecimento, aprimoramento e principalmente cultura,
que impedem que barreiras sejam rompidas em busca de uma
evoluo dentro do processo organizacional.
A melhor forma para evitar negociaes cansativas e reduzir problemas
graves,
como os anteriormente apresentados, melhorar o processo de
descoberta do domnio do contexto onde a organizao est inserida, melhorar

o entendimento, a negociao e descrio dos requisitos,
validando e
gerenciando os requisitos de sistemas.

Nuseibeh e Easterbrook (2000), nos apresentam o contexto no qual a ER
acontece. Normalmente um sistema humano de atividades, e os donos dos
problemas so as pessoas. A ER utiliza cincias sociais e cognitivas para
prover fundamentos tericos e tcnicas prticas para extrair e modelar:
A Psicologia Cognitiva fornece uma compreenso das dificuldades que

as pessoas podem ter ao descrever suas necessidades;
A Antropologia fornece uma aproximao metodolgica observando
atividades humanas que ajudam a desenvolver uma compreenso mais
rica de como sistemas de computador podem ajudar ou podem impedir
essas atividades;
A Sociologia fornece uma compreenso das mudanas polticas e
culturais causadas por informatizao. A introduo de um Sistema de
Computador causa mudanas na natureza do trabalho em uma
organizao e pode afetar a estrutura e os caminhos de comunicao
dentro dela.
A Lingstica importante porque ER, em grande parte, diz respeito
comunicao. As anlises lingsticas mudaram o modo como o idioma
ingls usado em especificaes, por exemplo, para evitar ambigidade
e melhorar o entendimento. Tambm podem ser usadas ferramentas de
lingstica em elicitaes de requisitos, por exemplo, para padres de
comunicao de anlise em uma organizao.
Outro ponto importante para a ER ressaltado por Cysneiros (2001), que o
engenheiro de software delimite os contornos do macrosistema no qual a
definio de software ocorrer, ou seja, delimite o Universo de Informaes do
sistema (UdI). Quanto melhor o delineamento de um UdI, maiores so as
chances de um software bem definido, pois mesmo que o macrosistema no
esteja bem definido, sempre pode-se e deve-se estabelecer os prprios limites
de atuao.
Em muitas organizaes, os requisitos so escritos como pargrafos em
linguagem natural e suplementados por diagramas. A linguagem natural a
nica notao compreendida por todos os leitores potenciais dos requisitos
(Ex.: clientes, usurios, engenheiros de software, engenheiros de requisitos)
(SOMMERVILLE e SAWYER, 1997). Leite (1992), apresenta uma estratgia
de representao de requisitos na qual utilizam-se listas de requisitos em
linguagem natural, suplementadas por lxicos ampliados da linguagem do UdI.
Thayer e Dorfman (1997) apresentam cinco orientaes bem definidas para a

Engenharia de Requisitos de Software (ERS). Ressaltam que ERS a cincia
e disciplina preocupada com o estabelecimento e documentao de requisitos
de software e consiste de:
Elicitao de requisitos de software Processo por meio do qual os

clientes (compradores e/ou usurios) e o desenvolvedor (contratante)
de um sistema de software, descobrem, revisam, articulam e
compreendem a necessidade do usurio e as restries que o software
dever apresentar. Alm de descobrir quais so as necessidades dos
usurios, essa atividade tambm requer uma cuidadosa anlise da
organizao, do domnio de aplicao e dos processos organizacionais
(KOTONYA e SOMMERVILLE, 1997). A elicitao a primeira atividade
no ciclo de vida da engenharia de requisitos, e seu papel geral obter
conhecimento relevante para o problema a ser resolvido. Entretanto, a
tarefa da elicitao identificar os fatos que compem os requisitos do
sistema, de forma a fornecer o mais correto entendimento do que
esperado do sistema de software.
Anlise de Requisitos de Software Processo de anlise das

necessidades dos usurios e clientes para chegar a uma definio de
requisitos de software. O principal objetivo dessa fase fornecer
descries abstratas dos requisitos que possam ser facilmente
interpretadas. Durante os processos de anlise e negociao so
encontrados problemas com os requisitos, tais como: requisitos
esquecidos,
conflitantes,
ambguos
duplicados.
partir
da
identificao desses requisitos com problemas, os usurios devem

discutir, priorizar e negociar at obterem um acordo com possveis
modificaes e simplificaes (ALVES, 2001).
Especificao de requisitos de software Desenvolvimento de um

documento que de forma clara e precisa registre cada requisito do
sistema de software. necessrio que o documento seja compreensvel
por todos os envolvidos no processo de engenharia de requisitos, pois
servir como um contrato entre usurios e desenvolvedores. Diferentes
linguagens tm sido propostas para expressar e descrever requisitos,

desde a linguagem natural at a lgica.
Verificao de Requisitos Software Processos asseguram que a

especificao de requisitos de software est de acordo
com os
requisitos de sistema, conforme padres de documentos das fases de

requisitos e uma base adequada para a arquitetura (preliminar) da
fase de projeto. Segundo Loucopoulus (1995), o processo de validao
de requisitos definido como a atividade na qual certifica-se que o
documento de requisitos consistente com as necessidades dos
usurios.
Gerncia de requisitos de software O planejamento e controle da

elicitao, anlise, especificao e verificao das atividades de
requisitos. A gerncia constituda das atividades relacionadas
manuteno de consistncia e ao controle de alteraes dos requisitos.
O gerenciamento de requisitos uma atividade muito importante no
processo de ER, pois necessrio no somente escrever os requisitos
de forma clara e compreensvel, mas permitir que possam ser
rastreados e gerenciados ao longo da evoluo do sistema. O
rastreamento de requisitos auxilia na definio de uma documentao
completa e com integridade,
como tambm ajuda no processo de
gerenciamento de mudanas desses requisitos (TORANZO e CASTRO,

1999).
Elicitao
Anlise
Especificao
Gerncia
Figura 2 Fases da ER.
Verificao
A fase de gerncia de requisitos a mais dinmica e atua em todas as fases

do processo da ER. De acordo com Cysneiros (2001), uma vez que dificilmente
ter-se- disposio recursos que permitam satisfazer todos os requisitos dos
usurios, estes podem ser classificados como desejveis ou obrigatrios,
utilizando-se um enfoque voltado para a necessidade de priorizar requisitos.
Podem tambm ser classificados como estveis, quando mudam mais
lentamente, ou volteis, quando mudam mais rapidamente. Essa classificao
auxilia a atividade de gerncia de requisitos, uma vez que possibilita antecipar
mudanas provveis de requisitos.
O artigo apresentado por Zave (1997), mostra que a grande dificuldade em
construir um esquema de classificao de pesquisas em ER a
heterogeneidade dos tpicos usualmente considerados parte do processo da
ER e incluem:
Tarefas que devem ser completadas: elicitao de informao de

clientes, validao, especificao;
Problemas que devem ser resolvidos (esclarecidos): linguagem formal e

anlise de algoritmo, prototipagem, mtricas, traceabilidade;
Formas de contribuio para o conhecimento: descrio de prticas

correntes, estudo de caso, experincia controlada;
Tipos de sistemas: sistemas implantados,
sistemas de segurana
crticos, sistemas distribudos.

Muitas vezes, produzir um bom relatrio de requisitos que identifica falhas nos
sistemas torna-se algo difcil e complicado. Trs razes fortes para essa
dificuldade so: i) A definio de requisitos de sistema pode ter sido ruim
(SCHARER,1981); ii) O conhecimento sobre atividades realizadas com
usurios podem ser insuficientes; iii) A cultura existente nas organizaes
muitas vezes impede que o trabalho seja desenvolvido. A expectativa dos
desenvolvedores na fase de projeto do sistema diferente das expectativas do
usurio; muitas vezes a situao do ambiente em estudo controla os
desenvolvedores e nem sempre so usadas tcnicas mais apropriadas para

dominar a contexto do ambiente organizacional em anlise.
A ER, como parte da Engenharia de Software, busca atacar um aspecto
fundamental no processo de produo, que a definio do que se quer
produzir.
O foco principal da ER a definio e a descrio do que um sistema de
software deve fazer para satisfazer aos requisitos informais fornecidos por um
relatrio de necessidades. O pensamento na anlise de requisitos deve voltarse principalmente aos problemas, no s solues (DAVIS, 1993).
Sommerville e Sawyer (1997), apresentam a importncia de um guia de
procedimentos e ressaltam que o mesmo depende da organizao e do tipo de
sistema que ser desenvolvido. Apresentam uma tabela com as fases da ER e
os passos importantes que devem ser seguidos para um trabalho coerente e
prtico. A seguir mostrado na Tabela 1 um Guia de Procedimentos com as
seis fases importantes para o desenvolvimento da ER:
Tabela 1 Guia de Procedimentos para as fases de Engenharia de Requisitos.
Aplicabilidade
Documento
Requisitos
Definio da Aplicabilidade
Guia de Procedimentos
de O documento de requisitos 1) Definir o padro de estrutura do

usado para comunicar requisitos
de
sistemas
usurios
clientes, 2) Como fazer uso do documento;
para
de
documento;
sistemas, 3) Incluir um sumrio de requisitos;
administradores
e 4) Fazer um caso de negcio para o
desenvolvedores
de
sistemas.
Sistema;
Esta aplicabilidade sugere como 5) Definir termos especializados;

melhorar
estrutura
a 6) Preocupar-se com o Lay Out do
organizao deste documento.
documento
sugerido um guia para documento
entendimento;
de requisitos.
para
um
melhor
7) Ajudar os leitores a encontrar

informaes;
8) Fazer o documento propcio a

alteraes;

Aplicabilidade Definio da Aplicabilidade
Elicitao
Requisitos
de Elicitao
de
processo
de
Requisitos
o 1) Avaliar a viabilidade do sistema;
de 2) Ser
descoberta
com
um
consideraes
clientes, 3) Identificar e consultar clientes,
usurios de sistemas e outros que

tm
polticas e organizacionais;
requisitos para um sistema pela

comunicao
sensvel
usurios e desenvolvedores;
interesse
no 4) Registrar fontes de requisitos;

desenvolvimento do sistema. Ele
5) Definir o ambiente operacional do
requer domnio da aplicao e
sistema;
conhecimento
organizacional
6) Usar preocupaes empresariais
tanto quanto o conhecimento do
para guiar a elicitao de
problema especfico. sugerido
requisitos;
um guia para documentos de
7) Procurar domnios de restrio;
requisitos.
8) Registrar a lgica dos requisitos;
9) Coletar requisitos de mltiplos

pontos de vista;
10) Fazer
prottipo
de
requisitos
pobremente compreendidos;
11) Usar cenrios para elicitao de

requisitos;
12) Definir processos operacionais;

Anlise
e Aps
conjunto
inicial
13) Reusar requisitos;

de 1) Definir limites de sistemas;
Negociao de requisitos ter sido relatado, deve 2) Usar checklists para analisar
Requisitos.
ser realizada uma anlise, quanto
requisitos;
a
conflitos,
sobreposies, 3) Fornecer software para apoiar
omisses
Quando
anlise
clientes,
inconsistncias.
informao
estiver
desta
disponvel,
usurios
os
e
desenvolvedores negociam entre

si com a finalidade de concordar
com os requisitos do sistema.
negociaes;
4) Planejar conflitos e resolv-los;
5) Priorizar requisitos;
6) Classificar requisitos usando uma

viso multi-dimensional;
7) Usar matrizes de interao para

encontrar conflitos e overlaps;
8) Avaliar riscos de requisitos;

Descrio de
Descrio de requisitos individuais 1) Definir modelo padro para
Requisitos
deve ser concisa, compreensvel
descrever requisitos;
e no ambgua. Este tpico foca 2) Usar

linguagem
simples
e
em
como
escrever
estas
consistente;
descries e especialmente quais 3) Usar diagramas de forma correta;
devem ser estas descries.
sugerido
um
guia
para
descrio de requisitos.
4) Suplementar linguagem natural

com
outras
de
requisitos;
5) Especificar
os
requisitos
quantitativamente;
quais 1) Desenvolver modelos de sistemas
Modelagem do
Modelos
Sistema
devem sempre ser produzidos,
Validao de
incluem um modelo de ambiente 2) Modelar ambientes de sistemas;

de sistema e um modelo de 3) Modelar arquitetura de sistema;
arquitetura do sistema. Estes
4) Usar mtodos estruturados para
modelos
de
alto
nvel
modelagem de sistemas;
suplementam
os modelos de
5) Usar dicionrio de dados;
sistemas mais detalhados como
6) Documentar a ligao entre
por exemplo, os modelos de fluxo
clientes,
usurios
e
de dados, que podem ser
desenvolvedores de requisitos e
produzidos quando usado o
modelos de sistemas;
mtodo de anlise estruturada.
Aps os documentos de requisitos 1) Checar o documento de requisitos
Requisitos
terem sido produzidos, devem ser
para
formalmente
satisfeitos;
processo
essenciais,
descries
validados.
que
os
padres
sejam
est 2) Organizar inspees de requisitos

preocupado com a verificao dos
formais;
requisitos quanto a omisses, 3) Usar equipes multi-disciplinares
conflitos,
de
Este
complementares;
validao
ambigidades
assegurar que os requisitos sigam

padres de qualidade.
para reviso de requisitos;
4) Definir validao de checklists;

5) Usar prototipagem para avaliar os
requisitos;
6) Escrever um manual de usurio;

Aplicabilidade
Definio da Aplicabilidade
7) Propor casos de teste
de
requisitos;
Gerncia de
Gerncia
de
Requisitos
preocupada
Requisitos
com
todos
8) Parafrasear modelos de sistemas;

est 1) Identificar de modo nico cada
os
requisito;
processos envolvidos na mudana 2) Definir polticas para gerncia de

de requisitos de sistemas.
requisitos;
3) Definir polticas de rastreamento e
rastreabilidade;
4) Manter
um
manual
de
rastreabilidade;
5) Usar um banco de dados para

gerncia de requisitos;
6) Definir polticas de mudana de

gerenciamento;
7) Identificar requisitos de sistemas

globais;
8) Identificar requisitos volteis;

Sistemas
So sistemas que apresentam
Crticos para
forte confiana, disponibilidade,
Engenharia de
sustentabilidade,
Requisitos
9) Listar requisitos rejeitados;

1) Criar checlists de requisitos de
segurana;
segurana
ou 2) Envolver revisores externos nos

requisitos de segurana. Os
processos de validao;
custos do fracasso do sistema 3) Identificar e analisar riscos;
so muito altos e processos de 4) Produzir requisitos seguros a
desenvolvimento de sistemas e
partir das anlises de riscos;
engenharia de requisitos devem 5) Verificar requisitos funcionais e
assegurar que clientes, usurios e
operacionais contra requisitos de
desenvolvedores
tenham
segurana;
confiana no sistema. sugerido 6) Especificar

sistemas
usando
um guia para atividades de
especificaes formais;
processos
importantes
para 7) Recolher
experincias
de
especificaes de sistemas
incidentes;

crticos.
8) Aprender a partir de incidentes;

9) Estabelecer cultura de segurana
organizacional;
Fonte: Sommerville e Sawyer (1997)

Em um dos primeiros trabalhos realizados na rea, Bell e Thayer (1976)
observaram
que
muitos
requisitos
so
inadequados,
inconsistentes,
incompletos e ambguos e que tm um grande impacto na qualidade do

software final. A partir dessa observao os autores concluram que
requisitos para um dado sistema no podem ser levantados naturalmente; ao
contrrio, precisam ser projetados e necessitam de contnuas revises.
Diversos estudos tm contribudo para que processos de ER evoluam cada vez
mais, trazendo consistncia para o desenvolvimento de softwares. A
negociao de requisitos deve ser um processo objetivo. As decises a serem
tomadas em relao aos requisitos do sistema devem ser baseadas nas
necessidades tcnicas e organizacionais e negociaes devem ser conduzidas
usando somente argumentos lgicos e tcnicos, pois muitas vezes so
fortemente influenciadas pelas necessidades pessoais dos indivduos.
2.7. TCNICAS UTILIZADAS
Sero
apresentadas
EM
ELICITAO DE REQUISITOS
nesta
seo
algumas
tcnicas
utilizadas
pelos
profissionais responsveis pela elicitao de requisitos do software.
2.7.1.CENRIOS
A tcnica de cenrios foi introduzida pela disciplina de planejamento militar e
em seguida adotada em vrias outras reas, tais como economia, gerncia e
planejamento (BECKER, 1983). A tcnica de cenrios vem crescentemente
tornando-se popular como parte de uma especificao de requisitos. Descreve
como componentes de sistemas e seus usurios interagem para fornecer uma
funcionalidade nivelada do sistema. Cada cenrio uma parte da histria e
quando combinados com outros cenrios fornecem maiores e completas

descries do sistema (UCHITEL et al., 2003).
Algumas definies de Cenrio:
[...] Cenrio projeta uma descrio concreta de uma atividade
em que o cliente se engaja no momento em que est
realizando uma tarefa especfica. Esta descrio tem de ser
suficientemente detalhada de modo que implicaes sobre o
desenho possam ser inferidas e discutidas (CARROL, 1995).
[...] Cenrios podem ser desde simples descries em
linguagem natural at modelos mais complexos, contendo
informao comportamental (aes, eventos e atividades) e at
objetos (entidades, dados e atributos) (ROLLAND et al., 1998).
Cenrios so definidos como descries narrativas ou histrias dentro de um

contexto
especfico
em
um
determinado
tempo
(CONSTANTINE
LOCKWOOD, 1999).
Cenrios so bem reconhecidos como uma estratgia importante para
entender a interface entre o ambiente e o sistema bem como seu significado
para elicitar e especificar comportamento de software (LEITE et al., 1997).
Cenrios podem ser exemplos especficos de casos de uso, onde um cenrio
descreve um caminho de aes por um caso de uso (KULAK e GUINEY,
2000).
Cenrios e casos de uso descrevem as interaes entre o sistema e os
usurios sem considerar a estrutura interna do sistema.
Cenrios tambm so usados para aplicar um caso de uso de um cliente
particular, outros para descrever qualquer seqncia de eventos do sistema, e
outros ainda aplicam cenrios para atingir metas empresariais ou fazer
inspees de software (CHANCE e MELHART, 1999). Descrevem as situaes
do mundo real onde os agentes que interagem dentro de um determinado
contexto esto envolvidos (ZORMAN, 1995). A tcnica de cenrios utiliza
elementos conhecidos pelos clientes, facilitando tanto o processo de elicitao
de requisitos quanto sua validao (CARROL, 1995). A seguir esto
sintetizadas algumas reas nas quais o autor, Carrol acima citado acredita que
a utilizao de cenrios pode ser benfica:
Elicitao de requisitos: captura e auxlio na compreenso do problema.

Facilita o entendimento das relaes entre elementos do macrosistema.
Cenrios tambm podem ser utilizados na identificao dos objetos do
domnio;
Comunicao entre clientes e desenvolvedores: Os prprios clientes podem

descrever cenrios que ilustrem elementos de desenho que sejam
importantes, problemas ou novas situaes que desejam que o sistema
implemente;
Captura das justificativas do desenho do sistema: Cenrios podem ser

utilizados como forma de registrar o processo de tomada de deciso. Nesse
enfoque no somente a soluo para um problema registrada, mas
tambm outras propostas que foram rejeitadas e as razes que levaram os
desenvolvedores a descart-las;
Projees futuras: Cenrios podem ser utilizados como meio de prototipar o

funcionamento do futuro sistema, especialmente do ponto de vista da
interao com clientes e usurios;
Desenho do Software: Cenrios podem ser usados na avaliao de

alternativas de desenho;
Implementao: Cenrios so teis para ilustrar a interao entre os

diversos subsistemas;
Documentao e Treinamento: Cenrios podem ser utilizados para

preencher o vazio que existe entre o artefato entregue, sistema, e as
tarefas que usurios desejam cumprir atravs de sua utilizao;
Avaliao do sistema: Atravs da utilizao de cenrios externos possvel

verificar se os requisitos dos clientes foram atendidos.
Usurios finais, desenvolvedores e outros agentes do sistema acham a

utilizao de cenrios mais fceis para relacionar-se aos exemplos da vida real
do que descries abstratas das funes realizadas pelo sistema. Por essa
razo, freqentemente til desenvolver um conjunto de interao dos
cenrios, e usar estes para elicitar e clarear requisitos de sistema. Cenrios

so exemplos de sesses de interao as quais so concentradas em um tipo
nico de interao entre um usurio final e o sistema. Usurios finais simulam
suas interaes usando cenrios. Explicam para a equipe de engenheiros de
requisitos o que esto fazendo e a informao que precisam do sistema para
descrever a tarefa descrita no cenrio.
Para Breitman (2000), cenrio descreve situaes do macrosistema e suas
relaes com o sistema a ser construdo. Pode ser utilizado para descrever as
interaes entre os diversos objetos presentes no sistema e evolui durante o
processo de desenvolvimento do software.
2.7.2.PONTOS DE VISTA (VIEWPOINTS)
Em elicitao de requisitos, diferentes stakeholders (clientes, usurios de
sistemas, administradores e desenvolvedores) freqentemente apresentam
diferentes pontos de vista de como um sistema proposto deveria se comportar,
resultando em inconsistncia e disparidade nas descries de requisitos
apresentadas.
Kotonya e Sommerville (1996) apresentam pontos de vista dentro de duas
classes:
Pontos de vista diretos: correspondem diretamente aos clientes, que

recebem servios do sistema e enviam controle de informaes e dados
para o sistema. So tambm sistemas operadores / usurios ou outro
subsistema interfaceados para o sistema a ser analisado.
Pontos de vista indiretos: pontos de viso indiretos tm interesse em

alguns ou em todos os servios que so entregues pelo sistema, mas
no interagem diretamente com este. Podem gerar requisitos que
forneam servios de restries para pontos de vista diretos.
Em Sommerville et al. (1998), proposta uma aproximao flexvel que

acomoda diversos tipos de pontos de vista e que permitem aos usurios
definirem apropriados pontos de vista para suas aplicaes:
O nome do ponto de vista;
Os focos do ponto de vista;
Os interesses do ponto de vista;
As origens do ponto de vista;
Os requisitos do ponto de vista;
A histria do ponto de vista.
Esses pontos de vista so flexveis e podem ser adaptados para especificar

prticas organizacionais e padres. Devem ser usados durante o estgio
anterior ao processo de engenharia de requisitos como um mecanismo
estruturado para a elicitao e anlise de requisitos.
Pontos de vista de engenharia de requisitos apontam que h mltiplos clientes,
usurios de sistemas, administradores e desenvolvedores que conduzem parte
do processo de requisitos, e ao mesmo tempo conduzem inevitavelmente a
discrepncias entre os mesmos. Mas essas discrepncias no so vistas como
indesejveis; por outro lado, podem ser usadas como um meio para melhorar a
elicitao de requisitos e outros aspectos de desenvolvimento de software.
Uma aproximao sistemtica para lidar com discrepncias em engenharia de
requisitos precisa ser diagnosticada adequadamente ao ser encontrada, antes
que seja tomada qualquer deciso sobre o que fazer. Esse diagnstico inclui a
discrepncia localizada, e identifica sua causa e classificao (SILVA, 2002).
2.7.3.CASOS DE USO
Um Caso de Uso foram introduzidos em 1987 como uma ferramenta que
acompanhou a tcnica Objectory, e a aproximao de Casos de Uso para a
engenharia de software foi feita por Ivar Jacobson (JACOBSON et al., 1997).
O diagrama de casos de uso mostra o relacionamento entre atores e casos de
uso dentro de um sistema. Um ator uma funo de objeto ou objetos fora de
um sistema que interagem diretamente com este como parte de uma unidade
de trabalho coerente. Um ator representa qualquer um ou qualquer coisa que
precise trocar informao com o sistema, como uma pessoa ou um sistema de

computador (MOISIADIS, 2000).
Casos de Uso so tcnicas baseadas em cenrios onde so identificados
atores e suas interaes com o sistema, como tambm deve descrever todas
as possveis interaes com o sistema. A Figura 3 apresenta um exemplo de
Casos de Uso.
Reserva Livro
Cliente
da
Biblioteca
(Ator)
Pega Livro
emprestado
Devolve Livro
Figura 3 Exemplo de Casos de Uso.

Diagramas de seqncia representam uma interao entre objetos. So
usados para rigorosamente documentar e verificar a lgica contida em casos
de uso (SCOTT, 2000). Descrevem como objetos interagem e comunicam-se
uns com os outros. Permitem representar como uma seqncia de mensagens
so enviadas e recebidas entre um conjunto de objetos de modo que cada um
execute uma funcionalidade. Cada mensagem no diagrama de seqncia de
eventos corresponde a uma operao no diagrama de classes. Diagramas de
seqncia podem ser usados para adicionar detalhes aos casos de uso ao
mostrar a seqncia de eventos no sistema e descrever as possveis
seqncias de interaes entre o sistema e os atores.
Casos de Uso no um nico cenrio (uma histria especfica de eventos
trocados entre atores e sistemas), mas especialmente uma descrio do
conjunto de cenrios potenciais, com alguns eventos iniciais de um ator para
sistema e seguindo transaes para concluses lgicas. Envolve uma
seqncia de interaes entre o iniciador e o sistema, possivelmente
envolvendo outros atores, e pode incluir opes, iteraes e parmetros.
uma descrio para o conjunto de cenrios, no mesmo sentido que uma classe
uma descrio para um conjunto de objetos.
Maiden et al. (1998), faz uma importante distino entre casos de uso e
cenrios. Tenta usar casos de uso como uma coleo de aes e regras
temporais que governam como a ao pode ser unida. Em contraste, um
cenrio uma seqncia de eventos ordenados, o qual so amarrados o incio
e fim dos eventos ou aes de um caso de uso. Entretanto, possvel ter
mltiplos cenrios para um caso de uso, cada um definindo uma possvel
seqncia de aes atravs de Casos de Uso.
A Figura 4 apresenta a descrio detalhada de Casos de Uso, na qual
detalhada a sequncia tpica de eventos: ao do ator e resposta do sistema
do caso de uso em anlise, Submeter Artigo.
Use Case: Descrio Detalhada

Use Case:
Atores:
Descrio:
Submeter Artigo
Autor
O autor requisita um formulrio de
submisso de artigos. O autor
preenche
o
formulrio
de
submisso e anexa o seu artigo.
Seqncia tpica de eventos
Ao do ator
Resposta do sistema
1. Inicia quando um autor

requisita um formulrio de
submisso de artigos.
3. O autor preenche o
formulrio de submisso e
anexa o artigo.
2. O sistema envia um
formulrio de submisso de
artigos para o autor.
4. O formulrio realiza
verificao semntica.
5. O formulrio retorna para o

coordenador do programa.
Figura 4 Descrio detalhada de Casos de Uso.
Um caso de uso descreve como um dos atores do sistema alcanar a meta

corretamente. Constitui um curso completo de eventos inicializados por um
ator e especifica o contexto de um sistema.
2.7.4.TCNICA SOFTGOAL (METAS FLEXVEIS)
Outros conceitos foram desenvolvidos para a documentao de requisitos no
funcionais, como o caso de Softgoals, utilizados para caracterizar metas que
podem ser parcialmente atendidas. Softgoal representa uma meta que no tem
definio clara nem um critrio para decidir se est sendo satisfeito ou no.
Metas exercem influncia sobre outras metas. Essa influncia pode ser
favorvel a seu atendimento (influncia positiva) ou contrria a seu
atendimento (influncia negativa). Um softgoal considerado atendido se
sofrer mais influncias positivas que negativas. s vezes a evidncia
suficientemente forte para uma deciso satisfatria de softgoal ser realizada
automaticamente sem interveno humana. Em outros casos, quando h
pouca evidncia, a deciso poder ser feita interativamente pelos stakeholders
no processo de anlise de requisitos (MYLOPOULOS et al., 1999).
Requisitos no-funcionais so tratados como softgoals a serem satisfeitos, ou
seja, so metas que precisam ser elaboradas, clarificadas e priorizadas.
SIG (Softgoal Interdependency Graph) um grafo que representa o interrelacionamento
entre
os
requisitos
no-funcionais.
Descreve
interdependncia entre softgoals e como eles so decompostos.

Softgoals so conectados por links de interdependncia, onde um softgoal
pai refinado em softgoals filhos. A seguir pode-se ver a representao da
decomposio dos softgoals atravs de relacionamento E/OU.
: o softgoal satisfeito se todos os sub-softgoals so
satisfeitos;
OU
: o softgoal satisfeito se algum dos sub-softgoals so
satisfeitos;
Decomposio OU
Decomposio E
Flexibilidade
Performance
Usabilidade
Figura 5 Resultado parcial da analise de requisitos no funcional para um

Cresciment
sistema dePadres
apoio
escritrio. (MYLOPOULOS
et al., 1999).
de
o
Futuro
Trabalhos Flexveis
Qualidade
[Tempo]
Esforo
[Escalonamento]
Rentabilidade
Aptido
[Tempo, Preferncias]
Troca de
Tarefas
Modularidad
e
Grau de Compromisso
Figura
6 Analise de requisitos funcionais para
um Tempo]
sistema de apoio
Troca de
[Participantes,
Informao
escritrio (MYLOPOULOS et al., 1999).
Esforo
[Escalonamento]
Acesso
ao
Banco de Dados
Padres de
Desempenh
o
Separados
Esforo
[Equiparando]
Projetos para
Terminais Extras
Manutenabilidad
Organizar Encontro
[Participante]
A Figura 5 apresenta a anlise dos requisitos no-funcionais para um sistema

Acesso aos
Arquivos de
outros
funcionrios
Obtendo
[Participante, Plano]
Performanc
de apoio
escritrio. A Figura 6 apresenta a anlise dos requisitos funcionais
Obtido Manualmente
Equiparar Encontro
Seguran Plano]
[Participante,
Tempo]
para o mesmo sistema de apoio escritrio. Para avaliar a [Participantes,
obteno
dos
Obtido
Automaticamente
Segurana
softgoals
so usados procedimentos
de avaliao para determinar se os
[Participante, Plano]
Equiparar Automtico
requisitos no-funcionais descritos, em especial os prioritrios, foram [Participantes,

obtidos.Tempo]
Atualizado
Reunido
[Calendrio]
Equiparar Manual
Nesse
processo
tambm avaliado
o [Calendrio]
impacto das [Participantes,
decises
Tempo]de projeto que
Obtido por Telefone
Obtido por e-mai
sero tomadas. medida que os softgoals esto sendo refinados, o

desenvolvedor deve decidir quando esto suficientemente detalhados para
tomar decises sobre o projeto do sistema. Assim o desenvolvedor pode
aceitar ou rejeitar as possveis operacionalizaes obtidas no grafo SIG:
Aceitar operacionalizao ou X recusar operacionalizao.
Contribuio positiva:
Um filho satisfeito resulta num pai satisfeito;
Um filho recusado resulta num pai recusado;
Contribuio negativa:
Um filho satisfeito resulta num pai recusado;
Um filho recusado resulta num pai satisfeito;
Vrias tcnicas e ferramentas auxliam as fases de ER. A compreenso do

ambiente em que um futuro software atuar garante qualidade, proporciona
segurana e agilidade ao produto a ser desenvolvido. Assim para desenvolver
a ferramenta que apoia a META, a compreenso da mesma faz-se necessrio.
O prximo captulo apresenta a reviso bibliogrfica da Teoria da Atividade, a
qual fundamenta a META.
3. TEORIA DA ATIVIDADE
A Teoria da Atividade originou-se com o psiclogo Vygotsky na Unio

Sovitica, na escola histrico-cultural no perodo de 1920 a 1930 e foca na
interao da atividade humana dentro do seu contexto ambiental (FUENTES et
al., 2004).
Em um sentido amplo, a Teoria da Atividade pode ser definida como uma
estrutura filosfica e interdisciplinar para estudar diferentes formas de prticas
humanas de processos de desenvolvimento, tanto em nvel individual como em
nvel social (NETO, 2003).
Nesta teoria, a mediao o princpio bsico, que explica o desenvolvimento
psquico do ser humano. O conceito de mediao na interao homemambiente pelo uso de instrumentos, foi estendido por Vygotsky. Ele elaborou
de forma criativa as concepes de Engels sobre o trabalho humano e o uso
de instrumentos como os meios pelos quais o homem transforma a natureza e,

ao faz-lo, transforma a si mesmo (WERTSCH, 1998).
O tema da mediao para Vygotsky reflete o pensamento dominante no qual
os meios mediacionais, ou as ferramentas (tambm chamados de artefatos)
fornecem a ligao ou servem de ponte entre as aes concretas conduzidas
por indivduos e grupos (WERTSCH, 1998). O papel principal desempenhado
pela mediao mediar a ao humana utilizando ferramentas tcnicas ou
psicolgicas.
A ao humana pode ser interna (transformao dos processos externos so
reconstrudos internamente, no plano mental - nvel de conscincia),
bem
como externa (os processos internos so convertidos em atos concretos) e

pode ser conduzida por indivduos, grupos pequenos ou grandes.
O psiclogo Lev Vygotsky explica que o desenvolvimento do indivduo originse a partir de seu relacionamento social e do trabalho (Para Marx e Engels,
trabalho a forma bsica / fundamental de atividade humana). Foi Leontev e
Lria que continuaram o trabalho de Vygotsky e passaram a ser responsveis
pelo termo empregado: Teoria da Atividade.
Na Teoria psicolgica da Atividade, argumenta-se que todos os processos
mentais, inclusive a personalidade, tem uma natureza de atividade orientada a
objeto (ASMOLOV, 1990). Com base em vrias afirmaes da Teoria da
Atividade, tem sido mostrado, por exemplo, que o motivo um objeto, e que
uma necessidade (aps encontrar um objeto) tambm torna-se orientada por
um objeto.
A Teoria psicolgica da Atividade est voltada para o problema das
ferramentas e objetos reais. Foca-se na ao mediada por ferramenta e
orientada para o objeto.
O estudo da atividade humana dentro desse contexto, possibilita o
entendimento de como uma atividade modificada atravs de seu ciclo de
vida, a partir do confronto entre experincias individuais e coletivas com a
inteno de melhor-la de acordo com as metas requeridas ou desejadas.
Segundo Engestrm (1996 apud KUTTI, 1996),

[...] Relaes entre elementos de uma atividade no so
dirigidas mas mediadas; Um exemplo: um instrumento tem um
papel mediador entre o ator e o objeto; o objeto visto e
manipulado dentro do conjunto de limitaes pelo instrumento.
Partindo dessa idia, no contexto de uma atividade temos trs elementos

bsicos que se interagem de forma lgica: o sujeito, objeto e ferramenta de
mediao, onde o sujeito atua sobre o objeto atravs de uma ferramenta de
mediao que por sua vez ter o papel de transformar este objeto em
resultado.
Kuutti (1996), apresenta um relacionamento mediado para o nvel individual
entre o sujeito e o objeto e apresenta a ferramenta como um artefato
importante na mediao entre estes. Como j mencionado, o fundamento da
teoria originada por Vygotsky mostra o relacionamento, onde sujeito e objeto
so mediados por uma ferramenta e o resultado obtido atravs dessa
mediao (Vide Figura 7). A existncia de uma atividade motivada a partir do
resultado obtido da transformao de um objeto.
Ferramenta
S u je i to
O bje to
Transformao
Trans formation
Res ultado
Figura 7 - Relacionamento mediado entre sujeito e objeto no nvel individual

(KUUTTI, 1996).
A estrutura apresentada na figura 7 muito simples para suprir as

necessidades de uma considerao de relaes sistmicas entre o sujeito e
seu ambiente em uma atividade. Assim a comunidade foi adicionada a essa
estrutura, a qual composta pelos sujeitos que compartilham o mesmo objeto

(FUENTES et al., 2005). Dessa adio foram formados dois novos
relacionamentos: comunidade-sujeito e comunidade-objeto, ambos mediados
por regras e diviso do trabalho, como mostra a Figura 8 (KUUTTI, 1996).
Ferramenta
Objeto
Sujeito
Regras
Comunidade
Transformao
Do Processo
Resultado
Diviso de
Trabalho
Figura 8 Estrutura Bsica de uma atividade (KUUTTI, 1996).
O relacionamento entre o sujeito e o objeto mediado por ferramentas; o

relacionamento entre o sujeito e a comunidade mediado por regras e o
relacionamento entre o objeto e a comunidade mediado pela diviso do
trabalho. As regras nesse contexto, so normas explcitas e implcitas,
convenes e relaes sociais dentro da comunidade. A diviso do trabalho
refere-se organizao explcita ou implcita de uma comunidade relacionada
ao processo de transformao de um objeto em resultado.
3.1. NVEIS DA ATIVIDADE
Engestrm (1987) deu continuidade a Teoria da Atividade e descreveu o
sistema de atividade humana como uma evoluo que caracterizada por trs
nveis diferentes:
1: No primeiro nvel, a atividade desenvolvida por uma comunidade

orientada por um objeto que corresponde satisfao das necessidades.
2: No segundo nvel situa-se a ao propriamente dita, que
consciente e que determina os meios que sero utilizados para satisfazer as
necessidades.
3: O terceiro nvel correspondente s operaes automatizadas que o
ser humano usa para obter o resultado desejado.
Aboulafia (1994), admite que esses trs nveis no existem isoladamente,
mesmo sendo relativamente independentes, e essa definio tem um sentido,
pois uma atividade pode vir a ser uma ao que para obter resultado precisa
de operaes. Uma ao definida como um elemento discreto da atividade
que realiza uma intermediao da meta consciente da atividade (HARRIS,
2004).
Atividades so formaes de longo prazo. Seus objetos so transformados em
resultados, no somente uma vez, mas atravs de um processo que
tipicamente consiste de diversas fases e etapas (KUUTTI, 1996). Uma
atividade desencadeia uma ao que por sua vez desencadeia uma operao.
A atividade orientada a motivos, a ao orientada metas e a operao
orientada condies (Vide Figura 9).
Conforme apresentado por Martins (2001, p. 63):
[...] O motivo a razo que orienta a atividade, expresso em
termos de desejos e necessidades humanas. As metas so
objetivos de curto prazo a serem atingidas pelas aes da
atividade. As aes concretizam uma atividade, e possuem
metas bem definidas para tal. Assim, existe uma relao
importante entre o motivo da atividade e as metas das aes
que compem a atividade. O motivo da atividade pode ser visto
como o ponto para o qual as metas das aes devem convergir
(o norte das aes).
Atividade
Motivos
Condio
Figura 9 Nveis Hierrquicos de uma atividade (KUUTTI, 1996).

As interaes entre os nveis hierrquicos de uma atividade podem ser
facilmente exemplificadas utilizando uma necessidade do mundo real, como
por exemplo, a fabricao de perfume. No primeiro nvel a atividade
orientada a motivo; no segundo nvel a ao orientada a metas e no terceiro
nvel a operao orientada a condies.
Ser apresentado a seguir um exemplo didtico de como os nveis interagem,
confirmando que esses trs nveis no existem isoladamente.
Analisando uma fbrica de perfume, vamos considerar a seguinte situao: o
objetivo de uma empresa que produz perfumes a venda de um determinado
perfume no segmento feminino. Para a definio do perfume final,
primeiramente a frmula precisa ser aprovada (neste momento entra a
sensibilidade do olfato humano na aprovao do produto, caracterstica
importante na definio do produto final).
Produzir um perfume com determinadas caractersticas, como por exemplo um
perfume feminino com notas frescas, o motivo que leva o profissional
especializado na produo do perfume, atividade de fabric-lo de acordo
com suas especificaes.
As aes dessa atividade so: ) pesar ingredientes solicitados pela frmula, )
analisar essncia olfativa e
) analisar colorao. Essas aes so realizadas
de forma consciente.
A meta de cada ao estabelecida : ) realizar a mistura das substncias
produzindo uma soluo (perfume); ) buscar aprovao da essncia; e
buscar aprovao da cor da essncia.
As operaes dessa atividade so: ) separar os ingredientes solicitados pela

frmula; ) misturar os ingredientes;
) realizar o teste olfativo; e
) colocar a
soluo em diferentes frascos de vidro (coloridos) para a escolha da cor do

produto.
Os equipamentos do laboratrio (balana, tubos de ensaio etc) so
representados como Ferramentas Tcnicas. A experincia de pesagem dos
ingredientes,
conhecimento
especfico
sobre
qumica
de
trabalho,
capacidade de leitura e a interpretao da frmula so representados como

Ferramentas Psicolgicas. Tanto a Ferramenta Tcnica como a Ferramenta
Psicolgica atuam como mediadoras entre o sujeito (Qumico) e o objeto
(Procedimentos - para a realizao do perfume). O resultado dessas
operaes ser o produto final (perfume).
A ao, realizada vrias vezes, quando alcana um nvel de maturidade
suficiente para ser executada, sem um planejamento prvio, passa para o nvel
operao (MARTINS, 2001). Assim, uma operao o resultado de uma ao
que se tornou simples dentro do contexto da atividade.
Aes cognitivas e motoras so compostas ao redor de unidades pequenas
(atos psicolgicos, movimentos) os quais podem ser amplamente no
conscientes, e so freqentemente referidos para as operaes (HARRIS,
2004).
As condies de realizao das operaes nesse processo so: ) ter os
ingredientes solicitados pela composio da frmula;
adequados para a mistura;
olfativa;
) ter os recipientes
) ter a pessoa especfica para realizar a anlise
) ter disponveis os frascos de vidro para anlise de colorao da
soluo.
H tambm a possibilidade das condies de execuo das operaes
estabelecidas serem alteradas. Ento a operao retorna ao nvel de ao
(passa a ser executada de forma consciente). Por exemplo, a condio
estabelecida para a separao dos ingredientes solicitados pela frmula ter
disponveis os ingredientes. Se essa condio for alterada, ento esta
operao retorna ao nvel de ao, passando a ser realizada de forma

consciente, onde novas metas sero estabelecidas.
Nesse nvel da atividade, motivo, ao, meta, operao e condio
apresentam um relacionamento importante, pois o motivo da atividade que
estabelece as metas das aes a serem realizadas, em uma determinada
atividade, e as operaes permanecem em execuo at que as condies
estabelecidas sejam alteradas.
3.2. PRINCPIOS BSICOS DA TEORIA DA ATIVIDADE
Neste captulo sero abordados os princpios bsicos da Teoria da Atividade
que formada por um conjunto de princpios que constituem um sistema
conceitual geral. De acordo com Martins (2001), sua organizao pode variar
de autor para autor, os quais normalmente a dividem em cinco ou seis
princpios.
(1) Princpio da unidade entre conscincia e atividade.

considerado o princpio fundamental da Teoria da Atividade, onde
conscincia e atividade so concebidas de forma integrada. A conscincia4
pode ser entendida como um conjunto de aspectos psicolgicos que so
utilizados no mbito racional, e a atividade como a interao humana com sua
realidade objetiva. A formao dos processos mentais tem sua gnese na
realizao das atividades. Esse princpio declara que a mente humana emerge
e evolui como um componente especial da interao humana com o seu
ambiente (onde a conscincia o repositrio dos resultados dessas
interaes), surgindo no processo de evoluo para ajudar a espcie humana
a sobreviver. Assim, a mente humana pode ser analisada e entendida somente
dentro do contexto da atividade humana. Pode-se dizer que a conscincia
humana abastecida pelas atividades que a pessoa realiza.
4
Uma definio mais precisa do que seja a conscincia humana ainda tema de pesquisa dentro da
prpria Psicologia, e portanto procuramos no estabelecer uma definio rgida para a mesma.
(2) Princpio da orientao a objetos.

Esse princpio foca a abordagem da Teoria da Atividade para o ambiente no
qual seres humanos interagem. Seres humanos vivem em ambientes que lhes
so significativos. Esses ambientes so formados por entidades (objetos) que
combinam todos os tipos de caractersticas objetivas, incluindo aquelas
determinadas culturalmente, e que por sua vez influenciam as formas como as
pessoas agem sobre essas entidades. Em qualquer atividade que se realiza,
defronta-se com objetos do mundo real, que de alguma forma influenciam
nossa maneira de executar atividades.
(3) Princpio da estrutura hierrquica da atividade.
A Teoria da Atividade diferencia os procedimentos humanos em trs nveis:
atividade, ao e operao, levando em conta os objetivos para os quais estes
procedimentos so orientados. A atividade orientada a motivos, a ao
orientada a metas e a operao orientada a condies de realizao. Essa
diferenciao permite que uma mesma atividade possa ser analisada por
diferentes pontos de vista, levando em considerao a base sobre a qual a
anlise pretende ser realizada: motivos, metas ou condies.
(4) Princpio da internalizao-externalizao.
Esse princpio foca os mecanismos bsicos de origem dos processos mentais.
Declara que processos mentais so derivados das aes externas5 atravs do
curso da internalizao. A internalizao o termo usado para descrever a
converso de processos e objetos materiais externos para processos
executados no plano mental, ou ainda, no plano da conscincia. A
internalizao ocorre a partir do contato com o ambiente em que a pessoa est
inserida. A externalizao o processo inverso da internalizao, onde os
processos mentais manifestam-se por meio de atos, de tal forma que possam
ser verificados e corrigidos se necessrio.
(5) Princpio da mediao.
5
Na Teoria da Atividade h uma diferenciao importante entre elementos externos ao plano mental e
internos ao plano mental. Estes elementos podem ser aes, processos, objetos etc.
A atividade humana mediada por ferramentas, tanto externas (como um

machado ou um computador) quanto internas (como uma heurstica ou um
conceito). As ferramentas so veculos da experincia social e do
conhecimento cultural. Uma questo importante que permeia esse conceito
no o fato de que com o uso de uma ferramenta uma atividade possa ser
executada de maneira mais facilitada ou menos custosa, mas sim o fato de
que, na verdade, uma nova atividade criada quando passa-se a utilizar um
instrumento de mediao.
(6) Princpio do desenvolvimento.
De acordo com a Teoria da Atividade, entender um fenmeno significa
conhecer como este se desenvolveu, at sua forma atual, pois ao longo do
tempo
sofre
alteraes.
Compreender
essas
alteraes
auxilia
no
entendimento do seu estado atual. Esse conceito remete idia de que a

atividade humana dinmica, alterando-se e transformando-se ao longo da
evoluo humana. Esses princpios no so idias isoladas, esto intimamente
ligados. A natureza da Teoria da Atividade manifestada nesse conjunto de
princpios.
A Teoria da Atividade composta de elementos em nvel individual, social,
nveis hierrquicos da atividade e de alguns princpios. Baseada na Teoria da
Atividade, a META foi desenvolvida para auxliar a fase de elicitao de
requisitos. O prximo captulo apresenta uma viso geral das etapas e
procedimentos da META.
4. UMA METODOLOGIA DE ELICITAO

NA TEORIA DA ATIVIDADE
Esta metodologia
DE
REQUISITOS
DE
SOFTWARE BASEADA
de elicitao de requisitos proposta por Martins (2001),
divide-se em trs etapas principais, seguidas de procedimentos que auxiliam

na identificao e descrio das atividades. A cada etapa desenvolvida,
seguida das sub-etapas, os requisitos tornam-se mais claros e a elicitao de
requisitos vai se desenvolvendo gradativamente (Vide tabela 02). A interao e
seqncia dessas atividades um fator importante para esta metodologia
(Figuras 10, 11, 12 e 13).
Tabela 2 Principais etapas da Metodologia de Elicitao de Requisitos de
Software Baseada na Teoria da Atividade.
Principais Etapas
1 Etapa
2 Etapa
3 Etapa
Diviso do problema em Delineamento do contexto Descrio
da
estrutura
atividades (unidades de das atividades (para cada hierrquica das atividades
elicitao de requisitos).
atividade).
(para cada atividade).
Procedimentos
1.1 Levantar atividades

candidatas;
1.2 Selecionar atividades;
1.3 Descrever histrico
das atividades
selecionadas;
2.1 Identificar os motivos

e resultados da
atividade;
2.2 Identificar os
elementos no nvel
individual;
2.3 Identificar os
elementos no nvel
social;
2.4
Modelar a atividade
atravs do diagrama
de Engestrm;
3.1 Identificar as aes e

operaes da
atividade;
3.2 Descrever as metas
das aes;
3.3 Descrever as
condies de
realizao das
operaes;
Figura 10 Etapas da metodologia de elicitao proposta (MARTINS, 2001).
Figura 11 Decomposio da Etapa Diviso do problema em atividade

(MARTINS, 2001).
Figura 12 Decomposio da etapa Delineamento do contexto da atividade

(MARTINS, 2001).
Figura 13 Decomposio da etapa Descrio da estrutura hierrquica da

atividade (MARTINS, 2001).
4.1. DEFINIO
DOS
PRINCIPAIS CONCEITOS RELATIVOS ATIVIDADE
Para uma organizao da metodologia, Martins (2001) classifica os conceitos

da Teoria da Atividade em dois grupos:
Tabela 3 Grupos dos conceitos relativos Atividade.
Conceitos Relativos Estrutura
Hierrquica da Atividade
Atividade
Motivo
Ao
Meta
Operao
Condies
Conceitos Relativos aos Elementos

que Formam o Contexto da Atividade
Sujeito
Objeto
Ferramenta:
Tcnica
e
Psicolgica
Comunidade
Regras
Diviso do Trabalho
Resultado
Para cada conceito da Teoria da Atividade foi apresentada uma caracterizao

geral, uma definio objetiva e sua importncia, sendo apresentada uma
definio particular a cada conceito.
Neste trabalho ser apresentado de forma objetiva cada conceito e definio
apresentados por Martins (2001).
4.2. Conceitos Relativos Estrutura Hierrquica da Atividade
fundamental a compreenso entre os nveis hierrquicos existentes em uma

atividade, pois nesta estrutura nota-se a existncia do relacionamento e o
funcionamento dos elementos contidos na estrutura hierrquica da atividade
(MARTINS, 2001).
1 - Atividade
Definio 1 {Atividade}: atividade uma unidade de elicitao de requisitos
que oferece um contexto mnimo para o entendimento de um conjunto de
aes cooperantes que agem sobre um ou mais objetos, transformando-os
num resultado.
2 Motivo.
Definio 2 {Motivo}: a razo que orienta a atividade, expresso em termos de
desejos ou necessidades humanas.
3 Ao.
Definio 3 {Ao}: uma ao um passo consciente realizado com o
inteno de se atingir uma meta bem definida no contexto da atividade.
4 Meta.
Definio 4 {Meta}: meta um objetivo imediato a ser atingido por uma ao.
5 Operao.
Definio 5 {Operao}: operao uma ao que se tornou rotineira no

contexto da atividade, de tal forma que realizada de forma automtica pelo
sujeito.
6 Condies.
Definio 6 {Condies}: conjunto de variveis que possuindo um determinado
estado habilita a execuo de uma operao.
4.3. CONCEITOS RELATIVOS AOS ELEMENTOS QUE FORMAM O CONTEXTO DA ATIVIDADE
Os elementos deste grupo so fundamentais na compreenso de seu contexto
tanto em nvel individual como social.
7 Sujeito.
Definio 7 {Sujeito}: agente que transforma o objeto da atividade por meio da
execuo de aes e operaes.
8 Objeto.
Definio 8 {Objeto}: algo material ou abstrato, que pode ser compartilhado
pelos participantes da atividade.
9 Ferramenta.
Definio 9 {Ferramenta Tcnica}: um artefato fsico de mediao utilizado
pelo sujeito na transformao de um objeto.
Definio 10 {Ferramenta Psicolgica}: um artefato abstrato de mediao
utilizado pelo sujeito para visualizar, comunicar ou representar conceito.
11 Comunidade.
Definio 11 {Comunidade}: conjunto formado por sujeitos que influenciam na
transformao do objeto da atividade.
12 Regras.
Definio 12 {Regras}: conjunto de normas e procedimentos dentro de uma

comunidade, que um sujeito deve atender durante a realizao de uma
atividade.
13 Diviso do Trabalho.
Definio 13 {Diviso do Trabalho}: conjunto de papis e responsabilidades
que os sujeitos assumem dentro de uma comunidade durante a realizao de
uma atividade.
14 Resultado.
Definio 14 {Resultado}: produto final do processo de transformao inerente
atividade.
4.4. RELACIONAMENTO ENTRE OS CONCEITOS ENVOLVIDOS NA ATIVIDADE.

Martins (2001) apresenta o relacionamento existente entre os elementos da
atividade. Uma viso pictrica desses relacionamentos oferecida atravs do
diagrama de classe, conforme padronizao da UML.
A Figura 14 apresenta o relacionamento existente entre os elementos que
formam a estrutura hierrquica da atividade.
Figura 14 Relacionamento entre os elementos que formam a estrutura

hierrquica da atividade (MARTINS, 2001).
Observa-se que a atividade uma agregao de aes. Uma ao agrega

outras aes e aes agregam operaes. Toda atividade possui pelo menos
um motivo, e estes por sua vez orientam as metas estabelecidas das aes de
cada atividade. Um motivo est associado a apenas uma atividade. Uma meta
est associada a apenas uma ao. Toda ao possui pelo menos uma meta
que orientada pelo menos por um motivo. Uma operao pode atender de
uma a muitas condies e uma condio pode definir o estado de execuo de
vrias operaes.
A Figura 15 apresenta o relacionamento entre os elementos que formam o
contexto da atividade.
Figura 15 Relacionamento entre os elementos que formam o contexto da

atividade (MARTINS, 2001).
Nota-se que a maioria dos elementos relaciona-se com multiplicidade de

muitos para muitos, o que denota o grau de complexidade nas relaes
existentes entre estes elementos. tambm observado na figura 15 que uma
atividade pode ser realizada por vrios sujeitos. Um mesmo sujeito pode
participar de vrias atividades. Um sujeito durante a realizao da atividade
pode utilizar vrias ferramentas de mediao (especializadas em ferramentas
tcnicas e psicolgicas). Uma ferramenta pode ser utilizada por vrios sujeitos.
O sujeito utiliza as ferramentas para transformar os objetos da atividade. Uma
ferramenta pode atuar sobre vrios objetos, que por sua vez podem receber a
atuao de vrias ferramentas. Um objeto transformado em um ou mais
resultados, que podem ser resultantes de mais de um objeto transformado. Um
sujeito pode pertencer a mais de uma comunidade, que formada por vrios
sujeitos. A comunidade regulada por vrias regras e possui uma diviso do
trabalho (a diviso do trabalho assume o papel de um conjunto de
responsabilidades dentro da comunidade).
4.5. DESCRIO DAS ETAPAS
Para cada etapa da metodologia apresentada por Martins (2001), ser

brevemente mencionado nesta seo nas Tabelas 4, 5 e 6, como se realiza o
encadeamento entre as etapas, os procedimentos particulares a cada etapa e
as definies e princpios da Teoria da Atividade, enfatizando cada
procedimento adotado.
Tabela 4 Descrio da 1 Etapa da Teoria da Atividade.
1 Etapa
Diviso do problema em Para Marx e Engels, trabalho a forma bsica /
atividades (unidades de fundamental de atividade humana. De acordo com o
elicitao de requisitos) princpio (1) da Teoria da Atividade a conscincia
realizadas no contexto humana abastecida pelas atividades realizadas
do sistema.
pelas pessoas e a formao dos processos mentais

tem sua gnese na realizao das atividades. Assim
organizar os problemas em atividades dar uma

primeira viso do ambiente do sistema em que se
encontra inserido o sujeito e as diversas tarefas
existentes dentro de um contexto organizacional. As
tarefas podem ter status de atividade, ao ou
operao, onde a atividade a tarefa de maior
Levantar atividades
granularidade, seguida de ao e operao.

Em um primeiro contato com o ambiente fica difcil
candidatas.
identificar
quais
so
as
principais
atividades
desenvolvidas pelos agentes envolvidos. Mas fazendo

uso da definio (1), podemos realizar um primeiro
levantamento
de
possveis
atividades
que
so
realizadas pelos agentes envolvidos (possivelmente

usurios do futuro sistema de software), mas ainda
sem a preocupao de uma classificao precisa das
Selecionar atividades.
tarefas como atividade, ao ou operao.

Nesta etapa faz-se uma classificao das tarefas
anteriormente levantadas como atividades. Para isto,
devemos fazer uso das definies (1) (3) e (5), pois as

1 Etapa
mesmas auxiliam na avaliao da granularidade das

tarefas em atividades, aes ou operaes. A
classificao das tarefas como atividades, aes ou
operaes se baseia no princpio (3) da Teoria da
Atividade. Aps essa classificao cada atividade
passa a ser vista como uma unidade de elicitao dos
Descrever histrico das
requisitos.
De acordo com o princpio (6) da Teoria da Atividade
atividades selecionadas.
entender um fenmeno significa conhecer como ele

se desenvolveu at sua forma atual. Nesta etapa ser
levantado
todo
histrico
das
atividades
selecionadas, compreendendo desde sua origem,

comportamento e quais foram os aspectos originais
que deram o surgimento da atividade. A compreenso
do histrico de cada atividade mais tarde poder
auxiliar nas mudanas dos processos existentes no
contexto organizacional, facilitando as rotinas dos
agentes envolvidos.

2 Etapa
Delineamento
do
Nesta fase, aps definidas as atividades, com base
contexto das atividades na Teoria da Atividade ser delineado o contexto de

(para cada atividade).
cada uma delas. A necessidade de delinear o

contexto da atividade atravs dos elementos (motivos,
resultados,
sujeitos,
(Tcnicas
ferramentas
Psicolgicas),
de
mediao
objetos,
regras,
comunidade e diviso do trabalho) baseia-se nos
Identificar os motivos e
princpios (2) e (5) da Teoria da Atividade.

De acordo com Martins, conforme apresentado na
resultados da atividade.
definio (2) um motivo expresso atravs de

desejos
necessidades
humanas,
os
quais
consideramos ser o ponto de partida da atividade.

2 Etapa
Por sua vez o resultado da atividade, conforme

apresentado na definio (14), o produto final do
processo de transformao embutido na atividade, o
qual consideramos como o ponto de chegada da
atividade. Identificando esses dois pontos, fica claro
Identificar os elementos
o tamanho que cada atividade apresenta.

Neste momento ser analisada a atividade em nvel
no nvel individual.
individual, auxiliando na identificao inicial dos

elementos bsicos da atividade (sujeito, objeto e
ferramenta de mediao tcnica ou psicolgica).
De acordo com a definio (7) o sujeito o
responsvel
pela
transformao
do
objeto
da
atividade em um resultado, atravs da execuo de

aes e operaes. O sujeito o principal agente que
atua diretamente sobre o objeto. Pela definio (8)
tem-se
que o objeto da atividade pode ser algo
material ou abstrato, e que compartilhado pelos

participantes da atividade (sujeitos e comunidade).
Conforme
apresentado
na
definio
(9)
uma
ferramenta tcnica um artefato fsico de mediao

utilizado pelo sujeito na transformao do objeto.
Todo sujeito atua sobre o objeto atravs de uma
ferramenta de mediao e pela definio (10) uma
ferramenta
psicolgica
um
artefato
abstrato
utilizado pelo sujeito para visualizar, comunicar ou
Identificar os elementos
representar conceitos.
Nesta fase o principal elemento a ser identificado a
no nvel social.
comunidade na qual o sujeito da atividade est

inserido. Para identificar uma comunidade, Martins
(2001), utilizou da definio (11), que declara que
uma comunidade formada pelos sujeitos que de
alguma forma influenciam o objeto (ou objetos) da
atividade e baseados nas definies (12) e (13)
parte-

2 Etapa
se para a descrio das regras que regulam a

comunidade em questo e para a descrio da
diviso
do
trabalho
componentes.
Os
existentes
entre
relacionamentos
os
seus
comunidade-
sujeito e comunidade-objeto so mediados por regras

e diviso do trabalho. A identificao das regras e da
diviso do trabalho contribuir na identificao das
aes e operaes executadas pelos sujeito da
atividade no qual seu comportamento regulado
pelas regras e atribuies dentro da comunidade
Modelar a atividade
atuante.
O diagrama de Engestrm, apresentado na Figura 16,
atravs do diagrama de
foi adotado para modelagem dos principais elementos
Engestrm.
da atividade como sujeito, ferramenta de mediao,

objeto, regras, comunidade, diviso do trabalho e
resultado da atividade. Martins (2001), destaca dois
tipos
de
elementos
relacionamentos
da
existentes
atividade,
entre
denominados
os
de
relacionamento intrnseco e relacionamento mediado

(Vide Figura 16). Entre o sujeito, objeto e comunidade
ocorre o relacionamento intrnseco (linhas pontilhadas)
e estes elementos somente se relacionam atravs da
mediao por uma ferramenta, regras e diviso do
trabalho
(linhas
relacionamento
slidas).
intrnseco
materializao
garantido
relacionamento mediado.
Ferramenta
Sujeito
Objeto
Transformao
Resultado
do
pelo
Regras
Comunidade
Diviso de
Trabalho
Figura 16 Tipos de relacionamento representados no diagrama de

Engestrm.

3 Etapa
Descrio da estrutura De acordo com princpio (3) da Teoria da Atividade, a
das atividade ser dividida em trs nveis hierrquicos:
hierrquica
atividades
(para
cada atividade, ao e operao. Identificando a ao e
atividade).
operao dentro do contexto da atividade ajudar na

compreenso de seus funcionamentos.
Identificar as aes e
De acordo com a definio (3) uma ao um passo
operaes da atividade.
consciente realizado (pelo sujeito da atividade) com a

inteno de se atingir uma meta bem definida no
contexto da atividade, e a definio (5) declara que
uma operao uma ao que se tornou rotineira no
contexto da atividade, de tal forma que ela
realizada de forma automtica pelo sujeito. O objetivo
desta etapa identificar nas atividades as tarefas
realizadas de forma consciente e no consciente,
pelo sujeito durante a execuo da tarefa.
Descrever as metas das Com base na definio (4), uma meta um objetivo
aes.
imediato a ser atingido por uma ao. Descrever as

metas das aes auxilia no entendimento das aes

3 Etapa
que o sujeito realiza, e assim que as metas vo sendo
alcanadas, os resultados das atividades vo sendo

atingidos.
Descrever as condies
Segundo a definio (6), as condies para a
de realizao das
realizao de uma operao so formadas por um
operaes.
conjunto de variveis que possuindo um determinado

estado determina a execuo de uma operao. As
condies de operao quando reconhecidas pelo
sujeito, so executas de forma automtica a partir
do momento em que as condies mudam, a
operao deixa de ser automtica e retorna ao nvel
de ao. necessrio o registro de todo o histrico
do funcionamento da operao e a maneira como
realizada, para posterior anlise de comportamento
dentro do contexto onde se realiza a atividade.
A Tabela 7 apresenta a META com suas respectivas etapas, procedimentos,

definies e princpios.
Tabela 7 - Definies e princpios da Teoria da Atividade utilizados em cada

etapa da metodologia.
Etapas
Procedimentos
Definie
s
(1)
1.1 Levantar atividades candidatas
1. Diviso do
problema em
atividades
1.2 Selecionar Atividades
do contexto
das atividades
3. Descrio da
estrutura
hierrquica
(1)
(1,2,5)
(3)
(6)
(2,14)
(2)
Atividade
2.2 Identificar os elementos no nvel
(7,8,9,10)
(2,5)
individual
2.3 Identificar os elementos no nvel social
(11,12,13)
(2,5)
(7,8,9,10,
11,12,13)
(5)
(3,5)
(3)
(4)
(3)
1.3 Descrever histrico das atividades

selecionadas
2.1 Identificar os motivos e resultados da
2. Delineamento
Princpios
2.4 Modelar a atividade atravs do

diagrama de Engestrm
3.1 Identificar as aes e operaes da
atividade
3.2 Descrever as metas das aes
das atividades
Aps a contextualizao da Metodologia de Elicitao de Requisitos de

Software baseada na Teoria da Atividade, a seo 4.6, a seguir, apresentar
um exemplo da sua aplicabilidade em um controle de recebimentos telefnicos
de clientes em uma empresa6.
4.6. EXEMPLO
UTILIZANDO A
META
PARA UM
SOFTWARE
DE
CONTROLE
DE
CHAMADAS
TELEFNICAS.
A empresa neste contexto no tem um segmento especfico, esta citada de um modo geral como auxlio
no exemplo ora apresentado.
O exemplo apresentado neste tpico referente a elicitao de requisitos para

um software que dever controlar o recebimento das chamadas telefnicas de
um servio de atendimento a clientes.
4.6.1. DESCRIO INICIAL DO PROBLEMA
Uma empresa deseja controlar o atendimento a clientes via chamadas
telefnicas. Para qualquer cliente que ligar deve ser criado um protocolo que
registre sua chamada. A telefonista que recebe o chamado gera um nmero de
protocolo e preenche os campos do quadro de registro do protocolo (conforme
Figura 17).
(1) Protocolo
n ______________ (2) Nome: ___________________________

(3) Numero Telefone:
______________________________________________
(4)
Assunto:______________________________________________________
(5) Data de Recebimento da Chamada: _______________________________
Figura 17 - Documento de registro do protocolo das chamadas telefnicas.
Os campos apresentados no quadro de registro do protocolo tm o seguinte

significado:
1. Nmero do protocolo
2. Nome do cliente
3. Nmero do Telefone
4. Assunto
5. Data de Recebimento da Chamada
Essas informaes so anotadas registrando os dados dos clientes que fazem

uma chamada telefnica empresa. No momento que o cliente realizada uma
chamada, esses dados so registrados e, a cada semana, esses documentos
com os dados dos clientes que realizaram uma chamada so entregues ao
gerente responsvel pelo departamento que realizar outra atividade
operacional utilizando esses dados.
A seguir cada etapa da Metodologia de Elicitao de Requisitos de Software

Baseada na Teoria da Atividade (vide tabela 7) ser aplicada ao estudo de
caso, apresentando os resultados obtidos nas mesmas.
1. Diviso do problema em atividades realizadas no contexto do sistema

A primeira etapa do processo de elicitao a diviso do problema em
unidades de elicitao de requisitos.
1.1 Levantamento das Atividades Candidatas
A partir das entrevistas realizadas com as telefonistas e baseando-se na
definio (1) da metodologia, foram levantadas inicialmente as seguintes
tarefas como atividades candidatas:
Criar protocolo;
Preencher documento de registro da chamada;
Consultar protocolo por data.
1.2 Seleo das Atividades

As atividades levantadas inicialmente passaram por uma anlise mais
detalhada, pois as mesmas foram confrontadas com as definies (1) (3) e (5)
buscando identificar se as atividades abrangiam aes e/ou operaes
relevantes do problema descrito. Como resultado desse procedimento
selecionaram-se duas atividades:
Criar protocolo;
Consultar protocolo por data;
A tarefa Preencher documento de registro da chamada foi desconsiderada

como atividade pois realizada dentro do contexto das atividades
selecionadas e, portanto, dever ser tratada como ao ou operao
(Analisada na etapa 3).
1.3 Descrio do histrico de cada atividade selecionada

Um levantamento sobre a evoluo histrica de cada atividade proporciona
uma viso dinmica auxiliando no entendimento do porqu a atividade est
sendo realizada dessa forma, no momento atual.
Conforme apresentado na Tabela 8, foram levantados dados histricos do
desenvolvimento de cada atividade para melhor compreenso das atividades
selecionadas neste exemplo.
Tabela 8 Descrio do Histrico das Atividades.
Atividade
s
Histrico
Criar protocolo
Consultar Protocolo por data
O departamento de recebimento
de chamadas deu incio ao
controle, de forma
independente. Cada telefonista
tinha seu prprio controle.
As telefonistas possuam um
documento independente, com
diferentes campos de
anotaes.
A padronizao do documento
com n de protocolo controlando
partiu do gerente responsvel
pelo departamento de
recebimento de chamada.
Dificilmente esta consulta

teria sucesso, pois a
desorganizao dos registros
fazia com que muitas
chamadas fossem
registradas, porm sem
nmero de protocolo e data
de recebimento da chamada.
2. Delineamento do contexto de cada atividade

Aps a diviso do problema em unidades de elicitao, que so as atividades,
delineou-se o contexto de cada atividade selecionada. Nesta etapa fez-se uso
das definies (2) (7) (8) (9) (10) (11) (12) (13) e (14), conforme apresentadas
na metodologia.
2.1 Identificao dos motivos e resultados da atividade
Conforme descrito na Tabela 7, para cada atividade foram identificados os

motivos e resultados esperados. As definies (2) e (14) foram utilizadas na
identificao desses elementos da atividade.
Tabela 9 Descrio dos Motivos e Resultados das Atividades.
Atividades
Motivos
Resultado
Criar Protocolo
Necessidade de controle das
chamadas telefnicas;
Necessidade de saber qual o
motivo (Assunto) da ligao;
Necessidade de manter os
clientes sempre bem atendidos e
satisfeitos com o produto;
Protocolo realizado;
Consultar Protocolo
por Data
Necessidade de
resgatar uma
Informao e ter como
parmetro o intervalo
de tempo para tomada
de deciso;
Localizao do
documento
pesquisado;
2.2 Identificao dos elementos das atividades no nvel individual

Na identificao dos sujeitos, ferramenta (tcnicas e psicolgicas) e objeto das
atividades, as definies (8) (9) (10) e (11) foram utilizadas, conforme descrito
no Tabela 10.
Tabela 10 Descrio dos elementos das atividades no nvel individual.
Criar Protocolo
Sujeito
Ferramenta
Tcnica
Ferramenta
Psicolgica
Objeto
Consultar Protocolo por

Data
Telefonista
Caneta
Gerente
Nenhuma
Capacidade de Escrita
Capacidade de Leitura
Documento de Registro da
Chamada
- Documento de Registro da
Chamada
- Linha de Datas Registrada
2.3 Identificao dos elementos da atividade no nvel social

Para identificar os elementos comunidade, regras e diviso do trabalho das
atividades, ou seja, os elementos do nvel social, foram utilizadas as definies
(12) (13) e (14), descritas na Tabela 11.
Tabela 11 Descrio dos elementos das atividades no nvel social.

Criar Protocolo
Comunidade
Regras
Diviso do
Trabalho
Telefonistas
Gerente
Clientes
O novo nmero gerado deve
ser igual ao nmero do
ltimo protocolo mais um;
As telefonistas so
responsveis pelo
atendimento das
chamadas gerando
nmeros de protocolos
a cada ligao;
O gerente
responsvel pelas
decises a serem
tomada;
Os clientes efetuam as
chamadas;
Consultar Protocolo por

Data
Telefonistas
Gerente
Clientes
Deve ser informada data de
recebimento da chamada,
que ser utilizada para
analisar as chamada
telefnicas de cada cliente.
As telefonistas so
responsveis pelo
registro da data de
chamada no
documento;
O gerente
responsvel pela busca
das datas para
possveis solues dos
problemas;
Os clientes solicitam
respostas aos assuntos
registrados;
2.4 Modelagem das atividades atravs do diagrama de Engestrm

Aps a identificao e descrio de todos os elementos da atividade, tanto no
nvel individual como no nvel social, os relacionamentos existentes entre os
elementos que definem o contexto da atividade sero apresentados.
Nas Figuras 18 e 19 sero apresentadas as modelagens das atividades
descritas nas sees anteriores, atravs do diagrama de Engestrm, conforme
sugerido na metodologia de Elicitao de Requisitos de Software Baseada na
Teoria da Atividade.
Caneta
Capacidade de escrita
Documento
de Registro
da Chamada.
Telefonista
Regras para
Criao do
Protocolo
Protocolo
realizado
Diviso do trabalho
entre Telefonistas e Gerente
Telefonistas
Clientes
Gerente
Figura 18 - Modelo sistmico para a atividade Criar Protocolo.
Capacidade de Leitura
Documento de
registro da
chamada,
Linha de Datas
Registrada
Gerente
Regras para
Consulta do
Protocolo por Data
Localizao
do documento
pesquisado
Diviso do trabalho
entre Telefonistas e Gerente
Telefonistas
Clientes
Gerente
Figura 19 - Modelo sistmico para a atividade Consultar Protocolo por Data.
3. Descrio da estrutura hierrquica de cada atividade

Com base nas definies (3) (4) (5) e (6), ser descrita a estrutura hierrquica
das atividades, ou seja, as aes e operaes que compem as atividades e
suas respectivas metas e condies de realizao.
3.1 Identificao das aes e operaes da atividade
Na Tabela 12 est apresentada a decomposio das atividades em aes e
operaes.
Tabela 12 Descrio das aes e operaes da atividade.
Atividades
Aes
Criar Protocolo
Gerar nmero do
protocolo;
Consultar Protocolo
por Data
Encontrar
protocolos
baseados em um
intervalo de tempo;
Operaes
Verificar nmero do ltimo
protocolo;
Adicionar um ao nmero do
ltimo protocolo;
Preencher campo de "nmero
do protocolo"(1);
Especificar data para consulta;
Buscar nmeros de protocolos
de acordo com a data
especificada;
Informar protocolos
encontrados;
3.2 Descrio das metas das aes

Com base na definio (3), toda ao tem a inteno de atingir uma ou mais
metas bem definidas no contexto da atividade. Na Tabela 13 esto
apresentadas as metas das aes que compem as atividades selecionadas.
Tabela 13 Descrio das metas das aes.
Atividades
Aes
Metas
Criar Protocolo
Gerar nmero do protocolo;
Consultar Protocolo
por Data
Encontrar protocolos
baseados em um intervalo
de tempo;
Criar uma identificao

para o documento que est
sendo protocolado;
Buscar quadros de registro
de protocolos cujas datas
estejam no intervalo de
tempo especificado;
3.3 Descrio das condies de realizao das operaes

Na Tabela 14 esto descritas as condies de execuo das operaes
identificadas neste exemplo. De acordo com as definies (5) e (6) uma
operao executada dependendo das condies existentes no momento de
sua execuo. Assim, importante descrever todas as condies de execuo
das operaes que compem as atividades selecionadas.
Tabela 14 Descrio das condies de realizao das operaes de cada
atividade.
Atividades Aes
Operaes
Criar
Protocolo
Verificar nmero do
ltimo protocolo;
Consultar
Protocolo
por Data
Gerar nmero do
protocolo.
Encontrar
protocolos
baseados em um
intervalo de
tempo.
Condies de
Realizao
- Adicionar um ao
nmero do ltimo
protocolo;
- Ter acesso ao
documento de registro
de protocolo das
chamadas;
Ter disponvel o ltimo
nmero de protocolo
criado;
- Preencher campo de
"nmero do
protocolo"(1) ;
Ter disponvel o novo

nmero de protocolo
gerado;
-Especificar data para

consulta;
Ter a data de
recebimento do
documento disponvel;
Buscar nmeros de
protocolos de acordo
com a data
especificada;
Ter acesso ao
documento de
chamadas ;
-Informar protocolos
encontrados;
Chegar a um resultado
para a consulta;
Neste exemplo temos uma viso geral do processo de elicitao de requisitos

organizado em atividades baseado nos princpios e conceitos da Teoria da
Atividade.
Com a reviso bibliogrfica da META e um exemplo didtico de sua
aplicabilidade, tem-se uma compreenso melhor do contexto em que a
ferramenta atuara. O prximo captulo referente a elicitao de requisitos,
modelagem lgica, arquitetura das classes implementadas da ferramenta,
representao fsica do banco de dados e apresentao de alguns exemplos
das interfaces da ferramenta.
5. FERRAMENTA DE APOIO ELICITAO DE REQUISITOS UTILIZANDO A META
5.1.ELICITAO DE REQUISITOS DA FERRAMENTA

Foi realizada a elicitao de requisitos, como processo da ER com a prpria
META, na compreenso do ambiente que a ferramenta auxiliar. A META
apresenta uma seqncia de processos a serem desenvolvidos com a
finalidade de elicitar os requisitos de forma orientada e seqencial
(FRANCETO, 2004). O processo foi realizado em trs etapas: a) Diviso do
Problema em Atividades; b) Delineamento do Contexto em Atividades; e c)
Descrio da Estrutura das Atividades.
a) Diviso do Problema em Atividades (1a Etapa)
A tarefa na primeira etapa da metodologia organizar os problemas em
atividades. Isto dar uma primeira viso do ambiente do sistema em que se
encontra inserido o sujeito (ator envolvido na atividade) e as diversas tarefas
existentes dentro de um contexto organizacional. Trs so os procedimentos
envolvidos:
1. Levantar as atividades candidatas;
2. Selecionar atividades ;
3. Descrever histrico das atividades selecionadas;
A seguir, so apresentados os resultados desses procedimentos.
1 - Levantar atividades candidatas
Dividir o problema em atividades;
Levantar atividades candidatas;
Selecionar atividades;
Descrever histrico das atividades selecionadas;
Delinear o contexto das atividades;
Identificar os motivos e resultados da atividade;
Identificar os elementos no nvel individual;
Identificar os elementos no nvel social;
Modelar a atividade atravs do diagrama de Engestrm;
Descrever a estrutura hierrquica das atividades;
Identificar as aes e operaes da atividade;
Descrever as metas das aes;
Descrever as condies de realizao das operaes;
2 - Selecionar atividades
{A1}
Levantar atividades candidatas;
{A2}
{A3}
{A4}
{A5}
{A6}
{A7}
{A8}
{A9}
Descrever as metas das aes;
{A10} Descrever as condies de realizao das operaes;

3 - Descrever histrico das atividades selecionadas
Tabela 15 Descrio do Histrico das Atividades Selecionadas.
Atividades
Histrico
{A1}
Levantar
candidatas;
atividades Com a utilizao da definio (1), pode-se realizar um primeiro
levantamento de possveis atividades que so realizadas pelos

agentes envolvidos (possivelmente usurios do futuro sistema de
software), mas ainda sem a preocupao de uma classificao
precisa das tarefas como atividade, ao ou operao.
Faz-se uma classificao das tarefas anteriormente levantadas
{A2} Selecionar atividades;
como atividades utilizando-se as definies (1,3,5), pois auxiliam
na avaliao da granularidade das tarefas, classificando-as em
atividades, aes ou operaes. A classificao das tarefas como
atividades, aes ou operaes baseia-se no princpio (3) da
Teoria da Atividade. Aps essa classificao cada atividade passa
a ser vista como uma unidade de elicitao dos requisitos.
{A3} Descrever histrico das De acordo com o princpio (6) da Teoria da Atividade entender um
fenmeno significa conhecer como ele se desenvolveu at sua
atividades selecionadas;
forma atual. Nesse procedimento ser levantado todo o histrico

Atividades
{A4} Identificar os motivos e

resultados da atividade;
{A5} Identificar os elementos

no nvel individual;
{A6} Identificar os elementos

no nvel social;
{A7} Modelar a atividade

atravs do diagrama de
Engestrom;
Histrico
das atividades selecionadas, compreendendo desde sua origem o
comportamento e quais foram os aspectos originais que deram o
surgimento da atividade. A compreenso do histrico da atividade,
mais tarde auxiliar nas mudanas dos processos existentes no
contexto organizacional, facilitando as rotinas dos agentes
envolvidos.
Conforme a definio (2), um motivo expresso atravs de
desejos e necessidades humanas, os quais considera-se como o
ponto de partida da atividade. Por sua vez o resultado da
atividade, conforme definio (14), o produto final do processo
de transformao embutido na atividade, o qual considera-se
como o ponto de chegada da atividade. Identificando estes dois
pontos, fica claro o tamanho que cada atividade apresenta.
Este procedimento auxilia a identificao inicial dos elementos
bsicos da atividade (sujeito, objeto e ferramenta de mediao
tcnica ou psicolgica). Conforme definio (7), o sujeito o
responsvel pela transformao do objeto da atividade em um
resultado, atravs da execuo de aes e operaes. O sujeito
o principal agente que atua diretamente sobre o objeto. Pela
definio (8), tem-se que o objeto da atividade pode ser algo
material ou abstrato, e que compartilhado pelos participantes da
atividade (sujeitos e comunidade). Pela definio (9), uma
ferramenta tcnica um artefato fsico de mediao utilizado pelo
sujeito na transformao do objeto e, pela definio (10), uma
ferramenta psicolgica um artefato abstrato utilizado pelo sujeito
para visualizar, comunicar ou representar conceitos.
O principal elemento a ser identificado a comunidade em que o
sujeito da atividade est inserido. Para identificar uma
comunidade, Martins (2001), utilizou a definio (11), que declara
que uma comunidade formada pelos sujeitos que de alguma
forma influenciam o objeto (ou objetos) da atividade e, com base
nas definies (12,13) parte-se para a descrio das regras que
regulam a comunidade em questo e para a descrio da diviso
do trabalho existentes entre os seus componentes. Os
relacionamentos comunidade-sujeito e comunidade-objeto so
mediados por regras e diviso do trabalho. A identificao das
regras e da diviso do trabalho contribuir na identificao das
aes e operaes executadas pelos sujeitos da atividade, que
tero seus comportamentos regulados pelas regras e atribuies
dentro da comunidade atuante.
O diagrama de Engestrom foi adotado para modelagem dos
principais elementos da atividade como sujeito, ferramenta de
mediao, objeto, regras, comunidade, diviso do trabalho e
resultado da atividade. Entre sujeito, objeto e comunidade ocorre o
relacionamento intrnseco (linhas pontilhadas) e esses elementos
somente se relacionam atravs da mediao por uma ferramenta,
regras e diviso do trabalho (linhas slidas). A materializao do
relacionamento intrnseco garantida pelo relacionamento
mediado.
{A8} Identificar as aes e

operaes da atividade;
De acordo com a definio (3) uma ao um passo consciente

realizado (pelo sujeito da atividade) com a inteno de atingir uma
meta bem definida no contexto da atividade, e a definio (5)
declara que uma operao uma ao que se tornou rotineira no
contexto da atividade, de tal forma que realizada de forma
automtica pelo sujeito. Nessa etapa identificam-se nas atividades
as tarefas realizadas de forma consciente e no consciente, pelo
sujeito durante a execuo da tarefa.
{A9} Descrever as metas das Com base na definio (4), uma meta um objetivo imediato a ser
atingido por uma ao. Descrever as metas das aes auxilia no
aes;
entendimento das aes que o sujeito realiza, e assim que as
metas vo sendo alcanadas, os resultados das atividades vo
sendo atingidos.

Atividades
Histrico
{A10}Descrever as condies
de realizao das operaes;
Segundo a definio (6), as condies para a realizao de uma

operao so formadas por um conjunto de variveis, que
possuindo um determinado estado determina a execuo de uma
operao. As operaes so executadas de forma automtica, a
partir do momento que as condies da operao mudam, a
operao deixa de ser automtica e retorna ao nvel de ao.
necessrio o registro de todo o histrico do funcionamento da
operao e a maneira como realizada, para posterior anlise de
comportamento no contexto onde se realiza a atividade.
b) Delineamento do Contexto das Atividades (2a Etapa)

Na segunda etapa, aps definidas as atividades, delineado o contexto de
cada atividade. A necessidade de delinear o contexto da atividade atravs dos
elementos motivos, resultados, sujeitos, ferramentas de mediao (tcnicas e
psicolgicas), objetos, regras, comunidade e diviso do trabalho se baseiam
nos princpios (2) e (5) da Teoria da Atividade. Quatro so os procedimentos
envolvidos nesta etapa:
1. Identificar os motivos e resultados da atividade;
2. Identificar os elementos no nvel individual;
3. Identificar os elementos no nvel social;
4. Modelar a atividade atravs do diagrama de Engestrm
A seguir, so apresentados os resultados destes procedimentos.
1 - Identificar os motivos e resultados da atividade
Tabela 16 Descrio dos Motivos e Resultados das Atividades Selecionadas.
Atividades
Selecionadas
Motivos
Resultados
{A1} Levantar
candidatas;
atividades Necessidade de iniciar um Atividades Candidatas;

mapeamento das atividades do
ambiente em estudo;
Necessidade de conhecer as
atividades macro do ambiente;
{A2} Selecionar atividades;
Necessidade
de
filtrar
atividades
verificando
extenso;
as Atividades selecionadas;
sua
Necessidade
de
iniciar
o
processo de Elicitao a partir
das atividades selecionadas;
Tabela 16 Descrio dos Motivos e Resultados das Atividades

Selecionadas.
Atividades
Motivos
Resultados
Selecionadas
{A3} Descrever histrico

das
atividades
selecionadas;
{A4} Identificar os motivos
e resultados da atividade;
Necessidade de entender a Histrico

de
cada
atividade
origem e desenvolvimento de selecionada;
cada atividade selecionada;
Necessidade de conhecer o Descrio dos motivos e resultados
motivo que leva a realizao de de cada atividade selecionada;
cada atividade;
Necessidade de conhecer o
resultado final obtido atravs da
transformao de cada atividade
{A5}
Identificar
elementos
no
individual;
os Necessidade de saber quais

nvel elementos
(sujeito,
objeto,
ferramenta de mediao) esto
envolvidos em cada atividade;
{A6}
Identificar
os Necessidade de conhecer a
elementos no nvel social; atividade inserida no contexto no
nvel
social,
verificando
a
comunidade em que o sujeito
participa, quais so as regras e
diviso de trabalho;
{A7} Modelar a atividade Necessidade da visualizao dos
atravs do diagrama de principais
elementos
Engestrm;
identificados no contexto de cada
atividade;
{A8} Identificar as aes e Necessidade de conhecer todas
operaes da atividade;
as aes e operaes no
contexto de cada atividade;
{A9} Descrever as metas Necessidade de saber qual o
das aes;
objetivo imediato a ser atingido
por cada ao das atividades
levantadas;
{A10}Descrever
as Necessidade de verificar se as
condies de realizao condies de realizao de cada
das operaes;
operao
esto
sendo
reconhecidas pelo sujeito;
Elementos do nvel individual;
Elementos do nvel social;
Modelo sistmico dos elementos que

formam a atividade;
Descrio das aes e operaes de
cada atividade selecionada;
Metas de cada ao;
Condies
de
realizao
operaes de cada atividade;
das
2 - Identificar os elementos no nvel individual

Tabela 17 Descrio dos Elementos no Nvel Individual das Atividades
Selecionadas.
Atividades
Selecionadas
Sujeitos
{A1}
Levantar Analista
atividades
Requisitos
candidatas;
{A2}
Selecionar Analista
atividades;
Requisitos
Ferramentas
Tcnicas
Ferramentas
Psicolgicas
de Formulrio para Definio (1)

registro
das Princpio (1)
Informaes;
Editor de Texto;
de Formulrio para Definies (1,3,5)

registro
das Princpio (3)
Informaes;
Objetos
Domnio do Problema;
Informaes
contexto das
candidatas ;
Informaes
contexto das
selecionadas;
sobre o
atividades
sobre o
atividades
Editor de Texto;
{A3}
Descrever Analista
histrico
das Requisitos
atividades
selecionadas;
de Formulrio para Princpio (6)

registro
das
Informaes;
Informaes sobre o
contexto das atividades
selecionadas;
Editor de Texto;
de Formulrio para Definies (2,14)
registro
das Princpios (2)
Informaes;
Informaes sobre o
selecionadas;
{A5} Identificar os Analista

elementos no nvel Requisitos
individual;
Editor de Texto;
de Formulrio para Definies
registro
das (7,8,9,10)
Informaes;
Princpios (2,5)
Informaes sobre o
selecionadas;

elementos no nvel Requisitos
social;
Editor de Texto;
registro
das (11,12,13)
Princpios (2,5)
Informaes;
Informaes sobre o
selecionadas;

motivos
e Requisitos
resultados
da
atividade;
{A7}
Modelar
a Analista
atividade atravs do Requisitos
diagrama
de
Engestrm
Editor de Texto;
Informaes sobre o
registro
das (7,8,9,10,11,12,13 contexto das atividades
Informaes;
)
selecionadas;
Princpios (5)
Editor de Texto;
{A8} Identificar as Analista

aes e operaes Requisitos
da atividade;

registro
das Princpio (3)
Informaes;
Informaes sobre o
selecionadas
Editor de Texto;
{A9} Descrever as Analista
metas das aes;
Requisitos
{A10}Descrever as Analista
condies
de Requisitos
realizao
das
operaes;
de Formulrio para Definio (4)

registro
das Princpio (3)
Informaes;
Informaes sobre o
selecionadas;
Editor de Texto;
registro
das Princpio (3)
Informaes;
Informaes sobre o
selecionadas;
Editor de Texto;
3 - Identificar os elementos no nvel social

A primeira verso da ferramenta de apoio META, para a qual foi realizada a
elicitao de requisitos ora apresentada, foi um ambiente mono-usurio.
Assim, entendemos no haver elementos do nvel social a serem identificados.
4 - Modelar a atividade atravs do diagrama de Engestrm
Daremos
uma
ateno
especial
para
modelagem
das
atividades
selecionadas atravs do diagrama de Engestrm. Nas figuras a seguir,

observa-se o comportamento entre os elementos em nvel individual
representadas no diagrama de Engestrm. Cada figura est relacionada a uma
atividade selecionada apresentada na Tabela 3 pela identificao {An}.
Figura
Figura
2021
Estrutura
Estrutura
dada
atividade
atividade
{A{A
1} 2-} Levantar
Selecionar
Atividades
Atividades.
Candidatas.
Figura 22 Estrutura da a atividade {A3} Descrever Histrico das Atividades
Selecionadas.
Figura 24 Estrutura da atividade {A5} Identificar os Elementos no Nvel Individual.
Figura 26 Estrutura da atividade {A7} Modelar a Atividade atravs do Diagrama de

Engestrm.
Figura 23 Estrutura da a atividade {A4} Identificar os Motivos e Resultados da

Atividade.
Figura 25 Estrutura da atividade {A6} Identificar os Elementos no Nvel Social.
Figura 27 Estrutura da atividade A8 Identificar as Aes e Operaes da Atividade.
Figura 28 Estrutura da atividade A9 Descrever as Metas das Aes.
Figura 29 Estrutura da atividade {A10} Descrever as Condies de Realizao das

Operaes.
c) Descrio da Estrutura Hierrquica das Atividades (3a Etapa)

A terceira etapa da metodologia baseia-se no princpio (3) da Teoria da
Atividade, que divide a atividade em trs nveis hierrquicos: atividade, ao e
operao. Identificando a ao e operao no contexto da atividade ajudar na
compreenso de seu funcionamento. Os procedimentos envolvidos nesta
etapa so trs:
1. Identificar as aes e operaes da atividade;
2. Descrever as metas das aes;
3. Descrever as condies de realizao das operaes.
Na primeira e segunda etapa, a cada procedimento foi desenvolvida uma
tabela apresentando as informaes coletadas. Nesta terceira etapa foi
desenvolvida apenas uma tabela para os trs procedimentos com o objetivo de
auxiliar a visualizao das informaes.
Tabela 18 Descrio da Estrutura Hierrquica das Atividades.

Atividades
Selecionadas
{A1} Levantar
atividades
candidatas;
Aes
Analisar o contexto
do ambiente em
estudo;
Aplicar a definio
(1) da META;
Metas
Compreender
problema;
Operaes
o Preencher
campos
especficos da
Orientar a utilizao ferramenta da
da META no processo atividade {A1};
de elicitao;
Condies de
Realizao
Ter acesso aos

campos
especficos
da
atividade {A1};
Ter compreendido
o contexto do
problema;
{A2}
Selecionar
atividades;
Analisar o contexto
do ambiente em
estudo;
Utilizar as atividades
candidatas;
Aplicar
(1,3,5) ;
{A3}
Descrever
histrico
das
atividades
selecionadas;
{A4} Identificar os
motivos
e
resultados
da
atividade;
{A5} Identificar os
elementos
no
nvel individual;
o Preencher
campos
especficos da
Selecionar
as ferramenta da
atividades a partir das atividade {A2};
atividades candidatas;
definies Orientar a utilizao
da META no processo
de elicitao;
Analisar o contexto
do ambiente em
estudo;
selecionadas;
Compreender
problema;
Compreender
problema;
Manter a referncia e
a
seqncia
das
atividades
selecionadas durante
o desenvolvimento da
atividade {A3};
Aplicar o princpio (6) Orientar a utilizao
da META no processo
da META;
de elicitao;
Analisar o contexto Compreender
o
do ambiente em problema;
estudo;
Utilizar as atividades Manter a referncia e
a
seqncia
das
selecionadas;
atividades;
atividade {A4};
Aplicar a definio Orientar a utilizao
(2) e (14) da META; da META no processo
de elicitao;
Analisar o contexto Compreender
o
do ambiente em problema;
estudo;
Utilizar as atividades Manter a referncia e
a
seqncia
das
selecionadas;
atividades
atividade {A5};
Aplicar as definies Orientar a utilizao
(7,8,9,10) da META; da META no processo
de elicitao;
Ter acesso s
atividades
candidatas;
Ter compreendido
o contexto do
problema;
Ter acesso aos
campos
especficos
da
atividade {A2};
Preencher
Ter acesso s
campos
atividades
especficos da selecionadas;
ferramenta da Ter compreendido
atividade {A3};
o contexto do
problema;
Ter acesso aos
campos
especficos
da
atividade {A3};
Preencher
campos
especficos da
ferramenta da
atividade {A4};
Ter acesso s
atividades
selecionadas;
Ter
compreendido o
contexto
do
problema;
Ter acesso aos
campos
especficos da
atividade {A4};
Preencher
campos
especficos da
ferramenta da
atividade {A5};
Ter acesso s
atividades
selecionadas;
Ter
compreendido o
contexto
do
problema;
Ter acesso aos
campos
especficos da
atividade {A5};
Atividades
Selecionadas
{A6} Identificar os
elementos
no
nvel social;
Aes
Analisar o contexto
do ambiente em
estudo;
selecionadas;
Metas
Compreender
problema;
Operaes
a
seqncia
das
atividades
atividade {A6};
Aplicar as definies Orientar a utilizao
(11,12,13) da META; da META no processo
de elicitao;
Preencher
campos
especficos da
ferramenta da
atividade {A6};
Condies de
Realizao
Ter acesso s
atividades
selecionadas;
Ter
compreendido o
contexto
do
problema;
Ter acesso aos
campos
especficos da
atividade {A6};
{A7} Modelar a
atividade atravs
do diagrama de
Engestrm;
Analisar o contexto
do ambiente em
estudo;
selecionadas;
Utilizar os elementos
levantados no nvel
individual, social e os
resultados
identificados
para
modelar o diagrama;
{A8} Identificar as
aes
e
operaes
da
atividade;
Aplicar
as
definies
(7,8,9,10,11,12,13)
;
Analisar o contexto
do ambiente em
estudo.
selecionadas.
Compreender
problema;
a
seqncia
das
atividades
atividade {A7};
Visualizar
os
elementos com seus
respectivos
comportamentos
no
contexto
das
atividades
selecionadas;
Orientar a utilizao
da
META
no
processo
de
elicitao;
Compreender
problema.
a
seqncia
das
atividades
atividade {A8}.
(3,5) da META.
da META no processo
de elicitao.
Utilizar as atividades Manter a referncia e a
seqncia
das
selecionadas.
Modelar
de
acordo
com
figura
de
Engestrm;
Ter acesso s
atividades
selecionadas;
Ter
compreendido o
contexto
do
problema;
Ter acesso aos
elementos
levantados
no
nvel individual,
social,
e
os
resultados
identificados
para modelar o
diagrama;
Preencher
campos
especficos da
ferramenta da
atividade {A8}.
Ter acesso s
atividades
selecionadas.
Ter
compreendido o
contexto
do
problema.
Ter acesso aos
campos
especficos da
atividade {A8}.
Ter
compreendido o
contexto
do
problema.
Ter acesso aos
campos
especficos da
atividade {A9}.
atividades selecionadas
durante
o
desenvolvimento
da
atividade {A9}.
Utilizar as aes das Manter a referncia das
aes
levantadas
atividades
durante
o
selecionadas.
desenvolvimento
da
atividade {A9}.
Aplicar a definio (4) Orientar a utilizao da
da META.
META no processo de
elicitao.

Atividades
Selecionadas
{A9}
Descrever
as metas das
aes;
Aes
Analisar o contexto
do ambiente em
estudo;
selecionadas;
Metas
Compreender
problema;
Operaes
o
a
seqncia
das
atividades
atividade {A9};
Utilizar as aes das Manter a referncia
atividades
das aes levantadas
selecionadas;
durante
o
desenvolvimento
da
atividade {A9};
(4) da META;
da META no processo
de elicitao;
Preencher
campos
especficos da
ferramenta da
atividade {A9};
Condies de
Realizao
Ter acesso s
atividades
selecionadas;
Ter
compreendido o
contexto
do
problema;
Ter acesso aos
campos
especficos da
atividade {A9};
{A10}Descrever
as condies de
realizao
das
operaes;
Analisar o contexto
do ambiente em
estudo;
selecionadas;
Compreender
problema;
a
seqncia
das
atividades
atividade {A10};
Utilizar as operaes Manter a referncia
das
atividades das
operaes
levantadas durante o
selecionadas;
desenvolvimento
da
atividade {A10};
da META no processo
(6) da META;
de elicitao;
Preencher
campos
especficos da
ferramenta da
atividade
{A10};
Ter acesso s
atividades
selecionadas;
Ter
compreendido o
contexto
do
problema;
Ter acesso aos
campos
especficos da
atividade {A10};
A primeira verso da ferramenta de apoio META, para a qual foi realizada a

elicitao de requisitos, foi um ambiente mono-usurio. Apenas o analista de
requisitos estar envolvido no contexto da utilizao da ferramenta. Alguns
pontos observados durante a elicitao de requisitos, auxiliaram no
desenvolvimento do projeto da ferramenta.
Foi observada aps a realizao da elicitao a ausncia dos elementos em
nvel social, pois a ferramenta ser utilizada por apenas um analista de
requisitos no envolvendo assim um conjunto de atores com suas respectivas
responsabilidades trabalhando em um mesmo ambiente, na metodologia
chamada de comunidade.
Para todos os procedimentos da META importante que a ferramenta
apresente, de forma resumida, uma interface interativa com definies e
princpios da META, auxiliando o analista a identificar rapidamente o
procedimento a ser trabalhado.
O modelo de Engestrm permite uma viso real do contexto onde a atividade
est inserida, com o relacionamento entre sujeitos e objetos mediados pelas
ferramentas (neste contexto a palavra ferramenta um dos elementos da
atividade).
Os requisitos da ferramenta podem ser observados claramente nas colunas
Aes e Operaes de cada atividade. Neste procedimento conseguimos
identificar o que ser necessrio efetivamente na implementao da

ferramenta. Por exemplo: na Atividade A5, as Aes so: analisar o contexto
do ambiente em estudo; utilizar as atividades selecionadas; aplicar as
definies (7,8,9,10) da META. As operaes so: preencher campos
especficos da ferramenta da atividade A5. Com esses requisitos a atividade
A5 dever conter um frame com o descritivo resumido do princpio (6) da
META, um combo-box com a relao de todas as Atividades Selecionadas e
um campo onde ser cadastrado o Sujeito (Elemento no Nvel Individual) de
cada Atividade Selecionada (FRANCETO, 2004).
Com a elicitao de requisitos, observaram-se os procedimentos da META, o
que auxiliou na modelagem de classes especificada no prximo capitulo de
acordo com a padronizao UML.
A ferramenta dever dar suporte META, no sentido de tornar a elicitao
apoiada na META de forma prtica. O entendimento da META indispensvel
para o analista de requisitos melhorando e agilizando a coleta de informaes,
aumentando a produtividade do projeto, assim como a qualidade da ER
realizada.
5.2.ANLISE DE REQUISITOS DA FERRAMENTA (MODELAGEM DO DOMNIO DO PROBLEMA)

5.2.1.MODELAGEM LGICA DA FERRAMENTA
A modelagem das classes que representam a estrutura lgica da ferramenta
foi desenvolvida de acordo com a estrutura hierrquica da atividade e os
elementos que formam o Contexto da Atividade proposto por Martins (2001),
vide Figura 30. Essa representao atravs do diagrama de classes, muito
contribuiu para uma melhor compreenso do domnio do problema na
implementao da ferramenta.
Figura 30 - Modelagem Lgica da Ferramenta.
Nessa
modelagem
observa-
relacionamento
se
da
classe
Atividade
com a maioria das classes representadas. A atividade

pode ser candidata ou selecionada. No incio da fase
da elicitao de requisitos todas as atividades coletadas so inicialmente
nomeadas de Atividades Candidatas. Na segunda fase da META, aps
aplicarem-se as definies 1, 3 e 5 e principio 3, as Atividades Candidatas se
tornam Atividades Selecionadas. Aps as Atividades Selecionadas serem
definidas, estas que fazem o relacionamento com as demais classes
existentes no modelo.
Toda Atividade Selecionada possui um nico histrico com o objetivo de
coletar e armazenar todas as informaes referentes atividade em anlise.
Toda Atividade Selecionada possui um ou mais sujeitos (atores que executam
aes e operaes sobre o objeto da atividade) que utilizam uma ou vrias
ferramentas
(artefato
fsico
de
mediao
utilizado
pelo
sujeito
na
transformao de um objeto) que podem ser tcnicas e/ou psicolgicas na

atuao sobre um ou mais objetos (algo material ou abstrato, que pode ser
compartilhado pelos participantes da atividade), obtendo-se um ou vrios

resultados (produto final do processo de transformao inerente atividade).
Os sujeitos podem pertencer a uma ou vrias comunidades (conjunto formado
por sujeitos que influenciam na transformao do objeto da atividade) com
suas respectivas responsabilidades (Diviso do Trabalho conjunto de papis
e responsabilidades que os sujeitos assumem dentro de uma comunidade
durante a realizao de uma atividade) e regras (conjunto de normas e
procedimentos dentro de uma comunidade, que um sujeito deve atender
durante a realizao de uma atividade).
Toda Atividade Selecionada possui um motivo (razo que orienta a atividade,
expressa em termos de desejos ou necessidades humanas). Atividades
Selecionadas agregam uma ou vrias aes (um passo consciente realizado
com a inteno de se atingir uma meta bem definida no contexto da atividade)
e estas agregam uma ou mais operaes (operao uma ao que se tornou
rotineira no contexto da atividade, de tal forma que realizada de maneira
automtica pelo sujeito). As aes possuem uma ou vrias metas (um objetivo
imediato a ser atingido por uma ao) e operaes atendem de uma a vrias
condies (conjunto de variveis que possuindo um determinado estado
habilita a execuo de uma operao).
Uma nova classe Projeto foi adicionada ao modelo da Figura 30 com o objetivo
de organizar as informaes a serem registradas, ou seja, sero armazenadas
por projeto. O diagrama representado na Figura 31 tem o objetivo facilitar a
visualizao dos relacionamentos das classes apresentadas e mostrar o
comportamento da classe projeto com as outras classes da modelagem lgica
da ferramenta. A classe Projeto tem um relacionamento de um para muitos
com as outras classes do modelo .
Tcnica
Candidata
Psicolgica
Selecionada
Objeto
Ferramenta
Cdigo Ferramenta
Ferramenta
Incluir Ferramenta()
Alterar Ferramenta()
Consultar Ferramenta()
Sujeito
Cdigo Sujeito
Nome "Ator"
Ativ idade
Cdigo Objeto
Objeto
Cdigo Ativ idade

Ativ idade
Incluir Objeto()
Alterar Objeto()
Consultar Objeto()
1..n
Incluir()
Alterar()
Consultar()
Incluir()
Alterar()
Consultar()
1..n
Resultado
1..n
1..n
Incluir Sujeito()
Alterar Sujeito()
Consultar Sujeito()
Codigo Resultado
Resultado
1..n
1..n
1
Comunidade
Projeto
Codigo Comunidade
Comunidade
Incluir Sujeito()
Alterar Sujeito()
Consultar Comunidade()
Motiv o
Cdigo Motiv o
Motiv o
1..n
Incluir()
Alterar()
Consultar()
Ao
Codigo Projeto
Projeto
Incluir()
Alterar()
Consultar()
Codigo Ao
Ao
1
1
1..n
1
11
Regra
Cdigo Regra
Regra
Incluir Regra()
Alterar Rera()
Consultar Regra()
Incluir()
Alterar()
Consultar()
Meta
1..n
1..n
1..n
Responsabilidade
Codigo Responsabilidade
Responsabilidade
Incluir Responsabilidade()
Altarar Responsabilidade()
Consultar Responsabilidade()
1..n
Histrico
1..n
Condio
Opeao
Cdigo Histrico
Histrico
Cd Operao
Operao
Incluir()
Alterar()
Consultar()
Incluir()
Alterar()
Consultar()
1..n
Cdigo Meta
Meta
Incluir()
Alterar()
Consultar()
Cd Condio
Condio
Incluir()
Alterar()
Consultar()
Figura 31 - Modelagem Lgica da Ferramenta adicionando a classe Projeto.
Para especificar os requisitos levantados, foram criados conforme Figura 32,

os casos de uso descritos a seguir. Foram desenvolvidos, procurando abranger
todo o escopo do projeto da Metodologia.
FIGURA 32 - DIAGRAMA DE CASOS DE USO.

Figura 32 - Casos de Uso que representam a interao do usurio no
contexto da ferramenta.
5.3. ARQUITETURA
DA
FERRAMENTA (O
ENGENHARIA REVERSA)
MODELO DAS CLASSES IMPLEMENTADAS
GERADAS POR
A elicitao, anlise e modelagem dos requisitos deram condies suficientes

para o desenvolvimento da ferramenta. Aps a implementao, utilizando a
engenharia reversa, com a inteno de auxiliar futuras mudanas na
ferramenta desenvolvida, os diagramas das Figuras 33, 34 e 35 apresentam o
comportamento das classes implementadas da ferramenta desenvolvida. Os
diagramas
foram
gerados
com
ferramenta
Omondo
EclipseUML
Technologies, atravs de engenharia reversa.

A META est dividida em trs etapas principais que ocorrem de forma
interativa e incremental (MARTINS, 2001). Para facilitar a visualizao das
classes implementadas, os diagramas tambm foram divididos em trs etapas.
O primeiro diagrama (Figura 33) representa as classes implementadas da
primeira etapa da metodologia, que a diviso do problema em atividades,
que englobam os procedimentos:
Levantar atividade candidatas;
O segundo diagrama (Figura 34) representa as classes implementadas da

segunda etapa da metodologia, que o delineamento do contexto das
atividades, que engloba os procedimentos:
O terceiro diagrama (Figura 35) representa as classes implementadas da

terceira etapa da metodologia, que a descrio da estrutura hierrquica das
atividades, que engloba os procedimentos:
Descrever as metas das aes ;
Descrever as condies de realizao das operaes;
Os nomes para as classes do programa foram criados na concepo do cdigo

fonte seguindo a conveno onde nomes das classes devem ser iniciadas com
letra maiscula (DEITEL, 2003).
A organizao das classes do programa desenvolvido apresenta quatro
classes que contm mtodos a serem utilizados por todas as outras classes da
ferramenta na execuo de funes especficas. Essas classes esto
presentes nos trs diagramas apresentados, e so Acesso, JComboBoxN,
JListN e MnuPrincipal.
O MnuPrincipal a tela principal do programa que apresenta os menus de
chamada s telas do programa.
A classe JComboBoxN contm os mtodos especficos que tratam dos itens
contidos em um Combo Box, por exemplo, adicionar, remover, verificar
posio. A classe JListN segue a mesma descrio do JComboBoxN, trata dos
itens contidos em um JList, como por exemplo, adicionar, remover, verificar
posio dos itens na lista. As telas e o menu principal (interface do usurio)
enviam e recebem os dados atravs de uma classe especfica que se dedica
exclusivamente a esse feito, a classe Acesso. A classe Acesso responsvel

pelo acesso aos dados do banco.
Figura 33 - Modelo
Implementadas referente a
Arquitetural das Classes

Diviso do Problema em Atividades.
No diagrama da Figura 33
observar
pode-se
dependncia
das classes CadCandidata,

CadSelecioanada
CadHistorico com a classe Acesso, pelo

motivo desta ter os mtodos que acessam os
dados
do
banco
de
dados.
uma
dependncia da classe MnuPrincipal com as

demais, pois responsvel pelas chamadas
das telas dos procedimentos do programa. A dependncia da classe
CadSelecionada com a CadHistorico pelo fato de existir um boto na tela

CadSelecionada chamando a tela que realizar o procedimento Cadastrar
Histrico, ou seja a classe CadHistorico.
Figura 34 - Modelo Arquitetural das Classes Implementadas referente a

85
Delineamento do Contexto das Atividades.
Figura
34
tambm
apresenta
as
classes
MnuPrincipal, JComboBoxN, JListN e Acesso. Essas

tm
mesma
funo
do
modelo
classes
arquitetural
apresentado na figura 33. A

classe ChoiceN, tem o mesmo
papel que o JComboBoxN. A
diferena que tem-se um diagrama implementado, o qual

representa o Diagrama de Engestrm. Por ser uma interface
grfica, utilizou-se um JComponent. Ento utilizou-se o
ChoiceN ao invs do JComboBox. Nesta figura nota-se a
presena
da
classe
AreaDesenho
que
implementa
Diagrama de Engestrm. H uma dependncia da classe MnuPrincipal com as

demais, pelo motivo da classe Acesso ter os mtodos que acessam os dados
do banco de dados. A dependncia por exemplo da classe CadResultado com
a classe CadSujeito acontece pelo motivo de existir um boto na tela
CadResultado chamando a tela que realizar o procedimento Cadastrar
Sujeito, ou seja a classe CadSujeito.
Figura 35 - Modelo
Implementadas referente
Estrutura Hierrquica da
A
Figura
classes
JListN
35
tambm
MnuPrincipal,
Arquitetural das Classes

a Descrio da
Atividade.
apresenta
as
JComboBoxN,
Acesso. Essas
classes tm a
mesma funo
que o modelo
arquitetural
apresentado
na figura 34. H uma dependncia da
classe MnuPrincipal com
as outras, pelo motivo da classe
Acesso ter os mtodos que
acessam os dados do banco de dados. A dependncia por exemplo da classe

CadAo com a classe CadMeta acontece por existir um boto na tela
CadAo chamando a tela que realizar o procedimento Cadastrar as Metas

das Aes, ou seja a classe
CadMeta. Assim, acontece para todo o
relacionamento de dependncia do programa. Todas as telas que tm os

mtodos que chamam a prxima tela do procedimento, de acordo com a
metodologia, apresentam um relacionamento de dependncia.
A Figura 36 representa a modelagem fsica do banco de dados da ferramenta
implementado em MySQL. Para garantir a integridade as tabelas foram
desenvolvidas em InnoDB ( um tipo de tabela transacional, desenvolvido pela
InnoDBase Oy). O InnoDB apresenta, alm da capacidade transacional, outros
recursos importantes, como suporte para transaes ACID (Atomicidade,
Consistncia, Isolamento e Durabilidade); Suporta FOREIGN KEYS e
integridade referencial com implementao dos constraints SET NULL, SET
DEFAULT, RESTRICT e CASCADE. As inseres e excluses, assim como as
queries, so extremamente rpidas, pois o tipo INNODB foi construdo para ser
rpido e fcil de utilizar, alm de robusto. Tem suporte para Foreign Keys
(chaves estrangeiras), alm de ser confivel, dentre outras caractersticas.
Com a utilizao das tabelas InnoDB, tm-se recursos de integridade
referencial e suporta transaes.
Figura 36 Representao Fsica do Banco de Dados da Ferramenta
89
A legenda da representao das cardinalidades do banco de dados notada a

seguir. Nesta legenda tm-se na Tabela A um relacionamento de um para
muitos com a Tabela B. A Tabela B tem um relacionamento de um para um
com a Tabela A.
5.4. INTERFACE
DO USURIO
As telas da ferramenta apresentam uma padronizao de botes. A seguir

feita uma descrio de cada boto com suas respectivas utilidades:
(e)
(a)
(b)
(c)
(d)
a) Novo:
Limpa a tela para o cadastro de um novo item;
b) Gravar:
Grava os dados registrados nos campos em branco pelo
usurio;
c) Excluir:
Exclui um item j cadastrado;
d) Limpar:
Limpa os dados dos campos em branco, que ainda no foram

gravados;
e) Candidata: Chama a prxima tela a ser registrados os dados;

Este boto apresenta o nome de cada interface da ferramenta,
conforme os procedimentos da metodologia. Neste exemplo a
que aparecer para o usurio ser a tela para
prxima tela
cadastro das Atividades
Candidatas.
(Lupa) = boto de consulta = busca dos dados do banco.
Anterior e Prximo = navega pelos registros j

cadastrados no banco. (Para a utilizao destes botes necessrio antes
clicar no boto de consulta para que a busca dos dados seja realizada).
ToolTipText = tarja cor violeta contendo uma descrio do Boto.
Boto Help = este boto chama o Help para auxiliar o uso da ferramenta.
A seguir sero mostradas algumas telas que fazem parte da ferramenta que
apia a META. A ferramenta apresenta dezesseis telas semelhantes de
interface com o usurio. Com a finalidade de mostrar a padronizao do layout das telas, algumas interfaces da ferramenta sero apresentadas a seguir.
Figura 37 - Interface: Cadastro de Projetos.
A Figura 37 a primeira interface que interage com o usurio: Cadastro de

Projetos. Nessa tela necessrio escolher um projeto ou criar-se um novo
projeto para iniciar o processo de elicitao de requisitos. Se a opo for criar
um novo projeto, o usurio deve apertar o boto Novo, escrever o nome do
projeto no espao em branco (Incluir Projeto) e apertar no boto Gravar,
registrando as informaes no banco de dados. Aps cadastrar o projeto o
usurio dever selecion-lo atravs do combo-box, antes de passar para a
prxima tela. Caso o projeto j esteja cadastrado, o usurio escolhe o projeto
atravs do combo-box. Com o projeto selecionado, o usurio aperta o boto
Candidata chamando a prxima tela da elicitao de requisitos.
Figura 38
Mensagem com Definio da Atividade Candidata.
- Interface:
Pelo motivo da ferramenta apresentar uma seqncia de procedimentos

baseados na META, a cada mudana de procedimento, ou seja, mudana de
tela, uma caixa de mensagem, conforme Figura 38, apresenta a Definio da
META especfica para o procedimento que estar sendo executado, auxiliando
o usurio no levantamento dos requisitos.
Figura 39 - Interface: Cadastro das Atividades Candidatas.
A figura 39 apresenta a tela de Cadastro das Atividades Candidatas. De

acordo com a definio 1 da META, nesse procedimento devem ser levantadas
as possveis atividades que so realizadas pelos agentes envolvidos
(possivelmente usurios do futuro sistema de software), mas ainda sem a
preocupao de uma classificao precisa das tarefas como atividade, ao ou
operao. Qualquer tarefa realizada por agentes envolvidos no sistema pode
inicialmente ser indicada como uma atividade em potencial. Dessa forma, no
h num primeiro momento um filtro que garanta a seleo imediata de
atividades (MARTINS, 2001).
Figura 40 - Interface: Cadastro das Atividades Selecionadas.
Na Figura 40 temos o Cadastro das Atividades Selecionadas. Nesse

procedimento busca-se uma classificao mais precisa sobre as tarefas
apontadas inicialmente como atividades. Utilizam-se as definies (1) (3) e (5),
pois as mesmas auxiliam na avaliao da granularidade das tarefas em
atividades. A classificao das tarefas como atividades baseia-se no princpio
(3) da Teoria da Atividade.
Ao trmino dessa etapa, tem-se j uma organizao mnima para a elicitao
dos requisitos, onde cada atividade passa a ser vista como uma unidade de
elicitao. Deve-se, portanto, partir para uma investigao das origens das
atividades selecionadas (MARTINS 2001).
A ferramenta auxilia na classificao das atividades selecionadas. Caso o
usurio responsvel pela elicitao de requisitos identifique, no contexto em
anlise, que duas ou mais atividades candidatas transformar-se-o em uma
nica atividade selecionada, ento dever selecionar a atividade candidata e
apertar o boto Mover, repetir esse procedimento at completar as atividades
candidatas envolvidas que faro parte de uma nica atividade selecionada. Em
seguida, o usurio dever registrar no campo Selecionada o nome da
Atividade Selecionada e apertar o boto Gravar. Nesse momento estar sendo
gravada a atividade selecionada e as atividades candidatas que se relacionam
com a nova atividades selecionada registrada. Mas, uma segunda situao
tambm poder acontecer, ou seja, uma atividade candidata passar a ser uma
atividade selecionada. Nesse caso, ao mover uma atividade candidata, a
ferramenta automaticamente escreve no campo Selecionada a informao
movida, ou seja o campo Selecionada assume o descritivo movido pelo
usurio, assim o usurio somente aperta o boto Gravar e os dados estaro
sendo registrados no banco de dados.
Consultar nico
item.
Consultar
conjunto de
dados
registrados.
Figura 41 - Interface: Cadastro dos Resultados das Atividades.

Na Figura 41, Cadastro dos Resultados das Atividades, pode-se observar que
existem duas TextArea, lugar para consulta e insero de dados. Com os
combo-box,
Projeto,
Atividade
Selecionada
selecionados, pode-se apertar o boto de consulta,
Motivo
e consultar todos os
resultados que j foram cadastrados. Existem duas formas de consulta nessa

tela.
a) Consulta a um nico item, onde permitido navegar pelos itens j
cadastrados. neste primeiro campo que ser permitida a alterao de
qualquer item.
Para atualizar os dados;
clica-se na lupa para consultar os dados;
percorre-se pelos botes (Prximo, Anterior) no registro que se

deseja alterar, faz-se a alterao e clica-se no boto (Gravar).
b) Caso se deseje consultar todos os dados j registrados, aperta-se o

boto da segunda lupa (ToolTipText = Consultar Grupo de Resultado).
Essa opo permite uma consulta de todos os itens j registrados.
Caso o usurio escolha uma atividade selecionada onde no existam motivos
cadastrados, o combo-box motivo, fica vazio.
Para cadastro das informaes referentes ao resultado de cada atividade
selecionada, devem ser seguidos a definio e princpios da META para esse
procedimento: escolhe-se uma atividade selecionada dentro do projeto
selecionado, insere-se as informaes na Descrio dos Resultados e apertase o boto Gravar.
A Figura 42 apresenta o diagrama de Engestrm da ferramenta, aps
cadastradas as informaes de um exemplo utilizado para a validao da
ferramenta na fase de elicitao de requisitos.
Figura 42 - Representao Grfica do Diagrama de Engestrm.
Figura 43 - Exemplo Do Relatrio Gerado pela Ferramenta.
A Figura 43 apresenta um relatrio gerado a partir de informaes registradas

de um exemplo realizado para validar a ferramenta na fase de elicitao de
requisitos. Neste exemplo foi gerado um relatrio das aes e metas da
atividade selecionada Controlar recebimento de mensalidades de alunos
referente ao Projeto Sistema para cursos de Ps-Graduao.
Figura 44 - Exemplo Do Help da Ferramenta.
A Figura 44 apresenta o Help da ferramenta tem o objetivo de auxiliar o

usurio durante a elicitao de requisitos. Cada tela apresenta seu respectivo
help. Consultar os dados na tela, por exemplo, diferenciam nas telas que
apresentam dois TextArea, como apresentado na figura 41 (interface de
Cadastro dos Resultados das Atividades). Existem duas formas de
CONSULTA nesta tela: a) Consultar um nico item: permitido navegar pelos
itens j cadastrados. Importante: neste primeiro campo que ser permitida a
alterao de qualquer item. b) Consultar conjunto de dados registrados: apertar
o segundo boto Consultar Grupo de Resultados. (ToolTipText = Consultar
Grupo de Resultado). Esta opo permite uma consulta de todos os itens j
registrados.
Na figura 37, interface de Cadastro de Projetos, que apresenta um TextArea,
para CONSULTAR os dados j registrados, clicar no boto Consultar Projetos
e para navegar em todos os registros, clicar nos botes Anterior e Prximo.
Algumas aes como por exemplo, Limpar as informaes na tela, so padro
em todas as interfaces da ferramenta.
6. VALIDAO DA FERRAMENTA
A validao da ferramenta uma etapa de fundamental importncia para que

seja assegurado que os objetivos e metas propostos neste trabalho sejam
realmente alcanados, e que a ferramenta auxilie na fase de elicitao de
requisitos, propsito do desenvolvimento. O teste de validao tem como
papel verificar se todos os requisitos foram cumpridos. Aps a validao, a
fase de teste se inicia a fim de testar a ferramenta e, se necessrio, realizar
ajustes. Neste trabalho a validao e teste da ferramenta foram realizados
atravs de um estudo de caso aplicado a um ambiente real.
6.1.CONTEXTUALIZAR
CASO DE TESTE
O teste da ferramenta foi realizado em uma empresa, cujo principal servio

montar e coordenar cursos de ps-graduao em nvel Lato Sensu. As
informaes obtidas na elicitao de requisitos e utilizadas para auxiliar na
validao da ferramenta compem uma parte de um projeto de Mestrado em
Cincias da Computao.
Aplicou-se o teste observando pontos que contribussem para a evoluo e
aperfeioamento da ferramenta. Tambm foi observada toda a interface
implementada, como botes verificando a funcionalidade para realizao de
operaes, campos para insero de dados e consulta aos dados.
Nesta fase de teste, dois analistas de sistemas participaram da validao da
ferramenta, ambos com conhecimentos da META. Um dos analistas atuou no
desenvolvimento
da
ferramenta
possui
experincia
em
anlise,
desenvolvimento, testes de softwares e treinamentos com usurios finais. O

segundo analista no teve nenhum envolvimento com o desenvolvimento da
ferramenta, porm com experincia em elicitao e anlise de requisitos
usando a metodologia em questo.
A validao da ferramenta teve durao de dois dias e o procedimento para a
fase de teste ocorreu seguindo as etapas da META. No primeiro dia as
informaes foram coletadas e registradas em papel. No segundo dia, todas as

informaes coletadas foram inseridas na ferramenta de forma a verificar
possveis falhas.
A Tabela 12 a seguir, apresenta o documento utilizado na validao da
ferramenta e foi criada de acordo com as necessidades de avaliao durante a
fase de teste. Como por exemplo, foram analisados botes de ao da tela, a
interface de um modo geral (tamanho dos campos, tamanho da tela), help de
ajuda ao usurio de cada tela, a funcionalidade da ferramenta e os padres e
procedimentos aderentes META, observando a interatividade das telas e
processos para aes dos procedimentos da ferramenta. Entretanto houve a
necessidade de criar um documento padro, em que todas as telas fossem
analisadas, seguindo uma diretriz de avaliao, como pode ser observado na
Legenda da Tabela 19.
Tabela 19 Documento de Validao da Ferramenta.
1 Tela: Cadastro de
Projetos
2 Tela: Cadastro de
Atividades
Candidatas
3 Tela: Cadastrar
Atividades
Selecionadas
4 Tela: Cadastro dos
Histricos das
Atividades
Selecionadas
Motivos das
Atividades
Selecionadas
Resultados das
Atividades
Selecionadas
Sujeitos das
Atividades
Selecionadas
Objetos das
Atividades
Selecionadas
Botes
de Ao
Lay-Out
Help
(Ajuda)
Funciona
-lidade
Desempenho
Processos
BS
MD
BS
BS
BS
NA
BS
BS
BS
BS
Tabela 19 Documento de Validao da Ferramenta.
9 Tela: Cadastro das

Ferramentas das
Atividades
Selecionadas
10 Tela: Cadastro
das
Responsabilidades
das Atividades
Selecionadas
11 Tela: Cadastro
das Comunidades
das Atividades
Selecionadas
12 Tela: Cadastro
das Regras das
Atividades
Selecionadas
13 Tela: Cadastro
das Aes das
Atividades
Selecionadas
14 Tela: Cadastro
das Metas das Aes
das Atividades
Selecionadas
15 Tela: Cadastro
das Operaes das
Atividades
Selecionadas
16 Tela: Cadastro
das Condies das
Operaes das
Atividades
Selecionadas
Diagrama de
Engestrm
Botes
de Ao
Lay-Out
NA
Help
(Ajuda)
Funciona
-lidade
Desempenho
Processos
NA
NO
BS
MD
BS
BS
NA
BS
BS
BS
BS
NO
MS
Legenda da Tabela:
Botes de Ao
A
= Adequado
NA
= No Adequado
MD
= Melhorar Definio
Integridade de Interface (Lay-Out)
A
= Adequada
NA
= No Adequada
MD
= Melhorar Definio
Help (Ajuda)
S
= Suficiente
BS
= Insuficiente
Funcionalidade
O
= Operacional
NO
= No Operacional
MF
= Melhorar Funcionalidade
Desempenho dos Processos
BS
= Bem Sucedido
MS
= Mal Sucedido
MP
= Melhorar Processos
O objetivo da validao da ferramenta foi descobrir erros e torn-la mais

funcional e prtica para o usurio na fase de elicitao de requisitos. Os botes
de ao, como por exemplo, Novo, Gravar, Excluir, Limpar, Consultar, etc, so
iguais para todas as telas; assim, foram observados e validados, pois
pertencem ao grupo da Integridade de Interface. As interfaces foram
observadas de maneira a serem adequadas ao usurio. O Help foi analisado
observando-se se suficiente para compreenso e desenvolvimento dos
processos da META utilizando a ferramenta. A funcionalidade foi observada
quanto busca de erros funcionais, e o desempenho de processos na
verificao dos processos, em relao aos processos da META e se esto
compatveis (PRESSMAN, 1995).
Durante o teste algumas falhas foram identificadas. Dentre os itens levantados
na Tabela 20, alguns foram alterados e outros itens que podem ser
melhorados, vide seo 6.3, ficaram para a segunda reviso da ferramenta.
Dentre as falhas encontradas, sero expostas na tabela a seguir as devidas
correes que trouxeram maior usabilidade para a ferramenta:
Tabela 20 Itens Alterados aps Validao da Ferramenta.

1 Tela: Cadastro de
Projetos
Help (Ajuda): As informaes que o help da ferramenta

apresentava foram insuficientes para o usurio registrar
informaes com praticidade e eficincia. Faltaram
informaes de como o usurio dever proceder ao
utilizar alguns botes, como por exemplo, o boto limpar,
excluir. O help foi alterado em sua totalidade, com mais
detalhes e objetivo s dvidas do usurio.

Atividades Candidatas

Atividades Selecionadas

Histricos das Atividades
Selecionadas

Motivos das Atividades
Selecionadas

Resultados das

Sujeitos das Atividades
Selecionadas

Boto de Ao: Identificou-se que ao clicar no boto
MOVER as informaes da Atividade Candidata deveria
automaticamente passar para o campo destinado
registrar a Atividade Selecionada. O cdigo fonte foi
implementado para que esta ao fosse realizada.
Interface: Identificou-se a falta do campo motivo na tela
de Cadastro dos Resultados. Este campo servir como
consulta dos motivos j registrados no momento da
insero dos resultados identificados.

Objetos das Atividades
Selecionadas

Ferramentas das

Interface: No momento da digitao das informaes,
identificou-se a necessidade do aumento do campo para
a insero de dados.

Responsabilidades das

Interface: No momento da digitao das informaes,
identificou-se a necessidade do aumento do campo para
a insero de dados.

Comunidades das

Regras das Atividades
Selecionadas
Funcionalidade: Identificaram-se erros na gravao das

informaes dos dados registrados. Houve uma correo
no cdigo fonte do programa.
Boto de Ao: Identificou-se que ao clicar no boto
MOVER o Sujeito deveria automaticamente passar para o
campo destinado a registrar o nome da Comunidade. O
cdigo fonte foi implementado para que esta ao fosse
realizada.

Aes das Atividades
Selecionadas

Metas das Aes das

Operaes das

Condies das
Operaes das
17 Tela: Diagrama de
Engestrm
Interface: Identificou-se que o campo destinado na

insero das Aes estava muito grande. Houve uma
reduo do campo.
utilizar alguns botes, como por exemplo, o boto
limpar,excluir. O help foi alterado em sua totalidade, com
mais detalhes e objetivo s dvidas do usurio.
Funcionalidade: Identificaram-se erros na gravao das
informaes dos dados registrados nos campos
Responsabilidade e Comunidade. Houve uma correo no
cdigo fonte do programa.
Desempenho dos Processos: Identificou-se que o campo
Sujeito necessitava ser mais dinmico pelo fato de poder
existir mais que um sujeito para cada atividade
selecionada, com diferentes responsabilidades e
ferramentas de trabalho. O erro foi corrigido colocando
um combo-box, o qual, ao alterar o sujeito, apresentado
as responsabilidades, ferramentas tcnicas e psicolgicas
referentes ao sujeito selecionado.
O campo Comunidade tambm necessitou ser alterado,
pois cada comunidade possui suas respectivas regras. O
erro foi corrigido colocando um combo-box, o qual ao
alterar a comunidade, apresentada a regra referente
comunidade selecionada.
6.2.PONTOS FORTES
A metodologia META apresenta uma interatividade entre as fases. Alguns

procedimentos da META no podem ser registrados sem que informaes
anteriores estejam registradas como, por exemplo, o cadastro de informaes
no procedimento Meta das Atividades depende das informaes das Aes
das Atividades para ser registrado. Nesse caso, se o procedimento do registro
da Meta das Aes no for executado, a ferramenta apresentar um combobox vazio da Ao, na interface do procedimento Meta das Aes das
Atividades, sinalizando que o procedimento anterior no foi realizado.
Para esse mesmo caso de dependncia entre procedimentos, a ferramenta
tem um facilitador para o analista de requisitos. A ferramenta permite a
visualizao do procedimento principal (no caso a Ao) na tela de insero de
dados das Metas das Aes. Assim, o analista no precisa ficar navegando
entre telas para saber de qual Ao ele est inserindo as informaes.
Outro ponto forte da ferramenta a navegabilidade entre as telas da
ferramenta. No h necessidade de se alterar em dois itens chaves da
ferramenta, Projeto e Atividade Selecionada, no momento que se passa de um
procedimento para outro. Uma vez escolhido o projeto e a atividade
selecionada a ser trabalhada no inicio, o analista de requisitos poder seguir
at o final dos procedimentos sem precisar se preocupar em alter-los.
A gerao de relatrios dinmicos tambm auxilia na visualizao das
informaes cadastradas. O usurio poder escolher entre trs opes de
combinao dos procedimentos
da META para gerar o relatrio. E a
visualizao grfica dos elementos que fazem parte do diagrama de

Engestrm facilita a anlise das informaes coletadas.
6.3.PONTOS QUE PRECISAM MELHORAR
A ferramenta exige do analista um conhecimento da metodologia para facilitar
a coleta das informaes. Entretanto, um ponto a ser melhorado na prxima
verso, o qual trar benefcios ferramenta um sinalizador de parada de
execuo da ferramenta. Ou seja, a ferramenta aps ser encerrada no meio
do processo da coleta de informaes, como por exemplo, se o usurio
analista estava registrando informaes na Tela Levantar Motivos das

Atividades, a ferramenta dever sinalizar ao usurio que o mesmo estar
interrompendo o processo de elicitao e, assim que o usurio analista
retornar ao trabalho com a mesma, esta seria iniciada automaticamente do
ponto em que foi interrompida, de acordo com o projeto selecionado.
Outro ponto a ser melhorado a apresentao das telas da ferramenta, de
modo que o usurio possa ter uma maior flexibilidade entre os processos da
META.
Finalmente, a ferramenta dever ser transformada em multi-usurios.
Assim como a META uma metodologia que tem pontos a evoluir, a
ferramenta necessitar acompanhar a mesma evoluo.
7.Concluso
Com a ferramenta desenvolvida neste trabalho, espera-se uma importante

contribuio para a fase de Elicitao de Requisitos apoiada na META,
buscando a organizao dos requisitos baseados no conceito de atividade e
auxiliando no registro das informaes coletadas.
Para a utilizao da ferramenta, o usurio dever ter conhecimentos da META,
pois a ferramenta engloba um contexto muito mais amplo do que simplesmente
sua utilizao como uma ferramenta de apoio. Com as etapas e procedimentos
da metodologia (Tabela 7) e, por meio do contato direto com as pessoas
envolvidas no sistema, as informaes coletadas com a utilizao da META,
no processo de elicitao de requisitos, devem ser registradas e armazenadas,
auxiliando o desenvolvimento de um projeto de software especfico.
Assim como os procedimentos da META orientam o usurio no processo de
elicitao de requisitos, a ferramenta apresenta uma dependncia entre as
etapas durante sua utilizao para a Elicitao de Requisitos.
Os dados extrados em um primeiro contato com o ambiente em estudo so
armazenados e organizados em um repositrio de dados. Dessa forma a
ferramenta une, em um mesmo ambiente, recurso para levantamento e
armazenamento de dados; consulta aos dados inseridos que poder ser de
forma grfica (diagrama de Engestrm), atravs de consultas pela interface da
ferramenta e atravs de relatrios, auxiliando os analistas de requisitos nas
fases posteriores da Engenharia de Requisitos e no desenvolvimento do
sistema de software.
O armazenamento dos dados auxilia tambm na tomada de decises, reviso
de procedimentos quanto aos processos atuais do ambiente em anlise, vises
diferenciadas de determinados procedimentos exercidos em duplicidade ou
tarefas desnecessrias.
A ferramenta proporciona maior praticidade para o analista de requisitos,
auxiliando na extrao e armazenamento das informaes dentro do contexto
do sistema onde ser desenvolvido o software.
Aps o desenvolvimento da ferramenta foi realizada a validao da mesma,

extraindo pontos fortes e pontos que necessitam melhorar. Algumas falhas
encontradas durante a validao da ferramenta foram corrigidas, como
apresentado na Tabela 20, com a finalidade de torn-la prtica e objetiva para
o trabalho proposto.
Assim como a META uma metodologia nova e tende a evoluir, a ferramenta
dever acompanhar sua evoluo com a finalidade de garantir o real propsito
durante a Elicitao de Requisitos.
Para uma segunda reviso da ferramenta importante a permisso de
trabalhos colaborativos, que possibilitar que vrios usurios trabalhem em
rede, tornando a ferramenta mais dinmica e interativa.
Referncias Bibliogrficas
ABOULAFIA, Annette. - Activity Theory: A way forward in HCI? - Amodeus

Project Report, Esprit Basic Research Action 7040, J/WP 24, University of
Copenhagen, 1994. In SANTOS, M. R. Design, Processo e Uso dos
Artefatos: Uma abordagem a partir da Atividade Humana Dissertao de
Mestrado dirigida ao Programa de Ps Graduao em Tecnologia do Centro
Federal de Educao Tecnolgica do Paran, na rea de Educao
Tecnolgica. Curitiba, 2000.
ALVES, C. F. - Seleo de Produtos de Software Utilizando uma
Abordagem Baseada em Engenharia de Requisitos. MSc. Thesis,
Departamento de Informtica, Universidade Federal de Pernambuco, Brasil,
Maro 2001.
ASMOLOV, A. G. Pskhologiya Lichnosti [The Psychology of Personality].
Moscow: Izdatelstvo Moskovskogo Universiteta, 1990. In WERTSCH, J. V.;
RIO, P. D.; ALVAREZ, A. Estudos Socioculturais da Mente [Traduo de
Maria da Graa Gomes Paiva e Andr Rossano Teixeira Camargo]. Porto
Alegre: ArtMed, 1998.
BECKER, H.A. The role of gaming and simulation in scenario project.
Operational Gaming: an international approach. International Institute for
Applied Systems Analysis, Luxemburg, Austria 1983.
BREITMAN, K. K. Evoluo de Cenrios - Tese apresentada ao
Departamento de Informtica da Pontifcia Universidade Catlica do Rio de
Janeiro, como parte dos requisitos para obteno do grau de Doutor em
Informtica. Departamento de Informtica Rio de Janeiro, 2000.
BELL, T. E.; THAYER, T. A. - Software Requirements: Are They Really a
Problem? Proceedings on 2nd International Conference on Software
Engineering. San Francisco, 1976.
CARROL, J.M. Scenario Based Design: Envisioning Work and
Technology in System Development John Willy and Sons, 1995.
CHANCE, B. D. e MELHART, B. E. - A Taxonomy for Scenario Use in

Requirements Elicitation and Analysis of Software Systems - IEEE
Conference and Workshop on Engineering of Computer-Based Systems.
March 1999.
CONSTANTINE, L. L., e LOCKWOOD, L. A. D. Software for use: a practical
guide to the models and methods of usage-centered design. Addison
Wesley Longman, Inc., 1999.
CHUNG, L.; NIXON, B.; YU, E. e MYLOPOULOS, J. Non-Functional
Requirements in Software Engineering Kluwer Academic Publishers, 2000.
CYSNEIROS, L. M. - Requisitos No Funcionais: Da Elicitao ao Modelo
Conceitual. PUC-Rio, Fevereiro de 2001.Tese apresentada ao Departamento
de Informtica da PUC/RJ como parte dos requisitos para a obteno do ttulo
de Doutor em Cincias da Computao.
DAVIS, A. "Software Requirements: Objects Functions and States"
Prentice Hall, Englewood Cliffs, New Jersey, USA, 1993.
DEITEL, H. M.; DEITEL, P. J. JAVA Como Programar. Trad Carlos Arthur
Lang Lisboa. 4 edio Porto Alegre: Bookman, 2003. ISBN 85-363-0123-6.
ENGESTRM, Yry. - Learning by Expanding: An activity Theoretical
Approach to Developmental Research. - Orienta Konsultif Oy, 1987. In
SANTOS, M. R. Design, Processo e Uso dos Artefatos: Uma abordagem a
partir da Atividade Humana Dissertao de Mestrado dirigida ao Programa de
Ps Graduao em Tecnologia do Centro Federal de Educao Tecnolgica
do Paran, na rea de Educao Tecnolgica. Curitiba, 2000.
FRANCETO, S.; MARTINS, L.E.G. Elicitao de Requisitos para o
Desenvolvimento de uma Ferramenta de Apoio Metodologia de
Elicitao de Requisitos de Software Baseada na Teoria a Atividade
(META1) 7 Workshop Iberoamericano de Ingeniera de Requisitos y

Ambientes Software. Arequipa, Peru, 3 a 7 de Mayo, 2004. Pages: 169-174.
ISBN: 9972-9876-1-2.
FUENTES, R.; GMES-SANZ, J.J,; PAVN, J. Managing Conflicts
between Individuals and Societies in Multi-Agent Systems. Engineering
Societies in the Agents World V, 5th InternationalWorkshop, ESAW 2004,
Toulouse, France, October 20-22, 2004. Pages: 106-118.
FUENTES, R.; GMES-SANZ, J.J,; PAVN, J. Requirements Elicitation
for Agent-based Applications. 6th International Workshop on
AGENT-ORIENTED SOFTWARE ENGINEERING (AOSE-2005), Utrecht,
Netherlands July 25-26, 2005.
HARRIS, S. R. Systemic-Structural Activity Analysis of HCI Video. In O.
W. Bertelsen, M. Korpela & A. Mursu (Eds.), Proceedings of
ATIT04: 1st
International Workshop on Activity theory Based Practical Methods for ITDesign, September 2-3, 2004, Copenhagen, Denmark (pp. 48-63). Aarhus:
Aarhus University Press.
HARRIS, S. R. Morphological Analysis of HCI Video Data Using Activity
Theory. In A. Dearden & L. Watts (Eds), Proceedings of HCI2004: Design for
Life (Vol. 2, pp. 41-44). Bristol: Research Press International. 2004. ISBN 1897851-13-8.
JACKSON, M. Software Requirements and Specifications: A Lexicon of
Practice, Principles and Prejudices. 1ed. Addison-Wesley. Massachusetts,
USA. 1995.
JACOBSON, I.; RUMBAUGH, J.; BOOCH, G., - Unified Modeling Language
Reference Manual, Addison Wesley, 1997.
KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering with

Viewpoints from Software Engineering J., Vol. 11, N 1, Jan. 1996, pp 55-18.
Copyright 1996 by the Institution of Electrical Engineers.
KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering Processes
and Techniques. John Willy & Sons, 1997.
KOTONYA, P.; SOMMERVILLE, I. Requirements Engineering: Processes
and Techniques. By John Wiley & Sons Ltd, 1998.
KULAK, D., e GUINEY E. Use cases requirements in context. ACM Press,
2000.
KUUTTI, K,. - Activity Theory as a Potential Framework for HumanComputer Interaction. In Context and Consciousness - Activity Theory and
Human- Computer Interaction, MIT Press, 1996, pp. 17-44.
LAMSWEERDE, A. Requirements Engineering in theYear 00: A Research
Perspective. In: International Conference on Software Engineering, 22., jun.
2000, Limerick, Ireland. Proceedings ACM, 2000, p. 5-19.
LEITE, J. C.S.P. Enhancing the Semantics of Requirements Statements
Proceedings of the XII International Conference of the Sociedad Chilena de
Ciencia de la Computacion, Santiago, 1992.
LEITE J.C.S.P. -, Engenharia de Requisitos- Notas de Aula, 1994.
LEITE, J.C.S.P.; ROSSI, G.; BALAGUER, F.; MAIORANA, V.; KAPLAN, G.;
HADAD, G.; OLIVEROS, A. Enhancing a Requirements Baseline with
Scenrios 3rd IEEE International Symposium on Requirements Engineering
(RE'
97) - Annapolis, MD. January 1997.
MACAULY, L.A. Requirements Engineering. London, 1996
MAIDEN, N.; MINOCHA, S.; MANNING, K.; RYAN, M. - CREWS-SAVRE:

Systematic Scenario Generation and Use - International Conference on
Requirements Engineering (ICRE '
98), p. 0148, April 1998.
MARTINS, L. E. G. - Uma Metodologia de Elicitao de Requisitos de
Software Baseada na Teoria da Atividade - Tese de Doutorado Unicamp,
Campinas, 2001.
MOISIADIS, F. - Prioritizing Scenario Evolution
- 4th International
Conference on Requirements Engineering (ICRE'

00), p. 85, June 2000.
MYLOPOULOS, J.; CHUNG, L.; YU, E. - From Object-Oriented to GoalOriented Requirements Analysis - COMMUNICATIONS OF THE ACM. Vol.
42, No. 1. January 1999.
NETO, G.C.; GOMES, S.G.; TEDESCO, P. Aliando Teoria da Atividade e
TROPOS na Elicitao de Requisitos de Ambientes Colaborativos de
Aprendizagem 6th International Workshop on Requirements Engineering.
Piracicaba, Brazil, November 27-28, 2003. Pages: 63-76. ISBN: 85-87926-07-1.
NUSEIBEH,
B.;
EASTERBROOK,
S.
Requirements
engineering: a
Roadmap - International Conference on Software Engineering Proceedings

of the conference on The future of Software engineering 2000 , Limerick,
Ireland - ACM Computing Surveys. Limerick, Ireland. Jun. 2000.
PETERS, J. F.; PEDRYCZ, W. Engenharia de Software-Teoria e Prtica.
Rio de Janeiro: Campus, 2001.
PRESSSMAN, R. S. Engenharia de Software. So Paulo: Makron Books,
1995.
REZENDE, D.A.; ABREU, A.F. Tecnologia da Informao : Aplicada a

Sistemas de Informao Empresariais. So Paulo: Atlas, 2000.
ROCCO, G.E. Um Modelo para Estruturao de Requisitos com Base em
Preceitos da Teoria da Atividade. Anais XXVIII Conferencia Latinoamericana
de Informtica (CLEI'
2002). Montevideo, Uruguay, Novembro, 2002.
ROLLAND, C.; ACHOUR, B.; CAUVET, C.; RALYT, J.; SUTCLIFFE, A.;
MAIDEN, N.; JARKE, M.; HAUMER, P.; POHL, K.; DUBOIS, E.; HEYMANS, P.
- A proposal for a scenario classification framework Journal of
Requirements Engineering Vol. 03 Springer Verlag, 1998.
SCHARER, L. Pinpointing Requirements Datamation, Apr. 1981, pp 139151. Reprinted with permission. Software Requirements Engineering / edited by
Richard H. Thayer and Merlin Dorfman, 1997.
SCOTT, W. A. - The Unified Modeling Language v1.1 and Beyond: The
Techniques of Object-Oriented Modeling - Copyright 1998-2000 Scott W.
Ambler.
SILVA, A. Requirements, Domain and Specifications: a Viewpoint-Based
Approach to Requirements Engineering - International Conference on
Software Engineering - Proceedings of the 24th international conference on
Software engineering, Orlando, Florida, 2002. Society Publisher ACM Press
New York, NY, USA. Pages: 94 104. ISBN:1-58113-472-X
SOMMERVILLE, I.; SAWYER, P. Requirements Engineering Good Pratice
Giuide.. 1 edio. Editora John Eiley e Sons Ltd. Publicao 1997.
REQUIREMENTS ENGINEERING/A GOOD PRACTICE GUIDE.
SOMMERVILLE, I; SAWYER, P; VILLER, S. - Viewpoints for Requirements
Elicitation: A Practical Approach - International Conference on Requirements
Engineering (ICRE '
98), p. 0074, April 1998.
THAYER, R. H.; DORFMAN, M. Software Requirements Engineering. 2

edio - Editora IEEE, 1997 - Washington
TORANZO, M.; CASTRO, J. A Comprehensive Traceability Model to
Support the Design of Interactive Systems. International Workshop on
Interactive System Development and Object Models - WISDOM 99. Lisboa,
Portugal. Jun. 1999.
UCHITEL, S.; KRAMAER, J.; MAGEE, J. - Synthesis of Behavioral Models
from Scenarios - IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
VOL. 29, NO. 2, FEBRUARY 2003.
WERTSCH, J. V. Estudos Socioculturais da Mente. Trad. Paiva, Maria da
Graa e Camargo, Andr Rossano Teixeira, Porto Alegre, ArtMed, 1998.
ZAVE, P. Classification of Research Efforts in Requirements Engineering
ACM Computing Surveys, Vol. 29, No 4, 1997, p. 315-321.
ZORMAN, L. Requirements Envisaging Through Utilizing Scenarios REBUS Ph.D. Dissertation, University of Southern California 1995.

VMEPWGALFNMD

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

VMEPWGALFNMD

Caricato da

Copyright:

Formati disponibili

UNIVERSIDADE METODISTA DE PIRACICABA

FACULDADE DE CINCIAS EXATAS E DA NATUREZA

ESPECIFICAO E IMPLEMENTAO DE UMA FERRAMENTA PARA

UNIVERSIDADE METODISTA DE PIRACICABA

ESPECIFICAO E IMPLEMENTAO DE UMA FERRAMENTA PARA

Dissertao apresentada ao Programa de PsGraduao em Cincia da Computao, da

1. Elicitao de requisitos. 2. Teoria da atividade. 3. Engenharia de

ESPECIFICAO E IMPLEMENTAO DE UMA FERRAMENTA PARA

AUTOR: SIMONE FRANCETO

Dissertao de Mestrado defendida em 20/12/2005, pela Banca Examinadora

Dr. Teresa Gonalves Kirner (UNIMEP)

Dr. Ariadne Maria Brito Rizzoni Carvalho (UNICAMP)

perseverana. Ao meu noivo, muito amor e compreenso.

A Deus primeiramente pela fora e luz ao longo de todo este

O futuro depender daquilo que fazemos no presente.

Uma Engenharia de Requisitos (ER) bem estruturada garante qualidade,

REQUISITOS, FERRAMENTA AUTOMATIZADA, METODOLOGIA

A well structured Requirements Engineering (ER) guarantees quality,

KEYWORDS: REQUIREMENTS ELICITATION, ACTIVITY THEORY, SOFTWARE ENGINEERING,

THEORY OF ACTIVITY (META).

LISTA DE ABREVIATURAS E SIGLAS

Atomicidade, Consistncia, Isolamento,Durabilidade

Engenharia de Requisitos de Software

Metodologia de Elicitao de Requisitos de Software Baseado

Unified Modeling Language

Universidade Metodista de Piracicaba

Universidade Estadual de Campinas

PROCESSO INTERATIVO DA ER...........................................................................

EXEMPLO DE CASOS DE USO.............................................................................

DESCRIO DETALHADA DE CASOS DE USO........................................................

RESULTADO PARCIAL DA ANALISE DE REQUISITOS NO FUNCIONAL PARA UM SISTEMA DE APOIO

ANALISE DE REQUISITOS FUNCIONAIS PARA UM SISTEMA DE APOIO ESCRITRIO

ESTRUTURA BSICA DE UMA ATIVIDADE (KUUTTI, 1996)...................................

NVEIS HIERRQUICOS DE UMA ATIVIDADE (KUUTTI, 1996) ................................

ETAPAS DA METODOLOGIA DE ELICITAO PROPOSTA (MARTINS, 2001).............

DECOMPOSIO DA ETAPA DIVISO DO PROBLEMA EM ATIVIDADE (MARTINS,

DECOMPOSIO DA ETAPA DELINEAMENTO DO CONTEXTO DA ATIVIDADE (MARTINS,

DECOMPOSIO DA ETAPA DESCRIO DA ESTRUTURA HIERRQUICA DA

RELACIONAMENTO ENTRE OS ELEMENTOS QUE FORMAM A ESTRUTURA

RELACIONAMENTO ENTRE OS ELEMENTOS QUE FORMAM O CONTEXTO DA

TIPOS DE RELACIONAMENTO REPRESENTADOS NO DIAGRAMA DE ENGESTRM......

DOCUMENTO DE REGISTRO DO PROTOCOLO DAS CHAMADAS TELEFNICAS...........

MODELO SISTMICO PARA A ATIVIDADE CRIAR PROTOCOLO...............................

MODELO SISTMICO PARA A ATIVIDADE CONSULTAR PROTOCOLO POR DATA......

ESTRUTURA DA ATIVIDADE {A1} LEVANTAR ATIVIDADES CANDIDATAS.................

ESTRUTURA DA ATIVIDADE {A2} SELECIONAR ATIVIDADES..................................

ESTRUTURA DA ATIVIDADE {A3} DESCREVER HISTRICO DAS ATIVIDADES

ESTRUTURA DA ATIVIDADE {A4} IDENTIFICAR OS MOTIVOS E RESULTADOS DAS

ESTRUTURA DA ATIVIDADE {A5} IDENTIFICAR OS ELEMENTOS NO NVEL

ESTRUTURA DA ATIVIDADE {A6} IDENTIFICAR OS ELEMENTOS NO NVEL

ESTRUTURA DA ATIVIDADE {A7} MODELAR A ATIVIDADE ATRAVS DO DIAGRAMA

ESTRUTURA DA ATIVIDADE {A8} IDENTIFICAR AS AES E OPERAES DA

ESTRUTURA DA ATIVIDADE {A9} DESCREVER AS METAS DAS AES...................

ESTRUTURA DA ATIVIDADE {A10} DESCREVER AS CONDIES DE REALIZAO

MODELAGEM LGICA DA FERRAMENTA...............................................................

MODELO ARQUITETURAL DAS CLASSES IMPLEMENTADAS REFERENTE A DIVISO DO PROBLEMA

MODELO ARQUITETURAL DAS CLASSES IMPLEMENTADAS REFERENTE

MODELO ARQUITETURAL DAS CLASSES IMPLEMENTADAS REFERENTE

REPRESENTAO FSICA DO BANCO DE DADOS DA FERRAMENTA.........................

INTERFACE: CADASTRO DE PROJETOS................................................................

INTERFACE: MENSAGEM COM DEFINIO DA ATIVIDADE CANDIDATA.....................

INTERFACE: CADASTRO DAS ATIVIDADES CANDIDATAS.........................................

INTERFACE: CADASTRO DAS ATIVIDADES SELECIONADAS.....................................

INTERFACE: CADASTRO DOS RESULTADOS DAS ATIVIDADES.................................