Apostila Requisitos

Mdulo VI
Requisitos de Software
Pedro de Alcntara dos Santos Neto
FICHA BIBLIOGRFICA
PRESIDENTE DA REPBLICA
Luiz Incio Lula da Silva
MINISTRO DA EDUCAO
Fernando Haddad
GOVERNADOR DO ESTADO DO PIAU
Wilson Martins
UNIVERSIDADE FEDERAL DO PIAU
Luiz de Sousa Santos Jnior
SECRETRIO DE EDUCAO A DISTNCIA DO MEC
Carlos Eduardo Bielschowsky
COORDENADORIA GERAL DA UNIVERSIDADE ABERTA DO BRASIL
Celso Costa
SECRETRIO DE EDUCAO DO ESTADO DO PIAU
Antnio Jos Medeiros
COORDENADOR GERAL DO CENTRO DE EDUCAO ABERTA A
DISTNCIA DA UFPI
Gildsio Guedes Fernandes
SUPERITENDENTE DE EDUCAO SUPERIOR NO ESTADO
Eliane Mendona
CENTRO DE CIENCIAS DA NATUREZA
Helder Nunes da Cunha
COORDENADOR DO CURSO DE SISTEMA DE INFORMAO NA
MODALIADE DE EAD
Lus Cludio Demes da Mata Souza
COORDENADORA DE MATERIAL DE DIDTICO DO CEAD/UFPI
Cleidinalva Maria Barbosa Oliveira
DIAGRAMAO
Joaquim Carvalho de Aguiar Neto
APRESENTAO
Um Sistema de Informao (SI), ou qualquer outro software,

tem seu incio associado idia de desenvolv-lo. A partir desse
momento, necessrio iniciar uma srie de reunies para se
aprofundar conhecimento nas regras que envolvem a operao do
sistema.
O conjunto de atividades que auxilia a obteno de
informaes a respeito de como o sistema deveria ser criado,
juntamente com uma representao desses conceitos em modelos
que sejam utilizados para o desenvolvimento, faz parte das
atividades de Requisitos e Anlise.
Nesta apostila apresentamos um detalhamento dessas
atividades, guiadas a partir de vrios exemplos prticos ilustrando
sua execuo.
Na Unidade I detalhamos os conceitos associados ao Fluxo
de Requisitos, diretamente relacionado obteno de informaes
dos clientes para se elaborar um documento que descreve suas
necessidades.
Na Unidade II apresentamos o Fluxo de Anlise, associado
modelagem das informaes obtidas durante o levantamento de
requisitos, porm, transformando-as em um nvel mais prximo dos
desenvolvedores.
apresentado
tambm
um
mtodo
para
contagem do tamanho de um sistema, baseado na Especificao de

Requisitos e Anlise.
Na Unidade III exibimos os exemplos completos de diversos
artefatos utilizados para exemplificarmos o levantamentos de
requisitos, convocao e exibio dos resultados de uma reunio,
alm da reviso dos requisitos e reviso da anlise.
SUMRIO GERAL

UNIDADE I ................................................................................................... 7
O FLUXO DE REQUISITOS ........................................................................ 7
1. O Fluxo de Requisitos ............................................................................. 9
1.1. Qualidade dos requisitos ................................................................ 10
1.1.1. Correo .................................................................................. 10
1.1.2. Preciso ................................................................................... 11
1.1.3. Completeza .............................................................................. 11
1.1.4. Consistncia ............................................................................ 12
1.1.5. Priorizao............................................................................... 12
1.1.6. Verificabilidade ....................................................................... 12
1.1.7. Modificabilidade ..................................................................... 13
1.1.8. Rastreabilidade ........................................................................ 13
1.2. Atividades do Fluxo de Requisitos ................................................ 14
1.1.9. Definio do Escopo ............................................................... 15
1.1.10. Identificao dos Requisitos ................................................. 18
1.1.11. Detalhamento dos Requisitos ................................................ 22
Detalhamento dos Casos de uso ........................................................... 29
1.1.12. Definio dos Prottipos de Interface ................................... 35
1.1.13. Reviso dos Requisitos ......................................................... 41
1.3. Exerccios ....................................................................................... 42
2. Tcnicas de Apoio ao Levantamento de Requisitos ............................. 45
1.4. Oficinas de requisitos ..................................................................... 45
2.1.1. Personalizao ......................................................................... 46
2.1.2. Sesses .................................................................................... 47
2.1.3. Fechamento ............................................................................. 49
1.5. Revises ......................................................................................... 50
2.1.4. Participantes ............................................................................ 52
2.1.5. Conduo................................................................................. 53
1.6. Exerccios ....................................................................................... 56
UNIDADE II ................................................................................................ 60
ANLISE DE SOFTWARE ........................................................................ 60
3. A Linguagem UML ............................................................................... 62
1.7. A Origem da UML ......................................................................... 62
1.8. Vises ............................................................................................. 64
1.9. Modelo de Elementos ..................................................................... 65
3.1.1. Classes ..................................................................................... 65
3.1.2. Objetos .................................................................................... 67
3.1.3. Estados .................................................................................... 68
3.1.4. Pacotes..................................................................................... 68
3.1.5. Componentes ........................................................................... 69
3.1.6. Relacionamentos ..................................................................... 69
1.10. Mecanismos Gerais ...................................................................... 74
1.11. Diagramas .................................................................................... 75
5
3.1.7. Diagrama de Casos de uso ...................................................... 75

3.1.8. Diagrama de Classes ............................................................... 76
3.1.9. Diagrama de Objetos ............................................................... 76
3.1.10. Diagrama de Estados ............................................................. 77
3.1.11. Diagrama de Seqncia ......................................................... 78
3.1.12. Diagrama de Colaborao ..................................................... 79
3.1.13. Diagrama de Atividades ........................................................ 80
3.1.14. Diagrama de Componentes ................................................... 81
3.1.15. Diagrama de Implantao ..................................................... 81
1.12. Consideraes Finais .................................................................... 82
1.13. Exerccios ..................................................................................... 82
4. O Fluxo de Anlise................................................................................ 84
1.14. Atividades do Fluxo de Anlise ................................................... 84
4.1.1. Identificao das Classes......................................................... 85
4.1.2. Organizao das Classes ......................................................... 94
4.1.3. Realizao dos Casos de Uso .................................................. 95
4.1.4. Reviso da Anlise .................................................................. 97
1.15. Exerccios ..................................................................................... 98
5. Anlise de Pontos de Funo ................................................................ 99
5.1 Introduo a Anlise de Pontos de Funo ................................... 103
5.2 O Processo de Contagem .............................................................. 105
5.2.1 Contagem de Funes de Dados ............................................ 112
5.2.2 Contagem de Funes de Transao ...................................... 114
5.3 Contagem Estimativa de Pontos de Funo .................................. 120
5.3.1 Contagem de funes de dados .............................................. 122
5.3.2 Contagem de funes de transao ........................................ 124
5.4 Planejamento e Gesto de Projetos com PF .................................. 130
5.5 Viso crtica da APF ..................................................................... 131
5.6 Exerccios ...................................................................................... 134
UNIDADE III............................................................................................. 139
EXEMPLOS DE ARTEFATOS ................................................................ 139

UNIDADE I
O FLUXO DE REQUISITOS
RESUMO
Nesta unidade apresentamos o Fluxo de Requisitos, que est
diretamente associado obteno de informaes junto aos clientes
sobre o problema a ser tratado.
Em muitos projetos esse fluxo pouco explorado, o que
normalmente resulta no desenvolvimento de um software que no
atende aos anseios dos usurios finais.
No Capitulo 1 apresentamos as atividades prescritas no fluxo,
com a exemplificao de como realizar cada atividade, a partir da
explicao de como execut-la no sistema exemplo.
No Captulo 2 apresentamos algumas tcnicas utilizadas
como forma de apoiar o levantamento de requisitos, mais
especificamente, tcnicas para se conduzir uma reunio com o
objetivo de se obter informaes e construir um conceito em
conjunto, alm de tcnicas para revisar artefatos produzidos durante
o desenvolvimento de software.
SUMRIO DA UNIDADE
UNIDADE I ................................................................................................... 7
O FLUXO DE REQUISITOS ........................................................................ 7
1. O Fluxo de Requisitos ............................................................................. 9
1.1. Qualidade dos requisitos ................................................................ 10
1.1.1. Correo .................................................................................. 10
1.1.2. Preciso ................................................................................... 11
1.1.3. Completeza .............................................................................. 11
1.1.4. Consistncia ............................................................................ 12
1.1.5. Priorizao............................................................................... 12
1.1.6. Verificabilidade ....................................................................... 12
1.1.7. Modificabilidade ..................................................................... 13
1.1.8. Rastreabilidade ........................................................................ 13
1.2. Atividades do Fluxo de Requisitos ................................................ 14
1.1.9. Definio do Escopo ............................................................... 15
1.1.10. Identificao dos Requisitos ................................................. 18
1.1.11. Detalhamento dos Requisitos ................................................ 22
Detalhamento dos Casos de uso ........................................................... 29
1.1.12. Definio dos Prottipos de Interface ................................... 35
1.1.13. Reviso dos Requisitos ......................................................... 41
1.3. Exerccios ....................................................................................... 42
2. Tcnicas de Apoio ao Levantamento de Requisitos ............................. 45
1.4. Oficinas de requisitos ..................................................................... 45
2.1.1. Personalizao ......................................................................... 46
2.1.2. Sesses .................................................................................... 47
2.1.3. Fechamento ............................................................................. 49
1.5. Revises ......................................................................................... 50
2.1.4. Participantes ............................................................................ 52
2.1.5. Conduo................................................................................. 53
1.6. Exerccios ....................................................................................... 56

UNIDADE I
1. O Fluxo de Requisitos
Um requisito pode ser definido como um desejo, necessidade,
restrio ou expectativa de um cliente com relao a um produto. Ou
seja, um cliente, ao pensar em um produto, possui muitos aspectos
Um requisito pode ser
resumido como algo
desejado por um
usurio, com relao a
um produto.
em sua mente. Esses aspectos necessitam ser capturados,

definidos,
organizados,
verificados
validados
para
ento
chegarmos a uma Especificao de Requisitos. Esse documento o

principal artefato gerado no incio do desenvolvimento de software.
Seu principal objetivo prover um enunciado completo, claro e
preciso dos requisitos de um produto de software.
Logicamente, a gerao de uma especificao de requisitos
para um produto novo bem mais complexa que para produtos
existentes. Em muitos casos, os prprios clientes no sabem ao
certo o que querem. Na verdade, a maioria dos clientes consegue
identificar bem o que no quer. Nesses casos, o uso da prototipao
algo muito recomendado. Mais adiante vamos detalhar essa
tcnica que pode auxiliar bastante o fluxo de requisitos.
importante detalhar de forma precisa o que o Fluxo de
Requisitos. Esse fluxo rene as atividades que visam a obter o
enunciado completo, claro e preciso dos requisitos de um produto de
software. Os requisitos devem ser levantados pela equipe do projeto,
normalmente denominados Analistas de Requisitos (ou Engenheiros
de Requisitos) em conjunto com representantes do cliente, usurios
chaves e at contando com a presena de especialistas da rea de
aplicao, uma vez que o projeto pode envolver conhecimentos no
triviais
que
exijam
presena
de
profissionais
altamente
especializados com a rea de negcio do produto a ser construdo.
O conjunto de tcnicas empregadas para levantar, detalhar,

O conjunto de tcnicas
empregadas para
levantar, detalhar,
documentar e validar os
requisitos de um
produto compe a
Engenharia de
Requisitos.
documentar e validar os requisitos de um produto compe a

Engenharia de Requisitos. O resultado principal do fluxo dos
requisitos o documento de Especificao de Requisitos, que
abreviaremos aqui de ER.
1.1.
Qualidade dos requisitos
Os requisitos de um software correspondem a uma parte

muito importante do desenvolvimento. Por conta disso, necessrio
que eles possuam diversas caractersticas de qualidade, permitindo
assim seu uso de forma adequada e eficiente. A seguir
apresentamos uma lista de caractersticas de qualidade de
requisitos, baseadas nas caractersticas de qualidade de requisitos
existentes no livro de Wilson de Pdua Paula Filho.
As caractersticas citadas nesta seo podem ser utilizadas
como critrios para se realizar uma reviso de requisitos, conforme
ser apresentado mais a frente. Mas para isso, necessrio
entender o que est relacionado a cada uma das caractersticas.
1.1.1.
Correo
Uma Especificao de Requisitos correta se todo requisito

presente nela realmente um requisito do produto a ser construdo.
No existe ferramenta que garanta a correo de uma Especificao
de Requisitos. Para verific-la, deve-se checar a coerncia da
Especificao dos Requisitos do Software com outros documentos
da aplicao, como manuais, protocolos, regras de negcio, etc.
Uma outra forma de se tentar garantir a correo solicitar a
aprovao formal da ER, por parte do cliente, sem a qual o projeto
no poder prosseguir.
Por conta disso que normalmente ao final de um
levantamento de requisitos feita uma reviso do trabalho
10
executado. A idia por trs disso e encontrar falha na qualidade dos

requisitos. Essas falhas podem estar associadas a qualquer uma
das caractersticas apresentadas nessa seo.
1.1.2.
Preciso
Uma ER precisa se todo requisito presente possuir apenas

uma nica interpretao, aceita tanto pelos desenvolvedores quanto
pelos
usurios
chaves.
Em
particular,
uma
ER
deve
ser
compreensvel para todo o seu pblico alvo, e deve ser suficiente

para a especificao dos testes de aceitao do produto.
Recomenda-se a incluso no glossrio da ER de todos os termos
contidos no documento que possam causar ambigidades de
entendimento.
Uma forma de verificar a preciso de uma ER solicitar sua
leitura por pessoas que no tenham participado da sua elaborao,
para analisarmos se possvel entender o que foi especificado de
forma precisa.
1.1.3.
Completeza
Uma ER completa se reflete todas as decises de

especificao que foram tomadas, no contendo clusulas de
pendncias. Uma ER completa deveria conter todos os requisitos
significativos relativos a funcionalidade, desempenho, restries de
desenho, atributos e interfaces externas, alm de definir as
respostas do software para todas as entradas possveis, vlidas e
invlidas, em todas as situaes possveis.
Tambm fundamental para uma ER possuir um glossrio de
todos os termos tcnicos e unidades de medida, facilitando assim
seu entendimento por todos.
bastante comum que organizaes criem suas pseudo ERs
contendo apenas um pedao da especificao do comportamento do
11
software desejado, normalmente ignorando os requisitos no

funcionais.
1.1.4.
Consistncia
Uma ER consistente se no h conflitos entre nenhum dos

subconjuntos de requisitos presentes, tais como conflitos com o
mundo real, como por exemplo, formatos de relatrios ou cores de
sinalizao; conflito lgico ou temporal entre aes, quando, por
exemplo, um requisito diz que a ao A deve ser realizada antes da
ao B, e outro diz o contrrio; e uso de termos diferentes para
designar o mesmo objeto do mundo real, como, por exemplo,
lembrete versus aviso.
Mais uma vez notamos que um reviso fundamental para o
fechamento de uma ER, pois apenas a partir de uma ao como
essa que poderemos descobrir certas incorrees.
1.1.5.
Priorizao
Uma ER priorizada se cada requisito classificado de

acordo com a respectiva importncia e estabilidade. A estabilidade
estima a probabilidade de que o requisito venha a ser alterado no
decorrer do projeto, com base na experincia de projetos correlatos.
A priorizao classifica o requisito de acordo com graus de
importncia atribudos pelos clientes.
A priorizao algo importante pois normalmente os custos e
prazos podem ser bastante limitados, sendo importante descrever o
que mais importante e deve ser tratado primeiro. Da mesma forma,
aquilo que ainda est em processo de mudana no pode ser
considerado para implementao, pois ainda no estvel e
qualquer ao aplicada pode ser trabalho perdido!
1.1.6.
Verificabilidade
12
Uma ER verificvel se todos os seus requisitos so

verificveis. Um requisito verificvel se existir um processo finito,
com custo compensador, que possa ser executado por uma pessoa
ou mquina e que mostre a conformidade do produto final com o
requisito.
1.1.7.
Modificabilidade
Uma ER modificvel se sua estrutura e estilo permitirem a

mudana de qualquer requisito, de forma fcil, completa e
consistente. A modificabilidade geralmente requer que haja uma
organizao coerente, com ndices e referncias cruzadas; ausncia
de redundncia entre requisitos; definio separada de cada
requisito.
Essa caracterstica est diretamente relacionada ao uso de
padres e convenes, de forma que o trabalho seja feito utilizandose formatos pr-definidos e adequados ao uso.
1.1.8.
Rastreabilidade
Uma ER rastrevel se permite a fcil determinao dos itens

que antecederam o surgimento do item e os itens que foram gerados
por conta da existncia do item. Isso normalmente est associado a
dois tipos de rastreabilidade:
Rastreabilidade para trs, na qual deve ser possvel localizar

a origem de cada requisito. Deve-se sempre saber por que
existe cada requisito e quem ou o que o originou. Isso
importante para que se possa avaliar o impacto da mudana
daquele requisito, e dirimir dvidas de interpretao.
Rastreabilidade para a frente, na qual deve ser possvel

localizar quais os resultados do desenvolvimento que sero
afetados por cada requisito. Isso importante para garantir
que os itens de anlise, desenho, cdigo e testes abranjam
13
todos os requisitos e para localizar os itens que sero

afetados por uma mudana nos requisitos.
1.2.
Atividades do Fluxo de Requisitos
O Fluxo de Requisitos composto por vrias atividades, que

devem ser executadas dentro de um processo de desenvolvimento.
Diversos processos de software possuem atividades de requisitos
em suas definies. As atividades que sero explanadas neste texto
representam as atividades mais comuns relacionadas Engenharia
de Requisitos. No entanto, a anlise de um processo de software
especfico pode conter diversas diferenas para as atividades aqui
apresentadas.
Figura 1: Atividades do Fluxo de Requisitos.
As atividades do Fluxo de Requisitos so exibidas na Figura 1.

A figura exibe um diagrama de atividades. O primeiro elemento na
14
figura (uma circunferncia preta) conhecida como atividade inicial.

Ela representa o ponto de partida do fluxo. Os demais retngulos
com os lados arredondados representam atividades. Existem duas
barras de sincronizao na figura, que representam que as
atividades posteriores s iniciam quando a todas as atividades com
ligao sincronizao tenham encerradas. Assim, conforme
exibido, a Reviso dos requisitos apenas tem inicio quando o
Detalhamento dos Requisitos e Detalhamento dos Prottipos de
Interface tenha sido concludas.
A Definio do Escopo a atividade onde o escopo do projeto
vai ser identificado. De forma geral, a partir do escopo deve ser
possvel identificar o que faz parte do projeto e o que no faz parte.
A Identificao dos Requisitos a atividade relacionada
obteno de tudo o que os clientes desejam com relao ao produto.
Isso inclui a definio do comportamento esperado, bem como
outros aspectos que devero ser identificados.
O Detalhamento dos Requisitos a atividade em que os
desenvolvedores, com a ajuda dos clientes, iniciam a desdobrar os
requisitos em funes do produto, de forma que o atendimento seja
completo.
A Definio dos Prottipos de Interface a atividade em que
verses iniciais das interfaces do produto so criadas, com o intuito
maior de deixar claro o que se deseja, reduzindo assim problemas
com requisitos questionveis ou difceis de serem entendidos.
Por fim, a Reviso dos Requisitos a atividade em que feita
uma reviso geral do trabalho realizado, com o intuito de remover
problemas com relao aos requisitos identificados e todos os seus
desdobramentos executados.
1.1.9.
Definio do Escopo
15
O Escopo de um Projeto algo fundamental para o seu

sucesso. Sua definio algo considerado simples, porm, ela deve
ser feita de forma prudente e com a participao dos principais
envolvidos.
Em muitos momentos, o escopo do projeto dever ser reanalisado, pois ele que define o que est includo e o que no est
includo no projeto em questo.
Um escopo mal estruturado poder levar a falhas de
cronograma e de oramento, uma vez que tarefas acima do previsto
podem ser consideradas, ao invs daquilo o que realmente deveria
ter sido includo.
De forma geral, o escopo de um projeto pode ser
simplesmente um texto, que define o que deve fazer parte do
projeto. Neste material, utilizaremos um exemplo para demonstrar
todas as atividades aqui descritas. Ser usado como exemplo
prtico algo muito apropriado ao tema: uma ferramenta para
Gerncia de Requisitos. Esse projeto ser denominado ReqG. Para
isso, precisamos definir o escopo de um projeto cujo objetivo
produzir uma ferramenta para gerenciamento de requisitos. Uma
sugesto de tal escopo pode ser visualizada a seguir:
Gerenciar os requisitos de um projeto de software, registrando todos
os dados associados sua definio, de forma a cobrir todas as
atividades previstas no fluxo de requisitos.
Uma boa forma de
evitar problemas com
os clientes de um
projeto definir bem o
escopo e, para evitar
falsas expectativas,
detalhar o que no faz
parte dele. Por isso
to importante termos
uma seo com os
Limites do Produto.
Na definio acima, podemos notar que o trabalho a ser

realizado foi definido. Certamente, nem todos os que chegarem a ler
o enunciado podero entender por completo o que deve ser feito.
Isso acontece por que apenas as pessoas com conhecimento no
problema e no que est sendo definido, poderiam entender por
completo essa definio. No entanto, ela poder ser revista em
diversos momentos do projeto.
Algo comum definio do escopo , definir tambm, o que
est fora dele. Isso normalmente ajuda aos clientes entenderem de
16
forma mais precisa o que est e o que no est includo no projeto.

A definio do que no est includo de forma explcita evita falsas
expectativas.
Isso
normalmente
favorece
processo
de
comunicao com o cliente.

importante ressaltar que o fluxo de requisitos um fluxo
com grande participao do cliente. Ele quem define praticamente
tudo o que ser produzido nessa fase do desenvolvimento. Assim,
quanto mais mecanismos utilizarmos para facilitar a comunicao
com o cliente, melhores resultados obteremos com sua execuo.
Continuando com nosso exemplo, uma forma interessante de
definir o escopo seria detalhar o que no est includo no projeto.
Essa seo normalmente conhecida como Limites do produto.
Uma sugesto para tal seo seria a seguinte:
1. O ReqG no controlar a execuo de tarefas no projeto, apenas
registrar os dados relacionados a requisitos.
2. O ReqG no gerar documentos editveis com a especificao
de requisitos. Os dados ficam registrados no sistema e s podem
ser alterados por ele.
3. O ReqG no controlar qualquer aspecto do custo ou do
cronograma de execuo.
4. O backup e a recuperao das bases de dados do sistema ficam
a cargo da administrao de dados e no sero providas pelo
ReqG.
5. O ReqG no ter ajuda on-line.
Uma dvida que deve pairar naqueles que iniciam a elicitao
de requisitos justamente saber quem deveria participar dessa
definio.
Normalmente, qualquer organizao possui alguns nveis
hierrquicos em sua constituio. As pessoas no nvel hierrquico
mais alto geralmente possuem um bom conhecimento sobre tudo o
que realizado na organizao. Isso acontece por que eles devem
ser comunicadas e devem acompanhar o que se passa dentro da
instituio. Essas pessoas formam um grupo ideal para se utilizar na
definio de um produto, pois conhecem o todo. Ao aprofundarmos
17
nas definies dos requisitos, necessitaremos da participao de

outras pessoas, com conhecimentos mais aprofundados em
detalhes especficos.
Assim, para levantar requisitos para uma aplicao que
Importante: para se
conhecer bem o que
deve ser feito por um
produto, devemos
comear a conversa
com aqueles que
entendem um pouco de
tudo (diretoria) para
depois iniciarmos um
aprofundamento nos
detalhes (gerncia,
chefias).
controle uma empresa, idealmente deveramos conversar com os

diretores da organizao, uma vez que eles devem saber
exatamente como a organizao funciona. Em seguida, devemos
conversar com os gerentes, pois normalmente existe um gerente
para cada rea prioritria da organizao. Ele conhece tudo o que se
passa em seu setor. Para que seja possvel detalhar o que
realmente feito em cada setor, deveramos conversar com os
funcionrios que executam as atividades ou com os chefes de
setores em um nvel inferior aos gerentes.
Baseado nos exemplos acima, vamos dar incio a um trabalho
prtico, que dever ser feito por cada aluno da disciplina, que
acompanhar este material: a definio de um Software de Controle
de Emprstimos Pessoais. Esse software ser definido por voc
leitor, ao longo deste material. De incio, procure definir o escopo e
os limites do produto, de forma similar ao que fizemos com o
software de gesto de requisitos. Utilize os modelos e o exemplo de
ERSw que estamos apresentando como exemplo e que est contido
na pgina da disciplina.
1.1.10.
Identificao dos Requisitos
A Identificao do Requisitos a atividade que prescreve a

criao de uma lista dos requisitos para a aplicao a ser
desenvolvida. Cada requisito nada mais que um descrio textual
de algo que deveria ser considerada durante o desenvolvimento de
software.
Os requisitos podem ser divididos em dois tipos: requisitos
funcionais e requisitos no funcionais. Os requisitos funcionais esto
diretamente ligadas ao comportamento que a aplicao deve conter.
18
Por exemplo, em um sistema de controle de uma biblioteca, o

Emprstimo de Livro exige que o usurio a tomar um livro
emprestado esteja cadastrado, ativo, que o livro desejado esteja
disponvel, no reservado, no seja cativo e que o usurio no
esteja com cinco livros emprestados, considerando que esse seja o
nmero mximo de emprstimos simultneos permitido. Tudo isso
Requisitos funcionais
esto associados a
comportamento.
Requisitos no
funcionais esto ligados
a caractersticas que o
comportamento deve
possuir.
que foi comentado so detalhes do comportamento que o software

deve ter.
Um outro tipo de requisito so os no funcionais. Nesse caso,
eles no expressam comportamento, mas caractersticas que o
comportamento deve ter. Por exemplo, supondo o mesmo requisito,
Emprstimo de Livro,
podemos exigir como requisito de
desempenho que ele funcione com at 100 usurios simultneos,

gerando respostas em at 8s. Outro requisito no funcional
associado ao emprstimo seria que ele fosse simples de usar,
permitindo que uma pessoa conseguisse utiliz-lo apenas lendo o
manual associado. Observe que tudo o que relatamos neste
pargrafo no trata de comportamento, mas de caractersticas
desejadas ao comportamento especificado no pargrafo anterior.
A lista dos requisitos, conforme comentado, a expresso
que resumo aquilo que os clientes desejam. importante a
participao dos Analistas de Requisitos para que seja possvel
organizar esses pedidos e estruturar o texto que os descreve de
forma que seja possvel analisar e desdobrar esses pedidos em
funes do produto. A Tabela 1 exibe a lista de requisitos para a
ferramenta de gesto de requisitos que queremos construir.
Tabela 1: Exemplo de definio de requisitos.
ID
RF1
Requisito
Requisitos
Descrio
O sistema deve permitir cadastrar e controlar
todos os aspectos relacionados aos requisitos de
um projeto, permitindo visualizar isso e
19
acompanhar sua evoluo, incluindo as pessoas

que trabalharam no projeto, os analistas e
gerente do projeto.
RF2
Casos de uso
O sistema deve possibilitar a especificao dos

casos de uso, registrando sua descrio, atores,
prottipos de tela associados, relacionando aos
requisitos que deram origem ao caso de uso.
RF3
Reviso
Deve ser possvel realizar uma reviso dos

requisitos e casos de uso, utilizando critrios
definidos pelos prprios gerentes de projetos, de
forma independente dos demais projetos.
RF4
Acompanhamento dos clientes
Deve ser possvel que os clientes possam

acompanhar a evoluo do projeto a qualquer
momento, consultando tudo o que foi feito.
RF5
Liberao de acesso por projeto
Deve ser possvel liberar o acesso ao sistema

por projeto, indicando o seu gerente. Assim,
para se ter acesso ao sistema, dever ser
adquirida uma licena para um projeto. A partir
disso o gerente ficar responsvel por definir
quem dever usar o sistema, seja para trabalhar
na especificao de requisitos, como um dos
Engenheiros de Requisitos, seja como cliente
consultando o resultado do trabalho realizado.
RF6
Gerao da documentao
Deve ser possvel gerar a especificao na

forma de um documento no editvel, contendo
todos os dados registrados do projeto.
Podemos notar que os requisitos exibidos na Tabela 1 so

simples e exibem as necessidades de algum que trabalha com
requisitos. Podemos notar tambm que muito precisa ser detalhado
para que tenhamos algo pronto para implementar.
A Tabela 2 exibe a lista de requisitos no funcionais
identificados para o produto. Observe que tambm so definies
simples, mas que retratam o que se deseja com relao a certas
caractersticas
ligadas
ao
comportamento
do
software.
So
exemplos disso a definio do ambiente (Web), o uso de uma

20
tecnologia especfica (MySQL) ou a definio de valores para

atributos de qualidade como a quantidade de acessos simultneos e
o tempo mximo de resposta.
importante
ressaltar
que
requisitos
no
funcionais
necessitam da definio de valores que permitam sua verificao.

Dizer que o sistema deve ser rpido no ajuda muito aos testadores
que devem verificar se o produto atende ER. Mas especificar um
tempo mximo de resposta em um contexto pr-definido ajuda
bastante.
Tabela 2: Exemplo de requisitos no funcionais.
ID
Requisito
Descrio
RNF1 Ambiente
O sistema deve funcionar em ambiente Web,

sendo compatvel com os principais
navegadores do momento: Internet Explorer,
Firefox, Safari e Chroma.
RNF2 Linguagem
O sistema deve ser desenvolvido utilizando-se a

linguagem Java, com as tecnologias JSF e
Hibernate.
RNF3 Banco de dados
O sistema deve utilizar o banco de dados

MySQL.
RNF4 Desempenho
O sistema deve ser construdo para funcionar

com 100 usurios simultneos, com respostas de
at 5s quando utilizado em rede local.
RNF5 Segurana
O sistema deve restringir o acesso por meio de

senhas. Deve-se ter um controle no registro de
senha, de forma a impedir o uso de senhas
consideradas fceis.
RNF6 Usabilidade
Um usurio com conhecimento bsico em

informtica e conhecimento nos conceitos de
requisitos deveria ser capaz de operar o sistema
com um curso de 30 minutos.
O desenvolvimento de software pode ser entendido como

