Notas Aula Engenharia Requisitos

UFES - Universidade Federal do Esprito Santo
Engenharia de Requisitos
Notas de Aula
Ricardo de Almeida Falbo

E-mail: falbo@inf.ufes.br
2012
Sumrio
Captulo 1 - Introduo
1.1 Desenvolvimento de Software e Engenharia de Requisitos
1.2 A Organizao deste Texto
Captulo 2 Engenharia de Requisitos de Software
2.1 Requisitos
2.2 O Processo de Engenharia de Requisitos
2.3 Engenharia de Requisitos e Normas e Modelos de Qualidade
Captulo 3 Levantamento de Requisitos
3.1 Viso Geral do Levantamento de Requisitos
3.2 Tcnicas de Levantamento de Requisitos
3.3 Requisitos e Modelagem de Processos de Negcio
3.4 Escrevendo e Documentando Requisitos de Usurio
Captulo 4 Anlise de Requisitos
4.1 Modelagem Conceitual
4.2 A Linguagem de Modelagem Unificada
4.3 O Paradigma Orientado a Objetos
4.4 Um Mtodo de Anlise de Requisitos Funcionais
4.5 Especificao de Requisitos No Funcionais
4.6 O Documento de Especificao de Requisitos
Captulo 5 Modelagem de Casos de Uso
1
1
3
5
5
8
23
29
29
33
54
57
70
72
73
74
81
83
84
87
5.1 Atores e Casos de Uso

5.2 Diagramas de Casos de Uso
5.3 Descrevendo Casos de Uso
5.4 Relacionamentos entre Casos de Uso
5.5 Trabalhando com Casos de Uso
88
91
93
104
113
Captulo 6 Modelagem Conceitual Estrutural
118
6.1 Identificao de Classes

6.2 Identificao de Atributos e Associaes
6.3 Especificao de Hierarquias de Generalizao / Especializao
Captulo 7 Modelagem Dinmica
7.1 Tipos de Requisies de Ao
7.2 Diagramas de Grfico de Estados
7.3 Diagramas de Atividades
7.4 Especificao das Operaes
119
122
134
138
137
141
151
155
Captulo 8 Qualidade e Agilidade em Requisitos

8.1 Tcnicas de Leitura de Modelos da Anlise de Requisitos
8.2 Modelagem gil
8.3 Reutilizao na Engenharia de Requisitos
Anexo A A Norma ISO/IEC 9126
158
159
162
164
173
Este trabalho foi licenciado com uma Licena Creative Commons - AtribuioNoComercial-SemDerivados 3.0 No Adaptada.
Engenharia de Requisitos: Notas de Aula

Captulo 1 Introduo
Sistemas de software so reconhecidamente importantes ativos estratgicos para
diversas organizaes. Uma vez que tais sistemas, em especial os sistemas de informao, tm
um papel vital no apoio aos processos de negcio das organizaes, fundamental que os
sistemas funcionem de acordo com os requisitos estabelecidos. Neste contexto, uma
importante tarefa no desenvolvimento de software a identificao e o entendimento dos
requisitos dos negcios que os sistemas vo apoiar (AURUM; WOHLIN, 2005).
A Engenharia de Requisitos o processo pelo qual os requisitos de um produto de
software so coletados, analisados, documentados e gerenciados ao longo de todo o ciclo de
vida do software (AURUM; WOHLIN, 2005). Este texto aborda o processo de Engenharia de
Requisitos, concentrando-se nas atividades de levantamento de requisitos e modelagem
conceitual.
Este captulo apresenta o tema e como o mesmo tratado neste texto. A Seo 1.1
discute a relao entre a Engenharia de Requisitos e o processo de software. A Seo 1.2
apresenta a organizao deste texto.
1.1 Desenvolvimento de Software e Engenharia de Requisitos

Um processo de software envolve diversas atividades que podem ser classificadas
quanto ao seu propsito em:
Atividades de Desenvolvimento (ou Tcnicas): so as atividades diretamente

relacionadas ao processo de desenvolvimento do software, ou seja, que contribuem
diretamente para o desenvolvimento do produto de software a ser entregue ao
cliente. So exemplos de atividades de desenvolvimento: levantamento e anlise de
requisitos, projeto e implementao.
Atividades de Gerncia: envolvem atividades relacionadas ao gerenciamento do

projeto de maneira abrangente. Incluem, dentre outras: atividades de planejamento
e acompanhamento gerencial do projeto (processo de Gerncia de Projetos), tais
como realizao de estimativas, elaborao de cronogramas, anlise dos riscos do
projeto etc.; atividades relacionadas gerncia da evoluo dos diversos artefatos
produzidos nos projetos de software (processo de Gerncia de Configurao);
atividades relacionadas gerncia de ativos reutilizveis de uma organizao
(processo de Gerncia de Reutilizao) etc.
Atividades de Controle da Qualidade: so aquelas relacionadas com a avaliao da

qualidade do produto em desenvolvimento e do processo de software utilizado.
Incluem atividades de verificao, validao e garantia da qualidade.
As atividades de desenvolvimento formam a espinha dorsal do desenvolvimento e so

realizadas segundo uma ordem estabelecida no planejamento. As atividades de gerncia e de

controle da qualidade so, muitas vezes, ditas atividades de apoio, pois no esto ligadas
diretamente construo do produto final, ou seja, o software a ser entregue para o cliente,
incluindo toda a documentao necessria. Essas atividades, normalmente, so realizadas ao
longo de todo o ciclo de vida, sempre que necessrio ou em pontos pr-estabelecidos durante
o planejamento, ditos marcos ou pontos de controle. A Figura 1.1 mostra a relao entre esses
tipos de atividades.
Atividades de Gerncia
Atividades de Desenvolvimento
Produto de
Software
Atividades de Controle da Qualidade

Figura 1.1 Atividades do Processo de Software
No que concerne s atividades tcnicas, tipicamente o processo de software inicia-se
com o Levantamento de Requisitos, quando os requisitos do sistema a ser desenvolvido so
preliminarmente capturados e organizados. Uma vez capturados, os requisitos devem ser
modelados, avaliados e documentados. Uma parte essencial dessa fase a elaborao de
modelos descrevendo o qu o software tem de fazer (e no como faz-lo), dita Modelagem
Conceitual. At este momento, a nfase est sobre o domnio do problema e no se deve
pensar na soluo tcnica, computacional a ser adotada.
Com os requisitos pelo menos parcialmente capturados e especificados na forma de
modelos, pode-se comear a trabalhar no domnio da soluo. Muitas solues so possveis
para o mesmo conjunto de requisitos e elas so intrinsecamente ligadas a uma dada
plataforma de implementao (linguagem de programao, mecanismo de persistncia a ser
adotado etc.). A fase de projeto tem por objetivo definir e especificar uma soluo a ser
implementada. uma fase de tomada de deciso, tendo em vista que muitas solues so
possveis.
Uma vez projetado o sistema, pode dar-se incio implementao, quando as unidades
de software do projeto so implementadas e testadas individualmente. Gradativamente, os
elementos vo sendo integrados e testados (teste de integrao), at se obter o sistema, quando
o todo deve ser testado (teste de sistema). Por fim, uma vez testado no ambiente de
desenvolvimento, o software pode ser colocado em produo. Usurios devem ser treinados, o
ambiente de produo deve ser configurado e o sistema deve ser instalado e testado, agora
pelos usurios no ambiente de produo (testes de homologao ou aceitao). Caso o
software demonstre prover as capacidades requeridas, ele pode ser aceito e a operao
iniciada.
Requisitos tm um papel central no desenvolvimento de software, uma vez que uma
das principais medidas do sucesso de um software o grau no qual ele atende aos objetivos e
requisitos para os quais foi construdo. Requisitos so a base para estimativas, modelagem,
projeto, implementao, testes e at mesmo para a manuteno. Portanto, esto presentes ao
longo de todo o ciclo de vida de um software.

Nos estgios iniciais de um projeto, requisitos tm de ser levantados, entendidos e

documentados (atividades de Levantamento, Anlise e Documentao de Requisitos). Dada a
importncia dos requisitos para o sucesso de um projeto, atividades de controle da qualidade
devem ser realizadas para verificar, validar e garantir a qualidade dos requisitos, uma vez que
os custos sero bem maiores se defeitos em requisitos forem identificados tardiamente.
Mesmo quando coletados de forma sistemtica, requisitos mudam. Os negcios so dinmicos
e no h como garantir que os requisitos no sofrero alteraes. Assim, fundamental
gerenciar a evoluo dos requisitos, bem como manter a rastreabilidade entre os requisitos e
os demais artefatos produzidos no projeto (atividade de Gerncia de Requisitos).
Como se pode observar, o tratamento de requisitos envolve atividades de
desenvolvimento (Levantamento, Anlise e Documentao de Requisitos), gerncia (Gerncia
de Requisitos) e controle da qualidade (Verificao, Validao e Garantia da Qualidade de
Requisitos). Ao conjunto de atividades relacionadas a requisitos, d-se o nome de Processo de
Engenharia de Requisitos.
1.2 - A Organizao deste Texto

Este texto procura oferecer uma viso geral da Engenharia de Requisitos de Software,
discutindo as principais atividades desse processo e como realiz-las. nfase especial dada
aplicao das tcnicas de modelagem e especificao de Sistemas de Informao, i.e.,
sistemas desenvolvidos para apoiar processos de negcio das organizaes.
Nos captulos que se seguem, os seguintes temas so abordados:
Captulo 2 Engenharia de Requisitos de Software: inicia discutindo o que so

requisitos e tipos e nveis de requisitos. A seguir, apresenta o processo de
engenharia de requisitos considerado neste texto, o qual contm as seguintes
atividades: Levantamento de Requisitos, Anlise de Requisitos, Documentao de
Requisitos, Verificao e Validao de Requisitos e Gerncia de Requisitos.
Discute-se, tambm, como as principais normas e modelos de qualidade de
processos de software tratam a questo dos requisitos.
Captulo 3 Levantamento de Requisitos: prov uma viso geral do processo de

levantamento de requisitos e aborda tcnicas para levantar requisitos, dentre elas
entrevistas, questionrios, observao, investigao de documentos e
prototipagem. Aborda-se, tambm, a modelagem de processos de negcio e como
ela pode apoiar o levantamento de requisitos. Finalmente, discute-se como
escrever e documentar requisitos de usurio.
Captulo 4 Anlise de Requisitos: trata da anlise de requisitos, discutindo a

anlise e especificao de requisitos funcionais (modelagem conceitual) e no
funcionais. O captulo inicia provendo uma introduo modelagem conceitual.
Na sequncia apresentada brevemente a Linguagem de Modelagem Unificada
(Unified Modeling Language UML), amplamente usada na Anlise de Requisitos
e os conceitos da orientao a objetos, paradigma adotado neste texto. Um mtodo
de anlise de requisitos funcionais apresentado. A seguir, discute-se a
especificao de requisitos no funcionais. Por fim, a documentao da atividade
de anlise de requisitos abordada.

Captulo 5 Modelagem de Casos de Uso: discute o papel da modelagem de casos

de uso na especificao de requisitos funcionais de sistema. Apresenta os
elementos centrais da modelagem de casos de uso, o diagrama de casos de uso da
UML e discute como descrever casos de uso textualmente.
Captulo 6 Modelagem Estrutural: trata da modelagem dos principais conceitos

do domnio, suas relaes e propriedades, permitindo representar o conhecimento
do domnio relevante para o sistema em desenvolvimento. A elaborao de
diagramas de classes da UML o foco deste captulo.
Captulo 7 Modelagem Dinmica: aborda os modelos usados para especificar as

mudanas vlidas no estado dos objetos de domnio, bem como para modelar o
comportamento esperado do sistema. O foco deste captulo a elaborao de
diagramas de estados e diagramas de atividades.
Captulo 8 Qualidade e Agilidade em Requisitos: explora tcnicas de leitura de

modelos, visando apoiar a verificao da consistncia entre os diversos artefatos
produzidos durante a anlise de requisitos; apresenta o enfoque da modelagem
gil; e discute abordagens para reutilizao na Engenharia de Requisitos, dentre
elas Engenharia de Domnio, Ontologias e Padres de Anlise.
Referncias do Captulo
AURUM, A., WOHLIN, C., Engineering and Managing Software Requirements, SpringerVerlag, 2005.


Requisitos tm um papel central no processo de software, sendo considerados
um fator determinante para o sucesso ou fracasso de um projeto de software. O processo
de levantar, analisar, documentar, gerenciar e controlar a qualidade dos requisitos
chamado de Engenharia de Requisitos.
Este captulo d uma viso geral da Engenharia de Requisitos. A Seo 2.1
apresenta diferentes definies do conceito de requisito e trata de tipos e nveis de
requisitos. A Seo 2.2 aborda o processo de engenharia de requisitos, discutindo cada
uma de suas atividades. Finalmente, a Seo 2.3 discute como as principais normas e
modelos de qualidade de processos de software tratam a questo dos requisitos.
2.1 Requisitos
Existem diversas definies para requisito de software na literatura, dentre elas:
Requisitos de um sistema so descries dos servios que devem ser

fornecidos por esse sistema e as suas restries operacionais
(SOMMERVILLE, 2007).
Um requisito de um sistema uma caracterstica do sistema ou a descrio

de algo que o sistema capaz de realizar para atingir seus objetivos
(PFLEEGER, 2004).
Um requisito alguma coisa que o produto tem de fazer ou uma qualidade

que ele precisa apresentar (ROBERTSON; ROBERTSON, 2006).
Com base nessas e em outras definies, pode-se dizer que os requisitos de um

sistema incluem especificaes dos servios que o sistema deve prover, restries sob as
quais ele deve operar, propriedades gerais do sistema e restries que devem ser
satisfeitas no seu processo de desenvolvimento.
As vrias definies acima apresentadas apontam para a existncia de diferentes
tipos de requisitos. Uma classificao amplamente aceita quanto ao tipo de informao
documentada por um requisito faz a distino entre requisitos funcionais e requisitos
no funcionais.
Requisitos Funcionais: so declaraes de servios que o sistema deve

prover, descrevendo o que o sistema deve fazer (SOMMERVILLE, 2007).
Um requisito funcional descreve uma interao entre o sistema e o seu
ambiente (PFLEEGER, 2004), podendo descrever, ainda, como o sistema
deve reagir a entradas especficas, como o sistema deve se comportar em
situaes especficas e o que o sistema no deve fazer (SOMMERVILLE,
2007).
Requisitos No Funcionais: descrevem restries sobre os servios ou

funes oferecidos pelo sistema (SOMMERVILLE, 2007), as quais limitam

as opes para criar uma soluo para o problema (PFLEEGER, 2004).

Neste sentido, os requisitos no funcionais so muito importantes para a fase
de projeto (design), servindo como base para a tomada de decises nessa
fase.
Os requisitos no funcionais tm origem nas necessidades dos usurios, em
restries de oramento, em polticas organizacionais, em necessidades de
interoperabilidade com outros sistemas de software ou hardware ou em fatores externos
como regulamentos e legislaes (SOMMERVILLE, 2007). Assim, os requisitos no
funcionais podem ser classificados quanto sua origem. Existem diversas classificaes
de requisitos no funcionais. Sommerville (2007), por exemplo, classifica-os em:
Requisitos de produto: especificam o comportamento do produto (sistema).

Referem-se a atributos de qualidade que o sistema deve apresentar, tais como
confiabilidade, usabilidade, eficincia, portabilidade, manutenibilidade e
segurana.
Requisitos organizacionais: so derivados de metas, polticas e

procedimentos das organizaes do cliente e do desenvolvedor. Incluem
requisitos de processo (padres de processo e modelos de documentos que
devem ser usados), requisitos de implementao (tal como a linguagem de
programao a ser adotada), restries de entrega (tempo para chegar ao
mercado - time to market, restries de cronograma etc.), restries
oramentrias (custo, custo-benefcio) etc.
Requisitos externos: referem-se a todos os requisitos derivados de fatores

externos ao sistema e seu processo de desenvolvimento. Podem incluir
requisitos de interoperabilidade com sistemas de outras organizaes,
requisitos legais (tais como requisitos de privacidade) e requisitos ticos.
No que se refere aos RNFs de produto, eles podem estar relacionados a

propriedades emergentes do sistema como um todo, ou seja, propriedades que no
podem ser atribudas a uma parte especfica do sistema, mas que, ao contrrio, s
aparecem aps a integrao de seus componentes, tal como confiabilidade
(SOMMERVILLE, 2007). Contudo, algumas vezes, essas caractersticas podem estar
associadas a uma funo especfica ou a um conjunto de funes. Por exemplo, uma
certa funo pode ter restries severas de desempenho, enquanto outras funes do
mesmo sistema no apresentam tal restrio.
Ainda que a classificao em requisitos funcionais e no funcionais seja a mais
amplamente aceita, h outras classificaes de requisitos. Por exemplo, Sommerville
(2007) considera, alm de requisitos funcionais e no funcionais, requisitos de domnio.
Segundo esse autor, requisitos de domnio so provenientes do domnio de aplicao do
sistema e refletem caractersticas e restries desse domnio. Eles so derivados do
domnio de aplicao e podem restringir requisitos funcionais existentes ou estabelecer
como clculos especficos devem ser realizados, refletindo fundamentos do domnio de
aplicao.
Requisitos de domnio na concepo de Sommerville so o que outros autores,
tal como Wiegers (2003), chamam de regras de negcio. Por exemplo, em um sistema
de matrcula de uma universidade, uma importante regra de negcio diz que um aluno
s pode se matricular em uma turma de uma disciplina se ele tiver cumprido seus pr-

requisitos. Essas regras de negcio geralmente incluem terminologia especfica do

domnio e fazem referncia a conceitos do domnio (SOMMERVILLE, 2007). Assim,
so mais facilmente capturadas na fase de modelagem conceitual.
Os requisitos devem ser redigidos de modo a serem passveis de entendimento
pelos diversos interessados (stakeholders). Clientes1, usurios finais e desenvolvedores
so todos interessados em requisitos, mas tm expectativas diferentes. Enquanto
desenvolvedores e usurios finais tm interesse em detalhes tcnicos, clientes requerem
descries mais abstratas. Assim, til apresentar requisitos em diferentes nveis de
descrio. Sommerville (2007) sugere dois nveis de descrio de requisitos:
Requisitos de Usurio: so declaraes em linguagem natural

acompanhadas de diagramas intuitivos de quais servios so esperados do
sistema e das restries sob as quais ele deve operar. Devem estar em um
nvel de abstrao mais alto, de modo que sejam compreensveis pelos
usurios do sistema que no possuem conhecimento tcnico.
Requisitos de Sistema: definem detalhadamente as funes, servios e

restries do sistema. So verses expandidas dos requisitos de usurio
usados pelos desenvolvedores para projetar, implementar e testar o sistema.
Como requisitos de sistema so mais detalhados, as especificaes em
linguagem natural so insuficientes e para especific-los, notaes mais
especializadas devem ser utilizadas.
Vale destacar que esses nveis de descrio de requisitos so aplicados em

momentos diferentes e com propsitos distintos. Requisitos de usurio so elaborados
nos estgios iniciais do desenvolvimento (levantamento preliminar de requisitos) e
servem de base para um entendimento entre clientes e desenvolvedores acerca do que o
sistema deve contemplar. Esses requisitos so, normalmente, usados como base para a
contratao e o planejamento do projeto. Requisitos de sistema, por sua vez, so
elaborados como parte dos esforos diretos para o desenvolvimento do sistema,
capturando detalhes importantes para as fases tcnicas posteriores do processo de
desenvolvimento, a saber: projeto, implementao e testes.
Entretanto, no se deve perder de vista que requisitos de sistema so derivados
dos requisitos de usurio. Os requisitos de sistema acrescentam detalhes, explicando os
servios e funes a serem providos pelo sistema em desenvolvimento. Os interessados
nos requisitos de sistema necessitam conhecer mais precisamente o que o sistema far,
pois eles esto preocupados com o modo como o sistema apoiar os processos de
negcio ou porque esto envolvidos na sua construo (SOMMERVILLE, 2007).
Uma vez que requisitos de usurio e de sistema tm propsitos e pblico alvo
diferentes, til descrev-los em documentos diferentes. Pfleeger (2004) sugere que
dois tipos de documentos de requisitos sejam elaborados:
Documento de Definio de Requisitos, ou somente Documento de

Requisitos: deve ser escrito de maneira que o cliente possa entender, i.e., na
importante notar a distino que se faz aqui entre clientes e usurios finais. Consideram-se clientes
aqueles que contratam o desenvolvimento do sistema e que, muitas vezes, no usaro diretamente o
sistema. Eles esto mais interessados nos resultados da utilizao do sistema pelos usurios do que no
sistema em si. Usurios, por outro lado, so as pessoas que utilizaro o sistema em seu dia a dia. Ou seja,
os usurios so as pessoas que vo operar ou interagir diretamente com o sistema.

forma de uma listagem do qu o cliente espera que o sistema proposto faa.

Ele representa um consenso entre o cliente e o desenvolvedor sobre o qu o
cliente quer.
Documento de Especificao de Requisitos: redefine os requisitos de

usurio em termos mais tcnicos, apropriados para o desenvolvimento de
software, sendo produzido por analistas de requisitos.
Vale ressaltar que deve haver uma correspondncia direta entre cada requisito de
usurio listado no documento de requisitos e os requisitos de sistema tratados no
documento de especificao de requisitos.
2.2 O Processo de Engenharia de Requisitos

A Engenharia de Requisitos de Software o ramo da Engenharia de Software
que envolve as atividades relacionadas com a definio dos requisitos de software de
um sistema, desenvolvidas ao longo do ciclo de vida de software (KOTONYA;
SOMMERVILLE, 1998).
O processo de engenharia de requisitos envolve criatividade, interao de
diferentes pessoas, conhecimento e experincia para transformar informaes diversas
(sobre a organizao, sobre leis, sobre o sistema a ser construdo etc.) em documentos e
modelos que direcionem o desenvolvimento de software (KOTONYA;
SOMMERVILLE, 1998).
A Engenharia de Requisitos fundamental, pois possibilita, dentre outros,
estimar custo e tempo de maneira mais precisas e melhor gerenciar mudanas em
requisitos. Dentre os problemas de um processo de engenharia de requisitos ineficiente,
podem-se citar (KOTONYA; SOMMERVILLE, 1998): (i) requisitos inconsistentes, (ii)
produto final com custo maior do que o esperado, (iii) software instvel e com altos
custos de manuteno e (iv) clientes insatisfeitos.
A Engenharia de Requisitos pode ser descrita como um processo, ou seja, um
conjunto organizado de atividades que deve ser seguido para derivar, avaliar e manter os
requisitos e artefatos relacionados. Uma descrio de um processo, de forma geral, deve
incluir, alm das atividades a serem seguidas, a estrutura ou sequncia dessas
atividades, quem responsvel por cada atividade, suas entradas e sadas, as
ferramentas usadas para apoiar as atividades e os mtodos, tcnicas e diretrizes a serem
seguidos na sua realizao.
Processos de engenharia de requisitos podem variar muito de uma organizao
para outra, ou at mesmo dentro de uma organizao especfica, em funo de
caractersticas dos projetos. A definio de um processo apropriado organizao traz
muitos benefcios, pois uma boa descrio do mesmo fornecer orientaes e reduzir a
probabilidade de esquecimento ou de uma execuo superficial. No entanto, no faz
sentido falar em processo ideal ou definir algum e imp-lo a uma organizao. Ao invs
disto, as organizaes devem iniciar com um processo genrico e adapt-lo para um
processo mais detalhado, que seja apropriado s suas reais necessidades
(SOMMERVILLE; SAWYER, 1997).
A implantao de processos em uma organizao deve ser feita segundo as
necessidades da mesma, ou seja, o processo deve ser definido de acordo com as

caractersticas da organizao. Existem, portanto, fatores que contribuem para a

variabilidade do processo de engenharia de requisitos, dentre eles a maturidade tcnica,
o envolvimento disciplinar, a cultura organizacional e os domnios de aplicao nos
quais a organizao atua (KOTONYA; SOMMERVILLE, 1998).
Wiegers (2003) destaca alguns benefcios que um processo de Engenharia de
Requisitos de alta qualidade pode trazer, dentre eles: menor quantidade de defeitos nos
requisitos, reduo de retrabalho, desenvolvimento de menos caractersticas
desnecessrias, diminuio de custos, desenvolvimento mais rpido, menos problemas
de comunicao, alteraes de escopo reduzidas, estimativas mais confiveis e maior
satisfao dos clientes e membros da equipe.
Ainda que diferentes projetos requeiram processos com caractersticas
especficas para contemplar suas peculiaridades, possvel estabelecer um conjunto de
atividades bsicas que deve ser considerado na definio de um processo de engenharia
de requisitos. Tomando por base o processo proposto por Kotonya e Sommerville
(1998), neste texto considera-se que um processo de engenharia de requisitos deve
contemplar, tipicamente, as atividades mostradas na Figura 2.1: levantamento de
requisitos, anlise de requisitos, documentao de requisitos, verificao e validao de
requisitos e gerncia de requisitos.
Figura 2.1 Processo de Engenharia de Requisitos (adaptado de (KOTONYA;

SOMMERVILLE, 1998))
O processo comea pelo levantamento de requisitos, que deve levar em conta
necessidades dos usurios e clientes, informaes de domnio, sistemas existentes,
regulamentos, leis etc. Uma vez identificados requisitos, possvel iniciar a atividade de
anlise, quando os requisitos levantados so usados como base para a modelagem do
sistema. Tanto no levantamento quanto na anlise de requisitos, importante
documentar requisitos e modelos. Conforme discutido anteriormente, para documentar
requisitos, dois documentos so normalmente utilizados: o Documento de Requisitos,
contendo uma lista dos requisitos de usurio identificados, e o Documento de
Especificao de Requisitos, que registra os requisitos de sistema e os vrios diagramas
resultantes do trabalho de anlise. Os documentos produzidos so, ento, verificados e
validados. Adicionalmente, um esforo de garantia da qualidade deve ser realizado,

10
visando garantir conformidade em relao a padres e ao processo estabelecidos pela

organizao. Caso clientes, usurios e desenvolvedores estejam de acordo com os
requisitos, o processo de desenvolvimento pode avanar; caso contrrio, deve-se
retornar atividade correspondente para resolver os problemas identificados. Em
paralelo a todas as atividades anteriormente mencionadas, h a gerncia de requisitos,
que se ocupa em gerenciar mudanas nos requisitos.
Vale destacar que no h limites bem definidos entre as atividades acima citadas.
Na prtica, elas so intercaladas e existe um alto grau de iterao e feedback entre elas.
O processo executado at que todos os usurios estejam satisfeitos e concordem com
os requisitos ou at que a presso do cronograma precipite o incio da fase de projeto, o
que indesejvel (KOTONYA; SOMMERVILLE, 1998).
Alm disso, ao se adotar um modelo de ciclo de vida iterativo, essas atividades
podem ser realizadas muitas vezes. Pode-se comear com um levantamento preliminar
de requisitos que considere apenas requisitos de usurio. Esses requisitos podem ser
documentados em um Documento de Requisitos e avaliados (verificao e validao).
Caso haja acordo em relao aos requisitos de usurio, pode-se iniciar um ciclo de
levantamento detalhado de requisitos e anlise, produzindo uma verso do Documento
de Especificao de Requisitos. Quando h acordo em relao aos requisitos e modelos
contidos nesse documento, o desenvolvimento pode prosseguir para a poro tratada
nessa iterao, enquanto um novo ciclo de levantamento e anlise se inicia para tratar
outros aspectos do sistema.
A seguir, as atividades do processo de engenharia de requisitos proposto so
discutidas com um pouco mais de detalhes.
2.2.1 Levantamento de Requisitos

O levantamento de requisitos corresponde fase inicial do processo de
engenharia de requisitos e envolve as atividades de descoberta dos requisitos. Nessa
fase, um esforo conjunto de clientes, usurios e especialistas de domnio necessrio,
com o objetivo de entender a organizao, seus processos, necessidades, deficincias
dos sistemas de software atuais, possibilidades de melhorias, bem como restries
existentes. Trata-se de uma atividade complexa que no se resume somente a perguntar
s pessoas o que elas desejam, mas sim analisar cuidadosamente a organizao, o
domnio da aplicao e os processos de negcio no qual o sistema ser utilizado
(KOTONYA; SOMMERVILLE, 1998).
Para levantar quais so os requisitos de um sistema, devem-se obter informaes
dos interessados (stakeholders), consultar documentos, obter conhecimentos do domnio
e estudar o negcio da organizao. Neste contexto, quatro dimenses devem ser
consideradas, como ilustra a Figura 2.2 (KOTONYA; SOMMERVILLE, 1998):

11
Levantamento de requisitos
Figura 2.2 - Dimenses do levantamento de requisitos
Entendimento do domnio da aplicao: entendimento geral da rea na

qual o sistema ser aplicado;
Entendimento do problema: entendimento dos detalhes do problema

especfico a ser resolvido com o auxlio do sistema a ser desenvolvido;
Entendimento do negcio: entender como o sistema ir afetar a organizao

e como contribuir para que os objetivos do negcio e os objetivos gerais da
organizao sejam atingidos;
Entendimento das necessidades e das restries dos interessados:

entender as demandas de apoio para a realizao do trabalho de cada um dos
interessados no sistema, entender os processos de trabalho a serem apoiados
pelo sistema e o papel de eventuais sistemas existentes na execuo e
conduo dos processos de trabalho. Consideram-se interessados no sistema,
todas as pessoas que so afetadas pelo sistema de alguma maneira, dentre
elas clientes, usurios finais e gerentes de departamentos onde o sistema ser
instalado.
A atividade de levantamento de requisitos dominada por fatores humanos,

sociais e organizacionais e envolve pessoas com diferentes conhecimentos e objetivos, o
que a torna complexa. Christel e Kang (apud PRESSMAN, 2006) citam alguns
problemas que tornam o levantamento de requisitos uma tarefa difcil:
Problemas de escopo: as fronteiras do sistema so mal definidas ou os

clientes/usurios especificam detalhes tcnicos desnecessrios que podem
confundir, em vez de esclarecer, os objetivos globais do sistema.
Problemas de entendimento: Os clientes/usurios no esto completamente

certos do que necessrio, tm pouca compreenso das capacidades e
limitaes de um ambiente computacional, no tm pleno entendimento do
domnio do problema, tm dificuldade de comunicar suas necessidades,
omitem informao que acreditam ser bvia, especificam requisitos que
conflitam com as necessidades de outros clientes/usurios ou especificam
requisitos que so ambguos ou impossveis de testar.
Problemas de volatilidade: Os requisitos mudam ao longo do tempo.

12
Kotonya e Sommerville (1998) destacam outras dificuldades que complementam e

reforam os problemas apontados por Christel e Kang, a saber:
Pode ser difcil compreender e coletar informaes quando existem muitos

termos desconhecidos, manuais tcnicos etc.
Pessoas que entendem o problema a ser resolvido podem ser muito ocupadas e
no ter muito tempo para, juntamente como analista, levantar os requisitos e
entender o sistema.
Polticas organizacionais podem influenciar nos requisitos de um sistema.
Os interessados no sabem muito bem o que querem do sistema e no

conhecem muitos termos.
Diversas tcnicas podem ser utilizadas no levantamento de requisitos, as quais

podem possuir diferentes objetos de investigao ou podem ter foco em tipos diferentes
de requisitos. Assim, til empregar vrias dessas tcnicas concomitantemente, de
modo a se ter um levantamento de requisitos mais eficaz. Dentre as vrias tcnicas,
podem ser citadas (KENDALL; KENDALL, 2010; KOTONYA; SOMMERVILLE,
1998; AURUM; WOHLIN, 2005):
Entrevistas: tcnica amplamente utilizada, que consiste em conversas

direcionadas com um propsito especfico e com formato pergunta-resposta.
Seu objetivo descobrir problemas a serem tratados, levantar procedimentos
importantes e saber a opinio e as expectativas do entrevistado sobre o
sistema.
Questionrios: o uso de questionrios possibilita ao analista obter informaes

como postura, crenas, comportamentos e caractersticas de vrias pessoas que
sero afetas pelo sistema.
Observao: consiste em observar o comportamento e o ambiente dos

indivduos de vrios nveis organizacionais. Utilizando-se essa tcnica,
possvel capturar o que realmente feito e qual tipo de suporte computacional
realmente necessrio. Ajuda a confirmar ou refutar informaes obtidas com
outras tcnicas e ajuda a identificar tarefas que podem ser automatizadas e que
no foram identificadas pelos interessados.
Anlise de documentos: pela anlise de documentos existentes na organizao,

analistas capturam informaes e detalhes difceis de conseguir por entrevista
e observao. Documentos revelam um histrico da organizao e sua direo.
Cenrios: com o uso desta tcnica, um cenrio de interao entre o usurio

final e o sistema montado e o usurio simula sua interao com o sistema
nesse cenrio, explicando ao analista o que ele est fazendo e de que
informaes ele precisa para realizar a tarefa descrita no cenrio. O uso de
cenrios ajuda a entender requisitos, a expor o leque de possveis interaes e
a revelar facilidades requeridas.
Prototipagem: um prottipo uma verso preliminar do sistema, muitas vezes

no operacional e descartvel, que apresentada ao usurio para capturar
informaes especficas sobre seus requisitos de informao, observar reaes

13
iniciais e obter sugestes, inovaes e informaes para estabelecer

prioridades e redirecionar planos.
Dinmicas de Grupo: h vrias tcnicas de levantamento de requisitos que
procuram explorar dinmicas de grupo para a descoberta e o desenvolvimento
de requisitos, tais como Brainstorming e JAD (Joint Application
Development). Na primeira, representantes de diferentes grupos de
interessados engajam-se em uma discusso informal para rapidamente
gerarem o maior nmero possvel de ideias. Na segunda, interessados e
analistas se renem para discutir problemas a serem solucionados e solues
possveis. Com as diversas partes envolvidas representadas, decises podem
ser tomadas e questes podem ser resolvidas mais rapidamente. A principal
diferena entre JAD e Brainstorming que, em JAD, tipicamente os objetivos
do sistema j foram estabelecidos antes dos interessados participarem. Alm
disso, sesses JAD so normalmente bem estruturadas, com passos, aes e
papis de participantes definidos.
2.2.2 Anlise de Requisitos

Uma vez identificados requisitos, possvel iniciar a atividade de anlise,
quando os requisitos levantados so usados como base para a modelagem do sistema.
Conforme discutido anteriormente, requisitos de usurio so escritos tipicamente em
linguagem natural, pois eles devem ser compreendidos por pessoas que no sejam
especialistas tcnicos. Contudo, til expressar requisitos mais detalhados do sistema
de maneira mais tcnica. Para tal, diversos tipos de modelos podem ser utilizados. Esses
modelos so representaes grficas que descrevem processos de negcio, o problema a
ser resolvido e o sistema a ser desenvolvido. Por utilizarem representaes grficas,
modelos so geralmente mais compreensveis do que descries detalhadas em
linguagem natural (SOMMERVILLE, 2007).
De maneira simples, um modelo uma simplificao da realidade enfocando
certos aspectos considerados relevantes segundo a perspectiva do modelo, e omitindo os
demais. Modelos so construdos para se obter uma melhor compreenso da poro da
realidade sendo modelada.
Em essncia, a fase de anlise uma atividade de modelagem. A modelagem
nesta fase dita conceitual, pois ela se preocupa com o domnio do problema e no com
solues tcnicas para o mesmo. Os modelos de anlise so elaborados para se obter
uma compreenso maior acerca do sistema a ser desenvolvido e para especific-lo.
Diferentes modelos podem ser construdos para representar diferentes perspectivas.
Tipicamente, duas principais perspectivas so consideradas na fase de anlise:
Perspectiva estrutural: busca modelar os conceitos, propriedades e relaes

do domnio que so relevantes para o sistema em desenvolvimento. Prov
uma viso esttica das informaes que o sistema necessita tratar e, portanto,
refere-se s representaes que o sistema ter de prover para abstrair
entidades do mundo real. Diagramas de classes so usados para modelar esta
perspectiva.
Perspectiva comportamental: visa modelar o comportamento geral do

sistema, de uma de suas funcionalidades ou de uma entidade especfica ao

14
longo do tempo. Prov uma viso do comportamento do sistema ou de uma

parcela do sistema. Diagramas de casos de uso, diagramas de atividades,
diagramas de estados e diagramas de interao so usados para modelar essa
viso.
Os modelos criados durante a atividade de anlise de requisitos cumprem os
seguintes papis (PRESSMAN, 2006):
Ajudam o analista a entender a informao, a funo e o comportamento do

sistema, tornando a tarefa de anlise de requisitos mais fcil e sistemtica;
Tornam-se o ponto focal para a reviso e, portanto, a chave para a

determinao da consistncia da especificao.
A anlise de requisitos uma atividade extremamente vinculada ao

levantamento de requisitos. Durante o levantamento de requisitos, alguns problemas so
identificados e tratados. Entretanto, determinados problemas somente so identificados
por meio de uma anlise mais detalhada. A anlise de requisitos ajuda a entender e
detalhar os requisitos levantados, a descobrir problemas nesses requisitos e a obter a
concordncia sobre as alteraes, de modo a satisfazer a todos os envolvidos. Seu
objetivo estabelecer um conjunto acordado de requisitos completos, consistentes e sem
ambiguidades, que possa ser usado como base para as demais atividades do processo de
desenvolvimento de software (KOTONYA; SOMMERVILLE, 1998).
De forma resumida, pode-se dizer que a anlise atende a dois propsitos
principais: (i) prover uma base para o entendimento e concordncia entre clientes e
desenvolvedores sobre o que o sistema deve fazer e (ii) prover uma especificao que
guie os desenvolvedores na demais etapas do desenvolvimento, sobretudo no projeto,
implementao e testes do sistema (PFLEEGER, 2004).
O processo de engenharia de requisitos dominado por fatores humanos, sociais
e organizacionais. Ele envolve pessoas de diferentes reas de conhecimento e com
objetivos individuais e organizacionais diferentes. Dessa forma, comum que cada
indivduo tente influenciar os requisitos para que seu objetivo seja alcanado, sem
necessariamente alcanar os objetivos dos demais (KOTONYA; SOMMERVILLE,
1998).
Problemas e conflitos encontrados nos requisitos devem ser listados. Usurios,
clientes, especialistas de domnio e engenheiros de requisitos devem discutir os
requisitos que apresentam problemas, negociar e chegar a um acordo sobre as
modificaes a serem feitas. Idealmente, as discusses devem ser governadas pelas
necessidades da organizao, incluindo o oramento e o cronograma disponveis. No
entanto, muitas vezes, as negociaes so influenciadas por consideraes polticas e os
requisitos so definidos em funo da posio e da personalidade dos indivduos e no
em funo de argumentos e razes (KOTONYA; SOMMERVILLE, 1998).
A maior parte do tempo da negociao utilizada para resolver conflitos de
requisitos. Quando discusses informais entre analistas, especialistas de domnio e
usurios no forem suficientes para resolver os problemas, necessria a realizao de
reunies de negociao, que envolvem (KOTONYA; SOMMERVILLE, 1998):
Discusso: os requisitos que apresentam problemas so discutidos e os

interessados presentes opinam sobre eles.

15
Priorizao: requisitos so priorizados para identificar requisitos crticos e ajudar

nas decises e planejamento.
Concordncia: solues para os problemas so identificadas, mudanas so

feitas e um acordo sobre o conjunto de requisitos acertado.
2.2.3 Documentao de Requisitos

Os requisitos e modelos capturados nas etapas anteriores devem ser descritos e
apresentados em documentos. A documentao , portanto, uma atividade de registro e
oficializao dos resultados da engenharia de requisitos. Como resultado, um ou mais
documentos devem ser produzidos.
Uma boa documentao fornece muitos benefcios, tais como (IEEE, 1998;
NUSEIBEH; EASTERBROOK, 2000): (i) facilita a comunicao dos requisitos; (ii)
reduz o esforo de desenvolvimento, pois sua preparao fora usurios e clientes a
considerar os requisitos atentamente, evitando retrabalho nas fases posteriores; (iii)
fornece uma base realstica para estimativas; (iv) fornece uma base para verificao e
validao; (v) facilita a transferncia do software para novos usurios e/ou mquinas e
(vi) serve como base para futuras manutenes ou incremento de novas funcionalidades.
A documentao dos requisitos tem um conjunto diversificado de interessados,
dentre eles (SOMMERVILLE, 2007; KOTONYA; SOMMERVILLE, 1998):
Clientes, Usurios e Especialistas de Domnio: so interessados na

documentao de requisitos, uma vez que atuam na especificao, avaliao
e alterao de requisitos.
Gerentes de Cliente: utilizam o documento de requisitos para planejar um

pedido de proposta para o desenvolvimento de um sistema, contratar um
fornecedor e para acompanhar o desenvolvimento do sistema.
Gerentes de Fornecedor: utilizam a documentao dos requisitos para

planejar uma proposta para o sistema e para planejar e acompanhar o
processo de desenvolvimento.
Desenvolvedores (analistas, projetistas, programadores e mantenedores):

utilizam a documentao dos requisitos para compreender o sistema e as
relaes entre suas partes.
Testadores: utilizam a documentao dos requisitos para projetar casos de

teste, sobretudo testes de validao do sistema.
Diferentes interessados tm propsitos diferentes. Assim, pode ser til ter mais
do que um documento para registrar os resultados da engenharia de requisitos.
Conforme discutido anteriormente, Pfleeger (2004) sugere que dois tipos de
documentos de requisitos sejam elaborados: um Documento de Definio de Requisitos
e um Documento de Especificao de Requisitos.
O Documento de Definio de Requisitos, ou simplesmente Documento de
Requisitos, deve conter uma descrio do propsito do sistema, uma breve descrio do
domnio do problema tratado pelo sistema e listas de requisitos funcionais, no
funcionais e regras de negcio, descritos em linguagem natural (requisitos de usurio).

16
Para facilitar a identificao e rastreamento dos requisitos, devem-se utilizar

identificadores nicos para cada um dos requisitos listados. O pblico-alvo deste
documento so os clientes, usurios, gerentes (de cliente e de fornecedor) e
desenvolvedores.
O Documento de Especificao de Requisitos deve conter os requisitos escritos a
partir da perspectiva do desenvolvedor, devendo haver uma correspondncia direta com
os requisitos no Documento de Requisitos, de modo a se ter requisitos rastreveis. Os
vrios modelos produzidos na fase de anlise devem ser apresentados no Documento de
Especificao de Requisitos, bem como glossrios de termos usados e outras
informaes julgadas relevantes.
Deve-se observar que no h um padro definido quanto quantidade e ao nome
dos documentos de requisitos. H organizaes que optam por ter apenas um
documento de requisitos, contendo diversas sees, algumas tratando de requisitos do
usurio, outras tratando de requisitos de sistema. Outras organizaes, por sua vez,
fazem uso de vrios documentos distintos, capturando em documentos separados, por
exemplo, requisitos funcionais, requisitos no funcionais, modelos de caso de uso e
modelos estruturais e comportamentais. De fato, cabe a cada organizao definir a
quantidade, o nome e o contedo de cada documento. Para estruturar o contedo,
necessrio que a organizao defina seus modelos de documentos de requisitos.
Vrias diretrizes tm sido propostas com objetivo de melhorar a estrutura e
organizao da documentao de requisitos, dentre elas (SOMMERVILLE; SAWYER,
1997; KOTONYA; SOMMERVILLE, 1998; PRESSMAN, 2006; WIEGERS, 2003): (i)
definir um modelo de documento para cada tipo de documento a ser considerado,
definindo um padro de estrutura para o documento; (ii) explicar como cada classe de
leitores deve usar os diferentes tipos de documentos; (iii) incluir uma seo explicando
por que o software necessrio e como ir contribuir para os objetivos gerais de
negcio da organizao; (iv) definir termos especializados em um glossrio; (v)
organizar o layout do documento para facilitar a leitura; (vi) auxiliar os leitores a
encontrar a informao, incluindo recursos tais como listas de contedo e ndices, e
organizando os requisitos em captulos, sees e subsees identificadas; (vii)
identificar as fontes dos requisitos de modo a manter dados da origem do requisito, de
modo que, quando alguma mudana for solicitada, seja possvel saber com quem essa
mudana deve ser discutida e avaliada; (viii) criar um identificador nico para cada
requisito, de modo a facilitar a rastreabilidade e o controle de mudanas; (ix)
documentar tambm as regras do negcio e definir ligaes entre os requisitos e as
regras correspondentes e (x) tornar o documento fcil de alterar.
2.2.4 Verificao e Validao de Requisitos

As atividades de Verificao & Validao (V&V) devem ser iniciadas o quanto
antes no processo de desenvolvimento de software, pois quanto mais tarde os defeitos
so encontrados, maiores os custos associados sua correo (ROCHA;
MALDONADO; WEBER, 2001). Uma vez que os requisitos so a base para o
desenvolvimento, fundamental que eles sejam cuidadosamente avaliados. Assim, os
documentos produzidos durante a atividade de documentao de requisitos devem ser
submetidos verificao e validao.

17
importante realar a diferena entre verificao e validao. O objetivo da

verificao assegurar que o software esteja sendo construdo de forma correta. Devese verificar se os artefatos produzidos atendem aos requisitos estabelecidos e se os
padres organizacionais (de produto e processo) foram consistentemente aplicados. Por
outro lado, o objetivo da validao assegurar que o software que est sendo
desenvolvido o software correto, ou seja, assegurar que os requisitos, e o software
deles derivado, atendem ao uso proposto (ROCHA; MALDONADO; WEBER, 2001).
No caso de requisitos, a verificao feita, sobretudo, em relao consistncia
entre requisitos e modelos e conformidade com padres organizacionais de
documentao de requisitos. J a validao tem de envolver a participao de usurios e
clientes, pois somente eles so capazes de dizer se os requisitos atendem aos propsitos
do sistema.
Nas atividades de V&V de requisitos, examinam-se os documentos de requisitos
para assegurar que (PRESSMAN, 2006; KOTONYA; SOMMERVILLE, 1998;
WIEGERS, 2003): (i) todos os requisitos do sistema tenham sido declarados de modo
no-ambguo, (ii) as inconsistncias, conflitos, omisses e erros tenham sido detectados
e corrigidos, (iii) os documentos esto em conformidade com os padres estabelecidos e
(iv) os requisitos realmente satisfazem s necessidades dos clientes e usurios. Em
outras palavras, idealmente, um requisito, seja ele uma regra de negcio, requisito
funcional ou no funcional, deve ser (WIEGERS, 2003; PFLEEGER, 2004):
Completo: o requisito deve descrever completamente a funcionalidade a ser

entregue (no caso de requisito funcional), a regra de negcio a ser tratada (no
caso de regras de negcio) ou a restrio a ser considerada (no caso de
requisito no funcional). Ele deve conter as informaes necessrias para que
o desenvolvedor possa projetar, implementar e testar essa funcionalidade,
regra ou restrio.
Correto: cada requisito deve descrever exatamente a funcionalidade, regra ou

restrio a ser construda.
Consistente: o requisito no deve ser ambguo ou conflitar com outro

requisito.
Realista: deve ser possvel implementar o requisito com a capacidade e com

as limitaes do sistema e do ambiente de desenvolvimento.
Necessrio: o requisito deve descrever algo que o cliente realmente precisa

ou que requerido por algum fator externo ou padro da organizao.
Passvel de ser priorizado: os requisitos devem ter ordem de prioridade para

facilitar o gerenciamento durante o desenvolvimento do sistema.
Verificvel e passvel de confirmao: deve ser possvel desenvolver testes

para verificar se o requisito foi realmente implementado.
Rastrevel: deve ser possvel identificar quais requisitos foram tratados em

um determinado artefato, bem como identificar que produtos foram
originados a partir de um requisito.
Neste contexto til (WIEGERS, 2003):

18
Realizar revises dos documentos de requisitos, procurando por problemas

(conflitos, omisses, inconsistncias, desvios dos padres etc) e discutindo
solues.
Definir casos de teste para os requisitos especificados.
Definir critrios de aceitao de requisitos, i.e., os usurios devem descrever

como vo determinar se o produto atende s suas necessidades e se adequado
para uso.
De maneira geral, i.e., sem estarem restritas a requisitos, as atividades de V&V

envolvem anlises estticas e dinmicas. A anlise dinmica (ou testes) objetiva detectar
defeitos ou erros no software por meio da execuo do produto. J a anlise esttica no
envolve a execuo do produto, sendo feita por meio de revises dos artefatos a serem
avaliados (ROCHA; MALDONADO; WEBER, 2001). No caso de requisitos, podem-se
realizar revises dos documentos de requisitos para avaliar requisitos e modelos (anlise
esttica), bem como possvel utilizar prototipagem para validar requisitos (anlise
dinmica).
A anlise dinmica, neste caso, se justifica, pois, muitas vezes, as pessoas
encontram dificuldades em visualizar como os requisitos sero traduzidos em um
sistema. Essa dificuldade pode ser amenizada por meio de prottipos, que auxiliam os
usurios na identificao de problemas e na sugesto de melhorias dos requisitos. Dessa
forma, a prototipagem pode ser utilizada no processo de validao de requisitos.
Entretanto, sua utilizao nessa fase tem uma relao custo-benefcio mais efetiva
quando ela tiver sido empregada tambm na fase de levantamento de requisitos
Das atividades de verificao e validao, a atividade de teste considerada um
elemento crtico para a garantia da qualidade dos artefatos produzidos ao longo do
desenvolvimento e, por conseguinte, do produto de software final (ROCHA;
MALDONADO; WEBER, 2001). Contudo, exceto por meio de prottipos ou
especificaes de requisitos executveis (estas um recurso muito pouco utilizado na
prtica), no possvel testar requisitos. Entretanto, uma das caractersticas de
qualidade de um requisito bem elaborado ser testvel e, portanto, uma boa maneira de
identificar problemas nos requisitos definir casos de teste para os mesmos. Se um
requisito est incompleto, inconsistente ou ambguo, pode ser difcil definir casos de
teste para ele (KOTONYA; SOMMERVILLE, 1998).
Definir casos de teste para requisitos e avaliar prottipos so importantes meios
de se verificar e validar requisitos. Contudo, imprescindvel, ainda, realizar revises
dos documentos de requisitos. De maneira geral, em uma reviso, processos,
documentos e outros artefatos so revisados por um grupo de pessoas, com o objetivo
de avaliar se os mesmos esto em conformidade com os padres organizacionais
estabelecidos e se o propsito de cada um deles est sendo atingido. Assim, o objetivo
de uma reviso detectar erros e inconsistncias em artefatos e processos, sejam eles
relacionados forma, sejam eles em relao ao contedo, e apont-los aos responsveis
pela sua elaborao (ROCHA; MALDONADO; WEBER, 2001).
Em um formato de reviso tcnica formal, o processo de reviso comea com o
planejamento da reviso, quando uma equipe de reviso formada, tendo frente um
lder. A equipe de reviso deve incluir membros da equipe que possam ser efetivamente

19
teis para atingir o objetivo da reviso. Muitas vezes, a pessoa responsvel pela
elaborao do artefato a ser revisado integra a equipe de reviso (ROCHA;
MALDONADO; WEBER, 2001).
O propsito da reviso deve ser previamente informado e o material a ser
revisado deve ser entregue com antecedncia para que cada membro da equipe de
reviso possa avali-lo. Uma vez que todos estejam preparados, uma reunio
convocada pelo lder. Dando incio reunio de reviso, normalmente, o autor do
artefato apresenta o mesmo e descreve a perspectiva utilizada para a sua construo. O
lder orientar o processo de reviso, passando por todos os aspectos relevantes a serem
revistos. Todas as consideraes dos vrios membros da equipe de reviso devem ser
discutidas e as decises registradas, dando origem a uma ata de reunio de reviso,
contendo uma lista de defeitos encontrados. Essa reunio deve ser relativamente breve
(duas horas, no mximo), uma vez que todos j devem estar preparados para a mesma
(ROCHA; MALDONADO; WEBER, 2001).
No que se refere reviso de requisitos, diversas tcnicas de leitura podem ser
usadas. A mais simples a leitura ad-hoc, na qual os revisores aplicam seus prprios
conhecimentos na reviso dos documentos de requisitos. Diferentemente de uma
abordagem ad-hoc, outras tcnicas buscam aumentar a eficincia dos revisores,
direcionando os esforos para as melhores prticas de deteco de defeitos. Tcnicas de
leitura baseada em listas de verificao (checklists), leitura baseada em perspectivas e
leitura de modelos orientados a objetos so bastante usadas na verificao e validao
de documentos de requisitos.
Checklists definem uma lista de aspectos que devem ser verificados pelos
revisores, guiando-os no trabalho de reviso. Podem ser usados em conjunto com outras
tcnicas, tais como as tcnicas de leitura baseada em perspectiva e leitura de modelos
orientados a objetos.
A tcnica de leitura baseada em perspectiva foi desenvolvida especificamente
para a verificao e validao de requisitos. Ela explora a observao de quais
informaes de requisitos so mais ou menos importantes para as diferentes formas de
utilizao do documento de requisitos. Cada revisor realiza a reviso segundo uma
perspectiva diferente. Algumas perspectivas tipicamente consideradas so as
perspectivas de clientes, desenvolvedores e testadores. Checklists para cada uma dessas
perspectivas podem ser providos (ROCHA; MALDONADO; WEBER, 2001).
A leitura de modelos orientados a objetos prope um conjunto de tcnicas de
leitura para reviso dos diferentes diagramas utilizados durante um projeto orientado a
objetos. Cada uma das tcnicas definida para um conjunto de diagramas a serem
analisados em conjunto. O processo de leitura realizado de duas maneiras: a leitura
horizontal diz respeito consistncia entre artefatos elaborados em uma mesma fase,
procurando verificar se esses artefatos esto descrevendo consistentemente diferentes
aspectos de um mesmo sistema, no nvel de abstrao relacionado fase em questo; a
leitura vertical refere-se consistncia entre artefatos elaborados em diferentes fases
(anlise e projeto) (ROCHA; MALDONADO; WEBER, 2001).

20
2.2.5 Gerncia de Requisitos

Mudanas nos requisitos ocorrem ao longo de todo o processo de software,
desde o levantamento e anlise de requisitos at durante a operao do sistema. Elas so
decorrentes de diversos fatores, tais como descoberta de erros, omisses, conflitos e
inconsistncias nos requisitos, melhor entendimento por parte dos usurios de suas
necessidades, problemas tcnicos, de cronograma ou de custo, mudana nas prioridades
do cliente, mudanas no negcio, aparecimento de novos competidores, mudanas
econmicas, mudanas na equipe, mudanas no ambiente onde o software ser instalado
e mudanas organizacionais ou legais. Para minimizar as dificuldades impostas por
essas mudanas, necessrio gerenciar requisitos (TOGNERI, 2002).
O processo de gerncia de requisitos envolve as atividades que ajudam a equipe
de desenvolvimento a identificar, controlar e rastrear requisitos e gerenciar mudanas de
requisitos em qualquer momento ao longo do ciclo de vida do software (KOTONYA;
SOMMERVILLE, 1998; PRESSMAN, 2006). Os principais objetivos desse processo
so (KOTONYA; SOMMERVILLE, 1998):
Gerenciar alteraes nos requisitos acordados.
Gerenciar relacionamentos entre requisitos.
Gerenciar dependncias entre requisitos e outros documentos produzidos

durante o processo de software.
Para tal, o processo de gerncia de requisitos deve incluir as seguintes

atividades, ilustradas na Figura 2.3 (WIEGERS, 2003): controle de mudanas, controle
de verso, acompanhamento do estado dos requisitos e rastreamento de requisitos.
Figura 2.3 - Atividades da Gerncia de Requisitos (WIEGERS, 2003)

O controle de mudana define os procedimentos, processos e padres que devem
ser utilizados para gerenciar as alteraes de requisitos, assegurando que qualquer
proposta de mudana seja analisada conforme os critrios estabelecidos pela
organizao (KOTONYA; SOMMERVILLE, 1998). Mudanas podem ser necessrias
em diferentes momentos e por diferentes razes. De maneira geral, o controle de
mudanas envolve atividades como (KOTONYA; SOMMERVILLE, 1998; WIEGERS,
2003):

21
Verificar se uma mudana vlida.
Descobrir quais os requisitos e artefatos afetados pela mudana, o que

envolve rastrear informaes.
Estimar o impacto e o custo das mudanas.
Negociar as mudanas com os clientes.
Alterar requisitos e documentos associados.
Para garantir uma abordagem consistente, recomenda-se que as organizaes

definam um conjunto de polticas de gerncia de mudana, contemplando (KOTONYA;
SOMMERVILLE, 1998):
o processo de solicitao de mudana e as informaes necessrias para

processar cada solicitao;
o processo de anlise de impacto e de custos da mudana, alm das

informaes de rastreabilidade associadas;
os membros que formalmente avaliaro as mudanas;
as ferramentas que auxiliaro o processo.
Se as mudanas no forem controladas, alteraes com baixa prioridade podem

ser implementadas antes de outras mais importantes e modificaes com custo alto que
no so realmente necessrias podem ser aprovadas (TOGNERI, 2002).
Ao se detectar a necessidade de alterao em um ou mais requisitos, deve-se
registrar uma solicitao de mudana, a qual deve ser avaliada por algum membro da
equipe do projeto de software. Nessa avaliao, o impacto da alterao deve ser
determinado e valores de custo, esforo, tempo e viabilidade devem ser repassados ao
solicitante da mudana. Assim, uma parte crtica do controle de mudanas a avaliao
do impacto de uma mudana no restante do software. Para que seja possvel efetuar essa
avaliao, cada requisito deve estar identificado unicamente e deve ser possvel, por
exemplo, saber quais so os requisitos dependentes desse requisito e em quais artefatos
do processo de software esse requisito tratado. Portanto, necessrio estabelecer uma
rede de ligaes de modo que um requisito e os elementos ligados a ele possam ser
rastreados. Surge, ento, o conceito de rastreabilidade.
A rastreabilidade pode ser definida como a habilidade de se acompanhar a vida
de um requisito em ambas as direes do processo de software e durante todo o ciclo de
vida. Ela fornece uma base para o desenvolvimento de uma trilha de auditoria para todo
o projeto, possibilitando encontrar outros requisitos e artefatos que podem ser afetados
pelas mudanas solicitadas (PALMER, 1997). Para tal, necessrio haver ligaes entre
requisitos e entre requisitos e outros elementos do processo de software. Assim, a
identificao da composio de requisitos, das dependncias entre requisitos, de
requisitos conflitantes, da origem dos requisitos e de seus interessados, alm da
identificao de em quais artefatos produzidos durante o desenvolvimento de software
um requisito tratado, de fundamental importncia para que a rastreabilidade possa
ser implementada (WIEGERS, 2003; ROBERTSON; ROBERTSON, 2006;
KOTONYA; SOMMERVILLE, 1998).

22
Matrizes de rastreabilidade so os principais artefatos produzidos na fase de

gerncia de requisitos. Elas relacionam os requisitos identificados a um ou mais
aspectos do sistema ou do seu ambiente, de modo que elas possam ser procuradas
rapidamente para entender como uma modificao em um requisito vai afetar diferentes
aspectos do sistema. Dentre as muitas possveis matrizes de rastreabilidade, h as
seguintes:
Matriz de rastreabilidade de dependncia: indica como os requisitos esto

relacionados uns com os outros.
Matriz de rastreabilidade requisitos fontes: indica a fonte de cada

requisito.
Matriz de rastreabilidade requisitos subsistemas: indica os subsistemas

que tratam os requisitos.
Matriz de rastreabilidade requisitos de usurio casos de uso: indica os

casos de uso que detalham um requisito funcional ou tratam um requisito no
funcional ou regra de negcio.
Alm das matrizes de rastreabilidade de requisitos, outras matrizes de

rastreabilidade entre outros artefatos do processo podem ser construdas, de modo a
apoiar a gerncia de requisitos. Por exemplo, ao se estabelecer uma matriz de
rastreabilidade casos de uso classes, indicando que classes de um modelo de
anlise so necessrias para se tratar um caso de uso, possvel, em conjunto com uma
matriz de rastreabilidade requisitos de usurio casos de uso, saber que classes so
importantes no tratamento de um requisito de usurio.
Davis (apud KOTONYA; SOMMERVILLE, 1998) aponta quatro tipos de
rastreabilidade interessantes para que uma anlise de impacto de mudanas possa ser
feita mais facilmente, como ilustra a Figura 2.4:
Rastreabilidade regressiva
a partir dos requisitos
Fonte do Requisito
Rastreabilidade progressiva
em direo aos requisitos
Rastreabilidade progressiva
a partir dos requisitos
Requisitos
Outros Artefatos:
-Projeto (Design)
- Cdigo
- Testes etc.
Rastreabilidade regressiva
em direo aos requisitos
Figura 2.4 Tipos de Rastreabilidade

23
Regressiva a partir dos requisitos (backward-from traceability): relaciona

requisitos com suas origens (outros documentos ou pessoas);
Progressiva a partir dos requisitos (forward-from traceability): relaciona

requisitos aos artefatos do projeto (planos, modelos de anlise e projeto,
cdigo etc.);
Regressiva em direo aos requisitos (backward-to traceability): relaciona

artefatos do projeto aos requisitos;
Progressiva em direo aos requisitos (forward-to traceability): relaciona as

fontes (p.ex., documentos que precederam o documento de requisitos) aos
requisitos relevantes.
Embora a rastreabilidade de requisitos no possa ser completamente

automatizada, porque o conhecimento das ligaes se origina na mente dos membros da
equipe de desenvolvimento, uma vez identificadas essas ligaes, ferramentas de apoio
so importantssimas para ajudar a gerenciar a grande quantidade de informaes de
rastreabilidade (WIEGERS, 2003).
Requisitos guiam vrias atividades do processo de software, dentre elas
planejamento, projeto (design), codificao e testes, e, portanto, esses artefatos devem
ser rastreveis para e a partir dos requisitos. A seguir so citadas algumas situaes, em
diversas etapas, nas quais os requisitos so importantes (WIEGERS, 2003):
Planejamento de Projeto: requisitos so teis para dimensionar o projeto,

sendo utilizados para estimar o tamanho do produto. Planos devem ser
atualizados caso haja mudanas em requisitos e requisitos prioritrios so
usados para direcionar iteraes, quando modelos de ciclo de vida iterativos
so adotados.
Projeto e Codificao: requisitos, com destaque para os no funcionais, so

usados para direcionar o projeto da arquitetura do sistema e so alocados a
componentes. Mudanas em requisitos devem ser rastreadas para o projeto e
o cdigo gerado, de modo a guiar as alteraes.
Testes: requisitos so a base para diversos tipos de testes, dentre eles testes
de sistema e de aceitao.
2.3 Engenharia de Requisitos e Normas e Modelos de Qualidade

Visando qualidade no processo de software, modelos e normas de qualidade de
processo de software tm sido propostos, dentre eles o CMMI (Capability Maturity
Model Integration) (SEI, 2010) e o MPS.BR (SOFTEX, 2009).
O CMMI um modelo de qualidade de processo desenvolvido pelo Instituto de
Engenharia de Software (Software Engineering Institute SEI) da Universidade de
Carnegie Mellon. O CMMI para Desenvolvimento (CMMI-Dev) (SEI, 2010) enfoca o
processo de software e tem como objetivo fornecer diretrizes para a definio e
melhoria de processos de software de uma organizao. O CMMI, em sua representao
em estgio, possui cinco nveis de maturidade: 1- Inicial, 2- Gerenciado, 3- Definido, 4Gerenciado Quantitativamente e 5- Em Otimizao.

24
O CMMI-Dev trata de requisitos tanto no nvel 2, atravs da rea de processo

Gesto de Requisitos, quanto no nvel 3, por meio da rea de processo Desenvolvimento
de Requisitos. Na Gesto de Requisitos o objetivo gerenciar os requisitos dos produtos
e componentes de produto do projeto e garantir alinhamento entre esses requisitos e os
planos e produtos de trabalho do projeto (SEI, 2010). Para isso, o CMMI sugere as
seguintes prticas:
SG 1 Gerenciar Requisitos
SP 1.1 Entender os requisitos.
SP 1.2 Obter comprometimento com os requisitos.
SP 1.3 Gerenciar mudanas de requisitos.
SP 1.4 Manter rastreabilidade bidirecional dos requisitos.
SP 1.5 Garantir alinhamento entre o trabalho de projeto (planos de projeto e
produtos de trabalho) e requisitos.
O Desenvolvimento de Requisitos, por sua vez, visa levantar, analisar e
estabelecer requisitos de cliente, do produto e de componentes do produto (SEI, 2010).
Neste caso, o CMMI sugere as seguintes prticas:
SG 1 Desenvolver Requisitos de Cliente
SP 1.1 Levantar necessidades.
SP 1.2 Transformar necessidades dos interessados em requisitos de cliente.
SG 2 Desenvolver Requisitos do Produto
SP 2.1 Estabelecer os requisitos do produto e de componentes do produto.
SP 2.2 Alocar requisitos de componentes do produto.
SP 2.3 Identificar requisitos de interface.
SG 3 Analisar e Validar Requisitos
SP 3.1 Estabelecer conceitos e cenrios operacionais.
SP 3.2 Estabelecer uma definio da funcionalidade e dos atributos de
qualidade requeridos.
SP 3.3 Analisar requisitos.
SP 3.4 Analisar requisitos para balancear.
SP 3.5 Validar requisitos.
O MPS.BR (Melhoria de Processo do Software Brasileiro) (SOFTEX, 2011)
um programa mobilizador, que tem como objetivo a melhoria de processo do software
brasileiro. Uma das metas do programa MPS.BR definir e aprimorar um modelo de
melhoria e avaliao de processo de software, visando preferencialmente s micro,
pequenas e mdias empresas, de forma a atender as suas necessidades de negcio e ser
reconhecido nacional e internacionalmente como um modelo aplicvel indstria de
software.
O modelo MPS estabelece um modelo de processos de software e um processo e um
mtodo de avaliao de processos. Esta estrutura fornece sustentao e garante que o
modelo MPS seja empregado de forma coerente com as suas definies. sendo um modelo
direcionado para a realidade brasileira. A base tcnica do MPS composta pelas normas
ISO/IEC 12207 e ISO/IEC 15504-2, alm buscar garantir conformidade com o CMMI.
Essa abordagem visa garantir que o MPS est em conformidade com padres
internacionais.

25
Assim como o CMMI, o MPS organizado em nveis de maturidade. No caso

do MPS, contudo, so sete nveis, a saber: G- Parcialmente Gerenciado, F- Gerenciado,
E- Parcialmente Definido, D- Largamente Definido, C- Definido, B- Gerenciado
Quantitativamente, A- Em Otimizao. O MPS procura manter uma correspondncia
entre seus nveis de maturidade e os nveis de maturidade do CMMI. Assim, o nvel 2
do CMMI corresponde ao nvel F do MPS, o nvel 3 do CMMI ao nvel C do MPS, o
nvel 4 do CMMI ao nvel B do MPS e finalmente o nvel 5 do CMMI corresponde ao
nvel A do MPS.
O MPS define, em seu nvel G, o processo de Gerncia de Requisitos e no nvel
D o processo de Desenvolvimento de Requisitos. O propsito do processo de Gerncia
de Requisitos gerenciar os requisitos do produto e dos componentes do produto do
projeto e identificar inconsistncias entre os requisitos, os planos do projeto e os
produtos de trabalho do projeto. Esse processo tem como resultados esperados
(SOFTEX, 2011):
GRE 1. O entendimento dos requisitos obtido junto aos fornecedores de
requisitos;
GRE 2. Os requisitos so avaliados com base em critrios objetivos e um
comprometimento da equipe tcnica com esses requisitos obtido;
GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de
trabalho estabelecida e mantida;
GRE 4. Revises em planos e produtos de trabalho do projeto so realizadas
visando identificar e corrigir inconsistncias em relao aos requisitos;
GRE 5. Mudanas nos requisitos so gerenciadas ao longo do projeto.
O Desenvolvimento de Requisitos, por sua vez, tem por objetivo definir os
requisitos do cliente, do produto e dos componentes do produto. Esse processo tem
como resultados esperados (SOFTEX, 2011):
DRE 1. As necessidades, expectativas e restries do cliente, tanto do produto
quanto de suas interfaces, so identificadas;
DRE 2. Um conjunto definido de requisitos do cliente especificado e
priorizado a partir das necessidades, expectativas e restries identificadas;
DRE 3. Um conjunto de requisitos funcionais e no-funcionais, do produto e dos
componentes do produto que descrevem a soluo do problema a ser resolvido,
definido e mantido a partir dos requisitos do cliente;
DRE 4. Os requisitos funcionais e no-funcionais de cada componente do
produto so refinados, elaborados e alocados;
DRE 5. Interfaces internas e externas do produto e de cada componente do
produto so definidas;
DRE 6. Conceitos operacionais e cenrios so desenvolvidos;
DRE 7. Os requisitos so analisados, usando critrios definidos, para balancear
as necessidades dos interessados com as restries existentes;

26
DRE 8. Os requisitos so validados.

De uma maneira geral, pode-se constatar que a Engenharia de Requisitos, pela
sua importncia no contexto do desenvolvimento de software, cuidadosamente tratada
pelos principais modelos de qualidade de processo de software.
Leitura Complementar
Os livros de Kotonya e Sommerville (1998), Wiegers (2003) e Robertson e
Robertson (2006) so dedicados integralmente Engenharia de Requisitos e, portanto,
contemplam vrios dos aspectos tratados neste captulo e muito mais.
Em (KOTONYA; SOMMERVILLE, 1998) h uma excelente discusso sobre
Engenharia de Requisitos. O processo apresentado neste texto fortemente baseado no
processo proposto nesse livro. Em especial, os seguintes captulos tm informaes
muito relevantes para complementar os estudos baseados nestas notas de aula: Captulo
1 Introduction na forma de um FAQ (Frequently Asked Questions), aborda as
noes de requisitos e engenharia de requisitos; o Captulo 2 Requirements
Engineering Process d uma viso geral do processo de engenharia de requisitos, o
qual detalhado posteriormente nos captulos 3 Requirements Elicitation and
Analysis, 4 Requirements Validation e 5 Requirements Management. Ainda neste
livro, o Captulo 8 Non-functional Requirements discute requisitos no funcionais.
Em (WIEGERS, 2003) h tambm vrios captulos que abordam temas
discutidos nestas notas de aula. Sugere-se, em especial, a leitura dos captulos 1, 3 e 17.
O Captulo 1 The Essential Software Requirements aborda o que so requisitos,
nveis e tipos de requisitos, os processos de desenvolvimento e gerncia de requisitos e
caractersticas de qualidade de requisitos. O Captulo 3 Good Practices for
Requirements Engineering d uma viso geral do processo de engenharia de
requisitos, apontando boas prticas. Indica, ainda, outros captulos do livro que
discutem em detalhes as atividades do processo de engenharia de requisitos. O Captulo
17 Beyond Requirements Development discute as relaes entre requisitos e outros
artefatos do processo de software, dentre eles planos de projeto, projeto (design), cdigo
e testes.
Em (ROBERTSON; ROBERTSON, 2006) o foco tambm a Engenharia de
Requisitos e, portanto, h vrios captulos que abordam temas discutidos nestas notas de
aula. Sugere-se, em especial, a leitura dos captulos 1 e 2. O Captulo 1 What are
Requirements? aborda o que so requisitos e tipos de requisitos. Apresenta, ainda,
brevemente o processo de requisitos proposto no livro, denominado Volere, e o modelo
de documento de requisitos proposto. O Captulo 2 The Requirements Process d
uma viso geral do processo de requisitos, indicando os demais captulos do livro que
discutem em detalhes as suas atividades.
Livros de Engenharia de Software tambm abordam a Engenharia de Requisitos,
tendo em vista que requisitos so parte fundamental do processo de software. Dentre os
diversos livros de Engenharia de Software, sugerem-se trs: (SOMMERVILLE, 2007),
(PFLEEGER, 2004) e (PRESSMAN, 2006).
Em (SOMMERVILLE, 2007), a parte 2 Requisitos como o prprio nome
indica, dedicada ao tema. Merecem ateno especial os captulos 6 e 7. O Captulo 6

27
Requisitos de Software trata de tipos e nveis de requisitos, bem como da

documentao de requisitos. O Captulo 7 Processos de Engenharia de Requisitos
apresenta e discute um processo de engenharia de requisitos (tambm muito similar ao
apresentado neste texto) e suas atividades.
Em (PFLEEGER, 2004), o Captulo 4 Identificando Requisitos tem uma boa
discusso sobre requisitos. Em relao aos temas abordados nestas notas de aula,
merecem destaque as sees 4.1, 4.2, 4.3, 4.6, 4.7, 4.8 e 4.9, as quais tratam dos
seguintes assuntos: requisitos, processo de requisitos, tipos de documentos de requisitos,
tipos de requisitos, caractersticas de requisitos (sees 4.1, 4.2 e 4.3), prototipagem de
requisitos (seo 4.6), documentao de requisitos (seo 4.7), participantes no processo
de requisitos (seo 4.8) e validao de requisitos (seo 4.9).
Em (PRESSMAN, 2006), o Captulo 7 Engenharia de Requisitos aborda
vrios dos temas discutidos neste captulo, com destaque para as sees 7.2 (Tarefas da
Engenharia de Requisitos), 7.3 (Incio do Processo de Engenharia de Requisitos), 7.4
(Levantamento de Requisitos), 7.7 (Negociao de Requisitos) e 7.8 (Validao de
Requisitos).
Por fim, as sees 3.4 e 3.6 de (ROCHA; MALDONADO; WEBER, 2001)
discutem, respectivamente, a Verificao e Validao (V&V) de Software e Revises de
Software. Trata-se de discusses gerais para quaisquer artefatos e no discusses
focadas em requisitos, mas mesmo assim muito teis. Em especial a subseo 3.6.2
importante, pois discute as tcnicas de leitura de requisitos baseada em perspectivas e as
tcnicas de leitura de projetos orientados a objetos.
AURUM, A., WOHLIN, C., Engineering and Managing Software Requirements,
Springer-Verlag, 2005.
BLAHA, M., RUMBAUGH, J., Modelagem e Projetos Baseados em Objetos com UML
2, Elsevier, 2006.
IEEE, IEEE Recommended Practice for Software Requirements Specifications: IEEE
Std 830-1998. New York: IEEE, 1998.
KENDALL, K.E., KENDALL, J.E.; Systems Analysis and Design, Prentice Hall, 8th
Edition, 2010.
KOTONYA, G., SOMMERVILLE, I., Requirements engineering: processes and
techniques. Chichester, England: John Wiley, 1998.
NUSEIBEH, B., EASTERBROOK, S., Requirements engineering: a roadmap. In:
Proceedings of the Conference on the Future of Software Engineering, Limerick,
Ireland, 2000.
PALMER, J.D., Traceability. In: THAYER, H. R.; DORFMAN, M. (Org.) Software
requeriments engineering. 2nd edition, Los Alamitos, California: IEEE Computer
Society, p.364-374, 1997.
PFLEEGER, S.L., Engenharia de Software: Teoria e Prtica, So Paulo: Prentice Hall,
2 edio, 2004.

28
PRESSMAN, R.S., Engenharia de Software, McGraw-Hill, 6 edio, 2006.

ROBERTSON, S., ROBERTSON, J. Mastering the Requirements Process. 2nd Edition.
Addison Wesley, 2006.
ROCHA, A.R.C., MALDONADO, J.C., WEBER, K.C., Qualidade de Software: Teoria
e Prtica. So Paulo: Prentice Hall, 2001.
SEI, CMMI for Development, Version, 1.3, CMMI-Dev V1.3, CMU/SEI-2010-TR-033,
2010.
SOFTEX, MPS.BR Melhoria de Processo do Software Brasileiro Guia Geral: 2011,
Agosto 2011.
SOMMERVILLE, I., Engenharia de Software, 8 Edio. So Paulo: Pearson
SOMMERVILLE, I., SAWYER, P., Requirements engineering: a good practice guide.
Chichester, England: John Wiley, 1997.
TOGNERI, D.F., Apoio Automatizado Engenharia de Requisitos Cooperativa.
Dissertao (Mestrado em Informtica), Universidade Federal do Esprito Santo
(UFES), Vitria, 2002.
WIEGERS, K.E., Software Requirements: Practical techniques for gathering and
managing requirements throughout the product development cycle. 2nd Edition,
Microsoft Press, Redmond, Washington, 2003.

29

Analistas e desenvolvedores trabalham com clientes e usurios para saber mais sobre o
problema a ser resolvido, os servios a serem providos pelo sistema, restries etc. Isso no
significa apenas perguntar o que eles desejam do sistema. Ao contrrio, requer uma anlise
criteriosa da organizao, do domnio do problema e dos processos de negcio que sero
apoiados pelo sistema. O quadro fica ainda mais complicado por causa de diversos fatores,
dentre eles: raramente os clientes tm uma viso clara de seus requisitos; diferentes pessoas
em uma organizao tm diferentes requisitos, s vezes conflitantes; e h limitaes
financeiras, tecnolgicas e de prazos. Assim, levantar requisitos no uma tarefa simples
Este captulo enfoca o levantamento de requisitos. A Seo 3.1 procura dar uma viso
geral dessa atividade, discutindo problemas tpicos e tarefas a serem realizadas no
levantamento de requisitos. A Seo 3.2 apresenta algumas tcnicas para apoiar o
levantamento de requisitos. A Seo 3.3 discute como a modelagem de processos de negcio
pode ajudar na captura de requisitos de software. Finalmente, a Seo 3.4 discute formas de se
escrever e documentar requisitos.
3.1 Viso Geral do Levantamento de Requisitos

O levantamento de requisitos preocupa-se com o aprendizado e entendimento das
necessidades dos usurios e patrocinadores do projeto, com o objetivo final de comunicar
essas necessidades para os desenvolvedores do sistema. Uma parte substancial do
levantamento de requisitos dedicada a descobrir, extrair e aparar arestas dos desejos de
potenciais interessados (AURUM; WOHLIN, 2005).
A fase de levantamento de requisitos envolve buscar, junto aos usurios, clientes e
outros interessados, seus sistemas e documentos, todas as informaes possveis sobre as
funes que o sistema deve executar (requisitos funcionais) e as restries sob as quais ele
deve operar (requisitos no funcionais). O produto principal dessa fase so os documentos de
requisitos (WAZLAWICK, 2004).
Entretanto, conforme citado anteriormente, levantar requisitos no uma tarefa fcil.
Esta uma tarefa de natureza multidimensional e os analistas (ou engenheiros de requisitos)
se veem diante de vrios desafios, dentre eles (KOTONYA; SOMMERVILLE, 1998):
O conhecimento acerca do domnio de aplicao encontra-se disperso em uma

variedade de fontes, tais como livros, manuais e, sobretudo, nas cabeas das
pessoas que trabalham na rea. Alm disso, muitas vezes, envolve uma
terminologia especializada que no imediatamente compreensvel pelo analista.
As pessoas que entendem o problema a ser resolvido frequentemente esto muito

ocupadas para despender tempo ajudando os analistas a entender os requisitos para
um novo sistema. Elas podem, inclusive, no estar convencidas da necessidade do

30
novo sistema e, por conseguinte, no quererem se envolver no processo de

engenharia de requisitos.
Fatores polticos e questes organizacionais podem influenciar os requisitos para o

sistema, bem como o estabelecimento de suas prioridades.
Clientes e usurios frequentemente no sabem o que realmente querem do sistema,

exceto em termos muito gerais. Mesmo quando eles sabem o que querem, eles tm
dificuldade para articular os requisitos. Alm disso, podem ter demandas no
realistas por no estarem cientes dos custos de suas solicitaes.
O ambiente de negcio no qual ocorre o levantamento de requisitos est em

constante mudana. Os requisitos podem mudar, a sua importncia pode mudar e
novos requisitos podem surgir de novos interessados.
Dadas todas essas dificuldades, o levantamento de requisitos deve ser conduzido de

forma bastante cuidadosa, fazendo uso de tcnicas para capturar e especificar os requisitos
levantados.
Uma boa prtica consiste em fazer o levantamento de requisitos de forma incremental.
Inicialmente, em um levantamento preliminar de requisitos, apenas requisitos de usurio so
capturados. Depois, em vrias iteraes, outros requisitos de usurio so capturados e
requisitos de sistema vo sendo detalhados e especificados. Neste contexto, importante
realar que o levantamento e a anlise de requisitos so atividades estreitamente relacionadas
e, portanto, devem ocorrer em paralelo. Assim, medida que os requisitos vo sendo
detalhados, eles devem ser modelados e especificados.
O levantamento preliminar de requisitos tem por objetivo prover uma viso do todo
para se poder definir o que mais importante e depois dividir o todo em partes para
especificar os detalhes. Nessa fase, o levantamento rpido e genrico, sendo feito em
extenso e no em profundidade, i.e., o analista deve entender a extenso do que o sistema
deve fazer, mas sem entrar em detalhes. Somente nos ciclos iterativos os requisitos sero
detalhados, especificados e modelados (WAZLAWICK, 2004).
O levantamento preliminar de requisitos inicia-se com uma declarao de alto nvel,
informal e incompleta, da misso do projeto. Essa declarao pode ser apresentada na forma
de um conjunto de metas, funes e restries fundamentais para o sistema ou como uma
explicao sobre os problemas a serem resolvidos. Esses resultados preliminares formam a
base para investigao adicional e para o refinamento dos requisitos, de maneira tipicamente
iterativa e incremental. Assim, o levantamento de requisitos pode ser visto como um processo
realizado de forma incremental, ao longo de mltiplas sesses, iterativamente em direo a
nveis de detalhe cada vez maiores e pelo menos parcialmente em paralelo com outras
atividades do processo de software (AURUM; WOHLIN, 2005).
O levantamento de requisitos envolve um conjunto de atividades que deve permitir a
comunicao, priorizao, negociao e colaborao com todos os interessados relevantes.
Deve prover, ainda, uma base para o aparecimento, descoberta e inveno de requisitos, como
parte de um processo altamente interativo (AURUM; WOHLIN, 2005).
Zowghi e Coulin, em (AURUM; WOHLIN, 2005), indicam que as atividades do
processo de levantamento de requisitos podem ser agrupadas em cinco tipos fundamentais de
atividades, a saber:

31
Entendimento do Domnio de Aplicao: importante investigar e examinar em

detalhes a poro do mundo real onde o sistema vai residir, dita o domnio de
aplicao. Aspectos sociais, polticos e organizacionais, bem como processos de
trabalho existentes e problemas a serem resolvidos pelo sistema, precisam ser
descritos em relao a metas e questes do negcio.
Identificao de Fontes de Requisitos: requisitos podem estar espalhados em vrias

fontes e podem existir em vrios formatos. Assim, podem existir muitas fontes de
requisitos para um sistema e elas devem ser identificadas. Interessados
representam a fonte de requisitos mais bvia. Em especial, clientes, usurios e
especialistas de domnio so os mais indicados para fornecerem informao
detalhada sobre os problemas e as necessidades. Sistemas e processos existentes
so tambm fontes de requisitos, especialmente quando o projeto envolve a
substituio de um sistema existente. A documentao acerca desses sistemas e
processos de negcio, incluindo manuais, formulrios e relatrios, bem como de
padres da indstria, leis e regulamentaes, prov informao til sobre a
organizao e seu ambiente. Outras fontes incluem especificaes de requisitos de
sistemas (quando o sistema envolve hardware e software e existe uma
especificao de mais alto nvel), problemas reportados e solicitaes de melhoria
para sistemas correntes, e observao do dia a dia dos usurios. A necessidade de
se obter requisitos a partir de mltiplas perspectivas e fontes ilustra bem a natureza
de comunicao intensiva da engenharia de requisitos.
Anlise de Interessados: conforme citado anteriormente, interessados

(stakeholders) so pessoas que tm interesse no sistema ou so afetadas de alguma
maneira por ele e, portanto, precisam ser consultadas durante o levantamento de
requisitos. Interessados incluem tanto pessoal interno quanto externo
organizao. O cliente ou patrocinador do projeto tipicamente o interessado mais
aparente de um projeto. Contudo, os usurios so, na maioria das vezes, os
interessados mais importantes. Outras partes cuja esfera de interesse pode ser
afetada pela operao do sistema, tais como parceiros e clientes da organizao,
devem ser consideradas interessadas. Assim, um dos primeiros passos no processo
de levantamento de requisitos consiste em analisar e envolver todos os interessados
relevantes.
Seleo de Tcnicas de Levantamento de Requisitos: Nenhuma tcnica

individualmente suficiente para levantar requisitos. Alm disso, a escolha das
tcnicas a serem adotadas fortemente dependente de caractersticas do projeto e
de seus envolvidos. Diferentes tcnicas devem ser empregadas, visando capturar
diferentes tipos de informao e em diferentes estgios do processo de
levantamento de requisitos. Assim, importante selecionar adequadamente as
tcnicas a serem aplicadas.
Levantamento de Requisitos de Interessados e Outras Fontes: Uma vez

identificados as fontes de requisitos e os interessados relevantes, o levantamento
de requisitos propriamente dito pode ser iniciado, aplicando-se as tcnicas
selecionadas.
Assim, antes de iniciar a descoberta de requisitos propriamente dita, ou mesmo

durante o levantamento de requisitos, til realizar algumas tarefas, a saber (KOTONYA;
SOMMERVILLE, 1998):

32
Compreender os objetivos gerais do negcio a ser apoiado, esboar uma descrio

do problema a ser resolvido e identificar por que o sistema necessrio e quais so
restries sobre o mesmo, tais como restries oramentrias, de cronograma e de
interoperabilidade.
Levantar informaes do contexto do desenvolvimento, dentre eles conhecimento

acerca da organizao onde o sistema ser implantado, informaes sobre o
domnio da aplicao e informaes sobre sistemas que esto em uso e sero
substitudos pelo sistema em desenvolvimento.
Organizar as informaes levantadas, descartando conhecimento irrelevante e

priorizando as metas da organizao. Alm disso, importante identificar
interessados (stakeholders) e seus papis na organizao.
O envolvimento de clientes e usurios um fator crtico para o sucesso do projeto.

Assim, importante engajar representantes deles desde o incio do projeto. Para definir esses
representantes, deve-se (WIEGERS, 2003):
Identificar diferentes classes de usurios. Usurios podem ser agrupados por

diferentes aspectos, tais como: (i) a frequncia com que usam o sistema, (ii)
experincia no domnio de aplicao e percia com sistemas computadorizados,
(iii) caractersticas do sistema que eles usam, (iv) tarefas que eles realizam no
apoio a seus processos de negcio e (v) nveis de privilgio de acesso e segurana.
Selecionar e trabalhar com indivduos que representem cada grupo de usurios;
Estabelecer um acordo sobre quem sero as pessoas responsveis por tomar

decises relativas a requisitos, sobretudo no que concerne a estabelecer prioridades
e resolver conflitos.
Cada classe de usurios tem seu prprio conjunto de requisitos, tanto funcionais
quanto no funcionais. Alm disso, h classes de usurios que so mais importantes que
outras. Essas classes devem ter tratamento preferencial na definio de prioridades e
resoluo de conflitos (WIEGERS, 2003).
Ainda em relao seleo de usurios, deve-se evitar obter requisitos de
intermedirios entre a fonte de requisitos efetivamente e os analistas. Essa prtica abre espao
para problemas de comunicao e, portanto, sempre que possvel, deve-se ir diretamente
fonte. Contudo, alguns desses intermedirios podem adicionar informao importante. Neste
caso, oua-os tambm. Entretanto, tome cuidado com gerentes de usurio (e tambm com
desenvolvedores) que pensam que sabem as necessidades dos usurios sem sequer consultlos (WIEGERS, 2003).
No que se refere aos responsveis por tomar decises relativas a requisitos, no incio
do projeto deve-se definir quem vai resolver requisitos conflitantes advindos de diferentes
classes de usurio, reconciliar inconsistncias, definir prioridades e arbitrar questes de
escopo que venham a surgir. Uma boa estratgia a tomada de deciso consultiva e
participativa, na qual se obtm ideias e opinies de diversos interessados antes de se tomar
uma deciso (WIEGERS, 2003).
interessante notar que, ao longo do processo de levantamento de requisitos, o
engenheiro de requisitos (ou analista de sistema, como mais conhecido popularmente)
desempenha diversos papis e assume diferentes responsabilidades. Por exemplo, um analista
frequentemente desempenha o papel de um facilitador em sesses de levantamento de

33
requisitos em grupo, guiando e apoiando os participantes no endereamento de questes

relevantes, bem como garantindo que os participantes se sentem confortveis e seguros com o
processo, tendo oportunidade suficiente para contribuir. Outro papel importante o de
mediador. Em muitos casos, a priorizao de requisitos ou negociao de requisitos
conflitantes por diferentes classes de interessados fonte de debate e disputa. Neste contexto,
o analista deve negociar uma soluo adequada e obter o compromisso dos envolvidos
(AURUM; WOHLIN, 2005).
3.2 Tcnicas de Levantamento de Requisitos

Uma vez que levantar requisitos no tarefa fcil, imprescindvel que essa atividade
seja cuidadosamente conduzida, fazendo uso de diversas tcnicas. Dentre as diversas tcnicas
que podem ser aplicadas para o levantamento de requisitos, destacam-se: entrevistas,
questionrios, workshops de requisitos, observao, investigao de documentos,
prototipagem, cenrios, abordagens baseadas em objetivos e reutilizao de requisitos.
Kendall e Kendall (2010) classificam os mtodos de levantamento de requisitos em
dois grandes grupos: mtodos interativos e mtodos no obstrutivos. Os mtodos interativos
envolvem a interao com membros da organizao, como o caso de entrevistas e
workshops de requisitos. Os mtodos no obstrutivos procuram no interferir no trabalho dos
membros da organizao. Este o caso de mtodos como observao e investigao de
documentos.
Alexander e Beus-Dukic (2009), por sua vez, organizam as tcnicas de levantamento
de requisitos pelo contexto no qual pode se dar a descoberta de requisitos. Esses contextos
podem ser a descoberta de requisitos a partir de indivduos (entrevistas, por exemplo), a partir
de grupos (p.ex., workshops de requisitos) ou a partir de coisas (p.ex., investigao de
documentos).
Os principais mtodos de levantamento de requisitos envolvem um processo geral que
contm as seguintes atividades:
Planejamento: visa definir o objetivo da atividade de levantamento de requisitos a

ser conduzida, as pessoas (no caso de mtodos interativos) ou as coisas (no caso de
mtodos no obstrutivos) envolvidas, quando a atividade vai ser realizada e sua
durao, onde e como ela vai ser realizada, incluindo material de apoio. Assim, o
planejamento envolve quatro perguntas bsicas: Por que?, Quem? (ou O qu?),
Quando? Onde? e Como?
Conduo: a realizao da atividade de levantamento de requisitos propriamente

dita.
Registro: consiste no registro das informaes obtidas na atividade realizada.
Validao dos achados: envolve submeter o registro das informaes obtidas para
avaliao pelas pessoas que participaram da atividade de levantamento de
requisitos.
A seguir algumas das tcnicas citadas anteriormente so apresentadas.

34
3.2.1 Entrevistas
Entrevistas so, provavelmente, a tcnica mais comumente utilizada no levantamento
de requisitos (AURUM; WOHLIN, 2005). Uma entrevista uma conversa direcionada com
um propsito especfico, que utiliza um formato pergunta-resposta (KENDALL;
KENDALL, 2010). Entrevistas so usadas em quase todos os esforos de levantamento de
requisitos. Nelas, os analistas formulam questes para os interessados e os requisitos so
derivados das respostas a essas perguntas (SOMMERVILLE, 2007).
Uma entrevista feita tipicamente por meio de uma reunio envolvendo o analista
(entrevistador) e um interessado no sistema (entrevistado). Assim, um mtodo interativo de
levantamento de requisitos a partir de um indivduo. Contudo, uma entrevista pode envolver
mais de um entrevistador e mais de um entrevistado. Uma entrevista pode ser, por exemplo,
realizada por dois entrevistadores, um fazendo a maior parte das perguntas, enquanto o outro
registra as informaes obtidas e presta ateno em requisitos possivelmente perdidos.
possvel, ainda, entrevistar dois ou trs interessados de uma s vez, mas deve-se evitar
envolver pessoas demais, pois se pode perder o controle da entrevista e o dilogo descambar
para uma discusso geral (ALEXANDER; BEUS-DUKIC, 2009).
As entrevistas podem ser de dois tipos principais (SOMMERVILLE, 2007):
Entrevistas fechadas, nas quais o interessado responde a um conjunto de perguntas

predefinidas.
Entrevistas abertas, nas quais no existe um roteiro predefinido. O analista explora

vrios assuntos com o interessado e, assim, desenvolve uma maior compreenso de
suas necessidades.
Geralmente, as entrevistas so uma combinao desses dois tipos. As respostas a

algumas perguntas podem levar a outros questionamentos, discutidos de maneira menos
estruturada. As discusses completamente abertas dificilmente funcionam bem. A maioria das
entrevistas requer algumas perguntas como ponto de partida e para manter o foco em um
aspecto do sistema a ser desenvolvido (SOMMERVILLE, 2007).
Entrevistas so teis para, dentre outros (SOMMERVILLE, 2007; KENDALL;
KENDALL, 2010; KOTONYA; SOMMERVILLE, 1998):
obter objetivos organizacionais e pessoais;
obter um entendimento geral sobre o problema, sobre o que os interessados fazem

e como eles podem interagir com o sistema;
conhecer os sentimentos do entrevistado sobre os sistemas atuais e as dificuldades

que eles tm com os mesmos;
levantar procedimentos informais para interao com tecnologias da informao.
No entanto, entrevistas podem no ser boas para o analista compreender ou aprender

sobre o domnio da aplicao. Especialistas de domnio, muitas vezes, usam terminologia e
jarges especficos, o que provoca mal entendidos por parte dos analistas. Alm disso, alguns
conhecimentos so to familiares para os interessados que so considerados difceis de
explicar; outros so considerados to bsicos que os especialistas de domnio consideram que
no vale a pena mencion-los (SOMMERVILLE, 2007).

35
Em uma entrevista, o engenheiro de requisitos est, provavelmente, estabelecendo um

relacionamento com uma pessoa estranha a ele. Assim, importante: (i) construir uma base de
confiana e entendimento; (ii) manter o controle da entrevista; e (iii) vender a ideia do
sistema, provendo informaes relevantes ao entrevistado (KENDALL; KENDALL, 2010).
Uma vez que entrevistas so essencialmente atividades sociais envolvendo pessoas,
sua efetividade depende em grande extenso da qualidade da interao entre os participantes.
Assim, os resultados de entrevistas podem variar bastante, em funo da habilidade do
entrevistador (AURUM; WOHLIN, 2005). As informaes obtidas em entrevistas
complementam outras informaes obtidas de documentos, observaes de usurios etc.
Assim, essa tcnica deve ser usada em conjunto com outras tcnicas de levantamento de
requisitos (SOMMERVILLE, 2007).
Uma entrevista precisa ser planejada. Tipicamente, o planejamento de uma entrevista,
assim como o de outras atividades de levantamento de requisitos, deve considerar as quatro
perguntas bsicas:
Por que?: a primeira coisa a ser feita estabelecer os objetivos da entrevista. As

primeiras entrevistas tm, normalmente, um carter exploratrio, quando se
desejam capturar objetivos da organizao para o sistema, propsito do sistema,
reas de negcio afetadas etc. Na medida em que o analista ganha entendimento
sobre o problema, seu foco tende a ficar mais restrito, visando um aprofundamento
em um tema ou aspecto especfico do sistema. Entrevista uma boa opo, dentre
outros, para capturar metas (organizacionais ou pessoais) e sentimentos e
necessidades em relao ao sistema (perspectivas de diferentes envolvidos), ou
para melhorar/aprofundar o entendimento sobre o problema. Por outro lado, no
uma boa opo para aprender sobre o domnio.
Quem?: tendo em mente o objetivo da entrevista, o prximo passo identificar

quais membros da organizao tm conhecimento acerca do assunto a ser tratado e
selecionar as pessoas a serem entrevistadas. interessante levantar, ainda, o papel
e a posio do potencial entrevistado na organizao. Pessoas da alta gerncia tm
normalmente uma viso mais abrangente dos objetivos organizacionais e
estratgicos, mas, por outro lado, no conhecem detalhes mais operacionais.
Assim, o objetivo da entrevista deve guiar a seleo do entrevistado. O cliente ou
patrocinador do projeto pode ajudar na identificao das pessoas mais indicadas
para uma entrevista. Quando houver muitos bons candidatos a entrevistas em um
mesmo papel/posio, pode-se usar amostragem para selecionar uma amostra
gerencivel.
Quando?: no que se refere questo temporal de uma entrevista, dois aspectos

devem ser considerados: primeiro, a data e o horrio; segundo, a durao. No que
se refere ao agendamento da entrevista, deve-se marcar a entrevista com certa
antecedncia (preferencialmente de alguns dias) e informar o objetivo da entrevista
e o tema a ser abordado, de modo que o entrevistado possa se preparar para
responder s perguntas. No que se refere durao, deve-se ter em mente que o
entrevistado vai interromper seu trabalho para atender o analista. Assim, deve-se
evitar tomar muito o seu tempo. Entrevistas com pontos de discusso focados
devem ter, em mdia, uma hora de durao. Entrevistas exploratrias, ou em
situaes especiais, podem durar um pouco mais (at duas horas). Em qualquer
caso, bom senso fundamental e a preparao para a entrevista deve ser feita com

36
cuidado para aproveitar ao mximo a oportunidade, sobretudo quando a entrevista

envolve membros da alta gerncia.
Onde?: definir o local onde se dar a entrevista. Normalmente, o analista vai at o

local de trabalho do entrevistado.
Como?: conhecendo o objetivo, o entrevistado (e seu perfil) e o tempo disponvel,

resta preparar a entrevista cuidadosamente para que a mesma seja o mais produtiva
possvel. A preparao envolve, dentre outros, a definio do tipo das questes a
serem feitas, a redao das questes propriamente dita, a definio da ordem em
que as perguntas sero feitas e a definio de como a entrevista ser registrada
durante a sua conduo.
Visando responder s questes acima, Kendall e Kendall (2010) sugerem que o

planejamento da entrevista envolva os seguintes passos:
1. Estudar material existente sobre o domnio e a organizao. Ateno especial
deve ser dada linguagem usada pelos membros da organizao, procurando
estabelecer um vocabulrio comum a ser usado na elaborao das questes da
entrevista. Este passo visa, sobretudo, otimizar o tempo despendido nas
entrevistas, evitando-se perguntar questes bsicas e gerais.
2. Estabelecer objetivos. De maneira geral, h algumas reas sobre as quais o analista
desejar fazer perguntas, tais como fontes de informao, formatos da informao,
frequncia na tomada de deciso, estilo da tomada de deciso etc.
3. Decidir quem entrevistar. importante incluir na lista de entrevistados as pessoaschave das diversas classes de interessados afetados pelo sistema. O cliente pode
ajudar nesta seleo.
4. Preparar o entrevistado. Uma entrevista deve ser marcada com antecedncia, de
modo que o entrevistado tenha tempo para pensar sobre a entrevista.
5. Preparar a entrevista. Deve-se decidir, dentre outros, sobre os tipos de questes e
a estrutura da entrevista e o modo como a mesma ser registrada.
Em relao ao tipo, questes podem ser de trs tipos principais (KENDALL;
KENDALL, 2010):
Questes subjetivas: permitem respostas abertas. Ex.: O que voc acha de [...]?;
Explique como voc [...]?. Seus pontos positivos so: (i) proveem riqueza de
detalhes; (ii) revelam novos questionamentos; e (iii) colocam o entrevistado mais
vontade, permitindo maior espontaneidade. Contudo, h tambm desvantagens,
dentre elas: (i) podem resultar em muitos detalhes irrelevantes; (ii) podem levar
perda do controle da entrevista; (iii) podem ter respostas muito longas para se
obter pouca informao til; e (iv) podem dar a impresso de que o entrevistador
est perdido e sem objetivo.
Questes objetivas: limitam as respostas possveis. Ex: Quantos [...]?; Quem

[...]?; Quanto tempo [...]?; Qual das seguintes informaes [...]?. Como
vantagens, questes objetivas: (i) permitem ganho de tempo, uma vez que elas vo
direto ao ponto em questo, (ii) permitem manter o controle da entrevista e (iii)
levam a dados relevantes. Como desvantagens, podem ser citadas: (i) questes
objetivas podem ser maantes para o entrevistado, (ii) podem falhar na obteno

37
de detalhes importantes e (iii) no constroem uma afinidade entre entrevistador e

entrevistado.
Questes de aprofundamento: permitem explorar os detalhes de uma questo.

Podem ser subjetivas ou objetivas. Ex: Por que?; Voc poderia dar um
exemplo?; Como isto acontece?.
A Tabela 3.1 apresenta um quadro comparativo de caractersticas obtidas com

questes objetivas e subjetivas.
Tabela 3.1 Quadro Comparativo Questes Objetivas x Subjetivas (adaptado de
(KENDALL; KENDALL, 2010)).
Subjetivas
Objetivas
Confiabilidade dos dados
Baixa
Alta
Uso eficiente do tempo
Baixo
Alto
Preciso dos dados
Baixa
Alta
Amplitude e profundidade
Alta
Baixa
Habilidade requerida do entrevistador
Alta
Baixa
Baixa
Alta
Facilidade de anlise
A elaborao de questes deve ser cuidadosa, pois ela pode levar a problemas como
(KENDALL; KENDALL, 2010):
Questes tendenciosas: tendem a levar o entrevistado a responder de uma forma

especfica. Ex.: Sobre este assunto, voc est de acordo com os outros diretores,
no est? Uma opo mais adequada seria: O que voc pensa sobre este assunto?
Duas questes em uma: O entrevistado pode responder a apenas uma delas, ou

pode se confundir em relao pergunta que est respondendo. Ex.: O que voc
faz e como?
A estrutura de uma entrevista diz respeito organizao das questes em uma

sequncia lgica. De acordo com (KENDALL; KENDALL, 2010), h trs formas bsicas de
se organizar as questes de uma entrevista:
Estrutura de Pirmide (abordagem indutiva): inicia com questes detalhadas e

objetivas e, medida que a entrevista progride, questes mais gerais, subjetivas,
so colocadas. til para situaes em que o entrevistado necessita de um
aquecimento para falar no assunto ou quando o analista deseja obter uma
finalizao sobre o assunto.
comea com questes especficas
termina com questes mais gerais

38
Estrutura de Funil (abordagem dedutiva): inicia com questes gerais subjetivas e,

medida que a entrevista avana, perguntas mais especficas, usando questes
objetivas, so feitas. Essa estrutura prov um meio fcil e mais amigvel para se
comear uma bateria de entrevistas. Permite levantar informao detalhada, sendo
desnecessrias longas sequncias de questes objetivas e de aprofundamento.
comea com questes genricas e
subjetivas
termina com questes especficas
Estrutura de Diamante: uma combinao das duas anteriores, comeando com

questes especficas, passando a questes gerais e fechando a entrevista
novamente com questes especficas. uma boa forma de se estruturar uma
entrevista, j que mantm o interesse do entrevistado em uma variedade de
questes. Contudo, tende a ser mais longa.
inicia com questes especficas
examina questes gerais
fecha com questes especficas
Estruturar entrevistas um meio de planejar a priori a ordem em que as questes sero

feitas. Obviamente, h a opo de no se definir essa ordem antecipadamente, em uma
abordagem de entrevista no estruturada, na qual no h uma definio da sequncia das
questes. De acordo com o andar da entrevista, caminhos possveis so avaliados e a
sequncia estabelecida. Normalmente, requer mais tempo. Entretanto, vale ressaltar que,
ainda que a sequncia das questes no seja definida a priori, as questes devem ser definidas
antecipadamente, ou seja, o planejamento necessrio. A Tabela 3.2 apresenta um quadro
comparativo entre as abordagens estruturada e no estruturada.

39
Tabela 3.2 Comparao entre as Abordagens Estruturada e No Estruturada

(adaptado de (KENDALL; KENDALL, 2010)).
No Estruturada
Estruturada
Mais Difcil
Mais Fcil
Tempo Requerido
Maior
Menor
Treinamento Requerido
Maior
Menor
Espontaneidade
Maior
Menor
Oportunidades para insight
Maior
Menor
Flexibilidade
Maior
Menor
Controle
Menor
Maior
Preciso
Menor
Maior
Confiabilidade
Menor
Maior
Amplitude e Profundidade
Maior
Menor
Avaliao
Por fim, o planejamento deve definir de que forma a entrevista ser registrada.
importante registrar os principais aspectos de uma entrevista durante a sua realizao, pois,
caso contrrio, as informaes obtidas podem ser perdidas logo em seguida. H duas formas
principais, cujas vantagens e desvantagens so apresentadas a seguir (KENDALL;
KENDALL, 2010) (ALEXANDER; BEUS-DUKIC, 2009):
Gravao / Filmagem: a entrevista gravada ou filmada. A gravao / filmagem

permite o registro completo da entrevista e a reproduo para outros membros da
equipe posteriormente. Contudo, muitos entrevistados no gostam de serem
gravados e, por conseguinte, ficam pouco vontade. Alm disso, o fato de saber
que a entrevista est sendo gravada pode deixar o entrevistador distrado,
comprometendo seu trabalho. Por fim, transcrever registros gravados uma
atividade que consome tempo e confiar em gravaes para posteriormente tirar
dvidas pode ser perigoso, deixando de se esclarecer uma dvida na hora da
entrevista.
Anotaes: o entrevistador toma notas durante a entrevista. Quando esta

abordagem adotada, deve-se considerar que escrever um processo lento,
enquanto falar rpido. Assim, as anotaes devem capturar a essncia do que foi
dito. Algumas das vantagens dessa abordagem so: (i) mantm o entrevistador
alerta; (ii) um esquema das anotaes a serem feitas pode ser usado para fornecer
um roteiro para a entrevista; (iii) mostra interesse e preparao do entrevistador.
Como desvantagens, podem ser citadas: (i) essa abordagem pode comprometer o
andamento da conversa; (ii) pode se dar excessiva ateno a fatos e pouca a
sentimentos e opinies.
Uma vez planejada, a entrevista deve ser realizada. Na vspera da reunio, recomendase que o analista entre em contato com o entrevistado para confirmar o horrio e o local da
entrevista. No dia da entrevista, o analista deve chegar um pouco antes do horrio marcado,

40
vestido apropriadamente. Ao iniciar a entrevista, interessante que o analista se apresente,

fale sucintamente sobre os objetivos da entrevista, diga ao entrevistado o que ser feito com
as informaes coletadas e assegure seu aspecto confidencial. Durante a entrevista,
fundamental gerenciar o tempo. Ao trmino da entrevista, pergunte se h algo mais sobre o
assunto que o entrevistado ache importante voc saber, faa um resumo da entrevista e d um
retorno acerca de suas impresses gerais. Informe o entrevistado sobre os passos seguintes e
pergunte se h outra pessoa com a qual ele acha que voc deveria conversar. Quando for o
caso, marque nova entrevista (KENDALL; KENDALL, 2010).
Ao finalizar a entrevista, resta ainda escrever um relatrio sobre a mesma. O relatrio
ou ata da entrevista deve capturar os pontos principais da entrevista e deve ser escrito to
rpido quanto possvel para assegurar a qualidade (KENDALL; KENDALL, 2010). De
maneira geral, os seguintes itens devem ser registrados: entrevistado(s), entrevistador(es), data
e hora, durao, assunto, objetivos e principais pontos discutidos. Uma vez escrito, esse
relatrio deve ser enviado para avaliao por todos os participantes (validao de achados).
3.2.2 Tcnicas de Coleta Colaborativa de Requisitos

A coleta colaborativa de requisitos uma tcnica muito comumente empregada.
Grupos so particularmente efetivos, porque eles envolvem e estabelecem o compromisso
diretamente com os interessados e porque promovem cooperao (AURUM; WOHLIN,
2005). H muitas abordagens diferentes de coleta colaborativa de requisitos, tais como
Workshops de Requisitos, JAD e Brainstorming. Todas aplicam, de alguma maneira, as
seguintes diretrizes bsicas (PRESSMAN, 2006): (i) as reunies envolvem representantes de
diferentes grupos de interessados, sendo estabelecidas regras de preparao e participao; (ii)
um facilitador, que pode ser o analista ou outro participante, controla a reunio; (iii)
mecanismos de anotao, tais como quadro branco, flipcharts, anotaes em um computador
projetadas para todos os participantes etc., so usados para registrar as ideias levantadas; e
(iv) a meta identificar ou debater um problema, propor elementos da soluo, negociar
diferentes abordagens e especificar um conjunto preliminar de requisitos da soluo.
Geralmente, o facilitador desempenha um papel crtico no planejamento, seleo dos
participantes e, sobretudo, na conduo da reunio, de modo a encorajar a participao para se
atingir objetivos de modo consensual. Se uma pessoa est participando pouco, o facilitador
deve tentar traz-la para a discusso, dando espao para ela se manifestar (WIEGERS, 2003).
Em alguma extenso, o trabalho em grupo se sobrepe ao trabalho com indivduos
(entrevistas). Entretanto, um grupo rene informaes de vrias fontes, coloca-as juntas,
permite ouvir vrios pontos de vista, refina o entendimento coletivo e atinge concordncia de
uma maneira que no possvel com outras tcnicas de levantamento de requisitos
(ALEXANDER; BEUS-DUKIC, 2009).
Para ser bem sucedido, os participantes devem estar de acordo com alguns princpios
operacionais bsicos, tais como comear e terminar a reunio nos horrios predefinidos,
manter apenas uma conversa de cada vez, permitir a contribuio de todos e enfocar
comentrios e crticas em questes e no em indivduos. Diferentes interessados tipicamente
tm um objetivo comum, mas tm diferentes vises do problema e sub-objetivos bastante
distintos. Ningum deve esquecer seus prprios sub-objetivos, mas o credo de todos os
participantes deve ser: Meu ponto de vista um dentre vrios e o mais importante o
objetivo final comum. Deve-se considerar, ainda, que o sucesso de uma reunio de coleta

41
colaborativa de requisitos depende fortemente da habilidade do facilitador e dos participantes

trabalharem como uma equipe inovadora. Alm disso, deve ser possvel dar voz a todos os
participantes (WIEGERS, 2003; ALEXANDER; BEUS-DUKIC, 2009).
Uma tcnica de coleta colaborativa de requisitos so os Workshops de Requisitos.
Workshop de Requisitos o nome dado a um nmero de diferentes tipos de reunies
envolvendo diversas pessoas, cujo foco a descoberta e desenvolvimento de requisitos
(AURUM; WOHLIN, 2005). Workshops de requisitos colocam um grupo de pessoas junto,
com o objetivo comum de levantar requisitos para um problema compartilhado, para o qual
essas pessoas tm vises distintas. O propsito obter conhecimento e energia suficientes
para levantar requisitos rpida e eficientemente (ALEXANDER; BEUS-DUKIC, 2009).
Um workshop de requisitos no simplesmente uma reunio. Um workshop uma
reunio com propsito definido e atividades planejadas. Assim, requer planejamento
endereando as cinco questes bsicas:
Por que?: a primeira coisa a ser feita estabelecer os objetivos do workshop.

Workshops so provavelmente o principal meio de tomar decises e fechar um
acordo entre membros de um grupo. Vrias informaes podem ser alvo de
descoberta em um workshop de requisitos, dentre elas as influncias que
interessados tm uns sobre os outros, objetivos, riscos, fronteiras do sistema,
restries e atributos de qualidade (requisitos no funcionais) e prioridades
Quem?: grupos pequenos (at seis participantes) tendem a funcionar melhor.

melhor organizar grupos menores em diferentes workshops do que ter um grupo
muito grande. As pessoas devem ser convidadas em funo dos objetivos e das
atividades planejadas para o workshop e da contribuio que as pessoas podem
dar. Especialistas e pessoas com poder de deciso sobre os requisitos so bons
candidatos a participantes (WIEGERS, 2003; ALEXANDER; BEUS-DUKIC,
2009).
Quando?: da mesma forma que entrevistas, workshops devem ser agendados com
antecedncia, em datas acordadas com todos os participantes. No que se refere
durao, deve-se ter em mente que todos os participantes vo interromper seu
trabalho para atender ao workshop. Assim, sesses de workshops devem ser to
curtas quanto possvel, idealmente com durao de uma a duas horas. Contudo,
alguns projetos podem requerer sesses mais longas, algumas vezes com durao
de vrias horas, podendo chegar a dias (ALEXANDER; BEUS-DUKIC, 2009).
Onde?: definir o local onde se a reunio ser realizada. Deve-se garantir que
haver espao suficiente para acomodar confortavelmente todos os participantes. O
layout da sala tambm importante. Layouts em crculo ou na forma de U
funcionam bem, uma vez que eles colocam todos os participantes em um mesmo
nvel de importncia.
Como?: durante a preparao, defina os recursos necessrios (computadores,

projetores, quadros brancos, flipcharts etc) e garanta que eles estaro disponveis
no perodo do workshop. Proveja o material de preparao necessrio para os
participantes com antecedncia. Por fim, obviamente, a definio de tpicos a
serem discutidos deve ser feita cuidadosamente. Tpicos complexos podem ser
divididos em sries de questes mais simples, tais como: Quais os objetivos dos

42
interessados para o assunto em questo? Que conflitos podem surgir? Como

podemos ver isso funcionando (cenrios)? Quais os argumentos de cada lado?
possvel imaginar diferentes solues para o problema? Quais so prioridades?
Durante a conduo do workshop, enfatize que o tempo limitado e minimize
distrbios, solicitando, p.ex., que as pessoas desliguem seus celulares. Atribua papis s
pessoas, tais como responsvel por controlar o tempo, responsvel por controlar se a
discusso est fugindo do assunto, responsvel por fazer anotaes etc. Uma vez terminado,
as informaes descobertas no workshop devem ser registradas em um relatrio, o qual deve
ser validado pelos participantes (ALEXANDER; BEUS-DUKIC, 2009).
Workshops de requisitos podem ser combinados com diversas tcnicas. Durante um
workshop de requisitos, por exemplo, cenrios podem ser elaborados. Por outro lado,
resultados obtidos em diversas entrevistas podem ser levados discusso em um workshop.
Alm dos Workshops de Requisitos, outras duas tcnicas de coleta colaborativa de
requisitos bastante utilizadas so:
Brainstorming: neste tipo de reunio, representantes de diferentes grupos de

interessados engajam-se em uma discusso informal para gerar rapidamente tantas
ideias quanto possvel, sem focar a ateno em nenhuma delas. Normalmente no
propsito de uma sesso de brainstorming resolver maiores questes ou tomar
decises. Essa tcnica frequentemente utilizada para desenvolver uma declarao
preliminar da misso e dos requisitos para o sistema. Um diferencial dessa tcnica
que ela promove a livre expresso, favorecendo a descoberta de solues novas e
inovadoras para problemas existentes (AURUM; WOHLIN, 2005).
JAD (Joint Application Development): envolve a participao de diferentes

interessados na investigao, por meio de discusses, tanto de problemas a serem
resolvidos quanto das solues disponveis para esses problemas. Com as diversas
partes envolvidas representadas, decises podem ser tomadas e questes resolvidas
mais rapidamente. Em uma sesso JAD, ao contrrio de uma sesso de
brainstorming, as metas do sistema j esto definidas. Contudo, o foco de uma
seo JAD de requisitos ainda recai nas necessidades e desejos de usurios e do
prprio negcio e no em detalhes tcnicos (AURUM; WOHLIN, 2005).
3.2.3 Questionrios
Questionrio ou survey uma tcnica de levantamento de informaes que permite ao
analista capturar, de vrias pessoas afetadas pelo sistema, atitudes, crenas, comportamentos e
caractersticas. Atitudes referem-se a o que as pessoas na organizao dizem querer; crenas
referem-se a o que as pessoas pensam ser realmente verdade; comportamento o que as
pessoas fazem; caractersticas so propriedades de pessoas ou coisas (KENDALL;
KENDALL, 2010).
H muitas similaridades entre questionrios e entrevistas e pode ser til utilizar as duas
abordagens em conjunto para refinar respostas no claras de um questionrio em uma
entrevista ou para projetar um questionrio com base no que foi descoberto em uma
entrevista. Usando questionrios aps a realizao de entrevistas, um analista pode estar
procurando quantificar o que foi levantado em entrevistas ou determinar como um sentimento

43
expresso em uma entrevista realmente difundido ou limitado. Por outro lado, questionrios
podem ser usados para examinar uma grande amostra de usurios para sentir problemas ou
levantar questes importantes, antes de se programar entrevistas (KENDALL; KENDALL,
2010).
Questionrios proveem um meio eficiente de coletar informaes de vrios
interessados. Entretanto, so limitados no que tange profundidade do conhecimento que
pode ser levantado, uma vez que no permitem que um tpico seja aprofundado ou que ideias
sejam expandidas (AURUM; WOHLIN, 2005).
Questionrios so teis quando (KENDALL; KENDALL, 2010):
As pessoas necessrias esto geograficamente dispersas.
H um grande nmero de pessoas envolvidas no projeto do sistema e necessrio

saber qual proporo de um dado grupo aprova ou desaprova uma particular
caracterstica do sistema proposto.
Se deseja saber uma opinio global antes de se definir qualquer direo especfica
para o projeto, em um estudo exploratrio.
Deseja-se assegurar que os problemas com o sistema corrente foram identificados

e tratados em entrevistas que se seguem.
Uma vez que questionrios e entrevistas seguem uma abordagem pergunta-resposta,

seria bastante razovel pensar que as consideraes feitas para entrevistas aplicam-se tambm
para questionrios. Contudo, importante ressaltar que h diferenas fundamentais entre essas
tcnicas e, portanto, outros aspectos devem ser considerados.
Em primeiro lugar, entrevistas permitem interao direta com o entrevistado a respeito
das questes e seus significados. Em uma entrevista, o analista pode refinar uma questo,
definir um termo obscuro, alterar o curso do questionamento e controlar o contexto de modo
geral. Isto no necessariamente verdade para um questionrio e, portanto, o planejamento de
um questionrio e de suas questes deve ser mais cuidadoso. Assim, um questionrio deve ter
questes claras e no ambguas, fluxo bem definido e administrao planejada em detalhes.
Alm disso, devem-se levantar, antecipadamente, as dvidas das pessoas que vo respond-lo
(KENDALL; KENDALL, 2010).
Em relao s cinco perguntas bsicas, valem as seguintes consideraes:
Por que?: assim como os demais mtodos, a primeira coisa a ser feita estabelecer
os objetivos de um questionrio. Conforme citado anteriormente, questionrios
podem ser usados para quantificar o que foi levantado com outros mtodos, para
determinar como um sentimento capturado por meio de outras tcnicas de
levantamento de requisitos realmente difundido ou limitado, ou para examinar
uma grande amostra de usurios para sentir problemas ou levantar questes
importantes.
Quem?: a definio de quem dever responder o questionrio deve ser feita em

conjunto com a definio de seus objetivos. Usar amostragem pode ajudar a
determinar quais classes de pessoas so necessrias e o tipo de respondentes. As
pessoas que vo efetivamente responder o questionrio so escolhidas, dentre
outros, em funo de sua posio, tempo de servio, responsabilidades e interesse
no sistema corrente ou proposto. importante garantir que um nmero suficiente

44
de respondentes ser includo, de modo a permitir uma amostra razovel,

considerando que algumas pessoas no vo responder ou vo responder
erradamente e tero seus questionrios descartados.
Quando? Onde?: estas questes esto fortemente relacionadas ao mtodo de

aplicao do questionrio a ser adotado. Quando se decide reunir todos os
respondentes em um mesmo lugar e momento, deve-se definir local, data, hora e
durao. Quando os respondentes so livres para administrar o preenchimento do
questionrio, deve-se indicar at que data isso deve ser feito e qual a durao
esperada para se responder o questionrio.
Como?: dentre os aspectos a serem considerados no projeto de um questionrio,

podem ser citados os tipos e a redao das questes, escalas e mtodo de aplicao.
Questionrios podem ter questes objetivas ou subjetivas. Questes subjetivas so

particularmente adequadas a situaes em que se deseja saber a opinio dos membros da
organizao acerca de algum aspecto do sistema, sendo impossvel, portanto, listar
efetivamente todas as respostas possveis para uma pergunta. Quando se decidir utilizar
questes subjetivas em um questionrio, deve-se antecipar o tipo de resposta que se espera
obter. Essas questes devem ser restritas o suficiente para guiar as pessoas, de modo que
respondam de uma maneira especfica (KENDALL; KENDALL, 2010). Deve-se tomar
cuidado com perguntas que permitam respostas muito amplas, pois isso pode dificultar a
comparao e a interpretao dos resultados.
Questes objetivas, por outro lado, devem ser utilizadas em um questionrio quando o
engenheiro de requisitos capaz de listar as possveis respostas e quando h uma grande
amostra de pessoas a examinar. Respostas a questes objetivas so mais facilmente
quantificadas, enquanto respostas a questes subjetivas so analisadas e interpretadas de
maneira diferente. A Tabela 3.2 compara o uso de questes objetivas e subjetivas em
questionrios (KENDALL; KENDALL, 2010).
Tabela 3.2 Uso de questes subjetivas e objetivas em questionrios (adaptado de
(KENDALL; KENDALL, 2010)).
Questes Subjetivas
Questes Objetivas
Tempo gasto para responder
Alto
Baixo
Natureza exploratria
Alta
Baixa
Amplitude e profundidade
Alta
Baixa
Facilidade de preparao
Fcil
Difcil
Difcil
Fcil
Facilidade de anlise
Assim como ocorrem com as entrevistas, a linguagem utilizada na elaborao de

questionrios extremamente importante para a sua efetividade. prudente escrever as
questes de modo a refletir a terminologia particular do negcio. Assim, tanto as perguntas
quanto as respostas sero mais fceis de interpretar. Para verificar a linguagem utilizada,
aplique o questionrio antecipadamente em um grupo piloto, pedindo ateno
adequabilidade dos termos empregados. Kendall e Kendall (2010) recomendam que, dentre
outras, as seguintes diretrizes sejam observadas na redao de um questionrio:

45
Sempre que possvel, use o vocabulrio das pessoas que iro responder. Prime pela
simplicidade.
Utilize perguntas simples e curtas.
Evite redao tendenciosa.
Garanta que as questes esto tecnicamente precisas antes de inclu-las no

questionrio.
Em questionrios, escalas so usadas para atribuir nmeros ou outros smbolos para

um atributo ou caracterstica com o propsito de medir esse atributo ou caracterstica. Escalas
so frequentemente arbitrrias e podem no ser nicas (por exemplo, escalas de temperatura
em oC, oF, K). Dentre os tipos de escalas de medio comumente usados por analistas de
sistemas (KENDALL; KENDALL, 2010), destacam-se:
Nominal: utilizada para classificar coisas. Os valores da escala permitem apenas

indicar se um indivduo pertence ou no a uma classe ou se possui ou no certa
caracterstica. No h qualquer relao de ordenao entre as classes. Assim, a
forma mais fraca de medio, uma vez que s obtm totais para cada classe. Ex.:
Estado civil, sexo.
Ex: Que tipo de software voc mais usa?
1- Editor de Texto
2- Planilha
3- Grfico
4- Outros
Ordinria: tambm utilizada para classificar coisas, mas pressupe-se que as

diferentes classes esto ordenadas em um ranking, sem, no entanto, quantificar a
magnitude das diferenas entre as classes.
Ex: Qual a sua opinio sobre as telas de ajuda?
1- No ajudam nada
2- Ajudam pouco
3- Ajudam muito
Mtrica: alm de ser possvel ordenar os indivduos, possvel tambm quantificar

as diferenas entre eles. As escalas mtricas dividem-se em dois subtipos:
Intervalar: possvel quantificar as distncias entre as medies, mas no h

um ponto nulo.
de Razo: no s possvel quantificar as diferenas entre as medies, como

tambm esto garantidas certas condies matemticas vantajosas, como um
ponto de nulidade.
As escalas mtricas tem como trao marcante o fato de permitirem que sejam
feitas operaes matemticas sobre os dados obtidos do questionrio e, portanto, uma
anlise mais completa. Para obter essa vantagem, uma estratgia bastante utilizada
consiste em tornar uma escala ordinria em uma escala mtrica, como no exemplo
abaixo.
Quo til o suporte tcnico do Centro de Informao?
1- Nada til
2
3
4
5- Extremamente til
Claramente, originalmente ela no era exatamente uma escala de intervalo, mas ao
ancorar a escala em ambas as extremidades, permite ao analista assumir que os respondentes
vo perceber os intervalos como iguais, tornando anlises quantitativas possveis.
Na construo de escalas, alguns problemas podem ocorrer. A seguir so listados
alguns desses problemas e possveis solues (KENDALL; KENDALL, 2010):

46
Condescendncia: a pessoa responde a todas as questes do mesmo jeito. Soluo:

de uma questo para a outra, mover a categoria mdia para a esquerda ou direita
em relao ao centro.
Tendncia Central: a pessoa responde tudo na mdia. Soluo: tornar as

diferenas menores nos extremos, ajustar a fora dos descritores ou criar uma
escala com mais pontos.
Efeito Aurola: a impresso formada em uma questo levada para a prxima.

Soluo: mesclar questes sobre objetos diferentes.
Um questionrio relevante e bem projetado pode aumentar a taxa de respostas. As

seguintes diretrizes podem ser teis durante o projeto um questionrio (KENDALL;
KENDALL, 2010):
Deixe espaos em branco.
Deixe espao suficiente para as respostas (para questes subjetivas).
Torne fcil para os respondentes marcar claramente suas respostas (para questes
objetivas).
Seja consistente no estilo.
Questionrios podem ser aplicados de diversas maneiras. Quando se decide aplicar um

questionrio por email ou pela Web, consideraes adicionais de planejamento relativas
confidencialidade, autenticao de identidade e problemas com mltiplas respostas devem ser
levadas em conta. No caso de questionrios disponveis na Web, use formatos de entrada de
dados comumente usados, tais como caixas de texto, check boxes, radio buttons, drop-down
menu etc (KENDALL; KENDALL, 2010).
Para ordenar as questes, considere os objetivos e, ento, determine a funo de cada
questo para atingir esses objetivos. Use um grupo piloto para auxiliar ou observe o
questionrio com olhos de respondedor. Algumas orientaes devem ser seguidas, dentre elas
(KENDALL; KENDALL, 2010):
Coloque questes que so importantes para os respondentes primeiro.
Agrupe itens de contedo similar e observe tendncias de associao.
Coloque questes menos controversas primeiro.
Por fim, no que se refere ao mtodo de aplicao do questionrio, h diversas

possibilidades, cada uma delas apresentando vantagens e desvantagens. Pode-se, por exemplo,
reunir todos os respondedores em um mesmo local para a aplicao do questionrio. Isso
permite alto retorno, instrues uniformes e resultado rpido. Contudo, pode ser difcil reunir
todas as pessoas em s lugar ao mesmo tempo e o respondedor pode ter coisas importantes a
fazer (KENDALL; KENDALL, 2010).
De maneira geral, permite-se que os respondentes administrem quando vo responder
o questionrio. Neste caso, corre-se o risco das pessoas esquecerem ou propositalmente
ignorarem o questionrio. Contudo, refora-se a sensao de anonimato e, por conseguinte,
podem-se obter respostas mais confiveis (KENDALL; KENDALL, 2010).
Aplicar questionrios eletronicamente, seja por email seja por meio de formulrio na
Web, um meio de rapidamente chegar aos respondentes. Evitam-se custos com cpias, as

47
respostas podem ser dadas de acordo com a convenincia dos respondedores e

automaticamente coletadas e armazenadas eletronicamente. Alguns sistemas para aplicar
questionrios permitem que o respondedor comece a responder, salve suas respostas e volte
ao questionrio posteriormente para completar seu preenchimento. Lembretes aos
respondentes podem ser facilmente enviados por email, assim como notificaes ao analista
sobre quando o respondente abriu a mensagem. Pesquisas mostram que questionrios pela
Web podem encorajar respostas francas e consistentes. Questes que podem ser difceis de
serem colocadas pessoalmente podem ser aceitveis de serem respondidas em um
questionrio pela Web (KENDALL; KENDALL, 2010).
3.2.4 - Observao
As pessoas, muitas vezes, tm dificuldade em articular detalhes de seu trabalho, pois
esto imersas nele e fazem muitas coisas de maneira intuitiva. Contudo, os contextos social e
organizacional em que as pessoas trabalham so importantes para o desenvolvimento de um
sistema e podem derivar requisitos e restries (SOMMERVILLE, 2007). Assim, observar o
comportamento e o ambiente do indivduo, sobretudo aquele que toma decises, pode ser uma
forma bastante eficaz de levantar informaes que, tipicamente, passam despercebidas quando
outras tcnicas so usadas (KENDALL; KENDALL, 2010).
A etnografia o estudo de pessoas em seu ambiente natural. No contexto do
levantamento de requisitos, envolve a participao ativa ou passiva do analista nas atividades
normais dos usurios, durante um perodo de tempo, enquanto coleta informaes a respeito
dos processos sendo realizados. Tcnicas de etnografia so especialmente teis para enderear
fatores contextuais e de ambientes de trabalho cooperativo (AURUM; WOHLIN, 2005).
A observao uma das tcnicas de etnografia mais usadas no levantamento de
requisitos. Como o prprio nome indica, o analista observa os usurios executando os
processos, sem interferncia direta (AURUM; WOHLIN, 2005). Ela empregada para
compreender requisitos sociais e organizacionais, bem como para compreender como as
tarefas so realizadas efetivamente. O analista se insere no ambiente de trabalho onde o
sistema ser usado, observa o trabalho do dia-a-dia e faz anotaes acerca das tarefas reais nas
quais os participantes esto envolvidos (SOMMERVILLE, 2007).
Atravs da observao possvel capturar (SOMMERVILLE, 2007; KENDALL;
KENDALL, 2010):
Requisitos derivados da maneira como as pessoas realmente trabalham e no da

maneira como os processos so documentados ou explicados. possvel derivar
requisitos implcitos que refletem os processos reais (e no os formais) com os
quais as pessoas esto envolvidas.
Requisitos derivados do relacionamento entre o indivduo que toma decises e

outros membros da organizao. Esses requisitos so derivados da colaborao e
do conhecimento das atividades de outras pessoas.
Por outro lado, essa tcnica no apropriada para obter requisitos de domnio, bem
como pode ser difcil identificar novas caractersticas a serem acrescentadas ao sistema.
Assim, a observao deve ser combinada com outras tcnicas de levantamento de requisitos.
Quando aplicadas em conjunto, observao pode ser usada para confirmar ou negar
informaes de entrevistas e/ou questionrios. Tambm se podem entrevistar as pessoas

48
observadas para completar informaes obtidas de uma observao. A observao pode ser
combinada tambm com a prototipagem. Uma vez construdo um prottipo, podem-se
observar os usurios utilizando o prottipo, de modo a avaliar o mesmo e derivar novos
requisitos (SOMMERVILLE, 2007; KENDALL; KENDALL, 2010; KOTONYA;
SOMMERVILLE, 1998). Alm disso, deve-se ressaltar que a efetividade de uma observao
pode variar na medida em que os usurios tm tendncia a ajustar o modo como realizam suas
tarefas quando sabem que esto sendo observados (AURUM; WOHLIN, 2005).
Como outras tcnicas de levantamento de requisitos, a observao envolve
planejamento, conduo e o registro de resultados. No planejamento, o analista deve definir o
que observar, quem observar, quando, onde, porque e como. Kotonya e Sommerville (1998)
apontam que no h uma forma padro de se conduzir estudos etnogrficos, contudo, indicam
algumas diretrizes para a aplicao dessa tcnica, dentre elas:
muito importante despender um tempo conhecendo as pessoas envolvidas e

estabelecendo uma relao de confiana.
Deve-se assumir que as pessoas que esto sendo observadas so boas em seu
trabalho e procurar capturar meios no padronizados de trabalhar. Esses meios
frequentemente apontam para eficincias no processo de trabalho que foram
incorporadas a partir da experincia individual.
Devem-se tomar notas detalhadas das prticas de trabalho durante a observao e

redigir um relatrio. possvel aprender bastante com os detalhes de como as
pessoas trabalham. Somente aps diversos desses detalhes terem sido coletados,
que um quadro coerente vai emergir.
til que o analista, antes de iniciar o trabalho, informe as pessoas e diga como a
observao vai ser conduzida e seu propsito.
No que se refere definio de quando realizar a observao, importante no

considerar apenas se o indivduo (ou indivduos) a ser observado estar trabalhando nos
processos de interesse no perodo agendado, mas tambm se esse processo de negcio de
interesse tem uma ocorrncia significativa no perodo considerado.
3.2.5 Prototipagem
Muitas vezes as pessoas acham difcil visualizar como um requisito especificado na
forma de uma sentena escrita ou por um conjunto de modelos vai se materializar em um
sistema de software. De maneira geral, pessoas tm dificuldade de descrever suas
necessidades sem ter algo tangvel sua frente. Nesses casos, se um prottipo do sistema
desenvolvido para demonstrar requisitos, fica mais fcil para usurios e outros interessados
encontrar problemas e sugerir como os requisitos podem ser melhorados. Afinal, criticar
mais fcil do que criar (KOTONYA; SOMMERVILLE, 1998; WIEGERS, 2003).
Um prottipo uma verso inicial do sistema que desenvolvido no incio do
processo de desenvolvimento. No contexto da engenharia de requisitos, um prottipo
desenvolvido com o propsito de apoiar o levantamento e a validao de requisitos. Assim,
nesse contexto, uma caracterstica essencial de um prottipo que ele seja desenvolvido
rapidamente (KOTONYA; SOMMERVILLE, 1998).

49
A prototipagem uma tcnica valiosa para o levantamento de requisitos. Ela torna os

requisitos mais reais e diminui lacunas de entendimento. Ao colocar o usurio na frente de
uma poro inicial ou uma imitao do sistema, a prototipagem estimula os usurios a pensar
e a estabelecer um dilogo sobre os requisitos. As consideraes tecidas sobre o prottipo
ajudam a se obter um entendimento compartilhado dos requisitos (WIEGERS, 2003). Alm
disso, a prototipagem muito til quando os interessados esto pouco familiarizados com as
solues disponveis (AURUM; WOHLIN, 2005). Este o caso, por exemplo, da introduo
de novas tecnologias.
Prottipos podem servir a outros propsitos, alm do propsito de clarear e completar
o entendimento sobre requisitos. Prottipos podem ser usados para explorar alternativas de
projeto (design), sobretudo no projeto de interfaces com o usurio, bem como a prototipagem
pode ser usada como parte de uma estratgia de desenvolvimento, na qual prottipos iniciais
vo sendo gradativamente transformados no produto final, atravs de uma sequncia de
iteraes de desenvolvimento. Contudo, do ponto de vista da Engenharia de Requisitos, foco
deste texto, a principal razo para se desenvolver um prottipo resolver incertezas a respeito
dos requisitos do sistema o mais cedo possvel. Assim, essas incertezas devem ser usadas para
decidir que partes do sistema prototipar e o que se espera aprender com as avaliaes do
prottipo (WIEGERS, 2003).
A prototipagem permite capturar as reaes iniciais do usurio em relao ao sistema.
Essas reaes podem ser obtidas atravs de observao, entrevistas ou questionrio e podem
ser usadas pelo engenheiro de requisitos para guiar iniciativas em direo de melhor atender
as necessidades dos usurios, bem como para ajudar a estabelecer (ou rever) prioridades e
redirecionar planos. Usurios, por sua vez, podem vislumbrar novas capacidades, no
imaginadas antes da interao com o prottipo e que surgiram da experimentao com o
mesmo (KENDALL; KENDALL, 2010):
Se um prottipo for desenvolvido para apoiar o levantamento de requisitos, faz sentido
utiliz-lo posteriormente na validao. Contudo, pode no valer a pena desenvolver um
prottipo apenas para apoiar a validao de requisitos (KOTONYA; SOMMERVILLE,
1998).
Diferentes tipos de prottipos podem ser desenvolvidos, sendo que diferentes autores
denominam esses tipos de forma diferente. Quanto s camadas da arquitetura que so
efetivamente implementadas, um prottipo pode ser:
Prottipo no-operacional ou de interface: apenas a camada de interface com o

usurio implementada; as demais camadas da arquitetura do sistema no so e,
portanto, o sistema no faz nenhum processamento propriamente dito. Wiegers
(2003) denomina este tipo de prottipo de prottipo horizontal, exatamente porque
ele no trata todas as camadas da arquitetura do sistema. til para avaliar certos
aspectos do sistema quando a codificao requerida pela aplicao custosa e a
noo bsica do que o sistema pode ser transmitida pela anlise de suas
interfaces (KENDALL; KENDALL, 2010). Prottipos no operacionais mostram
as opes de funes que estaro disponveis para o usurio e a aparncia das
interfaces. Contudo no contm funcionalidade real. s vezes, a navegao pode
funcionar, mas em alguns pontos o usurio pode se deparar apenas com uma
mensagem descrevendo o que seria realmente mostrado. Os dados que aparecem
em resposta a uma consulta so apenas ilustrativos e muitas vezes so constantes,
definidas no prprio cdigo do prottipo. Mesmo quando isso feito, deve-se

50
procurar usar dados reais para realar a validade do prottipo como um modelo do
sistema real. Normalmente, essa simulao boa o suficiente para os usurios
fazerem um julgamento se h funcionalidade faltando, errada ou desnecessria
(WIEGERS, 2003).
Prottipo operacional: funciona como se supe que o sistema real deveria

funcionar e implementa de alguma forma todas as camadas da arquitetura do
sistema. Wiegers (2003) denomina este tipo de prottipo de prottipo vertical, uma
vez que ele trata em alguma extenso de todas as camadas da arquitetura do
sistema. Um prottipo vertical tipicamente usado para reduzir riscos durante o
projeto, podendo ser usado, dentre outros, para avaliar se uma arquitetura vivel
e slida, ou para testar requisitos crticos. Prottipos verticais so construdos
usando ferramentas de produo, ou seja, as mesmas usadas para construir o
prprio sistema (WIEGERS, 2003).
Quanto ao uso futuro do prottipo como base para o sistema real, ou no, um prottipo
pode ser:
Prottipo descartvel: um prottipo exploratrio e no se pretende utiliz-lo

como uma parte real do sistema a ser fornecido (PFLEEGER, 2004). O prottipo
construdo apenas para apoiar o levantamento e a validao de requisitos, sendo
descartado aps essas fases. Prottipos descartveis enfatizam o desenvolvimento
rpido, sem prestar ateno a princpios de engenharia e qualidade de software.
Eles no devem ser mais elaborados do que o necessrio para atingir seus
objetivos. Assim, alguns atributos de qualidade, como robustez, confiabilidade e
desempenho, podem no ser levados em conta. O uso de prottipos descartveis
mais apropriado quando a equipe se depara com incertezas, ambiguidade, falta de
completeza e impreciso nos requisitos (WIEGERS, 2003).
Prottipo evolutivo: desenvolvido para se aprender mais sobre o problema e se

ter a base de uma parte ou de todo o software a ser fornecido (PFLEEGER, 2004).
Em contraste com um prottipo descartvel, o prottipo parte (ou uma verso) do
produto final e deve prover uma base para construir esse produto de forma
incremental. Portanto, deve considerar princpios de engenharia e qualidade de
software (WIEGERS, 2003).
Quanto ao conjunto de funcionalidades provido pelo prottipo, um prottipo pode ser:
Prottipo de caractersticas selecionadas: apenas uma poro do sistema

implementada no prottipo.
Prottipo completo: o prottipo apresenta todas as caractersticas do que se

imagina ser o sistema real.
Essas diferentes classificaes de prottipos so, em certa extenso, ortogonais e

podem ser combinadas. Por exemplo, um primeiro prottipo que implementa apenas parte das
interfaces de um sistema, mas que usado como base para o desenvolvimento posterior pode
ser classificado como um prottipo de interface, evolutivo e de caractersticas selecionadas. J
o que Kendall e Kendall (2010) chamam de um prottipo arranjado s pressas (i.e., um
prottipo que possui toda a funcionalidade do sistema final, mas que no foi construdo com o
devido cuidado e que, portanto, sua qualidade e desempenho so deficientes) pode ser
considerado um prottipo operacional e completo, podendo ser descartvel ou evolutivo,
dependendo se ele for ser usado, ou no, como base para o desenvolvimento do produto final.

51
O que Kendall e Kendall (2010) chamam de um prottipo primeiro de uma srie (i.e., um
sistema piloto desenvolvido para ser avaliado antes de ser distribudo) pode ser considerado
um prottipo operacional, completo e evolutivo. Contudo, nem todas as categorias podem ser
combinadas entre si. Por exemplo, um prottipo no operacional necessariamente um
prottipo de caractersticas selecionadas, uma vez que ele certamente no implementa todas as
caractersticas que se imagina ter o sistema real.
Diferentes tipos de prottipos podem ser combinados para apoiar um mesmo projeto
de desenvolvimento. Por exemplo, no estgio de levantamento preliminar de requisitos,
prottipos de interface podem ser usados para refinar requisitos. Esses requisitos so ento
gradativamente refinados e implementados em uma srie de prottipos evolutivos,
considerando inicialmente apenas os principais processos de negcio (caractersticas
selecionadas) e algumas camadas do software (interface com o usurio e lgica de negcio).
Outros elementos so incorporados ao produto final, por meio de incrementos e iteraes
sucessivas, at se obter o produto de software final.
A prototipagem tambm requer planejamento. Devem-se definir porque, quando e que
tipo de prottipo usar, selecionar usurios para avaliar o prottipo e definir como o feedback
do usurio ser obtido.
Usurios so fundamentais na prototipagem. Para capturar as reaes dos usurios em
relao ao prottipo, outras tcnicas de levantamento de informao devem ser usadas em
conjunto. Durante a experimentao do usurio com o prottipo, pode-se utilizar observao.
Para capturar opinies e sugestes, podem ser empregados, alm da observao, entrevistas e
questionrios (KENDALL; KENDALL, 2010).
Para o desenvolvimento do prottipo, as seguintes diretrizes podem ser teis
(KENDALL; KENDALL, 2010; WIEGERS, 2003):
Defina o propsito de um prottipo antes de comear a constru-lo.
Trabalhe com mdulos gerenciveis: para fins de prototipagem no necessrio e

muitas vezes, nem desejvel, construir um sistema completo.
Construa o prottipo rapidamente: a construo de um prottipo durante as fases

de levantamento e anlise de requisitos no pode consumir tempo em demasia,
caso contrrio perde sua finalidade. Para acelerar a construo, use ferramentas
adequadas.
Modifique o prottipo em iteraes sucessivas: o prottipo deve ser alterado em

direo s necessidades do usurio. Cada modificao requer uma nova avaliao.
Enfatize a interface com o usurio: as interfaces do prottipo devem permitir que o

usurio interaja facilmente com o sistema. Um mnimo de treinamento deve ser
requerido. Sistemas interativos com interfaces grficas so muito indicados
prototipagem.
A prototipagem pode trazer uma srie de benefcios, dentre eles (KENDALL;

KENDALL, 2010):
Permite alterar o sistema mais cedo no desenvolvimento, adequando-o mais de

perto s necessidades do usurio (menor custo de uma alterao).
Permite descartar um sistema quando este se mostrar inadequado (anlise de

viabilidade).

52
Possibilita desenvolver um sistema que atenda mais de perto as necessidades e

expectativas dos usurios, na medida em que permite uma interao com o usurio
ao longo de todo o ciclo de vida do desenvolvimento.
Contudo, a prototipagem tambm pode ser fonte de problemas, dentre eles

(KENDALL; KENDALL, 2010; AURUM; WOHLIN, 2005; WIEGERS, 2003):
Gerncia do projeto: Normalmente, vrias iteraes so necessrias para se refinar

um prottipo. Sob esta tica, surge uma importante questo: quando parar? Se essa
questo no for tratada com cuidado, a prototipagem pode se estender
indefinidamente. importante, pois, delinear e seguir um plano para coletar,
analisar e interpretar as informaes de feedback do usurio. Alm disso, em
alguns casos, trabalhar com prottipos pode ser caro e demandar muito tempo.
Considerar o prottipo como sendo o sistema final: o maior risco da prototipagem

que usurios, ao verem um prottipo rodando, concluam que o projeto est
prximo de seu fim, achando que o prottipo o sistema final. Analogamente, os
desenvolvedores podem se sentir tentados a transformar prottipos descartveis no
sistema, no levando em conta que a qualidade pode no ter sido apropriadamente
considerada. Assim, gerenciar expectativas fundamental para um uso bem
sucedido da prototipagem. Todos que veem o prottipo devem entender seu
propsito e suas limitaes.
3.2.6 Outras Tcnicas de Levantamento de Requisitos

Alm das tcnicas discutidas anteriormente, h vrias outras igualmente teis. Dentre
elas, podem ser citadas:
Investigao ou Anlise de Documentos: em qualquer negcio, h vrios

documentos cuja interpretao pode ajudar no levantamento de informaes, tais
como relatrios usados na tomada de deciso, fichas e uma variedade de
formulrios. Documentos com formato pr-determinado, tais como relatrios e
formulrios, tm um propsito especfico e um pblico-alvo e trazem informaes
muito teis. Relatrios de desempenho, por exemplo, podem mostrar metas da
organizao, a distncia em que a organizao se encontra da meta e a tendncia
atual. Relatrios usados no processo de tomada de deciso mostram informaes
compiladas e podem incorporar algum conhecimento sobre a estratgia da
organizao. Formulrios, assim como fichas, so muito teis para o levantamento
de requisitos de informao. Tais informaes so difceis de serem obtidas atravs
de outras tcnicas de levantamento de requisitos, como entrevistas e observao
(KENDALL; KENDALL, 2010).
Cenrios: so descries narrativas de processos correntes e futuros, incluindo

aes e interaes entre usurios e o sistema. O enredo do cenrio se refere a uma
poro do trabalho que est sendo estudada. O termo enredo usado para designar
que a poro de trabalho dividida em um nmero de passos ou cenas.
Explicando-se esses passos, explica-se o trabalho. Muitas vezes, cenrios so
usados para se chegar a um entendimento acerca de um caso de uso, mostrando,
passo a passo, como um caso de uso realizado. Uma vez que casos de uso
capturam uma poro discreta de funcionalidade, interessante definir cenrios
para contar a histria de um caso de uso. As pessoas geralmente consideram mais

53
fcil relatar exemplos de situaes reais do que abstrair descries e, da vem a

utilidade dos cenrios. Um cenrio pode comear com um esboo da interao e,
durante o levantamento de requisitos, detalhes podem ser adicionados para criar
uma descrio mais completa dessa interao. Neste sentido, cenrios requerem
uma abordagem incremental e interativa de desenvolvimento. Alm disso, cenrios
tipicamente no consideram a estrutura interna do sistema (AURUM; WOHLIN,
2005; ROBERTSON; ROBERTSON, 2006; SOMMERVILLE, 2007).
Reso de Requisitos: sempre uma boa prtica de engenharia de software

reutilizar tanto conhecimento quanto possvel durante o desenvolvimento de um
novo sistema. Isso no diferente no caso de requisitos (KOTONYA;
SOMMERVILLE, 1998). O reso de requisitos possvel em diversas situaes,
dentre elas: (i) requisitos relacionados ao mesmo domnio de aplicao; (ii)
requisitos relacionados mesma tarefa; (iii) requisitos de sistemas considerados
similares; e (iv) requisitos que refletem polticas organizacionais. Alm disso,
modelos podem ser reutilizados, conforme discutido no Captulo 8 deste texto.
3.2.7 Aplicando as Tcnicas de Levantamento de Requisitos

Duas importantes questes que precisam ser abordadas em relao s tcnicas de
levantamento de requisitos so (AURUM; WOHLIN, 2005):
Que tcnica(s) aplicar durante uma atividade de levantamento de requisitos?
Quais dessas tcnicas so complementares?
Em ltima instncia, cada situao , em alguma extenso, nica e, portanto, as

respostas a essas perguntas so dependentes do contexto do projeto (AURUM; WOHLIN,
2005). De maneira geral, as principais tcnicas discutidas neste texto so complementares.
Algumas informaes so difceis de serem obtidas atravs de entrevistas ou
observao, tais como dados sobre um determinado objeto ou evento, informao financeira e
contextos da organizao. Tais informaes revelam, tipicamente, um histrico da
organizao e sua direo. Nestes casos, a investigao de documentos uma boa opo, pois
fatos obtidos em uma investigao podem explicar o desempenho passado da organizao.
Por outro lado, metas projetam o futuro. Entrevistas so importantes para se determinar metas,
obter necessidades e perspectivas individuais. A coleta colaborativa de requisitos pode ser
uma boa alternativa ao uso de entrevistas, sobretudo para se ter um entendimento coletivo e
para decidir sobre requisitos.
Questionrios podem ser usados para quantificar o que foi levantado usando outras
tcnicas de levantamento e, portanto, um questionrio pode ser definido com base no que foi
levantado preliminarmente, por exemplo, em uma entrevista. Questionrios tambm podem
ser usados para examinar uma grande amostra de usurios do sistema para sentir problemas
ou levantar questes importantes, antes de se programar entrevistas (KENDALL; KENDALL,
2010).
Observao pode ser usada para confirmar ou refutar informaes levantadas em
entrevistas, workshops de requisitos e/ou questionrios, bem como para capturar informao
complementar sobre os interessados, seus processos de negcio e o seu ambiente de trabalho.
De maneira inversa, podem-se utilizar outras tcnicas para completar informaes obtidas em
uma observao.

54
A observao pode ser combinada tambm com a prototipagem. Uma vez construdo
um prottipo, podem-se observar os usurios utilizando o prottipo, de modo a avaliar o
mesmo e derivar novos requisitos. Para capturar as reaes dos usurios em relao ao
prottipo, outras tcnicas de levantamento de requisitos tambm podem ser usadas, tais como
entrevistas e questionrios para capturar opinies e sugestes. Por fim, cenrios podem ser
usados para derivar prottipos e prottipos podem ser apresentados no contexto da discusso
de um cenrio, sendo tcnicas complementares (KENDALL; KENDALL, 2010;
SOMMERVILLE, 2007).
De fato, quase todas as tcnicas so complementares em alguma extenso, podendo ser
alternativas em outras. Assim, importante avaliar cada caso e escolher o melhor conjunto de
tcnicas a serem aplicadas, levando em considerao, dentre outros, a experincia dos
analistas no uso das diversas tcnicas, o perfil dos interessados e o tempo disponvel.
3.3 Requisitos e Modelagem de Processos de Negcio

O uso de sistemas de informao tem por objetivo principal apoiar aes dos processos
de negcio das organizaes. Deve-se ter em mente que o principal interesse dos clientes no
o sistema de informao em si, mas sim os efeitos positivos gerados pela sua utilizao.
Assim, durante o levantamento de requisitos, necessrio compreender o contexto
organizacional, no qual o sistema ser inserido, bem como se alinhar aos objetivos desse
contexto. Se o entendimento do contexto organizacional no ocorre, os requisitos levantados
tendem a ficar mais centrados em aspectos tecnolgicos, sem levar em considerao fatores
organizacionais, tais como (CARVALHO, 2009):
Regras de negcio que tm impacto sobre o sistema;
Usurios que utilizam as informaes geradas pelo sistema;
Impactos gerados pelo sistema na forma de execuo dos processos de negcio da

organizao.
A relao entre os processos de negcio e o entendimento do domnio de um sistema

de informao constatada por diversos autores. Frye e Gulledge (2007), por exemplo,
afirmam que os sistemas de informao habilitam os processos de negcio e que, se os
processos de negcio e os sistemas no estiverem alinhados, ento os sistemas no atendero
s expectativas de seus usurios. Essa falta de alinhamento apontada como sendo uma das
principais causas do fracasso de projetos de desenvolvimento de sistemas de informao.
Assim, o uso de tcnicas de levantamento de requisitos de sistemas de informao
baseadas em processos de negcio torna-se relevante, pois esses sistemas mantm estreita
relao com o ambiente organizacional. Um tratamento dissociado do aparato de
levantamento de requisitos da viso de negcios pode levar subutilizao de potencialidades
tecnolgicas (CARVALHO, 2009).
Um modelo de negcio (business model) , na verdade, um conjunto de modelos que
prov uma visualizao dos processos de negcio, de como estes so executados, quais so as
suas metas, como cada processo trabalha para atingir essas metas, quais as unidades
organizacionais e os papis das pessoas envolvidos em cada atividade do processo, quais as
localidades onde a organizao est distribuda e quais eventos deflagram seus processos e
atividades (KNIGHT, 2004). A Figura 3.1 esquematiza os diferentes aspectos envolvidos em
um modelo de negcio.

55
Figura 3.1 Aspectos Envolvidos em um Modelo de Negcio (KNIGHT, 2004).

Como ilustra a Figura 3.2, para modelar esses diferentes aspectos, diferentes tipos de
modelos podem ser elaborados, dentre eles (KNIGHT, 2004):
Modelo organizacional: representa as unidades organizacionais, seus papis e seus

relacionamentos;
Modelo de localizao geogrfica: representa as localidades pelas quais a organizao

est distribuda e os relacionamentos entre localidades e unidades organizacionais;
Modelo de objetivos: mostra os objetivos da organizao e seus relacionamentos, o

desdobramento dos objetivos em subobjetivos e o relacionamento entre os objetivos e
os processos de negcio;
Modelo de processos: representa os processos de negcio executados na organizao

(com suas atividades e relacionamentos) e seus desdobramentos em subprocessos e
atividades;
Modelo de atividades: mostra o relacionamento entre as atividades executadas nos

processos de negcio, seus responsveis, objetos de negcio e eventos que disparam
ou so disparados com a execuo das atividades.

56
Modelo de Localidades
Modelo Organizacional
Modelo de Processos
possui
Estrutura Organizacional
Localizao
Geogrfica
executa
realizada em
Processo
possui
atende
Atividade manipula
dispara
Evento
Objetivo
desmembrado
em
Modelo de Objetivos
Objeto
Modelo de Atividades
Figura 3.2 Submodelos do Modelo de Negcio (adaptado de (KNIGHT, 2004)).

H muitas notaes utilizadas para representar os vrios tipos de modelos citados
anteriormente, sendo que alguns autores propem o uso de diagramas da UML ou extenses
deles para essa finalidade. Em especial, os diagramas de casos de uso e de atividades so
bastante utilizados para a representao de modelos de processos de negcio.
Diferentes propostas usam diferentes tipos de modelos para derivar requisitos. Um dos
usos mais comuns de modelos de processo na Engenharia de Requisitos a derivao de
casos de uso a partir da anlise das informaes capturadas nos diagramas que representam os
aspectos do negcio, incluindo a identificao das atividades dos processos que sero
apoiadas pelo sistema, bem como a identificao dos atores dos casos de uso a partir dos
executores (pessoas ou mquinas) relacionados aos processos.
Segundo Davenport (2000), dentre os principais benefcios da implantao de sistemas
de informao para apoiar processos de negcio esto: (i) a automatizao de tarefas antes
realizadas manualmente, (ii) a racionalizao dos dados, (iii) a implementao de melhorias
nos processos da organizao, (iv) ajuste das interfaces entre reas, (v) aperfeioamento dos
servios aos clientes e (vi) gerao de informaes gerenciais.
No decorrer da modelagem de processos, a reunio dos envolvidos no processo
permite que seja estabelecida uma viso abrangente de todo o contexto, possibilitando a
identificao de divergncias e abrindo espaos para a melhoria, o que pode levar
reengenharia dos processos de negcio. Processos correntes (processos AS IS) podem dar
origem a novos processos, mais eficazes, a serem implantados na organizao (processos TO
BE). O contexto no qual o sistema ser inserido considerado como parte integral na
aplicao da abordagem orientada a modelos de processos, permitindo que o sistema seja
considerado um agente de mudanas e no apenas a automatizao das prticas correntes,
sejam elas boas ou no.

57
A modelagem de processos complementa as prticas convencionais de engenharia de

requisitos, auxiliando o cliente a adquirir maturidade acerca da complexidade do seu prprio
negcio e revelando o grau de adequao dos requisitos levantados com os processos (e
objetivos) da organizao (CARDOSO; ALMEIDA; GUIZZARDI, 2008).
importante realar que a modelagem de processos de negcios independe do
desenvolvimento de sistemas e pode ser conduzida independentemente para a construo de
uma arquitetura organizacional de referncia (enterprise architecture). Quando necessria a
construo de um sistema que d apoio a partes dos processos modelados nessa arquitetura,
necessrio retornar ao cliente somente para levantar requisitos de sistema e no para levantar
requisitos de negcio (CARDOSO; ALMEIDA; GUIZZARDI, 2008).
3.4 Escrevendo e Documentando Requisitos de Usurio

Os resultados do levantamento de requisitos tm de ser registrados em um documento,
de modo que possam ser verificados, validados e utilizados como base para outras atividades
do processo de software. Para que sejam teis, os requisitos tm de ser escritos em um
formato compreensvel por todos os interessados. Alm disso, esses interessados devem
interpret-los uniformemente.
Normalmente, requisitos so documentados usando alguma combinao de linguagem
natural, modelos, tabelas e outros elementos. A linguagem natural quase sempre
imprescindvel, uma vez que a forma bsica de comunicao compreensvel por todos os
interessados. Contudo, ela geralmente abre espaos para ambiguidades e m interpretao.
Assim, interessante procurar estruturar o uso da linguagem natural e complementar a
descrio dos requisitos com outros elementos.
Conforme discutido no Captulo 2, diferentes abordagens podem ser usadas para
documentar requisitos. Neste texto, sugerimos elaborar dois documentos: o documento de
definio de requisitos (ou somente documento de requisitos) e o documento de especificao
de requisitos. O documento de requisitos mais sucinto, escrito em um nvel mais apropriado
para o cliente e contempla apenas os requisitos de usurio. O documento de especificao de
requisitos mais detalhado, escrito a partir da perspectiva dos desenvolvedores (PFLEEGER,
2004), normalmente contendo diversos modelos para descrever requisitos de sistema.
Os requisitos de usurio devem ser descritos de modo a serem compreensveis pelos
interessados no sistema que no possuem conhecimento tcnico detalhado. Eles devem
especificar apenas o comportamento externo do sistema, em uma linguagem simples, direta e
sem usar terminologia especfica de software (SOMMERVILLE, 2007).
O Documento de Definio de Requisitos (ou simplesmente Documento de
Requisitos) tem como propsito descrever os requisitos de usurio, tendo como pblico-alvo
clientes, usurios, gerentes (de cliente e de fornecedor) e desenvolvedores.
H muitos formatos distintos propostos na literatura para documentos de requisitos.
Neste texto, proposta uma estrutura bastante simples para esse tipo de documento, contendo
apenas quatro sees:

58
1. Introduo: breve introduo ao documento, descrevendo seu propsito e estrutura.

2. Descrio do Propsito do Sistema: descreve o propsito geral do sistema.
3. Descrio do Minimundo: apresenta, em um texto corrido, uma viso geral do
domnio, do problema a ser resolvido e dos processos de negcio apoiados, bem
como as principais ideias do cliente sobre o sistema a ser desenvolvido.
4. Requisitos de Usurio: apresenta os requisitos de usurio em linguagem natural.
Trs conjuntos de requisitos devem ser descritos nesta seo: requisitos funcionais,
requisitos no funcionais e regras de negcio.
As trs primeiras sees no tm nenhuma estrutura especial, sendo apresentadas na
forma de um texto corrido. A introduo deve ser breve e basicamente descrever o propsito e
a estrutura do documento, podendo seguir um padro preestabelecido pela organizao. A
descrio do propsito do sistema deve ser direta e objetiva, tipicamente em um nico
pargrafo. J a descrio do minimundo um pouco maior, algo entre uma e duas pginas,
descrevendo aspectos gerais e relevantes para um primeiro entendimento do domnio, do
problema a ser resolvido e dos processos de negcio apoiados. Contm as principais ideias do
cliente sobre o sistema a ser desenvolvido, obtidas no levantamento preliminar e exploratrio
do sistema. No se devem incluir detalhes.
A Seo 4, por sua vez, no deve ter um formato livre. Ao contrrio, deve seguir um
formato estabelecido pela organizao, contendo, dentre outros: identificador do requisito,
descrio, tipo, origem, prioridade, responsvel, interessados, dependncias em relao a
outros requisitos e requisitos conflitantes. A definio de padres organizacionais para a
definio de requisitos essencial para garantir uniformidade e evitar omisso de informaes
importantes acerca dos requisitos (SOMMERVILLE, 2007; WIEGERS, 2003). Como
consequncia, o padro pode ser usado como um guia para a verificao de requisitos. A
Tabela 3.4 apresenta o padro tabular sugerido neste texto. Sugerem-se agrupar requisitos de
um mesmo tipo em diferentes tabelas. Assim, a informao do tipo do requisito no aparece
explicitamente no padro proposto. Alm disso, informaes complementares podem ser
adicionadas em funo do tipo de requisito. A seguir, discute-se como cada um dos itens da
tabela pode ser tratado, segundo uma perspectiva geral. Na sequncia, so tecidas
consideraes mais especficas sobre a descrio dos diferentes tipos de requisitos.
Tabela 3.4 Tabela de Requisitos.
Identificador
Descrio
Origem
Prioridade
Responsvel
Interessados
Dependncias
Conflitos
Os requisitos devem possuir identificadores nicos para permitir a identificao e o

rastreamento na gerncia de requisitos. H diversas propostas de esquemas de rotulagem de
requisitos. Neste texto, recomenda-se usar um esquema de numerao sequencial por tipo de
requisito, sendo usados os seguintes prefixos para designar os diferentes tipos de requisitos:
RF requisitos funcionais; RNF requisitos no funcionais; RN regras de negcio. Para
outros esquemas de rotulagem, vide (WIEGERS, 2003). importante destacar que, quando
um requisito eliminado, seu identificador no pode ser atribudo a outro requisito.
A descrio do requisito normalmente feita na forma de uma sentena em linguagem
natural. Ainda que expressa em linguagem natural, importante adotar um estilo consistente e
usar a terminologia do usurio ao invs do jargo tpico da computao. Em relao ao estilo,

59
recomenda-se utilizar sentenas em um dos seguintes formatos para descrever requisitos

funcionais e no funcionais:
O sistema deve <verbo indicando ao, seguido de complemento>: use o verbo

dever para designar uma funo ou caracterstica requerida para o sistema, ou seja,
para descrever um requisito obrigatrio. Exemplos: O sistema deve efetuar o
controle dos clientes da empresa. O sistema deve processar um pedido do cliente
em um tempo inferior a cinco segundos, contado a partir da entrada de dados.
O sistema pode <verbo indicando ao, seguido de complemento>: use o verbo

poder para designar uma funo ou caracterstica desejvel para o sistema, ou seja,
para descrever um requisito desejvel, mas no essencial. Exemplos: O sistema
pode notificar usurios em dbito. O sistema pode sugerir outros produtos para
compra, com base em produtos colocados no carrinho de compras do usurio.
Em algumas situaes, pode-se querer explicitar que alguma funcionalidade ou

caracterstica no deve ser tratada pelo sistema. Isso pode ser feito indicando-se uma sentena
com a seguinte estrutura: O sistema no deve <verbo indicando ao, seguido de
complemento>. Tambm possvel registrar que alguma tarefa especfica relacionada ao
sistema no far parte do escopo do projeto, tal como a carga de dados de um sistema
existente. Nestes casos, pode ser til ter uma tabela de requisitos negativos.
Wiegers (2003) recomenda diversas diretrizes para a redao de requisitos, dentre elas:
Escreva frases completas, com a gramtica, ortografia e pontuao correta. Procure

manter frases e pargrafos curtos e diretos.
Use os termos consistentemente. Defina-os em um glossrio.
Prefira a voz ativa (o sistema deve fazer alguma coisa) voz passiva (alguma coisa
deve ser feita).
Sempre que possvel, identifique o tipo de usurio. Evite descries genricas

como o usurio deve [...]. Se o usurio no caso for, por exemplo, o caixa do
banco, indique claramente o caixa do banco deve [...].
Evite termos vagos, que conduzam a requisitos ambguos e no testveis, tais

como rpido, adequado, fcil de usar etc.
Escreva requisitos em um nvel consistente de detalhe. Evite requisitos

desnecessariamente pequenos, tais como requisitos individuais para tratar de aes
de incluso, remoo, alterao e consulta de um elemento de informao (p.ex.,
O sistema deve permitir a alterao de dados de clientes). Em casos como este,
considere agrupar os requisitos menores em um requisito maior (tal como O
sistema deve permitir o controle de clientes). Por outro lado, evite longos
pargrafos narrativos que contenham mltiplos requisitos. Divida um requisito
desta natureza em vrios menores.
O nvel de especificao de um requisito deve ser tal que, se o requisito

satisfeito, a necessidade do cliente atendida. Contudo, evite restringir
desnecessariamente o projeto (design).
Escreva requisitos individualmente testveis. Um requisito bem escrito deve

permitir a definio de um pequeno conjunto de testes para verificar se o requisito
foi corretamente implementado.

60
Conforme apontado anteriormente, requisitos devem ser testveis. Robertson e

Robertson (2006) sugerem trs maneiras de tornar os requisitos testveis:
Especificar uma descrio quantitativa de cada advrbio ou adjetivo, de modo que

o significado dos qualificadores fique claro e no ambguo.
Trocar os pronomes pelos nomes das entidades.
Garantir que todo termo importante seja definido em um glossrio no documento

de requisitos.
A origem de um requisito deve apontar a partir de que entidade (pessoa, documento,

atividade) o requisito foi identificado. Um requisito identificado durante uma investigao de
documentos, p.ex., tem como origem o(s) documento(s) inspecionado(s). J um requisito
levantado em uma entrevista com um certo usurio tem como origem o prprio usurio. A
informao de origem importante para se conseguir rastrear requisitos para a sua origem,
prtica muito recomendada no contexto da Gerncia de Requisitos.
Requisitos podem ter importncia relativa diferente em relao a outros requisitos.
Assim, importante que o cliente e outros interessados estabeleam conjuntamente a
prioridade de cada requisito.
muito importante saber quem o analista responsvel por um requisito, bem como
quem so os interessados (clientes, usurios etc.) naquele requisito. So eles que estaro
envolvidos nas discusses relativas ao requisito, incluindo a tentativa de acabar com conflitos
e a definio de prioridades. Assim, deve-se registrar o nome e o papel do responsvel e dos
interessados em cada requisito.
Um requisito pode depender de outros ou conflitar com outros. Quando as
dependncias e conflitos forem detectados, devem-se listar os respectivos identificadores nas
colunas de dependncias e conflitos.
3.4.1 - Escrevendo Requisitos Funcionais

As diretrizes apresentadas anteriormente aplicam-se integralmente a requisitos
funcionais. Assim, no h outras diretrizes especficas para os requisitos funcionais. Deve-se
realar apenas que, quando expressos como requisitos de usurio, requisitos funcionais so
geralmente descritos de forma abstrata, no cabendo neste momento entrar em detalhes.
Detalhes vo ser naturalmente adicionados quando esses mesmos requisitos forem descritos
na forma de requisitos de sistema.
Uma alternativa largamente empregada para especificar requisitos funcionais no nvel
de requisitos de sistema a modelagem. Uma das tcnicas mais comumente utilizadas para
descrever requisitos funcionais como requisitos de sistema a modelagem de casos de uso.
Vale ressaltar que os processos de negcio a serem apoiados pelo sistema tipicamente
do origem a requisitos funcionais. Assim, a partir de uma descrio de minimundo ou em um
relatrio proveniente de alguma atividade de levantamento de requisitos, podem ser
encontrados requisitos funcionais a partir da identificao dos processos a serem apoiados.
Alm disso, o controle de informaes que o negcio precisa gerenciar para apoiar os
processos de negcio tambm deve dar origem a requisitos funcionais representando
atividades custodiais (cadastros).

61
3.4.2 - Escrevendo Regras de Negcio

Toda organizao opera de acordo com um extenso conjunto de polticas corporativas,
leis, padres industriais e regulamentaes governamentais. Tais princpios de controle so
coletivamente designados por regras de negcio. Uma regra de negcio uma declarao que
define ou restringe algum aspecto do negcio, com o propsito de estabelecer sua estrutura ou
controlar ou influenciar o comportamento do negcio (WIEGERS, 2003).
Sistemas de informao tipicamente precisam fazer cumprir as regras de negcio. Ao
contrrio dos requisitos funcionais e no funcionais, a maioria das regras de negcio originase fora do contexto de um sistema especfico. Assim, as regras a serem tratadas pelo sistema
precisam ser identificadas, documentadas e associadas aos requisitos do sistema em questo
(WIEGERS, 2003).
Wiegers identifica cinco tipos principais de regras de negcio, cada um deles
apresentando uma forma tpica de ser escrito:
Fatos ou invariantes: declaraes que so verdade sobre o negcio. Geralmente

descrevem associaes ou relacionamentos entre importantes termos do negcio.
Ex.: Todo pedido tem uma taxa de remessa.
Restries: como o prprio nome indica, restringem as aes que o sistema ou seus
usurios podem realizar. Algumas palavras ou frases sugerem a descrio de uma
restrio, tais como deve, no deve, no pode e somente. Ex.: Um aluno s pode
tomar emprestado, concomitantemente, at trs livros.
Ativadores de Aes: so regras que disparam alguma ao sob condies

especficas. Uma declarao na forma Se <alguma condio verdadeira ou
algum evento ocorre>, ento <algo acontece> indicada para descrever
ativadores de aes. Ex.: Se a data para retirada do livro ultrapassada e o livro
no retirado, ento a reserva cancelada. Quando as condies que levam s
aes so uma complexa combinao de mltiplas condies individuais, ento o
uso de tabelas de deciso ou rvores de deciso indicado. As figuras 3.4 e 3.5
ilustram uma mesma regra de ativao de aes descrita por meio de uma rvore
de deciso e de uma tabela de deciso, respectivamente.
Tratamento
Sem atraso de
pagamento
registrado
Volume de
negcios
R$ 1 milho
Volume de
negcios <
R$ 1 milho
Com atraso
de pagamento
registrado
Prioritrio
Tempo de
trabalho
20 anos
Tempo de
trabalho <
20 anos
Figura 3.4 Exemplo de rvore de Deciso.
Prioritrio
Normal
Normal

62
Tratamento de Clientes
Volume de Negcios R$ 1 milho?
Atraso de pagamento registrado?
Tempo de trabalho 20 anos?
Tratamento Prioritrio
X
X
Tratamento Normal
Figura 3.5 Exemplo de Tabela de Deciso.
Inferncias: so regras que derivam novos fatos a partir de outros fatos ou clculos.
So normalmente escritas no padro se / ento, como as regras ativadoras de
ao, mas a clusula ento implica um fato ou nova informao e no uma ao a
ser tomada. Ex.: Se o usurio no devolve um livro dentro do prazo estabelecido,
ento ele torna-se um usurio inadimplente.
Computaes: so regras de negcio que definem clculos a serem realizados

usando algoritmos ou frmulas matemticas especficos. Podem ser expressas
como frmulas matemticas, descrio textual, tabelas etc. Ex.: Multa = Valor de
Locao * Nmero de Dias de Atraso.
Ao contrrio de requisitos funcionais e no funcionais, regras de negcio no so

passveis de serem capturadas por meio de perguntas simples e diretas, tal como Quais so
suas regras de negcio?. Regras de negcio emergem durante a discusso de requisitos,
sobretudo quando se procura entender a base lgica por detrs de requisitos e restries
apontados pelos interessados (WIEGERS, 2003). Assim, no se deve pensar que ser possvel
levantar muitas regras de negcio em um levantamento preliminar de requisitos. Pelo
contrrio, as regras de negcio vo surgir principalmente durante o levantamento detalhado
dos requisitos. Wiegers (2003) aponta diversas potenciais origens para regras de negcio e
sugere tipos de questes que o analista pode fazer para tentar capturar regras advindas dessas
origens:
Polticas: Por que necessrio fazer isso desse jeito?
Regulamentaes: O que o governo requer?
Frmulas: Como este valor calculado?
Modelos de Dados: Como essas entidades de dados esto relacionadas?
Ciclo de Vida de Objetos: O que causa uma mudana no estado desse objeto?
Decises de Atores: O que o usurio pode fazer a seguir?
Decises de Sistema: Como o sistema sabe o que fazer a seguir?
Eventos: O que pode (e no pode) acontecer?
Regras de negcio normalmente tm estreita relao com requisitos funcionais. Uma

regra de negcio pode ser tratada no contexto de certa funcionalidade. Neste caso, a regra de
negcio deve ser listada na coluna de dependncias do requisito funcional (vide Tabela 3.4).
H casos em que uma regra de negcio conduz a um requisito funcional para fazer cumprir a

63
regra. Neste caso, a regra de negcio considerada a origem do requisito funcional

(WIEGERS, 2003).
importante destacar a importncia das regras (restries) obtidas a partir de modelos
conceituais estruturais, ditas restries de integridade. Elas complementam as informaes de
um modelo deste tipo e capturam restries relativas a relacionamentos entre elementos de um
modelo que normalmente no so passveis de serem capturadas pelas notaes grficas
utilizadas na elaborao de modelos conceituais estruturais. Tais regras devem ser
documentadas junto ao modelo conceitual estrutural do sistema. Seja o exemplo do modelo
conceitual estrutural da Figura 3.6. Esse fragmento de modelo indica que: (i) um aluno cursa
um curso; (ii) um aluno pode se matricular em nenhuma ou vrias turmas; (iii) um curso
possui um conjunto de disciplinas em sua matriz curricular; (iv) uma turma de uma
disciplina especfica. Contudo, nada diz sobre restries entre o estabelecimento dessas vrias
relaes. Suponha que o negcio indique que a seguinte restrio deve ser considerada: Um
aluno s pode ser matricular em turmas de disciplinas que compe a grade curricular do curso
que esse aluno cursa. Essa restrio tem de ser escrita para complementar o modelo.
Figura 3.6 Exemplo de Fragmento de Modelo de Dados com Restrio de Integridade.

Outro tipo de restrio importante so as regras que impem restries sobre
funcionalidades de insero, atualizao ou excluso de dados, devido a relacionamentos
existentes entre as entidades. Voltando ao exemplo da Figura 3.7, a excluso de disciplinas
no deve ser livre, uma vez que turmas so existencialmente dependentes de disciplinas.
Assim, a seguinte regra de integridade referencial de dados deve ser considerada: Ao excluir
uma disciplina, devem-se excluir todas as turmas a ela relacionadas. Essas regras so
denominadas neste texto como restries de processamento e, uma vez que dizem respeito a
funcionalidades, devem ser documentadas junto com a descrio do caso de uso que detalha a
respectiva funcionalidade.
3.4.3 - Escrevendo Requisitos No Funcionais

Clientes e usurios naturalmente enfocam a especificao de requisitos funcionais e
regras de negcio. Entretanto para um sistema ser bem sucedido, necessrio mais do que
entregar a funcionalidade correta. Usurios tambm tm expectativas sobre quo bem o
sistema vai funcionar. Caractersticas que entram nessas expectativas incluem: quo fcil
usar o sistema, quo rapidamente ele roda, com que frequncia ele falha e como ele trata
condies inesperadas. Essas caractersticas, coletivamente conhecidas como atributos de
qualidade do produto de software, so parte dos requisitos no funcionais do sistema. Essas

64
expectativas de qualidade do produto tm de ser exploradas durante o levantamento de

requisitos (WIEGERS, 2003).
Clientes geralmente no apontam suas expectativas de qualidade explicitamente.
Contudo, informaes providas por eles durante o levantamento de requisitos fornecem
algumas pistas sobre o que eles tm em mente. Assim, necessrio definir o que os usurios
pensam quando eles dizem que o sistema deve ser amigvel, rpido, confivel ou robusto
(WIEGERS, 2003).
H muitos atributos de qualidade que podem ser importantes para um sistema. Uma
boa estratgia para levantar requisitos no funcionais de produto consiste em explorar uma
lista de potenciais atributos de qualidade que a grande maioria dos sistemas deve apresentar
em algum nvel. Por exemplo, o modelo de qualidade externa e interna de produtos de
software definido na norma ISO/IEC 9126-1, utilizado como referncia para a avaliao de
produtos de software, define seis caractersticas de qualidade, desdobradas em
subcaractersticas, a saber (ISO/IEC, 2001):
Funcionalidade: refere-se existncia de um conjunto de funes que satisfaz s

necessidades explcitas e implcitas e suas propriedades especficas. Tem como
subcaractersticas: adequao, acurcia, interoperabilidade, segurana de acesso e
conformidade.
Confiabilidade: diz respeito capacidade do software manter seu nvel de

desempenho, sob condies estabelecidas, por um perodo de tempo. Tem como
subcaractersticas: maturidade, tolerncia a falhas, recuperabilidade e
conformidade.
Usabilidade: refere-se ao esforo necessrio para se utilizar um produto de

software, bem como o julgamento individual de tal uso por um conjunto de
usurios. Tem como subcaractersticas: inteligibilidade, apreensibilidade,
operacionalidade, atratividade e conformidade.
Eficincia: diz respeito ao relacionamento entre o nvel de desempenho do

software e a quantidade de recursos utilizados sob condies estabelecidas. Tem
como subcaractersticas: comportamento em relao ao tempo, comportamento em
relao aos recursos e conformidade.
Manutenibilidade: concerne ao esforo necessrio para se fazer modificaes no

software. Tem como subcaractersticas: analisabilidade, modificabilidade,
estabilidade, testabilidade e conformidade.
Portabilidade: refere-se capacidade do software ser transferido de um ambiente

para outro. Tem como subcaractersticas: adaptabilidade, capacidade para ser
instalado, coexistncia, capacidade para substituir e conformidade.
interessante observar que, mesmo dentre as subcaractersticas de funcionalidade, h

atributos que geralmente no so pensados pelos usurios como funes que o sistema deve
prover, tais como interoperabilidade e segurana de acesso. Assim, importante avaliar em
que grau o sistema em questo necessita apresentar tais caractersticas.

65
Outro ponto importante a destacar que diferentes autores listam diferentes

caractersticas de qualidade, usando classificaes prprias. Por exemplo, Bass, Clements e
Kazman (2003) consideram, dentre outros, os seguintes atributos de qualidade:
Disponibilidade: refere-se a falhas do sistema e suas consequncias associadas.

Uma falha ocorre quando o sistema no entrega mais um servio consistente com
sua especificao.
Modificabilidade: diz respeito ao custo de modificao do sistema.
Desempenho: refere-se a tempo.
Segurana: est relacionada habilidade do sistema impedir o uso no autorizado,

enquanto ainda prov seus servios para os usurios legtimos.
Testabilidade: refere-se ao quo fcil testar o software.
Usabilidade: diz respeito ao quo fcil para o usurio realizar uma tarefa e o tipo
de suporte ao usurio que o sistema prov.
Alm das caractersticas de qualidade que se aplicam diretamente ao sistema, ditas

caractersticas de qualidade de produto, Bass, Clements e Kazman (2003) listam outras
caractersticas relacionadas a metas de negcio, dentre elas: tempo para chegar ao mercado
(time to market), custo-benefcio, tempo de vida projetado para o sistema, mercado alvo,
cronograma de implementao e integrao com sistemas legados.
Wiegers (2003), por sua vez, agrupa atributos de qualidade do produto em duas
categorias principais: atributos importantes para os usurios e atributos importantes para os
desenvolvedores. Como atributos importantes para os usurios so apontados os seguintes:
disponibilidade, eficincia, flexibilidade, integridade, interoperabilidade, confiabilidade,
robustez e usabilidade. Como atributos importantes para os desenvolvedores, so enumerados
os seguintes: manutenibilidade, portabilidade, reusabilidade e testabilidade.
Uma vez que no h um consenso sobre quais atributos de qualidade considerar, cada
organizao deve definir as categorias de requisitos no funcionais a serem consideradas em
seus projetos de software. Alm disso, essa informao deve ser adicionada tabela de
requisitos no funcionais e, portanto, a Tabela 3.4, quando usada para descrever requisitos no
funcionais, deve ter uma coluna adicional para indicar a categoria do requisito no funcional.
Em um mundo ideal, todo sistema deveria exibir os valores mximos para todos os
atributos de qualidade. Contudo, como no mundo real isso no possvel, fundamental
definir quais atributos so mais importantes para o sucesso do projeto. Uma abordagem para
tratar essa questo consiste em pedir para que diferentes representantes de usurios
classifiquem cada atributo em uma escala de 1 (sem importncia) a 5 (muito importante). As
respostas ajudam o analista a determinar quais atributos so mais importantes. Obviamente,
conflitos podem surgir e precisam ser resolvidos (WIEGERS, 2003).
Um aspecto a considerar que diferentes partes do produto podem requerer diferentes
combinaes de atributos de qualidade. Assim, importante tambm diferenciar
caractersticas que se aplicam ao produto por inteiro daquelas que so necessrias para certas
partes do sistema (WIEGERS, 2003).
Uma vez priorizados os atributos de qualidade, o analista deve passar, ento, a
trabalhar com os usurios no sentido de especificar requisitos mensurveis, e por conseguinte
testveis, para cada atributo considerado importante. Se os atributos de qualidade so

66
especificados de maneira no passvel de verificao, no possvel dizer posteriormente se

eles foram atingidos ou no. Quando apropriado, devem-se indicar escalas ou unidades de
medida para cada atributo e os valores mnimo, alvo e mximo. Se no for possvel
quantificar todos os atributos importantes, deve-se, pelo menos, definir suas prioridades.
Pode-se, ainda, perguntar aos usurios o que constituiria um valor inaceitvel para cada
atributo e definir testes que tentem forar o sistema a demonstrar tais caractersticas
(WIEGERS, 2003).
Robertson e Robertson (2006) sugerem definir critrios de adequao ou ajuste (fit
criteria) para permitir quantificar requisitos (tanto funcionais como no funcionais) e associlos descrio dos requisitos. primeira vista, alguns requisitos no funcionais podem
parecer difceis de quantificar. Entretanto, deve ser possvel atribuir nmeros a eles. Se no se
consegue quantificar e medir um requisito, ento provvel que o requisito no seja de fato
um requisito. Ele pode ser, por exemplo, vrios requisitos descritos em um s.
Seja a seguinte situao. No desenvolvimento de um sistema para uma biblioteca, o
usurio coloca o seguinte requisito no funcional: O sistema deve ser amigvel ao usurio.
Esse requisito vago, ambguo e no passvel de ser expresso em nmeros. Como quantificar
se o sistema amigvel ao usurio? Primeiro, preciso entender o que o usurio quer dizer
com amigvel ao usurio. Significa ser fcil de compreender? Fcil de aprender? Fcil de
operar? Atrativo? Clareando a inteno do usurio, possvel sugerir uma escala de medio.
Suponha que o usurio diga que ser amigvel ao usurio significa que os usurios sero
capazes de aprender rapidamente a usar o sistema. Uma vez definido que se est falando sobre
facilidade de aprender, possvel definir como escala de medio o tempo gasto para dominar
a execuo de certas tarefas. A partir disso, pode-se estabelecer como critrio de aceitao o
seguinte: Novos bibliotecrios devem ser capazes de efetuar emprstimos aps a quarta
tentativa de realizar essa tarefa usando o sistema.
Determinar critrios de ajuste (ou critrios de aceitao) ajuda a clarear um requisito.
Ao se estabelecer uma escala de medio e os valores aceitveis, o requisito transformado
de uma inteno vaga, e at certo ponto ambgua, em um requisito mensurvel e bem
formado. Estabelecida uma escala, pode-se perguntar ao usurio o que ele considera uma
falha em atender ao requisito, de modo a definir o critrio de aceitao. Contudo, pode ser
difcil, seno impossvel, obter um requisito completo e mensurvel em primeira instncia
(ROBERTSON; ROBERTSON, 2006). Assim, na descrio de requisitos de usurio pode ser
suficiente capturar a inteno e depois, na especificao de requisitos de sistema, transformar
essa inteno em um requisito mensurvel, adicionando a ele um critrio de ajuste. muito
comum que, neste processo, um requisito no funcional de usurio d origem a vrios
requisitos no funcionais de sistema.
Em (KOTONYA; SOMMERVILLE, 1998), o Captulo 3 Requirements Elicitation
and Analysis trata do processo de levantamento de requisitos, discutindo tambm, de forma
breve, algumas tcnicas de levantamento de requisitos, dentre elas entrevistas, cenrios,
observao, reutilizao de requisitos e prototipagem.
Em (WIEGERS, 2003) h vrios captulos que abordam temas discutidos nestas notas
de aula. Sugere-se, em especial, a leitura dos captulos 5, 6, 7, 9, 10, 12 e 13. O Captulo 5
Establishing the Product Vision and Project Scope discute a estrutura de um documento de

67
escopo e viso, que documenta preliminarmente os requisitos, de maneira anloga ao

documento de requisitos discutido neste texto. O Captulo 6 Finding the Voice of the
Customer discute, dentre outros, fontes de requisitos, classes de usurios e seus
representantes. O Captulo 7 Hearing the Voice of the Customer discute a tcnica de
workshop de requisitos e a classificao das informaes obtidas de clientes e usurios. O
Captulo 9 Playing by the Rules trata de regras de negcio, seus tipos e como documentlas. O Captulo 10 Documenting the Requirements discute a estrutura de um documento de
especificao de requisitos, que detalha os requisitos, de maneira anloga ao documento de
especificao de requisitos discutido neste texto. Alm disso, este captulo discute como
rotular e escrever requisitos. O Captulo 12 Beyound Functionality: Software Quality
Attributes discute a parte dos requisitos no funcionais relacionadas a atributos de qualidade
de produto de software. Finalmente, o Captulo 13 Risk Reduction Through Prototyping
dedicado prototipagem.
Em (ROBERTSON; ROBERTSON, 2006) h tambm vrios captulos que abordam
temas discutidos nestas notas de aula. Sugere-se, em especial, a leitura dos captulos 5, 7, 8, 9,
10 e 12. O Captulo 5 Trawling the Requirements aborda a coleta de requisitos, discutindo
diversas tcnicas de levantamento de requisitos, dentre elas entrevistas, workshops de
requisitos, brainstorming e investigao de documentos. O Captulo 7 Functional
Requirements aborda a captura e descrio de requisitos funcionais, enquanto o Captulo 8
Nonfunctional Requirements aborda requisitos no funcionais. O Captulo 9 Fit Criteria
trata da definio de critrios de ajuste para complementar a descrio de requisitos,
tornando-os mensurveis e testveis. O Captulo 10 Writing the Requirements discute a
documentao de requisitos, tomando por base o modelo de documento de especificao de
requisitos Volere, proposto pelos autores. Finalmente, o Captulo 12 Prototyping the
Requirements dedicado prototipagem.
O Captulo 2 de (AURUM; WOHLIN, 2005) Requirements Elicitation: A Survey of
Techniques, Approaches and Tools, mais especificamente sua seo 2.3 (Techniques and
Approaches for Requirements Elicitation) faz um timo apanhado sobre tcnicas de
levantamento de requisitos. Vrios dos comentrios feitos neste texto foram baseados nas
descries feitas por Zowghi e Coulin, autores dessa seo de (AURUM; WOHLIN, 2005).
Uma das principais fontes para as descries feitas neste texto sobre as tcnicas de
entrevistas, questionrios, observao e investigao de documentos foi a parte II de
(KENDALL; KENDALL, 2010) Information Requirements Analysis, a qual contm trs
captulos bastante usados nestas notas de aula, a saber: Captulo 4 Information Gathering:
Interactive Methods, que trata, dentre outros, de entrevistas e questionrios; Captulo 5
Information Gathering: Unobtrusive Methods, que aborda investigao de documentos e
observao; e Captulo 6 Agile Modeling and Prototyping, que discute prototipagem.
Outra fonte importante sobre tcnicas de levantamento de requisitos a parte II de
(ALEXANDER; BEUS-DUKIC, 2009) Discovery Contexts. Esta parte contm quatro
captulos, sendo trs deles relacionados a aspectos discutidos neste texto, a saber: Captulo 11
Requirements from Individuals, que trata de entrevistas e observao; Captulo 12
Requirements from Groups, que aborda workshops de requisitos; e Captulo 13
Requirements from Things, que discute prototipagem e reutilizao de requisitos.
Em (SOMMERVILLE, 2007), o Captulo 6 Requisitos de Software trata de tipos e
nveis de requisitos, bem como da documentao de requisitos. No Captulo 7 Processos de
Engenharia de Requisitos, a seo 7.2 dedicada ao levantamento e anlise de requisitos.

68
Nesta seo so brevemente discutidas algumas tcnicas de levantamento de requisitos, dentre

elas entrevistas, cenrios e etnografia.
Em (PFLEEGER, 2004), a seo 4.7, que trata da documentao de requisitos, merece
destaque. Em (PRESSMAN, 2006), merecem destaque as sees 7.3 (Incio do Processo de
Engenharia de Requisitos) e 7.4 (Levantamento de Requisitos).
Por fim, no que se refere modelagem de processos de negcio e sua sinergia com a
engenharia de requisitos, em (CARVALHO, 2009) e (CARDOSO, 2007) h timas
discusses. Em especial, o Captulo 5 de (CARVALHO, 2009) Apresentao de Algumas
Abordagens de Identificao de Requisitos de Sistemas a partir dos Processos de Negcio
apresenta diversas abordagens que fazem uso da modelagem de processos de negcio para
apoiar o levantamento de requisitos. Uma viso resumida, mas muito boa, do trabalho de
Cardoso (2007) apresentada em (CARDOSO; ALMEIDA; GUIZZARDI, 2008).
BASS, L., CLEMENTS, P., KAZMAN, R., Software Architecture in Practice, Second
edition, Addison Wesley, 2003.
CARDOSO, E.C.S., Uma Comparao entre Requisitos de Sistema Gerados por Tcnicas de
Modelagem de Processos com Requisitos de Sistema Gerados por Tcnicas
Convencionais de Engenharia de Requisitos, Projeto de Graduao (Engenharia de
Computao), Universidade Federal do Esprito Santo, 2007.
CARDOSO, E., ALMEIDA, J.P.A., GUIZZARDI, G., Uma Experincia com Engenharia de
Requisitos baseada em Modelos de Processos. In: Proceedings of the XI Iberoamerican
Workshop on Requirements Engineering and Software Environments (IDEAS 2008),
Recife, 2008.
CARVALHO, E.A., Engenharia de Processos de Negcio e a Engenharia de Requisitos:
Anlise e Comparaes de Abordagens e Mtodos de Elicitao de Requisitos de Sistemas
Orientada por Processos de Negcio, Dissertao de Mestrado, Programa de PsGraduao em Engenharia de Produo, COPPE/UFRJ, Rio de Janeiro, 2009.
DAVENPORT, T. H., Mission Critical: realizing the promise of enterprise systems. 1st
edition. Boston: Harvard Business School Press, 2000.
FRYE, D. W., GULLEDGE, T. R., End-to-end Business Process Scenarios. Industrial,
Management & Data Systems, v. 107, n. 6, pp.749761, 2007.
ISO/IEC 9126-1, Software Engineering - Product Quality - Part 1: Quality Model, 2001.
ISO/IEC TR 9126-2:2003, Software Engineering Product Quality Part 2: External
Metrics, 2003a.
ISO/IEC TR 9126-3:2003, Software Engineering Product Quality Part 3: Internal Metrics,
2003b.
KENDALL, K.E., KENDALL, J.E.; Systems Analysis and Design, Prentice Hall, 8th Edition,
2010.

69
KNIGHT, D. M. Elicitao de Requisitos de Software a partir do Modelo de Negcio.

Dissertao (Mestrado em Informtica). Ncleo de Computao Eletrnica (NCE),
Universidade Federal do Rio de Janeiro. Rio de Janeiro, 2004
KOTONYA, G., SOMMERVILLE, I., Requirements engineering: processes and techniques.
Chichester, England: John Wiley, 1998.
PFLEEGER, S.L., Engenharia de Software: Teoria e Prtica, So Paulo: Prentice Hall, 2
edio, 2004.
PRESSMAN, R.S., Engenharia de Software, McGraw-Hill, 6 edio, 2006.
SOMMERVILLE, I., Engenharia de Software, 8 Edio. So Paulo: Pearson Addison
Wesley, 2007.
WAZLAWICK, R.S., Anlise e Projeto de Sistemas de Informao Orientados a Objetos,
Elsevier, 2004.
WIEGERS, K.E., Software Requirements: Practical techniques for gathering and managing
requirements throughout the product development cycle. 2nd Edition, Microsoft Press,
Redmond, Washington, 2003.

70

Requisitos de usurio resultam diretamente da atividade de levantamento de requisitos,
sendo tipicamente descritos em linguagem natural, em um nvel pequeno de detalhes. Assim,
uma vez identificados os requisitos de usurio, necessrio detalh-los, colocando-os no nvel
de descrio de requisitos de sistema. Este o propsito da anlise de requisitos. Requisitos
de sistema resultam dos esforos dos analistas de organizar e detalhar requisitos de usurio,
envolvendo a elaborao de um conjunto de modelos abstratos do sistema, agora em um nvel
alto de detalhes. A correta derivao de requisitos de sistema a partir de requisitos de usurio
fundamental para assegurar que nenhum equvoco arbitrariamente introduzido pelos
analistas durante o processo de especificao de requisitos (AURUM; WOHLIN, 2005).
Durante a anlise de requisitos, requisitos funcionais e no funcionais devem ser expressos
em um nvel de detalhes que permita guiar as etapas subsequentes do desenvolvimento de
software (projeto, implementao e testes). Alm disso, ateno especial deve ser dada s
regras de negcio. Elas tm de ser capturadas e incorporadas s funcionalidades do sistema.
Para descrever requisitos funcionais detalhadamente, na maioria das vezes necessrio
produzir um conjunto de modelos, cada um deles capturando uma perspectiva diferente do
sistema. A linguagem natural ainda utilizada, mas em uma escala reduzida, circunscrita a
descries de certos modelos ou s definies em glossrios ou dicionrios de dados. Grande
parte das informaes tratadas na anlise de requisitos funcionais melhor comunicada por
meio de diagramas do que por meio de texto. Assim, a modelagem conceitual uma atividade
essencial da anlise de requisitos.
A modelagem conceitual visa definir em detalhes as funes requeridas pelo sistema e
o conhecimento necessrio para realiz-las. O produto principal da modelagem conceitual o
esquema conceitual do sistema (OLIV, 2007). O esquema ou modelo conceitual2 de um
sistema captura as funes e informaes que o sistema deve prover e gerenciar. Ele deve ser
concebido com foco no domnio do problema e no no domnio da soluo, mas deve tratar
tanto uma viso externa do sistema (como o sistema percebido pelos usurios) quanto uma
viso interna do mesmo (como as abstraes do domnio so representadas e relacionadas).
Os termos anlise de sistemas e anlise de requisitos so muitas vezes empregados
para designar as atividades de modelagem conceitual (anlise de requisitos funcionais).
Assim, a maioria dos mtodos de anlise de sistemas concentra-se na anlise de requisitos
funcionais, nada falando sobre a anlise de requisitos no funcionais. Entretanto, durante a
Oliv (2007) utiliza o termo esquema conceitual para designar o conjunto de artefatos que capturam o
conhecimento que um sistema de informao necessita para realizar suas funes. Contudo, a maioria dos textos,
tais como (WAZLAWICK, 2004) e (BLAHA; RUMBAUGH, 2006), utiliza o termo modelo conceitual para
designar esse conjunto de artefatos. Oliv utiliza o termo modelo conceitual para designar tipos de modelos,
tais como modelos de objetos, modelos de casos de uso etc. Nestas notas de aula, o termo modelo conceitual
usado como na maioria dos textos, no sendo feita uma distino precisa entre as duas acepes do termo. De
maneira geral, o contexto indica ao que se refere o termo.

71
atividade de anlise de requisitos, tanto requisitos funcionais quanto requisitos no funcionais

devem ser especificados em detalhes.
O produto de trabalho principal da anlise de requisitos o Documento de
Especificao de Requisitos. Esse documento deve conter os requisitos funcionais e no
funcionais descritos em nvel de requisitos de sistema. Conforme citado anteriormente, os
requisitos funcionais de sistema so descritos por um conjunto de modelos interrelacionados.
Os requisitos no funcionais de sistema detalham os requisitos no funcionais de usurio,
adicionando a eles critrios de aceitao.
importante apontar que h uma forte dependncia entre os mtodos e tcnicas usados
na modelagem conceitual e o paradigma de desenvolvimento adotado. Isso ocorre porque um
modelo uma representao do sistema segundo um particular metamodelo. Esse
metamodelo corresponde ao conjunto de elementos de modelagem (estruturais e
comportamentais) e regras de uso desses elementos, o qual permite construir modelos
segundo o respectivo paradigma (AURUM; WOHLIN, 2005). Assim, para a modelagem
conceitual de requisitos funcionais necessrio escolher um paradigma de desenvolvimento
(e o correspondente metamodelo subjacente a ele) a partir do qual os modelos sero
construdos. O paradigma orientado a objetos, por exemplo, fornece um conjunto de
elementos de modelagem que permite modelar um sistema como sendo composto de objetos
organizados em classes que se comunicam entre si por meio de troca de mensagens. Uma
classe define as propriedades (atributos, relacionamentos e operaes) que todos os objetos
dela podem possuir. Assim, classes, objetos, associaes, atributos e operaes, dentre outros,
so elementos do metamodelo subjacente ao paradigma orientado a objetos. Neste texto, o
paradigma adotado o da orientao a objetos.
Uma vez que a modelagem conceitual uma tarefa essencial e complexa, til seguir
um mtodo. Um mtodo pode ser visto como uma maneira sistemtica de trabalhar para se
obter um resultado desejado (PASTOR; MOLINA, 2007). H diversos mtodos de anlise
orientada a objetos propostos na literatura, dentre eles os apresentados em (LARMAN, 2007),
(WAZLAWICK, 2004)3, (BLAHA; RUMBAUGH, 2006) e (PASTOR; MOLINA, 2007).
Vale ressaltar que no h um mtodo reconhecido como um mtodo padro para o
desenvolvimento de software orientado a objetos. Diferentes projetos podem requerer
diferentes processos e, portanto, no h como definir um mtodo adequado a quaisquer
situaes. Neste captulo apresentado um mtodo que incorpora ideias de vrios mtodos, o
qual tem se mostrado eficaz na prtica, sobretudo, no desenvolvimento de sistemas de
informao.
Este captulo trata da anlise de requisitos, discutindo a anlise de requisitos
funcionais (modelagem conceitual) e no funcionais. A Seo 4.1 discute a modelagem
conceitual com foco em sistemas de informao e os tipos de modelos comumente utilizados
no desenvolvimento de software orientado a objetos. A Seo 4.2 apresenta a Linguagem de
Modelagem Unificada (Unified Modeling Language UML), amplamente usada na
modelagem conceitual. A Seo 4.3 discute os principais conceitos da orientao a objetos,
paradigma de desenvolvimento adotado neste texto. A Seo 4.4 apresenta o mtodo de
anlise de requisitos funcionais sugerido, indicando suas atividades e modelos a serem
produzidos. A Seo 4.5 trata da especificao de requisitos no funcionais. Finalmente, a
Seo 4.6 discute a documentao de requisitos em nvel de sistema.
3
O mtodo apresentado em (WAZLAWICK, 2004) , segundo o prprio autor, uma interpretao e um

detalhamento do mtodo de anlise e projeto apresentado por Larman.

72
4.1 Modelagem Conceitual

Todo sistema incorpora um esquema conceitual. Assim, para que o desenvolvimento
de um sistema seja bem sucedido, necessrio explicitar esse esquema. Esse o propsito da
modelagem conceitual (OLIV, 2007).
O esquema conceitual de um sistema de informao a especificao de seus
requisitos funcionais. Um sistema de informao um sistema projetado para coletar,
armazenar, processar e distribuir informao sobre o estado de um domnio. Assim, um
sistema dessa natureza tem tipicamente trs propsitos ou funes principais (OLIV, 2007):
Funo de Memria: sob esta tica, o objetivo de um sistema de informao

manter uma representao interna do estado do domnio. O estado do domnio
geralmente alterado com frequncia e de muitas maneiras. O sistema precisa
acompanhar essas alteraes e atualizar sua representao interna adequadamente.
Funo Informativa: o sistema deve prover aos usurios informaes sobre o

estado do domnio. A funo informativa no altera o estado do domnio; ela
apenas prov a informao solicitada pelos usurios.
Funo Ativa: o sistema pode realizar aes que modificam o estado do domnio.
Para realizar essa funo, o sistema precisa conhecer as aes que ele pode tomar,
quando elas devem ser tomadas e como elas vo afetar o estado do domnio.
Todos os sistemas de informao convencionais realizam, pelo menos, as funes de

memria e informativa. Para ser capaz de realizar suas funes, um sistema tem de ter um
conhecimento geral sobre o domnio da aplicao e sobre as funcionalidades que ele deve
executar. Na rea de sistemas de informao, esse conhecimento denominado de esquema
conceitual (OLIV, 2007).
O modelo conceitual de um sistema tipicamente composto de vrios modelos, cada
um deles enfocando uma perspectiva diferente, mas guardando alguma relao com outros
modelos. Os diferentes tipos de modelos conceituais podem ser agrupados em duas grandes
categorias:
Modelos Estruturais: procuram capturar os principais conceitos do domnio, suas

relaes e propriedades, que so relevantes para o sistema que se est
desenvolvendo. Abstrao um mecanismo chave e a definio do que relevante
definido com base no propsito do sistema. Dentre os tipos de modelos
estruturais, destacam-se o Modelo de Entidades e Relacionamentos e o Diagrama
de Classes na Orientao a Objetos.
Modelos Comportamentais: especificam as aes que o sistema pode realizar e as

mudanas vlidas no estado do domnio (OLIV, 2007). Tipos de modelos
comportamentais bastante utilizados no desenvolvimento orientado a objetos
incluem Modelos de Casos de Uso e Modelos Dinmicos, tais como Diagramas de
Transio de Estados e Diagramas de Interao.

73
4.2 A Linguagem de Modelagem Unificada

A Linguagem de Modelagem Unificada (Unified Modeling Language UML) uma
linguagem grfica padro para especificar, visualizar, documentar e construir artefatos de
sistemas de software (BOOCH; RUMBAUGH; JACOBSON, 2006).
A UML foi criada na dcada de 1990, a partir de uma tentativa de se unificar dois dos
principais mtodos orientados a objetos utilizados at ento: a Tcnica de Modelagem de
Objetos (Object Modeling Technique OMT) (RUMBAUGH et al., 1994) e o Mtodo de
Booch (BOOCH, 1994). Inicialmente, buscava-se criar um mtodo unificado. A este esforo
juntou-se tambm Ivar Jacobson, fundindo tambm seu mtodo OOSE (JACOBSON, 1992).
Contudo, percebeu-se que no era possvel estabelecer um nico mtodo adequado para todo
e qualquer desenvolvimento. De fato, um mtodo composto por uma linguagem
estabelecendo a notao a ser usada na elaborao dos artefatos a serem produzidos e de um
processo descrevendo que artefatos construir e como constru-los. A linguagem pode ser
unificada, mas a deciso de quais artefatos produzir e que passos seguir no passvel de
padronizao, j que pode variar at mesmo de projeto para projeto. Assim, ao invs de
criarem um mtodo unificado, Rumbaugh, Booch e Jacobson propuseram a UML,
incorporando as principais notaes para os produtos de seus mtodos e de vrios outros, com
a colaborao de vrias empresas e autores. A UML foi aprovada em novembro de 1997 pelo
OMG Object Management Group pondo fim a uma guerra de mtodos orientados a
objeto. Sua verso mais recente, a UML 2.0, foi adotada no incio de 2005 e resultado de um
esforo de diversos colaboradores, envolvendo empresas e pesquisadores sob a coordenao
de uma fora tarefa do OMG.
Vale realar que a UML somente uma linguagem e, portanto, apenas parte de um
mtodo de desenvolvimento de software. Ela independente do processo de software a ser
usado, ainda que seja mais adequada a processos de desenvolvimento orientados a objetos.
Ela se destina a visualizar, especificar, construir e documentar artefatos de software
(BOOCH; RUMBAUGH; JACOBSON, 2006). No contexto da Engenharia de Requisitos, a
UML prov diversos diagramas que podem ser usados na modelagem de requisitos, tanto
segundo a perspectiva estrutural quanto segundo a perspectiva comportamental. Para a
modelagem conceitual estrutural, os diagramas de classes so amplamente utilizados. Para a
modelagem comportamental, podem ser usados diagramas de casos de uso, de interao, de
estados e de atividades. A seguir, apresentada uma descrio sucinta de cada um desses
diagramas, baseada em (BOOCH; RUMBAUGH; JACOBSON, 2006):
Diagramas de Classes: Um diagrama de classes exibe um conjunto de classes e

seus relacionamentos. Diagramas de classes proveem uma viso esttica da
estrutura de um sistema e, portanto, so usados na modelagem conceitual
estrutural.
Diagramas de Casos de Uso: Um diagrama de casos de uso mostra um conjunto de

casos de uso e atores e seus relacionamentos. Os casos de uso descrevem a
funcionalidade do sistema percebida pelos atores externos. Um ator interage com o
sistema, podendo ser um usurio humano, dispositivo de hardware ou outro
sistema. Diagramas de casos de uso proveem uma viso das funcionalidades do
sistema, sendo importantes para a organiz-las e model-las.
Diagramas de Grfico de Estados (ou simplesmente Diagramas de Estados):

mostram os estados pelos quais um objeto pode passar ao longo de sua vida, em

74
resposta a estmulos recebidos, juntamente com suas aes. Os diagramas de

estados proveem uma viso dinmica de um objeto, sendo importantes para
modelar o comportamento dos objetos de uma classe em resposta ocorrncia de
eventos.
Diagramas de Atividades: mostram a estrutura de um processo. Proveem uma

viso dinmica do sistema (ou de uma poro do sistema) e podem ser usados
tanto para modelar processos de negcio quanto para modelar funes do sistema.
Um diagrama de atividades d nfase ao fluxo de controle entre objetos.
Diagramas de Interao: Um diagrama de interao mostra um conjunto de objetos

ou papis interagindo, incluindo as mensagens que podem ser trocadas entre eles.
Diagramas de interao proveem uma viso dinmica do comportamento de um
sistema ou de uma poro do sistema. H dois tipos de diagramas de interao:
o Diagramas de Sequncia: so um tipo de diagrama de interao cuja nfase
est na ordenao temporal das mensagens.
o Diagramas de Comunicao: tm o mesmo propsito dos diagramas de
sequncia, apresentando, contudo, nfase diferente. A nfase dos diagramas de
comunicao est na organizao estrutural dos objetos que enviam ou
recebem mensagens.
No contexto da Engenharia de Requisitos, alm dos diagramas anteriormente citados,

merecem ateno tambm os diagramas de pacotes. Na UML, pacote um mecanismo de
propsito geral usado para organizar elementos de modelagem em grupos. Assim, um
diagrama de pacotes mostra a decomposio de um modelo em unidades menores e suas
dependncias (BOOCH; RUMBAUGH; JACOBSON, 2006).
Vale ressaltar mais uma vez, que a UML uma linguagem de modelagem, no um
mtodo de desenvolvimento OO. Os mtodos consistem, pelo menos em princpio, de uma
linguagem de modelagem e um procedimento de uso dessa linguagem. A UML no prescreve
explicitamente esse procedimento de utilizao. Assim, a UML deve ser aplicada no contexto
de um processo, lembrando que domnios de problemas e projetos diferentes podem requerer
processos diferentes.
4.3 O Paradigma Orientado a Objetos

Para conduzir o processo de engenharia de requisitos, sobretudo a modelagem
conceitual estrutural, necessrio adotar um paradigma de desenvolvimento. Um dos
paradigmas mais adotados atualmente a orientao a objetos (OO). Segundo esse
paradigma, o mundo visto como sendo composto por objetos, onde um objeto uma
entidade que combina estrutura de dados e comportamento funcional. No paradigma OO, os
sistemas so modelados como objetos que interagem.
A orientao a objetos oferece um nmero de conceitos bastante apropriados para a
modelagem de sistemas. Os modelos baseados em objetos so teis para a compreenso de
problemas, para a comunicao com os especialistas e usurios das aplicaes, e para a
realizao das tarefas ao longo do processo de desenvolvimento de software. O paradigma
OO utiliza uma perspectiva humana de observao da realidade, incluindo objetos,
classificao e compreenso hierrquica.

75
Para fazer bom uso do paradigma OO, importante conhecer os princpios adotados
por ele na administrao da complexidade, bem como seus principais conceitos.
4.3.1 Princpios para Administrao da Complexidade
O mundo real algo extremamente complexo. Quanto mais de perto o observamos,
mais claramente percebemos sua complexidade. A orientao a objetos tenta gerenciar a
complexidade inerente dos problemas do mundo real, abstraindo conhecimento relevante e
encapsulando-o dentro de objetos. De fato, alguns princpios bsicos gerais para a
administrao da complexidade norteiam o paradigma orientado a objetos, entre eles
abstrao, encapsulamento e modularidade.
Abstrao
Uma das principais formas do ser humano lidar com a complexidade atravs do uso
de abstraes. As pessoas tipicamente tentam compreender o mundo, construindo modelos
mentais de partes dele. Tais modelos so uma viso simplificada de algo, onde apenas os
elementos relevantes so considerados. Modelos, portanto, so mais simples do que os
complexos sistemas que eles modelam.
Seja o exemplo de um mapa representando um modelo de um territrio. Um mapa
til porque abstrai apenas as caractersticas do territrio que se deseja modelar. Se um mapa
inclusse todos os detalhes do territrio, provavelmente teria o mesmo tamanho do territrio e,
portanto, no serviria a seu propsito.
Da mesma forma que um mapa precisa ser significativamente menor que o territrio
que ele mapeia, incluindo apenas as informaes selecionadas, um modelo deve abstrair
apenas as caractersticas relevantes de um sistema para seu entendimento. Assim, pode-se
definir abstrao como sendo o princpio de ignorar aspectos no relevantes de um assunto,
segundo a perspectiva de um observador, tornando possvel uma concentrao maior nos
aspectos principais do mesmo. De fato, a abstrao consiste na seleo que um observador faz
de alguns aspectos de um assunto, em detrimento de outros que no demonstram ser
relevantes para o propsito em questo. A Figura 2.4 ilustra o conceito de abstrao.
Mapa Rodovirio
So Paulo
Mapa de Temperaturas
Figura 2.4 Ilustrao do Conceito de Abstrao.

76
Encapsulamento
No mundo real, um objeto pode interagir com outro sem conhecer seu funcionamento
interno. Uma pessoa, por exemplo, utiliza um forno de microondas sem saber efetivamente
qual a sua estrutura interna ou como seus mecanismos internos so ativados. Para utiliz-lo,
basta saber usar seu painel de controle (a interface do aparelho) para realizar as operaes de
ligar/desligar, informar o tempo de cozimento etc. Como essas operaes produzem os
resultados, no interessa ao cozinheiro. A Figura 2.5 ilustra o conceito de encapsulamento.
Estrutura Interna
Interface
Figura 2.5 Ilustrao do Conceito de Encapsulamento.

O encapsulamento consiste na separao dos aspectos externos de um objeto,
acessveis por outros objetos, de seus detalhes internos de implementao, que ficam ocultos
dos demais objetos (BLAHA; RUMBAUGH, 2006). A interface de um objeto deve ser
definida de forma a revelar o menos possvel sobre o seu funcionamento interno.
Abstrao e encapsulamento so conceitos complementares: enquanto a abstrao
enfoca o comportamento observvel de um objeto, o encapsulamento oculta a implementao
que origina esse comportamento. Encapsulamento frequentemente conseguido atravs da
ocultao de informao, isto , escondendo detalhes que no contribuem para suas
caractersticas essenciais. Tipicamente, em um sistema orientado a objetos, a estrutura de um
objeto e a implementao de seus mtodos so encapsuladas (BOOCH, 1994). Assim, o
encapsulamento serve para separar a interface contratual de uma abstrao e sua
implementao. Os usurios tm conhecimento apenas das operaes que podem ser
requisitadas e precisam estar cientes apenas do qu as operaes realizam e no como elas
esto implementadas.
A principal motivao para o encapsulamento garantir estabilidade aos sistemas. Um
encapsulamento bem feito pode servir de base para a localizao de decises de projeto que
necessitam ser alteradas. Uma operao pode ter sido implementada de maneira ineficiente e,
portanto, pode ser necessrio escolher um novo algoritmo. Se a operao est encapsulada,
apenas o objeto que a define precisa ser modificado, garantindo estabilidade ao sistema.
Modularidade
Os mtodos de desenvolvimento de software buscam obter sistemas modulares, isto ,
construdos a partir de elementos que sejam autnomos e conectados por uma estrutura
simples e coerente. Modularidade visa obteno de sistemas decompostos em um conjunto

77
de mdulos coesos e fracamente acoplados e crucial para se obter sistemas fceis de manter
e estender.
Abstrao, encapsulamento e modularidade so princpios sinergticos, isto , ao se
trabalhar bem com um deles, est-se aperfeioando os outros tambm.
4.3.2 Principais Conceitos da Orientao a Objetos
De maneira simples, o paradigma OO traz uma viso de mundo em que os fenmenos
e domnios so vistos como colees de objetos interagindo entre si. Essa forma simples de se
colocar a viso do paradigma OO esconde conceitos importantes da orientao a objetos que
so a base para o desenvolvimento OO, tais como classes, associaes, generalizao etc. A
seguir os principais conceitos da orientao a objetos so discutidos.
Objetos
O mundo real povoado por entidades que interagem entre si, onde cada uma delas
desempenha um papel especfico. Na orientao a objetos, essas entidades so ditas objetos.
Objetos podem ser coisas concretas ou abstratas, tais como um carro, uma reserva de
passagem area, uma organizao etc.
Do ponto de vista da modelagem de sistemas, um objeto uma entidade que incorpora
uma abstrao relevante no contexto de uma aplicao. Um objeto possui um estado
(informao), exibe um comportamento bem definido (dado por um nmero de operaes
para examinar ou alterar seu estado) e tem identidade nica. O estado de um objeto
compreende o conjunto de suas propriedades, associadas a seus valores correntes.
Propriedades de objetos so geralmente referenciadas como atributos e associaes. Portanto,
o estado de um objeto diz respeito aos seus atributos/associaes e aos valores a eles
associados. Operaes so usadas para recuperar ou manipular a informao de estado de um
objeto e se referem apenas s estruturas de dados do prprio objeto, no devendo acessar
diretamente estruturas de outros objetos. Caso a informao necessria para a realizao de
uma operao no esteja disponvel, o objeto ter de colaborar com outros objetos.
A comunicao entre objetos d-se por meio de troca de mensagens. Para requisitar
uma operao de um objeto, necessrio enviar uma mensagem para ele. Uma mensagem
composta do nome da operao sendo requisitada e dos argumentos requeridos. Assim, o
comportamento de um objeto representa como esse objeto reage s mensagens a ele enviadas.
Em outras palavras, o conjunto de mensagens a que um objeto pode responder representa o
seu comportamento. Um objeto , pois, uma entidade que tem seu estado representado por um
conjunto de atributos e associaes (uma estrutura de informao) e seu comportamento
representado por um conjunto de operaes.
Cada objeto tem uma identidade prpria que lhe inerente. Todos os objetos tm
existncia prpria, ou seja, dois objetos so distintos, mesmo se seus estados e
comportamentos forem iguais. A identidade de um objeto transcende os valores correntes de
suas propriedades.
Classes
No mundo real, diferentes objetos desempenham um mesmo papel. Seja o caso de
duas cadeiras iguais. Apesar de serem objetos diferentes, elas compartilham uma mesma
estrutura e um mesmo comportamento. Entretanto, no h necessidade de se despender tempo

78
modelando cada cadeira. Basta definir, em um nico lugar, um modelo descrevendo a

estrutura e o comportamento desses objetos. A esse modelo d-se o nome de classe. Uma
classe descreve um conjunto de objetos com a mesma estrutura (atributos e associaes), o
mesmo comportamento (operaes) e a mesma semntica. Objetos que se comportam da
maneira especificada pela classe so ditos instncias dessa classe.
Todo objeto pertence a uma classe, ou seja, instncia de uma classe. De fato, a
orientao a objetos norteia o processo de desenvolvimento atravs da classificao de
objetos, isto , objetos so agrupados em classes, em funo de exibirem caractersticas
similares, sem, no entanto, perda de sua individualidade, como ilustra a Figura 2.6. Assim, a
modelagem orientada a objetos consiste, basicamente, na definio de classes. O
comportamento e a estrutura de informao de uma instncia so definidos pela sua classe.
Objetos com propriedades e comportamento idnticos so descritos como instncias de
uma mesma classe, de modo que a descrio de suas propriedades possa ser feita uma nica
vez, de forma concisa, independentemente do nmero de objetos que tenham tais
propriedades em comum. Deste modo, uma classe captura as caractersticas comuns a todas as
suas instncias.
Enquanto um objeto individual uma entidade real, que executa algum papel no
sistema como um todo, uma classe captura a estrutura e o comportamento comuns a todos os
objetos que ela descreve. Assim, uma classe serve como uma espcie de contrato que deve ser
estabelecido entre uma abstrao e todos os seus clientes.
Figura 2.6 Ilustrao do conceito de Classificao (BOOCH, 1994).

Ligaes e Associaes
Em qualquer sistema, objetos relacionam-se uns com os outros. Por exemplo, em o
empregado Joo trabalha no Departamento de Pessoal, temos um relacionamento entre o
objeto empregado Joo e o objeto Departamento de Pessoal.
Ligaes e associaes so meios de se representar relacionamentos entre objetos e
entre classes, respectivamente. Uma ligao uma conexo entre objetos. No exemplo
anterior, h uma ligao entre os objetos Joo e Departamento de Pessoal. Uma associao,
por sua vez, descreve um conjunto de ligaes com estrutura e semntica comuns. No
exemplo anterior, h uma associao entre as classes Empregado e Departamento. Todas as

79
ligaes de uma associao interligam objetos das mesmas classes e, assim, uma associao
descreve um conjunto de potenciais ligaes da mesma maneira que uma classe descreve um
conjunto de potenciais objetos (BLAHA; RUMBAUGH, 2006).
Uma associao comum entre duas classes representa um relacionamento estrutural
entre pares, significando que essas duas classes esto em um mesmo nvel, sem que uma seja
mais importante do que a outra. Alm das associaes comuns, a UML considera dois tipos
de associaes especiais entre objetos: composio e agregao. Ambos representam relaes
todo-parte. A agregao uma forma especial de associao que especifica um
relacionamento entre um objeto agregado (o todo) e seus componentes (as partes). A
composio, por sua vez, uma forma de agregao na qual o tempo de vida do todo e das
partes coincidente. As partes podem at ser criadas aps a criao do todo, mas uma vez
criadas, vivem e morrem com o todo. Uma parte pode ainda ser removida explicitamente
antes da morte do todo (BOOCH; RUMBAUGH; JACOBSON, 2006).
Generalizao / Especializao
Muitas vezes, um conceito geral pode ser especializado, adicionando-se a ele novas
caractersticas. Seja o exemplo do conceito de estudante no contexto de uma universidade. De
modo geral, h caractersticas que so intrnsecas a quaisquer estudantes da universidade.
Entretanto, possvel especializar esse conceito para mostrar especificidades de subtipos de
estudantes, tais como estudantes de graduao e estudantes de ps-graduao.
De maneira inversa, pode-se extrair de um conjunto de conceitos caractersticas
comuns que, quando generalizadas, formam um conceito geral. Por exemplo, ao se avaliar os
conceitos de carros, motos, caminhes e nibus, pode-se notar que eles tm caractersticas
comuns que podem ser generalizadas em um supertipo veculo automotor terrestre.
As abstraes de especializao e generalizao so muito teis para a estruturao de
sistemas. Com elas, possvel construir hierarquias de classes. A herana um mecanismo
para modelar similaridades entre classes, representando as abstraes de generalizao e
especializao. Atravs da herana, possvel tornar explcitos atributos, associaes e
operaes comuns em uma hierarquia de classes. O mecanismo de herana possibilita
reutilizao, captura explcita de caractersticas comuns e definio incremental de classes.
No que se refere definio incremental de classes, a herana permite conceber uma nova
classe como um refinamento de outras classes. A nova classe pode herdar as similaridades e
definir apenas as novas caractersticas.
A herana , portanto, um relacionamento entre classes (em contraposio s
associaes que representam relacionamentos entre objetos das classes), no qual uma classe
compartilha a estrutura e o comportamento definidos em outras (uma ou mais) classes. A
classe que herda caractersticas4 dita subclasse e a que fornece as caractersticas,
superclasse. Desta forma, a herana representa uma hierarquia de abstraes na qual uma
subclasse herda de uma ou mais superclasses.
Tipicamente, uma subclasse aumenta ou redefine caractersticas de suas superclasses.
Assim, se uma classe B herda de uma classe A, todas as caractersticas descritas em A tornamse automaticamente parte de B, que ainda livre para acrescentar novas caractersticas para
seus propsitos especficos.
4
O termo caracterstica usado aqui para designar estrutura (atributos e associaes) e comportamento
(operaes).

80
A generalizao permite abstrair, a partir de um conjunto de classes, uma classe mais

geral contendo todas as caractersticas comuns. A especializao a operao inversa e,
portanto, permite especializar uma classe em um nmero de subclasses, explicitando as
diferenas entre as novas subclasses. Deste modo possvel compor a hierarquia de classes.
Esses tipos de relacionamento so conhecidos tambm como relacionamentos um tipo de,
onde um objeto da subclasse tambm um tipo de objeto da superclasse. Neste caso, uma
instncia da subclasse dita uma instncia indireta da superclasse.
Quando uma subclasse herda caractersticas de uma nica superclasse, tem-se herana
simples. Quando uma classe definida a partir de duas ou mais superclasses, tem-se herana
mltipla. importante observar, no entanto, que na herana mltipla podem ocorrer dois
problemas: coliso de nomes herdados a partir de diferentes superclasses e a possibilidade de
herana repetida. A Figura 2.7 ilustra esses dois casos.
Classe A
x
Classe A
Classe B
y
x
w
y
x
Classe C
Classe B
w
z
Classe C
r
(a)
Classe D
r
(b)
Figura 2.7 - (a) Coliso de nomes. (b) Herana repetida.

No primeiro caso, a classe C herda das classes A e B. Entretanto ambas possuem uma
caracterstica com nome x. Assim, como ser a caracterstica x em C? Igual definida na
classe A ou igual da classe B?
No segundo caso, a classe D herda das classes B e C, que, por sua vez, herdam da
classe A. Assim, temos um caso de herana repetida, j que, indiretamente, a classe D herda
duas vezes da classe A.
Mensagens e Mtodos
A abstrao incorporada por um objeto caracterizada por um conjunto de operaes
que podem ser requisitadas por outros objetos, ditos clientes. Mtodos so implementaes
reais de operaes. Para que um objeto realize alguma tarefa, necessrio enviar uma
mensagem a ele, solicitando a execuo de um mtodo especfico. Um cliente s pode acessar
um objeto atravs da emisso de mensagens, isto , ele no pode acessar ou manipular
diretamente os dados associados ao objeto. Os objetos podem ser complexos e o cliente no
precisa tomar conhecimento de sua complexidade interna. O cliente precisa saber apenas
como se comunicar com o objeto e como ele reage. Assim, garante-se o encapsulamento.
As mensagens so o meio de comunicao entre objetos e so responsveis pela
ativao de todo e qualquer processamento. Dessa forma, possvel garantir que clientes no
sero afetados por alteraes nas implementaes de um objeto que no alterem o
comportamento esperado de seus servios.

81
Classes e Operaes Abstratas

Nem todas as classes so projetadas para instanciar objetos. Algumas so usadas
simplesmente para organizar caractersticas comuns a diversas classes. Tais classes so ditas
classes abstratas. Uma classe abstrata desenvolvida basicamente para ser herdada por outras
classes. Ela existe meramente para que um comportamento comum a um conjunto de classes
possa ser colocado em uma localizao comum e definido uma nica vez. Assim, uma classe
abstrata no possui instncias diretas, mas suas classes descendentes concretas, sim. Uma
classe concreta uma classe passvel de instanciao, isto , que pode ter instncias diretas.
Uma classe abstrata pode ter subclasses tambm abstratas, mas as classes-folhas na rvore de
herana devem ser classes concretas.
Classes abstratas podem ser projetadas de duas maneiras distintas. Primeiro, elas
podem prover implementaes completamente funcionais do comportamento que pretendem
capturar. Alternativamente, elas podem prover apenas a definio de um protocolo para uma
operao, sem apresentar um mtodo correspondente. Tal operao dita uma operao
genrica ou abstrata. Neste caso, a classe abstrata no completamente implementada e todas
as suas subclasses concretas so obrigadas a prover uma implementao para suas operaes
abstratas. Assim, diz-se que uma operao abstrata define apenas a assinatura5 a ser usada nas
implementaes que as subclasses devero prover, garantindo, assim, uma interface
consistente. Mtodos que implementam uma operao genrica tm a mesma semntica.
Uma classe concreta no pode conter operaes abstratas, porque seno seus objetos
teriam operaes indefinidas. Assim, toda classe que possuir uma operao genrica no pode
ter instncias diretas e, portanto, obrigatoriamente uma classe abstrata.
4.4 Um Mtodo de Anlise de Requisitos Funcionais

Uma vez que tipicamente diversos modelos do sistema so produzidos, surgem
algumas importantes questes: Que modelos produzir? Em que sequncia? Quais as relaes
existentes entre esses modelos? Estas questes podem ser parcialmente respondidas pela
adoo de um mtodo de anlise.
Um mtodo composto por uma linguagem estabelecendo a notao a ser usada na
elaborao dos artefatos a serem produzidos e de um processo descrevendo que artefatos
construir e como constru-los.
O mtodo sugerido neste texto adota a Linguagem de Modelagem Unificada (Unified
Modeling Language UML) (BOOCH; RUMBAUGH; JACOBSON, 2006) como linguagem
de modelagem e prescreve o processo ilustrado na Figura 4.1. Nessa figura, as atividades de
modelagem propriamente ditas esto destacadas em amarelo. As demais atividades
correspondem a atividades de documentao e verificao e validao do Documento de
Especificao de Requisitos.
nome da operao, parmetros e retorno

82
Figura 4.1 O Mtodo de Anlise de Requisitos Funcionais Proposto.

O primeiro modelo do sistema a ser construdo segundo a abordagem proposta o
modelo de casos de uso. Sua escolha como primeiro modelo a ser elaborado deve-se ao fato
do modelo de casos de uso ser passvel de compreenso tanto por desenvolvedores analistas,
projetistas, programadores e testadores como pela comunidade usuria clientes, usurios e
demais interessados.
O modelo de casos de uso um modelo comportamental, mostrando as funes do
sistema, mas de maneira esttica. Ele composto de dois tipos principais de artefatos: os
diagramas de casos de uso e as descries de casos de uso. Um diagrama de casos de uso
um diagrama bastante simples, que descreve o sistema, seu ambiente e como sistema e
ambiente esto relacionados. Assim, ele descreve o sistema segundo uma perspectiva externa.
As descries dos casos de uso descrevem o passo a passo para a realizao dos casos de uso
e so essencialmente textuais. A modelagem de casos de uso estudada em detalhes no
Captulo 5.
Tomando por base casos de uso e suas descries, possvel passar modelagem
conceitual estrutural, quando os conceitos e relacionamentos envolvidos no domnio so
capturados em um conjunto de diagramas de classes. Neste momento importante definir,
tambm, o significado dos conceitos e de suas propriedades, bem como restries sobre eles.
Essas definies so documentadas em um dicionrio de dados do projeto. A modelagem
conceitual estrutural o foco do Captulo 6.
Algumas classes do modelo estrutural apresentam um comportamento dependente de
seu estado. Para essas classes, til elaborar diagramas de estados, mostrando os estados
pelos quais um objeto da classe pode passar ao longo de sua existncia e os eventos que
provocam transies de um estado para outro. Alm disso, uma vez que os casos de uso foram
representados apenas de maneira esttica, pode ser til tambm mostrar a dinmica de um

83
caso de uso, representando como objetos do diagrama de classes interagem para realizar um
caso de uso. Os diagramas de interao so elaborados com este propsito. Finalmente, pode
ser til representar os passos de um caso de uso na forma de um diagrama, mostrando objetos
gerados e os atores envolvidos em cada passo. Para tal, diagramas de atividades podem ser
elaborados. A elaborao de diagramas de estados, de interao e de atividades o foco da
atividade de modelagem comportamental dinmica, a qual discutida com maiores detalhes
no Captulo 7.
Deve-se frisar que, apesar da Figura 4.1 sugerir que os passos do mtodo so
sequenciais, na prtica, isso no ocorre. Paralelamente modelagem de casos de uso, pode-se
iniciar a modelagem conceitual estrutural. Os diagramas de atividade podem tambm ser
elaborados em conjunto com a definio dos casos de uso, de maneira a complementar a
descrio de casos de uso especficos. Diagramas de estado e de interao requerem a
definio preliminar de casos de uso e classes. Contudo, podem ter sido definidos apenas
alguns casos de uso e classes (e no todos eles) para j iniciar a elaborao desses diagramas.
Assim, as atividades mostradas na Figura 4.1 so fortemente paralelas e iterativas.
Paralelamente a todas as atividades de modelagem, o documento de especificao de
requisitos deve ir sendo elaborado. Mesmo a verificao e a validao podem ser feitas por
partes e no para o documento como um todo. Por exemplo, bastante comum validar
primeiro somente os casos de uso. Verificaes de consistncia, tais como as feitas entre
casos de uso e classes, ou casos de uso, diagramas de interao e diagramas de classes, podem
ser feitas separadamente uma das outras. Assim, as atividades de documentao, verificao e
validao so atividades contnuas que ocorrem paralelamente modelagem conceitual.
4.5 Especificao de Requisitos No Funcionais

Assim como os requisitos funcionais precisam ser especificados em detalhes, o mesmo
acontece com os requisitos no funcionais. Para os atributos de qualidade considerados
prioritrios, o analista deve trabalhar no sentido de especific-los de modo que eles se tornem
mensurveis e, por conseguinte, testveis.
Para cada atributo de qualidade, devem-se definir as medidas a serem usadas,
indicando a unidade da medida e sua escala, e os valores mnimo, alvo e mximo. Pode-se,
ainda, perguntar aos usurios o que constituiria um valor inaceitvel para o atributo e definir
testes que tentem forar o sistema a demonstrar tais caractersticas (WIEGERS, 2003). Ao se
estabelecer uma escala de medio e os valores aceitveis, o requisito transformado de uma
inteno vaga, e at certo ponto ambgua, em um requisito mensurvel e bem formado.
Estabelecida uma escala, pode-se perguntar ao usurio o que considerado uma falha em
atender ao requisito, de modo a definir o critrio de aceitao do mesmo (ROBERTSON;
ROBERTSON, 2006). Assim, na especificao de requisitos de sistema, importante
transformar um requisito de usurio em um requisito mensurvel, adicionando a ele um
critrio de aceitao.
A ISO/IEC 9126 pode ser uma boa fonte de medidas. As partes 2 (Medidas Externas)
(ISO/IEC, 2003a) e 3 (Medidas Internas) (ISO/IEC, 2003b) dessa norma apresentam diversas
medidas que podem ser usadas para especificar objetivamente os requisitos no funcionais.
Nas partes 2 e 3 da norma, medidas so sugeridas para as diversas subcaractersticas de
qualidade externa e interna descritas na Parte 1, indicando, dentre outros, nome e propsito da
medida, mtodo de aplicao e frmula, e como interpretar os valores da medida.

84
Seja o exemplo de um sistema que tem como requisito no funcional ser fcil de
aprender. Esse requisito poderia ser especificado conforme mostrado na Tabela 4.1.
Tabela 4.1 Especificao de Requisito No Funcional.
RNF01 A funcionalidade Efetuar Locao de Item deve ser fcil de aprender.
Medida:
Facilidade de
Aprendizagem
de funo (Ease
of function
learn) (ISO/IEC,
2003a)
Critrio de
Aceitao:
Descrio:
Facilidade de aprender a realizar uma tarefa em uso.
Propsito:
Quanto tempo o usurio leva para aprender a realizar uma tarefa

especificada eficientemente?
Mtodo de
Aplicao:
Observar o comportamento do usurio desde quando ele comea a

aprender at quando ele comea a operar eficientemente.
Medio:
T = soma do tempo de operao do usurio at que ele consiga realizar

a tarefa em um tempo especificado (tempo requerido para aprender a
operao para realizar a tarefa).
T <= 15 minutos, considerando que o usurio est operando o sistema eficientemente

quando a tarefa Efetuar Locao realizada em um tempo inferior a 2 minutos.
4.6 O Documento de Especificao de Requisitos

Os requisitos de sistema, assim como foi o caso dos requisitos de usurio, tm de ser
especificados em um documento, de modo a poderem ser verificados e validados e
posteriormente usados como base para as atividades subsequentes do desenvolvimento de
software. O Documento de Especificao de Requisitos tem como propsito registrar os
requisitos escritos a partir da perspectiva do desenvolvedor e, portanto, deve incluir os vrios
modelos conceituais desenvolvidos, bem como a especificao dos requisitos no funcionais
detalhados.
Diferentes formatos podem ser propostos para documentos de especificao requisitos,
bem como mais de um documento pode ser usado para documentar os requisitos de sistema.
Neste texto, prope-se o uso de um nico documento, contendo as seguintes informaes:
1. Introduo: breve introduo ao documento, descrevendo seu propsito e estrutura.
2. Modelo de Casos de Uso: apresenta o modelo de casos de uso do sistema,
incluindo os diagramas de casos de uso e as descries de casos de uso associadas.
3. Modelo Estrutural: apresenta o modelo conceitual estrutural do sistema, incluindo
os diagramas de classes do sistema.
4. Modelo Dinmico: apresenta os modelos comportamentais dinmicos do sistema,
incluindo os diagramas de estados, diagramas de interao e diagramas de
atividades.
5. Dicionrio do Projeto: apresenta as definies dos principais conceitos capturados
pelos diversos modelos e restries de integridade a serem consideradas, servindo
como um glossrio do projeto.
6. Especificao dos Requisitos No Funcionais: apresenta os requisitos no
funcionais descritos no nvel de sistema, o que inclui critrios de aceitao.
importante frisar que dificilmente um sistema simples o bastante para ser
modelado como um todo. Quase sempre til dividir um sistema em unidades menores, mais

85
fceis de serem gerenciveis, ditas subsistemas. til organizar a especificao de requisitos

por subsistemas e, portanto, cada uma das sees propostas acima pode ser subdividida por
subsistemas.
Um modelo estrutural para uma aplicao complexa, por exemplo, pode ter centenas
de classes e, portanto, pode ser necessrio definir uma representao concisa capaz de orientar
um leitor em um modelo dessa natureza. O agrupamento de elementos de modelo em
subsistemas serve basicamente a este propsito, podendo ser til tambm para a organizao
de grupos de trabalho em projetos extensos. A base principal para a identificao de
subsistemas a complexidade do domnio do problema. Atravs da identificao e
agrupamento de elementos de modelo em subsistemas, possvel controlar a visibilidade do
leitor e, assim, tornar os modelos mais compreensveis.
A UML prov um tipo principal de item de agrupamento, denominado pacote, que
um mecanismo de propsito geral para a organizao de elementos da modelagem em grupos.
Um diagrama de pacotes mostra a decomposio de um modelo em unidades menores e suas
dependncias, como ilustra a Figura 4.4. A linha pontilhada direcionada indica que o pacote
origem (no exemplo, o pacote Atendimento a Cliente) depende do pacote destino (no
exemplo, o pacote Controle de Acervo).
Figura 4.4 Exemplo de um Diagrama de Pacotes

O Captulo 1 de (OLIV, 2007) Introduction d uma tima introduo
modelagem conceitual.
O Captulo 2 de (BLAHA; RUMBAUGH, 2006) Modelagem como uma Tcnica de
Projeto discute o que so modelos, seus papis e principais tipos de modelos. J o Captulo
1 Introduo apresenta uma boa introduo orientao a objetos e seus principais
conceitos.
Em (WIEGERS, 2003), os captulos 10 e 11 esto relacionados a temas discutidos
neste captulo. O Captulo 10 Documenting the Requirements discute a estrutura de um
documento de especificao de requisitos, enquanto o Captulo 11 A Picture is Worth 1024
Words discute a modelagem de requisitos, descrevendo diversos modelos que podem ser
empregados nesta tarefa.
De (ROBERTSON; ROBERTSON, 2006) sugere-se a leitura do Captulo 9 Fit
Criteria para a definio de critrios de aceitao para complementar a descrio de
requisitos, tornando-os mensurveis e testveis. Para apoiar a definio desses critrios,
recomenda-se utilizar as medidas definidas nas partes 2 e 3 da norma ISO/IEC 9126
(ISO/IEC, 2003a; ISO/IEC, 2003b).
Em (BASS; CLEMENTS; KAZMAN, 2003), o Captulo 4 Understanding Quality
Attributes discute atributos de qualidade de sistemas de software e como especificar
requisitos especficos desses atributos na forma de cenrios.

86
Por fim, o Captulo 2 de (BOOCH; RUMBAUGH; JACOBSON, 2006) Introduo

UML apresenta uma viso geral da UML, incluindo uma breve apresentao de seu
metamodelo, descrevendo seus itens estruturais, comportamentais, de agrupamento e de
anotao. O Captulo 7 Diagramas faz uma breve apresentao dos principais diagramas
da UML e o Captulo 12 Pacotes trata de pacotes e diagramas de pacotes.
BASS, L., CLEMENTS, P., KAZMAN, R., Software Architecture in Practice, Second
edition, Addison Wesley, 2003.
BLAHA, M., RUMBAUGH, J., Modelagem e Projetos Baseados em Objetos com UML 2,
Elsevier, 2006.
BOOCH, G., Object-Oriented Analysis and Design with Applications, 2nd edition,
Benjamin/Cummings Publishing Company, Inc, 1994.
BOOCH, G., RUMBAUGH, J., JACOBSON, I., UML Guia do Usurio, 2a edio, Elsevier
Editora, 2006.
ISO/IEC 9126-1, Software Engineering - Product Quality - Part 1: Quality Model, 2001.
ISO/IEC TR 9126-2:2003, Software Engineering Product Quality Part 2: External
Metrics, 2003a.
ISO/IEC TR 9126-3:2003, Software Engineering Product Quality Part 3: Internal Metrics,
2003b.
JACOBSON, I.; Object-Oriented Software Engineering, Addison-Wesley, 1992.
LARMAN, C., Utilizando UML e Padres, 3 edio, Bookman, 2007.
OLIV, A., Conceptual Modeling of Information Systems, Springer, 2007.
PASTOR, O., MOLINA, J.C., Model-Driven Architecture in Practice: A Software Production
Environment Based on Conceptual Modeling, Springer, 2007.
ROBERTSON, S., ROBERTSON, J., Mastering the Requirements Process. 2nd Edition.
RUMBAUGH, J., et al.; Modelagem e Projetos Baseados em Objetos, 1 Edio, Editora
Campus, 1994.
Elsevier, 2004.
WIEGERS, K.E., Software Requirements: Practical techniques for gathering and managing
requirements throughout the product development cycle. 2nd Edition, Microsoft Press,
Redmond, Washington, 2003.
YOURDON, E., Object-Oriented Systems Design: an Integrated Approach, Yourdon Press
Computing Series, Prentice Hall, 1994.

87

A anlise de requisitos um processo que envolve a construo de diversos modelos.
Diagramas de classes e diagramas de interao incluem detalhes relacionados estrutura
interna dos objetos, suas associaes, como eles interagem dinamicamente e como invocam o
comportamento dos demais. Essas informaes so necessrias para projetar e construir um
sistema, mas no so suficientes para comunicar requisitos com clientes e usurios. Elas no
capturam o conhecimento sobre as tarefas a serem realizadas e, portanto, difcil avaliar se o
sistema a ser construdo a partir de um modelo desse tipo, isoladamente, vai realmente atender
s necessidades dos usurios.
Assim, o primeiro modelo a ser construdo deve ser passvel de compreenso tanto por
desenvolvedores analistas, projetistas, programadores e testadores como pela comunidade
usuria clientes e usurios. Esse modelo inicial deve descrever o sistema, seu ambiente e
como sistema e ambiente esto relacionados.
Modelos de caso de uso (use cases) so uma forma de estruturar essa viso. Como o
prprio nome sugere, um caso de uso uma maneira de usar o sistema. Usurios interagem
com o sistema, interagindo com seus casos de uso. Tomados em conjunto, os casos de uso de
um sistema definem a sua funcionalidade. Casos de uso so, portanto, os itens que o
desenvolvedor negocia com seus clientes.
O propsito do modelo de casos de uso capturar e descrever a funcionalidade que um
sistema deve prover. Um sistema geralmente serve a vrios atores, para os quais ele prov
diferentes servios. Tipicamente, a funcionalidade a ser provida por um sistema muito
grande para ser analisada como uma nica unidade e, portanto, importante ter um
mecanismo de dividir essa funcionalidade em partes menores e mais gerenciveis. O conceito
de caso de uso muito til para esse propsito (OLIV, 2007).
importante ter em mente que modelos de casos de uso so fundamentalmente uma
ferramenta textual. Ainda que casos de uso sejam tambm descritos graficamente (p.ex.,
fluxogramas ou algum diagrama da UML, dentre eles diagramas de casos de uso, diagramas
de sequncia e diagramas de atividades), no se deve perder de vista a natureza textual dos
modelos de casos de uso. Olhando casos de uso apenas a partir da UML, que no trata do
contedo ou da escrita de casos de uso, pode-se pensar, equivocadamente, que casos de uso
so uma construo grfica ao invs de textual. Em essncia, casos de uso servem como um
meio de comunicao entre pessoas, algumas delas sem nenhum treinamento especial e,
portanto, o uso de texto para especificar casos de uso geralmente a melhor escolha. Casos de
uso so amplamente usados no desenvolvimento de sistemas, porque, por meio sobretudo de
suas descries textuais, usurios e clientes conseguem visualizar qual a funcionalidade a ser
provida pelo sistema, conseguindo reagir mais rapidamente no sentido de refinar, alterar ou
rejeitar as funes previstas para o sistema (COCKBURN, 2005). Assim, um modelo de casos
de uso inclui duas partes principais: (i) os diagramas de casos de uso e (ii) as descries de

88
atores e de casos de uso, sendo que essas ltimas podem ser complementadas com outros
diagramas associados, tais como os diagramas de atividade e de sequncia da UML6.
Outro aspecto a ser realado que os modelos de caso de uso so independentes do
mtodo de anlise a ser usado e at mesmo do paradigma de desenvolvimento. Assim, podese utilizar a modelagem de casos de uso tanto no contexto do desenvolvimento orientado a
objetos (foco deste texto), como em projetos desenvolvidos segundo o paradigma estruturado.
De fato, o uso de modelos de caso de uso pode ser ainda mais amplo. Casos de uso podem ser
usados, por exemplo, para documentar processos de negcio de uma organizao. Contudo,
neste texto, explora-se a utilizao de casos de uso para modelar e documentar requisitos
funcionais de sistemas. Assim, geralmente so interessados7 (stakeholders) nos casos de uso:
as pessoas que usaro o sistema (usurios), o cliente que requer o sistema, outros sistemas
com os quais o sistema em questo ter de interagir e outros membros da organizao (ou at
mesmo de fora dela) que tm restries que o sistema precisa garantir.
Este captulo aborda a tcnica de modelagem de casos de uso, discutindo os principais
elementos de modelos de casos de uso. A Seo 5.1 discute os dois principais conceitos
empregados na modelagem de casos de uso: atores e casos de uso. A Seo 5.2 aborda os
diagramas de casos de uso e sua notao segundo a UML. A Seo 5.3 trata da especificao
de casos de uso. A Seo 5.4 discute os tipos de relacionamentos que podem ser estabelecidos
entre casos de uso, a saber: incluso, extenso e generalizao / especializao. Finalmente, a
Seo 5.5 discute como trabalhar com casos de uso e como us-los em outras atividades do
processo de software.
5.1 Atores e Casos de Uso

Nenhum sistema computacional existe isoladamente. Todo sistema interage com
atores humanos ou outros sistemas, que utilizam esse sistema para algum propsito e esperam
que o sistema se comporte de certa maneira. Um caso de uso especifica um comportamento de
um sistema segundo uma perspectiva externa e uma descrio de uma sequncia de aes
realizada pelo sistema para produzir um resultado de valor para um ator (BOOCH;
RUMBAUGH; JACOBSON, 2006).
Segundo Cockburn (2005), um caso de uso captura um contrato entre os interessados
(stakeholders) em um sistema sobre o seu comportamento. Um caso de uso descreve o
comportamento do sistema sob certas condies, em resposta a uma requisio feita por um
interessado, dito o ator primrio do caso de uso. Assim, os dois principais conceitos da
modelagem de casos de uso so atores e casos de uso.
5.1.1 - Atores
D-se nome de ator a um papel desempenhado por entidades fsicas (pessoas ou outros
sistemas) que interagem com o sistema em questo da mesma maneira, procurando atingir os
mesmos objetivos. Uma mesma entidade fsica pode desempenhar diferentes papis no
mesmo sistema, bem como um dado papel pode ser desempenhado por diferentes entidades
(OLIV, 2007).
6
O uso de diagramas de atividade e de sequncia para complementar a especificao de um caso de uso

discutido no Captulo 7.
7
Algum ou algo com interesse no comportamento do sistema sob discusso (COCKBURN, 2005).

89
Atores so externos ao sistema. Um ator se comunica diretamente com o sistema, mas

no parte dele. A modelagem dos atores ajuda a definir as fronteiras do sistema, isto , o
conjunto de atores de um sistema delimita o ambiente externo desse sistema, representando o
conjunto completo de entidades para as quais o sistema pode servir (BLAHA; RUMBAUGH,
2006; OLIV, 2007).
Uma dvida que sempre passa pela cabea de um iniciante em modelagem de casos de
uso saber se o ator a pessoa que efetivamente opera o sistema (p.ex., o atendente de uma
locadora de automveis) ou se a pessoa interessada no resultado do processo (p.ex., o cliente
que efetivamente loca o automvel e atendido pelo atendente). Essa definio depende, em
essncia, da fronteira estabelecida para o sistema. Sistemas de informao podem ter
diferentes nveis de automatizao. Por exemplo, se um sistema roda na Internet, seu nvel de
automatizao maior do que se ele requer um operador. Assim, importante capturar qual o
nvel de automatizao requerido e levar em conta o real limite do sistema (WAZLAWICK,
2004). Se o caso de uso roda na Internet (p.ex., um caso de uso de reserva de automvel),
ento o cliente o ator efetivamente. Se o caso de uso requer um operador (p.ex., um caso de
uso de locao de automvel, disponvel apenas na locadora e para ser usado por atendentes),
ento o operador o ator.
Quando se for considerar um sistema como sendo um ator, deve-se tomar o cuidado
para no confundir a ideia de sistema externo (ator) com produtos usados na implementao
do sistema em desenvolvimento. Para que um sistema possa ser considerado um ator, ele deve
ser um sistema de informao completo (e no apenas uma biblioteca de classes, por
exemplo). Alm disso, ele deve estar fora do escopo do desenvolvimento do sistema atual. O
analista no ter a oportunidade de alterar as funes do sistema externo, devendo adequar a
comunicao s caractersticas do mesmo (WAZLAWICK, 2004).
Um ator primrio um ator que possui metas a serem cumpridas atravs do uso de
servios do sistema e que, tipicamente, inicia a interao com o sistema (OLIV, 2007). Um
ator secundrio um ator que interage com o sistema para prover um servio para este ltimo.
A identificao de atores secundrios importante, uma vez que ela permite identificar
interfaces externas que o sistema usar e os protocolos que regem as interaes ocorrendo
atravs delas (COCKBURN, 2005).
De maneira geral, o ator primrio o usurio direto do sistema ou outro sistema
computacional que requisita um servio do sistema em desenvolvimento. O sistema responde
requisio procurando atend-la, ao mesmo tempo em que protege os interesses de todos os
demais interessados no caso de uso. Entretanto, h situaes em que o iniciador do caso de
uso no o ator primrio. O tempo, por exemplo, pode ser o acionador de um caso de uso.
Um caso de uso que roda todo dia meia-noite ou ao final do ms tem o tempo como
acionador. Mas o caso de uso ainda visa atingir um objetivo de um ator e esse ator
considerado o ator primrio do caso de uso, ainda que ele no interaja efetivamente com o
sistema (COCKBURN, 2005).
Para nomear atores, recomenda-se o uso de substantivos no singular, iniciados com
letra maiscula, possivelmente combinados com adjetivos. Exemplos: Cliente, Bibliotecrio,
Correntista, Correntista Titular etc.

90
5.1.2 Casos de Uso

Um caso de uso uma poro coerente da funcionalidade que um sistema pode
fornecer para atores interagindo com ele (BLAHA; RUMBAUGH, 2006). Um caso de uso
corresponde a um conjunto de aes realizadas pelo sistema (ou por meio da interao com o
sistema), que produz um resultado observvel, com valor para um ou mais atores do sistema.
Geralmente, esse valor a realizao de uma meta de negcio ou tarefa (OLIV, 2007).
Assim, um caso de uso captura alguma funo visvel ao ator e, em especial, busca atingir
uma meta desse ator.
Deve-se considerar que um caso de uso corresponde a uma transao completa, ou
seja, um usurio poderia ativar o sistema, executar o caso de uso e desativar o sistema logo
em seguida, e a operao estaria completa e consistente e atenderia a uma meta desse usurio
(WAZLAWICK, 2004).
Ser uma transao completa uma caracterstica essencial de um caso de uso8, pois
somente transaes completas so capazes de atingir um objetivo do usurio. Casos de uso
que necessitam de mltiplas sesses no passam nesse critrio e devem ser divididos em casos
de uso menores. Seja o exemplo de um caso de uso de concesso de emprstimo.
Inicialmente, um atendente interagindo com um cliente informa os dados necessrios para a
avaliao do pedido de emprstimo. O pedido de emprstimo , ento, enviado para anlise
por um analista de crdito. Uma vez analisado e aprovado, o emprstimo concedido, quando
o dinheiro entregue ao cliente e um contrato assinado, dentre outros. Esse processo pode
levar vrios dias e no realizado em uma sesso nica. Assim, o caso de uso de concesso
de emprstimo deveria ser subdividido em casos de uso menores, tais como casos de uso para
efetuar pedido de emprstimo, analisar pedido de emprstimo e formalizar concesso de
emprstimo.
Por outro lado, casos de uso muito pequenos, que no caracterizam uma transao
completa, devem ser considerados passos de um caso de uso maior9. Seja o exemplo de uma
biblioteca a qual cobra multa na devoluo de livros em atraso. Um caso de uso especfico
para apenas calcular o valor da multa no relevante, pois no caracteriza uma transao
completa capaz de atingir um objetivo do usurio. O objetivo do usurio efetuar a devoluo
e, neste contexto, uma regra de negcio (a que estabelece a multa) tem de ser levada em
conta. Assim, calcular a multa apenas um passo do caso de uso que efetua a devoluo, o
qual captura uma ao do sistema para garantir a regra de negcio e, portanto, satisfazer um
interesse da biblioteca como organizao.
Um caso de uso rene todo o comportamento relevante de uma parte da funcionalidade
do sistema. Isso inclui o comportamento principal normal, as variaes de comportamento
normais, as condies de exceo e o cancelamento de uma requisio. O conjunto de casos
de uso captura a funcionalidade completa do sistema (BLAHA; RUMBAUGH, 2006).
Casos de uso fornecem uma abordagem para os desenvolvedores chegarem a uma
compreenso comum com os usurios finais e especialistas do domnio, acerca da
funcionalidade a ser provida pelo sistema (BOOCH; RUMBAUGH; JACOBSON, 2006).
Esta regra tem como exceo os casos de uso de incluso e extenso, conforme discutido mais adiante na seo
que trata de relacionamentos entre casos de uso.
9
As mesmas excees da nota anterior aplicam-se aqui, conforme discutido mais adiante.

91
Os objetivos dos atores so um bom ponto de partida para a identificao de casos de

uso. Pode-se propor um caso de uso para satisfazer cada um dos objetivos de cada um dos
atores. A partir desses objetivos, podem-se estudar as possveis interaes do ator com o
sistema e refinar o modelo de casos de uso.
Cada caso de uso tem um nome. Esse nome deve capturar a essncia do caso de uso.
Para nomear casos de uso sugere-se usar frases iniciadas com verbos no infinitivo, seguidos
de complementos, que representem a meta ou tarefa a ser realizada com o caso de uso. As
primeiras letras (exceto preposies) de cada palavra devem ser grafadas em letra maiscula.
Exemplos: Cadastrar Cliente, Devolver Livro, Efetuar Pagamento de Fatura etc.
Um caso de uso pode ser visto como um tipo cujas instncias so cenrios. Um cenrio
uma execuo de um caso de uso com entidades fsicas particulares desempenhando os
papis dos atores e em um particular estado do domnio de informao. Um cenrio, portanto,
exercita um certo caminho dentro do conjunto de aes de um caso de uso (OLIV, 2007).
Alguns cenrios mostram o objetivo do caso de uso sendo alcanado; outros terminam
com o caso de uso sendo abandonado (COCKBURN, 2005). Mesmo quando o objetivo de um
caso de uso alcanado, ele pode ser atingido seguindo diferentes caminhos. Assim, um caso
de uso deve comportar todas essas situaes. Para tal, um caso de uso normalmente descrito
por um conjunto de fluxos de eventos, capturando o fluxo de eventos principal, i.e., o fluxo de
eventos tpico que conduz ao objetivo do caso de uso, e fluxos de eventos alternativos,
descrevendo excees ou variantes do fluxo principal.
5.2 - Diagramas de Casos de Uso

Basicamente, um diagrama de casos de uso mostra um conjunto de casos de uso e
atores e seus relacionamentos, sendo utilizado para ilustrar uma viso esttica das maneiras
possveis de se usar o sistema (BOOCH; RUMBAUGH; JACOBSON, 2006).
Os diagramas de casos de uso da UML podem conter os seguintes elementos de
modelo, ilustrados na Figura 5.1 (BOOCH; RUMBAUGH; JACOBSON, 2006):
Assunto: o assunto delimita a fronteira de um diagrama de casos de uso, sendo

normalmente o sistema ou um subsistema. Os casos de uso de um assunto
descrevem o comportamento completo do assunto. O assunto exibido em um
diagrama de casos de uso como um retngulo envolvendo os casos de uso que o
compem. O nome do assunto (sistema ou subsistema) pode ser mostrado dentro
do retngulo.
Ator: representa um conjunto coerente de papis que os usurios ou outros

sistemas desempenham quando interagem com os casos de uso. Tipicamente, um
ator representa um papel que um ser humano, um dispositivo de hardware ou outro
sistema desempenha com o sistema em questo. Atores no so parte do sistema.
Eles residem fora do sistema. Atores so representados por um cone de homem,
com o nome colocado abaixo do cone.
Caso de Uso: representa uma funcionalidade que o sistema deve prover. Casos de
uso so parte do sistema e, portanto, residem dentro dele. Um caso de uso
representado por uma elipse com o nome do caso de uso dentro ou abaixo dela.

92
Relacionamentos de Dependncia, Generalizao e Associao: so usados para

estabelecer relacionamentos entre atores, entre atores e casos de uso, e entre casos
de uso.
Figura 5.1 - Diagrama de Casos de Uso Conceitos e Notao.

Atores s podem estar conectados a casos de uso por meio de associaes. Uma
associao entre um ator e um caso de uso significa que estmulos podem ser enviados entre
atores e casos de uso. A associao entre um ator e um caso de uso indica que o ator e o caso
de uso se comunicam entre si, cada um com a possibilidade de enviar e receber mensagens
(BOOCH; RUMBAUGH; JACOBSON, 2006).
Atores podem ser organizados em hierarquias de generalizao / especializao, de
modo a capturar que um ator filho herda o significado e as associaes com casos de uso de
seu pai, especializando esse significado e potencialmente adicionando outras associaes
como outros casos de uso.
A Figura 5.2 mostra um diagrama de casos de uso para um sistema de caixa
automtico. Nesse diagrama, o assunto o sistema como um todo. Os atores so: os clientes
do banco, o sistema bancrio e os responsveis pela manuteno do numerrio no caixa
eletrnico. Cliente e mantenedor so atores primrios, uma vez que tm objetivos a serem
atingidos pelo uso do sistema. O sistema bancrio um ator secundrio, pois o sistema do
caixa automtico precisa interagir com o sistema bancrio para realizar os casos de uso
Efetuar Saque, Emitir Extrato e Efetuar Pagamento.

93
Figura 5.2 - Diagrama de Casos de Uso Caixa Automtico.

Um caso de uso descreve o que um sistema deve fazer. O diagrama de casos de uso
prov uma viso apenas parcial disso, uma vez que mostra as funcionalidades por perspectiva
externa. necessrio, ainda, capturar uma viso interna de cada caso de uso, especificando o
comportamento do caso de uso pela descrio do fluxo de eventos que ocorre internamente
(passos do caso de uso). Assim, uma parte fundamental do modelo de casos de uso a
descrio dos casos de uso.
5.3 - Descrevendo Casos de Uso

Um caso de uso deve descrever o que um sistema faz. Exceto para situaes muito
simples, um diagrama de casos de uso insuficiente para este propsito. Assim, deve-se
especificar o comportamento de um caso de uso pela descrio textual de seu fluxo de
eventos, de modo que outros interessados possam compreend-lo.
A especificao ou descrio de um caso de uso deve conter, dentre outras
informaes, um conjunto de sentenas, cada uma delas designando um passo simples, de
modo que aprender a ler um caso de uso no requeira mais do que uns poucos minutos.
Dependendo da situao, diferentes estilos de escrita podem ser adotados (COCKBURN,
2005).
Cada passo do fluxo de eventos de um caso de uso tipicamente descreve uma das
seguintes situaes: (i) uma interao entre um ator e o sistema, (ii) uma ao que o sistema
realiza para atingir o objetivo do ator primrio ou (iii) uma ao que o sistema realiza para
proteger os interesses de um interessado. Essas aes podem incluir validaes e mudanas do
estado interno do sistema (COCKBURN, 2005).
No h um padro definido para especificar casos de uso. Diferentes autores propem
diferentes estruturas, formatos e contedos para descries de casos de uso, alguns mais
indicados para casos de uso essenciais e mais complexos, outros para casos de uso cadastrais
e mais simples. Mais alm, pode ser til utilizar mais de um formato dentro do mesmo

94
projeto, em funo das peculiaridades de cada caso de uso. De todo modo, recomendvel
que a organizao defina modelos de descrio de casos de uso a serem adotados em seus
projetos, devendo definir tantos modelos quantos julgar necessrios.
Cockburn (2005) recomenda que pelo menos dois modelos de descrio de casos de
uso sejam definidos: um casual, escrito como um texto corrido livre, a ser usado em projetos
com pouca formalidade; outro completo, com uma estrutura bem definida, para projetos de
maior formalidade.
As seguintes informaes so um bom ponto de partida para a definio de um modelo
de descrio de casos de uso:
Nome: nome do caso de uso, capturando a sua essncia
Escopo: diz respeito ao que est sendo documentado pelo caso de uso. Tipicamente
pode ser um processo de negcio, um sistema ou um subsistema. Vale lembrar que
este texto no aborda a utilizao de casos de uso para a modelagem de processos
de negcio. Assim, o escopo vai apontar o sistema / subsistema do qual o caso de
uso faz parte.
Descrio do Propsito: uma descrio sucinta do caso de uso, na forma de um

nico pargrafo, procurando descrever o objetivo do caso de uso.
Ator Primrio: nome do ator primrio, ou seja, o interessado que tem um objetivo
em relao ao sistema, o qual pode ser atingido pela execuo do caso de uso.
Interessados e Interesses: um interessado algum ou algo (um outro sistema) que

tem um interesse no comportamento do caso de uso sendo descrito. Nesta seo
so descritos cada um dos interessados no sistema e qual o seu interesse no caso de
uso, incluindo o ator primrio.
Pr-condies: o que deve ser verdadeiro antes da execuo do caso de uso. Se as

pr-condies no forem satisfeitas, o caso de uso no pode ser realizado.
Ps-condies: o que deve ser verdadeiro aps a execuo do caso de uso,

considerando que o fluxo de eventos normal realizado com sucesso.
Fluxo de Eventos Normal: descreve os passos do caso de uso realizados em

situaes normais, considerando que nada acontece de errado e levando em conta a
maneira mais comum do caso de uso ser realizado.
Fluxo de Eventos Alternativos: descreve formas alternativas de realizar certos

passos do caso de uso. H duas formas alternativas principais: fluxos variantes,
que so considerados dentro da normalidade do caso de uso; e fluxos de exceo,
que se referem ao tratamento de erros durante a execuo de um passo do fluxo
normal (ou de um fluxo variante ou at mesmo de um outro fluxo de exceo).
Requisitos Relacionados: listagem dos identificadores dos requisitos (funcionais,

no funcionais e regras de negcio) tratados pelo caso de uso sendo descrito, de
modo a permitir rastrear os requisitos. Casos de uso podem ser usados para
conectar vrios requisitos, de tipos diferentes. Assim, essa listagem ajuda a manter
um rastro entre requisitos funcionais, no funcionais e regras de negcio, alm de
permitir verificar se algum requisito deixou de ser tratado.

95
Classes / Entidades: classes (no paradigma orientado a objetos) ou entidades (no

paradigma estruturado) necessrias para tratar o caso de uso sendo descrito. Esta
seo normalmente preenchida durante a modelagem conceitual estrutural e
igualmente importante para permitir rastrear requisitos para as etapas subsequentes
do desenvolvimento (projeto e implementao, sobretudo).
5.3.1 Descrevendo os Fluxos de Eventos

Uma vez que o conjunto inicial de casos de uso estiver estabilizado, cada um deles
deve ser descrito em mais detalhes. Primeiro, deve-se descrever o fluxo de eventos principal
(ou curso bsico), isto , o curso de eventos mais importante, que normalmente ocorre. O
fluxo de eventos normal (ou principal) uma informao essencial na descrio de um caso
de uso e no pode ser omitido em nenhuma circunstncia. O fluxo de eventos normal ,
portanto, a principal seo de uma descrio de caso de uso, a qual descreve o processo
quando tudo d certo, ou seja, sem a ocorrncia de nenhuma exceo (WAZLAWICK, 2004).
Variantes do curso bsico de eventos e tratamento de excees que possam vir a
ocorrer devem ser descritos em cursos alternativos. Normalmente, um caso de uso possui
apenas um nico curso bsico, mas diversos cursos alternativos. Seja o exemplo de um
sistema de caixa automtico de banco, cujo diagrama de casos de uso mostrado na Figura
5.2. O caso de uso Efetuar Saque poderia ser descrito como mostrado na Figura 5.3.
Como visto nesse exemplo, um caso de uso pode ter um nmero de cursos alternativos
que podem levar o caso de uso por diferentes caminhos. Tanto quanto possvel, esses cursos
alternativos, muitos deles cursos de exceo, devem ser identificados durante a especificao
do fluxo de eventos normal de um caso do uso.
Vale realar que uma exceo no necessariamente um evento que ocorre muito
raramente, mas sim um evento capaz de impedir o prosseguimento do caso de uso, se no for
devidamente tratado. Uma exceo tambm no algo que impede o caso de uso de ser
iniciado, mas algo que impede a sua concluso. Condies que impedem um caso de uso de
ser iniciado devem ser tratadas como pr-condies. As pr-condies nunca devem ser
testadas durante o processo do caso de uso, pois, por definio, elas impedem que o caso de
uso seja iniciado. Logo, seria inconsistente imaginar que elas pudessem ocorrer durante a
execuo do caso de uso. Se uma pr-condio falsa, ento o caso de uso no pode ser
iniciado (WAZLAWICK, 2004).
Observa-se que a maioria das excees ocorre nos passos em que alguma informao
passada dos atores para o sistema. Isso porque, quando uma informao passada para o
sistema, muitas vezes ele realiza validaes. Quando uma dessas validaes falha, tipicamente
ocorre uma exceo (WAZLAWICK, 2004).

96
Nome: Efetuar Saque

Escopo: Sistema de Caixa Automtico
Descrio do Propsito: Este caso de uso permite que um cliente do banco efetue um saque,
retirando dinheiro de sua conta bancria.
Ator Primrio: Cliente
Interessados e Interesses:
Cliente: deseja efetuar um saque.
Banco: garantir que apenas o prprio cliente efetuar saques e que os valores dos
saques sejam compatveis com o limite de crdito do cliente.
Pr-condies: O caixa automtico deve estar conectado ao sistema bancrio.
Ps-condies: O saque efetuado, debitando o valor da conta do cliente e entregando o
mesmo valor para o cliente em espcie.
Fluxo de Eventos Normal
O cliente insere seu carto no caixa automtico, que analisa o carto e verifica se ele
aceitvel. Se o carto aceitvel, o caixa automtico solicita que o cliente informe a senha. O
cliente informa a senha. O caixa automtico envia os dados do carto e da senha para o
sistema bancrio para validao. Se a senha estiver correta, o caixa solicita que o cliente
informe o tipo de transao a ser efetuada. O cliente seleciona a opo saque e o caixa solicita
que seja informada a quantia. O cliente informa a quantia a ser sacada. O caixa envia uma
requisio para o sistema bancrio para que seja efetuado um saque na quantia especificada.
Se o saque autorizado, as notas so preparadas e liberadas.
Fluxos de Eventos de Exceo
O carto no aceitvel: Se o carto no aceitvel, seja porque sua tarja magntica
no passvel de leitura seja porque de um tipo incompatvel, uma mensagem de
erro de leitura mostrada.
Senha incorreta: Se a senha informada est incorreta, uma mensagem mostrada para
o cliente que poder entrar com a senha novamente. Caso o cliente informe trs vezes
senha incorreta, o carto dever ser bloqueado.
Saque no autorizado: Se o saque no for aceito pelo sistema bancrio, uma mensagem
de erro exibida e a operao abortada.
No h dinheiro suficiente disponvel no caixa eletrnico: Uma mensagem de erro
exibida e a operao abortada.
Cancelamento: O cliente pode cancelar a transao a qualquer momento, enquanto o
saque no for autorizado pelo sistema bancrio.
Requisitos Relacionados: RF01, RN01, RNF01, RNF0210
Classes: Cliente, Conta, Carto, Transao, Saque.
Figura 5.3 Descrio do Caso de Uso Efetuar Saque.
10
So as seguintes as descries dos requisitos listados: RF01 O sistema de caixa automtico deve permitir que
clientes efetuem saques em dinheiro; RN01 No devem ser permitidas transaes que deixem a conta do
cliente com saldo inferior ao de seu limite de crdito; RNF01 O sistema de caixa automtico deve estar
integrado ao sistema bancrio; RNF02 As operaes realizadas no caixa automtico devem dar respostas em
at 10s a partir da entrada de dados.

97
Em sistemas de mdio a grande porte, pode ser til considerar a fuso de casos de uso
fortemente relacionados em um nico caso de uso, contendo mais de um fluxo de eventos
normal. Em muitos sistemas necessrio dar ao usurio a possibilidade de cancelar ou alterar
dados de uma transao efetuada anteriormente com sucesso. Se cada uma dessas
possibilidades for considerada como um caso de uso isolado, o nmero de casos de uso pode
crescer demasiadamente, aumentando desnecessariamente a complexidade do modelo de
casos de uso. Alm disso, o fluxo de eventos normal de um caso de uso desse tipo tende a ser
muito simples, no justificando documentar todo um conjunto de informaes para adicionar
apenas duas ou trs linhas descrevendo os passos do caso de uso. Assim, em situaes dessa
natureza, interessante considerar apenas um caso de uso, contendo diversos fluxos de
eventos principais. Essa abordagem bastante recomendada para casos de uso cadastrais, em
que um nico caso de uso inclui fluxos de eventos normais para criar, alterar, consultar e
excluir entidades.
Fluxos de eventos normais podem ser descritos de diferentes maneiras, dependendo do
nvel de formalidade que se deseja para as descries. Dentre os formatos possveis, h dois
principais:
Livre: o fluxo de eventos normal escrito na forma de um texto corrido, como no

exemplo da Figura 5.3;
Enumerado: cada passo do fluxo de eventos normal numerado, de modo que

possa ser referenciado nos fluxos de eventos alternativos ou em outros pontos do
fluxo de eventos normal. A Figura 5.4 reapresenta o exemplo da Figura 5.3 neste
formato. As sees iniciais foram omitidas por serem iguais s da Figura 5.3.
Neste texto, advogamos em favor do uso do formato enumerado.
Cada exceo deve ser tratada por um fluxo alternativo de exceo. Fluxos alternativos
de exceo devem ser descritos contendo as seguintes informaes (WAZLAWICK, 2004):
um identificador, uma descrio sucinta da exceo que ocorreu, os passos para tratar a
exceo (aes corretivas) e uma indicao de como o caso de uso retorna ao fluxo principal
(se for o caso) aps a execuo das aes corretivas.
Quando um formato de descrio enumerado utilizado, no necessrio colocar uma
verificao como uma condicional no fluxo principal. Por exemplo, no caso da Figura 5.4, o
passo 3 no deve ser escrito como 3. Se o carto vlido, o caixa automtico solicita que o
cliente informe a senha.. Basta o fluxo alternativo, no exemplo, o fluxo 2a.
Ainda quando o formato de descrio enumerado utilizado, o identificador da
exceo deve conter a linha do fluxo de eventos principal (ou eventualmente de algum outro
fluxo de eventos alternativo) no qual a exceo ocorreu e uma letra para identificar a prpria
exceo (WAZLAWICK, 2004), como ilustra o exemplo da Figura 5.4.
Uma informao que precisa estar presente na descrio de um fluxo de eventos de
exceo diz respeito a como finalizar o tratamento de uma exceo. Wazlawick (2004) aponta
quatro formas bsicas para finalizar o tratamento de uma exceo:
Voltar ao incio do caso de uso, o que no muito comum nem prtico.
Voltar ao incio do passo em que ocorreu a exceo e execut-lo novamente. Esta

a situao mais comum.
Voltar para algum um passo posterior. Esta situao ocorre quando as aes
corretivas realizam o trabalho que o passo (ou a sequncia de passos) posterior

98
deveria executar. Neste caso, importante verificar se novas excees no

poderiam ocorrer.
Abortar o caso de uso. Neste caso, no se retorna ao fluxo principal e o caso de uso
no atinge seus objetivos.
Nome: Efetuar Saque

1.
2.
3.
4.
5.
O cliente insere seu carto no caixa automtico.

O caixa automtico analisa o carto e verifica se ele aceitvel.
O caixa automtico solicita que o cliente informe a senha.
O cliente informa a senha.
O caixa automtico envia os dados do carto e da senha para o sistema bancrio
para validao.
6. O caixa automtico solicita que o cliente informe o tipo de transao a ser
efetuada.
7. O cliente seleciona a opo saque.
8. O caixa automtico solicita que seja informada a quantia.
9. O cliente informa a quantia a ser sacada.
10. O caixa automtico envia uma requisio para o sistema bancrio para que seja
efetuado um saque na quantia especificada.
11. As notas so preparadas e liberadas.
2a O carto no aceitvel: Se o carto no aceitvel, seja porque sua tarja
magntica no passvel de leitura seja porque de um tipo incompatvel, uma
mensagem de erro de leitura mostrada e se retorna ao passo 1.
5a Senha incorreta:
5a.1 1 e 2 tentativas: Uma mensagem de erro mostrada para o cliente.
Retornar ao passo 3.
5a.2 3 tentativa: bloquear o carto e abortar a transao.
10a - Saque no autorizado: Uma mensagem de erro exibida e a operao abortada.
11a - No h dinheiro suficiente disponvel no caixa eletrnico: Uma mensagem de
erro exibida e a operao abortada.
1 a 9: Cancelamento: O cliente pode cancelar a transao, enquanto o saque no for
autorizado pelo sistema bancrio. A transao abortada.
Figura 5.4 Descrio do Caso de Uso Efetuar Saque Formato Enumerado
Alm dos fluxos de exceo, h outro tipo de fluxo de eventos alternativo: os fluxos
variantes. Fluxos variantes so considerados dentro da normalidade do caso de uso e indicam
formas diferentes, mas igualmente normais, de se realizar uma certa poro de um caso de
uso. Seja o caso de um sistema de um supermercado, mais especificamente um caso de uso
para efetuar uma compra. Um passo importante desse caso de uso a realizao do
pagamento, o qual pode se dar de trs maneiras distintas: pagamento em dinheiro, pagamento
em cheque, pagamento em carto. Nenhuma dessas formas de pagamento constitui uma
exceo. So todas maneiras diferentes, mas normais, de realizar um certo passo do caso de

99
uso e, portanto, pode-se dizer que o fluxo principal possui trs variaes. A descrio de um
fluxo variante deve conter: um identificador, uma descrio sucinta do passo especializado e
os passos enumerados, como ilustra a Figura 5.5.
Nome: Efetuar Compra
...
1. De posse do valor a ser pago, o atendente informa a forma de pagamento.
2. Efetuar o pagamento:
2a. Em dinheiro
2b. Em cheque
2c. Em carto
3. O pagamento registrado.
Fluxos de Eventos Variantes
2a Pagamento em Dinheiro:
2a.1 O atendente informa a quantia em dinheiro entregue pelo cliente.
2a.2 O sistema informa o valor do troco a ser dado ao cliente.
2b Pagamento em Cheque:
2b.1 O atendente informa os dados do cheque, a saber: banco, agncia, conta e valor.
2c Pagamento em Carto:
2c.1 O atendente informa os dados do carto e o valor da compra.
2.c.2 O sistema envia os dados informados no passo anterior, junto com a
identificao da loja para o servio de autorizao do Sistema de Operadoras de Carto
de Crdito.
2c.3 O Sistema de Operadoras de Carto de Crdito autoriza a compra e envia o
cdigo da autorizao.
Figura 5.5 Descrio Parcial do Caso de Uso Efetuar Compra com Variantes
Por fim, em diversas situaes, pode ser desnecessariamente trabalhoso especificar
casos de uso segundo um formato completo, seja usando uma descrio dos fluxos de eventos
no formato livre seja no formato enumerado. Para esses casos, um formato simplificado, na
forma de uma tabela, pode ser usado. O formato tabular normalmente empregado para casos
de uso que possuem uma estrutura de interao simples, seguindo uma mesma estrutura geral,
tais como casos de uso cadastrais (ou CRUD11) e consultas. Casos de uso cadastrais de baixa
complexidade tipicamente envolvem incluso, alterao, consulta e excluso de entidades e
seguem o padro de descrio mostrado na Figura 5.6.
11
CRUD do ingls: Create, Read, Update and Delete; em portugus: Criar, Consultar, Atualizar e Excluir, ou
seja, casos de uso que proveem as funes bsicas de manipulao de dados de uma entidade de interesse do
sistema.

100
Fluxos de Eventos Normais

Criar [Novo Objeto]
O [ator] informa os dados do [novo objeto], a saber: [atributos e associaes do objeto].
Caso os dados sejam vlidos, as informaes so registradas.
Alterar Dados
O [ator] informa o [objeto] do qual deseja alterar dados e os novos dados. Os novos dados
so validados e a alterao registrada.
Consultar Dados
O [ator] informa o [objeto] que deseja consultar. Os dados do [objeto] so apresentados.
Excluir [Objeto]
O [ator] informa o [objeto] que deseja excluir. Os dados do [objeto] so apresentados e
solicitada uma confirmao. Se a excluso for confirmada, o [objeto] excludo.
Incluir [Novo Objeto] / Alterar Dados
Dados do [objeto] invlidos: uma mensagem de erro exibida, solicitando correo da
informao invlida.
Figura 5.6 Padro Tpico de Descrio de Casos de Uso Cadastrais.
Assim, para simplificar a descrio de casos de uso cadastrais, recomenda-se utilizar o
modelo tabular mostrado na Tabela 5.1. Quando essa tabela for empregada, estar-se-
assumindo que o caso de uso envolve os fluxos de eventos indicados (I para incluso, A para
alterao, C para consulta e E para excluso), com a descrio base mostrada na Figura 5.5.
Tabela 5.1 Modelo de Descrio de Casos de Uso Cadastrais
Caso de Uso
Aes Possveis
Observaes Requisitos
<nome do caso de uso>
< I, A, C, E >
Classes
A coluna Observaes usada para listar informaes importantes relacionadas s

aes, tais como os itens informados na incluso, uma restrio a ser considerada para que a
excluso possa ser feita, uma informao que no pode ser alterada ou uma informao do
objeto que no apresentada na consulta. Deve-se indicar antes da observao a qual ao ela
se refere ([I] para incluso, [A] para alterao, [C] para consulta e [E] para excluso).
As colunas Requisitos e Classes indicam, respectivamente, os requisitos que esto
sendo (ou que devem ser) tratados pelo caso de uso e as classes do domnio do problema
necessrias para a realizao do caso de uso. O objetivo dessas colunas manter a
rastreabilidade dos casos de uso para requisitos e classes, respectivamente, de maneira
anloga ao recomendado no formato completo.
A Tabela 5.2 ilustra a descrio de casos de usos cadastrais do subsistema Controle de
Acervo de uma videolocadora.

101
Tabela 5.2 Descrio de Casos de Uso Cadastrais Controle de Acervo de

Videolocadora
Caso de Uso
Aes
Possveis
I, A, C, E
Cadastrar
Filme
Cadastrar Item
I, A, C, E
Cadastrar
Distribuidora
I, A, C, E
Cadastrar Tipo
de Mdia
I, A, C, E
Observaes
Requisitos
Classes
[I] Informar: ttulo original, ttulo em

portugus, pas, ano, diretores, atores,
sinopse,
durao,
gnero,
distribuidora, tipo de udio (p.ex.,
Dolby Digital 2.0), idioma do udio e
idioma da legenda.
[E] No permitida a excluso de
filmes que tenham itens associados.
[E] Ao excluir um filme, devem-se
excluir as reservas associadas.
[I] Informar: filme, tipo de mdia,
data de aquisio e nmero de srie.
[E] No permitido excluir um item
que tenha locaes associadas.
[I] Informar: razo social, CNPJ,
endereo, telefone e pessoa de
contato.
[E] No permitido excluir uma
distribuidora que tenha filmes
associados.
[I] Informar: nome e valor de locao.
[E] No permitido excluir um tipo
de mdia que tenha itens associados.
[E] Ao excluir um tipo de mdia,
devem-se excluir as reservas que
especificam apenas esse tipo de
mdia.
RF9, RNF1
Filme,
Distribuidora
RF9,
RNF1,
RNF3
Item,
Filme,
TipoMidia
RF10,
RNF1
Distribuidora
RF9, RNF1
TipoMidia
Para casos de uso de consulta mais abrangente do que a consulta de um nico objeto
(j tratada como parte dos casos de uso cadastrais), mas ainda de baixa complexidade (tais
como consultas que combinam informaes de vrios objetos envolvendo filtros), sugere-se
utilizar o formato tabular mostrado na Tabela 5.3.
Tabela 5.3 Modelo de Descrio de Casos de Uso de Consulta
Caso de Uso
Observaes Requisitos
Classes
<nome do caso de uso>
A coluna Observaes deve ser usada para listar informaes importantes
relacionadas consulta, tais como dados que podem ser informados para a pesquisa,
totalizaes feitas em relatrios etc.
As colunas Requisitos e Classes tm a mesma funo de suas homnimas no modelo
da Tabela 5.1, ou seja, indicam, respectivamente, os requisitos que esto sendo tratados (ou
que devem ser) pelo caso de uso e as classes do domnio do problema necessrias para a
realizao do mesmo.
A Tabela 5.4 ilustra a descrio de um caso de usos de consulta do subsistema
Controle de Acervo de uma videolocadora.

102
Tabela 5.4 Descrio de Casos de Uso de Consulta Controle de Acervo de

Videolocadora
Caso de Uso
Consultar Acervo
Observaes
Requisitos
As consultas ao acervo podero ser RF11, RNF1,
feitas informando uma (ou uma RNF2
combinao)
das
seguintes
informaes: ttulo (ou parte dele),
original ou em portugus, gnero, tipo
de mdia disponvel, ator, diretor,
nacionalidade e lanamentos.
Classes
Filme, Item,
TipoMidia,
Distribuidora
5.3.2 Descrevendo Informaes Complementares

As descries dos fluxos de eventos principal, variantes e de exceo so cruciais em
uma descrio de casos de uso. Contudo, h outras informaes complementares que so
bastante teis e, portanto, que devem ser levantadas e documentadas. Conforme listado no
incio desta seo, so informaes complementares importantes: atores, interessados e
interesses, pr-condies, ps-condies, requisitos relacionados e classes relacionadas.
Conforme discutido na Seo 5.1, um ator representa um papel que entidades fsicas
ou sociais podem desempenhar na interao com o sistema. Essas entidades fsicas so
tipicamente pessoas, dispositivos ou outros sistemas que so externos ao sistema em
desenvolvimento. Muitas vezes, apenas o nome de um ator, como mostrado em um diagrama
de casos de uso, pode ser pouco para um real entendimento do que representa esse ator.
Assim, importante que uma descrio sucinta dos atores seja feita. Uma vez que um mesmo
ator pode atuar em vrios casos de uso, a descrio dos atores no deve ser feita dentro da
descrio dos casos de uso, mas separada, como uma seo especfica dentro do Documento
de Especificao de Requisitos. Inicialmente, atores podem ser documentados em uma tabela
de duas colunas, contendo o nome e a descrio do ator.
Como atores interagindo com o sistema definem as interfaces do sistema com o mundo
externo, pode ser til adicionar informaes sobre o perfil do ator nessa interao. Quando o
ator um ator humano, esse perfil indicaria as habilidades e a experincia do ator,
informaes valiosas para o projeto da interface com o usurio. Adicionalmente, pode-se
incluir uma classificao segundo aspectos como nvel de habilidade, nvel na organizao e
membros em diferentes grupos. Pressman (2006) prope uma classificao que considera trs
grupos principais:
Usurio novato: conhece pouco a interface para utiliz-la eficientemente
(conhecimento sinttico; p.ex., no sabe como atingir uma funcionalidade desejada)
e entende pouco as funes e objetivos do sistema (conhece pouco a semntica da
aplicao) ou no sabe bem como usar computadores em geral;
Usurio conhecedor e espordico: possui um conhecimento razovel da semntica
da aplicao, mas tem relativamente pouca lembrana dos mecanismos de interao
providos pela interface (informaes sintticas necessrias para utilizar a interface);
Usurio conhecedor e frequente: possui bom conhecimento tanto sinttico quanto
semntico e buscam atalhos e modos abreviados de interao.

103
No so apenas os atores os interessados em um caso de uso. Outras pessoas ou

unidades de uma organizao podem ter interesse nos resultados do caso de uso. Seja o caso
de uma locadora de automveis. Em um caso de uso de locao, o nico papel a interagir com
o sistema o de funcionrio do atendimento. Contudo, o cliente, o setor de preparao de
automveis, a contabilidade, dentre outros, so tambm interessados neste caso de uso.
Assim, mesmo que essas pessoas no interajam diretamente com o sistema para a realizao
do caso de uso, elas devem ser listadas como interessados. Deve-se lembrar que o sistema
deve satisfazer os interesses de todos os envolvidos, direta ou indiretamente. Assim, na seo
Interessados e Interesses, deve-se listar os diversos interessados e uma descrio sucinta de
seus interesses em relao execuo do caso de uso. Ao analisar esses interesses possvel,
dentre outros, capturar regras de negcio e informaes e descobrir aes que o sistema tem
de realizar para atender a essas expectativas, tais como validaes, atualizaes e registros.
(WAZLAWICK, 2004; COCKBURN, 2005).
Pr-condies estabelecem o que precisa ser verdadeiro antes de se iniciar um caso de
uso. Ps-condies, por sua vez, estabelecem o que ser verdadeiro aps a execuo do caso
de uso. Pr-condies precisam ser verdadeiras para que o caso de uso possa ser iniciado. No
se deve confundi-las com excees. Pr-condies no so testadas durante a execuo do
caso de uso (como ocorre com as condies que geram excees). Ao contrrio, elas so
testadas antes de iniciar o caso de uso. Se a pr-condio falsa, ento no possvel executar
o caso de uso. Para documentar as pr-condies, recomenda-se listar as condies que tm
de ser satisfeitas na seo Pr-condies. Pr-condies devem ser escritas como uma
simples assero sobre o estado do mundo no momento em que o caso de uso inicia
(COCKBURN, 2005).
Muitas vezes, uma pr-condio para ser atendida requer que um outro caso de uso j
executado tenha estabelecido essa pr-condio. Contudo, um erro bastante comum escrever
como uma pr-condio algo que frequentemente, mas no necessariamente, verdadeiro
(COCKBURN, 2005). Seja o caso de uma locadora de vdeos em que clientes em atraso no
podem locar novos itens at que regularize suas pendncias. Neste caso, uma pr-condio do
tipo cliente no est em atraso como pr-condio de um caso de uso efetuar locao
inadequada. Observe que a identificao do cliente parte do caso de uso efetuar locao e,
portanto, no possvel garantir que o cliente no est em atraso antes de iniciar o caso de
uso. Esta situao tem de ser tratada como uma exceo e no como uma pr-condio.
As sees de requisitos e classes relacionados so importantes para a gerncia de
requisitos. A primeira estabelece um rastro entre casos de uso e os requisitos de usurio
documentados no Documento de Requisitos, permitindo, em um primeiro momento, analisar
se algum requisito no foi tratado. Em um segundo momento, quando uma alterao em um
requisito solicitada, possvel usar essa informao para analisar o impacto da alterao.
Para documentar os requisitos relacionados, recomenda-se listar os identificadores de cada um
dos requisitos na seo de Requisitos Relacionados.
A seo de classes relacionadas indica quais so as classes do modelo conceitual
estrutural necessrias para a realizao do caso de uso. Essa seo permite rastrear casos de
uso para classes em vrios nveis, uma vez que h uma grande tendncia de as mesmas classes
do modelo conceitual estrutural estarem presentes nos modelos de projeto e no cdigo-fonte.
Para documentar as classes relacionadas, recomenda-se listar o nome de cada uma das classes
envolvidas na seo de Classes Relacionadas. Vale ressaltar que essa informao
tipicamente preenchida durante a modelagem conceitual estrutural ou at mesmo depois,

104
durante a elaborao de modelos de interao. A partir das informaes de requisitos e classes

relacionados, pode-se, por exemplo, construir matrizes de rastreabilidade.
5.4 - Relacionamentos entre Casos de Uso

Para permitir uma modelagem mais apurada dos casos de uso em um diagrama, trs
tipos de relacionamentos entre casos de uso podem ser empregados. Casos de uso podem ser
descritos como verses especializadas de outros casos de uso (relacionamento de
generalizao/ especializao); casos de uso podem ser includos como parte de outro caso
de uso (relacionamento de incluso); ou casos de uso podem estender o comportamento de
um outro caso de uso (relacionamento de extenso). O objetivo desses relacionamentos
tornar um modelo mais compreensvel, evitar redundncias entre casos de uso e permitir
descrever casos de uso em camadas. A seguir esses tipos de relacionamentos so abordados.
5.4.1 - Incluso
Uma associao de incluso de um caso de uso base para um caso de uso de incluso
significa que o comportamento definido no caso de uso de incluso incorporado ao
comportamento do caso de uso base. Ou seja, a relao de incluso incorpora um caso de uso
(o caso de uso includo) dentro da sequncia de comportamento de outro caso de uso (o caso
de uso base) (BLAHA; RUMBAUGH, 2006; OLIV, 2007).
Esse tipo de associao til para extrair comportamento comum a vrios casos de
uso em uma nica descrio, de modo que esse comportamento no tenha de ser descrito
repetidamente. O caso de uso de incluso pode ou no ser passvel de utilizao isoladamente.
Assim, ele pode ser apenas um fragmento de uma funcionalidade, no precisando ser uma
transao completa. A parte comum includa por todos os casos de uso base que tm esse
caso de uso de incluso em comum e a execuo do caso de uso de incluso anloga a uma
chamada de subrotina (OLIV, 2007).
Na UML, o relacionamento de incluso entre casos de uso mostrado como uma
dependncia (seta pontilhada) estereotipada com a palavra-chave include, partindo do caso de
uso base para o caso de uso de incluso, como ilustra a Figura 5.6.
Figura 5.6 Associao de Incluso na UML

Uma associao de incluso deve ser referenciada tambm na descrio do caso de uso
base. O local em que esse comportamento includo deve ser indicado na descrio do caso
de uso base, atravs de uma referncia explcita chamada ao caso de uso includo. Assim, a
descrio do fluxo de eventos (principal ou alternativo) do caso de uso base deve conter um
passo que envolva a chamada ao caso de uso includo, referenciada por Incluir nome do caso
de uso includo. Para destacar referncias de um caso de uso para outro, sugere-se que o
nome do caso de uso referenciado seja sublinhado e escrito em itlico.

105
No exemplo do caixa automtico, todos os trs casos de uso tm em comum uma

poro que diz respeito validao inicial do carto. Neste caso, um relacionamento de
incluso deve ser empregado, conforme mostra a Figura 5.7.
Figura 5.7 - Diagrama de Casos de Uso Caixa Automtico com Incluso.

O caso de uso Validar Carto extrai o comportamento descrito na Figura 5.8. Ao
isolar este comportamento no caso de uso de Validar Cliente, o caso de uso Efetuar Saque
passaria a apresentar a descrio mostrada na Figura 5.9.
Deve-se observar que no necessariamente o comportamento do caso de uso includo
precisa ser executado todas as vezes que o caso de uso base realizado. Assim, possvel que
a incluso esteja associada a alguma condio. O caso de uso includo inserido em um local
especfico dentro da sequncia do caso de uso base, da mesma forma que uma subrotina
chamada de um local especfico dentro de outra subrotina (BLAHA; RUMBAUGH, 2006).

106
Nome: Validar Carto

1.
2.
3.
4.
5.
O cliente insere o carto no caixa automtico.

O caixa automtico analisa o carto e verifica se ele aceitvel.
O caixa automtico solicita que o cliente informe a senha.
O cliente informa a senha.
O caixa automtico envia os dados do carto e da senha para o sistema bancrio
para validao.
efetuada.
5a Senha incorreta:
1 a 5: Cancelamento: O cliente solicita o cancelamento da transao e a transao
abortada.
Figura 5.8 Descrio do Caso de Uso Validar Carto
Nome: Efetuar Saque
1.
2.
3.
4.
5.
Incluir Validar Carto.

O cliente seleciona a opo saque.
O caixa automtico solicita que seja informada a quantia.
O cliente informa a quantia a ser sacada.
O caixa automtico envia uma requisio para o sistema bancrio para que seja
6. As notas so preparadas e liberadas.
6a - No h dinheiro suficiente disponvel no caixa eletrnico: Uma mensagem de erro
Figura 5.9 Descrio do Caso de Uso Efetuar Saque com incluso.
Por fim, importante frisar que no h um consenso sobre a possibilidade (ou no) de
um caso de uso includo poder ser utilizado isoladamente. Diversos autores, dentre eles Oliv
(2007) e Blaha e Rumbaugh (2006), admitem essa possibilidade; outros no. Em (BOOCH;
RUMBAUGH; JACOBSON, 2006), diz-se explicitamente que um caso de uso includo

107
nunca permanece isolado, mas apenas instanciado como parte de alguma base maior que o
inclui. Neste texto, admitimos a possibilidade de um caso de uso includo poder ser utilizado
isoladamente, pois isso permite representar situaes em que um caso de uso chama outro
caso de uso (como uma chamada de subrotina), mas este ltimo pode tambm ser realizado
isoladamente. A Figura 5.10 ilustra uma situao bastante comum, em que, ao se realizar um
processo de negcio (no caso a reserva de um carro em um sistema de locao de
automveis), caso uma informao necessria para esse processo (no caso o cliente) no
esteja disponvel, ela pode ser inserida no sistema. Contudo, o cadastro da informao
tambm pode ser feito dissociado do processo de negcio que o inclui (no caso, o cliente pode
se cadastrar fora do contexto da reserva de um carro). Ao no se admitir a possibilidade de um
caso de uso includo poder ser utilizado isoladamente, no possvel modelar situaes desta
natureza, as quais so bastante frequentes.
Figura 5.10 Exemplo de Associao de Incluso.
5.4.2 - Extenso
Uma associao de extenso entre um caso de uso de extenso e um caso de uso base
significa que o comportamento definido no caso de uso de extenso pode ser inserido dentro
do comportamento definido no caso de uso base, em um local especificado indiretamente pelo
caso de uso de extenso. A extenso ocorre em um ou mais pontos de extenso especficos
definidos no caso de uso base. A extenso pode ser condicional. Neste caso, a extenso ocorre
apenas se a condio verdadeira quando o ponto de extenso especificado atingido. O caso
de uso base definido de forma independente do caso de uso de extenso e significativo
independentemente do caso de uso de extenso (OLIV, 2007; BOOCH; RUMBAUGH;
JACOBSON, 2006).
Um caso de uso pode ter vrios pontos de extenso e esses pontos so referenciados
por seus nomes (BOOCH; RUMBAUGH; JACOBSON, 2006). O caso de uso base apenas
indica seus pontos de extenso. O caso de uso de extenso especifica em qual ponto de
extenso ele ser inserido. Por isso, diz-se que o caso de uso de extenso especifica
indiretamente o local onde seu comportamento ser inserido.
A associao de extenso como uma relao de incluso olhada da direo oposta,
em que a extenso se incorpora ao caso de uso base, em vez de o caso de uso base incorporar
explicitamente a extenso. Ela conecta um caso de uso de extenso a um caso de uso base. O
caso de uso de extenso geralmente um fragmento, ou seja, ele no aparece sozinho como
uma sequncia de comportamentos. Alm disso, na maioria das vezes, a relao de extenso
possui uma condio associada e, neste caso, o comportamento de extenso ocorre apenas se a
condio for verdadeira. O caso de uso base, por sua vez, precisa ser, obrigatoriamente, um
caso de uso vlido na ausncia de quaisquer extenses (BLAHA; RUMBAUGH, 2006).

108
Na UML, a associao de extenso entre casos de uso mostrada como uma

dependncia (seta pontilhada) estereotipada com a palavra chave extend, partindo do caso de
uso de extenso para o caso de uso base, como ilustra a Figura 5.11. Pontos de extenso
podem ser indicados no compartimento da elipse do caso de uso, denominado extension
points (pontos de extenso). Opcionalmente, a condio a ser satisfeita e a referncia ao
ponto de extenso podem ser mostradas por meio de uma nota12 anexada associao de
extenso (OLIV, 2007). Assim, no exemplo da Figura 5.11, o Caso de Uso de Extenso 1
executado quando o ponto de extenso 1 do Caso de Uso Base for atingido, se a condio for
verdadeira.
Figura 5.11 Associao de Extenso na UML

Uma importante diferena entre as associaes de incluso e extenso que, na
primeira o caso de uso base est ciente do caso de uso de incluso, enquanto na segunda o
caso de uso base no est ciente dos possveis casos de uso de extenso (OLIV, 2007).
Assim como no caso da incluso, uma associao de extenso deve ser referenciada na
descrio do caso de uso base. Neste caso, contudo, o caso de uso base apenas aponta o ponto
de extenso, sem fazer uma referncia explcita ao caso de uso de extenso. O local de cada
um dos pontos de extenso deve ser indicado na descrio do caso de uso base, atravs de
uma referncia ao nome do ponto de extenso seguido de : ponto de extenso. Assim, a
descrio do fluxo de eventos (principal ou alternativo) do caso de uso base deve conter
indicaes explcitas para cada ponto de extenso.
No exemplo do caixa automtico, suponha que se deseja coletar dados estatsticos
sobre os valores das notas entregues nos saques, de modo a permitir alimentar o caixa
eletrnico com as notas mais adequadas para saque. Poder-se-ia, ento, estender o caso de uso
Efetuar Saque, de modo que, quando necessrio, outro caso de uso, denominado Coletar
Estatsticas de Notas, contasse e acumulasse o tipo das notas entregues em um saque,
conforme mostra a Figura 5.12. A Figura 5.13 mostra a descrio do caso de uso Efetuar
Saque indicando o ponto de extenso entrega do dinheiro.
12
Nota o nico item de anotao da UML. Notas so usadas para explicar partes de um modelo da UML. So
comentrios includos para descrever, esclarecer ou fazer alguma observao sobre qualquer elemento do
modelo. Assim, uma nota apenas um smbolo para representar restries e comentrios anexados a um
elemento ou a uma coleo de elementos. Graficamente, uma nota representada por um retngulo com um dos
cantos com uma dobra de pgina, acompanhado por texto e anexada ao(s) elemento(s) anotados por meio de
linha(s) pontilhada(s) (BOOCH; RUMBAUGH; JACOBSON, 2006). No exemplo da Figura 5.11, a nota est
anexada ao relacionamento de extenso, adicionando-lhe informaes sobre o ponto de extenso e a condio
associados extenso.

109
Figura 5.12 - Diagrama de Casos de Uso Caixa Automtico com Extenso.

Nome: Efetuar Saque
1.
2.
3.
4.
5.
Incluir Validar Carto.

O cliente seleciona a opo saque.
O caixa automtico solicita que seja informada a quantia.
O cliente informa a quantia a ser sacada.
O caixa automtico envia uma requisio para o sistema bancrio para que seja
6. As notas so preparadas.
entrega do dinheiro: ponto de extenso.
7. As notas so liberadas
6a - No h dinheiro suficiente disponvel no caixa eletrnico: Uma mensagem de erro
Figura 5.13 Descrio do Caso de Uso Efetuar Saque com extenso.

110
5.4.3 Generalizao / Especializao

Um relacionamento de generalizao / especializao entre um caso de uso pai e um
caso de uso filho significa que o caso de uso filho herda o comportamento e o significado do
caso de uso pai, acrescentando ou sobrescrevendo seu comportamento (OLIV, 2007;
BOOCH; RUMBAUGH; JACOBSON, 2006). Na UML, relacionamentos de generalizao /
especializao so representados como uma linha cheia direcionada com uma seta aberta
(smbolo de herana), como ilustra a Figura 5.14.
Figura 5.14 Associao de Generalizao / Especializao entre Casos de Uso na UML

Voltando ao exemplo do sistema de caixa automtico, suponha que haja duas formas
adotadas para se validar o carto: a primeira atravs de senha, como descrito anteriormente, e
a segunda por meio de anlise da retina do cliente. Neste caso, poderiam ser criadas duas
especializaes do caso de uso Validar Cliente, como mostra a Figura 5.15.
Figura 5.15 Exemplo de Generalizao / Especializao entre Casos de Uso

A descrio do caso de uso pai teria de ser generalizada para acomodar diferentes tipos
de validao. Esses tipos de validao seriam especializados nas descries dos casos de uso
filhos. A Figura 5.16 mostra as descries desses trs casos de uso.
A generalizao / especializao aplicvel quando um caso de uso possui diversas
variaes. O comportamento comum pode ser modelado como um caso de uso abstrato e
especializado para as diferentes variaes (BLAHA; RUMBAUGH, 2006). Contudo, avalie se
no fica mais simples e direto descrever essas variaes como fluxos alternativos variantes na
descrio de casos de uso. Quando forem poucas e pequenas as variaes, muito
provavelmente ser mais fcil captur-las na descrio, ao invs de criar hierarquias de casos
de uso. A Figura 5.17 mostra uma soluo anloga da Figura 5.16, sem usar, no entanto,
especializaes do caso de uso.

111
Nome: Validar Carto

1. O cliente insere o carto no caixa automtico.
2. O caixa automtico analisa o carto e verifica se ele aceitvel.
3. O caixa automtico solicita informao para identificao do cliente.
4. O cliente informa sua identificao.
5. O caixa automtico envia os dados do carto e da identificao para o sistema
bancrio para validao.
efetuada.
5a Dados de Identificao Incorretos:
abortada.
Nome: Validar Carto por Anlise de Retina
3. O caixa automtico solicita que o cliente se posicione corretamente para a captura
da imagem da retina.
4. O caixa automtico retira uma foto da retina do cliente.
5. O caixa automtico envia os dados do carto e a foto da retina para o sistema
Nome: Validar Carto por Autenticao de Senha
3. O caixa automtico solicita a senha.
4. O cliente informa a senha.
5. O caixa automtico envia os dados do carto e a senha para o sistema bancrio
para validao.
Figura 5.16 Descrio do Caso de Uso Validar Carto e suas Especializaes.

112
Nome: Validar Carto

1. O cliente insere o carto no caixa automtico.
2. O caixa automtico analisa o carto e verifica se ele aceitvel.
3. Validar carto.
efetuada.
Fluxos de Eventos Variantes
3a Validar carto por autenticao de senha:
3a.1 O caixa automtico solicita a senha.
3a.2 O cliente informa a senha.
3a.3 O caixa automtico envia os dados do carto e a senha para o sistema
3b Validar carto por anlise de retina:
3b.1 O caixa automtico solicita que o cliente se posicione corretamente para a
captura da imagem da retina.
3b.2 O caixa automtico retira uma foto da retina do cliente.
3b.3 O caixa automtico envia os dados do carto e a foto da retina para o
sistema bancrio para validao.
5a Dados de Identificao Incorretos:
abortada.
Figura 5.17 Descrio do Caso de Uso Validar Carto com Variantes.

113
5.4.4 Diretrizes para o Uso dos Tipos de Relacionamentos entre Casos de Uso
Os relacionamentos entre casos de uso devem ser utilizados com cuidado para evitar a
introduo de complexidade desnecessria. As seguintes orientaes so teis para ajudar a
decidir quando usar relacionamentos entre casos de uso em um diagrama de casos de uso:
A incluso tipicamente aplicvel quando se deseja capturar um fragmento de

comportamento comum a vrios casos de uso. Na maioria das vezes, o caso de uso
de incluso uma atividade significativa, mas no como um fim em si mesma
(BLAHA; RUMBAUGH, 2006). Ou seja, o caso de uso de incluso no precisa ser
uma transao completa.
Um relacionamento de incluso empregado quando h uma poro de

comportamento que similar ao longo de um ou mais casos de uso e no se deseja
repetir a sua descrio. Para evitar redundncia e assegurar reso, extrai-se essa
descrio e se compartilha a mesma entre diferentes casos de uso.Desta maneira,
utiliza-se a incluso para evitar ter de descrever o mesmo fragmento de
comportamento vrias vezes, capturando o comportamento comum em um caso de
uso prprio (BOOCH; RUMBAUGH; JACOBSON, 2006).
No se deve utilizar o relacionamento de generalizao / especializao para

compartilhar fragmentos de comportamento. Para este propsito, deve-se usar a
relao de incluso (BLAHA; RUMBAUGH, 2006).
A relao de extenso bastante til em situaes em que se pode definir um caso

de uso significativo com recursos adicionais. O comportamento bsico capturado
no caso de uso base e os recursos adicionais nos casos de uso de extenso. Use a
relao de extenso quando o sistema puder ser usado em diferentes configuraes,
algumas com os recursos adicionais e outras sem eles (BLAHA; RUMBAUGH,
2006).
Tanto a incluso quanto a extenso podem ser usadas para dividir o

comportamento em partes menores. A incluso, entretanto, implica que o
comportamento includo uma parte necessria de um sistema configurado,
mesmo que seu comportamento no seja executado todas as vezes, ou seja, mesmo
que o comportamento includo esteja associado a uma condio. A extenso, por
sua vez, implica que o sistema sem o comportamento adicionado pela extenso
significativo (BLAHA; RUMBAUGH, 2006).
5.5 Trabalhando com Casos de Uso

Para se utilizar a modelagem de casos de uso para o refinamento de requisitos de
usurio em requisitos de sistema necessrio proceder um exame detalhado do processo de
negcio a ser apoiado pelo sistema. Assim, atividades de levantamento de requisitos, como
entrevistas, observao, workshop de requisitos e cenrios, dentre outras, certamente
acontecero em paralelo com a modelagem de casos de uso.
Uma boa maneira de trabalhar com casos de uso consiste em, a partir dos requisitos
funcionais de usurio descritos no Documento de Requisitos, procurar derivar casos de uso.
Este apenas um ponto de partida, uma vez que vrios casos de uso podem ser derivados a
partir de um mesmo requisito funcional de usurio.

114
Uma maneira complementar de identificar casos de uso comear pela identificao

de atores. Cada ator deve ter um propsito nico e coerente, o qual deve ser descrito e
documentado. Para cada ator identificado, pode-se, ento, levantar quais so as
funcionalidades por ele requeridas, listando-as na forma de casos de uso. Cada caso de uso
deve representar uma transao completa que seja algo de valor para os atores envolvidos.
Contudo, antes de identificar atores e casos de uso, necessrio determinar claramente os
limites do sistema. Sem deixar claro quais so os limites do sistema, muito difcil identificar
atores ou casos de uso (BLAHA; RUMBAUGH, 2006).
Uma vez identificados atores e casos de uso, pode-se elaborar uma verso preliminar
do diagrama de casos de uso. Vale lembrar que, at mesmo para sistemas de pequeno porte,
til trabalhar com subsistemas, procurando agrupar casos de uso em pacotes. Assim,
importante procurar agrupar casos de uso relacionados em pacotes, construindo tambm
diagramas de pacotes medida que os casos de uso vo sendo agrupados.
Uma vez identificados e agrupados os casos de uso, interessante fazer uma descrio
sucinta de seu propsito. No se deve partir diretamente para os detalhes, descrevendo fluxos
de eventos e outras informaes. Fazendo apenas uma descrio sucinta, possvel levar mais
rapidamente os casos de uso discusso com os clientes e usurios, permitindo identificar
melhor quais so efetivamente os casos de uso a serem contemplados pelo sistema. Alm
disso, pode-se dividir o trabalho, designando diferentes analistas para trabalhar com casos de
uso (ou pacotes) especficos.
Somente ento se deve passar para a descrio detalhada dos casos de uso.
Inicialmente, o foco deve ser no fluxo de eventos principal, ou seja, aquele em que tudo d
certo na interao. Depois de descrever o fluxo de eventos normal, deve-se analisar de forma
crtica cada passo desses fluxos de eventos, procurando verificar o que pode dar errado
(WAZLAWICK, 2004), bem como se devem investigar maneiras alternativas, ainda normais,
de realizar o caso de uso, permitindo a identificao de fluxos variantes. A partir da
identificao de possveis excees e variaes, deve-se trabalhar na descrio de fluxos
alternativos de exceo (descrevendo procedimentos para contornar os problemas) e variantes
(descrevendo maneiras alternativas de realizar com sucesso uma certa poro do caso de uso).
Assim, uma maneira adequada para trabalhar com casos de uso consiste em identificlos, model-los e descrev-los com diferentes nveis de preciso. O seguinte processo resume
a abordagem descrita anteriormente:
1. Listar atores e casos de uso relacionados: neste momento, montada apenas uma
lista dos atores associados aos casos de uso de seu interesse. Apenas o nome do
caso de uso indicado.
2. Para cada caso de uso identificado, fazer uma descrio sucinta do mesmo. Essa
descrio deve conter, em essncia, o objetivo do caso de uso.
3. Elaborar um ou mais diagramas de casos de uso.
4. Revisar a exatido e a completude do conjunto de casos de uso com os
interessados e priorizar os casos de uso.
5. Definir o formato de descrio de caso de uso a ser usado (e o correspondente
modelo de descrio de caso de uso a ser adotado) para cada caso de uso.

115
6. Definir os fluxos de eventos principais a serem comportados pelo caso de uso: de

maneira anloga ao passo 1, apenas uma lista dos fluxos de eventos principais
elaborada, sem descrev-los ainda.
7. Descrever cada um dos fluxos principais de eventos do caso de uso, segundo o
modelo de descrio de caso de uso estabelecido no passo anterior. De acordo com
o modelo predefinido, levantar informaes adicionais como pr-condies e
requisitos relacionados.
8. Identificar fluxos alternativos: neste momento, levantada apenas uma lista de
excees e variaes que podem ocorrer no fluxo principal de eventos do caso de
uso, sem no entanto definir como o sistema deve trat-las.
9. Descrever os passos dos fluxos alternativos: descrever como o sistema deve
responder a cada exceo ou como ele deve funcionar em cada variao.
Vale ressaltar que a descrio de casos de uso na fase de anlise de requisitos deve ser
feita sem considerar a tecnologia de interface. Neste momento no interessa saber a forma das
interfaces do sistema, mas quais informaes so trocadas entre o sistema e o ambiente
externo (atores). O analista deve procurar abstrair a tecnologia e se concentrar na essncia das
informaes trocadas. Assim, diz-se que a descrio de caso de uso na fase de anlise uma
descrio essencial. A tecnologia de interface ser objeto da fase de projeto do sistema.
Agindo dessa maneira, abre-se caminho para se pensar em diferentes alternativas de interfaces
durante o projeto do sistema (WAZLAWICK, 2004).
Uma tcnica de levantamento de requisitos bastante til para apoiar a escrita de casos
de uso so os cenrios. Pode-se pedir para que o usurio descreva alguns cenrios na forma de
exemplos situados de um caso de uso em ao, mostrando o ator usando o sistema para
realizar o caso de uso em questo (COCKBURN, 2005).
Um cenrio uma sequncia especfica de aes que ilustra o comportamento de um
caso de uso. Assim, os cenrios so, na verdade, instncias de um caso de uso.
Os modelos de casos de uso so uma maneira eficaz para analistas, clientes,
especialistas de domnio e usurios chegarem a uma compreenso comum acerca das
funcionalidades que o sistema deve prover. Alm disso, servem para ajudar a verificar e
validar o sistema medida que ele vai sendo desenvolvido. Neste contexto, os casos de uso
podem ser utilizados como base para o projeto de casos de teste para o sistema, em uma
abordagem de testes baseada em casos de uso, na qual casos de teste so projetados a partir
dos fluxos de eventos principal e alternativos dos casos de uso, procurando explorar diferentes
cenrios de uso do sistema.
No contexto da Engenharia de Requisitos, casos de uso tm dois importantes papis:
Casos de uso especificam os requisitos funcionais de um sistema. Um modelo de

caso de uso descreve detalhadamente o comportamento de um sistema atravs de um
conjunto de casos de uso. O ambiente do sistema definido pela descrio dos
diferentes atores que utilizam o sistema realizando os casos de uso.
Casos de uso oferecem uma abordagem para a modelagem de sistemas. Para

gerenciar a complexidade de sistemas reais, comum apresentar os modelos do
sistema em um nmero de diferentes vises. Em uma abordagem guiada por casos
de uso, pode-se construir uma viso para cada caso de uso, isto , em cada viso so
modelados apenas aqueles elementos que participam de um caso de uso especfico.

116
Essa abordagem especialmente til para a modelagem comportamental feita

utilizando diagramas de atividade e de sequncia. Um particular elemento (uma
classe, p.ex.) pode, claro, participar de vrios casos de uso. Isto significa que um
modelo do sistema completo s visto atravs de um conjunto de vises. Para se
definir todas as responsabilidades de um elemento, deve-se olhar os casos de uso
onde esse elemento tem um papel.
importante destacar que a modelagem casos de uso pode (e deve) ser realizada com
algum grau de paralelismo em relao modelagem conceitual estrutural. A identificao de
conceitos relevantes para tratar um caso de uso pode ajudar a descobrir outros casos de uso
relevantes, sobretudo de natureza cadastral. Assim, uma vez iniciada a descrio dos casos de
uso, a modelagem conceitual estrutural pode ser tambm iniciada.
Alm de serem uma ferramenta essencial na especificao dos requisitos funcionais de
um sistema, casos de uso tm um papel fundamental no planejamento e controle de projetos
iterativos. Casos de uso podem ser usados para definir o escopo de uma iterao do projeto ou
mesmo do projeto como um todo. Neste contexto, uma tcnica interessante para administrar
discusses de escopo so as listas dentro / fora (COCKBURN, 2005). Uma lista dentro / fora
, na verdade, uma tabela com trs colunas. A primeira coluna enumera casos de uso; as duas
outras colunas so rotuladas Dentro e Fora. Sempre que no for claro se um caso de uso
est dentro ou fora do escopo da discusso (projeto ou iterao), ele includo na tabela e
deve-se perguntar aos interessados se o caso de uso est dentro ou fora do escopo. Assim,
possvel capturar as diferentes vises dos diferentes interessados, sendo essas vises muitas
vezes conflitantes. Identificados conflitos, os mesmos devem ser negociados e resolvidos.
Ainda no que se refere ao planejamento e controle de projetos iterativos, pode ser uma
boa estratgia priorizar os casos de uso, de modo a definir o que considerar ou no em uma
iterao (ou mesmo no projeto). Para os casos de uso considerados dentro do escopo do
projeto, pode-se indicar em qual verso o caso de uso deveria ser tratado. Por exemplo, se
foram planejados trs iteraes para o desenvolvimento de um certo sistema, os interessados
poderiam indicar em qual verso (1, 2 ou 3) cada caso de uso deveria ser tratado. Essas listas
de prioridades so usadas como ponto de partida para a negociao e o planejamento das
iteraes do projeto.
Os captulos 7 e 8 de (BLAHA; RUMBAUGH, 2006) Modelagem de Interaes e
Modelagem Avanada de Interaes, respectivamente abordam a modelagem de casos de
uso. Mais especificamente, recomenda-se a leitura da seo 7.1 (Modelos de Casos de Uso),
que d uma viso geral de atores, casos de uso e diagramas de casos de uso, e da seo 8.1
(Relaes entre Casos de Uso), que discute as relaes de incluso, extenso e generalizao
e especializao entre casos de uso.
O Captulo 15 de (OLIV, 2007) Use Cases d uma viso geral da modelagem de
casos de uso, discutindo de maneira breve, mas bastante didtica, os conceitos de ator e de
caso de uso, a especificao de casos de uso e os relacionamentos entre casos de uso.
O livro Escrevendo Casos de Uso Eficazes: Um guia prtico para desenvolvedores
de software (COCKBURN, 2005) inteiramente dedicado ao processo de escrita de casos de
uso. Esse livro uma tima referncia para os interessados em aperfeioar seu processo de
escrita de casos de uso, contendo diversas diretrizes incorporadas nestas notas de aula.

117
Em (WAZLAWICK, 2004), tanto o Captulo 2 (Concepo) quanto o Captulo 3

(Expanso dos Casos de Uso) abordam a modelagem de casos de uso.
Em (BOOCH; RUMBAUGH; JACOBSON, 2006), merecem ateno os captulos 17
(Casos de Uso) e 18 (Diagramas de Casos de Uso). As notaes da UML para diagramas de
casos de uso so tratadas com mais detalhes do que nas demais referncias citadas
anteriormente, precisamente por se tratar este de um livro sobre a UML.
Elsevier, 2006.
Editora, 2006.
COCKBURN, A., Escrevendo Casos de Uso Eficazes: Um guia prtico para desenvolvedores
de software, Porto Alegre: Bookman, 2005.
Elsevier, 2004.

118

Um modelo conceitual estrutural uma abstrao da realidade segundo uma
conceituao. Ele pode ser usado para comunicao, aprendizado e anlise de aspectos
relevantes do domnio subjacente (GUIZZARDI, 2005). O modelo conceitual estrutural de um
sistema tem por objetivo descrever as informaes que esse sistema deve representar e
gerenciar.
A modelagem conceitual a atividade de descrever alguns dos aspectos do mundo
fsico e social a nossa volta, com o propsito de entender e comunicar. Os modelos resultantes
das atividades de modelagem conceitual so essencialmente destinados a serem usados por
pessoas e no por mquinas (MYLOPOULOS, 1992). Assim, modelos conceituais devem ser
concebidos com foco no domnio do problema e no no domnio da soluo e, por
conseguinte, um modelo conceitual estrutural um artefato do domnio do problema e no do
domnio da soluo. As informaes a serem capturadas em um modelo conceitual estrutural
devem existir independentemente da existncia de um sistema computacional para trat-las.
Assim, o modelo conceitual deve ser independe da soluo computacional a ser adotada para
resolver o problema e deve conter apenas os elementos de informao referentes ao domnio
do problema em questo. Elementos da soluo, tais como interfaces, formas de
armazenamento e comunicao, devem ser tratados apenas na fase de projeto
(WAZLAWICK, 2004).
Uma vez que requisitos no-funcionais de produto (atributos de qualidade) so
inerentes soluo computacional, geralmente eles no so tratados na modelagem
conceitual. Ou seja, no se consideram elementos de informao para tratar aspectos como
desempenho, segurana de acesso, confiabilidade, formas de armazenamento etc. Esses
atributos de qualidade do produto so considerados posteriormente, na fase de projeto.
Os elementos de informao bsicos da modelagem conceitual estrutural so os tipos
de entidades e os tipos de relacionamentos. A identificao de quais os tipos de entidades e os
tipos de relacionamentos que so relevantes para um particular sistema de informao uma
meta crucial da modelagem conceitual (OLIV, 2007).
Na modelagem conceitual segundo o paradigma orientado a objetos, tipos de entidades
so modelados como classes. Tipos de relacionamentos so modelados como atributos e
associaes. Assim, o propsito da modelagem conceitual estrutural orientada a objetos
definir as classes, atributos e associaes que so relevantes para tratar o problema a ser
resolvido. Para tal, as seguintes tarefas devem ser realizadas:
Identificao de Classes
Identificao de Atributos e Associaes
Especificao de Hierarquias de Generalizao/Especializao

119
importante notar que essas atividades so dependentes umas das outras e que,
durante o desenvolvimento, elas so realizadas, tipicamente, de forma paralela e iterativa,
sempre visando ao entendimento do domnio do problema, desconsiderando aspectos de
implementao.
Este captulo aborda a modelagem conceitual estrutural, discutindo os principais
aspectos dessa importante tarefa, quando realizada segundo o paradigma orientado a objetos.
A Seo 6.1 discute o processo de identificao de classes. A Seo 6.2 aborda a identificao
de atributos e associaes. Finalmente, a Seo 6.3 discute a especificao de hierarquias de
generalizao / especializao.
6.1 Identificao de Classes

Classificao o meio pelo qual os seres humanos estruturam a sua percepo do
mundo e seu conhecimento sobre ele. Sem ela, no possvel nem entender o mundo a nossa
volta nem agir sobre ele. Classificao assume a existncia de tipos e de objetos a serem
classificados nesses tipos. Classificar consiste, ento, em determinar se um objeto ou no
uma instncia de um tipo. A classificao nos permite estruturar conhecimento sobre as coisas
em dois nveis: tipos e instncias. No nvel de tipos, procuramos encontrar as propriedades
comuns a todas as instncias de um tipo. No nvel de instncia, procuramos identificar o tipo
do qual o objeto uma instncia e os valores particulares das propriedades desse objeto
(OLIV, 2007).
Tipos de entidade so um dos mais importantes elementos em modelos conceituais.
Definir os tipos de entidade relevantes para um particular sistema de informao uma tarefa
crucial na modelagem conceitual. Um tipo de entidade pode ser definido como um tipo cujas
instncias em um dado momento so objetos individuais identificveis que se consideram
existir no domnio naquele momento. Um objeto pode ser instncia de vrios tipos ao mesmo
tempo (OLIV, 2007). Por exemplo, seja o caso dos tipos Estudante e Funcionrio em um
sistema de uma universidade. Uma mesma pessoa, por exemplo Joo, pode ser ao mesmo
tempo um estudante e um funcionrio dessa universidade.
Na orientao a objetos, tipos de entidade so representados por classes, enquanto as
instncias de um tipo de entidade so objetos. Assim, uma atividade crucial da modelagem
conceitual estrutural segundo o paradigma orientado a objetos (OO) a identificao de
classes. Na UML, classes so representadas por um retngulo com trs compartimentos: o
compartimento superior relativo ao nome da classe; o compartimento do meio dedicado
especificao dos atributos da classe; e o compartimento inferior dedicado especificao
das operaes da classe. A Figura 6.1 mostra a notao de classe na UML.
Figura 6.1 Notao de Classes na UML.

Para nomear classes, sugere-se iniciar com um substantivo no singular, o qual pode ser
combinado com complementos ou adjetivos, omitindo-se preposies. O nome da classe deve
ser iniciado com letra maiscula, bem como os nomes dos complementos, sem dar um espao

120
em relao palavra anterior. Acentos no devem ser utilizados. Ex.: Cliente, PessoaFisica,
ItemPedido.
Tomando por base os requisitos iniciais do usurio e, sobretudo, o modelo de casos de
uso, possvel iniciar o trabalho de modelagem da estrutura do sistema. Esse trabalho comea
com a descoberta de quais classes devem ser includas no modelo. O cerne de um modelo OO
exatamente o seu conjunto de classes.
Durante a anlise de requisitos, tipicamente o analista estuda, filtra e modela o
domnio do problema. Dizemos que o analista filtra o domnio, pois apenas uma parte desse
domnio far parte das responsabilidades do sistema. Assim, um domnio de problemas pode
incluir vrias informaes, mas as responsabilidades de um sistema nesse domnio podem
incluir apenas uma pequena parcela deste conjunto.
As classes de um modelo representam a expresso inicial do sistema. As atividades
subsequentes da modelagem estrutural buscam obter uma descrio cada vez mais detalhada,
em termos de associaes e atributos. Contudo, deve-se observar que, medida que atributos
e associaes vo sendo identificados, se ganha maior entendimento a respeito do domnio e
naturalmente novas classes surgem. Assim, as atividades da modelagem conceitual so
iterativas e com alto grau de paralelismo, devendo ser realizadas concomitantemente.
Um aspecto fundamental no processo de modelagem conceitual a interao constante
com os especialistas de domnio. Tcnicas de levantamento de requisitos, tais como
entrevistas, anlise de documentos e reunies JAD, tm um papel fundamental nesta etapa.
Assim, o levantamento de requisitos continua acontecendo paralelamente modelagem
conceitual.
Conforme apontado anteriormente, dois importantes insumos para a atividade de
identificao de classes so o Documento de Requisitos e o Modelo de Casos de Uso. Uma
maneira bastante prtica e eficaz de trabalhar a identificao de classes consiste em olhar
esses dois documentos, em especial a descrio do minimundo e as descries de casos de
uso, procura de classes.
Diversos autores, dentre eles Jacobson (1992) e Wazlawick (2004), sugerem que uma
boa estratgia para identificar classes consiste em ler esses documentos procurando por
substantivos. Esses autores argumentam que uma classe , tipicamente, descrita por um nome
no domnio e, portanto, aprender sobre a terminologia do domnio do problema um bom
ponto de partida. Ainda que um bom ponto de partida, essa heurstica ainda muito vaga. Se
o analista segui-la fielmente, muito provavelmente ele ter uma extensa lista de potenciais
classes, sendo que muitas delas podem, na verdade, se referir a atributos de outras classes.
Alm disso, pode ser que importantes classes no sejam capturadas, notadamente aquelas que
se referem ao registro de eventos de negcio, uma vez que esses eventos muitas vezes so
descritos na forma de verbos. Seja o seguinte exemplo de uma descrio de um domnio de
locao de automveis: clientes locam carros. Seriam consideradas potenciais classes:
Cliente e Carro. Contudo, a locao um evento de negcio importante que precisa ser
registrado e, usando a estratgia de identificar classes a partir de substantivos, Locao no
entraria na lista de potenciais classes.
Assim, neste texto sugere-se que, ao examinar documentos de requisitos e modelos de
casos de uso, os seguintes elementos sejam considerados como candidatos a classes:
Agentes: entidades do domnio do problema que tm a capacidade de agir com
inteno de atingir uma meta. Em sistemas de informao, h dois tipos principais

121
de agentes: os agentes fsicos (tipicamente pessoas) e os agentes sociais

(organizaes, unidades organizacionais, sociedades etc.). Em relao s pessoas,
deve-se olhar para os papis desempenhados pelas diferentes pessoas no domnio
do problema.
Objetos: entidades sem a capacidade de agir, mas que fazem parte do domnio de
informao do problema. Podem ser tambm classificados em fsicos (p.ex., carros,
livros, imveis) e sociais (p.ex., cursos, disciplinas, leis). Entretanto, h tambm
outros tipos de objetos, tais como objetos de carter descritivo usado para organizar
e descrever outros objetos de um domnio (p.ex., modelos de carro), algumas vezes
denominados objetos de especificao. Objetos sociais e de descrio (ou
especificao) tendem a ser coisas menos tangveis, mas so to importantes para a
modelagem conceitual quanto os objetos fsicos.
Eventos: representam a ocorrncia de aes no domnio do problema que precisam
ser registradas e lembradas pelo sistema. Eventos acontecem no tempo e, portanto,
a representao de eventos normalmente envolve a necessidade de registrar, dentre
outros, quando o evento ocorreu (ponto no tempo ou intervalo de tempo). Deve-se
observar que muitos eventos ocorrem no domnio do problema, mas grande parte
deles no precisa ser lembrada. Para capturar os eventos que precisam ser
lembrados e, portanto, registrados, devem-se focalizar os principais eventos de
negcio do domnio do problema. Assim, em um sistema de locao de automveis,
so potenciais classes de eventos: Locao, Devoluo e Reserva. Por outro lado, a
ocorrncia de eventos cadastrais, tais como os cadastros de clientes e carros, tende a
ser de pouca importncia, no sendo necessrio lembrar a ocorrncia desses
eventos.
Seja qual for a estratgia usada para identificar classes, sempre importante que o
analista tenha em mente os objetivos do sistema durante a modelagem conceitual. No se
devem representar informaes irrelevantes para o sistema e, portanto, a relevncia para o
sistema o principal critrio a ser adotado para decidir se um determinado elemento deve ou
no ser includo no modelo conceitual estrutural do sistema.
O resultado principal da atividade de identificao de classes a obteno de uma lista
de potenciais classes para o sistema em estudo. Um modelo conceitual estrutural para uma
aplicao complexa pode ter dezenas de classes e, portanto, pode ser necessrio definir uma
representao concisa capaz de orientar um leitor em um modelo desta natureza. O
agrupamento de classes em subsistemas serve basicamente a este propsito, podendo ser til
tambm para a organizao de grupos de trabalho em projetos extensos. Conforme discutido
no Captulo 5, a base principal para a identificao de subsistemas a complexidade do
domnio do problema. Atravs da identificao e agrupamento de classes em subsistemas,
possvel controlar a visibilidade do leitor e, assim, tornar o modelo mais compreensvel.
Assim, da mesma maneira que casos de uso so agrupados em pacotes, classes tambm
devem ser.
Quando uma coleo de classes colabora entre si para realizar um conjunto coeso de
responsabilidades (casos de uso), elas podem ser vistas como um subsistema. Assim, um
subsistema uma abstrao que prov uma referncia para mais detalhes em um modelo de
anlise, incluindo tanto casos de uso quanto classes. O agrupamento de classes em
subsistemas permite apresentar o modelo global em uma perspectiva mais alta. Esse nvel

122
ajuda o leitor a rever o modelo, bem como constitui um bom critrio para organizar a
documentao.
Uma vez identificadas as potenciais classes, deve-se proceder uma avaliao para
decidir o que efetivamente considerar ou rejeitar. Conforme discutido anteriormente, a
relevncia para o sistema deve ser o critrio principal. Alm desse critrio, os seguintes
tambm devem ser considerados nessa avaliao:
Estrutura complexa: o sistema precisa tratar informaes sobre os objetos da
classe? Tipicamente, uma classe deve ter, pelo menos, dois atributos. Se uma classe
apresentar apenas um atributo, avalie se no melhor trat-la como um atributo de
uma classe existente13.
Atributos e associaes comuns: os atributos e as associaes da classe devem ser
aplicveis a todas as suas instncias, isto , a todos os objetos da classe.
Classes no redundantes: duas classes so redundantes quando elas tm sempre a
mesma populao14. Seja o exemplo de um modelo conceitual que tenha as classes
Pessoa e Funcionrio. Se o sistema est interessado apenas nas pessoas empregadas
na organizao (ou seja, funcionrios), ento a populao dessas duas classes ser
sempre a mesma. A introduo de classes redundantes afeta a simplicidade do
modelo e, portanto, melhor no incluir tais classes em um modelo conceitual.
Existncia de instncias: toda classe deve possuir uma populao no vazia. Uma
potencial classe que possui uma nica instncia tambm no deve ser considerada
em um modelo conceitual estrutural. Tipicamente uma classe possui vrias
instncias e a populao da classe varia ao longo do tempo.
6.2 Identificao de Atributos e Associaes

Conforme apontado anteriormente, uma classe tpica de um modelo conceitual
estrutural deve apresentar estrutura complexa. A estrutura de uma classe corresponde a seus
atributos e associaes.
Conceitualmente, no h diferena entre atributos e associaes. Atributos so, na
verdade, tipos de relacionamentos binrios. Em um tipo de relacionamento binrio, h dois
participantes. Em alguns tipos de relacionamentos, esses participantes so considerados
colegas, porque eles desempenham funes anlogas e nenhum deles subordinado ao
outro. Seja o caso do tipo de relacionamento aluno cursa um curso. Um aluno s aluno se
cursar um curso. Por outro lado, no faz sentido existir um curso se ele no puder ser cursado
por alunos. A ordem dos participantes no modelo no implica uma relao de prioridade ou
subordinao entre eles (OLIV, 2007). Na orientao a objetos, esse tipo de relacionamento
modelado como uma associao.
Entretanto, h alguns tipos de relacionamentos nos quais usurios e analistas
consideram um participante como sendo uma caracterstica do outro. Seja o exemplo do tipo
de relacionamento filme possui gnero. Algum pode argumentar que o participante gnero
uma caracterstica de filme e, portanto, subordinado a este. Esse tipo de relacionamento
13
Uma classe que possui um nico atributo, mas vrias associaes, tambm satisfaz a esse critrio.
A populao de uma classe em um dado momento o conjunto de instncias que existem no domnio naquele
momento (OLIV, 2007).
14

123
modelado como um atributo. Assim, um atributo um tipo de relacionamento binrio em que

um participante considerado uma caracterstica de outro. Por conseguinte, um atributo
igual a uma associao, exceto pelo fato de usurios e analistas adicionarem a interpretao
que um dos participantes subordinado ao outro (OLIV, 2007).
De uma perspectiva mais prtica, atributos podem ser vistos como informaes
alfanumricas ligadas a um conceito. Associaes, por sua vez, consistem em um tipo de
informao que liga diferentes conceitos entre si (WAZLAWICK, 2004). Atributos ligam
classes do domnio do problema a tipos de dados.
Tipos de dados podem ser primitivos ou especficos de domnio. Os tipos de dados
primitivos so aplicveis aos vrios domnios e sistemas, tais como strings, datas, inteiros e
reais, e so considerados como sendo predefinidos. Os tipos de dados especficos de um
domnio de aplicao, por outro lado, precisam ser definidos. So exemplos de tipos de dados
especficos: CPF, ISBN de livros, endereo etc.
Neste texto so considerados os seguintes tipos de dados primitivos:
String: cadeia de caracteres;
boolean: admite apenas os valores verdadeiro e falso;
Integer (ou int): nmeros inteiros;
Float (ou float): nmeros reais;
Currency: valor em moeda (reais, dlares etc.);
Date: datas, com informao de dia, ms e ano;
Time: horas em um dia, com informao de hora, minuto e segundo;
DateTime: combinao dos dois anteriores;
YearMonth: informao de tempo contendo apenas ms e ano;
Year: informao de tempo contendo apenas ano.
6.2.1 Atributos
Um atributo uma informao de estado para a qual cada objeto em uma classe tem o
seu prprio valor. Os atributos adicionam detalhes s abstraes e so apresentados na parte
central do smbolo de classe.
Conforme discutido anteriormente, atributos possuem um tipo de dado, que pode ser
primitivo ou especfico de domnio. Ao identificar um atributo como sendo relevante, deve-se
definir qual o seu tipo de dado. Caso nenhum dos tipos de dados primitivos se aplique, devese definir, ento, um tipo de dados especfico. Por exemplo, em domnios que lidem com
livros, necessrio definir o tipo ISBN15, cujas instncias so ISBNs vlidos. Em domnios
que lidem com pessoas fsicas e jurdicas, CPF e CNPJ tambm devem ser definidos como
tipos de dados especficos. Usar um tipo de dados primitivo nestes casos, tais como String ou
15
O ISBN - International Standard Book Number - um sistema internacional padronizado que identifica
numericamente os livros segundo o ttulo, o autor, o pas, a editora, individualizando-os inclusive por edio.
Utilizado tambm para identificar software, seu sistema numrico pode ser convertido em cdigo de barras.

124
int, insuficiente, pois no so quaisquer cadeias de caracteres ou nmeros que se

caracterizam como ISBNs, CPFs ou CNPJs vlidos.
Tipos de dados especficos podem apresentar propriedades. Por exemplo, CPF um
nmero de 11 dgitos, que pode ser dividido em duas partes: os 9 primeiros dgitos e os dois
ltimos, que so dgitos verificadores.
Um tipo de dados especial a enumerao. Na enumerao, os valores do tipo so
enumerados explicitamente na forma de literais, como o caso do tipo DiaSemana, que
tipicamente definido como um tipo de dados compreendendo sete valores: Segunda, Tera,
Quarta, Quinta, Sexta, Sbado e Domingo. importante observar que tipos de dados
enumerados s devem ser usados quando se sabe priori quais so os seus valores e eles so
fixos. Assim, so bons candidatos a tipos enumerados informaes como sexo (M/F), estado
civil, etc.
Tipos de dados geralmente no so representados graficamente em um modelo
conceitual estrutural, de modo a torn-lo mais simples. Na maioria das situaes, basta
descrever os tipos de dados especficos de domnio no Dicionrio de Dados do Projeto.
Contudo, se necessrio, eles podem ser representados graficamente usando o smbolo de
classe estereotipado com a palavra chave <<dataType>>. Tipos enumerados tambm podem
ser representados usando o smbolo de classe, mas com o esteretipo <<enumeration>>,
sendo que ao invs de apresentar atributos de um tipo de dados, enumeram-se os valores
possveis da enumerao. A Figura 6.2 ilustra a notao de tipos de dados na UML.
Figura 6.2 Notao de Tipos de Dados na UML.

Uma dvida tpica e recorrente na modelagem estrutural se um determinado item de
informao deve ser modelado como uma classe ou como um atributo. Para que o item seja
considerado uma classe, ele tem de passar nos critrios de incluso no modelo discutidos na
seo anterior. Entretanto, h alguns itens de informao que passam nesses critrios, mas que
ainda assim podem ser melhor modelados como atributos, tendo como tipo um tipo de dado
complexo, especfico de domnio. Um atributo deve capturar um conceito atmico, i.e., um
nico valor ou um agrupamento de valores fortemente relacionados que sirva para descrever
outro objeto. Alm disso, para que um item de estrutura complexa seja modelado como um
atributo, ele deve ser compreensvel pelos interessados simplesmente pelo seu nome.
bom realar que, com o tempo, as classes do domnio do problema tendem a
permanecer relativamente estveis, enquanto os atributos provavelmente se alteram. Atributos
podem ser bastante volteis, em funo de alteraes nas responsabilidades do sistema.
muito importante lembrar tambm que, uma vez que atributos e associaes so
tipos de relacionamentos, no devemos incluir na lista de atributos de uma classe, atributos
representando associaes (ou atributos representando chaves estrangeiras como a classe

125
fosse uma tabela de um banco de dados relacional). Associaes j tm sua presena indicada
pela notao de associao, ou seja, pelas linhas que conectam as classes que se relacionam.
Um aspecto bastante importante na especificao de atributos a escolha de nomes.
Deve-se procurar utilizar o vocabulrio tpico do domnio do problema, usando nomes
legveis e abrangentes. Para nomear atributos, sugerem-se nomes iniciando com substantivo, o
qual pode ser combinado com complementos ou adjetivos, omitindo-se preposies. O nome
do atributo deve ser iniciado com letra minscula, enquanto os nomes dos complementos
devem iniciar com letras maisculas, sem dar um espao em relao palavra anterior.
Acentos no devem ser utilizados. Atributos monovalorados devem iniciar com substantivo
no singular (p.ex., nome, razaoSocial), enquanto atributos multivalorados devem iniciar com
o substantivo no plural (p.ex., telefones).
A sintaxe de atributos na UML, em sua forma plena, a seguinte (BOOCH;
RUMBAUGH; JACOBSON, 2006):
visibilidade nome: tipo [multiplicidade] = valorInicial {propriedades}
A visibilidade de um atributo indica em que situaes esse atributo visvel por outras
classes. Na UML h quatro nveis de visibilidade, os quais so marcados pelos seguintes
smbolos:
+ pblico : o atributo pode ser acessado por qualquer classe;
# protegido: o atributo s passvel de acesso pela prpria classe ou por uma de suas
especializaes;
- privado: o atributo s pode ser acessado pela prpria classe;
~ pacote: o atributo s pode ser acessado por classes declaradas dentro do mesmo
pacote da classe a que pertence o atributo.
A informao de visibilidade inerente fase de projeto e no deve ser expressa em
um modelo conceitual. Assim, em um modelo conceitual, atributos devem ser especificados
sem nenhum smbolo antecedendo o nome.
O tipo indica o tipo de dado do atributo, o qual deve ser um tipo de dado primitivo ou
um tipo de dado especfico de domnio. Tipos de dados especficos de domnio devem ser
definidos no Dicionrio de Dados do Projeto.
A multiplicidade a especificao do intervalo permitido de itens que o atributo pode
abrigar. O padro que cada atributo tenha um e somente um valor para o atributo. Quando
um atributo for opcional ou quando puder ter mais do que uma ocorrncia, a multiplicidade
deve ser informada, indicando o valor mnimo e o valor mximo, da seguinte forma:
valor_mnimo .. valor_mximo
A seguir, so dados alguns exemplos:
nome: String instncias da classe tm obrigatoriamente um e somente um nome.
carteira: String [0..1] instncias da classe tm uma ou nenhuma carteira.
telefones: Telefone [0..*] instncias da classe tm um ou vrios telefones.
pessoasContato: String [2] instncias da classe tm exatamente duas pessoas de

contato.

126
Um atributo pode ter um valor padro inicial, ou seja, um valor que, quando no
informado outro valor, ser atribudo ao atributo. O campo valorInicial descreve exatamente
este valor. O exemplo abaixo ilustra o uso de valor inicial.
origem: Ponto = (0,0) a origem, quando no informado outro valor, ser o ponto (0,0)
Finalmente, podem ser indicadas propriedades dos atributos. Uma propriedade que
pode ser interessante mostrar em um modelo conceitual a propriedade readonly, a qual
indica que o valor do atributo no pode ser alterado aps a inicializao do objeto. No
exemplo abaixo, est-se indicando que o valor do atributo numeroSocio de um scio de um
clube no pode ser alterado.
numSocio: int {readonly}
Alm das informaes tratadas na declarao de um atributo seguindo a sintaxe da
UML, outras informaes de domnio, quando pertinentes, podem ser adicionadas no
Dicionrio de Dados do Projeto, tais como unidade de medida, intervalo de valores possveis,
limite, preciso etc.
6.2.2 Associaes
Uma associao um tipo de relacionamento que ocorre entre instncias de duas ou
mais classes. Assim como classes, associaes so tipos. Ou seja, uma associao modela um
tipo de relacionamento que pode ocorrer entre instncias das classes envolvidas. Uma
instncia de uma associao (dita uma ligao) conecta instncias especficas das classes
envolvidas na associao. Seja o exemplo de um domnio em que clientes efetuam pedidos.
Esse tipo de relacionamento pode ser modelado como uma associao Cliente efetua Pedido.
Seja Pedro uma instncia de Cliente e Pedido100 uma instncia de Pedido. Se foi Pedro quem
efetuou o Pedido100, ento a ligao (Pedro, Pedido100) uma instncia da associao
Cliente efetua Pedido.
Associaes podem ser nomeadas. Neste texto sugere-se o uso de verbos conjugados,
indicando o sentido de leitura. Ex.: Cliente (classe) efetua > (associao) Locao (classe).
Cada classe envolvida na associao desempenha um papel, ao qual pode ser dado um nome.
Cada classe envolvida na associao possui tambm uma multiplicidade16 nessa associao,
que indica quantos objetos podem participar de uma instncia dessa associao. A notao da
UML tipicamente usada para representar associaes em um modelo conceitual ilustrada na
Figura 6.3.
Figura 6.3 Notao de Associaes na UML.

Na ilustrao da figura, um objeto da Classe1 se relaciona com no mnimo c e no
mximo d objetos da Classe2. J um objeto da Classe2 se relaciona com no mnimo a e no
mximo b objetos da Classe1. Objetos da Classe1 desempenham o papel de papelClasse1
16
Multiplicidades em uma associao so anlogas s multiplicidades em atributos e especificam as quantidades

mnima e mxima de objetos que podem participar da associao. Quando nada for dito, o padro 1..1 como no
caso de atributos. Contudo, para deixar os modelos claros, recomenda-se sempre especificar explicitamente as
multiplicidades das associaes.

127
nesta associao, enquanto objetos da Classe2 desempenham o papel de papelClasse2 nessa

mesma associao.
importante, neste ponto, frisar a diferena entre sentido de leitura (ou direo do
nome) de uma associao com a navegao da associao. O sentido de leitura diz apenas em
que direo ler o nome da associao, mas nada diz sobre a navegabilidade da associao. A
navegabilidade (linha de associao com seta direcionada) usada para limitar a navegao
de uma associao a uma nica direo e um recurso a ser usado apenas na fase de projeto.
Em um modelo conceitual, todas as associaes so no direcionais, ou seja, navegveis nos
dois sentidos.
Ainda que nomes de associaes e papis sejam opcionais, recomenda-se us-los para
tornar o modelo mais claro. Alm disso, h algumas situaes em que fica invivel ler um
modelo se no houver a especificao do nome da associao ou de algum de seus papis.
Seja o exemplo da Figura 6.4. Em uma empresa, um empregado est lotado em um
departamento e, opcionalmente, pode chefi-lo. Um departamento, por sua vez, pode ter
vrios empregados nele lotados, mas apenas um chefe. Sem nomear essas associaes, o
modelo fica confuso. Rotulando os papis e as associaes, o modelo torna-se muito mais
claro. Na figura 6.4, um departamento exerce o papel de departamento de lotao do
empregado e, neste caso, um empregado tem um e somente um departamento de lotao. No
outro relacionamento, um empregado exerce o papel de chefe e, portanto, um departamento
possui um e somente um chefe.
Figura 6.4 Exemplo: Nomeando Associaes.

Ao contrrio das classes e dos atributos que podem ser encontrados facilmente a partir
da leitura dos textos da descrio do minimundo e das descries de casos de uso, muitas
vezes, as informaes sobre associaes no aparecem to explicitamente. Casos de uso
descrevem aes de interao entre atores e sistema e, por isso, acabam mencionando
principalmente operaes. Operaes transformam a informao, passando um objeto de um
estado para outro, por meio da alterao dos seus valores de atributos e associaes. Uma
associao, por sua vez, uma relao esttica que pode existir entre duas classes. Assim, as
descries de casos de uso esto repletas de operaes, mas no de associaes
(WAZLAWICK, 2004).
Contudo, conforme discutido na seo anterior, h alguns eventos que precisam ter sua
ocorrncia registrada e, portanto, so tipicamente mapeados como classes. Esses eventos esto
descritos nos casos de uso e podem ter sido capturados como associaes. Seja o exemplo de
uma concessionria de automveis. Neste domnio, clientes compram carros, como ilustra a
parte (a) da Figura 6.5. Contudo, a compra um evento importante para o negcio e precisa
ser registrado. Neste caso, como ilustra a parte (b) da Figura 6.5, a compra deve ser tratada
como uma classe e no como uma associao.

128
Figura 6.5 Exemplo: Associao x Classe de Evento Lembrado.

Deve-se notar pelo exemplo acima que o evento representado por uma classe,
enquanto as associaes continuam representando relacionamentos estticos entre as classes e
no operaes ou transformaes (WAZLAWICK, 2004). Assim, deve-se tomar cuidado com
a representao de eventos como associaes, questionando sempre se aquela associao
relevante para o sistema em questo.
Seja o exemplo da Figura 6.6. Nesse exemplo, o caso de uso aponta que funcionrios
so responsveis por cadastrar livros em uma biblioteca. Seria necessrio, pois, criar uma
associao Funcionrio cadastra Livro no modelo estrutural? A resposta, na maioria dos
casos, no. Apenas se explicitamente expresso pelo cliente em um requisito que necessrio
saber exatamente qual funcionrio fez o cadastro de um dado livro (o que muito improvvel
de acontecer), que tal relao deveria ser considerada. Mesmo se houver a necessidade de
auditoria de uso do sistema (requisito no funcional relativo segurana), no h a
necessidade de modelar esta associao, pois requisitos no funcionais no devem ser
considerados no modelo conceitual, uma vez que solues bastante distintas do uso dessa
associao poderiam ser adotadas.
Figura 6.6 Exemplo: Associao x Caso de Uso.

Na modelagem conceitual fundamental saber a quantidade de objetos que uma
associao admite em cada um de seus papis, o que capturado pelas multiplicidades da
associao. Esta informao bastante dependente da natureza do problema e do real
significado da associao (o que se quer representar efetivamente), especialmente no que se
refere associao representar apenas o presente ou o histrico (WAZLAWICK, 2004).
Retomemos o exemplo da Figura 6.4, no qual se diz que um empregado est lotado em
um departamento e, opcionalmente, pode chefi-lo. Para definir precisamente as
multiplicidades, necessrio investigar os seguintes aspectos: Um empregado pode mudar de

129
lotao? Se sim, necessrio registrar apenas a lotao atual ou necessrio registrar o

histrico de lotaes dos empregados (ou seja, registrar o evento de lotao de um empregado
em um departamento)? Um departamento pode, ao longo do tempo, mudar de chefe? Se sim,
necessrio registrar o histrico de chefias do departamento (ou seja, registrar o evento de
nomeao do chefe do departamento)?
Como colocado no modelo da Figura 6.4, est-se representando apenas a situao
presente. Se houver mudana de chefe de um departamento ou do departamento de lotao de
um empregado, perder-se- a informao histrica. Na maioria das vezes, essa no uma
soluo aceitvel. Na maioria dos domnios, as pessoas querem saber a informao histrica.
Assim, nota-se que parte das responsabilidades do sistema registrar a ocorrncia dos eventos
de nomeao do chefe e de lotao de empregados. Assim, um modelo mais fidedigno a essa
realidade o modelo da Figura 6.7, o qual introduz as classes do tipo evento lembrado
NomeacaoChefia e Lotacao.
Figura 6.7 Registrando Histricos.

Ainda que este modelo seja mais fidedigno realidade, ele ainda apresenta problemas.
Por exemplo, o modelo diz que um empregado pode ter uma ou mais locaes. Mas o
empregado pode ter mais de uma lotao vigente? O mesmo vale para o caso da nomeao de
chefia. Um empregado pode ser chefe de mais de um departamento ao mesmo tempo? Um
departamento pode ter mais do que um chefe nomeado ao mesmo tempo? Infelizmente, o
modelo incapaz de responder a essas perguntas. Para eliminar essas ambiguidades,
necessrio capturar regras de negcio do tipo restries de integridade. No exemplo acima, as
seguintes regras se aplicam:
Um empregado s pode estar lotado em um nico departamento em um dado

momento.
Um empregado s pode estar designado como chefe de um nico departamento em

um dado momento.
Um departamento s pode ter um empregado designado como chefe em um dado

momento.
Observe que, como um departamento pode ter vrios empregados nele lotados ao
mesmo tempo, no necessrio escrever uma restrio de integridade, pois este o caso mais
geral (sem restrio). Assim, restries de integridade devem ser escritas apenas para as
associaes que so passveis de restries.

130
Restries de integridade so regras de negcio e poderiam ser lanadas no

Documento de Requisitos. Contudo, como elas so importantes para a compreenso e
eliminao de ambiguidades do modelo conceitual, til descrev-las no prprio modelo
conceitual.
Alm das restries de integridade relativas s multiplicidades n, diversas outras
restries podem ser importantes para tornar o modelo mais fiel realidade. Ainda no
exemplo da Figura 6.7, poder-se-ia querer dizer que um empregado s pode ser nomeado
como chefe de um departamento, se ele estiver lotado nesse departamento. Restries deste
tipo so comuns em pores fechadas de um diagrama de classes. Assim, toda vez que se
detectar uma poro fechada em um diagrama de classes, vale a pena analis-la para avaliar se
h ali uma restrio de integridade ou no. Havendo, deve-se escrev-la.
Restries de integridade tambm podem falar sobre atributos das classes. Por
exemplo, a data da portaria de nomeao de um empregado e como chefe de um departamento
d deve ser igual ou posterior data da portaria de lotao do empregado e no departamento d.
Geralmente, restries de integridade so escritas em linguagem natural, uma vez que
no so passveis de modelagem grfica. Contudo, conforme j discutido anteriormente, o uso
de linguagem natural pode levar a ambiguidades. Visando suprir essa lacuna na UML, o
OMG17 incorporou ao padro uma linguagem para especificao formal de restries, a OCL
(Object Constraint Language). Contudo, restries escritas em OCL dificilmente sero
entendidas por clientes e usurios, o que dificulta a validao das mesmas. Assim, neste texto,
sugere-se escrever as restries de integridade em linguagem natural mesmo.
Vale ressaltar que a UML prov alguns mecanismos para representar restries de
integridade em um modelo grfico. As prprias multiplicidades so uma forma de capturar
restries de integridade (ditas restries de integridade de cardinalidade). Alm das
multiplicidades, a UML prov o recurso de restries, as quais so representadas entre chaves
({restrio}). Restries podem ser usadas, dentre outros, para restringir a ocorrncia de
associaes. Seja o seguinte exemplo: em uma concessionria de automveis compras podem
ser financiadas ou por financeiras ou por bancos. Para capturar essa restrio, pode-se usar a
restrio xor da UML, como ilustra a Figura 6.8.
Figura 6.8 Restrio XOR entre Associaes.

Nesta figura, uma compra ou est relacionada a um banco ou a uma financeira. No
possvel que uma compra esteja associada aos dois ao mesmo. Como as multiplicidades
mnimas do lado de banco e financeira so zero, uma compra pode no ser financiada.
17
Object Management Group (http://www.omg.org/) uma organizao internacional que gerencia padres
abertos relativos ao desenvolvimento orientado a objetos, dentre eles a UML.

131
Ainda em relao s multiplicidades, vale frisar que associaes muitos-para-muitos so

perfeitamente legais em um modelo orientado a objetos, como ilustra o exemplo da Figura
6.9. Nesse exemplo, est-se dizendo que disciplinas podem possuir vrios pr-requisitos e
podem ser pr-requisitos para vrias outras disciplinas.
Figura 6.9 Associao Muitos-para-Muitos.

Deve-se observar, no entanto, que muitas vezes, uma associao muitos-para-muitos
oculta a necessidade de uma classe do tipo evento a ser lembrado. Seja o seguinte exemplo:
em uma organizao, empregados so alocados a projetos. Um empregado pode ser alocado a
vrios projetos, enquanto um projeto pode ter vrios empregados a ele alocados. Tomando por
base este fato, seria natural se chegar ao modelo da Figura 6.10(a). Contudo, se quisermos
registrar as datas de incio e fim do perodo em que o empregado esteve alocado ao projeto,
esse modelo insuficiente e deve ser alterado para comportar uma classe do tipo evento
lembrado Alocacao, como mostra a Figura 6.10(b).
Figura 6.10 Associao Muitos-para-Muitos e Classes de Evento Lembrado.

De fato, o problema por detrs do modelo da Figura 6.10(a) o mesmo anteriormente
discutido na Figura 6.7: a necessidade ou no de se representar informao histrica.
Contudo, de maneira mais abrangente, pode-se pensar que, se uma associao apresenta
atributos, melhor trat-la como uma nova classe. Seja o seguinte exemplo: em uma loja, um
cliente efetua um pedido, discriminando vrios produtos, cada um deles em uma certa
quantidade. O modelo da Figura 6.11(a) procura representar essa situao, mas uma questo
permanece em aberto: onde representar a informao da quantidade pedida de cada produto?
Essa informao no pode ficar em Produto, pois diferentes pedidos pedem quantidades
diferentes de um mesmo produto. Tambm no pode ficar em Pedido, pois um mesmo pedido
tipicamente especifica diferentes quantidades de diferentes produtos. De fato, quantidade no
nem um atributo da classe Pedido nem um atributo da classe Produto, mas sim um atributo
da associao especifica. Assim, uma soluo possvel introduzir uma classe ItemPedido,
reificando18 essa associao, como ilustra a Figura 6.11(b).
18
Reificar uma associao consiste em ver essa associao como uma classe. A palavra reificao vem da
palavra do latim res, que significa coisa. Reificao corresponde ao que em linguagem natural se chama
nominalizao, que basicamente consiste em transformar um verbo em um substantivo (OLIV, 2007).

132
Figura 6.11 Reificando uma Associao

A UML oferece uma primitiva de modelagem, chamada classe de associao, que
pode ser usada para tratar a reificao de associaes (OLIV, 2007). Uma classe de
associao pode ser vista como uma associao que tem propriedades de classe (BOOCH;
RUMBAUGH; JACOBSON, 2006). A Figura 6.12 mostra o exemplo anterior, sendo
modelado como uma classe de associao, segundo a notao da UML.
Figura 6.12 Notao da UML para Classes Associativas.

Classes associativas so ainda representaes de associaes. Assim como uma
instncia de uma associao, uma instncia de uma classe associativa um par ordenado
conectando duas instncias das classes envolvidas na associao. Assim, se Pedido100 uma
instncia de Pedido, Lpis uma instncia de Produto e o Pedido100 especifica 5 Lpis,
ento uma instncia de ItemPedido a tupla ((Pedido100, Lpis), 5).
Classes associativas podem ser usadas tambm para representar eventos cuja
ocorrncia precisa ser lembrada, como nos exemplos das figuras 6.7 e 6.10. Entretanto,
importante observar que o uso de classes associativas nesses casos pode levar a problemas de
modelagem. Seja o seguinte contexto: em um hospital, pacientes so tratados em unidades
mdicas. Um paciente pode ser tratado em diversas unidades mdicas diferentes, as quais
podem abrigar diversos pacientes sendo tratados. A Figura 6.13(a) mostra um modelo que
busca representar essa situao usando uma classe associativa. Como uma classe associativa,
as instncias de Tratamento so pares ordenados (Paciente, Unidade Mdica). Assim, cada
vez que um paciente tratado em uma unidade mdica diferente tem-se um tratamento. Esta
pode, contudo, no ser precisamente a concepo do problema original. Poder-se-ia imaginar
que um tratamento um tratamento de um paciente em vrias unidades mdicas. A classe de
associao no captura isso. Assim, um modelo mais fiel ao domnio aquele que representa
Tratamento como uma classe do tipo evento a ser lembrado e que est relacionada com
Paciente e Unidade Mdica da forma mostrada na Figura 6.13(b).

133
Figura 6.13 Classes Associativas x Classes do Tipo Evento a Ser Lembrado.

At o momento, todas as associaes mostradas foram associaes binrias, i.e.,
associaes envolvendo duas classes. Mesmo o exemplo da Figura 6.9 (Disciplina tem como
pr-requisito Disciplina) ainda uma associao binria, na qual a mesma classe desempenha
dois papis diferentes (disciplina que possui pr-requisito e disciplina que pr-requisito).
Entretanto, associaes n-rias so tambm possveis, ainda que bem menos corriqueiramente
encontradas. Uma associao ternria, por exemplo, envolve trs classes, como ilustra o
exemplo da Figura 6.14. Nesse exemplo, est-se dizendo que fornecedores podem fornecer
produtos para certos clientes.
Figura 6.14 Associao Ternria.

Na UML, associaes n-rias so mostradas como losangos conectados s classes
envolvidas na associao por meio de linhas slidas, como mostra a Figura 6.14. O nome da
associao colocado dentro ou em cima do losango, sem direo de leitura. Normalmente,
multiplicidades no so mostradas, dada a dificuldade de interpret-las.
Finalmente, algumas associaes podem ser consideradas mais fortes do que as outras,
no sentido de que elas, na verdade, definem um objeto como sendo composto por outros
(WAZLAWICK, 2004). Essas associaes todo-parte podem ser de dois tipos principais:
agregao e composio.
A composio o tipo mais forte de associao todo-parte. Ela indica que um objetoparte s pode ser parte de um nico todo. J a agregao no implica nessa exclusividade. Um
carro, por exemplo, tem como partes um motor e quatro ou cinco rodas. Motor e rodas, ao
serem partes de um carro, no podem ser partes de outros carros simultaneamente. Assim, esta

134
uma relao de composio, como ilustra a Figura 6.15(a). O exemplo da Figura 6.15(b)
ilustra o caso de comisses compostas por professores. Nesse caso, um professor pode
participar de mais de uma comisso simultaneamente e, portanto, trata-se uma relao de
agregao. Na UML, um losango branco na extremidade da associao relativa ao todo indica
uma agregao. J um losango preto indica uma composio.
Figura 6.15 Agregao e Composio.

Relaes todo-parte podem ser empregadas em situaes como:
Quando h clareza de que um objeto complexo composto de outros objetos

(componente de). Ex.: Motor um componente de um carro.
Para designar membros de colees (membro de). Ex.: Pesquisadores so membros

de Grupos de Pesquisa.
Muitas vezes pode ser difcil perceber a diferena entre uma agregao / composio e
uma associao comum. Quando houver essa dvida, melhor representar a situao usando
uma associao comum, tendo em vista que ela impe menos restries.
6.3 Especificao de Hierarquias de Generalizao / Especializao

Um dos principais mecanismos de estruturao de conceitos a generalizao /
especializao. Com este mecanismo possvel capturar similaridades entre classes,
dispondo-as em hierarquias de classes. No contexto da orientao a objetos, esse tipo de
relacionamento tambm conhecido como herana.
importante notar que a herana tem uma natureza bastante diferente das associaes.
Associaes representam possveis ligaes entre instncias das classes envolvidas. J a
relao de herana uma relao entre classes e no entre instncias. Ao se considerar uma
classe B como sendo uma subclasse de uma classe A est-se assumindo que todas as instncias
de B so tambm instncias de A. Assim, ao se dizer que a classe EstudanteGraduacao herda
da classe Estudante, est-se indicando que todos os estudantes de graduao so estudantes.
Em resumo, deve-se interpretar a relao de herana como uma relao de subtipo entre
classes. A Figura 6.16 mostra a notao da UML para representar herana.

135
Figura 6.16 Notao de Herana da UML.

A relao de herana aplicvel quando for necessrio fatorar os elementos de
informaes (atributos e associaes) de uma classe. Quando um conjunto de classes possuir
semelhanas e diferenas, ento elas podem ser organizadas em uma hierarquia de classes, de
forma a agrupar em uma superclasse os elementos de informao comuns, deixando as
especificidades nas subclasses.
De maneira geral, desnecessrio criar hierarquias de classes quando as
especializaes (subclasses) no tiverem nenhum elemento de informao diferente. Quando
isso ocorrer, normalmente suficiente criar um atributo tipo para indicar os possveis subtipos
da generalizao. Seja o caso de um domnio em que se faz distino entre clientes normais e
clientes especiais, dos quais se quer saber exatamente as mesmas informaes. Neste caso,
criar uma hierarquia de classes, como ilustra a Figura 6.17(a), desnecessrio. Uma soluo
como a apresentada na Figura 6.17(b), em que o atributo tipo pode ser de um tipo enumerado
com os seguintes valores {Normal, Especial}, modela satisfatoriamente o problema e mais
simples e, portanto, mais indicada.
Figura 6.17 Uso ou no de Herana.

136
Tambm no faz sentido criar uma hierarquia de classes em que a superclasse no tem
nenhum atributo ou associao. Informaes de estados pelos quais um objeto passa tambm
no devem ser confundidas com subclasses. Por exemplo, um carro de uma locadora de
automveis pode estar locado, disponvel ou em manuteno. Estes so estados e no subtipos
de carro.
De fato, interessante considerar alguns critrios para incluir uma subclasse (ou
superclasse) em um modelo conceitual. O principal deles o fato da especializao (ou
generalizao) estar dentro do domnio de responsabilidade do sistema. Apenas subclasses
(superclasses) relevantes para o sistema em questo devem ser consideradas. Alm desse
critrio bsico, os seguintes critrios devem ser usados para analisar hierarquias de herana:
Uma hierarquia de classes deve modelar relaes -um-tipo-de, ou seja, toda

subclasse deve ser um subtipo especfico de sua superclasse.
Uma subclasse deve possuir todas as propriedades (atributos e associaes)
definidas por suas superclasses e adicionar mais alguma coisa (algum outro
atributo ou associao).
Todas as instncias de uma subclasse tm de ser tambm instncias da superclasse.
Ateno especial deve ser dada nomeao de classes em uma hierarquia de classes.
Cada especializao deve ser nomeada de forma a ser auto-explicativa. Um nome apropriado
para a especializao pode ser formado pelo nome de sua superclasse, acompanhado por um
qualificador que descreve a natureza da especializao. Por exemplo, EstudanteGraduacao
para designar um subtipo de Estudante.
Hierarquias de classes no devem ser usadas de forma no criteriosa, simplesmente
para compartilhar algumas propriedades. Seja o caso de uma loja de animais, em que se deseja
saber as seguintes informaes sobre clientes e animais: nome, data de nascimento e
endereo. No faz nenhum sentido considerar que Cliente uma subclasse de Animal ou viceversa, apenas para reusar um conjunto de atributos que, coincidentemente, igual.
No que se refere modelagem de superclasses, deve-se observar se uma superclasse
concreta ou abstrata. Se a superclasse puder ter instncias prprias, que no so instncias de
nenhuma de suas subclasses, ento ela uma classe concreta. Por outro lado, se no for
possvel instanciar diretamente a superclasse, ou seja, se todas as instncias da superclasse so
antes instncias das suas subclasses, ento a superclasse abstrata. Classes abstratas so
representadas na UML com seu nome escrito em itlico e no devem herdar de classes
concretas.
Quando modeladas hierarquias de classes, necessrio posicionar atributos e
associaes adequadamente. Cada atributo ou associao deve ser colocado na classe mais
adequada. Atributos e associaes genricos, que se aplicam a todas as subclasses, devem ser
posicionados no topo da estrutura, de modo a serem aplicveis a todas as especializaes. De
maneira mais geral, se um atributo ou associao aplicvel a um nvel inteiro de
especializaes, ento ele deve ser posicionado na generalizao correspondente. Por outro
lado, se algumas vezes um atributo ou associao tiver um valor significativo, mas em outras
ele no for aplicvel, deve-se rever seu posicionamento ou mesmo a estrutura de
generalizao-especializao adotada.
Inevitavelmente, o processo detalhado de designar atributos e associaes a classes
conduz a um entendimento mais completo da hierarquia de herana do que era possvel em

137
um estgio anterior. Assim, deve-se esperar que o trabalho de reposicionamento de atributos e

associaes conduza a uma reviso da hierarquia de classes.
Por fim vale a pena mencionar que, durante anos, o mecanismo de herana foi
considerado o grande diferencial da orientao a objetos. Contudo, com o passar do tempo,
essa nfase foi perdendo fora, pois se percebeu que o uso da herana nem sempre conduz
melhor soluo de um problema de modelagem. Hoje a herana considerada apenas mais
uma ferramenta de modelagem, utilizada basicamente para fatorar informaes, as quais, de
outra forma, ficariam repetidas em diferentes classes (WAZLAWICK, 2004).
O livro Conceptual Modeling of Information Systems, de Antoni Oliv (OLIV,
2007) dedicado modelagem conceitual de sistemas. Esse livro uma tima referncia para
os interessados em se aperfeioar no trabalho de modelagem conceitual, contendo diversas
diretrizes incorporadas nestas notas de aula. Os captulos 2, 3, 4, 6, 7, 9 e 10 discutem,
respectivamente, tipos de entidades, tipos de relacionamentos, restries de cardinalidade,
reificao de associaes, tipos genricos de relacionamentos (incluindo relaes todo parte),
restries de integridade e relaes de generalizao / especializao.
O Captulo 5 de (WAZLAWICK, 2004) Modelagem Conceitual d uma viso
geral da modelagem estrutural, discutindo de maneira bastante didtica, diversos de seus
aspectos.
(Classes), 5 (Relacionamentos), 8 (Diagramas de Classes), 9 (Classes Avanadas) e 10
(Relacionamentos Avanados). As notaes da UML para diagramas de classes so tratadas
com mais detalhes do que nas demais referncias citadas anteriormente, precisamente por se
tratar este de um livro sobre a UML.
Editora, 2006.
GUIZZARDI, G., Ontological Foundations for Structural Conceptual Models, Telematics
Instituut Fundamental Research Series, The Netherlands, 2005.
JACOBSON, I.; Object-Oriented Software Engineering, Addison-Wesley, 1992.
MYLOPOULOS, J., Conceptual Modeling and Telos, In: Conceptual Modeling,
Databases and CASE, Wiley, 1992.
Elsevier, 2004.

138

Um sistema de informao realiza aes. O efeito de uma ao pode ser uma alterao
em sua base de informao e/ou a comunicao de alguma informao ou comando para um
ou mais destinatrios. Um evento de requisio de ao (ou simplesmente uma requisio)
uma solicitao para o sistema realizar uma ao. O esquema comportamental de um sistema
visa especificar essas aes (OLIV, 2007).
Uma parte importante do modelo comportamental de um sistema o modelo de casos
de uso, o qual fornece uma viso das funcionalidades que o sistema deve prover. O modelo
conceitual estrutural define os tipos de entidades (classes) e de relacionamentos (atributos e
associaes) do domnio do problema que o sistema deve representar para poder prover as
funcionalidades descritas no modelo de casos de uso. Durante a realizao de um caso de uso,
atores geram eventos de requisio de aes para o sistema, solicitando a execuo de alguma
ao. O sistema realiza aes e ele prprio pode gerar outras requisies de ao.
necessrio, pois, modelar essas requisies de aes, as correspondentes aes a serem
realizadas pelo sistema e seus efeitos. Este o propsito da modelagem dinmica.
Em uma abordagem orientada a objetos, requisies de ao correspondem a
mensagens trocadas entre objetos. As aes propriamente ditas e seus efeitos so tratados
pelas operaes das classes19. Assim, a modelagem dinmica est relacionada com as trocas
de mensagens entre objetos e a modelagem das operaes das classes.
Os diagramas de classes gerados pela atividade de modelagem conceitual estrutural
representam apenas os elementos estticos de um modelo de anlise orientada a objetos.
preciso, ainda, modelar o comportamento dinmico da aplicao. Para tal, necessrio
representar o comportamento do sistema como uma funo do tempo e de eventos especficos.
Um modelo de dinmico indica como o sistema ir responder a eventos ou estmulos externos
e auxilia o processo de descoberta das operaes das classes do sistema.
Para apoiar a modelagem da dinmica de sistemas, a UML oferece trs tipos de
diagramas (BOOCH; RUMBAUGH; JACOBSON, 2006):
19
Diagrama de Grfico de Estados: mostra uma mquina de estados que consiste

dos estados pelos quais objetos de uma particular classe podem passar ao longo de
seu ciclo de vida e as transies possveis entre esses estados, as quais so
resultados de eventos que atingem esses objetos. Diagramas de grfico de estados
(ou diagramas de transio de estados) so usados principalmente para modelar o
comportamento de uma classe, dando nfase ao comportamento especfico de seus
objetos.
De fato, abordagens distintas podem ser usadas, tal como representar tipos de requisies como classes, ditas
classes de evento, e os seus efeitos como operaes das correspondentes classes de evento, tal como faz Oliv
(2007).

139
Diagrama de Interao: descreve como grupos de objetos colaboram em certo

comportamento. Diagramas de interao podem ser de dois tipos: diagramas de
comunicao e diagramas de sequncia. Um diagrama de sequncia um diagrama
de interao que d nfase ordenao temporal das mensagens trocadas por
objetos. J um diagrama de comunicao d nfase organizao estrutural dos
objetos que enviam e recebem mensagens. Ambos so usados para ilustrar a viso
dinmica de um sistema.
Diagrama de Atividades: mostra o fluxo de uma atividade para outra em um

sistema, incluindo sequncias e ramificaes de fluxo, subatividades e objetos que
realizam e sofrem aes. Diagramas de atividades so usados principalmente para
a modelagem das funes de um sistema, dando nfase ao fluxo de controle na
execuo de um comportamento.
Diagramas de estados focalizam o comportamento de objetos de uma classe especfica.

Diagramas de interao e de atividades enfocam o fluxo de controle entre vrios objetos e
atividades. Enquanto os diagramas de interao do nfase ao fluxo de controle de um objeto
para o outro, os diagramas de atividade do nfase ao fluxo de controle de uma etapa
(atividade) para outra. Um diagrama de interao observa os objetos que passam mensagens;
um diagrama de atividades focaliza as atividades e suas entradas e sadas, i.e., objetos
passados de uma atividade para outra (BOOCH; RUMBAUGH; JACOBSON, 2006).
Este captulo aborda a modelagem dinmica, discutindo os principais aspectos dessa
importante tarefa, quando realizada segundo o paradigma orientado a objetos. So abordados
os diagramas de estados e os diagramas de atividades. Diagramas de interao no so
discutidos neste texto. A seo 7.1 discute os diferentes tipos de requisies de aes e como
os diagramas dinmicos da UML podem ser usados para model-los. A sees 7.2, 7.3 e 7.4
tratam, respectivamente, dos diagramas de transio de estados, diagramas de sequncia e
diagramas de atividades. A seo 7.4 aborda a especificao de operaes. Finalmente, a
seo 7.5 explora as relaes existentes entre os vrios modelos elaborados durante a anlise
de requisitos, as quais devem ser atentamente avaliadas durante a atividade de verificao de
requisitos.
7.1 Tipos de Requisies de Ao

Um sistema de informao mantm uma representao do estado do domnio em sua
base de informaes. Esse estado de coisas do domnio em um dado ponto no tempo
corresponde ao conjunto de instncias dos tipos de entidades (classes) e de relacionamentos
(associaes) relevantes que existem no domnio naquele momento. O esquema estrutural se
preocupa com essa perspectiva. Entretanto, o sistema tambm realiza aes. O efeito de uma
ao pode ser uma alterao em sua base de informao e/ou a comunicao de alguma
informao ou comando para um ou mais destinatrios. Um evento de requisio de ao (ou
simplesmente uma requisio) uma solicitao para que o sistema realize uma ao. Na
anlise de requisitos, assume-se que a tecnologia perfeita e, por conseguinte, que o sistema
executa as aes requisitadas instantaneamente (OLIV, 2007).
Dependendo de como so iniciadas, requisies podem ser explcitas, temporais ou
geradas. Uma requisio explcita iniciada explicitamente por um ator (requisio externa)
ou por uma outra ao (requisio induzida), como parte de seu efeito. Uma requisio
temporal iniciada pela passagem do tempo, ocorrendo independentemente do sistema. Por

140
fim, uma requisio gerada iniciada quando uma condio de gerao da requisio
satisfeita. O sistema detecta que a condio foi satisfeita e gera a correspondente requisio.
Por exemplo, em um sistema de controle de estoque, uma requisio de compra pode ser
gerada quando a quantidade mnima de um produto for atingida (OLIV, 2007).
A maioria das requisies externa. Dois importantes tipos de requisies externas
so notificaes de eventos de domnio e consultas. Uma consulta uma requisio externa
que prov alguma informao para o ator que iniciou a requisio. Consultas no alteram a
base de informaes do sistema. Uma notificao de evento de domnio uma requisio
externa cujo efeito uma mudana na base de informaes do sistema, correspondendo a um
evento de domnio. Nem todas as mudanas na base de informaes de um sistema so
admissveis. Os fatos nessa base mudam ao longo do tempo, mas no de maneira arbitrria.
Os eventos de domnio definem, exatamente, as mudanas admissveis. Por meio de
notificaes de eventos de domnio, atores dizem para o sistema que um evento de domnio
ocorreu (OLIV, 2007). Por exemplo, quando ocorre no mundo real o evento de reserva de
um carro em uma locadora de automveis, um usurio, ao realizar o caso de uso
correspondente (p.ex., Reservar Carro), est notificando o sistema que esse evento ocorreu, o
que inicia uma sequncia de aes (os passos do caso de uso), por meio da qual o sistema sabe
que o evento ocorreu no domnio.
Um evento de domnio corresponde a um conjunto no vazio de eventos estruturais,
percebido ou considerado como uma alterao nica no domnio. Um evento estrutural, por
sua vez, uma ao elementar que insere ou remove um fato na base de informaes do
sistema. H quatro tipos bsicos de eventos estruturais: insero de entidade, remoo de
entidade, insero de relacionamento e remoo de relacionamento. Esses eventos so ditos
estruturais, porque eles so completamente determinados pelo esquema conceitual estrutural e
no so explicitamente mostrados no esquema comportamental (OLIV, 2007).
No desenvolvimento orientado a objetos, os eventos estruturais correspondem a
operaes bsicas das classes. Assim, toda classe tem, implicitamente, operaes para: criar
objetos da classe (evento estrutural de insero de entidade), dita operao construtora da
classe; eliminar objetos (evento estrutural de remoo de entidade), dita operao destruidora
da classe; estabelecer ligaes e atribuir valores para atributos (eventos estruturais de insero
de relacionamentos); e remover ligaes ou excluir valores de atributos (eventos estruturais de
remoo de relacionamentos). Essas operaes so consideradas bsicas e no precisam ser
mostradas explicitamente no modelo conceitual.
Seja o exemplo de um sistema de controle de produtos, cujo modelo estrutural
parcialmente apresentado na Figura 7.1. Nesse exemplo, quando a companhia comea a
trabalhar com um novo produto (p.ex., Prod1), o estado do domnio se altera, caracterizando
um evento de domnio. Esse evento de domnio corresponde a cinco eventos estruturais, a
saber: (1) a criao do objeto Prod1, (2) a atribuio de um valor para o atributo codigo, (3) a
atribuio de um valor para o atributo valor, (4) a atribuio de um valor para o atributo
quantidadeEstoque e (5) o estabelecimento da associao fornece com seu fornecedor. Esse
novo produto considerado um evento de domnio, porque o conjunto de cinco eventos
estruturais que o compe visto como um evento nico. muito mais fcil para um usurio
dizer ao sistema que o evento de domnio ocorreu do que dizer explicitamente cada um dos
eventos estruturais.

141
Figura 7.1 Fragmento do Modelo Estrutural de um Sistema de Controle de Produtos.

Cada evento de domnio possui um conjunto de eventos estruturais, chamado de efeito
do evento. A correspondncia entre eventos e seus efeitos dada por uma expresso de
mapeamento. O efeito do evento pode ser definido segundo duas abordagens: a abordagem de
ps-condio e a abordagem procedimental. Na abordagem de ps-condio, o efeito de um
evento definido por uma condio da base de informaes do sistema que deve ser satisfeita
aps a aplicao do efeito do evento. Na abordagem procedimental, o efeito de um evento
definido por um procedimento, indicando os eventos estruturais que compem o evento de
domnio (OLIV, 2007). Neste texto, enfocamos apenas a abordagem procedimental.
Na abordagem procedimental, quando o paradigma orientado a objetos adotado, o
efeito de um evento definido como uma operao de uma classe. O corpo dessa operao
deve ser tal que sua execuo produza o conjunto de eventos estruturais que compe o evento
de domnio. A execuo dessa operao vai deixar a base de informaes em um novo estado,
o qual deve satisfazer a todas as restries estticas (definidas no modelo estrutural). Assim,
durante a definio da operao correspondente ao efeito de um evento de domnio, devem-se
levar em conta as restries capturadas no modelo estrutural e garantir que o novo estado da
base de informaes do sistema vai satisfazer a todas elas. Em outras palavras, os eventos de
domnio do esquema comportamental devem estar consistentes com o esquema estrutural
(OLIV, 2007).
A ideia de efeito de um evento de domnio estende-se, na verdade, para quaisquer
requisies. Ou seja, o efeito de uma requisio pode ser representado por meio de uma
operao, de maneira anloga ao descrito anteriormente para eventos de domnio.
No que concerne a consultas, na modelagem conceitual define-se apenas o contedo
de informao das respostas, abstraindo-se detalhes que dizem respeito ao formato e a
caractersticas de dispositivos de sada (OLIV, 2007). Para que as informaes de atributos e
associaes possam ser recuperadas para serem mostradas como parte das respostas a
consultas, as classes precisam prover operaes bsicas para obter essas informaes. Assim
como as demais operaes bsicas, assume-se que toda classe possui implicitamente
operaes para se obter os valores correntes de seus atributos e associaes.
Durante a realizao de um caso de uso, atores geram requisies para o sistema,
solicitando a execuo de aes. O sistema realiza aes e ele prprio pode gerar outras
requisies de ao. O conjunto de casos de uso tem de ser consistente com o conjunto de
requisies definidas no esquema comportamental do sistema.
7.2 - Diagramas de Grfico de Estados

Todo objeto tem um tempo de vida. Na criao, o objeto nasce; na destruio, ele
deixa de existir. Entre esses dois momentos, um objeto poder interagir com outros objetos,
enviando e recebendo mensagens (BOOCH; RUMBAUGH; JACOBSON, 2006). Essas
interaes representam o comportamento do objeto e ele pode ser varivel ao longo do ciclo

142
de vida do objeto. Ou seja, muitas vezes, o comportamento dos objetos de uma classe depende
do estado em que o objeto se encontra em um dado momento. Nestes casos, til especificar
o comportamento usando uma mquina de estados.
Classes com estados (ou classes modais) so classes cujas instncias podem mudar de
um estado para outro ao longo de sua existncia, mudando possivelmente sua estrutura, seus
valores de atributos ou comportamento dos mtodos (WAZLAWICK, 2004).
Classes modais podem ser modeladas como mquinas de estados finitos. Uma
mquina de estados finitos uma mquina que, em um dado momento, est em um e somente
um de um nmero finito de estados (OLIV, 2007). Os estados de uma mquina de estados de
uma classe modal correspondem s situaes relevantes em que as instncias dessa classe
podem estar durante sua existncia. Um estado considerado relevante quando ele ajuda a
definir restries ou efeitos dos eventos.
Em qualquer estado, uma mquina de estados pode receber estmulos. Quando a
mquina recebe um estmulo, ela pode realizar uma transio de seu estado corrente (dito
estado origem) para outro estado (dito estado destino), sendo que se assume que as transies
so instantneas. A definio do estado destino depende do estado origem e do estmulo
recebido. Alm disso, os estados origem e destino em uma transio podem ser o mesmo.
Neste caso, a transio dita uma autotransio (OLIV, 2007).
Diagramas de Transies de Estados so usados para modelar o comportamento de
instncias de uma classe modal na forma de uma mquina de estados. Todas as instncias da
classe comportam-se da mesma maneira. Em outras palavras, cada diagrama de estados
construdo para uma nica classe, com o objetivo de mostrar o comportamento ao longo do
tempo de vida de seus objetos. Diagramas de estados descrevem os possveis estados pelos
quais objetos da classe podem passar e as alteraes dos estados como resultado de eventos
(estmulos) que atingem esses objetos. Uma mquina de estado especifica a ordem vlida dos
estados pelos quais os objetos da classe podem passar ao longo de seu ciclo de vida. A Figura
7.2 mostra a notao bsica da UML para diagramas de grfico de estados.
Figura 7.2 - Notao Bsica da UML para Diagramas de Grfico de Estados.

Um estado uma situao na vida de um objeto durante a qual o objeto satisfaz
alguma condio, realiza alguma atividade ou aguarda a ocorrncia de um evento (BOOCH;
RUMBAUGH; JACOBSON, 2006). Estados so representados por retngulos com os cantos
arredondados, sendo que o nome de um estado deve ser nico em uma mquina de estados.
Uma regra prtica para nomear estados consiste em atribuir um nome tal que sejam

143
significativas sentenas do tipo o <<objeto>> est <<nome do estado>> ou o

<<objeto>> est no estado <<nome do estado>>. Por exemplo, em um sistema de
locadora de automveis, um estado possvel de objetos da classe Carro seria Disponvel. A
sentena o carro est disponvel tem um significado claro (OLIV, 2007).
Quando um objeto fica realizando uma atividade durante todo o tempo em que
permanece em um estado, deve-se indicar essa atividade no compartimento de aes do
respectivo estado. importante realar que uma atividade tem durao significativa e, quando
concluda, tipicamente a concluso provoca uma transio para um novo estado. A notao da
UML para representar atividades de um estado : do / <<nomeAtividade>>.
Transies so representadas por meio de setas rotuladas. Uma transio envolve um
estado origem, um estado destino e normalmente um evento, dito o gatilho da transio.
Quando a mquina de estados se encontra no estado origem e recebe o evento gatilho, ento o
evento dispara a transio e a mquina de estados vai para o estado destino. Se uma mquina
recebe um evento que no um gatilho para nenhuma transio, ento ela no afetada pelo
evento (OLIV, 2007).
Uma transio pode ter uma condio de guarda associada. s vezes, h duas ou mais
transies com o mesmo estado origem e o mesmo evento gatilho, mas com condies de
guarda diferentes. Neste caso, a transio disparada somente quando o evento gatilho ocorre
e a condio de guarda verdadeira (OLIV, 2007). Quando uma transio no possuir uma
condio de guarda associada, ento ela ocorrer sempre que o evento ocorrer.
Por fim, quando uma transio disparada, uma ao instantnea pode ser realizada.
Assim, o rtulo de uma transio pode ter at trs partes, todas elas opcionais:
evento [condioGuarda] / ao
Basicamente a semntica de um diagrama de estados a seguinte: quando o evento
ocorre, se a condio de guarda verdadeira, a transio dispara e a ao realizada
instantaneamente. O objeto passa, ento, do estado origem para o estado destino. Se o estado
destino possuir uma atividade a ser realizada, ela iniciada.
O fato de uma transio no possuir um evento associado normalmente aponta para a
existncia de um evento implcito. Isso tipicamente ocorre em trs situaes: (i) o evento
implcito a concluso da atividade do estado origem e a transio ocorrer to logo a
atividade associada ao estado origem tiver sido concluda; (ii) o evento implcito temporal,
sendo disparado pela passagem do tempo; (iii) o evento implcito torna a condio de guarda
verdadeira na base de informaes do sistema, mas o evento em si no modelado.
Embora ambos os termos ao e atividade denotem processos, eles no devem ser
confundidos. Aes so consideradas processos instantneos; atividades, por sua vez, esto
sempre associadas a estados e tm durao no tempo. Vale a pena observar que, no mundo
real, no h processos efetivamente instantneos. Por mais rpida que seja, uma ao ocorrer
sempre em um intervalo de tempo. Esta simplificao de se considerar aes instantneas no
modelo conceitual pode ser associada ideia de que a ao ocorre to rapidamente que no
possvel interromp-la. Em contraste, uma atividade passvel de interrupo, sendo possvel,
por exemplo, que um evento ocorra, interrompa a atividade e provoque uma mudana no
estado do objeto antes da concluso da atividade.
s vezes quer se modelar situaes em que uma ao instantnea realizada quando
se entra ou sai de um estado, qualquer que seja a transio que o leve ou o retire desse estado.
Seja o exemplo de um elevador. Neste contexto, ao parar em um andar, o elevador abre a

144
porta. Suponha que a abertura da porta do elevador seja um processo que no possa ser
interrompido e, portanto, que se opte por model-lo como uma ao. Essa ao dever ocorrer
sempre que o elevador entrar no estado Parado e deve ser indicada no compartimento de
aes desse estado como sendo uma ao de entrada no estado. A notao da UML para
representar aes de entrada em um estado : entry / <<nomeAo>>. Para representar aes
de sada de um estado a notao : exit / <<nomeAo>>.
Restam ainda na Figura 7.2 dois tipos especiais de estados: os ditos estados inicial e
final. Conforme citado anteriormente, um objeto est sempre em um e somente um estado.
Isso implica que, ao ser instanciado, o objeto precisa estar em algum estado. O estado inicial
precisamente esse estado. Graficamente, um estado inicial mostrado como um pequeno
crculo preenchido na cor preta. Seu significado o seguinte: quando o objeto criado, ele
colocado no estado inicial e sua transio de sada automaticamente disparada, movendo o
objeto para um dos estados da mquina de estados (no caso da Figura 7.2, para o Estado1).
Toda mquina de estados tem de ter um (e somente um) estado inicial. Note que o estado
inicial no se comporta como um estado normal20, uma vez que objetos no se mantm nele
por um perodo de tempo. Ao contrrio, uma vez que eles entram no estado inicial, sua
transio de sada imediatamente disparada e o estado inicial abandonado. A transio de
sada do estado inicial tem como evento gatilho implcito o evento responsvel pela criao
do objeto (OLIV, 2007) e, na UML, esse evento no explicitamente representado. Estados
iniciais tm apenas transies de sada. As transies de sada de um estado inicial podem ter
condies de guarda e/ou aes associadas. Quando houver condies de guarda, deve-se
garantir que sempre pelo menos uma das transies de sada poder ser disparada.
Quando um objeto deixa de existir, obviamente ele deixa de estar em qualquer um dos
estados. Isso pode ser dito no diagrama por meio de uma transio para o estado final. O
estado final indica, na verdade, que o objeto deixou de existir. Na UML um estado final
representado como um crculo preto preenchido com outro crculo no preenchido ao seu
redor, como mostra a Figura 7.2. As transies para o estado final definem os estados em que
possvel excluir o objeto. Classes cujos objetos no podem ser excludos, portanto, no
possuem um estado final (OLIV, 2007). Assim como o estado inicial, o estado final no se
comporta como um estado normal, uma vez que o objeto tambm no permanece nesse estado
(j que o objeto no existe mais). Ao contrrio do estado inicial, contudo, uma mquina de
estados pode ter vrios estados finais. Alm disso, deve-se representar o evento que elimina o
objeto (na Figura 7.2, eventoDestruio).
Os eventos mostrados nas transies so os mesmos eventos de requisio de ao
discutidos na Seo 7.1. Contudo, importante indicar no diagrama de estados os eventos
maiores (eventos de domnio e requisies de aes) e no os eventos estruturais que
efetivamente alteram o estado do objeto. Assim, neste texto sugere-se indicar como eventos
de transies de uma mquina de estados as requisies de realizao de casos de uso do
sistema (ou de fluxos de eventos especficos, quando um caso de uso tiver mais de um fluxo
de eventos normal). Para facilitar a rastreabilidade, sugere-se usar como nome do evento
exatamente o mesmo nome do caso de uso (ou do fluxo de eventos). Seja o exemplo de uma
locadora de automveis, que possua, dentre outros, os casos de uso mostrados na Figura 7.3,
os quais possuem os fluxos de eventos mostrados nas notas anexadas aos casos de uso.
20
Por no se comportar como um estado normal, o estado inicial considerado um pseudoestado no metamodelo
da UML.

145
Figura 7.3 Locadora de Automveis - Casos de Uso e Fluxos de Eventos Associados.

A classe Carro tem o seu comportamento definido pela mquina de estados do
diagrama de grfico de estados da Figura 7.4. Ao ser adquirido (fluxo de eventos Comprar
Carro, do caso de uso Negociar Carro), o carro colocado Em Preparao. Quando liberado
para uso (fluxo de eventos Liberar Carro para Uso, do caso de uso Efetuar Manuteno de
Carro), o carro fica Disponvel. Quando o cliente retira o carro (fluxo de eventos Retirar
Carro, do caso de uso Efetuar Locao), este fica Em Uso. Quando devolvido (fluxo de
eventos Devolver Carro, do caso de uso Efetuar Locao), o carro fica novamente Em
Preparao. Quando Disponvel, um carro pode ser transferido de uma localidade para outra
(fluxo de eventos Transferir Carro para Outra Localidade do caso de uso Transferir Carro).
Durante o trnsito de uma localidade para outra, o carro est Em Trnsito, at ser recebido na
localidade destino (fluxo de eventos Receber Carro Vindo de Outra Localidade, do caso de
uso Transferir Carro), quando novamente colocado Em Preparao. Finalmente, carros Em
Preparao podem ser vendidos (fluxo de eventos Vender Carro, do caso de uso Negociar
Carro), quando deixam de pertencer locadora e so eliminados de sua base de informaes.

146
Figura 7.4 Diagrama de Grfico de Estados da Classe Carro Disponibilidade

(adaptado de (OLIV, 2007)).
Nem todas as classes precisam ser modeladas como mquinas de estados. Apenas
classes modais (i.e., classes que apresentam comportamento varivel em funo do estado de
seus objetos) necessitam ser modeladas como mquinas de estados. Alm disso, para os
diagramas de estados serem efetivamente teis, recomenda-se modelar uma mquina de
estados somente se a classe em questo tiver trs ou mais estados relevantes. Se uma classe
possuir apenas dois estados relevantes, ainda cabe desenvolver uma mquina de estados.
Contudo, de maneira geral, o diagrama tende a ser muito simples e a acrescentar pouca
informao relevante que justifique o esforo de elaborao e manuteno do correspondente
diagrama. Neste caso, os estados e transies podem ser levantados, sem, no entanto, ser
elaborado um diagrama de estados.
Para algumas classes, pode ser til desenvolver mais do que um diagrama de estados,
cada um deles modelando o comportamento dos objetos da classe por uma perspectiva
diferente. Em um determinado momento, um objeto est em um (e somente um) estado em
cada uma de suas mquinas de estado. Cada diagrama define seu prprio conjunto de estados
nos quais um objeto pode estar, a partir de diferentes pontos de vista (OLIV, 2007). Seja
novamente o exemplo da classe Carro. A Figura 7.4 mostra os possveis estados de um carro
segundo um ponto de vista de disponibilidade. Entretanto, independentemente da
disponibilidade, do ponto de vista de possibilidade de negociao, um carro pode estar em
dois estados (No Venda, Venda), como mostra a Figura 7.5.
Vale ressaltar que os diferentes diagramas de estados de uma mesma classe no devem
ter estados comuns. Cada diagrama deve ter seu prprio conjunto de estados e cada estado
pertence a somente um diagrama de estados. J os eventos podem aparecer em diferentes
diagramas de estados, inclusive de classes diferentes. Quando um evento aparecer em mais de
um diagrama de estados, sua ocorrncia vai disparar as correspondentes transies em cada
uma das mquinas de estados em que ele aparecer (OLIV, 2007).

147
Figura 7.5 Diagrama de Grfico de Estados da Classe Carro Possibilidade de

Negociao (adaptado de (OLIV, 2007)).
A Figura 7.5 mostra duas transies em que os eventos no so declarados
explicitamente. No primeiro caso (quilometragem > 50.000Km), o evento implcito torna a
condio de guarda verdadeira na base de informaes do sistema. Esse evento corresponde
ao registro no sistema de qual a quilometragem corrente do carro. Caso esse registro ocorra
sempre no ato da devoluo do carro pelo cliente (fluxo de eventos Devolver Carro, do caso
de uso Efetuar Locao) e/ou no ato do recebimento do carro vindo de outra localidade (fluxo
de eventos Receber Carro Vindo de Outra Localidade, do caso de uso Transferir Carro),
esses eventos poderiam ser explicitamente declarados. Contudo, se o registro pode ocorrer em
vrios eventos diferentes, melhor deixar o evento implcito. O segundo caso (dataCorrente
dataAquisicao > 1 ano) trata-se de um evento temporal, disparado pela passagem do tempo.
Todos os estados mostrados at ento so estados simples, i.e., estados que no
possuem subestados. Entretanto, h tambm estados compostos, os quais podem ser
decompostos em um conjunto de subestados disjuntos e mutuamente exclusivos e um
conjunto de transies (OLIV, 2007). Um subestado um estado aninhado em outro estado.
O uso de estados compostos e subestados bastante til para simplificar a modelagem de
comportamentos complexos. Seja o exemplo da Figura 7.4, que trata da disponibilidade de um
carro. Suponha que seja necessrio distinguir trs subestados do estado Em Uso, a saber: Em
Uso Normal, quando o carro no est quebrado nem em atraso; Quebrado, quando o cliente
reportar um defeito no carro; e Em Atraso, quando o carro no foi devolvido na data de
devoluo prevista e no est quebrado. A Figura 7.6 mostra a mquina de estados da classe
Carro considerando, agora, que, quando um carro est em uso, ele pode estar nesses trs
subestados.
Nesse diagrama, no est sendo mostrado que os estados Em Uso Normal, Em Atraso
e Quebrado so, de fato, subestados do estado Em Uso e, portanto, transies comuns (por
exemplo, aquelas provocadas pelo evento Devolver Carro) so repetidas. Isso torna o modelo
mais complexo e fica claro que esta soluo representando diretamente os subestados (e
omitindo o estado composto) no escalvel para sistemas que possuem muitos subestados,
levando a diagramas confusos e desestruturados (OLIV, 2007). A Figura 7.7 mostra uma
soluo mais indicada, em que tanto o estado composto quanto seus subestados so mostrados
no mesmo diagrama. Uma outra opo ocultar a decomposio do estado composto,
mantendo o diagrama como o mostrado na Figura 7.4, e mostrar essa decomposio em um
diagrama de estados separado.

148
Figura 7.6 Diagrama de Estados da Classe Carro (Disponibilidade) com Subestados de

Em Uso (adaptado de (OLIV, 2007)).
Se um objeto est em um estado composto, ento ele deve estar tambm em um de
seus subestados. Assim, um estado composto pode possuir um estado inicial para indicar o
subestado padro do estado composto, como representado na Figura 7.7. Entretanto, deve-se
considerar que as transies podem comear e terminar em qualquer nvel. Ou seja, uma
transio pode ir (ou partir) diretamente de um subestado (OLIV, 2007). Assim, uma outra
opo para o diagrama da Figura 7.7 seria fazer a transio nomeada pelo evento Retirar
Carro chegar diretamente ao subestado Em Uso Normal, ao invs de chegar ao estado
composto Em Uso.
O estado de um objeto deve ser mapeado no modelo estrutural. De maneira geral, o
estado pode ser modelado por meio de um atributo. Esse atributo deve ser monovalorado e
obrigatrio. O conjunto de valores possveis do atributo o conjunto dos estados possveis,
conforme descrito pela mquina de estados (OLIV, 2007). Assim, bastante natural que o
tipo de dados desse atributo seja definido como um tipo de dados enumerado. Um nome
adequado para esse atributo estado. Contudo, outros nomes mais significativos para o
domnio podem ser atribudos. Em especial, quando uma classe possuir mais do que uma
mquina de estado e, por conseguinte, mais do que um atributo de estado for necessrio, o
nome do atributo de estado deve indicar a perspectiva capturada pela correspondente mquina
de estados.

149
Figura 7.7 Diagrama de Estados da Classe Carro (Disponibilidade) com Estado

Composto Em Uso (adaptado de (OLIV, 2007)).
interessante observar que algumas transies podem mudar a estrutura da classe.
Quando os diferentes estados de um objeto no afetam a sua estrutura, mas apenas,
possivelmente, os valores de seus atributos e associaes, diz-se que a transio estvel e os
diferentes estados podem ser mapeados para um simples atributo (WAZLAWICK, 2004),
conforme discutido anteriormente.
Entretanto, h situaes em que, conforme um objeto vai passando de um estado para
outro, ele vai ganhando novos atributos ou associaes, ou seja, h uma mudana na estrutura
da classe. Seja o exemplo de uma locao de carro. Como mostra a Figura 7.8, quando uma
locao criada, ela est ativa, em curso normal. Quando o carro no devolvido at a data
de devoluo prevista, a locao passa a ativa com prazo expirado. Se a locao estendida,
ela volta a ficar em curso normal. Quando o carro devolvido, a locao fica pendente.
Finalmente, quando o pagamento efetuado, a locao concluda.

150
Figura 7.8 Diagrama de Estados da Classe Locao.

Locaes ativas (e em seus subestados, obviamente) tm como atributos: data de
locao, data de devoluo prevista, valor devido e cauo. Quando uma locao vai para o
estado pendente, necessrio registrar a data de devoluo efetiva e os problemas observados
no carro devolvido. Finalmente, quando o pagamento efetuado, preciso registrar a data do
pagamento, o valor e a forma de pagamento. Diz-se que as transies dos estados de Ativa
para Pendente e de Pendente para Concluda so monotnicas21, porque a cada mudana de
estado, novos relacionamentos (atributos ou associaes) so acrescentados (mas nenhum
retirado).
Uma soluo frequentemente usada para capturar essa situao no modelo conceitual
estrutural consiste em criar uma nica classe (Locacao) e fazer com que certos atributos sejam
nulos at que o objeto mude de estado, como ilustra a Figura 7.9. Essa forma de modelagem,
contudo, pode no ser uma boa opo, uma vez que gera classes complexas com regras de
consistncia que tm de ser verificadas muitas vezes para evitar a execuo de um mtodo que
atribui um valor a um atributo especfico de um estado (WAZLAWICK, 2004), tal como
dataPagamento.
Figura 7.9 Classe Locao com atributos inerentes a diferentes estados.

21
Monotnico diz respeito a algo que ocorre de maneira contnua. Neste caso, a continuidade advm do fato de
um objeto continuamente ganhar novos atributos e associaes, sem perder os que j possua.

151
possvel modelar essa situao desdobrando o conceito original em trs: um

representando a locao efetivamente, outro representando a devoluo e outro representando
o pagamento. Desta forma, capturam-se claramente os eventos de locao, devoluo e
pagamento, colocando as informaes de cada evento na classe correspondente, como ilustra
a Figura 7.10.
Figura 7.10 Distribuindo as responsabilidades.

Finalmente, vale a pena comentar que estados de uma classe modal podem ser tratados
por meio de operaes ao invs de atributos. Seja o exemplo anterior de locaes de carros
(Figura 7.10). O estado de uma locao pode ser computado a partir dos atributos e
associaes da classe Locacao, sem haver a necessidade de um atributo estado. Se uma
locao no tem uma devoluo associada, ento ela est ativa. Estando ativa, se a data
corrente menor ou igual data de devoluo prevista, ento a locao est em curso normal;
caso contrrio, ela est com prazo expirado. Se uma locao possui uma devoluo, mas no
possui um pagamento associado, ento ela est pendente. Finalmente, se a locao possui um
pagamento associado, ento ela est concluda. Em casos como este, pode-se optar por tratar
estado como uma operao e no como um atributo. Opcionalmente, pode-se utilizar a
operao para calcular o valor de um atributo derivado22 estado. Atributos derivados so
representados na UML precedidos por uma barra (no exemplo, /estado).
7.3 - Diagramas de Atividades

Um diagrama de atividades como um fluxograma, no sentido que focaliza o fluxo de
controle de uma atividade para outra. Entretanto, ao contrrio de um fluxograma tradicional,
um diagrama de atividades mostra, alm de fluxos sequenciais e ramificaes de controle,
fluxos concorrentes (BOOCH; RUMBAUGH; JACOBSON, 2006; BLAHA; RUMBAUGH,
2006). O propsito de um diagrama de atividades mostrar as etapas de um processo
complexo e a sequncia entre elas (BLAHA; RUMBAUGH, 2006).
Diagramas de atividades so usados para representar processos, sendo utilizados tanto
para modelar processos de negcio quanto para representar a realizao de um caso de uso.
Eles foram adicionados UML relativamente tarde, adquirindo status de um tipo de diagrama
22
Um atributo derivado quando seu valor pode ser deduzido ou calculado a partir de outras informaes
(atributos e associaes) j existentes no modelo estrutural.

152
somente na UML 2.0. At a UML 1.5, diagramas de atividades eram considerados um tipo
especial de diagrama de estados.
Os diagramas de atividades so muito usados para modelar processos de negcio e
fluxos de trabalho em organizaes (ver Seo 3.3), uma vez que esses processos / fluxos de
trabalho envolvem muitas pessoas e unidades organizacionais que realizam atividades
concorrentemente (BLAHA; RUMBAUGH, 2006). Principalmente no contexto de sistemas
corporativos e de misso crtica, o sistema em desenvolvimento estar funcionando no
contexto de processos de negcio de mais alto nvel e pode ser til usar diagramas de
atividades para modelar esses processos com o intuito de investigar as formas como humanos
e os vrios sistemas automatizados colaboram (BOOCH; RUMBAUGH; JACOBSON, 2006).
Esse importante uso dos diagramas de atividades, contudo, est fora do escopo deste texto e,
portanto, no ser aqui abordado.
No contexto da modelagem comportamental de sistemas (foco deste texto), os
diagramas de atividades podem ser usados para modelar o fluxo de trabalho em um caso de
uso. Para essa finalidade, os principais elementos de modelo dos diagramas de atividades da
UML utilizados so: atividades, fluxos de controle, pontos de iniciao e concluso, desvios
(ou ramificaes), bifurcao e unio, fluxos de objetos e regies de expanso. Na
modelagem de processos, utilizam-se tambm raias para indicar quem (que pessoa ou unidade
organizacional) responsvel por uma atividade.
Uma atividade uma poro significativa de trabalho dentro de um fluxo de trabalho.
Atividades podem ser atmicas ou complexas. Uma atividade atmica (i.e., que no pode ser
decomposta) dita uma ao na UML. Uma atividade complexa composta de outras
atividades (atmicas ou complexas) e na UML representada por um n de atividade. Assim,
um n de atividade representa um grupo de aes ou de outros ns de atividade aninhados,
que possui uma subestrutura visvel, representada em um outro diagrama de atividades
(BOOCH; RUMBAUGH; JACOBSON, 2006). Atividades so representadas por elipses
alongadas. Quando uma atividade concluda, o fluxo de controle passa imediatamente para a
atividade seguinte. O fluxo de controle mostrado por meio de uma seta no rotulada de uma
atividade para a sua sucessora.
O fluxo de controle inicia e termina em algum lugar. Os pontos de iniciao e de
concluso do fluxo de controle so mostrados em um diagrama de atividades usando a mesma
notao de estados inicial e final de diagramas de grficos de estados, respectivamente.
Quando um diagrama de atividades ativado, o fluxo de controle inicia no ponto de iniciao
e avana por meio da(s) seta(s) de fluxo de controle em direo (s) primeira(s) atividade(s) a
ser(em) realizada(s). Quando o ponto de concluso atingido, todo o processo encerrado e a
execuo do diagrama de atividades termina (BOOCH; RUMBAUGH; JACOBSON, 2006;
BLAHA; RUMBAUGH, 2006). A Figura 7.11 mostra a notao da UML para atividades,
fluxos de controle e pontos de iniciao e concluso.

153
Figura 7.11 - Notao Bsica da UML para Diagramas de Atividades.

Os elementos da Figura 7.11 s permitem modelar sequncias de atividades. Contudo,
a maioria dos fluxos de trabalho envolve fluxos alternativos, concorrentes e/ou iterativos. Para
representar essas estruturas de controle, so necessrios outros elementos de modelo. Em
diagramas de atividades da UML, fluxos alternativos, concorrentes e/ou iterativos podem ser
representados por meio de desvios (ou ramificaes), bifurcaes e unies, e regies de
expanso, respectivamente.
Um desvio ou ramificao permite especificar caminhos alternativos a serem seguidos,
tomando por base alguma expresso booleana. Uma ramificao possui um fluxo de entrada e
dois ou mais de sada. Em cada fluxo de sada colocada uma expresso booleana, a qual
avaliada quando o controle atinge a ramificao. As condies no podem se sobrepor, pois
seno o fluxo de controle poderia seguir por mais de um caminho, o que no admissvel em
uma ramificao. Alm disso, elas tm de cobrir todas as possibilidades, pois, caso contrrio o
fluxo de controle pode ficar sem ter para onde seguir em alguma situao. Para evitar esse
problema, pode-se utilizar a condio else, a qual satisfeita caso nenhuma outra condio
seja satisfeita (BOOCH; RUMBAUGH; JACOBSON, 2006; BLAHA; RUMBAUGH, 2006).
Uma ramificao representada na UML por um losango. Quando dois caminhos de
controle alternativos se fundem novamente, pode-se utilizar o mesmo smbolo para mescllos. Na fuso, contudo, h duas ou mais setas de fluxo de controle de entrada e somente uma
de sada. A Figura 7.12 ilustra a notao de desvios e fuses.
Figura 7.12 Ramificaes em Diagramas de Atividades da UML.

154
Para mostrar atividades realizadas concorrentemente, podem-se utilizar bifurcaes e

unies, as quais so representadas por barras de sincronizao. Uma barra de sincronizao
representada por uma linha grossa horizontal ou vertical. Uma bifurcao tem de ter um nico
fluxo de controle de entrada e dois ou mais fluxos de sada, cada um deles representando um
fluxo de controle independente. As atividades associadas a cada um desses caminhos
prosseguem paralelamente, indicando que as atividades ocorrem concorrentemente. J uma
unio representa a sincronizao de um ou mais fluxos de controle concorrentes. Uma unio
tem de ter dois ou mais fluxos de entrada e apenas um fluxo de controle de sada. Na unio, os
fluxos concorrentes de entrada so sincronizados, significando que cada um deles aguarda at
que todos os fluxos de entrada tenham atingido a unio, a partir da qual o fluxo de controle de
sada prossegue. De maneira geral, deve haver um equilbrio entre bifurcaes e unies,
indicando que o nmero de fluxos de controle que deixam uma bifurcao deve ser
equivalente ao nmero de fluxos que chegam a uma unio correspondente (BOOCH;
RUMBAUGH; JACOBSON, 2006). A Figura 7.13 ilustra a notao de bifurcaes e unies.
Figura 7.13 Bifurcaes e Unies em Diagramas de Atividades da UML.

Para representar atividades que ocorrem vrias vezes, operando sobre elementos de um
conjunto, podem-se utilizar regies de expanso. Uma regio de expanso representa um
fragmento do diagrama de atividades que realizado operando sobre os elementos de uma
lista ou conjunto. Ela representada por uma linha tracejada em torno da regio do diagrama
que envolve as atividades iterativas. A regio executada uma vez para cada elemento do
conjunto de entrada (BOOCH; RUMBAUGH; JACOBSON, 2006).
Muitas vezes til representar os objetos requeridos (entradas) e produzidos (sadas)
por uma atividade em um diagrama de atividades. possvel especificar os objetos
envolvidos nas atividades, conectando-os s atividades que os produzem ou consomem. Alm
de representar objetos e o seu fluxo nas atividades, pode-se representar, ainda, o estado em
que se encontra o objeto. A Figura 7.14 mostra a notao de objetos, fluxos de objetos e
estado do objeto.

155
Figura 7.14 Objetos e Fluxos de Objetos em Diagramas de Atividades da UML.

Um fluxo de objetos implica em um fluxo de controle, pois representa o fluxo de um
objeto de uma atividade para outra. Portanto, desnecessrio desenhar um fluxo de controle
entre as atividades conectadas por fluxos de objetos (BOOCH; RUMBAUGH; JACOBSON,
2006).
Neste texto, defendemos o uso de diagramas de atividades para complementar a viso
comportamental de casos de uso complexos. Sugere-se elaborar um diagrama de atividades
para cada fluxo de eventos normal complexo, mostrando no mesmo diagrama o fluxo de
eventos normal e os correspondentes fluxos variantes e de exceo. Elaborar diagramas de
atividade para casos de uso simples, tais como casos de uso cadastrais e de consulta,
dificilmente adicionar algum valor ao projeto e, portanto, tais diagramas so dispensveis.
Para ajudar os usurios a entender um diagrama de atividades, pode ser til ilustrar a
execuo do mesmo usando fichas de atividade. Uma ficha colocada no ponto de iniciao
do diagrama e ela vai sendo deslocada pelas atividades do diagrama. Quando houver uma
bifurcao, mltiplas fichas vo surgir, uma para cada fluxo de sada. De maneira anloga,
uma unio do controle reduz o conjunto de fichas de entrada para uma nica ficha de sada
(BLAHA; RUMBAUGH, 2006).
7.4 Especificao das Operaes

Uma vez estudado o comportamento do sistema, tem-se uma base para a definio das
operaes das classes que compem o sistema. Operaes correspondem a servios que
podem ser solicitados aos objetos de uma classe e so apresentadas na seo inferior do
smbolo de classe, com a seguinte sintaxe23 para a sua assinatura (BOOCH; RUMBAUGH;
JACOBSON, 2006):
visibilidade nome(lista_de_parmetros): tipo_de_retorno
A visibilidade de uma operao indica em que situaes ela visvel por outras
classes, podendo uma operao ser pblica, protegida, privada e de pacote, da mesma forma
que atributos (ver Seo 6.2.1). A informao de visibilidade inerente fase de projeto e no
deve ser expressa em um modelo conceitual.
Para nomear uma operao, sugere-se o uso de um verbo no infinitivo, o qual pode ser
combinado com complementos, omitindo-se preposies. A exceo fica por conta de
operaes com retorno booleano, para as quais se sugere usar um nome que d uma noo de
23
A UML admite outras informaes na assinatura de uma operao. Entretanto, essas so as notaes mais
comumente utilizadas.

156
uma pergunta sendo feita. O nome da operao deve ser iniciado com letra minscula,
enquanto os nomes dos complementos devem iniciar com letras maisculas, sem dar um
espao em relao palavra anterior. Acentos no devem ser utilizados. Ex.: calcularValor,
emAtraso.
Na assinatura de uma operao, podem ser indicados zero ou mais parmetros
separados por vrgula, cada um deles com a sintaxe abaixo24, onde nome_parmetro o nome
para referenciar o parmetro, tipo seu tipo de dados ou classe, e valor_padro o valor que
ser assumido se um valor no for informado.
nome_parmetro: tipo [= valor_padro]
O tipo_de_retorno indica a classe ou o tipo de dado do valor retornado pela operao,

o qual pode ser uma classe, um tipo de dado primitivo ou um tipo de dado especfico de
domnio. Caso uma operao no tenha retorno, nada especificado.
Conforme discutido anteriormente, h operaes, ditas bsicas, que simplesmente
manipulam atributos e associaes, criam ou destroem objetos. Essas operaes no so
representadas nos diagramas de classes, nem especificadas e documentadas no Dicionrio de
Projeto, j que podem ser deduzidas do modelo conceitual estrutural. As demais operaes
devem ser descritas no Dicionrio de Projeto, dando uma descrio sucinta de seu propsito.
Conforme apontado no Captulo 6, o livro Conceptual Modeling of Information
Systems, de Antoni Oliv (OLIV, 2007) dedicado modelagem conceitual de sistemas e,
portanto, uma tima referncia para os interessados em se aperfeioar nessa rea. Vrias das
discusses feitas nesse livro foram incorporadas nestas notas de aula. Os captulos 11 e 12
discutem, respectivamente, eventos de domnio e eventos de requisio de aes, discutidos
na seo 7.1 destas notas de aula. Os captulos 13 e 14 desse livro abordam a elaborao de
diagramas de transio de estados.
O Captulo 4 de (WAZLAWICK, 2004) Operaes e Consultas de Sistema discute
aspectos relacionados elaborao de diagramas de sequncia. No Captulo 5 Modelagem
Conceitual h uma boa discusso sobre classes modais, ainda que no se aborde a
elaborao de diagramas de estados.
(Diagramas de Interao), 20 (Diagramas de Atividades), 22 (Mquinas de Estados) e 25
(Diagramas de Grficos de Estados). As notaes da UML para os diagramas abordados
neste captulo so tratadas com bastante detalhes, uma vez que este um livro sobre a UML.
Alm desses captulos, merece ateno a parte do Captulo 9 (Classes Avanadas) que trata da
sintaxe de operaes.
Finalmente, em (BLAHA; RUMBAUGH, 2006), os captulos 5, 6 e 12 abordam o
desenvolvimento de diagramas de estados, enquanto os captulos 7, 8 e 13 discutem a
elaborao de diagramas de sequncia e de atividades, dentre outras coisas.
24
Idem comentrio anterior.

157
Elsevier, 2006.
Editora, 2006.
Elsevier, 2004.

158

Durante o processo de Engenharia de Requisitos, diversos documentos e modelos
podem ser elaborados. Durante o levantamento de requisitos, requisitos de usurio so
capturados em um Documento de Requisitos. Na fase de anlise, esses requisitos so
especificados usando diagramas diversos organizados em dois modelos principais: o modelo
estrutural e o modelo comportamental. O modelo conceitual estrutural de um sistema tem por
objetivo descrever as informaes que esse sistema deve representar e gerenciar. O modelo
comportamental, por sua vez, prov uma viso ampla do comportamento do sistema.
No que tange modelagem do comportamento de um sistema, em um nvel superior,
os diagramas de casos de uso proveem uma viso externa da funcionalidade do sistema e dos
atores nela envolvidos. O comportamento dos casos de uso elaborado por meio de
descries de casos de uso. Essas descries podem ser refinadas por meio de diagramas de
atividade ou de sequncia. Os diagramas de sequncia tipicamente mostram vises parciais.
Eles, geralmente, so desenvolvidos apenas para fluxos de eventos principais ou so
desenvolvidos um diagrama de sequncia para o fluxo principal de eventos e diagramas
adicionais para os fluxos de exceo e variantes. Diagramas de atividade permitem consolidar
todo esse comportamento em um nico diagrama, documentando ramificaes, bifurcaes e
unies do fluxo de controle. Diagramas de sequncia so bons para mostrar colaboraes
entre objetos em um caso de uso. J os diagramas de atividade so teis para focalizar as
atividades de um processo complexo. Contudo, esses dois tipos de diagramas no so
apropriados para observar o comportamento de um objeto isolado ao longo de vrios casos de
uso. Para tal, so utilizados diagramas de grfico de estados.
Neste contexto, uma questo importante precisa ser tratada: como fazer a engenharia
dos requisitos de um sistema com qualidade, mas ao mesmo tempo de maneira gil, sem
despender tempo elaborando diagramas que acrescentam pouco valor ao projeto? No se deve
perder de vista que o propsito da modelagem ajudar a entender o problema de modo que se
possa produzir um sistema que atenda s necessidades do usurio. Produzir artefatos
desnecessrios transforma o trabalho de Engenharia de Software em burocracia de software.
Para tratar essa questo, primeiro deve-se considerar a tica da qualidade. Sob esse
ponto de vista, fundamental garantir consistncia entre os diversos artefatos produzidos. Os
diversos documentos e modelos proveem diferentes vises de um mesmo sistema e, portanto,
devem estar compatveis entre si. importante observar que os modelos produzidos envolvem
conceitos comuns, dentre eles classes, objetos e operaes, e que essencial manter as
informaes rastreveis. Ambos os modelos, estrutural e comportamental, so necessrios
para um completo entendimento de um problema, embora a importncia de cada um dos
diagramas envolvidos varie de projeto para projeto e em funo do tipo de aplicao a ser
desenvolvida. Esses modelos se unem para dar forma s classes com atributos, associaes e
operaes, que sero a base para o projeto e a implementao. Em especial, as operaes
envolvem dados (objeto destino, argumentos, variveis e retorno), controle (sequncia) e
interaes (mensagens e chamadas). Assim, para uma completa especificao das classes, o

159
que envolve a especificao de suas operaes, so necessrios os modelos estrutural e

comportamental. Alm disso, necessrio compar-los para garantir que no h
inconsistncias entre eles (BLAHA; RUMBAUGH, 2006). Para apoiar a verificao da
consistncia, tcnicas de leitura de modelos de anlise podem ser aplicadas. Algumas dessas
tcnicas so discutidas na Seo 8.1.
Do ponto de vista de agilidade no processo de Engenharia de Requisitos, merece
destaque a modelagem gil. A modelagem gil prov uma srie de princpios e valores que
podem ser aplicados para nortear a deciso de quais diagramas produzir, de modo que o
esforo despendido na anlise de requisitos seja compensador. A modelagem gil discutida
na Seo 8.2.
Por fim, visando tanto qualidade quanto a agilidade, podem ser aplicadas tcnicas de
reutilizao de requisitos. A reutilizao tende a proporcionar qualidade, uma vez que os
requisitos, modelos ou outros artefatos reutilizados j foram avaliados em outros contextos e,
por conseguinte, tendem a prover solues j avaliadas. Do ponto de vista da agilidade, ao se
reutilizar algum artefato da Engenharia de Requisitos, espera-se que haja um aumento da
produtividade, uma vez que no se est partindo do zero. A reutilizao na Engenharia de
Requisitos discutida na Seo 8.3.
8.1 Tcnicas de Leitura de Modelos da Anlise de Requisitos

Na verificao da consistncia entre os diversos modelos e diagramas produzidos
durante um processo de software orientado a objetos, devem ser consideradas tcnicas de
leitura de modelos orientados a objetos, as quais podem ser de dois tipos: tcnicas para leitura
vertical e para leitura horizontal. As tcnicas para leitura horizontal dizem respeito
consistncia entre artefatos elaborados em uma mesma fase, procurando verificar se esses
artefatos esto descrevendo consistentemente diferentes aspectos de um mesmo sistema, no
nvel de abstrao relacionado fase em questo. Tcnicas verticais referem-se consistncia
entre artefatos elaborados em diferentes fases.
Neste texto, o foco recai sobre tcnicas de leitura horizontal, mais especificamente
entre os modelos produzidos durante a anlise de requisitos. A Figura 8.1 mostra as relaes
existentes entre os diferentes artefatos elaborados na fase de anlise de requisitos, indicando
as tcnicas de leituras associadas. Essa figura destaca a importncia de dois artefatos
produzidos na anlise de requisitos: as descries de casos de uso e os diagramas de classes.
Como se pode notar pela figura, esses dois artefatos tm relaes com quase todos os demais,
o que mostra o papel central que eles desempenham no processo de desenvolvimento
orientado a objetos. Na sequncia, cada uma das tcnicas referenciadas na Figura 8.1
descrita.

160
Descries de
Casos de Uso
H6
H1
Diagrama de
Casos de Uso
Dicionrio de
Projeto
H2
H5
H3
Diagrama de
Atividades
H7
Diagrama de
Classes
H4
Diagrama de
Estados
H8
Figura 8.1 Tcnicas de Leitura Horizontal de Modelos Orientados a Objetos Fase de
Anlise de Requisitos.
H1 Descries de Casos de Uso x Diagrama de Casos de Usos

Os seguintes aspectos devem ser verificados nas relaes entre diagramas de casos de
uso e descries de casos de uso:
a) Para cada caso de uso identificado em um diagrama de casos de uso, deve haver
uma descrio de caso de uso associada.
b) Os nomes dos casos de uso nos dois artefatos devem ser os mesmos.
c) As descries dos casos de uso devem fazer meno aos atores envolvidos nos
casos de uso e os atores identificados nos dois artefatos devem ser consistentes.
d) Quando um diagrama de casos de uso apontar uma associao entre casos de uso
(incluso ou extenso), a descrio correspondente deve fazer meno
explicitamente realizao do caso de uso associado.
H2 Descries de Casos de Uso x Diagrama de Classes
Os seguintes aspectos devem ser verificados nas relaes entre descries de casos de
uso e diagramas de classes:
a) As classes, associaes, atributos e operaes modelados no diagrama de classes
devem ser necessrios e suficientes para realizar cada um dos fluxos de eventos
apontados nas descries de casos de uso.
b) Quando uma descrio de caso de uso fizer meno a dados de uma classe no
diagrama de classes, ento a descrio do caso de uso deve ser consistente com os
atributos modelados na correspondente classe do diagrama de classes (e viceversa).
c) Para manter os modelos rastreveis, a descrio de caso de uso deve enumerar as
classes envolvidas em sua realizao.

161
H3 Dicionrio de Projeto x Diagrama de Classes

Os seguintes aspectos devem ser verificados nas relaes entre dicionrios de projeto e
diagramas de classes:
a) Para cada classe existente no diagrama de classes deve haver uma entrada no
dicionrio de projeto, associada a uma descrio sucinta da mesma.
b) Todos os atributos e operaes apresentados no diagrama de classes devem estar
enumerados e sucintamente descritos na entrada do dicionrio de projeto referente
correspondente classe.
c) Restries de integridade no passveis de registro pela notao da UML devem
ser explicitamente declaradas no modelo de classes. As classes, associaes e
atributos envolvidos em uma restrio de integridade devem estar consistentes com
o diagrama de classes e suas descries no dicionrio de projeto.
H4 Diagrama de Estados x Diagrama de Classes
Os seguintes aspectos devem ser verificados nas relaes entre diagramas de estados e
diagramas de classes:
a) Um diagrama de estados deve estar relacionado a uma classe modelada no
diagrama de classes.
b) A classe correspondente no diagrama de classes deve conter atributos, associaes
e/ou operaes capazes de indicar todos os estados pelos quais um objeto da
mesma pode passar.
H5 Diagrama de Estados x Descries de Casos de Uso
uso e diagramas de estados:
a) Os eventos associados a transies entre estados em um diagrama de estados
devem corresponder a fluxos de eventos ou a casos de uso em uma descrio de
casos de uso.
b) Quando pertinente, a descrio de caso de uso deve fazer uma meno explcita
transio para o novo estado.
H6 Diagrama de Atividades x Descries de Casos de Uso
uso e diagramas de atividades:
a) Um diagrama de atividades deve mostrar as atividades no contexto de um fluxo de
eventos descrito em uma descrio de casos de uso. Cursos alternativos (de
exceo ou variantes) devem ser mostrados no mesmo diagrama de atividades.
b) A sequncia de atividades em um diagrama de atividades deve estar consistente
com a sequncia de passos da descrio do caso de uso correspondente.

162
H7 Diagrama de Atividade x Diagrama de Classes

Os seguintes aspectos devem ser verificados nas relaes entre diagramas de
atividades e diagramas de classes:
a) Todos os objetos em um diagrama de atividades devem ter a indicao de a qual
classe pertencem. Essas classes devem estar modeladas no diagrama de classes.
b) Algumas atividades em um diagrama de atividades, tipicamente aquelas que
apontam um processamento a ser feito pelo sistema, podem indicar a necessidade
de uma operao na classe de um dos objetos que so entrada para essa atividade.
Quando este for o caso, a operao deve ser mostrada na classe correspondente do
diagrama de classes.
H8 Diagrama de Atividade x Diagrama de Estados
Os seguintes aspectos devem ser verificados nas relaes entre diagramas de
atividades e diagramas de estados:
a) Quando um objeto em um diagrama de atividades tiver o seu estado indicado e
houver um diagrama de estados para a classe desse objeto, ento os estados devem
estar consistentes, inclusive em relao ao evento que altera o estado do objeto.
8.2 Modelagem gil

Ao contrrio da modelagem conceitual estrutural em que o modelo de classes
basicamente o modelo a ser construdo, na modelagem comportamental h diversos modelos e
diagramas que podem ser empregados (modelos de casos de uso, diagramas de estados,
diagramas de sequncia e diagramas de atividades). Cada um desses diagramas trabalha uma
perspectiva diferente e, portanto, diferentes diagramas podem e devem ser elaborados para
prover uma viso abrangente do comportamento de um sistema. Entretanto, fundamental
considerar a relao custo-benefcio do uso desses modelos. Neste contexto, importante
levar em considerao princpios da Modelagem gil.
A Modelagem gil (AMBLER, 2004) uma coleo de valores, princpios e prticas
de modelagem de software que pode ser aplicada a projetos de desenvolvimento de software
de modo a torn-los mais leves e efetivos. Dentre os princpios de modelagem propostos por
Ambler, destacamos os seguintes:
O sistema de software seu objetivo principal; possibilitar o prximo trabalho

seu objetivo secundrio: o principal objetivo de um projeto de desenvolvimento de
software produzir um sistema de software de qualidade e no criar uma
documentao. Contudo, durante o desenvolvimento, necessrio preparar o
terreno para a prxima atividade, que no caso da modelagem de anlise pode ser a
fase de projeto ou mesmo de manuteno. Para apoiar atividades subsequentes do
processo de software, ser necessrio ter tambm uma documentao suficiente e
de qualidade.
Modele com um propsito: para que um certo diagrama seja elaborado, deve-se ter
uma finalidade em mente. Um diagrama deve ser til para comunicar informaes
para clientes e usurios, ajudando a se obter um entendimento comum dos
requisitos, ou deve ajudar desenvolvedores a compreender melhor algum aspecto

163
de software. Com base na meta estabelecida, deve-se escolher o tipo de diagrama

mais apropriado para atingir a meta e o nvel de detalhe a ser utilizado.
Use mltiplos modelos: h muitos modelos / diagramas e nveis de descrio

(notao) que podem ser usados descrever sistemas de software. Contudo,
normalmente apenas um pequeno subconjunto deles essencial para a maioria dos
projetos. Assim, para que a elaborao de um certo diagrama se justifique, ele deve
adicionar valor ao projeto. Ou seja, apenas aqueles diagramas que ofeream valor
sua audincia alvo devem ser usados.
Diminua a carga de trabalho (Viaje leve): cada um dos modelos e diagramas

elaborados, se conservado ao longo do desenvolvimento, precisa ser mantido
medida que mudanas nos requisitos acontecem. Isso representa trabalho para a
equipe e, portanto, toda vez que se decide conservar um modelo, est-se
comprometendo a agilidade em prol da convenincia de se ter aquela informao
disponvel para a equipe. A diretriz, portanto, conservar apenas aqueles modelos
que fornecero valor em longo prazo e descartar o restante. Esse princpio tem
vrias consequncias:
o Deve-se selecionar apenas um pequeno conjunto de modelos e diagramas
para serem elaborados, mantendo-se em linha com o princpio anterior;
o Caso se opte por elaborar um certo diagrama para compreender melhor um
certo aspecto do software, ele pode ser elaborado, mas no precisa ser
necessariamente incorporado documentao. s vezes, um esboo em
uma folha de papel cumpre o propsito e o diagrama pode ser descartado
em seguida;
o Praticamente todos os modelos e diagramas elaborados na fase de anlise
podem ser refinados na fase de projeto, incorporando detalhes relativos
soluo especfica a ser adotada. Modelos de classes, de casos de uso,
diagramas de estados, de sequncia e de atividades, por exemplo, podem
ter verses de anlise e projeto. Contudo, nem sempre vale pena refinar
todos esses diagramas. Deve-se avaliar criteriosamente quais deles refinar
na fase de projeto.
Adote a simplicidade: pressuponha que a soluo mais simples a melhor e

mantenha os modelos to simples quanto puder. No modele seu sistema em
excesso hoje, mostrando caractersticas adicionais no requeridas.
Conhea os modelos e as ferramentas usadas para cri-los: Entenda o propsito

de cada modelo / diagrama, seus pontos fortes e fracos e as principais notaes a
serem empregadas em cada fase do processo de desenvolvimento. Conhea
tambm as ferramentas usadas para cri-los e suas limitaes. Isso dar agilidade
ao desenvolvimento de modelos.
Ao considerar esses princpios na modelagem segundo o paradigma orientado a

objetos, chega-se ao seguinte conjunto de orientaes:
Modelos de casos de uso e de classes so essenciais para o desenvolvimento e

devem ser elaborados durante a anlise de requisitos. Descries de casos de uso
completas s devem ser elaboradas para casos de uso mais complexos, tipicamente

164
aqueles relacionados aos principais processos de negcio sendo apoiados pelo

sistema em desenvolvimento.
Diagramas de estados s devem ser elaborados para classes com comportamento

dependente do estado. Recomenda-se elaborar diagramas de estados apenas para as
classes que possurem trs ou mais estados relevantes. Se julgado til para a
compreenso, pode ser elaborado um diagrama de estados para uma classe com
apenas dois estados relevantes. Entretanto, deve-se avaliar se o mesmo no pode
ser descartado aps cumprir seu propsito, no sendo incorporado documentao
do projeto.
Diagramas de atividades s devem ser elaborados quando forem teis para refinar
o entendimento provido pela descrio de um caso de uso complexo, normalmente
com vrias atividades paralelas, iterativas, condicionais ou alternativas. Diagramas
de atividades tambm so uma boa opo para a modelagem de processos de
negcio (ver Seo 3.3).
Em relao ao refinamento de modelos e diagramas na fase de projeto, de maneira

geral, modelos de classe devem ser refinados, uma vez que eles so a base para a
implementao. O mesmo no ocorre com os modelos comportamentais (modelos
de casos de uso, diagramas de estados, sequncia e atividades), os quais, na
maioria das vezes, basta manter a verso de anlise.
8.3 Reutilizao na Engenharia de Requisitos

A reutilizao no desenvolvimento de software tem como objetivos melhorar o
cumprimento de prazos, diminuir custos e obter produtos de maior qualidade (GIMENES;
HUZITA, 2005). Artefatos de software so reutilizados com o intuito de diminuir o tempo de
desenvolvimento, investindo-se esforo na sua adaptao ao invs de se investir esforo na
sua construo a partir do zero. Ao longo do processo de software, diversos tipos de artefatos
podem ser reutilizados, dentre eles modelos, especificaes, planos, cdigo-fonte etc. Nesta
seo, o foco na reutilizao como apoio Engenharia de Requisitos.
Analisando o processo de Engenharia de Requisitos, possvel notar que a reutilizao
pode ser til, sobretudo no reso de requisitos de sistemas similares e de modelos conceituais.
Contudo, na prtica, na grande maioria das vezes, requisitos e modelos so construdos a
partir do zero. Ou seja, requisitos de usurio so levantados junto aos interessados e
posteriormente refinados em requisitos de sistema, quando modelos so construdos levandose em conta os requisitos inicialmente capturados. Entretanto, essa abordagem tem se
mostrado insuficiente, pois desconsidera a reutilizao do conhecimento j existente na
organizao acerca do domnio do problema (FALBO et al., 2007).
Ao especificar requisitos para um sistema interessante ter em mente que muito
provavelmente algum j desenvolveu algum sistema muito parecido ou at mesmo idntico
ao que est sendo desenvolvido. Assim, caso se tenha acesso aos requisitos de um sistema
similar ao que ser desenvolvido, certamente o esforo para se obter requisitos para o mesmo
ser bem menor (ROBERTSON; ROBERTSON, 2006).
O reso na Engenharia de Requisitos tem por objetivo a utilizao de requisitos (e
outros artefatos relativos s fases da Engenharia de Requisitos) de projetos anteriores com o
intuito de auxiliar a obteno dos requisitos para um novo sistema a ser desenvolvido.

165
Requisitos podem ser reutilizados de diversas maneiras, dentre elas pelo reso de
especificaes de projetos similares ao projeto atual, informalmente atravs da experincia
das pessoas ou pela reutilizao de artefatos desenvolvidos previamente com vistas ao reso.
Por exemplo, ao se analisar um projeto similar, desenvolvido para um mesmo domnio de
aplicao, pode-se concluir que diversos requisitos funcionais, no funcionais e at regras de
negcio podem se aplicar ao novo projeto em desenvolvimento. Neste caso, os requisitos
podem ser copiados, e adaptados, quando necessrio, de um projeto para o outro. Outra
abordagem bastante utilizada pelas organizaes consiste em definir equipes que atuam
sistematicamente em um certo domnio de aplicaes, de modo que seus membros possam
reutilizar o conhecimento que tm sobre esse domnio no desenvolvimento de novos projetos.
Ainda que essas abordagens mais informais e oportunistas tragam alguns benefcios,
elas no exploram adequadamente as potencialidades de uma reutilizao sistemtica. Em
uma abordagem sistemtica de desenvolvimento para e com reutilizao, primeiramente
artefatos so concebidos explicitamente para serem reutilizados. Depois, os projetos de
desenvolvimento reutilizam esses artefatos, fazendo as adaptaes necessrias. Uma vez que
esses itens tenham sido desenvolvidos para reso, o esforo de adaptao e reutilizao tende
a ser menor. Assim, para se obter os reais benefcios da reutilizao, importante que os
artefatos j sejam desenvolvidos pensando no reso posterior. Neste contexto, merecem
destaque trs abordagens, discutidas na sequncia: Engenharia de Domnio, Ontologias e
Padres de Anlise.
8.3.1 Engenharia de Domnio

A Engenharia de Domnio representa um enfoque sistemtico para a produo de
componentes reutilizveis que engloba atividades de anlise, projeto e implementao de
domnio, as quais objetivam, respectivamente, representar requisitos comuns de uma famlia
de aplicaes por meio de modelos de domnio, disponibilizar modelos arquiteturais para
aplicaes a partir de um nico modelo de domnio e disponibilizar implementaes de
componentes que representam funcionalidades bsicas de aplicaes relacionadas a um
domnio (GIMENES; HUZITA, 2005).
A Anlise de Domnio a atividade diretamente ligada reutilizao na Engenharia de
Requisitos. A Anlise de Domnio visa capturar os elementos relevantes de um domnio de
aplicaes e disponibiliz-los para serem utilizados no desenvolvimento de diferentes
sistemas de apoio a negcios neste domnio. Assim, a Anlise de Domnio busca explicitar e
modelar aspectos de domnio, produzindo artefatos (tipicamente modelos) que contm
informaes sobre o domnio e que podem ser reutilizados no desenvolvimento de sistemas.
Pode-se fazer um paralelo entre a Anlise de Domnio e a Anlise de Requisitos:
ambas enfocam a modelagem conceitual de um domnio de aplicaes. Entretanto, enquanto a
anlise de requisitos convencional enfoca a modelagem dos aspectos do domnio que so
relevantes para um sistema especfico, a anlise de domnio mais abrangente e visa capturar
elementos de informao do domnio potencialmente relevantes para o desenvolvimento de
diversos sistemas neste domnio, estando, portanto, em nvel mais alto de abstrao. Em
outras palavras, ao invs de explorar requisitos de uma aplicao especfica, na anlise de
domnio, os requisitos explorados dizem respeito a uma famlia de aplicaes de uma
determinada rea (ARANGO; PRIETO-DAZ, 1994). Neste sentido, pode-se considerar que a
Anlise de Domnio direciona a Engenharia de Requisitos, pois seus modelos de domnio,

166
mais abstratos, fornecem uma base para o trato com requisitos no contexto de um projeto
especfico.
Para se fazer uma anlise de domnio, pode-se trabalhar de maneira anloga anlise
de requisitos convencional, consultando-se especialistas do domnio e modelando o
conhecimento capturado, de modo que esse conhecimento possa ser reutilizado nos vrios
projetos que faam parte desse domnio (ROBERTSON; ROBERTSON, 2006). H, ainda,
diversos mtodos de anlise de domnio, os quais procuram explorar as especificidades dessa
atividade, dentre eles FODA, ODM, EDLC, FORM, RSEB e Catalysis (GIMENES;
HUZITA, 2005). Contudo, qualquer que seja a abordagem de anlise de domnio empregada,
deve-se ter em mente que um modelo de domnio deve conter os elementos comuns s vrias
aplicaes do domnio e no detalhes especficos de uma ou de todas as aplicaes. Assim,
para ser realmente reutilizvel, um modelo de domnio deve ser mais geral e abstrato,
contendo o conhecimento de senso comum a respeito do domnio, sem incluir detalhes que
podem ser relevantes apenas para uma ou para poucas aplicaes.
Deve-se apontar, ainda, que a anlise de domnio apenas ser uma abordagem
interessante, caso haja uma real necessidade de reso no domnio em questo. A anlise de
domnio uma atividade complexa que consome tempo e recursos, podendo ser anterior ou
paralela a um processo de desenvolvimento de software. Assim, se no houver uma real
possibilidade de reso nesse domnio, a anlise de domnio torna-se invivel.
A Figura 8.2 ilustra o processo de Engenharia de Domnio e como ele pode apoiar o
processo de desenvolvimento de um sistema de software.
Figura 8.2 Abordagens para e com Reso na Engenharia de Domnio.

Nuseibeh e Easterbrook (2000), em seu mapa para o futuro da Engenharia de
Requisitos, colocaram o reso de modelos como um dos maiores desafios da Engenharia de
Requisitos para os anos 2000. Eles acreditavam que, para muitos domnios de aplicao,
modelos de referncia para especificao de requisitos seriam desenvolvidos, de modo que o

167
esforo de desenvolver modelos de requisitos a partir do zero fosse reduzido. De alguma

forma, isso, de fato, vem ocorrendo, ainda que no propriamente na forma de modelos de
referncia, mas por meio da construo de diversas ontologias de domnio e pelo crescente
nmero de padres de anlise disponveis (FALBO et al., 2007), assuntos discutidos a seguir.
8.3.2 Ontologias de Domnio

Uma grande dificuldade atual no desenvolvimento de sistemas para apoiar processos
de negcio em um mesmo domnio, sobretudo quando os mesmos precisam trabalhar de
maneira integrada, a existncia de diversas vises parciais sobre esse domnio. Cada viso
parcial carrega consigo um vocabulrio e determinados valores prprios, dificultando a
integrao entre os diversos profissionais pela ausncia de padronizao. Esse problema pode
ser minimizado se a conceituao envolvida no domnio for, pelo menos parcialmente,
explicitada, o que pode ser feito por meio de uma ontologia de domnio.
Uma ontologia de domnio um artefato de engenharia que busca explicitar a
conceituao de um domnio particular. Uma conceituao, por sua vez, corresponde ao
conjunto de conceitos usados para interligar abstraes de entidades de um dado domnio.
Assim, uma ontologia de domnio tem como objetivo explicitar e formalmente definir os
conceitos, relaes, propriedades e restries em um domnio particular (GUIZZARDI, 2005).
Ontologias de domnio tm diversos usos, dentre eles (JASPER; USCHOLD, 1999):
(i) apoio comunicao entre pessoas envolvidas no domnio; (ii) integrao de dados e
interoperabilidade de sistemas desenvolvidos para o domnio e (iii) especificao reutilizvel
para a construo de sistemas no domnio.
Ontologias de domnio podem ser usadas como modelos de domnio em uma
abordagem de Engenharia de Domnio. Assim, como discutido na seo anterior, pode-se
pensar que o processo de Engenharia de Domnio, neste caso, envolveria atividades de
Modelagem da Ontologia, Projeto da Ontologia e Implementao da Ontologia. Do ponto de
vista da Engenharia de Requisitos, est-se mais interessado em ontologias como modelos
conceituais. Assim, o foco est nas ditas ontologias de referncia, as quais representam um
modelo de consenso dentro de uma comunidade. Uma ontologia de referncia uma
especificao independente de soluo, com o objetivo de fazer uma descrio clara e precisa
de entidades do domnio, para propsitos de comunicao, aprendizado e resoluo de
problemas (ZAMBORLINI; GONALVEZ; GUIZZARDI, 2008).
Vale a pena destacar similaridades e diferenas entre modelos de domnio em uma
abordagem tradicional de Engenharia de Domnio e em uma abordagem baseada em
ontologias. Ambos tm como propsito capturar a conceituao de um certo domnio, estando
em um nvel de abstrao mais elevado do que um modelo conceitual de um sistema.
Entretanto, ontologias so desenvolvidas com vrios propsitos em mente (e no somente de
servir como uma especificao base para o desenvolvimento de sistemas), o que faz com que
tenha de ser especificada com mais rigor, normalmente exigindo o consenso em uma
comunidade, tornando-a mais geral do que modelos de domnio.
Uma vez que uma ontologia um artefato complexo de engenharia, ela deve ser
construda usando mtodos apropriados. H diversos mtodos existentes para o
desenvolvimento de ontologias, dentre eles SABiO (FALBO, 2004), Neon (SUREZFIGUEROA et al., 2007) e Methontology (GOMEZ-PEREZ; CORCHO; FERNANDEZLOPEZ, 2007).

168
8.3.3 Padres de Anlise

Padres de software formalizam solues para problemas recorrentes no
desenvolvimento de software, com base na experincia de especialistas, permitindo que essas
solues possam ser reutilizadas em vrias outras situaes, por outros especialistas. Na
engenharia de software, padres so usados para descrever solues de sucesso para
problemas de software comuns. Esses padres refletem a estrutura conceitual dessas solues
e podem ser aplicados vrias vezes na anlise, projeto e produo de aplicaes, em um
contexto particular (DEVEDZIC, 1999). O uso pelos engenheiros de software de solues j
conhecidas e testadas ajuda a aumentar o nvel de abstrao, a produtividade e a qualidade dos
projetos nas vrias fases do desenvolvimento de sistemas (COTA, 2004).
No contexto de desenvolvimento de software, padres procuram representar a
experincia de muitos esforos de reengenharia de desenvolvedores que tentaram adquirir
maior reusabilidade e flexibilidade em seus produtos de software. Representam tambm, a
formalizao de uma soluo para determinada situao que desenvolvedores sempre se
depararam na sua experincia em desenvolver sistemas. Diante de uma situao recorrente,
observa-se que pode ser aplicada uma soluo que j foi adotada em vrios contextos e, com
isso, estabelece-se um padro.
Os desenvolvedores no inventam padres de software, descobrem-nos da experincia
em construir sistemas na prtica (DEVEDZIC, 1999). Em outras palavras, os padres so
descobertos e no inventados. Por exemplo, modelos se tornam padres somente quando se
descobre que eles podem ter uma utilidade comum. Ou seja, padres so coisas que os
desenvolvedores conhecem e reconhecem que podem ser teis em diferentes contextos. Ou
seja, a partir da anlise de diversos eventos de negcio do mesmo tipo, um padro de anlise
pode ser derivado por meio da abstrao de elementos comuns (ROBERTSON;
ROBERTSON, 2006). Com um padro, apresentada uma aproximao genrica para
resolver um problema. Assim, padres tm que ser trabalhados e adaptados para casos
especficos.
Padres existem em vrias fases do desenvolvimento de software. A comunidade de
padres de software primeiro descobriu, descreveu e classificou um certo nmero de padres
de projeto (GAMMA et al.,1995). Mais recentemente foram identificados outros padres
relacionados a outras fases e aspectos do desenvolvimento de software, como os padres de
anlise (FOWLER, 1997) e padres para arquiteturas de software (FOWLER, 2003). Para a
Engenharia de Requisitos, os padres de interesse so os padres de anlise.
Padres de anlise so definidos a partir de modelos conceituais de aplicaes. Ao se
criar um modelo conceitual, os analistas percebem que muitos aspectos de projetos anteriores
se repetem. Se ideias usadas em projetos anteriores so teis atualmente, ento, eles
melhoram essas ideias e as adaptam para atender a uma nova demanda. Para reutilizar um
padro de anlise em outra aplicao, preciso reinterpretar cada classe no padro como uma
classe correspondente no novo sistema. A estratgia a abstrao do modelo inicial, de onde
novos modelos podem ser desenvolvidos.
Fowler (1997) se refere a padres de anlise como grupos de conceitos que
representam uma construo comum na modelagem de negcios. Eles podem ser relevantes
para somente um domnio ou podem ser expandidos para vrios domnios. Os padres de
anlise lidam com problemas gerais de modelagem, sendo apresentados atravs de um
problema particular em um domnio, onde mais fcil de entend-los. Conhecendo-os, so
identificadas inmeras situaes onde aplic-los. No citado livro, so descritos padres para

169
vrios domnios de negcios, de acordo com a experincia pessoal do autor em aplicar

modelagem de objetos a sistemas de informao de grandes corporaes.
Padres de maneira geral so registrados em catlogos. Um catlogo de padres uma
coleo de padres com uma estrutura e uma organizao. Os padres so subdivididos em
categorias e h relaes entre eles. A classificao em um catlogo facilita o aprendizado e
direciona os esforos para encontrar novos padres, torna-os teis para os leitores, que podem
lembrar dos padres, identific-los em diferentes situaes e reutiliz-los no desenvolvimento
de algum sistema. Para tal, a cada padro de software dado um nome, que serve como um
guia para facilitar a discusso do padro e a informao que ele representa.
Um dos catlogos de padres de anlise mais conhecidos o descrito por Fowler em
seu livro Analysis Patterns: Reusable Objects Models (Padres de Anlise: Modelos de
Objetos Reutilizveis) (FOWLER, 1997), onde h mais de 40 padres de anlise, contendo
modelos j aplicados em projetos nos quais o autor trabalhou. Os padres neste catlogo so
organizados em dez categorias principais, a saber: Responsabilidades, Observaes e
Medies, Observaes para Finanas Coorporativas, Referncia a Objetos, Inventrio e
Contabilidade, Uso de Modelos de Contabilidade, Planejamento, Negociao, Contratos
Derivados e Pacotes de Negociao.
Os padres de anlise relativos a responsabilidades, por exemplo, buscam capturar
situaes em que uma pessoa ou organizao responsvel por outra. uma noo abstrata
que pode empregada em vrias situaes, incluindo estrutura organizacional, contratos e
relaes de emprego. Dentre os padres dessa categoria podem ser citados: Parte (Party),
Hierarquia Organizacional (Organization Hierarquies) e Estrutura Organizacional
(Organization Structure).
Os padres de anlise de negociao, por sua vez, tratam o comrcio de mercadorias
sob uma perspectiva de vendedor / comprador. Esses padres tratam compra e venda de
mercadorias e o valor dessas mercadorias com respeito s mudanas nas condies de
mercado. Nesta categoria h, dentre outros, os seguintes padres: Contrato (Contract) e
Carteira de Negcios (Portfolio).
As figuras 8.3, 8.4 e 8.5 mostram alguns exemplos de modelos estruturais propostos
em padres de anlise, adaptados de (FOWLER, 1997). Na Figura 8.3, apresentado o padro
Pessoa, cujo propsito tratar situaes em que pessoas fsicas e jurdicas tm
responsabilidades similares. Neste caso, a soluo adotada criar um tipo Pessoa, como um
supertipo de Pessoa Fsica e Pessoa Jurdica, reunindo propriedades comuns s duas.
Figura 8.3 Padro de Anlise Pessoa.

170
As figuras 8.4 e 8.5 mostram diferentes verses de um mesmo padro: o padro Plano.
O problema envolvido neste caso o planejamento de aes. Na verso da Figura 8.4,
considera-se que uma ao definida exclusivamente para um plano. Na verso da Figura 8.5,
considera-se que uma ao proposta pode fazer parte de diversos planos.
Figura 8.4 Padro de Anlise Plano Verso 1.
Figura 8.5 Padro de Anlise Plano Verso 2.

Utilizar ontologias e padres de anlise para a modelagem conceitual de sistemas abre
espao para uma viso mais abrangente do domnio tratado, levando a um melhor
entendimento do mesmo. Isso pode diminuir o tempo gasto na especificao de requisitos,
pois os analistas j tm uma fonte preliminar para aprender sobre o domnio, que estabelece
uma terminologia comum aos especialistas do negcio (COTA, 2004).
Padres de Anlise, assim como ontologias, descrevem aspectos no nvel de
conhecimento. Assim, uma vez que eles proveem conhecimento sobre solues bem
sucedidas a problemas recorrentes no desenvolvimento de software, eles favorecem a
reutilizao. No entanto, ontologias capturam a estrutura conceitual intrnseca de um domnio,
enquanto padres de anlise focalizam a estrutura de uma aplicao (DEVEDZIC, 1999).
Em (FALBO et al., 2007) proposto um processo de Engenharia de Requisitos
baseado em reutilizao de ontologias e padres de anlise, voltado para o desenvolvimento

171
de sistemas de informao. O processo proposto visa contribuir para a institucionalizao de

prticas de reso na Engenharia de Requisitos. O processo comea com um levantamento
preliminar de requisitos, cujo objetivo definir o escopo do projeto e enumerar os principais
requisitos funcionais e no-funcionais. Paralelamente, um modelo conceitual elaborado,
tomando por base ontologias e padres de anlise relacionados ao domnio do problema. Os
requisitos so ento detalhados e os modelos detalhados. Como produto, um documento de
especificao de requisitos produzido.
Em (AMBLER, 2004) so apresentados em detalhes os princpios e valores da
modelagem gil. Em especial, os captulos 3 e 4 apresentam os princpios dessa abordagem.
Em (GIMENES; HUZITA, 2005), o Captulo 3 aborda aspectos relacionados
Engenharia de Domnio.
Finalmente, em (FOWLER, 2007), so apresentados diversos padres de anlise. Em
especial, os captulos de 2 a 11 apresentam diversos padres de anlise agrupados em
categorias.
AMBLER, S.W., Modelagem gil: Prticas Eficazes para a Programao eXtrema e o
Processo Unificado, Porto Alegre: Bookman, 2004.
ARANGO, G., PRIETO-DAZ, R., Domain Analysis Concepts and Research Directions,
Workshop on Software Architecture, USC Center for Software Engineering, Los Angeles,
EUA, 1994.
Elsevier, 2006.
COTA, R.I.; Um Estudo sobre o Uso de Ontologias e Padres de Anlise na Modelagem de
Sistemas de Gesto Empresarial. Dissertao de Mestrado, Mestrado em Informtica,
UFES, 2004.
DEVEDZIC, V.; Ontologies: Borrowing from Software Patterns, Intelligence, vol. 10, issue
3 (Fall 1999), 1999, p. 14-24.
FALBO, R. A.; Experiences in Using a Method for Building Domain Ontologies
Proceedings of the 16th International Conference on Software Engineering and Knowledge
Engineering, International Workshop on Ontology In Action, Banff, Canada, 2004.
FALBO, R.A., MARTINS, A.F., SEGRINI, B.M., BAICO, G., DAL MORO, R., NARDI,
J.C.; Um Processo de Engenharia de Requisitos Baseado em Reutilizao e Padres de
Anlise, VI Jornadas Iberoamericanas de Ingeniera del Software e Ingeniera del
Conocimiento (JIISIC07), Lima, Peru, 2007.
FOWLER, M.; Analysis Patterns: Reusable Object Models. Addison-Wesley Professional
Computing Series, 1997.
FOWLER, M., Patterns of Enterprise Application Architecture, Addison-Wesley, 2003.

172
GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J.M., Design Patterns - Elements of
Reusable Object-Oriented Software. Addison-Wesley, 1995.
GIMENES, I.M.S., HUZITA, E.H.M.; Desenvolvimento Baseado em Componentes:
Conceitos e Tcnicas. Editora Cincia Moderna, 2005.
GMEZ-PREZ, A., CORCHO, O., FERNANDEZ-LOPEZ, M.; Ontological Engineering:
with examples from the areas of Knowledge Management, e-Commerce and the Semantic
Web, 2nd edition, Springer, 2007.
GUIZZARDI, G., Ontological Foundations for Structural Conceptual Models, Telematics
Instituut Fundamental Research Series, The Netherlands, 2005.
JASPER, R., USCHOLD, M.; A Framework for Understanding and Classifying Ontology
Applications, Proceedings of the IJCAI99 Workshop on Ontologies and Problem-Solving
Methods, Stockholm, Sweden, 1999.
NUSEIBEH, B., EASTERBROOK, S., Requirements Engineering: A Roadmap, In:
Procedings of the Future of Software Engineering, ICSE2000, Ireland, 2000, p. 37-46.
SUREZ-FIGUEROA, M.A., et al., NeOn Development Process and Ontology Life Cycle,
2007.
Disponvel
em
http://www.neon-project.org/webcontent/index.php?option=com_weblinks&view=category&id=17&Itemid=73.
ZAMBORLINI, V., GONALVEZ, b., GUIZZARDI, G.; Codification and Application of a
Well-Founded Heart-ECG Ontology, Proceedings of the 3rd Workshop on Ontologies
and Metamodels in Software and Data Engineering, Campinas, Brazil, 2008.

173
A ISO/IEC 9126 uma famlia de normas que trata da avaliao da qualidade de

produtos de software. Ela estabelece um modelo de qualidade para produtos de software e
apresenta diversas medidas para aferir qualitativa e quantitativamente a presena dos atributos
de qualidade descritos em seu modelo. A ISO/IEC 9126 dita uma famlia ou srie de
normas, pois dividida em partes, a saber:
Parte 1 Modelo da qualidade

Parte 2 Mtricas externas
Parte 3 Mtricas internas
Parte 4 Mtricas de qualidade em uso
A ISO/IEC 9126 encontra-se em fase de transio para uma nova famlia de normas, a
ISO/IEC 25000 - Software Product Quality Requirement and Evaluation (SQuaRE).
Entretanto, o modelo de qualidade de produto de software proposto nessa norma continua
vlido. Esse modelo, descrito na ISO/IEC 9126-1 (ISO/IEC, 2001), dividido em duas partes:
(i) qualidade interna e externa; (ii) qualidade em uso.
O modelo de qualidade interna e externa especifica seis caractersticas, as quais so
por sua vez subdivididas em subcaractersticas. Essas subcaractersticas so manifestadas
externamente quando o software utilizado e so resultado de atributos internos. Qualidade
externa a qualidade do produto percebida quando o software executado, ou seja, uma
percepo da qualidade do ponto de vista do usurio. A qualidade interna, por sua vez, referese percepo da qualidade do ponto de vista de desenvolvedores. A Figura A.1 mostra o
modelo de qualidade interna e externa da ISO/IEC 9126-1, suas seis caractersticas de
qualidade, desdobradas em subcaractersticas.
Qualidade
externa e interna
Funcionalidade
Adequao
Acurcia
Interoperabilidade
Segurana de
acesso
Conformidade
Confiabilidade
Maturidade
Tolerncia a Falhas
Recuperabilidade
Conformidade
Usabilidade
Inteligibilidade
Apreensibilidade
Operacionalidade
Atratividade
Conformidade
Eficincia
Manutenibilidade
Comportamento em
relao ao tempo
Comportamento em
relao aos recursos
Analisabilidade
Modificabilidade
Estabilidade
Testabilidade
Conformidade
Conformidade
Portabilidade
Adaptabilidade
Capacidade para
ser instalado
Co-existncia
Capacidade para
substituir
Conformidade
Figura A.1 Modelo de Qualidade da ISO/IEC 9126-1 para Qualidade Externa e

Interna (adaptado de ISO/IEC, 2001).

174
importante notar que em todas as caractersticas temos uma subcaracterstica

denominada conformidade. A conformidade se refere capacidade do produto de software de
estar de acordo com normas, convenes ou regulamentaes em leis e prescries similares
relacionadas caracterstica de qualidade em questo. Ela utilizada para avaliar o quanto o
software obedece aos requisitos de legislao e todo o tipo de padronizao ou normalizao
aplicvel ao contexto.
O modelo de qualidade em uso especifica quatro caractersticas, mas no apresenta o
modelo de qualidade abaixo do nvel de caracterstica. Qualidade em uso mede o quanto um
usurio pode alcanar de seus objetivos num ambiente particular. Seu foco no uso do
software e no nas propriedades do software em si.
Uma vez que o enfoque da qualidade em uso no recai sobre as propriedades do
software em si, as caractersticas de qualidade em uso so mais importantes para a avaliao
de produtos de software do que para a definio de requisitos. Para apoiar a definio de
requisitos, a parte do modelo relativa qualidade interna e externa mais relevante.
A seguir, so descritas as caractersticas de qualidade enumeradas na ISO/IEC 9126-1.
Caractersticas de Qualidade Externa e Interna
As seis caractersticas de qualidade externa e interna descritas na ISO/IEC 9126-1
(ISO/IEC, 2001) so:
Funcionalidade: refere-se existncia de um conjunto de funes que satisfaz s

necessidades explcitas e implcitas e suas propriedades especficas. Tem como
subcaractersticas:
o Adequao: capacidade do produto de software de prover um conjunto
apropriado de funes para tarefas e objetivos do usurio especificados;
o Acurcia: capacidade do produto de software de prover resultados ou
efeitos corretos ou acordados com o grau de preciso necessrio;
o Interoperabilidade: capacidade do produto de software de interagir com um
ou mais sistemas especificados;
o Segurana de Acesso: capacidade do produto de software de proteger
informaes e dados de forma que pessoas ou sistemas no autorizados
no possam l-los nem modific-los e pessoas ou sistemas autorizados no
faam acessos danosos a eles;
Confiabilidade: diz respeito capacidade do software manter seu nvel de

desempenho, sob condies estabelecidas, por um perodo de tempo. Tem como
subcaractersticas:
o Maturidade: capacidade do produto de software de evitar falhas decorrentes
de defeitos no software;
o Tolerncia a Falhas: capacidade do produto de software de manter um nvel
de desempenho especificado em casos de defeitos no software ou de
violao de sua interface especificada;

175
o Recuperabilidade: capacidade do produto de software de reestabelecer seu

nvel de desempenho e recuperar os dados diretamente afetados no caso de
uma falha;
Usabilidade: refere-se capacidade do produto de software ser compreendido,

aprendido, usado pelo usurio e atrativo ao usurio, quando usado sob condies
especificadas. Tem como subcaractersticas:
o Inteligibilidade: capacidade do produto de software de permitir ao usurio
compreender se o software se aplica a suas necessidades e como ele pode
ser usado para determinadas tarefas e condies de uso;
o Apreensibilidade: capacidade do produto de software de permitir ao usurio
aprender sua aplicao;
o Operacionalidade: capacidade do produto de software de permitir o usurio
oper-lo e control-lo;
o Atratividade: capacidade do produto de software de ser atrativo ao usurio;
Eficincia: diz respeito capacidade do produto de software de fornecer

desempenho apropriado, relativo quantidade de recursos usados, sob condies
especificadas. Tem como subcaractersticas:
o Comportamento em relao ao tempo: capacidade do produto de software
de fornecer tempo de resposta e tempo de processamento apropriados e
taxas de throughput quando executando suas funes, sob condies
estabelecidas;
o Comportamento em relao aos recursos: capacidade do produto de
software de usar quantidade e tipos de recursos apropriados quando o
software executa suas funes sob condies estabelecidas;
Manutenibilidade: concerne ao esforo necessrio para se fazer modificaes no

software. Tem como subcaractersticas:
o Analisabilidade: capacidade do produto de software de permitir o
diagnstico de deficincias ou causas de falhas no software, ou a
identificao de partes a serem modificadas;
o Modificabilidade: capacidade do produto de software de permitir que a
modificao especificada seja implementada;
o Estabilidade: capacidade do produto de software de minimizar efeitos
inesperados de modificaes de software;
o Testabilidade: capacidade do produto de software permitir que o software
modificado ser testado;
Portabilidade: refere-se capacidade do software ser transferido de um ambiente

para outro. Tem como subcaractersticas:
o Adaptabilidade: capacidade do produto de software de ser adaptado para
diferentes ambientes especificados sem necessidade de aplicao de outras
aes ou meios alm daqueles fornecidos para essa finalidade pelo software
considerado;

176
o Capacidade para ser Instalado: capacidade do produto de software para ser

instalado em um ambiente especificado;
o Coexistncia: capacidade do produto de software para coexistir com outros
softwares independentes em um ambiente comum compartilhando recursos
comuns;
o Capacidade para Substituir: capacidade do produto de software para ser
usado em substituio de outro produto de software especificado para o
mesmo propsito no mesmo ambiente.
Caractersticas de Qualidade em Uso
As quatro caractersticas de qualidade em uso descritas na ISO/IEC 9126-1 (ISO/IEC,
2001) so:
Eficcia: capacidade do produto de software de permitir aos usurios atingir metas

especificadas com acurcia e completude em um contexto de uso especificado;
Produtividade: capacidade do produto de software de permitir ao usurio usar a

quantidade de recursos apropriados em relao eficcia atingida quando o
produto de software utilizado em um contexto de uso especificado;
Segurana: capacidade do produto de software de atingir nveis aceitveis de riscos

de danos para pessoas, negcios, software, propriedades ou ambiente em um
contexto de uso especificado;
Satisfao: capacidade do produto de software satisfazer os usurios em um

contexto de uso especificado.

Notas Aula Engenharia Requisitos

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Notas Aula Engenharia Requisitos

Enviado por

Direitos autorais:

Formatos disponíveis

UFES - Universidade Federal do Esprito Santo

Ricardo de Almeida Falbo

5.1 Atores e Casos de Uso

Captulo 6 Modelagem Conceitual Estrutural

6.1 Identificao de Classes

Captulo 8 Qualidade e Agilidade em Requisitos

Engenharia de Requisitos: Notas de Aula

UFES - Universidade Federal do Esprito Santo

1.1 Desenvolvimento de Software e Engenharia de Requisitos

Atividades de Desenvolvimento (ou Tcnicas): so as atividades diretamente

Atividades de Gerncia: envolvem atividades relacionadas ao gerenciamento do

Atividades de Controle da Qualidade: so aquelas relacionadas com a avaliao da

As atividades de desenvolvimento formam a espinha dorsal do desenvolvimento e so

Engenharia de Requisitos: Notas de Aula

UFES - Universidade Federal do Esprito Santo

Atividades de Controle da Qualidade

Engenharia de Requisitos: Notas de Aula

Nos estgios iniciais de um projeto, requisitos tm de ser levantados, entendidos e

1.2 - A Organizao deste Texto

Captulo 2 Engenharia de Requisitos de Software: inicia discutindo o que so

Captulo 3 Levantamento de Requisitos: prov uma viso geral do processo de

Captulo 4 Anlise de Requisitos: trata da anlise de requisitos, discutindo a

Engenharia de Requisitos: Notas de Aula

Captulo 5 Modelagem de Casos de Uso: discute o papel da modelagem de casos

Captulo 6 Modelagem Estrutural: trata da modelagem dos principais conceitos

Captulo 7 Modelagem Dinmica: aborda os modelos usados para especificar as

Captulo 8 Qualidade e Agilidade em Requisitos: explora tcnicas de leitura de

Engenharia de Requisitos: Notas de Aula

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

Requisitos de um sistema so descries dos servios que devem ser

Um requisito de um sistema uma caracterstica do sistema ou a descrio

Um requisito alguma coisa que o produto tem de fazer ou uma qualidade

Com base nessas e em outras definies, pode-se dizer que os requisitos de um

Requisitos Funcionais: so declaraes de servios que o sistema deve

Requisitos No Funcionais: descrevem restries sobre os servios ou

Engenharia de Requisitos: Notas de Aula

Captulo 2 Engenharia de Requisitos de Software

as opes para criar uma soluo para o problema (PFLEEGER, 2004).

Requisitos de produto: especificam o comportamento do produto (sistema).

Requisitos organizacionais: so derivados de metas, polticas e

Requisitos externos: referem-se a todos os requisitos derivados de fatores

No que se refere aos RNFs de produto, eles podem estar relacionados a

Engenharia de Requisitos: Notas de Aula

Captulo 2 Engenharia de Requisitos de Software

requisitos. Essas regras de negcio geralmente incluem terminologia especfica do

Requisitos de Usurio: so declaraes em linguagem natural

Requisitos de Sistema: definem detalhadamente as funes, servios e

Vale destacar que esses nveis de descrio de requisitos so aplicados em

Documento de Definio de Requisitos, ou somente Documento de

Engenharia de Requisitos: Notas de Aula

Captulo 2 Engenharia de Requisitos de Software

UFES - Universidade Federal do Esprito Santo

forma de uma listagem do qu o cliente espera que o sistema proposto faa.

Documento de Especificao de Requisitos: redefine os requisitos de

2.2 O Processo de Engenharia de Requisitos

Engenharia de Requisitos: Notas de Aula

Captulo 2 Engenharia de Requisitos de Software

UFES - Universidade Federal do Esprito Santo

caractersticas da organizao. Existem, portanto, fatores que contribuem para a

Figura 2.1 Processo de Engenharia de Requisitos (adaptado de (KOTONYA;

Engenharia de Requisitos: Notas de Aula

Captulo 2 Engenharia de Requisitos de Software

visando garantir conformidade em relao a padres e ao processo estabelecidos pela