uma srie de transformaes que nos levam dos desejos dos
clientes, at um produto executvel, que atende a tais desejos. O
incio das transformaes acontece quando iniciamos uma srie de
21
reunies para entender o que os clientes desejam. Essa lista,

normalmente abstrata, devendo ser melhor detalhada sob diversos
aspectos, at que possa ser utilizada como guia para a
implementao.
Na identificao dos requisitos, todos os aspectos levantados
pelos clientes devem ser registrados, da forma mais parecida com o
que foi relatado. Nas prximas atividades esses aspectos sero
transformados em elementos que permitem seu detalhamento de
forma estruturada. No entanto, isso no acontece nesse momento.
Mais uma vez ressaltamos que essa atividade necessita ser
realizada com pessoas que possuam uma boa viso geral do todo. A
idia obter uma descrio de alto nvel do que precisa ser feito,
deixando para depois um detalhamento aprofundado de cada
questo.
Nesse momento voc dever fazer o levantamento dos
requisitos relacionados ao Software de Controle de Emprstimos
Pessoais, que iniciamos anteriormente. Crie uma lista de requisitos
desejados por voc com relao a esse produto. Utilize o exemplo
que disponibilizamos na pgina para iniciar o trabalho. Dessa forma,
voc deve ir alterando as sees sendo descritas.
1.1.11.
Detalhamento dos Requisitos
O Detalhamento dos Requisitos a atividade em que cada

requisito identificado deve ser desdobrado em funes do produto.
Cada funo do produto pode estar ligada a um nico requisito,
Casos de uso podem
ser considerados as
funes que um produto
deve oferecer.
assim como pode estar relacionada a mais de um requisito.

O desdobramento de requisitos gera a identificao dos
Casos de Uso. Esse um termo comum na Engenharia de
Requisitos e que precisa ser entendido. Um Caso de Uso uma fatia
de funcionalidade do sistema, que representa algo de valor para
seus usurios e que no apresenta nem lacunas nem superposio
com outros casos de uso.
22
Os casos de uso so acionados por atores. Um ator a

representao de um papel no sistema. Atores podem representar
um grupo de usurios, um outro sistema, com o qual o sistema
sendo especificado deve interagir. Um caso de uso normalmente
interage com apenas um ator, mas pode interagir com mais de um.
Segundo Wilson de Paula Pdua Filho, atores podem ser
identificados atravs dos seguintes critrios:
quem est interessado em certo requisito;
quem se beneficiar diretamente do produto;
quem usar informao do produto;
quem fornecer informao ao produto;
quem remover informao do produto;
quem dar suporte e manuteno ao produto;
quais os recursos externos usados pelo produto;
quais os papis desempenhados por cada usurio;
quais os grupos de usurios que desempenham o mesmo

papel;
quais os sistemas legados com os quais o produto deve

interagir;
tempo,
quando
casos
de
uso
so
disparados
periodicamente, de forma automtica.

Atores so usados para representar tambm sistemas
externos. Estes podem incluir sistemas legados, produtos comerciais
de software e outros componentes de um sistema maior. Podem
incluir recursos de hardware e comunicao que devam receber um
tratamento
especfico
por
parte
do
produto
(por
exemplo,
dispositivos de hardware que normalmente no fazem parte do

ambiente operacional). Um ator especial o Tempo, usado para
acionar casos de uso que so disparados periodicamente, de forma
automtica.
23
Atores modelam papis

associados ao uso do
produto. Papis e no
pessoas!
Cada
diagrama
de
casos
de
uso
especifica
os
relacionamentos entre casos de uso e atores. Os relacionamentos

indicam a existncia de comunicao entre atores e casos de uso.
Um caso de uso pode estar associado a mais de um ator, quando a
sua execuo requer a participao de diferentes atores.
Normalmente, a comunicao ser representada como
ligao sem direo. Nesses casos, convencionado que a iniciativa
de comunicao parte do ator. Quando a iniciativa parte do caso de
uso (por exemplo, alarmes, mensagens, dados enviados para outros
sistemas etc.), a comunicao deve ser direcionada para o ator.
Figura 2: Exemplo de ator e caso de uso.
A Figura 2 exibe um exemplo de como representado um

caso de uso e atores em UML. O caso de uso Exemplo de caso de
uso est associado a dois atores, o Ator e o Outro ator. Observe que
o relacionamento entre o caso de uso e o ator Outro ator possui uma
seta com indicao de direo. Isso mostra o fluxo de dados no
relacionamento. Dessa forma, as informaes devem fluir do caso
de uso para o ator.
Assim, aps a identificao dos requisitos, necessrio
detalhar quais casos de uso sero necessrios para atender aos
desejos identificados pelos clientes. Nesse momento inicia-se uma
tarefa um pouco mais nobre dos Engenheiros de Requisitos, que
justamente ajudar aos clientes a pensar como estruturar o software,
em termos de funes, para atender aos anseios identificados.
Como exemplo iremos analisar os requisitos contidos na
Tabela 1. Inicialmente, utilizaremos o RF1. O texto que o descreve
est detalhado no quadro a seguir:
24
O sistema deve permitir cadastrar e controlar todos os aspectos

relacionados aos requisitos de um projeto, permitindo visualizar isso
e acompanhar sua evoluo, incluindo as pessoas que trabalharam
no projeto, os analistas e o gerente do projeto.
De acordo com o texto do requisito, o sistema deve
Os requisitos so textos
que descrevem os
desejos dos clientes.
Simples assim!
Os casos de uso so as
tradues dos requisitos
em funes do produto,
feita por Engenheiros
de Requisitos, a partir
de um entendimento do
que foi solicitado e o
que pode ter em um
produto.
possibilitar o cadastro e controle dos requisitos. Com isso, podemos

identificar uma funo do produto: Cadastro de requisitos. Esse
ento j um dos casos de uso do sistema. Temos que lembrar que
existem requisitos funcionais e no funcionais. Assim, teremos que
decidir se iremos realizar esse cadastro em uma nico caso de uso
ou se sero necessrios dois casos de uso: um para o cadastro de
requisitos funcionais e outro para requisitos no funcionais. Nesse
caso em especfico, vamos utilizar um nico caso de uso para
registro dos requisitos. Vamos nomear esse caso de uso como
Gesto de requisitos.
Observe que ainda no texto do RF1 existe a meno ao
registro das pessoas que trabalharam no projeto. Isso significa que
teremos que ter um cadastro dos envolvidos no projeto. Teremos
que cadastrar o gerente, os analistas e os clientes envolvidos. Com
isso, possvel identificar que teremos que cadastrar os membros
do projeto. Isso d origem a mais um caso de uso: Gesto de
membros.
Continuando a anlise, podemos concluir que para atender o
RF2 necessrio termos um caso de uso para a Gesto de Casos
de Uso. No entanto, teremos tambm que registrar os atores
associados ao caso de uso. Isso nos remete a um novo caso de uso:
Gesto de atores.
O RF3 nos remete diretamente a um novo casos de uso:
Reviso. No entanto, foi descrito que as revises sero guiadas por
critrios independentes para cada projeto. Isso nos leva a identificar
um novo caso de uso: Gesto de critrios.
25
O RF4 solicita que exista uma forma de acompanhar o

projeto. Isso pode ser resumido a partir de uma funo do produto
que gerasse a especificao em um formato contendo todos os
dados do projeto, incluindo requisitos, casos de uso, atores, etc. Por
conta disso, o RF4 nos levou a identificar mais um caso de uso:
Gerao da especificao.
O RF5 refere-se ao modelo de negcio do sistema. Para que
alguma pessoa possa utiliz-lo, necessrio que seja realizado o
cadastro de um projeto. Esse projeto ter um gerente associado que
a partir de ento poder cadastrar seus analistas, clientes, os
requisitos, casos de uso, etc. Dessa forma, necessrio que o
sistema tenha um caso de uso Cadastro de Projeto, que deve ser
feito por um administrador, responsvel por liberar acesso ao
software. No entanto, um projeto possui diversos dados adicionais,
como seu escopo, datas de execuo, limites do produto, que
tambm precisam ser cadastrados. Isso nos leva a ter um outro caso
de uso, para que seja possvel registrar tais dados, mas utilizado
pelo gerente do projeto e no pelo administrador do sistema. Esse
caso de uso ser chamado de Controle do projeto.
Analisando o RF6, que trata da gerao da documentao,
encontramos algo interessante: a necessidade relatada j est
contemplada com a proposio do caso de uso Gerao da
documentao, identificado quando analisamos o RF4. Dessa forma,
ao propormos o caso de uso Gerao da documentao, no s
atendemos ao requisito RF4, como tambm ao RF6.
Pronto! Acabamos de identificar todos os casos de uso do
sistema, a partir de uma leitura e interpretao dos requisitos
expostos pelos clientes. Mais uma vez importante ressaltar que
embora tenhamos feito isso de forma direta neste documento, isso
normalmente exige reunies, discusses e um amadurecimento, no
s por parte dos clientes, como tambm dos profissionais
envolvidos, para que se cheguem a uma determinao do produto a
ser desenvolvido. A Figura 3 apresenta um diagrama de casos de
26
uso com todos os casos de uso identificados, alm dos atores

associados.
Outro ponto importante de ressaltar que isso no representa
ainda o detalhamento dos requisitos. necessrio descrever de
forma muito mais aprofundada os requisitos. Isso inclui a
determinao das regras de negcio associadas a cada um dos
casos de uso. Isso ser feito na prxima subseo.
O diagrama de casos
de uso nos d uma
visao ampla do sistema,
exibindo as funes
existentes e os papis
associados.
Figura 3: Diagrama de casos de uso para o ReqG.
A exibio dos casos de

uso e os requisitos que
foram utilizados para
sua gerao, nos do
uma idia da
rastreabilidade dos
requisitos.
A Tabela 3 exibe a lista de casos de uso identificados no

sistema, com uma identificao dos requisitos associados. Essa
ligao entre caso de uso e requisito conhecida como
27
rastreabilidade. Isso nos permite saber quem deu origem a qu.

Assim, possvel saber que um requisito deu origem a um
determinado caso de uso.
Tabela 3: Lista de casos de uso identificados.
ID
Caso de uso
Requisito
associado
Descrio
UC1
Gesto de
Requisitos
RF1
Cadastro
de
requisitos
funcionais e no funcionais
associados ao projeto.
UC2
Gesto de Membros RF1
Cadastro
de
todos
envolvidos no projeto.
UC3
Gesto de Casos de
Uso
RF2
Definio dos casos de uso do

projeto.
UC4
Gesto de Atores
RF2
Definio dos atores que iro

interagir no projeto.
UC5
Reviso
RF3
Reviso de um requisito ou de
um caso de uso, observando os
critrios pr-estabelecidos no
projeto para a reviso.
UC6
Gesto de Critrios
de Reviso
RF3
Cadastro de critrios a serem

utilizados em uma reviso.
UC7
Cadastro de Projeto
RF5
Cadastro de um projeto, com

definio do seu gerente, feito
pelo administrador do sistema.
UC8
Gesto de Gerentes
RF5
Cadastro de um gerente de
projeto, feito pelo
administrador do sistema.
UC9
Controle de
Projetos
RF5
Controle do projeto, com

detalhamento de informaes
sobre o mesmo, feito pelo
gerente do projeto.
RF6, RF4
Gerao da especificao de
requisitos,
utilizando
um
formato
pr-definido,
contendo todos os dados
registrados no projeto.
UC10 Gerao da
especificao
os
28
UC11 Relatrio de
Acompanhamento
RF6, RF4
Emisso de um relatrio
contendo uma indicao do
estado do projeto, a partir do
estado de cada caso de uso que
o compe.
A Tabela 4 exibe a lista de atores identificados. importante

ressaltar que a identificao de atores muito nos facilita o
entendimento do produto. Por isso, fundamental que ao se pensar
em uma funo do sistema, haja tambm uma reflexo sobre que
grupo deveria utilizar tal funo.
Tabela 4: Lista de atores do projeto.
Ator
1.
Cliente
2.
Administrador
3.
Gerente
4.
Membro
Descrio
Clientes de um projeto, normalmente responsvel
pelo fornecimento de informaes para moldagem
do produto.
Responsvel pelo controle do uso do sistema,
liberando acesso aos Gerentes a partir do
cadastramento de um projeto.
Responsvel pelo controle de um projeto, definindo
a equipe e suas tarefas.
Pessoa que faz parte da equipe que trabalha no
projeto.
Dando prosseguimento ao nosso trabalho, relacionado ao

Software de Controle de Emprstimos Pessoais, necessrio
identificar os casos de uso e atores associados ao sistema.
Detalhamento dos Casos de uso

Conforme demonstrado na Seo anterior, o Detalhamento
dos Requisitos inicia pela identificao dos casos de uso
relacionados s necessidades relatadas pelos fornecedores de
requisitos. No entanto, a identificao dos casos de uso apenas o
incio do detalhamento. A partir da identificao de um caso de uso,
sabemos que uma determinada funo dever existir no sistema.
Mas ser necessrio detalhar como ser essa funo. Isso inclui a
29
descrio desses casos de uso, especificando como eles devero

funcionar.
A atividade de Detalhamento dos Casos de Uso uma
subatividade do Detalhamento dos Requisitos. Existem muitas
formas de ser descrever um caso de uso. Uma forma muito utilizada
e adotada neste trabalho utilizar o conceito de fluxos dos casos de
uso.
O detalhamento dos fluxos dos casos de uso uma tarefa
onerosa e muito importante para a correta especificao do
funcionamento de parte de um produto. Cada fluxo detalha passo a
passo o que deve acontecer em determinada parte do produto. Essa
descrio geralmente feita por meio de textos seguindo formatos
pr-estabelecidos. Notaes muito informais so chamadas de
histrias de usurio (user stories) e so comumente adotadas por
metodologias geis.
Cada caso de uso deve possuir ao menos a descrio de
suas pr-condies, assim como um fluxo principal, que representa
um caminho de execuo que normalmente o mais utilizado para o
caso de uso. Um exemplo de fluxo principal apresentado a seguir.
Nele, possvel observar que existem passos relacionados com
aes do sistema (ReqG) e passos relacionados a aes do ator
(Administrador).
Fluxo principal
1. O ReqG exibe a Tela de Gesto de Gerentes.
2. O Administrador informa os dados para pesquisa por Gerentes.
3. O Administrador aciona o comando Pesquisar.
4. O ReqG recupera e exibe na lista Gerentes recuperados os Gerentes que
atendem aos parmetros de pesquisa informados, ordenados pelo Nome
em ordem crescente.
Os fluxos so comumente descritos em linguagem natural, na

forma de uma seqncia de passos. Cada passo corresponde a uma
ao de um ator ou do produto e que devem aparecer explicitamente
como sujeitos da frase. Outros atores podem aparecer como objetos
30
verbais de uma ao. Nesses caso, provavelmente tais atores

estejam ligados ao caso de uso utilizando-se setas que indicam a
direo da comunicao no diagrama de casos de uso. Condies e
iteraes podem aparecer nas descries dos casos de uso (se
alguma coisa, para cada coisa faa isso).
Um detalhe importante que a descrio dos casos de uso,
na forma apresentada neste trabalho, necessitar de um prottipo de
interface com o usurio. Isso ser descrito na prxima seo. Por
enquanto, iremos nos ater descrio do caso de uso. No entanto,
utilizaremos parte de um exemplo que ser completamente includo
como anexo deste trabalho. Uma leitura detalhada no Anexo I
permitir um bom entendimento dos conceitos apresentados, uma
vez que o anexo descreve um sistema real em que foi necessrio
aplicar todos os conceitos apresentados neste trabalho.
Alm do fluxo principal, que descreve uma parte do caso de
uso que provavelmente seja a mais utilizada, existem fluxos
alternativos e subfluxos. Os fluxos alternativos (tambm chamados
de fluxos excepcionais) so descries de alternativas de execuo
que podem ser iniciadas sempre que suas pr-condies forem
atendidas. Um exemplo disso apresentado a seguir.
Fluxo alternativo Incluso de um Novo Gerente
Precondies 1. O Administrador acionou o comando Novo.
Passos
1. O Administrador preenche os Dados do Gerente.

2. O Administrador aciona o comando Salvar.
3. O ReqG verifica que no existe um Gerente com email e
login informados.
4. O ReqG salva os Dados do Gerente.
Observe que na descrio do fluxo alternativo acima existe a

especificao de precondies. Essas precondies detalham o que
deve acontecer para que o fluxo entre em execuo. No caso, para
que a incluso de um novo gerente acontea, necessrio que o
31
ator associado ao caso de uso acione o comando novo, pois essa

a indicao que se deseja que o fluxo seja executado.
Nesse fluxo tambm temos algo muito interessante e
fundamental na descrio dos casos de uso: a especificao de
restries no seu funcionamento. No passo 3 do fluxo especificado
que o sistema (ReqG) verificar se uma determinada condio
atendida. Isso significa que o fluxo s continuar se ela for verdade.
Caso ela no seja verdade, o fluxo no continuar sua execuo.
Nesse caso, foi especificada uma condio simples, relacionada
verificao da existncia de um gerente com determinadas
informaes. No entanto, poderamos ter especificado condies
bem mais complexas. Essas condies sero traduzidas nas
diversas
regras
de
negcio
de
um
produto
durante
sua
implementao.
O levantamento de
requisitos deve detalhar
o desejo dos clientes.
No devemos introduzir
especificidades de
desenho ou
implementao durante
essa atividade. Por isso
no aconselhado
detalhar mensagens ao
usurio, tecnologias,
etc.
Outro detalhe importante que devemos ressaltar que no

precisamos definir mensagens ao usurio neste momento. A maioria
dos iniciantes na descrio de casos de uso tentado a descrever a
verificao contida no passo 3 do fluxo alternativo exibido
anteriormente contendo uma mensagem ao usurio, normalmente
da seguinte forma: O ReqG verifica se no existe um gerente com
email informado. Se existir o ReqG emite a mensagem Gerente j
cadastrado!. Mas qual o problema em especificar mensagens
durante o detalhamento dos casos de uso? Mensagens ao usurio
fazem parte do projeto (design) do sistema, uma etapa posterior aos
requisitos e anlise. As mensagens devem seguir convenes e
padres de usabilidade, no sendo adequado defini-las em um
momento em que isso no o foco. Assim, bem melhor apenas
identificar as restries e deixar para o momento apropriado a
definio completa e correta das mensagens.
Os subfluxos so utilizados para descrever conjuntos de
passos que foram extrados de algum fluxo por serem grandes,
complexos ou com potencial de serem reutilizados em outros fluxos.
Seria algo equivalente a extrair um mtodo de um outro mtodo.
32
Para acionar a execuo de um subfluxo necessrio especificar

isso de forma direta: O ReqG executa o Subfluxo X.
Em casos de uso do tipo CRUD (Create, Read, Update,
Delete), que descrevem um cadastro, normalmente contendo
funcionalidades para se cadastrar, pesquisar, alterar e excluir algo,
uma dvida comum : qual dessas funcionalidades deve ser
especificada no fluxo principal do caso de uso? A resposta :
qualquer uma. Mas lembre-se que normalmente utilizamos no fluxo
principal a funcionalidade que mais comumente utilizada. Uma
conveno utilizada neste trabalho foi sempre utilizar as pesquisas
como funcionalidade descrita no fluxo principal de casos de uso do
tipo CRUD.
Em geral, os casos de uso no possuem pr-condies e
alguns tem apenas o fluxo principal. Embora existam diversos
formatos utilizados para sua descrio, conforme o formato
apresentado nos exemplos contidos neste texto, o mais importante
que as descries utilizadas sejam inteligveis para quem as l.
Dessa forma, o bom senso o maior guia para a descrio dos
casos de uso: se uma pessoa consegue ler e entender o que tem
descrito, com condies de criar um programa que implemente as
descries, ento o caso de uso est bem descrito. No entanto,
importante ressaltar que os iniciantes na descrio de casos de uso
nem sempre deixam lacunas na descrio que impossibilitam o seu
entendimento. Isso muito comum e tende a ser reduzido com a
experincia.
Para finalizar essa seo, apresentamos a descrio de um
caso de uso um pouco mais complexo, que detalha as regras para
gerao de um relatrio associado ao nosso exemplo, contido no
Anexo I deste texto.
Fluxo principal
O ReqG exibe a Tela de Relatrio de Acompanhamento.
O Membro informa os dados para pesquisa por Projetos.
O Membro aciona o comando Pesquisar.
33
O ReqG recupera e exibe na lista Projetos Recuperados os Projetos que

atendem aos parmetros de pesquisa informados e que tenham como
Membro no projeto o usurio corrente, ordenados pelo nome do Projeto em
ordem crescente.
O Membro aciona o comando Gerar Relatrio.
Para cada requisito contido no projeto:
O ReqG imprime uma linha com o ID, nome, descrio, tipo e estado do
requisito, calculado a partir do estado ou a partir dos casos de uso
associados.
Para cada caso de uso associado ao requisito:
O ReqG imprime uma linha com o ID, nome, descrio e estado do
caso de uso.
O ReqG soma o percentual de concluso de cada caso de uso, de
acordo com o seu estado, sendo Identificado (10%), Detalhado (25%),
Implementado (75%) e Homologado (100%).
Se o requisito possui casos de uso associados:
O ReqG calcula o percentual de concluso do requisito a partir da
soma de todos os percentuais dos casos de uso, dividido pela quantidade de
casos de uso.
Seno:
O ReqG calcula o percentual de concluso do requisito a partir do
estado do requisito.
O ReqG calcula o percentual de concluso do projeto a partir da soma de
todos os percentuais dos requisitos, divididos pela quantidade de requisitos
existentes.
Esse exemplo possui alguns pontos interessantes. Ele possui
claramente definido em cada passo o seu responsvel, que
normalmente o sistema ou o ator. Existe a descrio de diversas
regras de negcio, detalhando como calcular alguma coisa. Para
isso,
foram
utilizados
condicionais
(se)
iteraes
(para).
Ressaltamos que apenas a leitura do caso de uso no nos permite

gerar o relatrio detalhado, pois temos que analisar tambm uma
sugesto de formato para tal relatrio. Isso est descrito no Anexo I
e ser comentado na prxima seo, que trata da definio dos
prottipos de interface.
Nesse momento necessrio o detalhamento dos casos de
uso identificados ao Software de Controle de Emprstimos Pessoais.
Crie a descrio dos casos de uso, sempre levando em
considerao a necessidade de termos restries para algumas
regras envolvidas no sistema.
34
1.1.12.
Interface
Definio dos Prottipos de
A Definio dos Prottipos de Interface especifica, de forma

detalhada, os requisitos relacionados as fontes de entrada e sada
de dados no produto.
Nas interfaces grficas de usurio, existem questes que
claramente representam requisitos dos produtos, tais como formatos
de dados e comandos. Outros detalhes, como formatos de telas e
janelas, so aspectos de desenho da interface de usurio e no
devem ser tratados durante a fase de Requisitos.
No entanto, a criao de um esboo da interface normalmente
auxilia bastante a identificao de regras de negcio, dados a serem
utilizados e formatos de campos. extremamente importante definir
Os prottipos de
interfaces, durante o
levantamento de
requisitos, devem ser
focados em se
descobrir as
informaes e
restries importantes
ao requisito. Nenhum
aspecto de execuo ou
usabilidade deveria ser
tratado nesse momento.
que tecnologia utilizar para gerao desses esboos, uma vez que
eles no devem demandar muito esforo e nem deveriam focar em
tecnologias especfica, visto que isso pode limitar o espao da
soluo sem que haja essa necessidade. Os esboos so apenas
sugestes, mas que no deveriam ser seguidos rigorosamente na
construo no produto. Eles servem muito mais para detalhar os
dados envolvidos nos fluxos do que propriamente para especificar
formatos de tela. Exemplos de esboos podem ser construdos
utilizando-se as seguintes tecnologias:
desenhos mo livre, em papel;
leiautes alfanumricos, feitos com um editor de texto, como o

Word;
leiautes feitos em um editor HTML, como o DreamWeaver;
desenhos feitos com uma ferramenta de desenho tcnico,

como o Pencil;
telas desenhadas em um ambiente de desenvolvimento

rpido, como Delphi;
35
telas desenhadas no ambiente definitivo de implementao,

utilizando Java Swing.
Os esboos devem ser descritos de forma que o usurio
consiga entender seu objetivo e entenda seu funcionamento,

independente da tecnologia a ser utilizada.
Os campos e comandos existentes nos prottipos devem
representar requisitos relacionados aos dados necessrios para se
implementar uma determinada funo. importante utilizar formatos
independente de tecnologia, para que sua definio final fique
apenas para o Projeto (Design). No interessante tentar definir
esse formato durante o levantamento de requisitos.
Neste
trabalho
iremos
utilizar
uma
conveno
para
especificao de prottipos criados utilizando-se um editor de texto.

Essa alternativa bastante vivel por conta da sua facilidade de
manipulao, expressividade e, alm disso, pelo fato de estar
completamente
dissociada
de
qualquer
tecnologia
de
implementao.
Gerao da Especificao
Informaes do Projeto
Projeto
SystemG (texto com at 30 caracteres)
Gerente
Silio Silvestre Ferreira Freitas (texto com at 100 caracteres)
<Pesquisar>
Projetos recuperados
Projeto
Descrio
Gerente
SystemG
Criao de um sistema X
Silio Silvestre Ferreira Freitas
Frigo
Projeto muito interessante
Alberto Sobrinho Arajo
TecnoComp
Manuteno de algo
<Gerar Especificao>
Figura 4: Exemplo de prottipo simples.
A Figura 4 exibe um exemplo de um prottipo simples para

uma interface de usurio. Nela existem diversas convenes que
guiaro a criao de outras interfaces. A primeira conveno est
relacionada s cores utilizadas nas interfaces. Cada cor possui um
significado, conforme detalhado na Tabela 5. Um campo com fundo
branco indica que ele editvel, ou seja, o usurio poder realizar
36
alteraes nos valores existentes. Campos com uma tonalidade

cinza clara so campos com valores dinmicos, preenchidos pelo
sistema, mas que no podem ser alterados pelo usurio. As demais
partes do prottipo que possuem uma tonalidade cinza mais
acentuada so partes fixas e rtulos, que normalmente no so
mutveis.
Tabela 5: Conveno relacionada s cores nos prottipos.
Campo altervel.
Campo no altervel.
Ttulo de interface, rtulo de campo ou comando.
Na Figura 4 temos ainda outras informaes interessantes. O

formato de cada campo altervel descrito na forma de um texto,
junto ao prprio campo. Isso pode ser visto no campo projeto, que
pode conter textos com at 30 caracteres. Quaisquer outras
restries associadas podem ser especificadas nesse texto,
independente de sua complexidade. Podemos especificar mscaras,
condies para que ele seja ocultado ou exibido, valores inicialmente
exibidos, etc. Tudo o que for necessrio pode ser especificado no
prprio campo. Isso torna muito simples o entendimento do seu
formato e do seu funcionamento.
Na mesma figura existe ainda a especificao de diversos
comandos, descritos a partir dos delimitadores <>. Um comando
uma entidade que dispara alguma ao. Note que no definimos se
o comando ser um boto, hiperlink, comando de voz ou qualquer
outro tipo. O importante deixar claro que existe um comando na
tela e que ao ser acionado responsvel por alguma ao. Essa a
vantagem de se utilizar prottipos independentes de tecnologia: no
temos aderncia a qualquer formato. Isso facilita o desenho
definitivo da interface sem limitar o conjunto de alternativas
existentes.
Outro ponto interessante na figura a existncia de uma
tabela com uma lista de valores (Projetos recuperados). Uma tabela
37
algo
comum
na
maioria
dos
sistemas.
Freqentemente
necessitamos especificar tabelas em nossos prottipos, pois elas

so muito teis para agrupar informaes correlacionadas.
Tambm importante ressaltar algo que geralmente gera
muita confuso nos iniciantes em criao de prottipos para o
levantamento de requisitos: essas telas nunca vo executar! Assim,
fique tranqilo quanto a usabilidade, pois elas no sero usveis! As
telas definitivas, feitas com base nesses prottipos que vo
executar. Mas por enquanto, temos apenas um esboo daquilo que
ser feito em uma fase posterior do desenvolvimento.
Quando temos um prottipo e o detalhamento do caso de uso,
o entendimento de parte de um produto se torna bastante simples.
Veja por exemplo, a descrio do fluxo principal associado ao
prottipo exibido na Figura 4.
O ReqG exibe a Tela de Gerao da Especificao.
O ReqG recupera e exibe na lista Projetos Recuperados os Projetos que
atendem aos parmetros de pesquisa informados e que tenham como
Membro no projeto o usurio corrente, ordenados pelo nome do Projeto em
ordem crescente.
O Membro aciona o comando Gerar Especificao.
O ReqG gera um documento no formato especificado no arquivo ModeloERSw.doc.
Alguns prottipos possuem campos com formatos mais

especficos, conforme apresentado na Figura 5. O campo projeto
possui um asterisco que indica que ele obrigatrio. Alm disso, seu
contedo contm a especificao que ele conter uma lista de
projetos que atendem a uma determinada restrio. Isso significa
que essa lista ser carregada dinamicamente, durante a execuo
do produto e que seus valores sero trazidos de uma entidade do
produto.
38
Dados da Reviso
[Lista de Projetos que possuem o usurio corrente como
membro]
Reviso preliminar de requisitos (texto at 50
caracteres)
Projeto*
Identificador*
Descrio*
Data*
Participantes dos
desenvolvedores*
Reviso preliminar de requisitos (texto at 50 caracteres)

12/12/2010 (data no formato dd/mm/aaaa)
[Lista de Membros do Projeto que no sejam clientes]
...
[Lista de Membros do Projeto que sejam clientes]
...
[Aberta; Fechada]
Participantes dos
clientes
Situao*
Figura 5: Prottipo com campos mais especficos.
Ainda no prottipo exibido na Figura 5, podemos notar que o

campo Participantes dos desenvolvedores tambm possui uma
especificao de uma lista, porm, podemos notar que esse mesmo
campo poder ter mais de um valor. Isso poder ser mapeado sob
diversas formas em uma interface definitiva: vrios campos do tipo
check box, um campo list, uma tabela, etc.
Tipos de Ingresso
Effects
Classificao
[Lista de Tipos de Ingresso pr-cadastrados no sistema]

...
[Lista de Tipos de Ingresso pr-cadastrados no sistema]
[Lista de Effects pr-cadastrados no sistema]
...
[Lista de Effects pr-cadastrados no sistema]
[Matrcula; Nome]
Figura 6: Exemplo de especificao de prottipo usando editores de texto.
39
Uma modelagem do
prottipo, feita utilizando
nossas convenes,
podem ser mapeadas
para diferentes formatos
em tecnologias
especficas.
Figura 7: Exemplo de interface definitiva similar ao prottipo da figura anterior.
Na Figura 6 temos a especificao de trs campos utilizando

nossas convenes. Os dois primeiros campos so multivalorados
enquanto que o terceiro pode ser apenas um de dois possveis
valores. Na Figura 7 temos um exemplo de como esse prottipo
pode ser construdo em um ambiente definitivo (HTML). Note que
embora os dois primeiros campos possuam a mesma representao
em nosso formato independente de tecnologia, ele pode ter
diferentes implementaes em um ambiente definitivo.
Mais uma vez ressaltamos que existem diversos exemplos no
Anexo I deste documento, que possui a especificao completa de
um sistema real. Ele deve servir de base para a criao do nosso
trabalho prtico.
chegada a hora de realizar a criao dos prottipo para os
casos de uso identificados. Lembre-se de seguir o formato
independente de tecnologia apresentado aqui e fique atento s
convenes definidas.
40
1.1.13.
Reviso dos Requisitos
A reviso dos requisitos a atividade realizada para garantir

que o padro prescrito pela organizao foi realmente seguida e que
os requisitos identificados atendam aos critrios de qualidade
solicitados,
permitindo
seu
correto
entendimento
e,
por
conseguinte, a realizao do projeto adequado bem como da
Uma reviso deve ser

feita com base em
critrios bem definidos.
implementao apropriada.
Para a reviso necessrio inicialmente estabelecer os
critrios a serem utilizados. Na Seo 2 foram expostos diversos
critrios de qualidade para requisitos. Um projeto pode determinar
que critrios devem ser utilizados para a realizao das revises,
para ento analisar cada requisito luz dos critrios selecionados.
Dessa forma, podemos facilmente visualizar que uma reviso
nada mais que uma leitura e posterior anlise dos requisitos, tendo
em mente aspectos bem pontuais a serem avaliados. De modo
geral, pessoas que no sejam os autores da especificao de
requisitos seriam mais adequados para a realizao da reviso que
os prprios autores. Isso acontece por que normalmente os autores
podem ficar cegos quanto a certos problemas.
Um exemplo de reviso para parte dos requisitos contidos no
Anexo I apresentado a na Tabela 6. Nela podemos notar a anlise
de alguns requisitos e casos de uso, com base em critrios prdefinidos. A partir dessa anlise sero registrados os eventuais
conflitos e acompanhado os passos para sua resoluo.
Tabela 6: Fragmento da reviso de uma ER.
Requisito
Caso de
Uso
Ambigidade
1
2
RF1
RF2
UC2
UC3
Aprovado
Aprovado
Aprovado
Aprovado
No
aprovado
Aprovado
RF5
UC8
No aprovado
Aprovado
Aprovado
Nr.
Clareza
Completude
Conflitos
No foi especificado a
ordem em que os
resultados devem ser
exibidos.
O caso de uso parece que
poderia ser agrupado com o
caso de uso Gesto de
Membros, no havendo
41
necessidade de criao de
um caso de uso adicional.
No prximo captulo apresentaremos de forma detalhada uma

forma de se conduzir reunies para levantamento de requisitos e
para realizao de revises.
No Anexo IV existe a reviso por completo, contendo os
critrios utilizados e sua explicao, assim como o resultado da
avaliao executada. Voc deve criar algo similar para o Software de
Controle de Emprstimo Pessoais. Lembre-se de definir os critrio,
detalhando como eles sero utilizados, alm de registrar os
problemas e as formas de resoluo deles.
Com a apresentao do formato para reviso de requisitos,
encerramos o detalhamento do Fluxo de Requisitos. Aps uma
execuo completa desse fluxo, teremos boas informaes sobre
como desenvolver um produto que atenda s necessidades do
cliente, porm, ainda sero necessrias vrias transformaes at
que o produto seja construdo.
Algo que devemos ressaltar bastante para os iniciantes no
levantamento de requisitos uma frase contida no livro do Prof.
Wilson de Pdua: desenvolver uma especificao de requisitos custa
tempo e dinheiro; no faz-la geralmente custa mais tempo e
dinheiro ainda!
1.3.
Exerccios
1. Qual a definio de requisito?

2. Qual o objetivo de uma Especificao de Requisitos?
3. Por que a gerao de uma Especificao de Requisitos
para um produto novo mais complexa que para produtos
existentes?
4. O que o fluxo de requisitos?
5. Quem participa do levantamento de requisitos?
42
6. O que a Engenharia de Requisitos?

7. Cite e explique 3 caractersticas de qualidade de
requisitos.
8. Quais so as atividades do fluxo de requisitos? Descrevaas brevemente/
9. O que o escopo de um projeto?
10. Por que importante se definir os limites do produto?
11. Como deve ser a abordagem em uma instituio para se
levantar requisitos junto aos clientes?
12. Qual a diferena entre requisitos funcionais e nofuncionais?
13. Cite 3 exemplos de requisitos funcionais para um Sistema
Acadmico.
14. Cite 3 exemplos de requisitos no-funcionais para um
Sistema Acadmico.
15. O que um caso de uso?
16. O que so os atores?
17. Como identificar atores?
18. O que devemos fazer para identificarmos casos de uso?
19. Identifique casos de uso e atores para os requisitos
descritos na questo 13.
20. Crie um diagrama de casos de uso para os itens
identificados na questo anterior.
21. O que um fluxo principal?
22. Qual a diferena entre fluxo principal e fluxo alternativo?
23. Como podemos especificar regras de negcio nos casos
de uso?
24. Qual a importncia de um prottipo de interface?
25. Quais so as tecnologias possveis que serem utilizadas
para construo de prottipos?
26. Qual a conveno de cores utilizadas para construo de
prottipos? O que elas significam?
43
27. Crie um prottipo de tela utilizando as convenes

prescritas no captulo, para modelar alguma tela real de
algum sistema que voc utilize.
28. Para que serve a reviso dos requisitos?
Qual a importncia dos critrios para uma reviso de
requisitos?
44
UNIDADE I
2. Tcnicas de Apoio ao Levantamento de

Requisitos
Durante o levantamento de requisitos so necessrias
diversas reunies. Tais reunies tem como objetivo bsico entender
bem as necessidades dos clientes, alm de avaliar se os dados
coletados esto adequados e consistentes com as necessidades.
Por conta disso so necessrias tcnicas que facilitem a
execuo
dessas
reunies.
Neste
captulo
apresentaremos
justamente tcnicas apropriadas para os dois casos citados

anteriormente. Boa parte do material deste captulo foi baseado do
livro Engenharia de Software de autoria do Prof. Wilson de Pdua
Paula Filho.
1.4.
Oficinas de requisitos
As oficinas de requisitos so reunies estruturadas para

Uma oficina de
requisitos uma forma
de se identificar o que
se deseja de forma
conjunta com os
usurios.
definio conjunta dos requisitos, envolvendo desenvolvedores,

usurios e demais especialistas. O tipo de oficina que ser aqui
discutido baseado nas tcnicas de JAD, embora existam variantes
na literatura.
As oficinas de requisitos usam uma tcnica estruturada de
conduo de reunies de desenvolvimento, aplicvel a diversas
atividades do ciclo de vida do software, sendo especialmente til no
levantamento de requisitos. Nessas reunies, denominadas oficinas
de requisitos, o levantamento e detalhamento dos requisitos feito
em conjunto, com a participao de desenvolvedores e usurios
chaves, assim como gerentes, todos unidos para termos uma melhor
qualidade no resultado do trabalho.
45
As oficinas de requisitos tendem a apresentar melhores

resultados do que os levantamentos baseados em reunies
individuais com alguns usurios. Isso acontece por uma srie de
razes, dentre elas:
elas facilitam o comprometimento dos usurios com poder de

deciso e os requisitos;
O levantamento de
requisitos utilizando
JAD normalmente
apresenta resultados
muito interessantes.
elas reduzem o prazo de levantamento de requisitos, visto

que a reunio com todos os envolvidos tende a ser mais
direta que conversas individuais setorizadas;
eliminam requisitos de valor questionvel, uma vez que todos

so discutidos nas reunies;
reduzem diferenas de interpretao dos requisitos entre

usurios e desenvolvedores, uma vez que as explicaes
acontecem ao vivo e com diferentes pontos de vista;
produzem um primeiro esboo das interfaces de usurio, a

partir do direcionamento dado pelos prprios usurios no
momento das reunies;
trazem a tona, o mais cedo possvel, problemas polticos que

possam interferir no projeto.
Essas oficinas possuem trs partes bem distintas: a
Personalizao, onde so feitas adaptaes do mtodo para a

aplicao; as Sesses propriamente ditas, na qual as reunies so
realizadas com a participao de todos os envolvidos; e o
Fechamento, com a produo do resultados obtidos.
2.1.1.
Personalizao
A personalizao da oficina de requisitos uma parte simples

do processo. Nessa parte as equipes so selecionadas e
organizadas, para que haja a participao dos usurios chave para
as reunies sejam produtivas, alm de uma orientao sobre como
os trabalhos sero conduzidos.
46
Alm do que foi exposto, so feitas as particularizaes

necessrias ao projeto, bem como a preparao das instalaes a
serem utilizadas para as reunies.
Um ponto importante a se discutir nesse momento : quais
so os usurios adequados a participarem de uma reunio de
levantamento de requisitos? No existe uma resposta genrica e
adequada para tal questo, mas existem diretrizes importantes a
A seleo dos
participantes das
reunies algo que
pode facilitar muito o
levantamento de
requisitos.
serem seguidas. Uma dessas diretivas : nas reunies iniciais, onde

so determinados o escopo e os requisitos, mais importante a
participao de usurios com um bom conhecimento do todo,
embora no tenha conhecimentos aprofundados sobre as partes.
Tipicamente, esses usurios so as pessoas da organizao com
maior nvel hierrquico. Normalmente chefes, coordenadores,
gerentes, diretores possuem um bom conhecimento do todo e pouco
das partes. Eles so pessoas importantes para as reunies iniciais
de levantamento de requisitos.
Uma vez levantados os requisitos iniciais, torna-se importante
ter contato com as pessoas que possuem mais conhecimentos
detalhados nas partes que compem o produto. chegada a hora
de termos o detalhamento dos requisitos, onde teremos que propor
prottipos para as interfaces, alm de detalhar as regras de
negcios do produto. Para isso os funcionrios com mais
conhecimento dos detalhes e provavelmente menos conhecimento
do todo, so mais importantes.
2.1.2.
Sesses
As sesses correspondem realizao efetiva das reunies.

Todos os integrantes da equipe da oficina devem participar das
sesses em tempo integral, para que no se perca tempo em
recapitulaes para os ausentes em sesses anteriores. Idealmente,
as sesses devem ser conduzidas em local afastado das
organizaes dos participantes, visto que muito comum que haja
47
diversas interrupes quando as sesses so realizadas nas

instalaes do cliente. Assim, uma boa dica levar as sesses para
longe do ambiente dos clientes.
Interrupes so altamente prejudiciais, sendo importante
avisar todos os participantes sobre essa regras. Telefonemas no
devem ser atendidos, os telefones celulares devem ser desligados.
Sem o controle
adequado nas sesses,
o risco de insucesso
aumenta bastante!
Deve-se
planejar
disponibilidade
dos
materiais
necessrios, tais como:
computadores: normalmente so necessrios pelo menos 2

computadores (ou notebooks), sendo um para projeo da ER
sendo criada e outro para redao da ata da reunio;
projetores: pelo menos um projetor necessrio, para que

seja possvel exibir o resultado do trabalho e permitir uma
discusso de todos;
copiadoras: eventualmente pode ser necessrio compartilhar

material com os demais participantes;
blocos de escrever, flip-charts, quadros brancos, lpis e

canetas: em muitos momentos ser necessrio escrever,
sendo importante termos materiais para tal fim;
lanches: as sesses podem durar um turno inteiro, sendo

importante um momento para repor as energias e evitar a
desateno nas discusses.
Existem papis importantes nas sesses. Cada um possui
uma atribuio especfica e pode ser decisivo para o sucesso das

reunies. Dentre os papis destacamos:
o lder da sesso, responsvel por manter o bom clima e o

foco das discusses, que deve dominar tcnicas de conduo
de reunio e ser treinado na conduo destas oficinas;
48
os patrocinadores, representantes do cliente, responsveis

pela resoluo de conflitos entre grupos de usurios, com
poder de deciso para tal;
os representantes dos usurios, com autoridade para tomar

decises em nome da respectiva comunidade;
os desenvolvedores, cuja funo bsica durante a oficina

deve ser a de fornecer informao sobre a viabilidade das
idias levantadas;
o relator, participante da equipe do projeto, encarregado de

redigir as atas de reunio.
Durante a discusso, as idias devem ser registradas e
simultaneamente exibidas a todos os participantes, seja atravs de

quadros brancos, seja atravs de computador com projetor. O lder
deve estimular a participao de todos, mantendo o foco,
encaminhando a resoluo de conflitos e identificando questes que
no possam ser resolvidas durante a sesso. Deve ficar claro para
todos o comprometimento que dever existir em relao s
concluses da oficina.
2.1.3.
importante apresentar
os resultados de uma
sesso na forma de
uma ata. Isso passa
uma imagem mais
profissional, alm de
demonstrar
organizao.
Fechamento
No Fechamento so produzidos os artefatos resultantes da

reunio. Isso normalmente inclui partes da ER e atas. Deve-se ter
um cuidado especial para as pendncias registradas na reunio e
que devem ser resolvidas em uma data acertada por todos.
Normalmente no fechamento feita uma apresentao do
material produzido, incluindo a Ata, para posterior envio e aprovao
por parte dos envolvidos.
No Anexo II exibimos um exemplo de uma Agenda para uma
reunio de levantamento de requisitos e no Anexo III um exemplo de
uma ata para uma reunio. Esses modelo podem ser utilizados para
servir de base para criao desses artefatos em um projeto.
49
De modo geral, uma ata deve conter um espao para detalhar

os participantes (clientes e desenvolvedor), assuntos discutidos e
pendncias. As atas so importantes pois alm de registrarem os
assuntos discutidos, envolvidos na discusso e o tempo em que tais
discusses apareceram, mostra profissionalismo nas relaes, algo
que no comum em todas as empresas que trabalham com o
desenvolvimento de software.
1.5.
O
Uma reviso um
mecanismo de garantia
da qualidade
normalmente aplicada
para verificar artefatos
no executveis.
Revises
Teste
de
Software
algo
muito
importante
no
desenvolvimento. Ele usado para avaliar se o produto construdo

est de acordo com os requisitos identificados. Mas se construmos
uma ER, como fazer para test-la? nesse momento que torna-se
necessrio a realizao de atividades de garantia da qualidade que
tenha como objetivo avaliar o trabalho realizado. Para os casos em
que o produto do trabalho no executvel, as revises so
adequadas.
As revises de software so tcnicas eficazes de garantia da
qualidade. Segundo um grande pesquisador na rea da Engenharia
de Software, Watts Humphrey, as Revises so mais eficazes que
os testes para se encontrar defeitos em um produto.
As revises aplicadas no desenvolvimento de software
normalmente so de responsabilidade de um grupo de garantia da
qualidade. Como boa parte das organizaes so pequenas e no
conseguem ter um grupo dedicado somente a isso, necessrio ter
no processo uma previso dessa atividade. O fluxo de requisitos
apresentado neste texto contm a previso de uma reviso no final
de sua execuo, devendo essa ser liderada pelo Gerente do
Projeto, caso no haja um responsvel direto.
Existem diversos tipos de reviso. A reviso tcnica tem como
objetivo avaliar artefatos especficos para verificar se eles esto
50
conformes com os respectivos padres e se modificaes foram

efetuadas de maneira correta.
A inspeo mais formal que a reviso tcnica. Ela tem o
objetivo principal de identificar e remover defeitos. Para isso, seu
resultado deve gerar uma lista de defeitos com classificao,
exigindo dos autores do artefato revisado providncia para a
resoluo dos problemas relatados.
Na reviso de apresentao o autor demonstra o material em
ordem lgica, sem limite de tempo, a um grupo que verifica o
material medida que ele vai sendo apresentado. Este tipo de
reviso no exige preparao prvia e pode ser feito com maior
nmero de participantes, por terem estes papel mais passivo. Elas
podem ser usadas nos marcos de projeto em que so necessrias
apresentaes ao cliente.
A reviso gerencial conduzida pelo gerente de um projeto,
com os objetivos principais de avaliar os problemas tcnicos e
gerenciais do projeto, assim como o seu progresso em relao aos
planos.
Alm das revises formais, existem diversos tipos de reviso
informal, que podem e devem ser usadas. Alguns mtodos geis se
utilizam muito desse tipo de reviso, uma vez que essa prtica de
revisar uma boa prtica no desenvolvimento de software. Dentre
os tipos de revises informais, destacam-se:
A programao em pares, adotada no XP e outros processos

geis. Essa uma reviso contnua, onde uma dupla trabalha
programando em uma mesma mquina. Um dos integrantes
da dupla responsvel por pilotar o equipamento e o outro
responsvel por uma reviso permanente do trabalho sendo
executado.
A reviso individual realizada pelos autores, seguindo

formalmente os roteiros pertinentes, eventualmente com a
ajuda de pares.
51
A reviso preliminar realizada por um ou mais pares dos

autores, para eliminar defeitos mais simples do material,
como ortografia, numerao, estilos e consistncia.
2.1.4.
Participantes
Uma reviso deve ser feita com a participao de diversas

pessoas. No entanto, aconselhvel que esse grupo tenha de 5 a 8
membros, sendo: 1 lder; 1 relator; 1 ou 2 autores; 2 a 4 revisores
pares dos autores; 0 a 2 representantes dos usurios, dependendo
do material em reviso.
O lder da reviso deve possuir algumas caractersticas,
conforme detalhamento a seguir:
Um nmero grande de
participantes inviabiliza
a produo de bons
resultados em uma
reviso.
ele deve compreender o propsito das revises em geral e

entender seu funcionamento;
ter conhecimentos tcnicos de alto nvel sobre o material a

ser revisado;
ter participado de alguma outra reviso como revisor e

tambm, de preferncia, como autor;
no ter com qualquer um dos revisores alguma dificuldade

pessoal que possa interferir em sua habilidade de liderar a
reviso.
Assim como o lder, o relator da reviso tambm deve possuir
algumas caractersticas:
compreender o propsito das revises em geral e entender

seu funcionamento;
compreender o jargo e os formatos utilizados neste material;

ser capaz de comunicar-se com as pessoas que estaro
presentes na reviso;
ter participado de alguma outra reviso como revisor ou como

autor.
52
Os demais revisores devem levar em conta os seguintes

aspectos de comportamento:
estar preparado, lendo cuidadosamente o material antes da

reunio;
ter conhecimento tcnico sobre parte do material da reviso;
ser cooperativo;
ser franco em relao ao material da reviso, mas polido em

relao aos autores;
compreender perfeitamente os pontos discutidos;
usar um comentrio positivo e outro negativo;
apontar defeitos, mas no discutir como resolv-los (a

resoluo no faz parte da reviso);
evitar discusses sobre detalhes no-pertinentes qualidade

do material em reviso;
limitar-se aos assuntos tcnicos;
no avaliar os produtores, apenas o resultado do projeto.

Normalmente, os revisores so desenvolvedores, ou seja,
pares dos autores. Em alguns casos, pode ser desejvel a

participao de usurios como revisores, por exemplo, em revises
das especificaes de requisitos, dos desenhos das interfaces de
usurio e da documentao de usurio. Nesse caso, os usurios
devem estar cientes de que estaro analisando a qualidade do
material sob reviso.
2.1.5.
Conduo
muito importante deixar bem claro nas reunies que o que

est sendo revisado um trabalho e no seus autores. Isso deve ser
frisado por que comum que haja certas disputas em revises que
trazem tona certos problemas de relacionamento.
Outro ponto chave manter sempre em mente que o objetivo
da reviso no detalhar solues, mas apenas apontar problemas
e, eventualmente, dar sugestes sobre possveis melhorias ao
53
material em reviso. A descoberta por solues pode levar um

tempo muito grande, inviabilizando a prpria reviso.
Normalmente a reunio de reviso no deve ultrapassar duas
horas. Deve-se garantir que no sejam feitas interrupes externas
reunio e que os membros da reviso no sejam solicitados por
telefonemas ou trabalhos externos. O lder da reviso deve certificarse de que todos os telefones celulares estejam desligados.
Nas revises tcnicas, o material normalmente apresentado
na ordem em que est documentado, por um autor ou pelo lder da
reviso. Nas inspees, comum utilizar-se a ordem por item
analisado. Desta maneira, em cada etapa a equipe de inspeo ter
a ateno focalizada em um aspecto especfico.
preciso deixar muito
claro que em uma
reviso estamos
analisando o trabalho
produzido e no seus
produtores.
reunio
deve
ser
iniciada
pontualmente;
nenhum
participante poder mais entrar, aps o seu incio. Se a reunio tiver

que ser interrompida, ou se algum dos participantes estiver ausente
reviso dever ser cancelada, e nova data para a reviso dever
ser marcada pelo lder.
Uma reviso tcnica realizada de acordo com o seguinte
procedimento:
1. O gerente do projeto envia o material para o Grupo de
Garantia da Qualidade (GQ) ou para o grupo responsvel pela
realizao das revises, caso no haja o grupo de garantia da
qualidade. O material consiste dos resultados de uma ou mais
atividades de fase do desenvolvimento, como uma ER, prrevisados se necessrio, para eliminar problemas menores de estilo,
ortografia etc.
2.
O GQ convoca os membros da equipe de reviso,
escolhe o lder e o relator desta equipe e distribui os resultados para

o grupo de revisores.
3.
O grupo de revisores estuda o material e faz a
preparao
da
reviso,
possivelmente
registrando
suas
observaes.
54
4.
O lder comanda a realizao da reunio de reviso e
envia para o GQ os relatrios contendo o resultado do material

analisado.
5.
O GQ faz o ps processamento da reviso.
Em alguns estilos de reviso, a deteco de defeitos

realizada principalmente durante a reunio, tendo a preparao o
objetivo de estudo e anlise preliminar do material. Em outros
estilos, solicita-se que os revisores procurem localizar o mximo de
defeitos durante a preparao, tendo a reunio o objetivo principal
de eliminar duplicaes e padronizar a classificao dos defeitos e o
fraseado das observaes.
O Relatrio de Reviso deve conter uma lista com os defeitos
encontrados. importante o uso de um projetor durante a gerao
do relatrio, para permitir que todos vejam o que est sendo escrito.
Ao final da reunio, deve-se produzir uma verso impressa, com
listagem das anotaes, que ser conferida por todos os
participantes e que receber as assinaturas destes.
Os autores devem agir em relao a essa lista de defeitos,
anotando as providncias tomadas. Uma recomendao que para
cada defeito, o autor deve inserir a providncia correspondente,
indicando se o defeito foi corrigido ou expondo as razes pelas quais
discorda da necessidade de correo. O autor deve tambm indicar
o tempo gasto para remoo do defeito, que ser posteriormente
usado para alimentar uma base de dados histricos.
Aps a reviso, o GQ deve encaminhar o resultado para o
Gerente do Projeto, para que se faam as correes necessrias no
material revisado. Isso depende muito do resultado da reviso, que
pode ser:
Aceitao: indicando que o material foi aceito, embora ainda

devam existir outros procedimentos de controle.
Revises menores: o gerente do projeto solicita equipe do

projeto que providencie os acertos necessrios. O GQ deve
verificar se as correes devidas foram feitas.
55
Revises maiores: o gerente do projeto solicita equipe do

projeto que corrija o material e pede ao GQ uma nova reviso
ao final da correo.
Reconstruo: o gerente do projeto investiga as causas dos

problemas
material,
detectados,
indicando
as
agendando
provveis
reconstruo
falhas
para
do
serem
observadas.
importante ressaltar que as sugestes apontadas no
relatrio
de
reviso
no
precisam
ser
necessariamente
implementadas. Cabe ao gerente do projeto determinar, entre as

alteraes propostas, quais devem ser realmente executadas,
ponderando os aspectos tcnicos, gerenciais e polticos e ouvindo o
GQ.
Os
Relatrios
de
Revises
devem
ser
arquivados
permanentemente, sendo importante que cada projeto mantenha

seu repositrio.
1.6.
Exerccios
1. O que so oficinas de requisitos?

2. Por que as oficinas de requisitos tendem a apresentar
melhores resultados que as reunies individuais?
3. Como so divididas as oficinas?
4. O que feito na personalizao de uma oficina?
5. Por que as sesses de levantamento deveriam ser feitas
longe do ambiente dos participantes dos clientes?
6. Que materiais so necessrios durante uma sesso de
levantamento de requisitos?
7. Quais so os papis associadas a uma sesso de
8. O que feito no fechamento de uma sesso?
9. O que deve existir em uma ata de uma reunio de
56
10. Qual a relao existente entre o teste e a reviso?

11. Quem o responsvel pela conduo de uma reviso?
12. Quais so os tipos de reviso existentes?
13. Qual a forma de reviso existente no processo XP?
14. Quais caractersticas devem estar associadas ao lder de
uma reviso?
15. Quais caractersticas devem estar associadas ao relator
de uma reviso?
16. Quais aspectos de comportamento so importantes para
os demais revisores?
17. Como deve ser conduzida uma reunio de reviso?
18. Quais so os possveis resultados de uma reviso?
57
UNIDADE I
WEBLIOGRAFIA
Pgina da Universidade Aberta do Piau - UAPI

http://www.ufpi.br/uapi
Pgina da Universidade Aberta do Brasil- UAB
http://www.uab.gov.br
Instituto de Engenharia de Software do MIT
http://www.sei.cmu.edu/
Stio de apoio ao livro de Roger Pressman
http://www.rspa.com/
Stio de apoio ao livro de Ian Sommerville
http://www.comp.lancs.ac.uk/computing/resources/IanS/
Stio de apoio ao livro de Wilson de Pdua
http://homepages.dcc.ufmg.br/~wilson/
Stio da Ferramenta Astah
http://astah.change-vision.com
58
UNIDADE I
REFERNCIAS BIBLIOGRFICAS
ALISTAIR, COCKBURN, Escrevendo Casos De Uso Eficazes,
Editora Bookman, 2003.
IAN SOMMERVILLE, Engenharia de Software, 6a. Edio,
Addison-Wesley, 2005.
JANE WOOD, SILVER DENISE, Joint Application Development,
John Wiley & Sons Inc, ISBN 0-47104-299-4.
KENT
BECK,
Extreme
Programming
Explained:
embrace
change. Boston: AddisonWesley/Longman, 1999.

ROGER S. PRESSMAN, Engenharia de Software, 5a. Edio,
McGraw-Hill, So Paulo, 2002.
WILSON DE PDUA PAULA FILHO, Engenharia de Software:
Fundamentos, Mtodos e Padres, Editora LTC, 2 Edio, 2003.
59
UNIDADE II
ANLISE DE SOFTWARE
RESUMO
Nesta unidade apresentamos o Fluxo de Anlise. Ele tem
como objetivo modelar conceitos importantes, identificados durante o
levantamento de requisitos. Essa modelagem d origem a diversas
classes e diagramas, que apresentam a especificao de requisitos
sob outra forma, mais prxima dos desenvolvedores e um pouco
mais distante dos usurios finais.
No Capitulo 3 apresentamos a Linguagem UML, um padro
de facto para a modelagem de sistemas e fundamental para
execuo do Fluxo de Anlise. Todos os seus elementos sero
descritos, juntamente com um breve detalhamento sobre como
utilizar a ferramenta Astah para modelagem.
No Captulo 4 apresentamos o Fluxo de Anlise. No fluxo so
detalhadas as atividades relacionadas disciplina, apresentando em
detalhes a Anlise para nosso sistema exemplo. Detalharemos os
passos executados para cada atividade.
No Captulo 5 apresentamos a Anlise de Ponto de Funo,
que uma tcnica para contagem de sistemas quando esses ainda
no foram implementados e possuem apenas uma Especificao de
Requisitos e um Modelo de Anlise.
60
SUMRIO DA UNIDADE
UNIDADE II ................................................................................................ 60
ANLISE DE SOFTWARE ........................................................................ 60
3. A Linguagem UML ............................................................................... 62
1.7. A Origem da UML ......................................................................... 62
1.8. Vises ............................................................................................. 64
1.9. Modelo de Elementos ..................................................................... 65
3.1.1. Classes ..................................................................................... 65
3.1.2. Objetos .................................................................................... 67
3.1.3. Estados .................................................................................... 68
3.1.4. Pacotes..................................................................................... 68
3.1.5. Componentes ........................................................................... 69
3.1.6. Relacionamentos ..................................................................... 69
1.10. Mecanismos Gerais ...................................................................... 74
1.11. Diagramas .................................................................................... 75
3.1.7. Diagrama de Casos de uso ...................................................... 75
3.1.8. Diagrama de Classes ............................................................... 76
3.1.9. Diagrama de Objetos ............................................................... 76
3.1.10. Diagrama de Estados ............................................................. 77
3.1.11. Diagrama de Seqncia ......................................................... 78
3.1.12. Diagrama de Colaborao ..................................................... 79
3.1.13. Diagrama de Atividades ........................................................ 80
3.1.14. Diagrama de Componentes ................................................... 81
3.1.15. Diagrama de Implantao ..................................................... 81
1.12. Consideraes Finais .................................................................... 82
1.13. Exerccios ..................................................................................... 82
4. O Fluxo de Anlise................................................................................ 84
1.14. Atividades do Fluxo de Anlise ................................................... 84
4.1.1. Identificao das Classes......................................................... 85
4.1.2. Organizao das Classes ......................................................... 94
4.1.3. Realizao dos Casos de Uso .................................................. 95
4.1.4. Reviso da Anlise .................................................................. 97
1.15. Exerccios ..................................................................................... 98
5. Anlise de Pontos de Funo ................................................................ 99
5.1 Introduo a Anlise de Pontos de Funo ................................... 103
5.2 O Processo de Contagem .............................................................. 105
5.2.1 Contagem de Funes de Dados ............................................ 112
5.2.2 Contagem de Funes de Transao ...................................... 114
5.3 Contagem Estimativa de Pontos de Funo .................................. 120
5.3.1 Contagem de funes de dados .............................................. 122
5.3.2 Contagem de funes de transao ........................................ 124
5.4 Planejamento e Gesto de Projetos com PF .................................. 130
5.5 Viso crtica da APF ..................................................................... 131
5.6 Exerccios ...................................................................................... 134
61
UNIDADE II
O FLUXO DE ANLISE
3. A Linguagem UML
A modelagem um dos conceitos importantes para o
desenvolvimento de software. Um modelo uma abstrao de algo,
em que nos concentramos nos aspectos fundamentais do que se
est querendo modelar, ignorando os aspectos que no so
relevantes.
Modelos so fundamentais no desenvolvimento pois criam
uma camada de abstrao do que estamos querendo modelar,
focando apenas no que importante. Isso permite que os
desenvolvedores consigam representar algo complexo de forma bem
mais simples, explorando apenas o que se deseja explorar em um
determinado momento.
A Unified Modelling Language (UML), ou Linguagem de
Modelagem Unificada em Portugus, uma linguagem utilizada para
a criao de modelos. Ela possui uma interessante caracterstica
que a fez ser to difundida: ela uma linguagem baseada em
diagramas, o que a torna muito mais simples de usar e entender.
Existem diversas
ferramentas UML
disponveis.
Escolhemos uma por
sua adequao ao que
necessitaremos e no
por ser melhor que as
outras ferramentas
existentes.
Neste trabalho utilizaremos uma ferramenta gratuita para a

modelagem UML. O objetivo possibilitar o uso de uma ferramenta,
aplicando os conceitos de forma prtica. A ferramenta selecionada
foi
ASTAH,
que
pode
ser
gratuitamente
obtida
em
http://astah.change-vision.com. Utilizamos a verso community para

demonstrar a aplicao prtica dos conceitos apresentados durante
o captulo.
1.7.
A Origem da UML
62
At o surgimento da UML existiam diversos processos de

software e diversas linguagens de modelagem associadas aos
processos. Isso gerava muitos problemas, devido a ausncia de um
padro para se modelar conceitos de um sistema. Por conta disso,
houve uma tentativa de padronizar os processos e as linguagens de
modelagem, gerando uma unificao dos conceitos associados. Isso
deu origem ao Processo Unificado (Unified Process UP) e a UML.
Trs processos deram origem ao UP e UML:
Booch Esse mtodo foi criado por Grady Booch e foi

baseado no fato de um sistema ter diversas vises, cada uma
descrita por modelos e diagramas. O mtodo possua uma
simbologia complexa de ser desenhada mo.
OMT O Object Modelling Technique foi desenvolvido pela

General Electric onde o pesquisador James Rumbaugh
trabalhava.
Os
modelos
prescritos
pelo
mtodo
so
compostos por modelos de objetos, funcional e casos de uso.
OOSE/Objectory Os dois mtodos foram desenvolvidos por

Ivar Jacobson. Ambos so baseados na utilizao de casos
de uso, a partir da modelagem dos requisitos iniciais do
sistema vistos por um ator externo. O mtodo Objectory foi
adaptado para permitir seu uso tambm para a modelagem
de processos de negcio, fundamentais no funcionamento de
qualquer organizao.
Os mtodos citados anteriormente tinham idias em comum e
idias diferentes. Da mesma forma, eles possuam notaes

prprias. A partir disso, os trs amigos resolveram criar um notao
nica, baseada no que havia de melhor em cada notao. Isso deu
origem UML. De forma similar, eles criaram um processo nico,
tambm baseado na unificao das melhores idias existentes nos
processos, criando assim o UP.
A UML atualmente um padro de facto. O mundo inteiro
utiliza a UML. Ela uma forma de comunicao padro que aceita
e exigida por muitas organizaes. Para entendermos a UML
63
necessrio saber como ela dividida. Nas prximas sees

apresentaremos cada uma das partes da UML: Vises, Modelos de
Elementos, Mecanismos Gerais e Diagramas.
1.8.
Cada viso foca em um
aspecto particular do
produto sendo
modelado.
Vises
Uma viso mostra um aspecto diferente do sistema que est

sendo modelado, sendo normalmente composta por diversos
diagramas que focam em aspectos particulares de um sistema. As
principais vises da UML so:
Viso de Casos de Uso: descreve o comportamento do

sistema, a partir da definio de como o sistema se
comportar a partir da interao com os atores externos que o
utilizaro. Isso est diretamente ligado ao diagrama de casos
de uso.
Viso
Lgica:
descreve
como
comportamento
ser
implementado. Enquanto a viso de caso de uso est muito

mais associada viso externa do sistema, a viso lgica
foca na viso interna, descrevendo os mecanismos que sero
necessrios para que o sistema funcione. Isso inclui a
estrutura
esttica,
composta
por
classes,
objetos,
relacionamentos, assim como a estrutura dinmica, composta

por realizaes. A parte esttica da viso lgica descrita por
diagrama de classes e de objetos. A parte dinmica descrita
por diagramas de estado, seqncia, colaborao e atividade.
Viso de Componentes: descreve a diviso da implementao

em mdulos, demonstrando suas dependncias. Essa viso
est diretamente ligado ao diagrama de componentes.
Viso de concorrncia: descreve o sistema sob a perspectiva

de diviso em processos e processadores, indicando se
haver execues em paralelo, detalhando a comunicao e
a concorrncia existente no sistema. Essa viso pode ser
descrita pelos diagramas dinmicos (estado, seqncia,
64
colaborao
atividade),
alm
dos
diagramas
de
desdobramento.
Viso de Organizao: descreve a organizao fsica do

sistema, indicando os computadores, perifricos e suas
conexes entre si. Essa viso ligada aos diagramas de
desdobramento.
1.9.
Modelo de Elementos
Os conceitos utilizados nos diagramas so modelos de

elementos. Eles representam as definies comuns existentes na
linguagem, tais como classes, objetos, mensagens, atributos e
relacionamentos. Esta seo detalha os principais modelo de
elementos existentes na UML.
3.1.1.
Classes
Uma classe uma representao abstrata de um conceito.

Nessa representao tentamos focar nos dados relacionados
entidade sendo modelada, bem como nas possveis operaes que
podem acontecer sobre esses dados.
Na UML as classes so representadas por um retngulo que
pode ser dividido em at 3 compartimentos: o nome da classe, seus
atributos e as operaes possveis.
A identificao de classes em um sistema feito a partir de
uma anlise da Especificao de Requisitos. A notao de classes
da UML independente da linguagem a ser utilizada. Assim, uma
classe representada em UML pode ser gerada em Java, C++, Ruby,
etc.
65
Figura 8: Exemplo de Classe.
A Figura 8 exibe um exemplo de classe. O nome da classe

Pessoa. Ela possui diversos atributos (nome, email, telefone, celular,
login e senha). Na classe existe apenas uma operao (salvar). Para
se criar uma classe utilizando a ferramenta Astah ser necessrio
criar um diagrama de classes, uma vez que tal diagrama possibilita a
criao de classes. Uma vez criado um diagrama de classe, ser
exibida uma barra de ferramentas similar mostrada na Figura
9Figura 9. De forma geral, todas as ferramentas UML apresentam
barras de ferramentas para facilitar a criao de elementos em
diagramas. Para cada diagrama, uma barra de ferramentas com os
elementos possveis de integrar o diagrama so exibidos.
Figura 9: Barra de ferramentas para criao de diagramas de classe.
O primeiro item na barra de ferramenta o item para seleo

de objetos. O segundo item o boto que permite criar classes.
Basta clicar nele e clicar no diagrama para que uma classe seja
criada. Aps sua criao, possvel, via acionamento do boto
direito do mouse sob a classe, criar atributos e operaes, conforme
exibido na Figura 10.
66
Figura 10: Criao de atributos e operaes para classes.
3.1.2.
Objetos
Os objetos representam instncias de uma classe. De

maneira simples, enquanto que as classes representam conceitos,
objetos representam coisas reais associadas ao conceito modelado.
Como exemplo, na Figura 9 temos a representao do conceito
pessoa, indicando que algo que contm nome, email, celular, etc.
Na Figura 11 temos um exemplo de uma instncia de Pessoa, que
possui nome Pedro, email pedro@gmail.com, etc. Esse apenas um
exemplo de Pessoa, mas muitos outros podem ser criados.
Para criar um objeto, podemos utilizar a barra de ferramentas
exibida na Figura 9. O boto para tal ao o 15o. elemento da
esquerda para a direita. Ao se passar o ponteiro do mouse por cima
dele ser exibido o texto InstanceSpecification. Ao clicar no boto,
para que ele fique selecionado, clicando em qualquer local dentro do
diagrama de classe, um objeto ser apresentado. Depois disso voc
ter que associar o objeto a uma classe, para que em seguida seja
possvel especificar os valores dos atributos.
67
Figura 11: Exemplo de um objeto pessoa.
3.1.3.
Estados
Os objetos normalmente possuem um estado. Um estado

representa o resultado das operaes executadas no objeto, sendo
normalmente determinado pelos valores de seus atributos e ligaes
existentes com outros objetos. A Figura 12 apresenta dois estados
relacionados a um objeto Livro. Um livro pode estar livre ou
emprestado. Para mudar de livre para emprestado necessrio que
o evento emprstimo seja realizado. Para mudar de emprestado
para livre, necessrio que o evento devoluo acontea. Os
estados de um objeto podem deixar claro seu funcionamento, sendo
uma descrio simples de se entender e bastante expressiva.
Figura 12: Exemplos de estados para o objeto Livro.
3.1.4.
Pacotes
Um Pacote um agrupamento de itens, utilizado para fins de

organizao. De forma geral, esses agrupamentos so feitos para se
manter juntos elementos que possuem algum tipo de relao entre
si. Os pacotes podem ser criados dentro dos modelos UML, a partir
do acionamento do boto direito do mouse em cima do local
desejado. De forma simples, um pacote pode ser comparado a uma
68
pasta dentro do modelo. A Figura 13 apresenta um exemplo de

criao de um pacote em um modelo UML.
Figura 13: Criao de um pacote na ferramenta Astah.
3.1.5.
Componentes
Um componente a representao de uma parte do sistema.

Isso pode ser um cdigo na linguagem fonte ou cdigo executvel.
Imagine um sistema feito em Java. Cada arquivo .class pode ser
considerado um componente, assim como qualquer arquivo .java. A
Figura 14 exibe exemplos de componentes criados na Astah.
O uso desse tipo de elemento est diretamente associado ao
projeto de um software. Por conta disso, ele ser pouco explorado
neste material, uma vez que estamos tratando de requisitos e
anlise.
Figura 14: Exemplos de componentes.
3.1.6.
Relacionamentos
Os relacionamentos permitem a ligao de classes e objetos

entre si, estabelecendo uma relao entre eles. Essas ligaes
podem assumir os seguintes tipos: associao, generalizao e
dependncia. A seguir detalhamos brevemente cada um dos tipos
de relacionamentos.
Associao
69
Uma associao cria uma conexo entre as classe ou entre

objetos das classes. Dessa forma, uma associao entre classes
indica que qualquer objeto de uma classe ter uma conexo com um
objeto da outra classe.
A associao simples a forma mais comum de uma
associao. Ela representada por uma linha ligando duas classes.
Essa linha pode possuir uma seta indicando direo. Isso significa
que ela s pode ser usada para o lado em que ela aponta. No
havendo seta, significa que os dois lados so navegveis. A Figura
15 exibe um exemplo contendo associaes com e sem direo. Isso
significa que podemos obter os Membros a partir de um Projeto,
assim como a partir de Membro podemos obter os Projetos, uma vez
que a associao no possui direo. J a outra associao indica
que podemos obter facilmente os Clientes de um Projeto, mas o
inverso no verdadeiro.
Figura 15: Exemplo de classes com associaes com e sem direo.
A Figura 16 exibe as mesmas associaes contidas na Figura

15, porm, com a especificao dos nomes dos papis nos
relacionamentos e multiplicidades das relaes. Os nomes dos
papis do origem ao nome dos atributos das classes quando
fazemos gerao de cdigo. Dessa forma, ao gerarmos cdigo para
a classe Projeto, ela conter dois atributos de coleo: um
denominado membros e outro chamado clientes. A maioria das
ferramentas UML permitem alguma gerao de cdigo. No entanto,
isso no est diretamente ligado aos objetivos deste material, pois
estamos ainda entendendo o problema e no projetando uma
soluo.
70
Para se inserir nome dos papis, multiplicidade e nome nos

relacionamentos, voc deve clicar na associao e visualizar a caixa
de propriedades do item, que normalmente fica localizado no canto
inferior esquerdo da tela da ferramenta Astah.
Figura 16: Associao com nomeao dos papis e multiplicidades.
A multiplicidade das associaes pode assumir diversos

valores, tais como 0..1 (zero ou um), 2 (dois), 4..9 (de quatro a
nove), etc. O uso de * indica que no h um limite estabelecido.
Quando no descrito multiplicidade utilizamos como padro 1.
Figura 17: Exemplo com auto-associao e especificao do nome da associao.
A Figura 17 exibe um exemplo de associao recursiva entre

Membro
(tambm
chamada
de
auto-associao).
Conforme
especificado, um membro, que um chefe, chefia vrios membros

subordinados. Da mesma forma, um membro subordinado tem um
membro que seu chefe. Esse exemplo tambm mostra uma
associao com nome (chefia).
Existem outros tipos de associao que no sero detalhados
aqui, como as associaes com restries, associaes ternrias,
associaes qualificadas e classes de associao. No entanto,
existe muito material na Internet disponvel sobre o assunto, que no
71
to comum de ser encontro em modelos de anlise, foco deste

documento.
Ainda existem dois tipos particulares de associao que
merecem comentrios: agregao e composio. A Agregao
uma associao que indica a relao todo/parte. Isso significa que
um dos itens relacionados o todo na relao e o outro uma parte.
Normalmente os nomes das associaes, caso fossem utilizados,
deveriam ser tem, contm, faz parte. Uma agregao no
possui uma representao especfica na maioria das linguagens de
programao nem necessitam de um comportamento especial da
implementao associada. A Figura 18 exibe um exemplo que mostra
que um Projeto contm Membros.
Conforme comentado, a
implementao da agregao entre projeto e membros dever gerar

a mesma implementao que uma associao normal. Observe que
uma Agregao representada por um losango no preenchido.
necessrio termos muita ateno com a simbologia associada
UML: o uso de um smbolo errado pode passar um idia
completamente diferente do que se desejava!
Figura 18: Exemplo de agregao.
A Figura 19 exibe uma associao do tipo Composio. Nesse

tipo de associao existe um relacionamento forte entre os
integrantes: a parte no vive sem o todo. Dessa forma, a
implementao de uma Composio exige que esse comportamento
seja implementado, caso contrrio, no estaremos cumprindo o que
foi modelado. No exemplo temos modelado que Scio contm
Dependentes. Dessa forma, est implcito que, a excluso de um
scio, implica na excluso de todos os seus dependentes.
72
Figura 19: Exemplo de Composio.
Observe que a composio tambm representada por um

losango, porm, preenchido. Observe tambm que a diferena entre
estar ou no preenchido pode causar uma grande mudana no
entendimento e na forma de implementar o que foi modelado!
Generalizaes
Uma Generalizao indica que um elemento herdar todos os
atributos e operaes de um outro elemento, podendo ainda incluir
comportamento adicional. Nos locais em que so esperados um
elemento do tipo mais geral pode-se utilizar um elemento especfico
sem qualquer problema.
A Figura 20 exibe um exemplo de generalizao. Nela
podemos notar que um Projeto possui um Cliente, que a classe
genrica. Um Cliente pode tanto ser uma Pessoa Fsica como uma
Pessoa Jurdica.
Figura 20: Exemplo de Generalizao.
Dependncias
73
A Dependncia uma relao mais fraca entre elementos,

que indica que uma alterao em um elemento pode indicar uma
mudana de comportamento em outro. A dependncia muito
utilizada na especificao de arquitetura de um sistema, indicando
que um determinado sistema depende de tecnologia X, Y, Z. De
forma geral uma relao mais fraca que a associao mas indica
uma conexo semntica entre os envolvido.
Figura 21: Exemplo de Dependncia entre classes.
A Figura 21 exibe uma relao de dependncia entre classes.

Pode-se visualizar que a classe Dependente possui um mtodo
salvar que possui um parmetro do tipo Conexo. Logo, uma
alterao no tipo Conexo pode causar uma mudana no
comportamento de Dependente. Isso causa a dependncia entre as
classes. A dependncia no precisa ser exibida nos diagramas, a
no ser que seja necessrio expor essa dependncia. Por conta
disso, na figura existe a composio entre scio e dependente
exibida duas vezes, sendo que na parte do lado direito foi enfatizada
a dependncia entre a classe Dependente e conexo, uma vez que
dentro da classe Dependente existe um mtodo que usa um objeto
do tipo Conexo.
1.10.
Mecanismos Gerais
Na UML existem informaes adicionais que so associados

aos modelos. O grande exemplo disso so as notas. Embora a UML
tenha muita semntica associada s representaes, no possvel
modelar tudo. Dessa forma, uma nota pode ajudar a detalhar certas
informaes. A Figura 22 exibe um diagrama contendo uma nota.
74
Nela, especificado uma regra para a associao de scios e

dependentes, utilizando nossa linguagem natural.
Figura 22: Exemplo de nota em um diagrama.
1.11.
Diagramas
Na UML existem diversos grficos que descrevem o que

existe em uma viso. Esses grficos so os diagramas, utilizados
para criar as vises do sistema. Existem 9 diagramas na UML que
sero apresentados nas prximas subsees. A criao de um
diagrama na ferramenta Astah feito a partir do menu Create
Diagram, exibido quando se clica com o boto direito em algum
pacote do modelo. A partir desse menu possvel criar qualquer um
dos diagramas existentes. A Figura 23 exibe o menu para criao de
diagramas na ferramenta Astah.
Figura 23: Menu para criao de diagramas na Astah.
3.1.7.
Diagrama de Casos de uso
O diagrama de casos de uso exibe os requisitos funcionais de

um sistema. Isso est diretamente ligado ao comportamento que o
sistema dever adotar. Nesse diagrama existem atores, que
representam papis no sistema e casos de uso, que representam as
75
funcionalidades existentes. A ligao entre atores e caso de uso

indica que h comunicao entre eles. Uma seta direcionada pode
ser utilizada para definir o sentido da comunicao.
A Figura 24 exibe um exemplo de diagrama de casos de uso.
Temos o caso de uso Reserva de livro, associado ao ator Aluno.
Nesse caso, pode-se concluir que um aluno pode reservar um livro,
embora no tenhamos detalhes sobre quais so as regras
especficas para a reserva. O ator Aluno, nesse caso, representa um
Diagramas de caso de
uso so excelentes para
se obter um
entendimento rpido
sobre um sistema!
papel relacionado a um grupo de usurios. O outro caso de uso da

figura, Invalidao de reserva, est associado ao ator Tempo. Isso
indica que o caso de uso acionado automaticamente dentro de
certos perodos de tempo pr-estabelecidos.
Figura 24: Exemplo de casos de uso.
3.1.8.
Diagrama de Classes
O diagrama de classes est associado viso esttica de um

sistema. Conforme visto neste captulo, classes podem se associar a
outras classes de diferentes formas (associao, composio,
dependncia, etc.). Um sistema real pode conter um nmero grande
de classes, sendo necessrio a criao de diversos diagramas, cada
um focando em um aspecto especfico. Uma mesma classe pode
aparecer em diferentes diagramas. Nas figuras anteriores foram
apresentados diversos diagramas de classe para se explicar os mais
diferentes relacionamentos entre classes.
3.1.9.
Diagrama de Objetos
O diagrama de objetos descreve uma instncia especfica de

uma diagrama de classe. Sua notao bem prxima do diagrama
76
de classe, porm, importante frisar que ele exibe as instncias das

classes, com sua configurao de execuo momentnea.
Os diagramas de objetos no so to utilizados nos modelos,
mas servem para esclarecer aspectos importantes de diagramas
complexos. A Figura 25 exibe um diagrama de objetos para o
diagrama de classe apresentado na Figura 19. Essa apenas uma
possvel configurao para o diagrama de classe comentado. Nele
podemos perceber que o Scio Pedro possui dois dependentes: Ana
Diagramas de objetos
podem facilitar o
entedimento de classes
complexas, a partir da
demonstrao de uma
instncia especfica,
onde podemos
demonstrar alguns
aspectos mais difceis
de serem entendidos.
Clia e Joana. Diversas outros diagramas de objetos so possveis,

desde que eles no violem as restries existentes no diagrama de
classe original.
Figura 25: Diagrama de objetos.
Os diagramas de
estados mostram a
dinmica das classes e
so facilmente
entendidos por usurios
leigos, a partir de um
mnimo de explicao.
3.1.10.
Diagrama de Estados
O diagrama de estados descreve o comportamento dinmico

de uma instncia de uma classe, normalmente representando seu
ciclo de vida. Esse diagrama importante para descrever classes
que possuem objetos com ciclos complexos, uma vez que podemos
especificar as aes e condies associadas s mudanas de
estado.
A exibe um diagrama de estados para um objeto Livro. Ele
inicia livre, pronto para ser reservado, emprestado ou tornado cativo
e, dependendo da funo utilizada, pode assumir outros estados.
Um livro pode ser reservado, para depois ser emprestado e ento
devolvido para que seja feito novo emprstimo. No diagrama, temos
a indicao que o estado inicial de um objeto livro livre e que
furtado um estado final (sinalizado pelo estado final, ligado ao
estado furtado). Um estado final indica que o ciclo de vida do objeto
77
acabou, no sendo possvel mais nenhuma outra transio de

estados.
Figura 26: Diagrama de estados para o objeto Livro.
3.1.11.
Diagrama de Seqncia
O diagrama de seqncia mostra a troca de mensagens entre

objetos durante a implementao de certos comportamentos. O foco
no diagrama de seqncia mostrar as interaes entre objetos, ao
invs de mostrar apenas o comportamento interno de um objeto. Ele
ainda apresenta a ordem temporal das chamadas, destacando assim
a seqncia das aes invocadas, por isso seu nome.
A Figura 27 exibe um diagrama de seqncia. Os objetos
associados ao diagrama so exibidos na forma de um retngulo,
com uma linha tracejada abaixo. Essa linha chamada linha da vida
do objeto, indicando quando o objeto est vivo durante a execuo
do roteiro sendo modelado. As setas entre objetos indicam o
acionamento de algum mtodo existente via troca de mensagens.
Na figura podemos notar que o objeto Scio invoca o mtodo criar
do objeto Dependente, acionando os mtodos associar e salvar logo
em seguida. O mtodo salvar, do objeto Dependente, aciona o
mtodo validar, tambm interno a Dependente, que por sua vez
78
aciona o mtodo validarCPF do objeto til e salvarObjeto do objeto

Persistncia. Fica claro a ordenao temporal das chamadas.
Diagramas de seqncia podem ser utilizados para se
detalhar casos de uso. Essa uma notao alternativa aos textos
descrevendo os diversos fluxos que compem os casos de uso. No
entanto, essa alternativa mais difcil de ser entendida pelos
clientes, razo essa que dificulta sua adoo com essa finalidade.
Figura 27: Exemplo de Diagrama de Seqncia.
Um outra aplicao para diagramas de seqncia exibir

conceitos
chaves
de
uma
arquitetura,
detalhando
como
determinados roteiros funcionam. Ele serve como uma explicao do

que acontece em determinados casos, uma vez que detalha o
comportamento dinmico que parte de um software pode ter sob
certas circunstncias.
3.1.12.
Diagrama de Colaborao
O diagrama de colaborao pode ser considerado como uma

outra forma de exibio do diagrama de seqncia. Um diagrama
pode ser convertido para o outro, na maioria das ferramentas UML, a
partir de um clique.
A diferena entre os diagramas est no foco: no diagrama de
colaborao enfatizado a troca de mensagens entre objetos e no
79
sua ordem temporal. O diagrama de colaborao pouco utilizado

no desenvolvimento de software, sendo prefervel o diagrama de
seqncia. Por conta disso, no daremos muita nfase a ele neste
trabalho.
3.1.13.
Diagrama de Atividades
O diagrama de atividades uma variante do diagrama de

estados na UML. Porm, seu objetivo completamente diferente:
Diagramas de atividade
podem ser utilizados
com diferentes
propsitos. At mesmo
para modelar um
processo!
enquanto os diagramas de estados exibem o comportamento interno

de um objeto, o diagrama de atividades exibem as aes associadas
a um roteiro, possibilitando detalhar os executores envolvidos e os
produtos de trabalho gerados.
Diagramas de atividades podem ser usados para detalhar
etapas de um processo, descrio de fluxos de um caso de uso e
qualquer outro roteiro que exija a informao das aes associadas.
Neste trabalho, utilizamos diagramas de atividades para
descrever os processos relacionados com requisitos e anlise.
Figura 28: Descrio de um processo utilizando Diagrama de Atividades.
80
A Figura 28 exibe um diagrama de atividades criado com o

intuito de descrever um processo para criao de mquinas virtuais
em um Datacenter. Podemos notar que o diagrama exibe a ordem
em que as aes devem acontecer, deixando claro os responsveis
(exibidos na forma de diviso de colunas no diagrama). Existe no
diagrama uma condio que indica para onde a execuo deve ir,
caso determinada situao acontea.
3.1.14.
Diagrama de Componentes
O diagrama de componentes exibe a relao entre as partes

que compem um sistema e a organizao dos mdulos. Eles
podem representar classes, pacotes e subsistemas. Esse tipo de
diagrama muito associado exibio da arquitetura de um
sistema, deixando claro como ele est estruturado, alem de
demonstrar sua organizao e dependncia.
Figura 29: Diagrama de Componentes detalhando estrutura de um sistema.
A Figura 29 exibe um diagrama de componentes detalhando a

estrutura de um sistema. Podemos notar que os subsistemas RH e
Acadmico dependem do sistema Administrativo. De mesma forma,
poderamos detalhar dependncias entre pacotes, classes e outros
subsistemas. Isso descreve o agrupamento utilizado na construo
de um sistema, exibindo ainda sua organizao e dependncias.
3.1.15.
Diagrama de Implantao
O diagrama de implantao exibe a arquitetura de execuo

de um sistema, detalhando os componentes fsicos que executam no
81
ambiente de execuo utilizado. Com isso possvel detalhar que

mdulo
funcionar
em
qual
dispositivo
como
ser
sua
comunicao com outros dispositivos.
Esse tipo de diagrama tambm muito associado exibio da

arquitetura de um sistema, deixando claro como ser organizada sua
execuo.
1.12.
Consideraes Finais
Neste captulo apresentamos a UML. Essa linguagem

atualmente um padro de facto para a modelagem no mundo.
Demonstramos sua diviso e como utliz-la a partir de uma
ferramenta gratuita, a Astah. No prximo captulo iremos apresentar
como usar a UML para modelar aspectos identificados em uma ER,
embora isso j tenha iniciado com a criao de diagramas de caso
de uso durante o levantamento de requisitos.
1.13.
Exerccios
1. O que um modelo?
2. O que a UML?
3. Qual a origem da UML?
4. O que so as vises da UML?
5. Quais so as vises existentes na UML?
6. O que uma classe? Como ela representada em UML?
7. O que um objeto? Como ele representado em UML?
8. O que um estado na UML?
82
9. Quando devemos utilizar estados da UML?

10. O que um pacote na UML?
11. O que um componente na UML?
12. Existem diversos tipos de relacionamentos entre classes
na UML. Descreva a associao simples, apresentando
um exemplo com nome dos papis e cardinalidades.
13. O que uma autoassociao?
14. Qual
diferena
de
uma
agregao
para
uma
composio?
15. Cite
um
exemplo
prtica
de
uma
Generalizao,
demonstrando isso no formato prescrito pela UML.

16. O que significa o relacionamento de dependncia?
17. Crie um diagrama de caso de uso para um sistema
acadmico, com pelo menos 4 casos de uso.
18. Crie um diagrama de estados para um sistema acadmico,
com pelo menos 5 classes.
19. Crie um diagrama de estado para modelar algo que faa
parte do seu dia a dia.
20. Para que utilizamos o diagrama de atividades?
21. Crie um diagrama de atividades para modelar algo em seu
trabalho ou relacionado ao seu dia a dia.
22. Para que serve o diagrama de componentes?
23. Qual o objetivo do diagrama de implantao?
83
UNIDADE II
O FLUXO DE ANLISE
4. O Fluxo de Anlise
O Fluxo de Anlise tem como objetivo modelar os conceitos
identificados na ER, tornando-os mais prximos do mundo
computacional e um pouco mais distante dos usurios finais. Com
isso, tambm feita uma reviso dos requisitos identificados,
visando avaliar sua qualidade.
Atualmente, a Anlise Orientada a Objetos o formato mais
utilizado para modelagem dos conceitos existentes em uma ER. Por
conta disso, utilizaremos bastante o conceito de classe e objeto.
Tambm ser bastante utilizada a linguagem UML, uma vez que a
Anlise se baseia na modelagem dos conceitos existentes na ER.
1.14.
Atividades do Fluxo de Anlise
Figura 30: Atividades do Fluxo de Anlise.
A Figura 30 exibe as atividades do Fluxo de Anlise. Conforme

foi ressaltado durante a apresentao do Fluxo de Anlise,
enfatizamos que essa figura exibe uma sugesto de atividades para
o fluxo. Processos como o RUP prescrevem muito mais atividades
enquanto processos geis prescrevem muito pouco. De forma geral,
colocamos aqui apenas o essencial e que provavelmente seja
interessante em qualquer processo.
84
O Fluxo de Anlise inicia pela identificao das classes. Nessa

atividade teremos que traduzir os conceitos relevantes, identificados
na ER, em classes, relacionamentos, atributos e operaes.
Na atividade Organizao das classes feito uma organizao
das classes identificadas, criando pacotes (pastas) para melhor
agrupamento dos itens e atribuindo esteretipos a todos os
No existe consenso
sobre as atividades
relacionadas Anlise.
Neste trabalho
detalhamos aquilo que
muito til na prtica e
presente em muitos
processos.
elementos identificados.
Na Realizao dos Casos de Uso so exibidas as interaes
entre objetos para se implementar um determinado comportamento,
expresso na descrio dos casos de uso da ER. A diferena est no
formato dessa descrio, que ser feita na forma de troca de
mensagens entre objetos.
A Reviso da Anlise o momento em que o trabalho realizado
no fluxo revisto, no intuito de se aumentar a qualidade e evitar que
problemas
se
perpetuem
no
restante
das
atividades
de
desenvolvimento.
4.1.1.
Identificao das Classes
O principal resultado obtido durante a Identificao das Classes

a criao de diagramas modelando os principais conceitos
existentes no sistema.
Um conceito simples de entender e modelar est relacionado
aos dados persistentes. Praticamente todas as aplicaes existentes
necessitam persistir dados. Um diagrama exibindo todos as classes
associadas a dados persistentes, demonstrando os relacionamentos
existentes, facilita bastante o entendimento do problema e at
mesmo a criao de uma soluo. Esse diagrama normalmente
denominado Diagrama de Classes de Entidade. Uma entidade
uma classe que est relacionada a dados persistentes.
Dando continuidade ao nosso exemplo, com requisitos
levantados na Unidade I, poderemos agora iniciar o levantamento
85
das classes persistentes, para depois detalharmos tais classes. Para

que isso seja feito, necessrio analisar cada caso de uso,
procura de informaes que devem ser persistidas.
Iniciando essa anlise, a partir do caso de uso Cadastro de
Projeto, podemos notar a necessidade de termos uma entidade
associada a Projeto. Pela descrio do caso de uso fcil notar que
No existe uma tcnica
bem estabelecida e
reconhecidamente
efetiva para a
identificao de classes.
O entendimento do
contexto descrito na ER
e o bom senso apurado
so as melhores
tcnicas existentes!
um projeto deve possuir uma sigla, descrio e um gerente

associado. Aqui cabe uma anlise a mais: um gerente ser uma
outra entidade ou pode ser apenas um campo texto para informao
do seu nome? Nossa idia cadastrar gerentes de projeto, para que
possamos associ-los a outros projetos e manter assim um histrico
de execues. Dessa forma fundamental que os gerentes estejam
associados a alguma entidade. Com isso j possvel criar as
entidades Projeto e Gerente.
Continuando a anlise, podemos notar que o caso de uso
Gesto de Gerentes nos fornece mais informaes sobre os dados
associados a um gerente, tais como nome, email, telefone, login e
senha. Assim, podemos completar a classe Gerente, j identificada,
adicionando tais atributos.
O prximo caso de uso, Gesto de Membros, nos faz refletir
sobre alguns pontos importantes. Um membro pode ser um Cliente
ou um Engenheiro de Requisitos, conforme consta no caso de uso.
Dessa forma fica a reflexo: ser que necessitamos realmente de
uma classe de entidade para modelar Gerente ou ser que o
Gerente de um projeto tambm no um Membro? No existe uma
resposta precisa sobre a questo, pois o contexto deve ser
analisado. No entanto, definimos nesse trabalho, por achar mais
adequado, que devemos ter apenas a classe Membro. Assim, a
classe Gerente, identificada no pargrafo anterior ser excluda do
nosso modelo, ficando apenas Projeto e Membro at o momento.
Isso
nos
gera
modelo
exibido
na
86
Figura 31. A classe projeto contm vrios outros atributos

identificados a partir da anlise do caso de uso Controle de Projetos.
Figura 31: Modelo representando Projeto e Membro.
Uma outra constatao interessante que os membros

possuem login e senha para acesso ao sistema. Tomamos a deciso
de modelar isso em uma classe separada, indicando que os
membros so usurios do sistema. Observe que isso foi uma
deciso de modelagem tomada pela equipe, sem que houvesse um
indicao na ER que pudesse nos levar a isso. Poderamos ter
mantido
os
atributos
de
Usurio
na
classe
Membro,
no
necessitando dessa classe extra. Porm, acreditamos que a

modelagem utilizada mais apropriada e permite uma maior
inteligibilidade representao. Por conta disso, resolvemos adotla. Isso exibido na Figura 32.
87
Figura 32: Extrao da classe Usurio.
Continuando nossa anlise, partirmos para o caso de uso

Gesto de Requisitos. fcil notar que um projeto pode ter vrios
requisitos. Os requisitos possuem atributos simples: identificador,
nome, descrio, tipo, prioridade, complexidade e situao. Os
atributos relacionados a uma lista com valores fixos e pr-definidos,
como o caso de tipo, prioridade, complexidade e situao, podem
ser modelados com o tipo inteiro, onde cada valor pode ser
representado por um nmero. No entanto, a anlise desse caso de
uso nos levanta duas questes interessantes:
1. Qual o tipo de associao entre projeto e requisitos? Ela no
parece ser uma associao simples. Os requisitos fazem
parte do projeto e parecem no sobreviver sem a existncia
do projeto. Isso nos remete ao conceito de composio.
Dessa forma, modelaremos a associao entre projeto e
requisitos como uma composio.
2. No prottipo da tela de gesto de requisitos existe um
histrico de alterao. Isso nos indica que ser necessrio a
existncia de uma entidade que modele as alteraes de
requisitos. Nesse caso, a classe requisito dever ter uma
associao com os histricos de alterao.
88
A modelagem das classes at as consideraes acima, nos

remete a um modelo conforme o exibido na Figura 33.
Figura 33: Modelo do sistema contendo requisitos e alteraes.
Os prximos casos de uso: Gesto de Atores e Gesto de

Casos de Uso, esto bastante relacionados. A classe Ator possui
atributos simples (nome e descrio) e pode estar relacionada a
vrios casos de uso, uma vez que possvel registrar vrios casos
de uso associado a um ator.
O caso de uso Gesto de Casos de Uso possui diversos
atributos e relacionamentos com outras classes. fcil perceber que
um caso de uso pode ter vrios prottipos de tela. Isso nos remete a
uma nova classe (Prottipo) e o relacionamento com essa classe.
Como um prottipo no consegue viver dissociado de seu caso de
uso, isso indica uma composio entre os dois.
Algo bem mais interessante acontece com os fluxos. Observe
que um caso de uso tem um fluxo principal, diversos fluxos
alternativos e diversos subfluxos. Um fluxo contm seu nome e
passos. Fluxos alternativos contm, alm disso, pr-condies. Isso
89
denota
que
existe
uma
generalizao
envolvida
nesse
relacionamento. Dessa forma, fluxo algo que contm nome e

passos e fluxo alternativo um fluxo com pr-condies. Observe
que na Figura 34 apresentamos um exemplo para tal modelagem. A
classe Caso de uso contm dois relacionamentos com Fluxo: uma
para representar o fluxo principal e outro para representar os
possveis subfluxos existentes. importante ressaltar que essa
uma boa modelagem para o problema, mas difcil de ser percebida
para iniciantes na execuo da Anlise.
Figura 34: Modelagem para Ator e Caso de uso.
A ltima parte da ER a ser considerada para Anlise a parte

relacionada
complexidade
Reviso.
associada,
Essa
no
parte
sendo
tambm
trivial
possui
sua
uma
anlise
entendimento. Um projeto pode possuir diversas revises. As

revises tem critrios associados, com uma indicao de aprovao
e uma observao, alm da associao ao item sendo avaliado, que
pode ser um requisito ou caso de uso. Mas como representar isso?
Nesse caso teremos que criar uma classe adicional, no visvel
pelos usurios diretamente, para agrupar todos os elementos
necessrios ao relacionamento. Assim, teremos um item de
90
avaliao, que estar relacionado ao critrio utilizado para avaliao,

reviso em andamento e ao elemento sendo revisado (requisito ou
caso de uso). muito comum durante uma anlise de um caso real,
encontrarmos a necessidade de criao de itens para agrupamento,
como foi o caso da reviso.
Figura 35: Modelagem dos aspectos relacionados a um reviso.
Observe na Figura 35 o resultado da modelagem dos aspectos

ligado uma reviso. O projeto contm revises, que possuem
diversos itens de reviso. Esses itens so os responsveis pelo
agrupamento que indica qual o critrio utilizado, o que est sendo
revisado (requisito ou caso de uso) e qual o resultado dessa
avaliao de item em especfico, dado pelos atributos avaliao e
observaes.
Ainda existem dois casos de uso na ER: Gerao da
Especificao e Relatrio de Acompanhamento. Porm, nenhum dos
91
dois acrescenta dados novos. Com isso ento, finalizamos a

identificao das classes de entidade. O resultado final dessa
Anlise mostrada na Figura 36.
Figura 36: Modelagem final dos conceitos existentes na ER do ReqG.
No entanto, preciso destacar que a Identificao das Classes

ainda no foi concluda. Ainda devemos identificar todas as demais
classes do projeto. Isso inclui as classes relacionadas s telas e
relatrios, denominadas classes de fronteira, alm das classes que
devem conter as regras de negcio, denominadas classes de
controle. A identificao dessas classes permite a criao das
realizaes dos casos de uso. No entanto, a realizao algo que
no prescrito pelos mtodos geis e ser apenas demonstrado
neste trabalho, sem tanta profundidade.
92
Figura 37: Exemplo de classes de fronteira e controle.
A Figura 37 exibe um diagrama contendo duas classes de

fronteira e uma classe de controle. Esses classes foram criadas para
representar as telas identificadas para os casos de uso Cadastro de
Projetos e Controle de Projetos, alm de uma classe para modelar
as regras de negcio relacionadas a projeto, denominada Regras de
Projeto. Essas classes foram estereotipadas, com os esteretipos
<<boundary>> e <<control>>. Isso possibilitou essa apresentao
utilizando a forma icnica, onde as classes se apresentam com
imagens no tradicionais.
Os esteretipos do mais poder UML, permitindo classificar
elementos com alguma coisa em comum. Um exemplo para facilitar
o entendimento seria, por exemplo, modelar hospital. Poderamos ter
smbolos especficos para representar mdicos e pacientes. Com
isso, estaramos estereotipando um elemento. Assim, todos os
mdicos
teriam
mesmo
smbolo,
indicando
algumas
propriedades e comportamento associado. Esse smbolo poderia

estar associado e uma imagem, destacando cada elemento em um
diagrama.
A Figura 37 nos demonstra que as classes Tela de Cadastro
de Projetos e Tela de Controle de Projetos representam classes de
apresentao (uma vez que esto estereotipadas como fronteira) e
possuem uma associao com a classe Regras de Projeto. Essa
93
classe contm as regras de negcio relacionado a projetos, uma vez

que ela est estereotipada como controle. Normalmente, ao
identificarmos uma classe j definimos seu esteretipo, embora isso
seja uma atividade diretamente relacionada organizao das
classes, apresentada a seguir.
4.1.2.
Organizao das Classes
Uma vez identificadas todas as classes de entidade, devemos

organiz-las, de forma a facilitar o trabalho e entendimento do
projeto. A organizao est associada criao de pacotes com os
agrupamentos necessrios, alm da atribuio dos esteretipos
exigidos.
Devemos utilizar algum critrio para agrupamento das classes.
No entanto, no existe uma regras especfica para isso. Geralmente
o bom senso o melhor dos guias. Como exemplo, observe o
agrupamento sugerido para o nosso exemplo, apresentado na Figura
38. Dividimos o projeto em quatro pacotes:
Administrao: para conter os itens relacionados

administrao e uso do sistema, composto pelas classes
Alterao (registro de histrico de alterao) e Usurios
(representao dos usurios do sistema).
Projeto: contendo a representao de um projeto e dos

seus membros.
Requisitos: contendo os elementos ligados requisitos,

como os casos de uso, prottipos, atores, fluxos e fluxos
alternativos.
Reviso: contendo os itens diretamente ligados a uma

reviso, como os critrios, itens de reviso e a prpria
reviso.
Conforme comentado, o importante criar uma organizao no

projeto, que favorea seu entendimento. Se isso acontecer, o
resultado da execuo da atividade foi bom.
94
Figura 38: Organizao das classes para o ReqG.
4.1.3.
Realizao dos Casos de Uso
Uma realizao de caso de uso mostra como um caso de uso

ser implementado, a partir da colaborao dos objetos que os
implementam. Isso feito a partir da criao de diagramas de
interao (seqncia ou colaborao) detalhando o caso de uso. De
forma geral, uma realizao pode ser considerada como a descrio
do caso de uso, similar descrio textual, s que utilizando objetos
e operaes.
95
Figura 39: Realizao para o caso de uso Controle de Projeto.
A Figura 39 exibe a realizao para o caso de uso Controle de

Projetos. Podemos observar que na realizao esto todas as
classes relacionadas ao caso de uso: sua tela, regras de negcio e
as entidades associadas. No caso em especfico, existe apenas uma
entidade relacionada. Se esse caso de uso tivesse que criar
relacionamentos com diversos objetos de outras classes, elas
deveriam estar na realizao, alm de existir mensagens at esses
objetos.
Conforme j comentado, alguns processos prescrevem a
realizao de todos os seus casos de uso, outros apenas dos mais
importantes e, alguns, como os baseados em mtodos geis, no
prescrevem
qualquer
realizao.
No
entanto,
havendo
a
96
necessidade de se criar realizaes ser necessrio organiz-las.

Um exemplo de tal organizao pode ser exibido na Figura 40.
importante mantermos um padro para evitar dificuldades de
entendimento.
Figura 40: Organizao das realizaes de um caso de uso.
Uma vez identificadas todas as classes de entidade, devemos

organiz-las, de forma a facilitar o trabalho e entendimento do
projeto. A organizao est associada a criao de pacotes com os
agrupamentos necessrios, alm da atribuio dos esteretipos
necessrios.
4.1.4.
Reviso da Anlise
A reviso da anlise o momento de fazermos uma verificao

geral nos diagramas e classes identificadas. A reviso da Anlise
97
pode ser feita da mesma forma que a reviso dos Requisitos. Os

artefatos so exatamente os mesmos. At mesmo os critrios
podem ser iguais. A mudana est na forma de se avaliar o
atendimento aos critrios. Por exemplo, o critrio completude
deveria verificar se todos os atributos existentes nos prottipos esto
modelados nas entidades. Isso, por sinal, um dos principais itens
para a reviso da Anlise e que precisa ser executado com bastante
ateno.
No Anexo V deste trabalho temos a planilha utilizada para a
reviso do modelo de Anlise, contendo a descrio dos critrios
associados, bem como o resultado da prpria reviso executada.
1.15.
Exerccios
1. Qual o objetivo do fluxo de anlise?

2. Descreva brevemente as atividades do fluxo de anlise.
3. O que uma classe de entidade?
4. Como devemos proceder para identificar classes a partir
de um ER?
5. O que um esteretipo na UML?
6. Por que devemos organizar as classes de um modelo de
anlise?
7. O que uma realizao de caso de uso?
8. Qual o principal objetivo da reviso da Anlise?
9. Qual um dos principais pontos a se verificar durante
uma reviso da Anlise?
98
UNIDADE II
ANLISE DE PONTOS DE FUNO
5. Anlise de Pontos de Funo

A cada dia que passa, cresce a necessidade mundial por
sistemas de informao, que esto cada vez mais presentes em
nossas vidas, auxiliando as mais variadas tarefas. Essa abrangncia
dos sistemas, causa tambm um aumento na sua complexidade,
sendo sempre importante que eles sejam desenvolvidos o mais
rpido possvel, cumprindo sempre um cronograma pr-estabelecido
para tal.
Um problema frequente relacionado ao desenvolvimento de
software est relacionado ao estabelecimento de estimativas de
prazos e custos equivocadas, o que leva a dificuldade em
cumprimento do que foi estabelecido. Fora isso, provvel que haja
uma correria no final do projeto, possibilitando a perda de qualidade
para que seja possvel cumprir prazos irreais.
Para se estabelecer
estimativas de custo e
prazo para projetos de
software, necessrio
ter uma base histrica
de custo e prazo de
outros projetos!
Tais problemas so muito comuns. Mas uma pergunta que

pode ser feita : como podemos evitar tais problemas? Uma possvel
resposta para isso usar experincias passadas, com o apoio de
tcnicas associadas ao controle e gesto de projetos. Isso exige o
uso de mtricas que permitam associar um trabalho a uma medida
clara e objetiva de quanto foi gasto para faz-lo.
A Mensurao em software o processo de definir, coletar,
analisar e agir sobre medidas que possam melhorar no s a
qualidade dos produtos, como tambm o prprio processo de
desenvolvimento. fundamental que a mensurao gere dados
quantitativos que possam ser utilizados para auxiliar o processo de
tomada de decises.
99
Muitas coisas podem ser medidas durante o desenvolvimento

de software. So exemplos dessas possibilidades: o tamanho do
produto, complexidade, esforo necessrio para sua construo,
cronograma, etc. Mas uma importante pergunta que devemos fazer
: para que necessitamos medir o tamanho de um produto de
software? Vrias so as razes. Apenas medindo que podemos
estimar algo. Isso viabiliza a determinao de preo do produto,
alm de facilitar o planejamento do projeto.
As medidas de tamanho de produtos de software possuem
correlao
com
esforo
necessrio
para
sua
produo.
Conhecendo tais medidas podemos ser capazes de realizar

estimativas com muito mais chances de acertarmos, uma vez que
tendo medidas podemos encontrar a produtividade da equipe. Com
base nessa produtividade podemos fazer previses para outras
situaes.
A Produtividade uma medida importante para a realizao de
A produtividade uma
medida fundamental
para realizao de
estimativas. Ela indica a
capacidade de
produo por unidade
de tempo.
estimativas. Ela baseada na medida do produto do trabalho

dividido pelo esforo para produzi-lo. Um exemplo simples disso a
produtividade de um pintor. Imagine que ele consegue pintar 20m2
de parede por dia. Essa medida, 20m2/dia, pode ser utilizada para
nos guiar nas prximas estimativas. Se existir um servio para pintar
200m2 de paredes, poderamos estimar 10 dias teis de trabalho.
Da mesma forma, a produtividade relacionada a software pode
nos ajudar em estimativas. Para isso, fundamental que o esforo
dedicado para realizar um trabalho seja cuidadosamente medido, de
forma precisa. De nada adianta termos o registro do esforo se ele
no for preciso. Isso certamente vai gerar estimativas equivocadas.
Imagine como exemplo a medida de produtividade do pintor
comentado acima. Se houvssemos errado na medida do esforo
empregado para pintar uma parede, imaginando, por exemplo, que
para pintar 20m2 o profissional gastou apenas 4h ao invs de 8h,
qualquer medida feita com base nessa produtividade (20m2/4h)
estar associada a uma grande taxa de erro.
100
Dessa forma torna-se claro a necessidade por mensurao,

uma vez que ela base para encontrarmos a produtividade e a
produtividade nos permite realizar estimativas. No entanto, para a
rea de software temos um problema adicional: a mensurao na
rea de software no nada trivial! necessrio utilizar uma medida
que seja padronizada, uniforme para uma aplicao e inteligvel para
a populao. Existem algumas medidas possveis, como linhas de
cdigo, casos de uso e mdulos implantados. Mas vamos ver que
tais medidas no so as mais adequadas.
De forma geral, uma boa medida de tamanho deve possuir
algumas
caractersticas
fundamentais
para
garantir
sua
adequabilidade:
ela deve ser deduzida dos requisitos, ou seja, a partir da

especificao de requisitos associadas ao produto deve
ser possvel estimar o tamanho do produto. Um exemplo
disso a medida de tamanho de uma casa, em que
normalmente
utilizado
tamanho
em
metros
quadrados. A partir da especificao de produto (casa),

detalhando nmero de quartos, banheiros, salas,
possvel deduzir o tamanho da edificao. Se for
realizado um pr-projeto, incluindo uma planta baixa,
essa estimativa tende a ser muito melhorada, uma vez
que ela serve como um prottipo da construo a ser
realizada;
ser contvel a partir de um procedimento definido. A

medida deve permitir que a contagem do tamanho do
produto seja facilmente mensurvel quando o mesmo
encontra-se completo. Continuando no exemplo de uma
casa, podemos notar que, uma vez a casa construda
fcil medi-la em m2, permitindo assim uma fcil
comparao entre o que foi estimado e o que foi
realmente feito.
101
Existem diversas medidas de tamanho que podem ser

utilizadas para software. Dentre elas destacamos:
linhas de cdigo;
pontos de funo;
pontos de caso de uso;
pontos de objetos.
A medida em linhas de cdigo muito interessante por muitos

aspectos, dentre eles, podemos destacar que ela a mais simples e
barata de se utilizar. Alm disso, ela pode ser contada de forma
totalmente automtica, uma vez que possui as caractersticas
comentadas acima.
Aps
as
explicaes
acima,
detalhando
as
vantagens
associadas ao uso de linhas de cdigo como medida de tamanho

para software, podemos nos questionar: por que ela no seria a
medida ideal a utilizarmos? por que utilizar outra medida?
A
resposta
para
as
perguntas
anteriores
tambm,
relativamente simples: linhas de cdigo somente podem ser medidas

DEPOIS do produto concludo. Mas, no entanto, essa medida no
A medida em linhas de
cdigo muito boa:
simples, de baixa custo,
bem definida. Mas ela
s pode ser obtida
DEPOIS do produto
pronto! Isso
impossibilita seu uso
para estimar a
construo do produto.
adequada por que ela no pode ser obtida dos requisitos. Ou seja,
ela no pode nos ajudar em estimativas, pois ela adequada para
contar o tamanho de produtos construdos e no de produtos a
construir. Alm disso, a medida em linhas de cdigo no
independente de tecnologia: um produto desenvolvido em Java deve
ter tamanho diferente de um desenvolvido em Delphi, que deve ser
diferente de um desenvolvido em Ruby. Isso no uma
caracterstica boa para uma medida.
Por esses motivos, foram criados outras medidas apropriadas
para o desenvolvimento de software. Uma dessas medidas,
denominada pontos de funo bastante utilizada no mundo e
objeto de estudo deste captulo.
102
5.1
Introduo a Anlise de Pontos de Funo

A Anlise de Pontos de Funo (APF) mede a funcionalidade
entregue ao usurio. Uma caracterstica interessante da APF que

ela independente da forma de implementao, ou seja, se o
produto vai ser desenvolvimento em Java, C, Ruby, Delphi, isso no
influencia em nada a contagem realizada.
Essa caracterstica de independncia de tecnologia possibilita
algo muito interessante: a comparao entre empresas e linguagens.
APF independente de
tecnologia. Isso permite
comparar empresas e
tecnologias de forma
efetiva!
Existindo uma medida independente de tecnologia, possvel

analisar se a empresa X trabalha de forma mais rpida que a
empresa Y, caso ambas iniciem o desenvolvimento do produto. Da
mesma forma, podemos analisar se a linguagem A permite maior
produtividade que a linguagem B.
Pontos de funo foram inicialmente propostos por Allan
Albrecht em 1979. A formalizao das regras de contagem teve
incio em 1984, pela IBM, a partir da criao de manuais para guiar a
contagem. Em 1986 foi criado o International Function Points Users
Group
(IFPUG).
reconhecida
Essa
como
organizao
lder
na
tem
promoo
como
misso
encorajamento
ser
do
gerenciamento do desenvolvimento de software a partir do uso da

APF. Dentre outras atribuies, o IFPUG mantm o manual de
contagem de pontos de funo, que atualmente est em sua verso
4.3.1 e pode ser obtido na pgina oficial da organizao
(http://www.ifpug.org/).
A tcnica de Anlise de Pontos de Funo foi concebida com
dois objetivos principais:
Possibilitar a mensurao de funcionalidades que um

software
oferece
independente
da
aos
seus
usurios,
de
tecnologia
utilizada
para
forma
sua
implementao;
Criar uma forma de contagem que gere um custo

adicional pequeno, no sendo caro realizar a medio e
103
que permita que seu uso seja feito entre diferentes

projetos e organizaes.
Aps sua criao e uso por parte da comunidade, foi possvel
notar que a tcnica de APF possua no somente os benefcios
inicialmente propostos, mas permitia tambm:
Determinar o tamanho de uma aplicao j construda, a

partir da funcionalidade nela contida;
Determinar os benefcios de um pacote de aplicativos

para uma organizao, baseados em quantas funes
eles atendem dentro do contexto de necessidades
existentes, permitindo uma comparao quantitativa
sobre quem atendeu mais em termo de tamanho.
Alm disso, a APF permitiu que o controle de produtividade dos

elementos que fazem parte de uma equipe de desenvolvimento
fosse medido e acompanhado. Isso foi possvel devido ao fato de
existir um mtodo simples para se medir o tamanho de uma
funcionalidade,
aliada
ao
tempo
para
se
desenvolver
tal
funcionalidade. Isso gera a produtividade, que, conforme j foi dito,

a razo entre o tamanho de um produto de trabalho desenvolvido
pelo esforo necessrio para sua produo.
Fora a produtividade, foi possvel estabelecer um parmetro de
comparao com outros projetos, permitindo estimar outros recursos
necessrios para uma empreitada. Isso permite um melhor
planejamento, pois independe da tecnologia utilizada, pontos de
funo servem para normalizar os dados relativos a tamanho,
permitindo a comparao entre empresas, tudo isso de forma
independente do que usam para produzir seu trabalho.
De forma geral, as principais vantagens do uso de APF so:
Transparncia para o usurio final. Com o uso de APF, o

usurio consegue entender a medida de tamanho
relacionada ao produto que ele deseja. Isso tambm
permite o acompanhamento da evoluo do produto.
104
Isso tambm estimula o prprio usurio e o torna mais

ativo no desenvolvimento.
Apoio estimativa de tempo, recursos e custos. O uso

de APF permite estimar o tempo necessrio para
desenvolver algo, baseado em uma comparao da
produtividade de uma equipe em projetos passados. A
partir dessa base histrica possvel encontrar o tempo
gasto para desenvolver um ponto de funo, permitindo
assim estimar qualquer trabalho que possa ser contado
utilizando APF. importante notar que, mesmo se
tivermos um detalhamento do projeto, mesmo que ele
esteja em estgios iniciais de desenvolvimento,
possvel j iniciar as estimativas, pois a contagem pode
ser feita de forma preliminar. Essa outra caracterstica
muito interessante.
Facilitar contratos de terceirizao. Muitas vezes, uma

empresa terceirizada pode alegar ter trabalho por 100h
em parte de um software sem ter conseguido muita
evoluo. Por isso a contagem em horas no
considerada uma forma eficiente para se avaliar
contratos terceirizados. fundamental acompanhar tais
contratos pela medida de funcionalidade desenvolvida
em um perodo de tempo. Por conta disso, APF a
tcnica sugerida para acompanhar praticamente todos
os
contratos
de
desenvolvimento
existentes
nas
instituies pblicas.
De forma geral, a APF uma tcnica muito utilizada no mundo
e bastante consolidada. Isso no significa que ela no tenha
defeitos. Possui vrios e possui contextos de uso bem definidos.
Iremos tratar disso mais a frente. Por hora, vamos detalhar um
pouco melhor como ela funciona.
5.2
O Processo de Contagem
105
Muito j falamos sobre APF. Mas como ela funciona

exatamente? Nesta seo trataremos disso. Uma representao dos
principais elementos relacionados contagem de pontos de funo
A contagem de PF
baseada em 5
elementos: dados
mantidos pela
aplicao, dados
mantidos por outra
aplicao e usados pela
aplicao sendo
contada, funes que
mudam dados, funes
que consultam dados e
realizam
processamento nesses
dados e funes que
apenas consultam
dados.
exibido na Figura 41. Para a contagem temos que levar em

considerao cinco elementos:
1. Arquivo Lgico Interno (ALI), que representam os dados
mantidos pela aplicao.
2. Arquivo de Interface Externa (AIE), que representam dados
utilizados pela aplicao, mas mantidos por outras aplicaes.
3. Entrada Externa (EE), que representam as entradas de dados
que causam mudanas nos ALIs.
4. Sada Externa (SE) que causam a exibio de dados
relacionados aplicao, normalmente exigindo algum tipo de
processamento.
5. Consulta Externa (CE) que causam a simples exibio de
dados relacionados aplicao.
Figura 41: Representao dos principais elementos associados APF.
A contagem de pontos de funo envolve um procedimento

simples, baseado em poucos passos:
1. Determinar o tipo de contagem;
2. Identificar o escopo de contagem e a fronteira da
aplicao;
3. Contar funes de dados;
4. Contar funes de transao;
5. Determinar o fator de ajuste;
6. Calcular o total de pontos de funo ajustados.
106
Cada um desses passos sero detalhados nas prximas

sees. Por enquanto, iremos detalhar mais alguns aspectos
relacionados contagem.
De forma geral, existem trs tipos de contagem de PF:
Projeto de desenvolvimento. Nesse caso medido o

tamanho
das
funes
oferecidas
aos
usurios,
decorrentes do desenvolvimento de um software, que

ser criado no projeto, ou seja, ele no existe ainda.
Projeto de evoluo. feita a medida das modificaes

de
funcionalidades
associadas
uma
aplicao
existente, ou seja, a contagem das mudanas em um

software que j foi desenvolvido mas precisa ser
alterado.
Aplicao. Est associado medida das funcionalidades

existentes em uma aplicao. Essa medida inicializada
quando a contagem do projeto de desenvolvimento
concluda. Depois, cada vez que um projeto de evoluo
realizado, a contagem da aplicao deve ser
atualizada, incorporando a medida das mudanas
efetivadas.
Para que uma contagem possa ser realizada necessrio

definir o objetivo da contagem, deixando claro para que ser
realizado o trabalho de mensurao. Existem diferentes objetivos
possveis. necessrio tambm estabelecer o escopo da contagem,
determinando exatamente o que deve ser considerado. Alm disso,
necessrio estabelecer o limite existente entre o sistema e o
mundo exterior, uma vez que isso ajuda a guiar a contagem.
Podem existir diferentes objetivos para uma contagem. Um
possvel objetivo fornecer insumos para a estimativa do esforo de
desenvolvimento. Podemos contar o tamanho de um software, a
partir da sua especificao, com o intuito de utiliza-lo para estimar o
tempo de desenvolvimento. Isso feito com base em outros projetos
107
conjunto de aplicaes instaladas. Nesse caso, realizamos uma

contagem apenas para termos o inventrio dos sistemas existentes.
Um outro objetivo comparar o tamanho das funcionalidades
oferecidas por produtos concorrentes. Imagine que estamos
querendo selecionar o produto que mais atenda a uma certa
especificao. Poderamos contar o tamanho de funcionalidade
atendida por um e pelo outro, facilitando assim saber quem mais
atende.
Alm do objetivo, necessrio definir o escopo da contagem.
Isso significa que devemos definir um (sub)conjunto do software a
ser medido, utilizando como base o objetivo definido. necessrio
determinar exatamente o que deve ser includo na contagem. Em
alguns casos isso pode incluir mais de uma aplicao.
Em projetos de evoluo, o escopo da contagem pode incluir
todas as funes adicionadas, alteradas ou excludas. Em projetos
de desenvolvimento isso inclui todas as funes construdas ou
customizadas
pelo
projeto.
Em
aplicaes
inclui
toda
funcionalidade ou apenas a frao que tem valor para o usurio,

como por exemplo no caso de comparao entre ferramentas que
mais atendem certas funcionalidades.
Para que a contagem acontea, tambm importante definir a
fronteira da aplicao. Isso significa que devemos estabelecer uma
diviso conceitual entre a aplicao e mundo externo, uma vez que
temos que saber exatamente o que est dentro e o que est fora da
aplicao, pois isso tem influncia direta na contagem. Os dados
mantidos pela aplicao possuem contagem diferenciada de dados
apenas consultados, mantidos externamente. fundamental saber
quais so as funes que operam utilizando dados que cruzam a
fronteira da aplicao a partir de transaes.
A fronteira da aplicao deve ser definida com base na viso
do usurio. Ele deve ser independente do escopo da contagem. Ela
deve ser delimitada em reas funcionais, como vistas pelo usurio e
no baseada em consideraes tcnicas. A fronteira dada por
108
aquilo que o usurio percebe. Assim, analisando a aplicao pela

viso do usurio conseguimos dizer o que faz parte e o que no faz
parte da aplicao.
Figura 42: Aes para clculo em PF.
A Figura 42 exibe as aes relacionadas a contagem em Pontos

de Funo. Inicialmente, necessrio identificar todas as funes
existentes na aplicao. Em seguida, necessrio contar os
elementos. Podem existir diversos elementos associados a uma
funo, sendo necessrio cont-los adequadamente. Aps essa
contagem ser possvel estabelecer os pesos relacionados a cada
parte a ser considerada. A partir desses pesos possvel identificar
o tamanho em PF.
A identificao de funes o momento em que devemos listar
todas as funes existentes na aplicao. Isso deve ser feito
levando-se em considerao o escopo da contagem, uma vez que
ele determina o que deve ser includo. Cada funo dever contribuir
para parte do tamanho total da aplicao. Basicamente, existem
duas categorias de funes:
Funes de dados
Funes de transao
109
As funes de dados representam a funcionalidade oferecida

ao usurio para cumprir requisitos de dados, ou seja, elas so a
representao de todos os dados existentes na aplicao. Elas
podem ser categorizadas em dois tipos:
A diferena de um ALI
para um AIE
simplesmente o fato
que um ALI mantido
pela aplicao sendo
contada e o AIE no!
Arquivo Lgico Interno (ALI);
Arquivo de Interface Externa (AIE).
importante ressaltar que o termo arquivo refere-se a grupos

de dados logicamente correlatos, independente de sua forma de
implementao. Assim, um ALI pode representar um dado que foi
implementado sob a forma de uma tabela em um banco de dados.
No caso de um sistema de biblioteca, poderamos ter como funes
de dados:
Usurio da biblioteca;
Ttulo;
Exemplar;
Emprstimo;
Reserva.
Os AIEs so similares aos ALIs, com uma nica diferena:

eles so mantidos por outra aplicao e no pela aplicao sendo
considerada na contagem. Ou seja, os AIEs so ALIs em outras
aplicaes. Por exemplo, imagine que em um sistema de biblioteca,
no tenhamos os dados de endereo (logradouro, bairro, cidade,
estado) de um usurio. Ao invs disso, temos apenas o CEP e o
nmero. Assim, os dados de endereo sero considerados como um
AIE, pois no sero mantidos pela aplicao.
As funes de transao representam a funcionalidade
oferecida ao usurio para processar os dados da aplicao. Elas
podem ser de trs tipos:
Entrada Externa (EE);
Sada Externa (SE);
Consulta Externa (CE).

110
Conforme j comentado, uma EE representa alguma funo

que causa algum tipo de mudana em dados mantidos pela
aplicao. So exemplo de EE em um sistema de biblioteca o
emprstimo de livro, reserva de exemplar, incluso de novo usurio.
Cada uma dessas funes deve causar uma alterao em um dado
mantido em algum ALI da aplicao.
A diferena de uma SE
para uma CE que
existe um
processamento
associado a uma SE.
Uma SE representa a gerao de dados, normalmente na

forma de um relatrio, que envolva algum tipo de processamento
associado. So exemplos desse tipo de funo o quantitativo de
emprstimos por perodo e livros com maior quantidade de reserva.
Uma CE representa algo parecido com uma SE, porm, no
envolve nenhum tipo de processamento complexo para sua gerao.
So exemplos de tais funes a listagem de livros emprestados e
usurios ativos.
Uma vez tendo identificado todas as funes, precisamos
contar os elementos presentes. Para o caso de funes de dados
necessrio contarmos os tipos de registros e os campos de dados
envolvidos. Nas prximas sees iremos fazer isso para o exemplo
da apostila. Para cada funo de transao necessrio contar os
arquivos referenciados e os campos de dados.
A partir dessa contagem podemos classificar cada funo
quanto complexidade, que pode ser Baixa, Mdia ou Alta. Cada
tipo de funo possui um peso, de acordo com sua complexidade. O
peso corresponde quantidade de PF no ajustados que a funo
agrega aplicao. Somando-se os pesos de todas as funes,
podemos obter o total de PF no ajustados.
A Tabela 7 exibe os pesos associados s funes. Nela temos a
classificao por cada tipo de funo e por complexidade. Uma vez
que saibamos quais so as funes existentes e sua complexidade,
basta obter o seu peso, que j representa o tamanho em PF.
111
Tabela 7: Pesos associados s funes na contagem de PF.
5.2.1 Contagem de Funes de Dados

A contagem de um ALI
deve ser independente
de modelagem e
baseada na viso do
usurio.
As funes de dados so tipicamente as primeiras funes

contadas em uma aplicao. Conforme j mencionado, so divididas
em ALI e AIE, correspondendo a grupos de dados que podem ser
atualizados e recuperados pela aplicao.
importante ressaltar que os agrupamentos utilizados para a
contagem no esto associados sua implementao no sistema
desenvolvido. Eles devem estar associados ao significado lgico
reconhecvel pelo usurio.
Os ALIs so grupos de dados ou informaes de controle,
identificveis pelo usurio e mantidos dentro da fronteira da
aplicao. Seu objetivo principal armazenar dados, mantidos por
meio de um ou mais processos elementares da aplicao que est
sendo contada.
Para se identificar ALIs necessrio procurar por grupos de
dados ou informaes de controle correlatos. Um ALI deve
necessariamente apresentar uma unidade lgica reconhecvel pelo
usurio e deve ser mantido por meio de um processo elementar da
aplicao.
112
importante ressaltar que no devemos considerar os

arquivos lgicos que o usurio no tenha acesso, tais como arquivos
internos do sistema (temporrios ou de trabalho).
Para se atribuir complexidade a um ALI necessrio identificar
Para a contagem de um
ALI necessrio
identificar o nmero de
agrupamentos
existentes (TER) e
nmero de campos
(TED).
os Tipos de Elementos de Registro (TERs) e os Tipos de Elementos

de Dados (TEDs). Um TER um subgrupo de dados dentro de um
ALI/AIE reconhecvel pelo usurio. Essa definio normalmente traz
muitas dvidas aos contadores, uma vez que essa definio
imprecisa. Mas de modo geral, uma ALI/AIE possui apenas um TER.
O outro elemento associado contagem de ALI/AIE so os
TEDs. Eles representam um campo nico, no repetitivo e
reconhecvel pelo usurio, mantido ou consultado no arquivo durante
a execuo de uma funcionalidade. No entanto, fundamental
ressaltar que devemos considerar apenas os TEDs que so
efetivamente usados pela aplicao. Assim, se um ALI possui 20
TEDs mas so utilizados apenas 10 na aplicao, temos que
considerar apenas os 10 campos. Alm desses campos,
necessrio considerar os dados necessrios para estabelecer
relacionamentos entre os ALI/AIE.
Tabela 8: Tabelam para classificao de ALI/AIE.
A Tabela 8 exibe a tabela com os parmetros para classificao

de um ALI/AIE.
Os AIEs so, de forma similar aos ALIs, grupo de dados ou
informaes de controle, identificveis pelo usurio e referenciados
113
pela aplicao. No entanto, eles so mantidos na fronteira de outra

aplicao. Logicamente, por conta disso, tambm devero ser
contados de forma diferente.
5.2.2 Contagem de Funes de Transao
As funes de transao correspondem funcionalidade

oferecida ao usurio com o intuito de permitir o processamento dos
dados contidos na aplicao. Isso inclui a entrada de dados,
consultas a dados pr-armazenados, alm da gerao de dados
derivados.
Conforme j comentado, existem, basicamente, trs tipos de
funes de transao: Entrada Externa (EE), Sada Externa (SE) e
Consulta Externa (CE).
Entrada Externa
Uma Entrada Externa um processo elementar da aplicao
que processa dados ou informaes de controle que entram na
fronteira de aplicao, ou seja, tem como principal objetivo manter
um ou mais ALIs. Isso normalmente causa uma alterao no
comportamento da aplicao.
O termo processo elementar utilizado para denotar a menor
unidade de atividade que significativa para o usurio. Essa funo
deve sempre levar a aplicao a um estado consistente, sob a tica
do negcio.
importante frisar que para algo ser classificado como uma
Entrada Externa necessrio receber dados de fora da aplicao.
Isso significa que pelo menos um ALI deve ser mantido.
Para se identificar uma EE, pelo menos uma das seguintes
condies deve ser satisfeita:
A lgica de processamento deve ser nica, diferente

das lgicas executadas por outras EEs;
114
O conjunto de elementos de dados identificado

diferente daqueles identificados para outras EEs;
O conjunto de ALIs ou AIEs referenciados diferente

daqueles referenciados por outras EEs.
necessrio contar
apenas os dados de
cruzam a fronteira da
aplicao e que fazem
sentido para o usurio.
Nada de contar
entradas dependents de
tecnologia e
imperceptveis na viso
do usurio.
So casos tpicos de uma EE a incluso, alterao ou excluso

de itens em um cadastro, obteno de mensagens e atualizao de
arquivos. No devemos considerar entradas necessrias apenas em
funo da tecnologia empregada e que no contribuem em nada
para o usurio, nem parte da entrada das consultas que serve
apenas para direcionar a recuperao de dados, como so os casos
de parmetros de pesquisa e nem telas de entrada para fins de
navegao, como os menus.
Em alguns casos, existem sistemas com mtodos diferentes
para executar a mesma funo. Eles no devem ser considerados
EEs. Da mesma forma, respostas s mensagens de confirmao
no cruzam a fronteira da aplicao.
Uma vez identificada uma EE, necessrio atribuir sua
complexidade. Isso est diretamente ligado identificao dos Tipos
de Arquivos Referenciados (TARs) e Tipos de Elementos de Dados
(TEDs). Os TARs representam o nmero de ALIs/AIEs mantidos ou
referenciados
pela
EE.
Os
TEDs
representam
os
campos
reconhecveis pelo usurio, que cruzam a fronteira da aplicao

durante a EE. Uma vez conhecidos o nmero de TARs e TEDs,
podemos chegar complexidade da funo.
A Tabela 9 exibe a tabela para atribuio de complexidade
para uma EE.
115
Tabela 9: Atribuio de complexidade para EEs.
Sada Externa
Uma Sada Externa (SE) um processo elementar da
aplicao que gera dados ou informao de controle para fora da
fronteira
da
aplicao.
Seu
objetivo
principal
apresentar
informaes ao usurio da aplicao, fornecendo dados que

auxiliem suas atividades.
Uma SE funciona a partir de uma lgica de processamento,
que envolve a gerao de dados derivados. Essa, por sinal, a
diferena de uma SE de uma CE. Uma SE envolve dados cuja
obteno requer algum tipo de processamento alm da recuperao
de campos de ALIs. Se isso no ocorrer, no se trata de uma SE.
Para a identificao de uma SE, necessrio procurar por
dados ou informaes de controle que devem sair da fronteira da
aplicao. Ressaltando mais uma vez, a lgica de processamento de
uma SE deve:
Conter pelo menos um clculo ou frmula matemtica;
Criar dados derivados;
Manter pelo menos um ALI; ou
Alterar o comportamento da aplicao.
Um outro detalhe importante que a lgica de processamento

utilizada na SE deve ser nica, diferente daquela executada por
outras SEs. Da mesma forma, o conjunto de elementos de dados
identificado deve ser diferente daqueles identificados para outras
116
SEs, assim como o conjunto de ALIs ou AIEs referenciados tambm

deve ser diferente daqueles referenciados por outras SEs. Se isso
no se configurar, provavelmente temos uma nica SE, que possui
parmetros diferentes e que no deveria ser contada como uma
outra SE. So exemplos tpicos de SEs:
Relatrios que consolidam dados atravs de clculos;
Telas de exibio de dados, que possuam dados

derivados;
Exibio de grficos com dados calculados;
Transferncia
de
dados,
arquivos
ou
mensagens
enviadas a outra aplicao, quando isso envolve

gerao de dados derivados ou atualizao de arquivos.
muito importante que no seja considerado como SEs
relatrios idnticos, com valores de dados diferentes. Uma mudana
em um parmetro, seja a introduo de um parmetro adicional, no
representa uma SE diferente. Da mesma forma, mensagens de erro
ou validao, que fazem parte de outro processo elementar, no
podem ser consideradas SEs. Assim, se no processo de incluso de
um elementos em uma aplicao, for necessrio fazer uma
validao, que gere um dado calculado, que ser apresentado e
demonstrado como uma mensagem ao usurio, isso no pode ser
considerado como uma SE.
Arquivos enviados a outras aplicaes, que no envolvam
dados derivados ou manuteno de arquivos, tambm no podem
ser consideradas SEs.
De forma similar a EE, a atribuio de complexidade a uma SE
se d a partir da identificao dos TARs e TEDs contidos na funo.
A regra tambm bem parecida:
Contar um TAR para cada ALI ou AIE lido durante o

processamento da SE, de acordo com os requisitos do
usurio;
117
Contar um TAR para cada ALI mantido pelo processo

elementar da SE, lembrando que cada ALI conta uma
vez, e no cada TER de um ALI;
Contar apenas uma vez os ALIs que so tanto lidos

quanto mantidos;
Contar um TED para cada campo no repetitivo

reconhecido pelo usurio, seja ele um campo que entra
na fronteira da aplicao ou que saia da fronteira da
aplicao. Se um mesmo TED entra e sai da fronteira da
aplicao, ele deve ser contado apenas uma vez.
Alguns detalhes especiais com relao contagem de TEDs

devem ser especificadas. No devemos contar:
Numerao de pginas;
Campo de data/hora de emisso de relatrio;
Literais (strings);
Ttulos fixos, nomes de campos, ttulos de colunas, etc;
Campos de ALIs mantidos ou consultados, que no

cruzem a fronteira da aplicao;
Campos mltiplos que na viso do usurio tenham um

significado nico, como por exemplo, mltiplas linhas de
um campo de endereo.
A Tabela 10 exibe a tabela para atribuio de complexidade

para uma SE.
Tabela 10: Atribuio de complexidade para SEs.
118
Consulta Externa
Uma Consulta Externa (CE) um processo elementar que
recupera dados ou informao de controle para fora da fronteira da
aplicao. Seu objetivo principal apresentar informaes ao
usurio, a partir da simples recuperao de dados de ALIs e/ou
AIEs.
Um CE no envolve clculos nem manuteno de ALIs. No
entanto, fundamental que existam dados ou informaes de
controle que saiam da fronteira da aplicao, recuperados de um ou
mais ALIs ou AIEs associados funo.
A lgica de processamento envolvida em uma CE no pode
conter clculos ou frmulas matemticas, nem a gerao de dados
derivados ou a manuteno de ALIs.
O CE tambm segue as mesmas restries associadas a uma
SE:
A lgica de processamento nica, diferente daquela

executada por outras CEs;
O conjunto de elementos de dados identificado

diferente daqueles identificados para outras CEs;
O conjunto de ALIs ou AIEs referenciados diferente

daqueles referenciados por outras CEs.
So exemplos tpicos de CEs relatrios que exibem dados

contidos em ALIs ou AIEs, sem clculos, telas de exibio de dados
que no possuam dados derivados e transferncia de dados,
arquivos ou mensagens enviadas a outra aplicao, sem que haja
dados derivados ou atualizao de ALIs.
Existem algumas caractersticas adicionais na contagem de
CEs. So tambm classificados como CEs:
Telas de log-on, para autenticao de usurios;
Ajuda on-line. Nesse caso, cada nvel de ajuda (tela,

campo) conta como uma CE distinta;
119
Consultas do tipo lista e combo, normalmente utilizadas

para facilitar o preenchimento de campos em outros
processos elementares.
Tambm de forma similar s SEs, no devem ser consideradas

CEs
relatrios
idnticos
com
valores
de
dados
diferentes,
mensagens de erro ou confirmao que fazem parte de outro

processo elementar e arquivos enviados a outras aplicaes que
envolvam dados derivados ou manuteno de arquivos.
A contagem tambm feita de forma similar a uma SE: devem
ser contado um TAR para cada ALI ou AIE lido durante o
processamento da CE. A contagem para TEDs similar ao de uma
SE. A Tabela 11 exibe a tabela para atribuio de complexidade para
uma CE.
Tabela 11: Atribuio de complexidade para CEs.
5.3
Contagem Estimativa de Pontos de Funo

Nesta seo explicaremos como proceder com uma contagem
estimativa de pontos de funo. importante ressaltar que uma

contagem estimativa no tem como objetivo ir a fundo nas regras e
detalhes da contagem. Ela serve como uma aproximao do valor
exato, para fins gerenciais, mas sem ser to rigorosa quanto ao
processo utilizado para obteno desse valor.
Nosso objetivo neste captulo no tornar o leitor um
especialista em APF, mas sim um conhecedor da tcnica. Para se
120
tornar um especialista ser necessrio muito mais investimento no

estudo do manual do IFPUG, bem como na prtica de contagem.
A Figura 43 exibe um resumo do roteiro para contagem
estimativa em um projeto de software. De posse do modelo de
dados para o projeto, normalmente contido nos diagramas UML que
descrevem a aplicao, possvel realizar uma contagem das
funes de dados existentes. Da mesma forma, com a descrio das
funes, normalmente contidas nas descries dos casos de uso
que compem o projeto, possvel contar as funes de transao.
Assim, a Especificao de Requisitos, juntamente com o Modelo de
Anlise
possuem
todas
as
informaes
necessrias
para
procedermos com uma contagem.
Figura 43: Roteiro para contagem estimativa em um projeto.
Agora vamos proceder com a contagem estimativa para o

nosso exemplo. importante ressaltar que em uma contagem,
normalmente surgem diversas dvidas. Precisamos anotar nossas
decises para que qualquer pessoa que tente realizar uma
contagem possa chegar aos mesmos resultados.
Neste trabalho no discutimos nem utilizaremos o fator de
ajuste, que uma medida que pode influenciar em 35% do tamanho
do sistema (para mais ou para menos), devido a algumas
121
caractersticas a serem avaliadas. Como o fator de ajuste est muito

defasado, por conta das caractersticas avaliadas, utilizaremos
apenas o valor bruto calculado. Em uma contagem tradicional esse
valor deveria ser multiplicado pelo fator de ajuste, para obtermos o
clculo em pontos de funo ajustados.
5.3.1 Contagem de funes de dados

Nossa contagem se inicia pelas funes de dados. Nosso
Esta seo apresenta
um exemplo de
contagem estimativa
para funes de dados.
Voc dever fazer o
mesmo para um
exemplo escolhido por
voc.
sistema exemplo, mesmo no sendo complexo, possui diversas

classes. Temos que proceder com a contagem desses elementos.
Utilizaremos como base o diagrama de classes exibido na Figura 36.
Iniciando pela classe Projeto, podemos perceber que ela um
ALI contendo 9 TEDs. Ela no possui nem um agrupamento interno,
por conta disso, devemos conta-la como um ALI com apenas um
TER. De acordo com a Tabela 8, Projeto uma ALI simples.
Continuando pela classe Membro, comeamos a ter que decidir
algumas questes para proceder com a contagem. Conforme pode
ser visto na Figura 36 a classe Membro herda de Usurio, que por
sua vez tem uma relao com Alterao. De um modo geral, um
usurio da aplicao no perceber essa diviso interna. Assim,
essas 3 classes juntas representam um nico ALI, que possui 2
TERs (e no 3, pois Usurio e Membro representam apenas um
agrupamento). Como todo membro deve ter as informaes de
usurio, isso representa um nico TER, ao invs de 2. A classe
alterao representa um outro TER. Com isso, temos que Membro
um ALI, que possui 2 TERs. Com relao a quantidade de campo,
possumos as seguintes quantidades:
Membro possui 4 campos;
Usurio possui 2 campos;
Alterao possui 1 campo.
Nossa contagem levar em considerao 10 campos para

Membro, contabilizando os 4 visveis diretamente, 2 de usurio e 2
campos adicionais, para permitir seus relacionamentos com projeto,
122
alm de 2 outros campos para a classe Reviso. Com isso teremos

7 TEDs. Com isso, a complexidade do ALI Membro pode ser
considerada baixa.
A
classe
Critrio
representa
um
ALI
simples,
sem
agrupamentos. Ela possui 3 campos, porm, devemos considerar

um campo adicional para o relacionamento com projeto. Assim, a
classe critrio tem complexidade baixa.
A classe Requisito um ALI que possui 2 TERs.
Consideramos isso por conta do relacionamento com Alterao.
Requisito possui 7 campos, mas consideraremos 8 por conta do
relacionamento com Projeto. Alterao possui um campo, mas
consideraremos 2 por conta do relacionamento com Requisito.
Assim, temos Requisito como sendo um ALI, com 2 TERs e 10
TEDs.
A classe Ator representa um ALI simples, contendo um
agrupamento para alteraes. Ela possui 2 campos, porm,
devemos considerar um campo adicional para o relacionamento com
Caso de uso. Alterao possui 1 campo, mas vamos considerar 2
por conta do agrupamento com Ator. Assim, a classe Ator uma
ALI, com 2 TERs e 5 TEDs. Ela tem complexidade baixa.
A classe Caso de uso provavelmente o item mais complexo
do exemplo. Ela possui diversos TERs:
Caso de uso, com 6 campos;
Alterao com 1 campo;
Prottipo com 2 campos;
Fluxos com 2 campos;
Fluxos alternativos com 1 campo.
No total, Caso de uso um ALI com 5 TERs e que possui 18

campos, pois foram contabilizados 8 campos para a classe caso de
uso (2 adicionais para o relacionamento com requisitos e atores), 2
campos para Alterao (1 campo adicional para o relacionamento
com Caso de uso), 3 campos para Prottipo (1 campo adicional para
123
o relacionamento com Caso de uso), 3 campos para Fluxo (1 campo

adicional para o relacionamento com Caso de uso) e 2 campos para
Fluxo Alternativa (1 campo adicional para o relacionamento com
Caso de uso). Assim, Caso de uso considerado um ALI com
complexidade baixa. Observe que embora bem mais complexo que
os demais ALIs analisados aqui, ele ainda possui a mesma
complexidade. Essa uma das crticas a contagem em PF.
Finalizando, a classe Reviso possui um agrupamento para a
avaliao, denominada Item de reviso. A classe Reviso possui 4
campos e Item de reviso possui 2 campos. No entanto, existem 3
relacionamentos adicionais, que Reviso responsvel (2 com
Membro e um com Projeto). Item de reviso possui 4 campos
adicionais, por conta dos relacionamentos com Reviso, Critrio,
Requisito e Caso de uso, contabilizando 4 campos adicionais.
Assim, Reviso um ALI com 2 TERs e 13 TEDs. Com isso,
Reviso tambm possui complexidade baixa.
A Tabela 12 resume a atribuio de complexidade para os
elementos presentes em nosso exemplo.
Tabela 12: Resumo das complexidades para os ALI do exemplo.
Cada ALI de complexidade baixa conta 7 PF, conforme descrito

na Tabela 7. Assim, temos 6 ALIs simples, que nos resulta em 6 x 7 =
42 pontos de funo de dados.
5.3.2 Contagem de funes de transao

Agora procederemos com a contagem das funes de
transao. Vale ressaltar que uma contagem detalhada deve levar
em considerao todas as regras, incluindo campos chaves,
comandos, ajuda, previso de relacionamentos, etc. Por conta disso,
124
faremos uma contagem bastante simplificada. Utilizaremos com

base para contagem de TEDs apenas os campos visveis ao
usurios, esquecendo-se de outros detalhes da contagem. Assim,
contaremos os ALIs/AIEs referenciados na funo (que sero os
TARs) e os TEDs envolvidos. Depois disso, faremos a atribuio de
complexidade, baseado nas tabelas de atribuio de complexidade
para EE, SE e CE (Tabela 9, Tabela 10, Tabela 11).
De forma similar
seo anterior, nesta
seo apresentamos
um exemplo de
contagem estimativa
para funes de
transao. Voc dever
fazer o mesmo para um
exemplo escolhido por
voc.
A contagem das funes de transao vai seguir a ordem dos

casos de uso na Especificao de Requisitos do ReqG. O primeiro
caso de uso o Cadastro de Projeto. A pesquisa por projeto faz com
que 2 campos cruzem a fronteira do sistema. Esses campos so de
dois ALIs diferentes: Projeto e Membro (gerente). Assim, a pesquisa
uma CE que possui 2 TARs e 2 TEDs referenciados. Por conta
disso, ela uma CE de complexidade baixa, conforme Tabela 11.
Ainda no Cadastro de Projeto possvel visualizar os dados,
exibindo os trs campos relacionados (sigla, descrio e gerente). A
visualizao tambm possui 2 TARs (Projeto e Gerente) e 3 TEDs.
Ela tambm uma CE de complexidade baixa. A alterao uma
EE que possui 2 TARs e 3 TEDs. Ela uma EE de complexidade
baixa. A excluso um caso diferenciado. Para a excluso,
normalmente apenas o identificador do elemento a ser excludo
cruza a fronteira da aplicao. Por conta disso, utilizaremos sempre
nas excluses o padro de termos 1 TAR e 1 TED. Isso funciona
dessa forma na contagem detalhada, porm, existem algumas
outras regras envolvidas.
O segundo caso de uso considerado Gesto de Gerentes.
Podemos realizar uma pesquisa, a visualizao dos dados de um
gerente, uma incluso, alterao e excluso. A pesquisa uma CE
que referencia dois ALIs: Gerente e Projeto. Alm disso, a pesquisa
exibe 4 campos. O restante da funes lida apenas com o ALI
Gerente. A visualizao, incluso e alterao lidam com 5 campos. A
excluso, conforme nossa padronizao, trata de apenas 1 campo.
125
O prximo caso de uso, Gesto de Membros, parecido com o

caso de uso Gesto de Gerentes. Podemos realizar uma pesquisa, a
visualizao dos dados de um membro, uma incluso, alterao e
excluso. Todas as funes referenciam 2 ALIs: Membro e Projeto.
O restante contar os campos referenciados e atribuir a
complexidade.
O caso de uso Controle de Projetos possui apenas 3 funes:
pesquisa, alterao e visualizao. A pesquisa um CE que
referencia 2 ALIs, Projeto e Membro. A visualizao e alterao
tambm referenciam 2 ALIs, mas exibem vrios campos. Observe
que alguns campos aparecem 2 vezes na tela, por isso no so
contados duas vezes. So exemplos disso o nome do projeto e
nome de um membro, que aparecem tanto nos dados do projeto,
como tambm nos dados dos Membros.
O caso de uso Gesto de Requisitos um CRUD (acrnimo
para Create, Read, Update, Delete) que referencia 3 ALIs: Projeto,
Requisito e Membro. No entanto, na pesquisa so referenciados
apenas 2 ALIs.
O caso de uso Gesto de Atores tambm um CRUD. Ele
possui 3 ALIs referenciados: Projeto, Caso de Uso e Ator. A
pesquisa referencia 4 campos, enquanto que as outras funes (com
exceo da excluso) referenciam 8 campos.
A Gesto de Casos de Uso possui muitos ALIs referenciados.
Na pesquisa so referenciados 3 ALIs: Caso de uso, Requisito e
Projeto. Nas demais funes, ainda temos referencia a Membro e
Ator. Observe que existem campos na tela utilizados para entrada de
dados mas que no cruzam a fronteira do sistema. Um exemplo
disso a tabela Dados do Fluxo Alternativo. Os campos so usados
para criar a lista de Fluxos Alternativos da tela. Essa lista que
enviada e que cruza a fronteira da aplicao. Assim, no devemos
contar os campos que no cruzam a fronteira da aplicao.
126
A Gesto de Critrios um caso de uso simples, que

referencia os ALIs Projeto e Critrio, alm de usar 4 campos.
O caso de uso Reviso possui 5 funes de transao:
pesquisa, visualizao, incluso, alterao e reabertura. A pesquisa
referencia 2 ALIs: Reviso e Projeto. As funes de visualizao,
incluso
alterao
referenciam
Projeto,
Reviso,
Critrio,
Requisitos, Caso de uso e Membro. A funo Reabertura apenas

altera um campo de Reviso, que indica de ela foi fechada ou no.
A Gerao da Especificao possui duas funes de
transao: pesquisa e gerao. A pesquisa referencia 2 ALIs:
Projeto e Membro. A gerao de especificao uma CE que
referencia todos os ALIs, com exceo de Reviso e Critrio. So 5
ALIs. Todos os campos desses ALIs so referenciados na funo.
O Relatrio de acompanhamento possui duas funes: uma CE
relacionada pesquisa e uma SE relacionada gerao do relatrio
de acompanhamento. A pesquisa referencia 2 ALIs: Projeto e
Membro. A SE referencia os ALIs Projeto, Membro, Requisito e Caso
de uso. Existem campos adicionais para informar o percentual de
concluso do requisito, do caso de uso e do projeto como um todo.
Esses so campos adicionais do relatrio e que precisam ser
contabilizados. Por isso a contagem referencia 14 campos: so 11
campos normais e 3 calculados.
A Tabela 13 exibe um resumo da contagem realizada,
detalhando as funes identificadas, nmero de TARs e TEDs
envolvidos, complexidade identificada e valor da funo em Pontos
de Funo.
importante frisar que devemos ter um cuidado especial com o
nmero de ALIs referenciados nas funes. Se existir pelo menos
um campo de um ALI envolvido na funo, ento esse ALI
referenciado. Alm disso, temos que contar o nmero de campos
associados funo. Conforme comentamos, utilizamos uma
contagem simplificada: contamos apenas os campos visveis. No
127
trataremos aqui de outros detalhes, como previso de comandos,

mensagens, relacionamentos entre elementos, etc. Isso simplifica o
processo de entendimento da APF. No entanto, frisamos que
existem muitos detalhes a serem considerados em uma contagem
detalhada.
128
Tabela 13: Resumo da contagem de funes de transao.
129
5.4
Planejamento e Gesto de Projetos com PF

Pontos de Funo podem ser utilizados para auxiliar a
estimativa de esforo necessrio ao desenvolvimento ou evoluo

de um produto. Isso pode ser feito a partir do clculo de
produtividade associada a um projeto e sua equipe.
O uso de APF permite o
acompanhamento da
produtividade, bem
como seu uso para a
realizao de
estimativas de custo e
esforo.
A produtividade uma medida que indica a capacidade de

produo. No caso de software, ela indica a capacidade de produzir
software por unidade de tempo. Uma funo para produtividade,
baseada em pontos de funo : Produtividade = PF / PM (ponto de
funo por pessoa-ms). Mas como calcular isso? Basta contar
quantos pontos de funo foram desenvolvidos por uma equipe em
um ms de trabalho. Se descobrirmos isso, podemos usar para fazer
estimativas.
De posse da produtividade de uma pessoa ou de uma equipe,
fcil obter uma estimativa de tempo para realizao do
desenvolvimento de um sistema. Por exemplo, se uma equipe tem
mdia de 200 PF/ms, um software de 600 PF poderia ser
construdo em 3 meses.
No entanto, existem diversos fatores que podem influenciar os
dados de produtividade. As diferenas entre linguagens utilizadas,
tecnologias e capacitao da equipe podem influenciar muito os
dados de produtividade. Imagine por exemplo programadores
COBOL e programadores que utilizem Delphi. Certamente a
produtividade de programadores Delphi deve ser bem superior a de
programadores COBOL, uma vez que Delphi possui elementos que
favorecem a produtividade em relao ao COBOL.
Na verdade, uma mesma equipe pode ter produtividade
bastante diferente de um projeto para outro. As pessoas podem
perder produtividade quando esto com problemas pessoais.
130
Um outro dado interessante que o tamanho dos projetos

tambm pode influenciar na produtividade. Projetos muito grandes
tendem a ter produtividade menor que projetos pequenos. A
explicao para isso simples: quando um projeto muito grande,
coisas simples podem crescer em dimenso, de formar a gerar um
problema. Um exemplo a comunicao: grandes equipes tem
muitos problemas para uma reunio, por exemplo. Pequenas
equipes resolvem isso facilmente.
Outros
fatores
que
podem
influenciar
no
clculo
de
produtividade so as coletas de medidas no padronizadas ou no

confiveis. Se isso ocorrer, as estimativas podem ser muito
imprecisas. Outro ponto importante que as medidas sejam feitas
utilizando produtos que tenham sua qualidade controlada. Uma
empresa pode gerar um sistema rapidamente e com isso ter uma
produtividade alta. Porm, se a qualidade dele no medida, podem
ser descobertos tantos erros que no justifiquem considerar o
produto concludo. Assim, fundamental o controle da qualidade
para que tenhamos uma medida de produtividade efetiva.
Normalmente a obteno de dados de produtividade segue
alguns passos. Inicialmente, preciso identificar projetos similares,
uma vez que a produtividade pode ser dependente do que se faz.
Outro ponto importante caracterizar o tamanho, linguagem,
aplicao, experincia da equipe e principalmente o processo usado
para guiar o trabalho. Com isso feito, pode-se obter a produtividade
para cada projeto.
Assim, pontos de funo uma boa mtrica para ajudar no
clculo de produtividade. No entanto, necessrio ter cuidado com
as medies, para no gerarmos dados inconfiveis.
5.5
Viso crtica da APF
131
A APF possui muitas vantagens e desvantagens associadas.

importante conhecer cada um desses pontos para que tenhamos
subsdios suficientes para decidir ou no pelo seu uso.
As vantagens do PF so:
A especificao de requisitos suficiente para o clculo.

Essa caracterstica muito interessante para o uso do
APF em projetos. Com a ER de um produto, podemos
estimar seu tamanho e assim estimar custo e esforo
para seu desenvolvimento.
Mtodo de grande difuso. APF utilizado no mundo

inteiro. Alm disso, mesmo estando defasado em alguns
pontos, ainda possui muitos usurios. Alm disso, em
projetos de terceirizao no Brasil ele indicado como
mtrica para clculo da produo e definio de
pagamentos.
Muitos dados publicados. Existem muitos dados de

empresas relativos ao uso de APF. Esses dados podem
at ser adquiridos por outras empresas. So bases
histricas
de
projetos
com
diversas
informaes
disponveis, que podem ser utilizadas por outras

organizaes para ajudar em suas estimativas.
Podem ser usados para comparaes. Com o uso do

APF podemos comparar a efetividade de tecnologias
diferentes
(Java
Delphi),
alm
de
permitir
comparao de empresas (A x B), analisando quem

produz mais em menos tempo.
Grupo internacional de usurios (IFPUG). O grupo de

usurios de APF grande, existente em boa parte do
mundo e bastante atuante. Questes enviadas ao grupo
so respondidas em pouco tempo.
Frum para troca de informao. Existem muitos fruns

para eliminao de dvidas associados, com respostas
efetivas e em tempos reduzidos.
132
No entanto, mesmo tendo essas vantagens, existem diversas

desvantagens associadas.
No tm nenhuma interpretao concreta. No faz parte

do nosso dia a dia o uso de APF. Assim, dizer que algo
tem 200PF ou 600PF no representa uma informao
associada. No a mesma coisa de dizer que uma casa
tem 1.000m2. No entanto, apenas difundindo ainda mais
o seu uso que essa medida pode ter uma
interpretao concreta.
Contagem no pode ser facilmente automatizada.

Existem muita interpretao associada contagem de
PF. Isso dificulta sua automao por completo, visto que
essas
interpretaes
so
difceis
de
serem
automatizadas por completa.
Existem
variantes
variaes
do
do
mtodo
mtodo.
que
Existem
utilizam
algumas
caractersticas
diferentes de contagem. Isso pode gerar diferenas em

trabalhos e contradies. Existem valores diferentes
para os pesos usados, alm de regras diferentes de
contagem.
So orientados para sistemas de informao. APF foi

criada para contagem de sistemas de informao, sendo
apropriadas para esses casos. No entanto, seu uso para
contagem de tamanho de jogos, aplicaes para
celulares,
adequadas.
recuperao
da
informao,
no
so
Assim, qualquer aplicao em contextos
diferentes requerem adaptaes para os produtos a

serem contados.
A contagem rigorosa difcil. Existem muitas regras

associadas. Por conta disso fizemos uma contagem
bastante simplificada. As regras so muito extensas e
difceis de serem seguidas em detalhes.
133
Requer
profissional
especializado.
Uma
contagem
detalhada exige um profissionais bastante especializado,

que caro e difcil de ser encontrado no mercado de
trabalho.
A APF ainda possui algumas limitaes que devem ser
consideradas em qualquer projeto de contagem:
No leva em conta a reutilizao. A APF no possui um

mecanismo de contabilizar o reuso de partes de um
projeto, visto que isso pode reduzir o esforo necessrio
A APF possui vrias

vantagens e
desvantagens
associadas. No entanto,
ela ainda uma forma
muito utilizada no
mundo.
para sua construo. No previsto o reuso de

componentes, de cdigo legado, de cdigo herdado de
verses anteriores.
difcil seu uso para contagem de alteraes de

requisitos.
APF inadequada para contar a complexidade de aes

de manuteno corretiva, pois difcil expressar as
diferenas de uma verso para outra.
De modo geral, APF possui vantagens e desvantagens, mas

mesmo assim um mtodo bastante utilizado. De qualquer forma,
independente de utilizar APF ou outro mtodo, importante termos
medidas para controlar nosso trabalho. Como foi dito pelo famoso
escritor Tom DeMarco: No se consegue controlar o que no se
consegue medir.
5.6
Exerccios
1. O que a mensurao em software?
2. O que pode ser medido em um software?
3. O que a produtividade?
4. Quais so as caractersticas de uma boa medida de
tamanho?
134
5. Por que linhas de cdigo no utilizada como medida

para controlar estimativas de desenvolvimento?
6. O que APF?
7. Quando surgiu a APF?
8. Quais foram os dois objetivos principais da APF?
9. Quais so os cinco elementos considerados em uma
contagem? Explique cada um deles.
10. Quais so os passos includos no procedimento de
contagem de PF?
11. Quais so os 3 tipos de contagem existente? Explique
cada uma.
12. O que o escopo da contagem em PF?
13. Quais so as duas categorias de funes a ser
consideradas em um clculo de PF?
14. O que um ALI? E um AIE? Qual a diferena entre eles?
15. Quais so os 3 tipos de funes de transao?
16. O que pode influenciar a contagem de um ALI? Explique
esses elementos.
17. Quais campos devem ser considerados em uma tela para
a contagem do tamanho de uma EE?
18. D exemplos de SE e CE ressaltando a diferena entre os
dois.
19. O que pode ser usado como insulo para a contagem das
funes de dados em um projeto? O que pode ser usado
para contar as funes de transao?
20. Realize uma contagem de funes de dados de um
projeto diferente do exemplo da apostila, explicando as
decises existentes e detalhando os nmeros associados,
de forma similar ao exemplo detalhado.
21. De forma similar a questo anterior, realize uma
contagem de funes de transao de um projeto
diferente do exemplo da apostila, explicando as decises
existentes e detalhando os nmeros associados, de forma
similar ao exemplo detalhado.
135
22. Como podemos utilizar APF para estimar um projeto?

23. Cite vantagens e desvantagens do uso de APF.
136
UNIDADE II
O FLUXO DE ANLISE
WEBLIOGRAFIA
Pgina da Universidade Aberta do Piau - UAPI

http://www.ufpi.br/uapi
Pgina da Universidade Aberta do Brasil- UAB
http://www.uab.gov.br
Stio de apoio ao livro de Wilson de Pdua
http://homepages.dcc.ufmg.br/~wilson/
Stio oficial da UML
http://www.uml.org/
International Function Points User Group
http://www.ifpug.org/
Brazilian Function Points User Group
http://www.bfpug.com.br/
137
UNIDADE II
O FLUXO DE ANLISE
REFERNCIAS BIBLIOGRFICAS
BERTRAND
MEYER,
Object-oriented
Software
Construction,
Prentice-Hall, 2a edio, 1997.

DAVID GARMUS, DAVID HERRON, Function Point Analysis:
Measurement Practices for Successful Software Projects,
Addison-Wesley, 2000.
KENDALL
SCOTT,
Processo
Unificado
Explicado,
Editora
Bookman, 2003.
J. RUMBAUGH, I. JACOBSON, G. BOOCH. The Unified Modeling
Language Reference Manual, Addison Wesley, 1999.
WILSON DE PDUA PAULA FILHO, Engenharia de Software:
Fundamentos, Mtodos e Padres, Editora LTC, 2 Edio, 2003.
138
UNIDADE III
EXEMPLOS DE ARTEFATOS
RESUMO
Nesta unidade apresentamos exemplos completos dos
artefatos utilizados para o levantamento de requisitos, registro de
uma reunio e para reviso de uma ER ou de um modelo de anlise.
Eles so exemplos completos para o sistema exemplo abordado no
trabalho.
139
SUMRIO DA UNIDADE
UNIDADE III............................................................................................. 139

EXEMPLOS DE ARTEFATOS ................................................................ 139
ANEXO I Exemplo de Especificao de Requisitos .............................. 141
ANEXO II Exemplo de Agenda de Oficina de Levantamento de
Requisitos ................................................................................................... 178
ANEXO III Exemplo de Ata de Oficina de Levantamento de Requisitos
.................................................................................................................... 180
Anexo IV - Reviso da Especificao de Requisitos ................................. 181
Anexo V - Reviso do Modelo de Anlise................................................. 185
140
ANEXO I Exemplo de Especificao de Requisitos
Fictcia Solues em Informtica
Especificao dos Requisitos do Software

ReqG 1.0
Autores: Equipe Fictcia
Teresina - PI
Dezembro de 2010
141
Aprovao
Aprovamos o documento de Especificao de Requisitos do projeto ReqG 1.0.
Responsvel
Gildsio Guedes Fernandes
Instituio
Data
UAPI
08/12/2010
Lus Cludio Demes da Mata UAPI

Souza
08/12/2010
Pedro de Alcntara dos S. Neto FICTCIA
08/12/2010
Assinatura
142
Verses revisadas anteriores
Responsvel
Verso
Pedro de Alcntara dos S. Neto
1.0
Data
07/12/2010
Descrio
Finalizao da verso inicial.
143
Especificao dos Requisitos do Software

Gerenciador de Requisitos 1.0
Sumrio

Introduo
Nome do produto
Escopo do produto
Limites do produto
Definies e siglas
Definio dos Requisitos
Requisitos Funcionais
Requisitos No-Funcionais
Diagrama de contexto
Casos de uso
Atores
Especificao dos Casos De Uso
Cadastro de Projeto
Gesto de Gerentes
Gesto de Membros
Controle de Projetos
Gesto de Requisitos
Gesto de Atores
Gesto de Casos de Uso
Gesto de Critrios
Reviso
Relatrio de Acompanhamento
145
145
145
145
145
146
146
146
148
148
148
149
151
151
153
155
157
158
161
164
168
170
175
175
144
Introduo
Nome do produto
ReqG: Sistema Gerenciador de Requisitos de Software.
Escopo do produto
Gerenciar os requisitos de um projeto de software, via Web, registrando todos os dados
associados sua definio, de forma a cobrir todas as atividades previstas em um fluxo
de requisitos.
Limites do produto
1. O ReqG no controlar a execuo de tarefas no projeto, apenas registrar os dados
relacionados aos requisitos.
2. O ReqG no gerar documentos editveis com a especificao de requisitos. Os dados ficam
registrados no sistema e s podem ser alterados por ele.
3. O ReqG no controlar qualquer aspecto do custo ou do cronograma de execuo.
4. O backup e a recuperao das bases de dados do sistema ficam a cargo da administrao de
dados e no sero providas pelo ReqG.
5. O ReqG no ter ajuda on-line.
Definies e siglas
Nr.
Sigla
Definio
JSF
Java Server Faces. Tecnologia para construo da camada de

apresentao de um sistema Web.
Hibernate
Framework para persistncia de dados em Java.
MySQL
Banco de dados livre bastante popular no mundo.
145
Definio dos Requisitos

Requisitos Funcionais
ID
Requisito
Descrio
RF1
Requisitos
O sistema deve permitir cadastrar e controlar

todos os aspectos relacionados aos requisitos de
um projeto, permitindo visualizar isso e
acompanhar sua evoluo, incluindo as pessoas
que trabalharam no projeto, os analistas e
gerente do projeto.
RF2
Casos de uso
O sistema deve possibilitar a especificao dos

casos de uso, registrando sua descrio, atores,
prottipos de tela associados, relacionando aos
requisitos que deram origem ao caso de uso.
RF3
Reviso
Deve ser possvel realizar uma reviso dos

requisitos e casos de uso, utilizando critrios
definidos pelos prprios gerentes de projetos, de
forma independente dos demais projetos.
RF4
Acompanhamento dos clientes
Deve ser possvel que os clientes possam

acompanhar a evoluo do projeto a qualquer
momento, consultando tudo o que foi feito.
RF5
Liberao de acesso por projeto
Deve ser possvel liberar o acesso ao sistema

por projeto, indicando o seu gerente. Assim,
para se ter acesso ao sistema, dever ser
adquirida uma licena para um projeto. A partir
disso o gerente ficar responsvel por definir
quem dever usar o sistema, seja para trabalhar
na especificao de requisitos, como um dos
Engenheiros de Requisitos, seja como cliente
consultando o resultado do trabalho realizado.
RF6
Gerao da documentao
Deve ser possvel gerar a especificao na

forma de um documento, contendo todos os
dados registrados do projeto.
5.7
Requisitos No-Funcionais
ID
Requisito
Descrio
146
RNF1 Ambiente
O sistema deve funcionar em ambiente Web,

sendo compatvel com os principais
navegadores do momento: Internet Explorer,
Firefox, Safari e Chroma.
RNF2 Linguagem
O sistema deve ser desenvolvido utilizando-se a

linguagem Java, com as tecnologias JSF e
Hibernate.
RNF3 Banco de dados
O sistema deve utilizar o banco de dados

MySQL.
RNF4 Desempenho
O sistema deve ser construdo para funcionar

com 100 usurios simultneos, com respostas de
at 5s quando utilizado em rede local.
RNF5 Segurana
O sistema deve restringir o acesso por meio de

senhas. Deve-se ter um controle no registro de
senha, de forma a impedir o uso de senhas
consideradas fceis.
RNF6 Usabilidade
Um usurio com conhecimento bsico em

informtica e conhecimento nos conceitos de
requisitos deveria ser capaz de operar o sistema
com um curso de 30 minutos.
147

Diagrama de contexto
Casos de uso
ID
UC1
Caso de uso
Requisito
associado
Descrio
Gesto de Requisitos
RF1
Cadastro de requisitos funcionais e no

148
funcionais associados ao projeto.

UC2
Gesto de Membros
RF1
Cadastro de todos os envolvidos no

projeto.
UC3
RF2
Definio dos casos de uso do projeto.
UC4
Gesto de Atores
RF2
Definio dos atores que iro interagir

no projeto.
UC5
Reviso
RF3
Reviso de um requisito ou de um caso

de uso, observando os critrios prestabelecidos no projeto para a reviso.
UC6
Gesto de Critrios de
Reviso
RF3
Cadastro de critrios a serem utilizados

em uma reviso.
UC7
Cadastro de Projeto
RF5
Cadastro de um projeto, com definio

do seu gerente, feito pelo administrador
do sistema.
UC8
Gesto de Gerentes
RF5
Cadastro de um gerente de projeto,

feito pelo administrador do sistema.
UC9
RF5
Controle do projeto, com detalhamento

de informaes sobre o mesmo, feito
pelo gerente do projeto.
UC10 Gerao da especificao
RF6, RF4
Gerao da especificao de requisitos,

utilizando um formato pr-definido,
contendo todos os dados registrados no
projeto.
UC11 Relatrio de
Acompanhamento
RF4, RF6
Emisso de um relatrio contendo uma

indicao do estado do projeto, a partir
do estado de cada caso de uso que o
compe.
Atores
N
Ator
5.
Cliente
6.
Administrador
7.
Gerente
Descrio
Clientes de um projeto, normalmente responsvel pelo
fornecimento de informaes para moldagem do produto.
Responsvel pelo controle do uso do sistema, liberando acesso
aos Gerentes a partir do cadastramento de um projeto.
Responsvel pelo controle de um projeto, definindo a equipe e
suas tarefas.
149
8.
Membro
9.
Engenheiro
Requisito
Pessoa que faz parte da equipe que trabalha no projeto.

de Tcnico com formao em Engenharia de Software, capaz de
identificar e descrever requisitos, utilizando as prescries de
Engenharia de Requisitos existentes e implementadas no
sistema.
150
Especificao dos Casos De Uso

Cadastro de Projeto
Prottipo de Tela de Cadastro de Projetos

Cadastro de Projetos
Pesquisa por Projetos
Nome
Gerente
Silio Silvestre Ferreira Freitas (Texto com at 100 caracteres)
<Pesquisar>
Sigla
Gerente
SystemG
Frigo
TecnoComp
<Novo> <Alterar> <Visualizar> <Excluir>
Dados do Projeto
Sigla*
ReqG 1.0 (texto com at 30 caracteres)
Descrio
Sistema de Gerenciamento de Requisitos do Projeto (texto com at 255
caracteres)
Gerente*
[Lista de Gerentes de Projeto cadastrados no sistema]
<Salvar>
Detalhamento do Caso de Uso

Precondies
No aplicvel.
Fluxo principal
1. O ReqG exibe a Tela de Cadastro de Projetos.
2. O Administrador informa os dados para pesquisa por projetos.
4. O ReqG recupera e exibe na lista Projetos Recuperados os projetos que atendem aos parmetros
de pesquisa informados, ordenados pela Sigla em ordem crescente.
Fluxo alternativo Incluso de novo projeto
O Administrador acionou o comando Novo.
Precondies 1.
Passos
1.
O Administrador preenche os Dados do Projeto.
2.
O Administrador aciona o comando Salvar.
3.
O ReqG verifica que no existe um projeto com sigla informada.
4.
O ReqG salva os dados do projeto.
5.
O ReqG envia um email ao gerente do projeto informando o

cadastramento do projeto.
151
Fluxo alternativo Alterao de um Projeto

Precondies 1. O Administrador selecionou um Projeto na lista de Projetos Recuperados.
2. O Administrador acionou o comando Alterar.
Passos
1. O ReqG recupera e exibe Dados do Projeto.

2. O Administrador altera os Dados do Projeto que desejar.
4. O ReqG salva os dados do projeto.
5. O ReqG verifica que no existe um projeto com sigla informada.
6. O ReqG salva os dados do projeto.
7. O ReqG envia um email ao gerente do projeto informando a alterao no
projeto.
Fluxo alternativo Visualizao de Dados de um Projeto

Precondies 1. O Administrador selecionou um projeto na lista de Projetos Recuperados.
2. O Administrador acionou o comando Visualizar.
Passos
1. O ReqG recupera e exibe os Dados do Projeto somente para leitura.
Fluxo alternativo Excluso de um Projeto

Precondies 1. O Administrador selecionou um projeto na lista de Projetos Recuperados.
2. O Administrador acionou o comando Excluir.
Passos
1. O ReqG verifica que no h dados associado ao projeto selecionado,

como requisitos, casos de uso, membros e revises.
2. O ReqG exclui o projeto selecionado.
3. O ReqG envia um email ao gerente do projeto informando a excluso do
projeto.
152
Gesto de Gerentes
Prottipo de Tela de Gesto de Gerentes

Gesto de Gerentes
Nome
Projeto
Pesquisa por Gerentes

Ferrare 1.0 (texto com at 30 caracteres)
<Pesquisar>
Gerentes recuperados
Nome
Login
Email

Joo Jos Almeida Cavalcante
Silio
jj
siliosffreitas@gmail.com
jjacavalcante@hotmail.com
Projeto
Ferrare 1.0, ReqG 1.0

Genesis 2.0

Dados do Gerente
siliosffreitas@gmail.com (email vlido)
(86) 3224-3678 (texto at 100 caracteres)
siliosffreitas (texto at 20 caracteres)
12345678 (texto at 20 caracteres)
<Salvar>
Nome*
Email*
Telefone
Login*
Senha*

Precondies
No aplicvel.
Fluxo principal
5. O ReqG exibe a Tela de Gesto de Gerentes.
6. O Administrador informa os dados para pesquisa por Gerentes.
8. O ReqG recupera e exibe na lista Gerentes recuperados os Gerentes que atendem aos parmetros
de pesquisa informados, ordenados pelo Nome em ordem crescente.
Fluxo alternativo Incluso de um Novo Gerente
Precondies 2. O Administrador acionou o comando Novo.
Passos
6. O Administrador preenche os Dados do Gerente.

8. O ReqG verifica que no existe um Gerente com email e login
informados.
Fluxo alternativo Alterao de um Gerente

153
Precondies 1. O Administrador selecionou um Gerente na lista de Gerentes recuperados.

2. O Administrador acionou o comando Alterar.
Passos
1. O ReqG recupera e exibe Dados do Gerente.

2. O Administrador altera os Dados do Gerente que desejar.
4. O ReqG verifica que no existe um Gerente com email e login informados.
Fluxo alternativo Visualizao de Dados de um Gerente

2. O Administrador acionou o comando Visualizar.
Passos
1. O ReqG recupera e exibe os Dados do Gerente somente para leitura.
a. Fluxo alternativo Excluso de um Gerente

2. O Administrador acionou o comando Excluir.
Passos
1. O ReqG verifica que no h nenhum projeto que tenha o Gerente

selecionado como Gerente do projeto.
2. O ReqG exclui o Gerente selecionado.
154
Gesto de Membros
Prottipo de Tela de Gesto de Membros

Gesto de Membros
Pesquisa por Membros
Nome
Pedro da Silva Castro (texto com at 50 caracteres)
Cargo
[Analista, Programador, Designer, Arquiteto de Software, Fornecedor de Requisitos]
<Pesquisar>
Membros do Projeto
Nome
Projeto
Telefone
Papel
Email
Pedro
Lucas
Adriana
Nome*
Email*
Telefone *
Papel*
Login*
Senha*
Projeto*
Pedro@email.com
lucassld@gmail.com
Adriana12@hotmail.com
Ferrare 1.0
Quantum 2.0
XMen 1.1
(12) 1212-1212
(23) 3443-3433
(34) 4554-5445
Analista
Design
Programador

Dados do Membro
Thiago Alves (texto com at 100 caracteres)
tt@gmail.com (email vlido)
(086) 9999-9999 (telefone vlido)
[Cliente; Engenheiro de Requisitos]
Thiago (texto com at 20 caracteres)
Senha (texto com at 20 caracteres)
[Lista de projetos pr-cadastrados no sistema e associados ao usurio corrente]
...
[Lista de projetos pr-cadastrados no sistema e associados ao usurio corrente]
<Salvar>

Precondies
No aplicvel.
Fluxo principal
1. O ReqG exibe a Tela de Gesto de Membros.
2. O Gerente informa os dados para pesquisa por Membros.
3. O Gerente aciona o comando Pesquisar.
4. O ReqG recupera e exibe na lista Membros Recuperados os Membros que atendem aos
parmetros de pesquisa informados, ordenados pelo Nome em ordem crescente.
Fluxo alternativo Incluso de um Novo Membro
Precondies 1. O Gerente acionou o comando Novo.
Passos
1. O Gerente preenche os Dados do Membro.

155
2. O Gerente aciona o comando Salvar.

3. O ReqG verifica que no existe um membro cadastrado com login e
email informados.
4. O ReqG salva os dados do Membro.
5. O ReqG envia um email ao Membro informando sobre sua incluso nos
projetos selecionados, detalhando seu cargo em cada projeto.
Fluxo alternativo Alterao de um Membro
Precondies 1. O Gerente selecionou um Membro na lista de Membros Recuperados.
2. O Gerente acionou o comando Alterar.
Passos
1.
2.
3.
4.
5.
6.
O ReqG recupera e exibe Dados do Membro.

O Gerente altera os Dados do Membro que desejar.
O Gerente aciona o comando Salvar.
O ReqG verifica que no existe um membro com login e email informados.
O ReqG salva os dados do Membro.
O ReqG envia um email para o membro informando as alteraes.
Fluxo alternativo Visualizao de Dados de um Membro

2. O Gerente acionou o comando Visualizar.
Passos
1. O ReqG recupera e exibe os Dados do Membro somente para leitura.
Fluxo alternativo Excluso de um Membro

2. O Gerente acionou o comando Excluir.
Passos
1. O ReqG verifica se que o Membro no trabalhou no projeto, fornecendo

informaes a respeito do levantamento de requisitos tais como registrando
requisitos, detalhando casos de uso, prottipos, realizando revises, etc..
2. O ReqG exclui o Membro selecionado.
156
Prottipo de Tela de Controle de Projetos

Controle do Projeto
Pesquisa por projetos
Projeto
Estocando (texto com at 30 caracteres)
<Pesquisar>
Sigla
Gerente
SystemG
Frigo
TecnoComp
<Alterar> <Visualizar>
Dados do Projeto
Projeto
SystemG
Gerente
Escopo*
Sistema de apoio e controle de requisitos (texto com at 2000
caracteres)
Diagrama de Contexto
SystemG_DiagramaContexto.jpg (Imagem)
Limites do produto
O sistema no ter monitoramento online (rea de texto com at
2000 caracteres)
Instituio responsvel
Ficttica Solues em Informtica (texto com at 100 caracteres)
pela execuo
Instituio cliente
Biriba Comrcio (texto com at 100 caracteres)
Data de incio*
12/05/2009 (data passada ou atual vlida no formato
dd/mm/aaaa)
Data de Trmino
12/05/2011 (data futura vlida no formato dd/mm/aaaa)
Membros do Projeto
Nome
Projeto
Celular
Cargo
Email
Pedro
Lucas
Adriana
Pedro@email.com
lucassld@gmail.com
Adriana12@hotmail.com
Ferrare 1.0
Quantum 2.0
XMen 1.1
(12) 1212-1212
(23) 3443-3433
(34) 4554-5445
Analista
Design
Programador
<Salvar>

Precondies
No aplicvel.
Fluxo principal
O ReqG exibe a Tela de Controle do Projeto.
O Gerente informa os dados para pesquisa por Projetos.
O Gerente aciona o comando Pesquisar.
157
O ReqG recupera e exibe na lista Projetos Recuperados os Projetos que atendem aos parmetros de
pesquisa informados e que tenham como Gerente o usurio corrente, ordenados pelo Nome em ordem
crescente.
O Gerente seleciona o projeto a controlar e aciona o comando Alterar.
O Gerente altera os dados de controle do projeto.
O Gerente aciona o comando Salvar.
O ReqG salva os dados do projeto.
O ReqG envia um email a todos os membros do projeto relatando as alteraes realizadas.
Gesto de Requisitos
Prottipo de Tela de Gesto de Requisitos
Projeto
Requisito
Gesto de Requisitos
Pesquisa por requisitos
Linguagem (texto com at 30 caracteres)
<Pesquisar>
158
Requisitos recuperados
Nome
Descrio
Linguagem Java Desenvolvido em Java
Gesto de Projetos Gesto de Projetos
Reviso
Prioridade
Alta
Mdia

Baixa
Identificador*
Nome*
Projeto
Ferrare 1.0
Quantum 2.0
XMen 1.0
Dados do Requisito
RF1 (formato RFn para funcionais ou RNFn para no funcionais,
onde n o prximo nmero natural no associado a um requisito)
Descrio*
Linguagem Java (texto at 100 caracteres)

O Sistema deve ser desenvolvido em Java para a Web (texto at 2000
caracteres)
Tipo*
Prioridade*
[Funcional; No Funcional]
[Alta; Mdia; Baixa]
Complexidade*
Situao*
[Alta; Mdia; Baixa]

[Identificado; Detalhado; Implementado; Homologado]
<Salvar>
Histrico de Alterao
Data
10/05/2010
15/05/2010
Responsvel
Joaquim Parente
Astulfo Alves
Papel
Analista
Analista
Email
joa@gmail.com
astoa@gmail.com
10/07/2010
Silio Silvestre
Gerente
silio@gmail.com

Precondies
O usurio corrente deve ser um Engenheiro de Requisitos ou o Gerente do Projeto.
Fluxo principal
O ReqG exibe a Tela de Gesto de Requisitos.
O Engenheiro de Requisitos informa os dados para pesquisa por Requisitos.
O Engenheiro de Requisitos aciona o comando Pesquisar.
O ReqG recupera e exibe na lista Requisitos Recuperados os requisitos que atendem aos parmetros
de pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo
Nome em ordem crescente.
Fluxo alternativo Incluso de Novo Requisito
159
Precondies 1. O Engenheiro de Requisitos acionou o comando Novo.

Passos
1. O Engenheiro de Requisitos preenche os Dados do Requisito.

2. O Engenheiro de Requisitos aciona o comando Salvar.
3. O ReqG gera o identificador do requisito sendo RF + n para requisitos
funcionais ou RNF + n para requisitos no funcionais, onde n o prximo
numero natural no associado a um requisito.
4. O ReqG verifica que no h requisito para o projeto com o nome e tipo
informado.
5. O ReqG verifica que a situao do requisito Identificado.
6. O ReqG salva os dados do Requisito.
7. O ReqG registra no histrico de alterao do requisito a data atual, o
usurio corrente como responsvel pela incluso.
Fluxo alternativo de Alterao do Requisito

Precondies 1. O Engenheiro de Requisitos selecionou um Requisito na lista de
Requisitos recuperados.
2. O Engenheiro de Requisitos acionou o comando Alterar.
Passos
1. O ReqG recupera e exibe Dados do Requisito.

2. O Engenheiro de Requisitos altera os Dados do Requisito que desejar.
4. O ReqG verifica que todos os casos de uso relacionados ao requisito esto
na mesma situao do requisito.
5. O ReqG salva os dados do Requisito.
6. O ReqG registra no histrico de alterao do requisito a data atual e o
usurio corrente como responsvel pela alterao.
Fluxo alternativo Visualizao de Dados de Requisito

Requisitos recuperadas.
2. O Engenheiro de Requisitos acionou o comando Visualizar.
Passos
1. O ReqG recupera e exibe os Dados do Requisito somente para leitura.
Fluxo alternativo Excluso de Requisito
160

Requisitos recuperados.
2. O Engenheiro de Requisitos acionou o comando Excluir.
Passos
1. O ReqG verifica que no existe nenhum caso de uso ou reviso associado

ao Requisito.
2. O ReqG exclui o requisito selecionado.
Gesto de Atores
Prottipo de Tela de Gesto de Atores
Projeto
Ator
Gesto de Atores
Pesquisa por Ator
Gerente (texto com at 30 caracteres)
<Pesquisar>
Atores recuperados
Nome
Caixeiro
Descrio
Caso de Uso
Projeto
Usurio que abre e fecha
UC6,UC8
Estocando
compra
Fiscal de
Fiscaliza entrada e sada
UC1
Estocando
ponto
de
Reviso
UC2
Ferrare 1.0
Dados do Ator
Nome*
Caixeiro (texto at 50 caracteres, nico)
Descrio*
Responsvel pela venda de mercadorias (texto at 100 caracteres)
Caso de uso associado [Lista de caso de uso cadastrado no projeto]
...
[Lista de caso de uso cadastrado no projeto]
<Salvar>
Histrico de Alterao
Data
10/05/2010
Responsvel
Joaquim Parente
Papel
Analista
Email
joa@gmail.com
15/05/2010
10/07/2010
Astulfo Alves
Silio Silvestre
Analista
Gerente
astoa@gmail.com
silio@gmail.com

Precondies
161
Fluxo principal
O ReqG exibe a Tela de Gesto de Atores.
O Engenheiro de Requisitos informa os dados para pesquisa por Atores.
O ReqG recupera e exibe na lista Atores Recuperados os atores que atendem aos parmetros de
pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo Nome
em ordem crescente.
Fluxo alternativo Incluso de Novo Ator
Passos
1. O Engenheiro de Requisitos preenche os Dados do Ator.

3. O ReqG verifica que no existe um ator com mesmo nome para o projeto.
4. O ReqG salva os dados do Ator.
5. O ReqG registra no histrico de alterao do ator a data atual, o usurio
corrente como responsvel pela incluso.
Fluxo alternativo de Alterao do Ator

Precondies 1. O Engenheiro de Requisitos selecionou um Ator na lista de Atores
recuperados.
Passos
1. O ReqG recupera e exibe Dados do Ator.

2. O Engenheiro de Requisitos altera os Dados do Ator que desejar.
4. O ReqG verifica que no existe um ator com mesmo nome para o projeto.
5. O ReqG salva os dados do Ator.
6. O ReqG registra no histrico de alterao do ator a data atual, o usurio
corrente como responsvel pela alterao.
Fluxo alternativo Visualizao de Dados de Ator

recuperados.
Passos
1. O ReqG recupera e exibe os Dados do Ator somente para leitura.
Fluxo alternativo Excluso de Ator
162

recuperados.
Passos
1. O ReqG verifica que o ator no est associado a nenhum caso de uso.

2. O ReqG exclui o ator selecionado.
163
Prottipo de Tela de Gesto de Casos de Uso

Projeto
Caso de uso

Pesquisa por Casos de Uso
Estocando (texto at 30 caracteres)
Criao de Projetos (texto at 30 caracteres)
<Pesquisar>
Casos de Uso recuperados
Nome
Descrio
Requisitos
Projeto
Gesto de Projetos Criao de Projetos
RF01, RF03
Estocando
Gesto de Gerentes Controle de Gerentes por um projeto.
RF01
Estocando
Gesto de Membros Controle de membros de uma equipe
RF02
Ferrare 1.0
Dados do Caso de Uso
Identificador*
UC1 (formato UCn, onde n o prximo nmero natural no associado
a um caso de uso)
Nome*
Cadastrar Projeto (texto at 100 caracteres)
Descrio*
Cria a conta no sistema para o gerenciamento dos requisitos de um
projeto (texto at 2000 caracteres)
Ator
[Lista de atores pr-cadastrados para o projeto]
...
[Lista de atores pr-cadastrados para o projeto]
Requisitos
[Lista de requisitos pr-cadastrados para o projeto]
associados
...
[Lista de requisitos pr-cadastrados para o projeto]
Prioridade*
[Alta; Mdia; Baixa]
Complexidade*
Situao*
[Alta; Mdia; Baixa]

[Identificado; Detalhado; Implementado; Homologado]
Fluxo Principal
Precondio
Usurio logado no Sistema como Gerente (Texto com at 500
caracteres)
Passos*
O ReqG exibe a Tela de Gesto de Casos de Uso.
O ReqG recupera e exibe todos os casos de uso cadastrados.
(rea de texto com at 2000 caracteres)
Fluxos Alternativos
Nome
Pr-condies
Passos
Incluso de caso de O usurio acionou o
O ReqG faz isso.
uso
comando novo.
O ReqG faz aquilo.
ReqG salva tudo.
Excluso de caso de O usurio acionou o
O ReqG remove tudo.
uso
comando excluir.
Dados do Fluxo Alternativo
Nome*
Incluso de usurio (texto com at 100 caracteres, nico por projeto)
Precondio*
Usurio logado no Sistema como Gerente (texto com at 500
caracteres)
164
Passos*

<Adicionar fluxo> <Excluir fluxo>
Subfluxos
Nome
Passos
Atualizao de algo O ReqG faz isso.
O ReqG faz aquilo.
ReqG salva tudo.
Atualizao de algo O ReqG faz isso.
O ReqG faz aquilo.
ReqG salva tudo.
Dados do Subfluxo
Nome*
Incluso de usurio (texto com at 100 caracteres, nico por projeto)
Passos*
<Adicionar subfluxo> <Excluir Subfluxo>
Prottipos de interfaces
Nome
Arquivo
Tela de Incluso de caso de uso
Tela.jpg
Conexo com sistema de tarefas
Dados de Prottipos de interfaces
Nome*
Tela de incluso de usurio (texto com at 100 caracteres, nico por
projeto)
Arquivo
Tela.jpg (arquivo com imagem)
<Adicionar prottipo> <Excluir prottipo>
<Salvar>
Histrico de Alterao
Data
Responsvel
Papel
Email
10/05/2010
15/05/2010
10/07/2010
Joaquim Parente
Astulfo Alves
Silio Silvestre
Analista
Analista
Gerente
joa@gmail.com
astoa@gmail.com
silio@gmail.com

Precondies
Fluxo principal
O ReqG exibe a Tela de Gesto de Casos de uso.
O Engenheiro de Requisitos informa os dados para pesquisa por Casos de uso.
165
O ReqG recupera e exibe na lista Casos de uso Recuperados os casos de uso que atendem aos
parmetros de pesquisa informados e que tenham como Membro no projeto o usurio corrente,
ordenados pelo Nome em ordem crescente.
Fluxo alternativo Incluso de Novo Caso de Uso
Passos
1. O Engenheiro de Requisitos preenche os Dados do Caso de Uso.

2. Se desejar, o Engenheiro de Requisitos inclui fluxos alternativos,
subfluxos e prottipos de interfaces.
3. Se desejar, o Engenheiro de Requisitos exclui fluxos alternativos,
subfluxos e prottipos de interfaces.
5. O ReqG verifica que no existe um caso de uso com mesmo nome para o
projeto.
6. O ReqG salva os dados do caso de uso.
7. O ReqG registra no histrico de alterao do caso de uso a data atual e o
usurio corrente como responsvel pela incluso.
Fluxo alternativo de Alterao do Caso de Uso

Precondies 1. O Engenheiro de Requisitos selecionou um Caso de Uso na lista de
Casos de Uso recuperados.
Passos
1. O ReqG recupera e exibe Dados do Caso de Uso.

2. O Engenheiro de Requisitos altera os Dados do Caso de Uso.
3. Se desejar, o Engenheiro de Requisitos inclui fluxos alternativos e
prottipos de interfaces.
5. O ReqG verifica que no existe um caso de uso com mesmo nome para o
projeto.
6. O ReqG salva os dados do Caso de Uso.
7. O ReqG registra no histrico de alterao do caso de uso a data atual e o
usurio corrente como responsvel pela alterao.
Fluxo alternativo Visualizao de Caso de Uso

Precondies 1. O Engenheiro de Requisitos selecionou um Caso de Uso na lista de
Casos de Uso recuperados.
Passos
1. O ReqG recupera e exibe os Dados do Caso de Uso somente para leitura.
Fluxo alternativo Excluso de Caso de Uso

166
Precondies 1. O Engenheiro de Requisitos selecionou um Caso de Uso na lista de Caso

de Uso recuperado.
Passos
1. O ReqG solicita confirmao da excluso.

2. O ReqG exclui o caso de uso.
167
Gesto de Critrios
Prottipo de Tela de Critrios

Gesto de Critrios
Projeto
Critrio
Pesquisa por Critrios

Estocando (texto at 30 caracteres)
Ambiguidade (texto at 50 caracteres)
Tipo
[Requisito; Caso de uso]

<Pesquisar>
Critrios recuperados
Projeto
Nome
Descrio
Tipo
Ferrare 1.0
Ambiguidade
Apresenta mais de um sentido semntico
Requisito
Ferrare 1.0
Clareza
Apresenta uma interpretao direta e clara
Requisito
ReqG 1.0
Completude
O Caso de uso est completo
Caso de uso

Dados do Critrio
[Lista de Projetos cadastrados e que o usurio corrente Membro]
Ambigidade (texto at 50 caracteres)
Projeto
Nome*
Descrio*
Tipo*
Apresenta mais de um sentido (texto at 2000 caracteres)

[Requisito; Caso de Uso]
<Salvar>

Precondies
No aplicvel.
Fluxo principal
O ReqG exibe a Tela de Gesto de Critrios.
O Gerente informa os dados para pesquisa por Critrios.
O Gerente aciona o comando Pesquisar.
O ReqG recupera e exibe na lista Critrios Recuperados os critrios que atendem aos parmetros de
pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo Nome
em ordem crescente.
Fluxo alternativo Incluso de Novo Critrio
168
Precondies 1. O Gerente acionou o comando Novo.

Passos
1. O Gerente preenche os Dados do Critrio.

3. O ReqG verifica que no existe um critrio cadastrado com o nome
informado.
4. O ReqG salva os dados do Critrio.
Fluxo alternativo de Alterao de Critrio

Precondies 1. O Gerente selecionou um Critrio na lista de Critrios recuperados.
2. O Gerente acionou o comando Alterar.
Passos
1. O ReqG recupera e exibe Dados do Critrio.

2. O Gerente altera os Dados do Critrio que desejar.
5. O ReqG verifica que no existe um critrio cadastrado com o nome
informado.
4. O ReqG salva os dados do Critrio.
Fluxo alternativo Visualizao de Dados de Critrio

2. O Gerente acionou o comando Visualizar.
Passos
1. O ReqG recupera e exibe os Dados do Critrio somente para leitura.
Fluxo alternativo Excluso de Critrio

2. O Gerente acionou o comando Excluir.
Passos
1. O ReqG verifica que no existe nenhuma reviso cadastrada e que utilize

o critrio.
2. O ReqG exclui o Critrio selecionado.
169
Reviso
Prottipo de Tela de Reviso

Reviso
Pesquisar por Revises
Reviso
Reviso preliminar de levantamento (texto com at 30 caracteres ).
Projeto
SystemG (texto com at 30 caracteres )

<Pesquisar>
Revises recuperadas
Projeto
Identificador da Reviso
Data
SystemG 1.0
Reviso preliminar de levantamento de requisitos 31/10/2009
SystemG 1.0
Reviso final de detalhamento de requisitos
SystemG 2.0
Reviso preliminar de levantamento de requisitos 17/10/2010
SystemG 2.0
Reviso final de detalhamento de requisitos
ProjetoX 1.0
31/11/2009
14/11/2010
Reviso inicial de requisitos
12/12/2010
<Nova Reviso> <Alterar Reviso> <Visualizar Reviso> <Reabrir reviso>

Dados da Reviso
Projeto*
Identificador*
Descrio*
Data*
Participantes dos
desenvolvedores*
[Lista de Projetos que possuem o usurio corrente como membro]

12/12/2010 (data no formato dd/mm/aaaa)
Participantes dos
clientes

...
...
Situao*

[Aberta; Fechada]
Requisitos/Casos de uso Avaliados
Requisito/Caso de uso
Critrio
Atende?
Observaes
Banco de dados
Ambuiguidade
Sim
Clareza
No
No ficou claro o banco a ser

utilizado.
Preciso
No
No foi definido com preciso

a verso do banco a ser
utilizado.
Ambuiguidade
Sim
Gesto de membros
170
Reviso
Clareza
Sim
Preciso
Sim
Ambuiguidade
Sim
Clareza
No
No ficou claro se a reviso

apenas de requisitos ou se
pode ser de casos de uso
tambm.
Preciso
Sim
<Excluir Avaliao de Requisito/Caso de uso>

Avaliao de Critrios para Requisitos
Requisito a ser
avaliado
[Lista de requisitos cadastrados no projeto]
Critrio
Atende?
Observaes
Ambuiguidade
[sim; no]
(texto com at 100 caracteres)
Clareza
[sim; no]
Preciso
[sim; no]
<Adicionar Avaliao de Requisito>

Avaliao de Critrios para Casos de Uso
Caso de uso a
ser avaliado
[Lista de Casos de uso cadastrados no projeto]
Critrio
Atende?
Observaes
Ambuiguidade
[sim; no]
Clareza
[sim; no]
Preciso
[sim; no]
<Adicionar Avaliao de Caso de uso>

<Salvar>

Precondies
No aplicvel.
Fluxo principal
O ReqG exibe a Tela de Reviso.
O Engenheiro de Requisito informa os dados para pesquisa por Reviso.
O Engenheiro de Requisito aciona o comando Pesquisar.
O ReqG recupera e exibe na lista Revises Recuperados as revises que atendem aos parmetros de
pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo
Projeto e Identificador da reviso em ordem crescente.
171
Fluxo alternativo Incluso de Nova Reviso

Precondies 1. O Engenheiro de Requisito acionou o comando Nova Reviso.
Passos
1. O Gerente preenche os Dados do Reviso

2. Para cada Requisito a ser avaliado:
2.1. O ReqG executa o Subfluxo Avaliao de Requisito.
3. Para cada Caso de uso a ser avaliado:
3.1. O ReqG executa o Subfluxo Avaliao de Caso de uso.
4. Se desejar excluir alguma avaliao de requisito ou caso de uso:
4.1. O ReqG executa o Subfluxo
6. O ReqG verifica que no existe uma reviso cadastrada para o projeto com
o mesmo identificador.
7. O ReqG salva os dados da Reviso.
Subfluxo Avaliao de Requisito

1. O Engenheiro de Requisitos informa o Requisito a ser avaliado.
2. O ReqG recupera e exibe na lista de Avaliao de Critrios para Requisitos os critrios associados
a requisitos cadastrados no projeto.
3. O Engenheiro de Requisitos informa se o critrio foi atendido e, se desejar, preenche algum
informao adicional no campo observaes.
4. O Engenheiro de Requisitos aciona o comando Adicionar Avaliao de Requisito.
Subfluxo Avaliao de Caso de uso

1. O Engenheiro de Requisitos informa o Caso de uso a ser avaliado.
2. O ReqG recupera e exibe na lista de Avaliao de Critrios para Casos de uso os critrios
associados a casos de uso cadastrados no projeto.
3. O Engenheiro de Requisitos informa se o critrio foi atendido e, se desejar, preenche algum
informao adicional no campo observaes.
4. O Engenheiro de Requisitos aciona o comando Adicionar Avaliao de Caso de uso.
Subfluxo Excluso de Avaliao
1. O Engenheiro de Requisitos seleciona uma avaliao de Requisito ou Caso de uso na lista de
Requisitos/Casos de uso avaliados.
172
2. O Engenheiro de Requisitos aciona o comando Excluir Avaliao de Requisito/Caso de uso.

3. O ReqG remove a avaliao do requisito/caso de uso.
Fluxo alternativo Alterao de Reviso

Precondies 1. O Engenheiro de Requisito selecionou uma Reviso da Lista de Revises
recuperadas.
2. O Engenheiro de Requisito acionou o comando Alterar Reviso.
3. A Reviso no encontra-se no estado fechada.
Passos
1. O ReqG recupera e exibe cada avaliao de requisito e caso de uso

associada reviso na lista de Requisitos/Casos de uso avaliados.
2. O Gerente preenche os Dados do Reviso.
3. Para cada Requisito a ser avaliado:
3.1. O ReqG executa o Subfluxo Avaliao de Requisito.
4. Para cada Caso de uso a ser avaliado:
4.1. O ReqG executa o Subfluxo Avaliao de Caso de uso.
5. Se desejar excluir alguma avaliao de requisito ou caso de uso:
5.1. O ReqG executa o Subfluxo
7. O ReqG verifica que no existe uma reviso cadastrada para o projeto com
o mesmo identificador.
Fluxo alternativo Visualizao de Reviso

recuperadas.
2. O Engenheiro de Requisito acionou o comando Visualizar Reviso.
Passos
1. O ReqG recupera e exibe os Dados da Reviso.

2. O ReqG recupera e exibe cada avaliao de requisito e caso de uso
associada reviso na lista de Requisitos/Casos de uso avaliados.
Fluxo alternativo Reabertura de Reviso
173

recuperadas.
2. O Engenheiro de Requisito acionou o comando Reabrir Reviso.
3. A Reviso encontra-se no estado fechada.
Passos
1. O ReqG altera o status da reviso para Aberta.

174
Prottipo de Tela de Gerao da Especificao

Projeto
Gerente
<Pesquisar>
Projeto
Descrio
Gerente
SystemG
Frigo
TecnoComp
Manuteno de algo
<Gerar Especificao>

Precondies
No aplicvel.
Fluxo principal
O ReqG exibe a Tela de Gerao da Especificao.
pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo nome
do Projeto em ordem crescente.
O Membro aciona o comando Gerar Especificao.
O ReqG gera um documento no formato especificado no arquivo Modelo-ERSw.doc.
Prottipo da Tela de Relatrio de Acompanhamento

Projeto
Gerente
<Pesquisar>
Projeto
Descrio
Gerente
SystemG
Frigo
TecnoComp
Manuteno de algo
175
<Gerar Relatrio>
Prottipo do Relatrio de Acompanhamento

Projeto: SystemG
Gerente: Silio Silvestre
ID Requisito
Descrio
Tipo
Estado
--------------------------------------------------------------------------------------------------------------------------RF1 Linguagem Java O sistema deve ser feito em Java.
No-funcional Identificado (10%)
RF2 Acompanhamento O sistema deve permitir o acompa- Funcional
Identificado (20%)
nhamento do projeto pelos membros
ID
Caso de uso
Descrio
Estado
-----------------------------------------------------------------------------------------------------------------------UC4 Gerao da especificao Relatrio com a descrio do projeto
Detalhado (25%)
UC6 Relatrio de Acomp.
Relatrio com o estado do projeto
Detalhado (25%)
UC8 Gesto de Membros
Cadastro de membros
Identificado (10%)
RF3 Gesto de projeto
O sistema deve permitir o acompa- Funcional

Detalhado (50%)
nhamento do projeto pelos membros
ID
Caso de uso
Descrio
Estado
-----------------------------------------------------------------------------------------------------------------------UC2 Gesto de projetos
Cadastro de projetos
Detalhado
(25%)
UC3 Controle de projetos
Controle do projeto
Implementado (75%)
Percentual de concluso do projeto: 27%

Precondies
No aplicvel.
Fluxo principal
O ReqG exibe a Tela de Relatrio de Acompanhamento.
pesquisa informados e que tenham como Membro no projeto o usurio corrente, ordenados pelo nome
do Projeto em ordem crescente.
O Membro aciona o comando Gerar Relatrio.
Para cada requisito contido no projeto:
O ReqG imprime uma linha com o ID, nome, descrio, tipo e estado do requisito, calculado a
partir do estado ou a partir dos casos de uso associados.
Para cada caso de uso associado ao requisito:
O ReqG imprime uma linha com o ID, nome, descrio e estado do caso de uso.
O ReqG soma o percentual de concluso de cada caso de uso, de acordo com o seu estado, sendo
Identificado (10%), Detalhado (25%), Implementado (75%) e Homologado (100%).
Se o requisito possui casos de uso associados:
176
O ReqG calcula o percentual de concluso do requisito a partir da soma de todos os percentuais

dos casos de uso, dividido pela quantidade de casos de uso.
Seno:
O ReqG calcula o percentual de concluso do requisito a partir do estado do requisito.
O ReqG calcula o percentual de concluso do projeto a partir da soma de todos os percentuais dos
requisitos, divididos pela quantidade de requisitos existentes.
177
ANEXO II Exemplo de Agenda de Oficina de Levantamento de Requisitos
Agenda de Oficina de Levantamento de Requisitos

Projeto NomeDoProjeto
Data:
Horrio:
Local:
10/05/10
11:00 - 11:30h
Nome do Local
Participantes do Cliente:
Nome do Cliente 1
Nome do Cliente 2
Nome do Cliente 3
Participantes do Desenvolvedor:
Nome do Desenvolvedor 1
Pauta prevista:
N
1.
Assunto
Apresentao inicial
Descrio
Apresentao do calendrio (programao de datas e
pautas) das oficinas;
Apresentao do cronograma do levantamento inicial e
detalhamento dos requisitos.
2.
Sees iniciais da ERSw
Determinao do Escopo do produto

Descrio Geral do Produto
Levantamento das Funes
Pauta adicional:
N
1.
Assunto
Assunto 1
Descrio
Pauta adicional, para ser discutida caso haja tempo na
reunio, apenas uma forma de preveno.
Documentos necessrios para a realizao da oficina

Pelo Cliente:
Pelos Desenvolvedores:
1. Algum documento necessrio para se chegar em alguma

funo do sistema, como normas, leis, exemplos, etc.
1. Algum documento ou artefato que pode ajudar no
levantamento de requisitos.
Pendncias a serem checadas:
Descrio
1
1. Observaes:
A Pauta Adicional ser discutida apenas se houver disponibilidade de tempo.
Responsvel
-
A impossibilidade de participao de algum membro convocado dever ser comunicada, no mnimo,

com um dia de antecedncia da reunio.
Caso algum documento a ser apresentado ou pendncia a ser checada no tenha sido preparada(o)
178
em tempo, tal fato deve ser comunicado, no mnimo, com um dia de antecedncia da reunio.
Convocado por:
Nome da Organizao Desenvolvedora Nome da Equipe
Data:
10/05/10
179
ANEXO III Exemplo de Ata de Oficina de Levantamento de Requisitos
Ata de Reunio de Levantamento de Requisitos

Projeto NomeDoProjeto
Data:
Horrio:
Local:
10/05/10
11:00 - 11:30h
Nome do Local
Participantes do Cliente:
Nome do Cliente 1
Nome do Cliente 2
Nome do Cliente 3
Participantes do Desenvolvedor:
Tpicos discutidos
N
Assunto
1.
2.
Descrio
Apresentao inicial
Sees iniciais da ERSw
1. O planejamento inicial foi apresentado aos usurios.

1. Foi solicitada a alterao da data de incio do perodo de
reviso da ERSw pelos usurios. O fornecedor ficou de
avaliar se ser possvel.
2. Foi esclarecido que os resultados precisaro ser
acompanhados por outros membros da PLAG.
3. Foi sugerida uma apresentao do trabalho que est sendo
feito para as pessoas envolvidas do cliente para que as
mesmas tomem conhecimento.
4. O cronograma inicial das oficinas e pautas sugeridas para
cada uma delas foi apresentado aos usurios. Foi colocado
que caso alguma oficina seja cancelada, esse cancelamento
ter repercusso em todo o planejamento comprometendo os
prazos de entrega da ERSw e fases posteriores a
especificao.
Erratas
Data
-
Tpico incorreto
Correo
Pendncias
N
3.
Descrio
Agendar uma data para apresentao do trabalho que est

sendo feito para os envolvidos do cliente.
4.
Rever perodo de reviso da ERSw pelos usurios.
5.
Rever Pautas previstas das oficinas.
Data de envio da ata para o cliente:
Responsvel
UFPI
Prazo
Em aberto
UFPI
UFPI
180

Apostila Requisitos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Apostila Requisitos

Transféré par

Droits d'auteur :

Formats disponibles

Mdulo VI

Um Sistema de Informao (SI), ou qualquer outro software,

contagem do tamanho de um sistema, baseado na Especificao de

3.1.7. Diagrama de Casos de uso ...................................................... 75

em sua mente. Esses aspectos necessitam ser capturados,

chegarmos a uma Especificao de Requisitos. Esse documento o

especializados com a rea de negcio do produto a ser construdo.

O conjunto de tcnicas empregadas para levantar, detalhar,

documentar e validar os requisitos de um produto compe a

Qualidade dos requisitos

Os requisitos de um software correspondem a uma parte

Uma Especificao de Requisitos correta se todo requisito

executado. A idia por trs disso e encontrar falha na qualidade dos

Uma ER precisa se todo requisito presente possuir apenas

compreensvel para todo o seu pblico alvo, e deve ser suficiente

Uma ER completa se reflete todas as decises de

software desejado, normalmente ignorando os requisitos no

Uma ER consistente se no h conflitos entre nenhum dos

Uma ER priorizada se cada requisito classificado de

Uma ER verificvel se todos os seus requisitos so

Uma ER modificvel se sua estrutura e estilo permitirem a

Uma ER rastrevel se permite a fcil determinao dos itens

Rastreabilidade para trs, na qual deve ser possvel localizar

Rastreabilidade para a frente, na qual deve ser possvel

todos os requisitos e para localizar os itens que sero

Atividades do Fluxo de Requisitos

O Fluxo de Requisitos composto por vrias atividades, que

Figura 1: Atividades do Fluxo de Requisitos.

As atividades do Fluxo de Requisitos so exibidas na Figura 1.

figura (uma circunferncia preta) conhecida como atividade inicial.

O Escopo de um Projeto algo fundamental para o seu

Na definio acima, podemos notar que o trabalho a ser

forma mais precisa o que est e o que no est includo no projeto.

comunicao com o cliente.

nas definies dos requisitos, necessitaremos da participao de

controle uma empresa, idealmente deveramos conversar com os

Identificao dos Requisitos

A Identificao do Requisitos a atividade que prescreve a

Por exemplo, em um sistema de controle de uma biblioteca, o

que foi comentado so detalhes do comportamento que o software

podemos exigir como requisito de

desempenho que ele funcione com at 100 usurios simultneos,

Tabela 1: Exemplo de definio de requisitos.

acompanhar sua evoluo, incluindo as pessoas

O sistema deve possibilitar a especificao dos

Deve ser possvel realizar uma reviso dos

Acompanhamento dos clientes

Deve ser possvel que os clientes possam

Liberao de acesso por projeto

Deve ser possvel liberar o acesso ao sistema

Deve ser possvel gerar a especificao na

Podemos notar que os requisitos exibidos na Tabela 1 so

exemplos disso a definio do ambiente (Web), o uso de uma

tecnologia especfica (MySQL) ou a definio de valores para

necessitam da definio de valores que permitam sua verificao.

O sistema deve funcionar em ambiente Web,

O sistema deve ser desenvolvido utilizando-se a

RNF3 Banco de dados

O sistema deve utilizar o banco de dados

O sistema deve ser construdo para funcionar

O sistema deve restringir o acesso por meio de

Um usurio com conhecimento bsico em

O desenvolvimento de software pode ser entendido como