Requisitos de Software PDF

Universidade Federal do Piau
Centro de Educao Aberta e a Distncia
Requisito de
software
Pedro de Alcntara dos Santos Neto
2 UNIDADE 01
Ministrio da Educao - MEC
Universidade Aberta do Brasil - UAB
Universidade Federal do Piau - UFPI
Centro de Educao Aberta a Distncia - CEAD
Requisito de Software

PRESIDENTE DA REPBLICA Dilma Vana Rousseff Linhares
MINISTRO DA EDUCAO Jos Henrique Paim
GOVERNADOR DO ESTADO Wilson Nunes Martins
REITOR DA UNIVERSAIDADE FEDERAL DO PIAU Luiz de Sousa Santos Jnior
PRESIDENTE DA CAPES Jorge Almeida Guimares
COORDENADOR GERAL DA UNIVERSIDADE ABERTA DO BRASIL Joo Carlos Teatini de S. Clmaco
DIRETOR DO CENTRO DE EDUCAO ABERTA E A DISTNCIA DA UFPI Gildsio Guedes Fernandes
COORDENADORES DE CURSOS
ADMINISTRAO Francisco Pereira da Silva Filho
CINCIAS BIOLGICAS Maria da Conceio Prado de Oliveira
FILOSOFIA Zoraida Maria Lopes Feitosa
FSICA Miguel Arcanjo Costa
MATEMTICA Joo Bencio de Melo Neto
PEDAGOGIA Vera Lcia Costa Oliveira
QUMICA Davi da Silva
SISTEMAS DE INFORMAO Arlino Henrique Magalhes de Arajo
EQUIPE DE DESENVOLVIMENTO CONSELHO EDITORIAL DA EDUFPI

TCNICO EM ASSUNTOS EDUCACIONAIS Ubirajara Santana Assuno Prof. Dr. Ricardo Alaggio Ribeiro ( Presidente )
EDIO Roberto Denes Quaresma Rgo Des. Tomaz Gomes Campelo
PROJETO GRFICO Samuel Falco Silva Prof. Dr. Jos Renato de Arajo Sousa
DIAGRAMAO Jos Lus Silva Prof. Dr. Teresinha de Jesus Mesquita Queiroz
REVISO Beatriz Gama Rodrigues
Prof. Francisca Maria Soares Mendes
REVISO GRFICA Carmem Lcia Portela Santos
Prof. Iracildes Maria de Moura F Lima
Prof. Dr. Joo Renr Ferreira de Carvalho
S237 Neto, Pedro de Alcntara dos Santos

Sistemas de Informaes / Pedro de Alcntara
dos Santos Neto - Teresina: EDUFPI/UAPI, 2011
160 p.
ISBN: 978-85-7463-326-8
1- Requisito de Software 2 - CPU. 3 - Motivao
C.D.D. - 005.3
2013. Universidade Federal do Piau - UFPI. Todos os direitos reservados.A responsabilidade pelo contedo e
imagens desta obra do autor. O contedo desta obra foi licenciado temporria e gratuitamente para utilizao
no mbito do Sistema Universidade Aberta do Brasil, atravs da UFPI. O leitor se compromete a utilizar o
contedo desta obra para aprendizado pessoal, sendo que a reproduo e distribuio ficaro limitadas ao
mbito interno dos cursos. A citao desta obra em trabalhos acadmicos e/ou profissionais poder ser feita
com indicao da fonte. A cpia deste obra sem autorizao expressa ou com intuito de lucro constitui crime
contra a propriedade intelectual, com sanses previstas no Cdigo Penal.
Um Sistema de Informao (SI) ou qualquer outro software tem
seu incio associado ideia de desenvolv-lo. A partir desse momento,
necessrio iniciar uma srie de reunies para se aprofundar o
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.
UNIDADE 1
11 O FLUXO DE REQUISITOS
1.1 O Fluxo de Requisitos .......................................................... ....13

Qualidade dos requisitos .......................................................... 14
Correo.................................................................................... 14
Preciso..................................................................................... 15
Completeza ........................................................................... ....15
Consistncia ............................................................................. 15
Verificabilidade........................................................................... 16
Modificabilidade......................................................................... 16
Rastreabilidade ..................................................................... ....16
1.2 Atividades do Fluxo de Requisitos ............................................ 16
Definio do Escopo.................................................................. 17
Identificao dos Requisitos...................................................... 17
Detalhamento dos Requisitos ............................................... ....17
Detalhamento dos Casos de uso .............................................. 17
Definio dos Prottipos de Interface........................................ 18
Reviso dos Requisitos............................................................. 18
Exerccios.................................................................................. 40
1.3 Tcnicas de Apoio ao Levantamento de Requisitos ............. ....42
Oficinas de requisitos ............................................................... 42
Personalizao.......................................................................... 43
Sesses..................................................................................... 44
Fechamento............................................................................... 45
Revises.................................................................................... 45
Participantes.............................................................................. 47
Condues................................................................................. 48
Exerccios.................................................................................. 50
UNIDADE 2
53 ANLISE DE SOFTWARE
2.1 A Linguagem UML ................................................................ ....55

A Origem da UML ..................................................................... 55
Vises........................................................................................ 56
Modelo de Elementos................................................................ 57
Classes ................................................................................. ....11
Objetos ..................................................................................... 59
Estados...................................................................................... 59
Pacotes...................................................................................... 60
Componentes ....................................................................... ....60
Relacionamentos ...................................................................... 61
Mecanismos Gerais................................................................... 65
2.2 Diagramas................................................................................. 65
Diagrama de Casos de uso .................................................. ....66
Diagrama de Classes ............................................................... 66
Diagrama de Objetos................................................................. 66
Diagrama de Estados................................................................ 67
Diagrama de Seqncia............................................................ 68
Diagrama de Colaborao .................................................... ....69
Diagrama de Atividades ............................................................ 69
Diagrama de Componentes....................................................... 70
Diagrama de Implantao.......................................................... 71
Consideraes Finais................................................................ 72
Exerccios.................................................................................. 72
2.3 O Fluxo de Anlise..................................................................... 73
Atividades do Fluxo de Anlise.................................................. 73
Identificao das Classes.......................................................... 74
Organizao das Classes.......................................................... 81
Realizao dos Casos de Uso................................................... 82
Reviso da Anlise.................................................................... 84
2.4 Anlise de Pontos de Funo.................................................... 85
Introduo a Anlise de Pontos de Funo............................... 88
O Processo de Contagem......................................................... 90
Contagem de Funes de Dados.............................................. 95
Contagem de Funes de Transao........................................ 96
Contagem Estimativa de Pontos de Funo........................... 101
Contagem de funes de dados.............................................. 102
Contagem de funes de transao........................................ 104
Planejamento e Gesto de Projetos com PF........................... 108
Viso crtica da APF................................................................. 109
Exerccios.................................................................................111
UNIDADE 3
115 EXEMPLOS DE ARTEFATOS
Exemplos de Artefatos ........................................................ ....115
UNIDADE 1
O fluxo de
Requisito
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.
REQUISITO DE SOFTWARE 11
O FLUXO DE REQUISITO
Um requisito pode ser definido como um desejo, necessidade,
Um requisito pode
restrio ou expectativa de um cliente com relao a um produto. Ou seja,
ser resumido como
ao pensar em um produto, um cliente possui muitos aspectos em sua
algo desejado por um
mente que necessitam ser capturados, definidos, organizados, verificados
usurio em relao a
e validados para que se chegue a uma Especificao de Requisitos. Esse
um produto.
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 obter o enunciado O conjunto de
completo, claro e preciso dos requisitos de um produto de software. Os tcnicas empregadas
requisitos devem ser levantados pela equipe do projeto, normalmente para levantar, detalhar,
denominados Analistas de Requisitos (ou Engenheiros de Requisitos) documentar e validar
em conjunto com representantes do cliente, usurios chaves que contam os requisitos de um
com a presena de especialistas da rea de aplicao, uma vez que o produto compe a En-
projeto pode envolver conhecimentos no triviais que exijam a presena genharia de Requisitos
de profissionais altamente 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 Engenharia
de Requisitos. O resultado principal do fluxo dos requisitos o documento
de Especificao de Requisitos (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 segundo Paula Filho (2003).
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.
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. Outra forma de 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 executado. A ideia por trs
disso encontrar falhas na qualidade dos requisitos que podem estar
associadas a qualquer uma das caractersticas apresentadas nessa
seo.
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.
14 UNIDADE 01
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
funcionalidade, desempenho, restries de desenho, atributos e interfaces
externas, alm de definir as respostas do software para todas as entradas
possveis, vlidas e invlidas e 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
software desejado, normalmente ignorando os requisitos no funcionais.
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 uma reviso fundamental para o
fechamento de uma ER, pois apenas a partir de uma ao como essa
que poderemos descobrir certas incorrees.
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
Verificabilidade
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
mostrando conformidade do produto final com o requisito.
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 atravs de
formatos pr-definidos e adequados ao uso.
Rastreabilidade
Uma ER rastrevel quando permite a fcil determinao dos
itens que antecederam o surgimento deste, os quais foram gerados por
conta da existncia do mesmo. Isso normalmente est associado a dois
tipos de rastreabilidade:
1. 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 extinguir
dvidas de interpretao.
2. Rastreabilidade para 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 todos os requisitos; 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
16 UNIDADE 01
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
figura (uma circunferncia preta) conhecido como atividade inicial,
representando o ponto de partida do fluxo. Os demais retngulos com
os lados arredondados representam atividades. Existem duas barras de
sincronizao na figura, representando que as atividades posteriores s
iniciam quando 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 concludo.
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.
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 desdobram 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.
Definio do Escopo
O Escopo de um Projeto algo fundamental para o seu sucesso.
Sua definio algo considerado simples, porm deve ser feita de forma
prudente e com a participao dos principais envolvidos.
Em muitos momentos, o escopo do projeto dever ser reanalisado,
Uma boa forma de evitar pois define o que est e o que no est includo no projeto em questo.
problemas com os clien- Um escopo mal estruturado poder levar a falhas de cronograma
tes de um projeto definir e de oramento, uma vez que tarefas acima do previsto podem ser
bem o escopo e, para consideradas, ao invs daquilo o que realmente deveria ter sido includo.
evitar falsas expectativas, De forma geral, o escopo de um projeto pode ser simplesmente
detalhar o que no faz um texto que define o que deve fazer parte do projeto. Neste material,
parte dele. Por isso, to utilizaremos um exemplo para demonstrar todas as atividades aqui
importante termos uma descritas. Ser usado como exemplo prtico algo muito apropriado ao
seo com os Limites do tema: uma ferramenta para Gerncia de Requisitos. Esse projeto ser
Produto. 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.
Na definio acima, podemos notar que o trabalho a ser realizado

foi definido. Certamente, nem todos os que chegarem a ler o enunciado
poder 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
18 UNIDADE 01
fora dele. Isso normalmente ajuda aos clientes entenderem de 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 o 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 sero obtidos 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 Importante: para se con-
requisitos justamente saber quem deveria participar dessa definio. hecer bem o que deve
ser feito por um produto,
Normalmente, qualquer organizao possui alguns nveis devemos comear a
hierrquicos em sua constituio. As pessoas no nvel hierrquico conversa com aqueles
mais alto geralmente possuem um bom conhecimento sobre tudo o que entendem um pouco
de tudo (diretoria) para
que realizado na organizao. Isso acontece por que eles devem ser depois iniciarmos um
comunicados e devem acompanhar o que se passa dentro da instituio. aprofundamento nos
Essas pessoas formam um grupo ideal para se utilizar na definio de detalhes (gerncia,
chefias).
um produto, pois conhece o todo. Ao aprofundarmos 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 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.
Daremos incio a um trabalho prtico que dever ser feito por cada
aluno da disciplina, o qual 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
ERSs que estamos apresentando como exemplo e que est contido na
pgina da disciplina.
Requisitos funcionais
esto associados a
Identificao dos Requisitos
comportamento. Req-
uisitos no funcio- A Identificao dos Requisitos a atividade que prescreve a
nais esto ligados a criao de uma lista dos requisitos para a aplicao a ser desenvolvida.
caractersticas que o
Cada requisito nada mais que uma descrio textual de algo que deveria
comportamento deve
ser considerado durante o desenvolvimento de software.
possuir.
Os requisitos podem ser divididos em dois tipos: requisitos
funcionais e no funcionais. Os funcionais esto diretamente ligados
ao comportamento que a aplicao deve conter. 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 e ativo; que o
livro desejado esteja disponvel, no reservado e no seja cativo; que o
usurio no esteja com cinco livros emprestados, considerando que esse
seja o nmero mximo de emprstimos simultneos permitido. Tudo isso
que foi comentado so detalhes do comportamento que o software deve
ter.
Outro tipo de requisito o no funcional. 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.
Conforme comentado, a lista dos requisitos a expresso que
20 UNIDADE 01
resume 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.
ID Requisito Descrio
O sistema deve permitir cadastrar e con-
trolar todos os aspectos relacionados
aos requisitos de um projeto, permitindo
RF1 Requisitos
visualiz-lo e acompanhar sua evoluo,
incluindo as pessoas que trabalharam no
projeto, analistas e gerente do projeto.
O sistema deve possibilitar a especifica-
o dos casos de uso, registrando sua
RF2 Casos de uso descrio, atores, prottipos de tela as-
sociados, relacionando os requisitos que
deram origem ao caso de uso.
Deve ser possvel realizar uma reviso
dos requisitos e casos de uso, utilizando
RF3 Reviso critrios definidos pelos prprios geren-
tes de projetos, de forma independente
aos demais projetos.
Deve ser possvel que os clientes pos-
sam acompanhar a evoluo do projeto
RF4 Acompanhamento dos clientes
a qualquer momento, consultando tudo
o que foi feito.
Deve ser possvel liberar o acesso ao
sistema por projeto, indicando o seu
gerente. Assim, para se ter acesso ao
sistema, dever ser adquirido uma li-
cena para um projeto. A partir disso,
RF5 Liberao de acesso por projeto o gerente ficar responsvel por definir
quem dever usar o sistema, seja para
trabalhar na especificao de requisitos
como um dos Engenheiros de Requi-
sitos, seja como cliente consultando o
resultado do trabalho realizado.
Deve ser possvel gerar a especificao
na forma de um documento no editvel,
RF6 Gerao da documentao
contendo todos os dados registrados do
projeto.
Tabela 1: Exemplo de definio de requisitos
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 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.
O sistema deve funcionar em ambiente
Web, sendo compatvel com os princi-
RNF1 Ambiente
pais navegadores do momento: Internet
Explorer, Firefox, Safari e Chroma.
O sistema deve ser desenvolvido utili-
RNF2 Linguagem zando-se a linguagem Java, com as tec-
nologias JSF e Hibernate.
O sistema deve utilizar o banco de da-
RNF3 Banco de dados
dos MySQL.
O sistema deve ser construdo para fun-
cionar com 100 usurios simultneos,
RNF4 Desempenho
com respostas de at 5s quando utiliza-
do em rede local.
O sistema deve restringir o acesso por
meio de senhas. Deve-se ter um con-
RNF5 Segurana trole no registro de senha, de forma a
impedir o uso de senhas consideradas
fceis.
O sistema deve restringir o acesso por
meio de senhas. Deve-se ter um con-
RNF5 Segurana trole no registro de senha, de forma a
impedir o uso de senhas consideradas
fceis.
Tabela 2: Exemplo de requisitos no funcionais
O desenvolvimento de software pode ser entendido como uma

srie de transformaes que nos levam aos desejos dos clientes at um
produto executvel que atende a tais desejos. O incio das transformaes
acontece quando iniciamos uma srie de 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.
22 UNIDADE 01
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 ideia
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 que esto sendo descritas.
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, assim como
pode estar relacionado 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.
Os casos de uso so acionados por atores. Um ator a
representao de um papel no sistema. Atores podem representar um Casos de uso podem ser
considerados as funes
grupo de usurios, outro sistema, com o qual o sistema sendo especificado que um produto deve
deve interagir. Um caso de uso normalmente interage com apenas um oferecer.
ator, mas pode interagir com mais de um. Segundo Pdua Filho (2003),
atores podem ser identificados atravs dos seguintes critrios:
1. Quem est interessado em certo requisito;
2. Quem se beneficiar diretamente do produto;
3. Quem usar informao do produto;
4. Quem fornecer informao ao produto;
5. Quem remover informao do produto;
6. Quem dar suporte e manuteno ao produto;
7. Quais os recursos externos usados pelo produto;
8. Quais os papis desempenhados por cada usurio;
9. Quais os grupos de usurios que desempenham o mesmo papel;
10.Quais os sistemas legados com os quais o produto deve interagir;
11. Quando casos de uso so disparados periodicamente, o tempo 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.
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
Atores modelam exemplo, alarmes, mensagens, dados enviados para outros sistemas,
papis associados ao
uso do produto. Pa-
etc.), a comunicao deve ser direcionada para o ator.
pis e no pessoas!
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, o ator e Outro ator possuem 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
24 UNIDADE 01
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:
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 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 um 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
Os requisitos so textos
Gesto de requisitos. que descrevem os dese-
jos dos clientes. Simples
Observe que ainda no texto do RF1 existe a meno ao registro assim!
das pessoas que trabalharam no projeto. Isso significa que teremos que Os casos de uso so as
tradues dos requisitos
ter um cadastro dos envolvidos no projeto. Cadastraremos o gerente, os em funes do produto,
analistas e os clientes envolvidos. Com isso, possvel identificar que feita por Engenheiros de
Requisitos, a partir de um
teremos que cadastrar os membros do projeto. Isso d origem a mais um entendimento do que foi
caso de uso: Gesto de membros. solicitado e o que pode ter
em um produto.
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 novos 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.
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, 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 com datas de execuo, limites do produto
que tambm precisam ser cadastrados. Isso nos leva a ter 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.
A exibio dos casos de
uso e os requisitos que Analisando o RF6 que trata da gerao da documentao,
foram utilizados para sua encontramos algo interessante: a necessidade relatada j est
gerao, nos do uma
idia da rastreabilidade contemplada com a proposio do caso de uso Gerao da documentao,
dos requisitos. 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
O diagrama de casos de isso de forma direta neste documento, isso normalmente exige reunies,
uso nos d uma visao discusses e um amadurecimento por parte dos clientes e envolvidos
ampla do sistema, exibin-
do as funes existentes para que se chegue a uma determinao do produto a ser desenvolvido.
e os papis associados. A Figura 3 apresenta um diagrama de casos de 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, sendo necessrio um maior
aprofundamento dos requisitos. Isso inclui a determinao das regras
de negcio associadas a cada um dos casos de uso que ser feito na
prxima subseo.
26 UNIDADE 01
Figura 3: Diagrama de casos de uso para o ReqG.
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 rastreabilidade. Isso nos permite
saber quem deu origem a qu. Assim, possvel saber que um requisito
deu origem a um determinado caso de uso.
ID Caso de uso Requisito associado Descrio
Cadastro de requisitos
funcionais e no fun-
UC1 Gesto de Requisitos RF1
cionais associados ao
projeto.
ID Caso de uso Requisito associado Descrio
Cadastro de todos os
UC2 Gesto de Membros RF1
envolvidos no projeto.
Definio dos casos de

UC3 Gesto de Casos de Uso RF2
uso do projeto.
Definio dos atores

UC4 Gesto de Atores RF2 que iro interagir no
projeto.
Reviso de um requisito
A exibio dos casos de ou de um caso de uso,
uso e os requisitos que UC5 Reviso RF3 observando os critrios
pr-estabelecidos no
foram utilizados para sua projeto para a reviso.
gerao, nos do uma
Cadastro de critrios
idia da rastreabilidade Gesto de Critrios de
UC6 RF3 a serem utilizados em
Reviso
dos requisitos. uma reviso.
Cadastro de um projeto,
com definio do seu
UC7 Cadastro de Projeto RF5
gerente, feito pelo admi-
nistrador do sistema.
Cadastro de um gerente
UC8 Gesto de Gerentes RF5 de projeto, feito pelo ad-
ministrador do sistema.
Controle do projeto, com
detalhamento de infor-
UC9 Controle de Projetos RF5 maes sobre o mesmo,
feito pelo gerente do
projeto.
Gerao da especifi-
cao de requisitos,
utilizando um formato
UC10 Gerao da especificao RF6, RF4
pr-definido, contendo
todos os dados registra-
dos no projeto.
Emisso de um relatrio
contendo uma indicao
Relatrio de Acompanha- do estado do projeto,
UC11 RF6, RF4
mento a partir do estado de
cada caso de uso que o
compe.
Tabela 3: Lista de casos de uso identificados.
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.
28 UNIDADE 01
N Ator Descrio
Clientes de um projeto, normalmente responsvel
1. Cliente pelo fornecimento de informaes para moldagem do
produto.
Responsvel pelo controle do uso do sistema, libe-
2. Administrador rando acesso aos gerentes a partir do cadastramento
de um projeto.
Responsvel pelo controle de um projeto, definindo a

3. Gerente
equipe e suas tarefas.
Pessoa que faz parte da equipe que trabalha no

4. Membro
projeto.
Tabela 4: Lista de atores do 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 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 histrias de usurios (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 sequncia de passos. Cada passo corresponde a uma ao de
um ator ou do produto que devem aparecer explicitamente como sujeitos
da frase. Outros atores podem aparecer como objetos verbais de uma
ao. Nesse caso, provavelmente tais atores estejam ligados ao caso de
uso utilizando setas que indicam a direo da comunicao no diagrama
de casos de uso. Condies e interaes 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
apresentados nesse 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 ou 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.
30 UNIDADE 01
Fluxo alternativo: Incluso de um Novo Gerente
Prcondies 1 - O Administrador acionou o comando Novo.
1 - O Administrador preenche os Dados do Gerente.

2 - O Administrador aciona o comando Salvar.
Passos 3 - O ReqGverifica que no existe um Gerente com email O levantamento de requisi-
e login informados. tos deve detalhar o desejo
4 - O ReqGsalva os Dados do Gerente.
dos clientes. No devemos
introduzir especificidades
de desenho ou implementa-
Observe que na descrio do fluxo alternativo acima existe a o durante essa atividade.
especificao de pr-condies que detalham o que deve acontecer para Por isso no aconselhado
que o fluxo entre em execuo. No caso, para que a incluso de um novo detalhar mensagens ao
gerente acontea, necessrio que o ator associado ao caso de uso usurio, tecnologias, etc.
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 no seja, 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 que sero traduzidas nas diversas regras
de negcio de um produto durante sua implementao.
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 e complexos ou com
potencial de serem reutilizados em outros fluxos. Seria algo equivalente
a extrair um mtodo de outro mtodo. 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
programe 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.
O ReqG recupera e exibe os Projetos que atendem aos parmetros de pesquisa
informados na lista Projetos Recuperados e que tenham como Membro no projeto o
usurio corrente, ordenados pelo nome do Projeto em ordem crescente.
32 UNIDADE 01
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.
Se no:
O ReqG calcula o percentual de concluso do requisito a partir do estado do
requisito, ou seja, 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) e interaes (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.
Definio dos Prottipos de Interface

A Definio dos Prottipos de Interface especifica, de forma
detalhada, os requisitos relacionados s 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 auxilia bastante
a identificao de regras de negcio, dados a serem utilizados e formatos
de campos. extremamente importante definir que tecnologia utiliza
para gerao desses esboos, uma vez que eles no devem demandar
muito esforo e nem deveriam focar em tecnologias especfica, visto que
Os prottipos de interfaces,
isso pode limitar o espao da soluo sem que haja essa necessidade.
durante o levantamento
Os esboos so apenas sugestes, mas que no deveriam ser seguidos
de requisitos, devem ser
focados em se descobrir
rigorosamente na construo no produto. Eles servem muito mais para
as informaes e restries detalhar os dados envolvidos nos fluxos que propriamente para especificar
importantes ao requi- formatos de tela. Exemplos de esboos podem ser construdos utilizando
sito. Nenhum aspecto de as seguintes tecnologias:
execuo ou usabilidade 1. Desenhos mo livre, em papel;
deveria ser tratado nesse
2. Layout alfanumrico feitos com um editor de texto como o Word;
momento.
3. Layout feitos em um editor HTML, como o DreamWeaver;
4. Desenhos feitos com uma ferramenta de desenho tcnico como
o Pencil;
5. Telas desenhadas em um ambiente de desenvolvimento rpido
como Delphi;
6. 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
independentes 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.
34 UNIDADE 01
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 Silio Silvestre Ferreira Freitas
<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 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.
Campo altervel.
Campo no altervel.
Ttulo de interface, rtulo de campo ou comando.
Tabela 5: Exemplo de prottipo simples.
Na Tabela 5 mostrado que o formato de cada campo altervel

descrito na forma de um texto junto ao prprio campo. Isso pode ser
visto no campo projeto, o qual contm 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, facilitando 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 algo comum
na maioria dos sistemas. Frequentemente necessita-se 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 tranquilo
quanto 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 denominada Projetos Recuperados aqueles
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 Modelo-
ERSw.doc.
36 UNIDADE 01
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 conter uma lista de projetos que atendem
a uma determinada restrio, significando que essa lista ser carregada
dinamicamente durante a execuo do produto e que seus valores sero
trazidos de uma entidade do produto.
Dados da Reviso
Projeto* [Lista de Projetos que possuem o usurio corrente como membro]
Identificador* Reviso preliminar de requisitos (texto at 50 caracteres)
Descrio* Reviso preliminar de requisitos (texto at 50 caracteres)
Data* 12/12/2010 (data no formato dd/mm/aaaa)
[Lista de Membros do Projeto que no sejam clientes]
Participantes
dos desenvolve- ...
dores*
[Lista de Membros do Projeto que sejam clientes]
Participantes dos
...
clientes
Situao* [Aberta; Fechada]
Figura 5: Prottipo com campos mais especficos.
Ainda no prottipo exibido na Figura 5, podemos notar que o campo

Participante dos desenvolvedores tambm possui uma especificao de
uma lista, mas poder ter mais de um valor, o qual ser mapeado por
diversas formas em uma interface definitiva: vrios campos do tipo check
box, um campo list, uma tabela, etc.
[Lista de Tipos de Ingresso pr-cadastrados no sistema]

Tipos de Ingresso ...
[Lista de Tipos de Ingresso pr-cadastrados no sistema]
[Lista de Effects pr-cadastrados no sistema]
Effects ...
[Lista de Effects pr-cadastrados no sistema]
Classificao [Matrcula; Nome]
Figura 6: Exemplo de especificao de prottipo usando editores de texto.
Figura 7: Exemplo de interface definitiva similar ao prottipo da figura anterior.
Uma modelagem do
prottipo, feita utilizando
Na Figura 6 temos a especificao de trs campos utilizando nossas
nossas convenes, pode
convenes. Os dois primeiros campos so multivalorados enquanto que
ser mapeada para diferen-
tes formatos em tecnologias o terceiro pode ser apenas um de dois possveis valores. Na Figura 7
especficas 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, este poder 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, o qual deve servir de base para a criao do nosso trabalho
prtico.
chegada a hora de realizar a criao dos prottipos para os
casos de uso identificados. Lembre-se do formato independente de
tecnologia apresentado aqui e fique atento s convenes definidas.
Reviso dos Requisitos

A reviso dos requisitos a atividade realizada para garantir
que o padro prescrito pela organizao foi realmente seguido e que os
requisitos identificados atendam aos critrios de qualidade solicitados,
permitindo o seu correto entendimento e, por conseguinte, a realizao
do projeto adequado bem como da implementao apropriada.
38 UNIDADE 01
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
devam 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 adequadas 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 na Tabela 6. Nela podemos notar a anlise de alguns
requisitos e casos de uso com base em critrios pr-definidos. A partir
dessa anlise sero registrados os eventuais conflitos e acompanhado
os passos para sua resoluo.
Caso de Comple-
Nr. Requisito Ambigidade Clareza Conflitos
Uso tude
No foi especifi-
cada a ordem
No
1 RF1 UC2 Aprovado Aprovado em que os resul-
aprovado
tados devem ser
exibidos.
2 RF2 UC3 Aprovado Aprovado Aprovado -
O caso de uso
parece que
poderia ser
agrupado com
o caso de uso
No aprova- Gesto de
3 RF5 UC8 Aprovado Aprovado
do Membros, no
havendo ne-
cessidade de
criao de um
caso de uso
adicional.
Tabela 6: Fragmento da reviso de uma ER.
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 critrios, detalhando
como eles sero utilizados, alm de registrar os problemas e as formas
de resoluo dos mesmos.

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 segundo o autor Pdua
Filho (2003, p. ? ) para desenvolver uma especificao de requisitos
que custa tempo e dinheiro; no faz-la geralmente custa mais tempo e
dinheiro ainda!
exerccios propostos
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?
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? Descreva-as
brevemente/
9. O que o escopo de um projeto?
10. Por que importante definir os limites do produto?
11. Como deve ser a abordagem em uma instituio para se levantar
requisitos junto aos clientes?
40 UNIDADE 01
12. Qual a diferena entre requisitos funcionais e no-funcionais?
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, segundo requisitos do software?
16. O que so os atores, segundo requisitos do software?
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 utilizadas para construo de
prottipos?
26. Qual a conveno de cores utilizadas para construo de
prottipos? O que elas significam?
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?
29. Qual a importncia dos critrios para uma reviso de requisitos?
1.3 Tcnicas de Apoio ao Levantamento de Requisitos
Durante o levantamento de requisitos so necessrias diversas
reunies que 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 baseada do livro Engenharia de Software de
autoria do Paula Filho (2003).
Oficinas de requisitos
Uma oficina de requisitos
uma forma de identifi-
As oficinas de requisitos so reunies estruturadas para definio
car o que se deseja de conjunta dos requisitos, envolvendo desenvolvedores, usurios e demais
forma conjunta com os
especialistas. O tipo de oficina que ser aqui discutido baseado nas
usurios.
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 so feitos em conjunto
com a participao de desenvolvedores e usurios chaves, assim como
gerentes, todos unidos para termos uma melhor qualidade no resultado
O levantamento de do trabalho.
requisitos utilizando JAD As oficinas de requisitos tendem a apresentar melhores resultados
normalmente apresenta
resultados muito interes- que os levantamentos baseados em reunies individuais com alguns
santes. usurios. Isso acontece por uma srie de razes, dentre elas:
1. Elas facilitam o comprometimento dos usurios com poder de deciso
e os requisitos;
2. 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;
3. Eliminam requisitos de valor questionvel, uma vez que todos so
discutidos nas reunies;
4. Reduzem diferenas de interpretao dos requisitos entre usurios e
desenvolvedores, uma vez que as explicaes acontecem ao vivo e com
diferentes pontos de vista;
5. Produzem um primeiro esboo das interfaces de usurio, a partir do
42 UNIDADE 01
direcionamento dado pelos prprios usurios no momento das reunies;
6. Trazem tona, o mais cedo possvel, problemas polticos que possam
interferir no projeto. Essas oficinas possuem trs partes bem distinta: 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
dos resultados obtidos.
Personalizao
A personalizao da oficina de requisitos uma parte simples do
processo. 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.
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 A seleo dos par-
os usurios adequados a participarem de uma reunio de levantamento ticipantes das reunies
algo que pode facilitar
de requisitos? No existe uma resposta genrica e adequada para tal muito o levantamento de
questo, mas existem diretrizes importantes a serem seguidas. Uma requisitos.
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.
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 diversas interrupes quando 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 essas regras. Telefonemas no devem ser
Sem o controle ad-
atendidos, ou seja, preferncia desligar.
equado nas sesses,
o risco de insucesso Deve-se planejar a disponibilidade e necessidade dos materiais,
aumenta bastante! tais como:
1. Computadores: normalmente so necessrios pelo menos 2
computadores (ou notebooks), sendo um para projeo da ER que est
sendo criada e outro para redao da ata da reunio;
2. Projetores: pelo menos um projetor necessrio para que seja possvel
exibir o resultado do trabalho e permitir uma discusso de todos;
3. Copiadoras: eventualmente pode ser necessrio compartilhar material
com os demais participantes;
4. Blocos de escrever, flip-charts, quadros brancos, lpis e canetas: em
muitos momentos ser necessrio escrever, sendo importantes termos
materiais para tal fim;
5. 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:
1. 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;
2. Os patrocinadores, representantes do cliente, responsveis pela
resoluo de conflitos entre grupos de usurios, com poder de deciso
para tal;
3. Os representantes dos usurios tm autoridade para tomar decises
em nome da respectiva comunidade;
4. Desenvolvedores: fornecem informao sobre a viabilidade das idias
levantadas;
44 UNIDADE 01
5. O relator, participante da equipe do projeto, encarregado de redigir as
atas de reunio.
Durante a discusso, as ideias devem ser registradas e
simultaneamente exibidas a todos os participantes, seja atravs de
quadros brancos, seja atravs do 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 todo o comprometimento que dever
existir em relao s concluses da oficina.
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, o fechamento feito apresentando o 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. Esse modelo pode ser utilizado para servir de
base para criao desses artefatos em um projeto.
De modo geral, uma ata deve conter um espao para detalhar
os participantes (clientes e desenvolvedores), assuntos discutidos
e pendncias. As atas so importantes, pois alm de registrarem os
assuntos discutidos e envolvidos na discusso, detalha o tempo em que
tais discusses apareceram, mostrando profissionalismo nas relaes,
algo que no comum em todas as empresas que trabalham com o
desenvolvimento de software. Uma reviso um me-
canismo de garantia da
qualidade normalmente
Revises aplicada para verificar ar-
tefatos no executveis.
O Teste de Software algo muito importante no desenvolvimento.
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 se torna necessria 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
porque se encontra defeitos em um produto nessa fase.
As revises aplicadas no desenvolvimento de software geralmente
so de responsabilidade de um grupo de garantia da qualidade. Como
boa parte das organizaes pequena e no consegue 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 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 conformes
com os respectivos padres e se modificaes foram efetuadas de
maneira correta.
A inspeo mais formal que a reviso tcnica. Tem como objetivo
principal 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 este papel mais passivo. Podem ser usadas nos marcos de
projeto em que so necessrias apresentaes ao cliente.
A reviso gerencial conduzida pelo gerente de um projeto com
o objetivo principal 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:
1. 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 por uma reviso permanente do
trabalho sendo executado.
2. A reviso individual realizada pelos autores, seguindo formalmente
46 UNIDADE 01
os roteiros pertinentes, eventualmente com a ajuda de pares.
3. A reviso preliminar realizada por um ou mais pares dos autores, para
eliminar defeitos mais simples do material como ortografia, numerao,
estilos e consistncia.
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:
1. Ele deve compreender o proposito das revises em geral e entender
seu funcionamento;
2. Ter conhecimentos tcnicos de alto nvel sobre o material a ser revisado;
3. Ter participado de alguma outra reviso como revisor e tambm, de
Um nmero grande de
preferncia, como autor;
participantes inviabiliza a
4. No ter com qualquer um dos revisores alguma dificuldade pessoal produo de bons resul-
que possa interferir em sua habilidade de liderar a reviso. tados em uma reviso.
Assim como o lder, o relator da reviso tambm deve possuir algumas

caractersticas:
1. Compreender o proposito das revises em geral e entender seu
funcionamento;
2. Compreender o jargo e os formatos utilizados neste material; ser
capaz de se comunicar com as pessoas presentes na reviso;
3. Ter participado de alguma outra reviso como revisor ou como autor.
Os demais revisores devem levar em conta os seguintes aspectos

de comportamento:
1. Estar preparado, lendo cuidadosamente o material antes da
reunio;
2. Ter conhecimento tcnico sobre parte do material da reviso;
3. Ser cooperativo;
4. Ser franco em relao ao material da reviso, mas polido em
relao aos autores;
5. Compreender perfeitamente os pontos discutidos;
6. Usar um comentrio positivo e outro negativo;
7. Apontar defeitos, mas no discutir sua resoluo, pois esta no
faz parte da reviso;
8. Evitar discusses sobre detalhes no-pertinentes qualidade do
material em reviso;
9. Limitar-se aos assuntos tcnicos;
10. 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.
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.
preciso deixar muito
Outro ponto chave manter sempre em mente que o objetivo
claro que em uma re- da reviso no detalhar solues, mas apenas apontar problemas e,
viso estamos analisan-
eventualmente, dar sugestes sobre possveis melhorias ao material em
do o trabalho produzido e
no seus produtores. 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 certificar-se
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 a ordem por item analisado. Desta
maneira, em cada etapa a equipe de inspeo ter a ateno focalizada
em um aspecto especfico.
A reunio deve ser iniciada pontualmente; nenhum participante
poder mais entrar apos 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:
48 UNIDADE 01
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, pr-revisados, 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.
4. O lder comanda a realizao da reunio de reviso e envia os relatorios
para o GQ contendo o resultado do material analisado.
5. O GQ faz o pos-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, o qual ser conferido 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 historicos.
Apos 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:
1. Aceitao: indicando que o material foi aceito, embora ainda devam
existir outros procedimentos de controle.
2. 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.
3. 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.
4. Reconstruo: o gerente do projeto investiga as causas dos problemas
detectados, agendando a reconstruo do material, indicando as
provveis falhas para serem observadas.
importante ressaltar que as sugestes apontadas no relatorio

de reviso no precisam ser necessariamente implementadas. Cabem
ao gerente do projeto determinar, entre as alteraes propostas, quais
devem ser realmente executadas, ponderando os aspectos tcnicos,
gerenciais e polticos ouvindo o GQ.
Os Relatorios de Revises devem ser arquivados permanentemente,
sendo importante que cada projeto mantenha seu repositrio.
exerccios propostos
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 levantamento de
requisitos?
8. O que feito no fechamento de uma sesso?
9. O que deve existir em uma ata de uma reunio de levantamento de
requisitos?
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?
50 UNIDADE 01
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?
Referncias da WEB
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
52 UNIDADE 01
UNIDADE 2
Anlise de Software
Resumo
Nesta unidade apresentamos o Fluxo de Anlise. 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 que so detalhadas s atividades
relacionadas disciplina, apresentando em detalhes a Anlise para nosso sistema exemplo,
os quais detalharo 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.
ANLISE DE SOFTWARE 53
ANLISE DE SOFTWARE
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: uma linguagem baseada em diagramas, o que a torna muito
mais simples de usar e entender.
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 a
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.
A Origem da UML
At o surgimento da UML existiam diversos processos de software
e diversas linguagens de modelagem associadas aos processos. Isso
gerava muitos problemas, devido 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:
1. Booch Esse mtodo foi criado por Grady Booch e baseada 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.
2. OMT O Object Modelling Technique foi desenvolvido pelo General
Electric onde o pesquisador James Rumbaugh trabalhava. Os modelos
prescritos pelo mtodo so compostos por modelos de objetos, funcional
e casos de uso.
3. 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 ideias em comum e

diferente. Da mesma forma, eles possuam notaes prprias. A partir
disso, os trs amigos resolveram criar uma 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 ideias 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 necessrio saber
como ela dividida. Nas prximas sees apresentaremos cada uma
das partes da UML: Vises, Modelos de Elementos, Mecanismos Gerais
e Diagramas.
Cada viso foca em um

aspecto particular do Vises
produto sendo modelado.
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:
1. 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.
56 56 UNIDADE 02
2. Viso Lgica: descreve como o 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, sequncia,
colaborao e atividade.
3. Viso de Componentes: descreve a diviso da implementao em
mdulos, demonstrando suas dependncias. Essa viso est diretamente
ligada ao diagrama de componentes.
4.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, colaborao e atividade), alm dos diagramas de
desdobramento.
5.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.
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 modelos de
elementos existentes na UML.
Classes
Uma classe uma representao abstrata de um conceito.
Nessa representao tentamos focar os dados relacionados entidade
que est 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.
Figura 8: Exemplo de Classe.
A Figura 8 exibe um exemplo de classe, chamado Pessoa. Ela

possui diversos atributos (nome, email, telefone, celular, login e senha).
Na classe existe apenas uma operao (salvar). Para ser criada 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 este diagrama, ser exibida uma barra de ferramentas
similar mostrada na Figura 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.
Figura 10: Criao de atributos e operaes para classes.
58 58 UNIDADE 02
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 tem 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, clica-se 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.
Figura 11: Exemplo de um objeto pessoa.
Estados
Os objetos normalmente possuem um estado que 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 bastante expressiva e simples de
ser entendida.
Figura 12: Exemplos de estados para o objeto Livro.
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 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
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.
60 60 UNIDADE 02
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.
Associao
Uma associao cria uma conexo entre as classes 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.
representada por uma linha ligando duas classes, o qual 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, conter dois atributos
de coleo: os membros e os clientes. A maioria das ferramentas UML
permite 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.
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 autoassociao). Conforme especificado,
um membro, denominado 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 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,
62 62 UNIDADE 02
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 uma ideia
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.
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 outro elemento, podendo ainda incluir
comportamento adicional. Nos locais em que esperado um elemento
do tipo 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
A Dependncia uma relao mais fraca entre elementos,
indicando 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, mostrando 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
64 64 UNIDADE 02
e dependente que exibida duas vezes, sendo que 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.
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, especificando uma
regra para a associao de scios e dependentes, utilizando nossa
linguagem natural.
Figura 22: Exemplo de nota em um diagrama.
2.2 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.
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 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
Diagramas de caso de
uso so excelentes para caso, pode-se concluir que um aluno pode reservar um livro, embora
se obter um entendi- no tenhamos detalhes sobre quais so as regras especficas para a
mento rpido sobre um
sistema! reserva. O ator Aluno, nesse caso, representa um 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.
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,
Diagramas de obje- dependncia, etc.). Um sistema real pode conter um nmero grande de
tos podem facilitar o
classes, sendo necessria a criao de diversos diagramas, cada um
entedimento de classes
complexas, a partir da focando em um aspecto especfico. Uma mesma classe pode aparecer
demonstrao de uma
em diferentes diagramas. Nas figuras anteriores foram apresentados
instncia especfica,
onde podemos demon- diversos diagramas de classe para se explicar os mais diferentes
strar alguns aspectos relacionamentos entre classes.
mais difceis de serem
entendidos.
Diagrama de Objetos
O diagrama de objetos descreve uma instncia especfica de um
diagrama de classe. Sua notao bem prxima do diagrama de classe,
porm, importante frisar que ele exibe as instncias das classes com
66 66 UNIDADE 02
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 Clia e Joana. Diversos outros diagramas de
objetos so possveis, desde que eles no violem as restries existentes
no diagrama de classe original.
Figura 25: Diagrama de objetos.
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
Os diagramas de esta-
objetos com ciclos complexos, uma vez que podemos especificar as
dos mostram a dinmica
aes e condies associadas s mudanas de estado. das classes e so
A exibe um diagrama de estados para um objeto Livro. Ele facilmente entendidos
por usurios leigos, a
inicia livre, pronto para ser reservado, emprestado ou tornado cativo e, partir de um mnimo de
dependendo da funo utilizada, pode assumir outros estados. Um livro explicao.
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 acabou no sendo possvel mais nenhuma outra transio de
estados.
Figura 26: Diagrama de estados para o objeto Livro.
Diagrama de Sequncia
O diagrama de sequncia mostra a troca de mensagens entre
objetos durante a implementao de certos comportamentos. O foco
no diagrama de sequncia 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
sequncia das aes invocadas, por isso seu nome.
A Figura 27 exibe um diagrama de sequncia. 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 que est 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 aciona o
mtodo validarCPF do objeto til e salvarObjeto do objeto Persistncia. Fica
clara a ordenao temporal das chamadas.
Diagramas de sequncia 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.
68 68 UNIDADE 02
Figura 27: Exemplo de Diagrama de Sequncia.
Outra aplicao para diagramas de sequncia 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.
Diagrama de Colaborao
O diagrama de colaborao pode ser considerado como outra
forma de exibio do diagrama de sequncia. 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 enfatizada a troca de mensagens entre objetos e no
sua ordem temporal. O diagrama de colaborao pouco utilizado no
desenvolvimento de software, sendo prefervel o diagrama de sequncia.
Por conta disso, no daremos muita nfase a ele neste trabalho.
Diagrama de Atividades
O diagrama de atividades uma variante do diagrama de estados
na UML. Porm, seu objetivo completamente diferente, enquanto os
diagramas de estados exibem o comportamento interno de um objeto,
o diagrama de atividades exibe 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.
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 quem so 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.
Diagrama de Componentes
O diagrama de componentes exibe a relao entre as partes
que compem um sistema e a organizao dos mdulos. Eles podem
70 70 UNIDADE 02
representar classes, pacotes e subsistemas. Esse tipo de diagrama
muito associado exibio da arquitetura de um sistema, deixando
claro como ele est estruturado, alm 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. Da 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.
Diagrama de Implantao
O diagrama de implantao exibe a arquitetura de execuo
de um sistema, detalhando os componentes fsicos que executam no
ambiente de execuo utilizado, sendo possvel detalhar que mdulo
funcionar em qual dispositivo e como ser sua comunicao com outros
dispositivos.
Figura 29.1
Esse tipo de diagrama tambm muito associado exibio da

arquitetura de um sistema, deixando claro como ser organizada sua
execuo.
Consideraes Finais
Neste captulo apresentamos a UML. Essa linguagem atualmente
um padro de facto para a modelagem no mundo. Demonstramos sua
diviso e como utiliz-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.
exerccios propostos
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?
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 a diferena de uma agregao para uma composio?
15.Cite um exemplo prtico 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
72 72 UNIDADE 02
ou relacionado ao seu dia-a-dia.
22. Para que serve o diagrama de componentes?
23. Qual o objetivo do diagrama de implantao?
2.3 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.
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 No existe consenso so-
bre as atividades relacio-
essencial e que provavelmente seja interessante em qualquer processo.
nadas Anlise. Neste
O Fluxo de Anlise inicia pela identificao das classes. Nessa trabalho detalhamos
aquilo que muito til
atividade teremos que traduzir os conceitos relevantes, identificados na
na prtica e presente em
ER em classes, relacionamentos, atributos e operaes. muitos processos.
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 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 aumentar a qualidade e evitar que problemas
se perpetuem no restante das atividades de desenvolvimento.
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 todas 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 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.
No existe uma tcnica
bem estabelecida e recon- Iniciando essa anlise, a partir do caso de uso Cadastro de Projeto,
hecidamente efetiva para a podemos notar a necessidade de termos uma entidade associada a Projeto.
identificao de classes. O
Pela descrio do caso de uso fcil notar que um projeto deve possuir
entendimento do contexto
descrito na ER e o bom uma sigla, descrio e um gerente associado. Aqui cabe uma anlise a
senso apurado so as mel- mais: um gerente ser outra entidade ou pode ser apenas um campo
hores tcnicas existentes!
texto para informao do seu nome? Nossa ideia 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.
74 74 UNIDADE 02
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 o modelo exibido na classe projeto que contm
vrios outros atributos identificados a partir da anlise do caso de uso
Controle de Projetos.
Figura 31: Modelo representando Projeto e Membro.
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 uma 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 adot-la.
Isso exibido na Figura 32.
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 quais 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 como 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 parece 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 necessria 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.
A modelagem das classes at as consideraes acima, nos remete
a um modelo conforme o exibido na Figura 33.
76 76 UNIDADE 02
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 subfluxos. Um fluxo contm seu nome e passos. Fluxos alternativos
contm, alm disso, pr-condies. Isso denota que existe uma
generalizao envolvida nesse relacionamento. Dessa forma, fluxo
algo que contm nome e passos; 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 Reviso. Essa parte tambm possui uma complexidade
associada, no sendo trivial sua anlise e entendimento. Um projeto
pode possuir diversas revises, os quais tm 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 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.
78 78 UNIDADE 02
Figura 35: Modelagem dos aspectos relacionados a reviso.

Observe na Figura 35 o resultado da modelagem dos aspectos
ligados a 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 dois acrescenta
dados novos. Com isso ento, finalizamos a identificao das classes de
entidade. O resultado final dessa Anlise mostrado 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
denominados 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.
Figura 37: Exemplo de classes de fronteira e controle.
80 80 UNIDADE 02
A Figura 37 exibe um diagrama contendo duas classes de fronteira
e uma classe de controle. Essas 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
o mesmo smbolo, j 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 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.
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 regra 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:
1. 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).
2. Projeto: contendo a representao de um projeto e dos seus
membros.
3. Requisitos: contendo os elementos ligados aos requisitos como
os casos de uso, prottipos, atores, fluxos e fluxos alternativos.
4. 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.
Figura 38: Organizao das classes para o ReqG.
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 (sequncia 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.
82 82 UNIDADE 02
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 necessidade de 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 criao de pacotes com os agrupamentos
necessrios, alm da atribuio dos esteretipos necessrios.
Reviso da Anlise
A reviso da anlise o momento de fazermos uma verificao
geral nos diagramas e classes identificadas. A reviso da Anlise 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 um dos
principais itens para a reviso da Anlise e que precisa ser executado
84 84 UNIDADE 02
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.
exerccios propostos
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?
2.4 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
Para se estabelecer esti-
tambm um aumento na sua complexidade, sendo sempre importante mativas de custo e prazo
que eles sejam desenvolvidos o mais rpido possvel, cumprindo sempre para projetos de software,
necessrio ter uma base
um cronograma pr-estabelecido para tal. histrica de custo e prazo
Um problema frequente relacionado ao desenvolvimento de de outros projetos!
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.
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.
Muitas coisas podem ser medidas durante o desenvolvimento de
A produtividade uma software. So exemplos dessas possibilidades: o tamanho do produto,
medida fundamental complexidade, esforo necessrio para sua construo, cronograma,
para realizao de
estimativas. Ela indica a etc. Mas uma importante pergunta que devemos fazer : para que
capacidade de produo necessitamos medir o tamanho de um produto de software? Vrias so
por unidade de tempo.
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 o 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
estimativas. 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.
Dessa forma torna-se claro a necessidade por mensurao, uma
86 86 UNIDADE 02
vez que base para encontrarmos a produtividade que 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:
1. 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 o 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;
2. 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 se encontra- completo. Continuando no
exemplo de uma casa, podemos notar que a casa construda fcil
medi-la em m2, permitindo assim uma fcil comparao entre o que foi
estimado e o que foi realmente feito.
Existem diversas medidas de tamanho que podem ser utilizadas

para software. Dentre elas destacamos:
1. Linhas de cdigo;
2. Pontos de funo;
3. Pontos de caso de uso;
4. 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 para ser
utilizada? 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. No entanto, essa medida no 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
A medida em linhas de c-
digo muito boa: simples, de cdigo no independente de tecnologia: um produto desenvolvido
baixo custo, bem definida. em Java deve ter tamanho diferente de um desenvolvido em Delphi,
Mas ela s pode ser obtida
DEPOIS do produto pronto!
que deve ser diferente de um desenvolvido em Ruby. Isso no uma
Isso impossibilita seu uso caracterstica boa para uma medida.
para estimar a construo
do produto.
Por esses motivos, foram criadas 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.
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 Existindo uma medida independente de tecnologia, possvel analisar
tecnologia. Isso permite
comparar empresas e tec- se a empresa X trabalha de forma mais rpida que a empresa Y,
nologias de forma efetiva! 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). Essa
organizao tem como misso ser reconhecida como lder na promoo
e encorajamento 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
88 88 UNIDADE 02
objetivos principais:
1. Possibilitar a mensurao de funcionalidades que um software
oferece aos seus usurios, de forma independente da tecnologia utilizada
para sua implementao;
2. Criar uma forma de contagem que gere um custo adicional
pequeno, no sendo caro realizar a medio e 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:
1. Determinar o tamanho de uma aplicao j construda, a partir
da funcionalidade nela contida;
2. 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:
1. 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. Isso tambm estimula o prprio usurio e o torna mais ativo no
desenvolvimento.
2. 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.
3. 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.
A contagem de PF
Possuem vrios contextos de uso bem definidos. Iremos tratar disso mais
baseada em 5 elementos:
dados mantidos pela apli- a frente. Por hora, vamos detalhar um pouco melhor como ela funciona.
cao, dados mantidos por
outra aplicao e usados
pela aplicao sendo con- O Processo de Contagem
tada, funes que mudam
dados, funes que con- Muito j falamos sobre APF. Mas como ela funciona exatamente?
sultam dados e realizam Nesta seo trataremos disso. Uma representao dos principais
processamento nesses da-
dos e funes que apenas elementos relacionados contagem de pontos de funo exibido na
consultam dados. Figura 41. Para a contagem temos que levar em considerao cinco
elementos:
1. Arquivo Lgico Interno (ALI) que representa os dados mantidos
pela aplicao.
2. Arquivo de Interface Externa (AIE) que representa dados
utilizados pela aplicao, mas mantidos por outras aplicaes.
3. Entrada Externa (EE) que representa as entradas de dados que
causam mudanas nos ALIs.
4. Sada Externa (SE) que causa a exibio de dados relacionados
aplicao, normalmente exigindo algum tipo de processamento.
5. Consulta Externa (CE) que causa a simples exibio de dados
relacionados aplicao.
90 90 UNIDADE 02
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.
Cada um desses passos ser detalhado nas prximas sees.
Por enquanto, iremos detalhar mais alguns aspectos relacionados
contagem.
De forma geral, existem trs tipos de contagem de PF:
1. 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, ainda no existe ainda.
2. Projeto de evoluo: feita a medida das modificaes de
funcionalidades associadas a uma aplicao existente, ou seja, a
contagem das mudanas em um software que j foi desenvolvido, mas
precisa ser alterado.
3. Aplicao. Est associado medida das funcionalidades
existentes em uma aplicao. Essa medida inicializada quando a
contagem do projeto de desenvolvimento concluda. 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 seja 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 utiliz-lo para estimar o tempo
de desenvolvimento. Isso feito com base em outros projetos conjunto
de aplicaes instaladas. Nesse caso, realizamos uma contagem
apenas para termos o inventrio dos sistemas existentes. Outro
objetivo comparar o tamanho das funcionalidades oferecidas por
produtos concorrentes. Imagine que estamos querendo selecionar
o produto que mais atenda a 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 a 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 aquilo
que o usurio percebe. Assim, analisando a aplicao pela viso do
92 92 UNIDADE 02
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 contagem em Pontos

de Funo (PF). Inicialmente, necessrio identificar todas as funes
existentes na aplicao e 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,
identificando 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:
1. Funes de dados;
2. Funes de transao.
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:
1. Arquivo Lgico Interno (ALI);
2. 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:
1. Usurio da biblioteca;
2. Ttulo;
3. Exemplar;
4. Emprstimo;
5. Reserva.
Os AIEs so similares aos ALIs, com a diferena que 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:
1. Entrada Externa (EE);
2. Sada Externa (SE);
3. Consulta Externa (CE).
Conforme j comentado, uma EE representa alguma funo que
causa algum tipo de mudana em dados mantidos pela aplicao. So
A diferena entre um ALI e exemplo de EE em um sistema de biblioteca o emprstimo de livro, reserva
um AIE simplesmente o
fato que um ALI man- de exemplar, incluso de novo usurio. Cada uma dessas funes deve
tido pela aplicao sendo causar uma alterao em um dado mantido em algum ALI da aplicao.
contada e o AIE no!
Uma SE representa a gerao de dados na forma de um relatrio,
que envolva algum tipo de processamento associado. exemplo 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
94 94 UNIDADE 02
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.
Funo C. Baixa C. Mdia C. Alta

ALI 7 10 15
AIE 5 7 10
EE 3 4 6
SE 4 5 7
CE 3 4 6
Tabela 7: Pesos associados as funes na contagem de PF.
Contagem de funes de dados

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 Para a contagem de um
ALI necessrio identificar
mais processos elementares da aplicao que est sendo contada. o nmero de agrupamen-
Para se identificar ALIs necessrio procurar por grupos de dados tos existentes (TER) e
nmero de campos (TED).
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.
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
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.
TER TED 1-19 20-50 >50

1 Baixa Baixa Mdia
2-5 Baixa Mdia Alta
>5 Mdia Alta Alta
Tabela 8: Tabela para classificao de ALI/AIE.
Os AIEs so, de forma similar aos ALIs, grupo de dados ou

informaes de controle, identificveis pelo usurio e referenciados pela
aplicao. No entanto, eles so mantidos na fronteira de outra aplicao.
Logicamente, por conta disso, tambm devero ser contados de forma
diferente.
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 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
processam dados ou informaes de controle que entram na fronteira de
96 96 UNIDADE 02
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 necessria 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:
1. A lgica de processamento deve ser nica, diferente das lgicas
executadas por outras EEs;
2. O conjunto de elementos de dados identificado diferente
daqueles identificados para outras EEs;
3. O conjunto de ALIs ou AIEs referenciados diferente daqueles
referenciados por outras EEs.
So casos tpicos de uma EE a incluso, alterao ou excluso de
itens em um cadastro, obteno de mensagens e atualizao de arquivos. necessrio contar apenas
No devemos considerar entradas necessrias apenas em funo da os dados que cruzam a
fronteira da aplicao e que
tecnologia empregada e que no contribuem em nada para o usurio,
fazem sentido para o usurio.
nem parte da entrada das consultas que serve apenas para direcionar a Nada de contar entradas
recuperao de dados como so os casos de parmetros de pesquisa e dependentes de tecnologia
e imperceptveis na viso do
nem telas de entrada para fins de navegao como os menus.
usurio.
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).
OsTARs 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.
TAR TED 1-4 5-15 >15
<2 Baixa Baixa Mdia
2 Baixa Mdia Alta
>2 Mdia Alta Alta
Tabela 9: Atribuio de complexidade para EES.
Sada Externa
Uma Sada Externa (SE) um processo elementar da aplicao
que geram 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, sendo 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:
1. Conter pelo menos um clculo ou frmula matemtica;
2. Criar dados derivados;
3. Manter pelo menos um ALI;
4. Alterar o comportamento da aplicao.
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 identificados deve ser
diferente daqueles identificados para outras SEs, assim como o conjunto
de ALIs ou AIEs referenciados tambm devem ser diferentes 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 outra SE. So exemplos tpicos de SEs:
1. Relatrios que consolidam dados atravs de clculos;
2. Telas de exibio de dados que possuam dados derivados;
3. Exibio de grficos com dados calculados;
4. 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
98 98 UNIDADE 02
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 elemento
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:
1. Contar um TAR para cada ALI ou AIE lido durante o
processamento da SE de acordo com os requisitos do usurio;
2. 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;
3. Contar apenas uma vez os ALIs que so tanto lidos quanto
mantidos;
4. 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 especificados. No devemos contar:
1. Numerao de pginas;
2. Campo de data/hora de emisso de relatrio;
3. Literais (strings);
4. Ttulos fixos, nomes de campos, ttulos de colunas, etc;
5. Campos de ALIs mantidos ou consultados, que no cruzem
a fronteira da aplicao;
6. 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.
TAR TED 1-5 6-19 >19
<2 Baixa Baixa Mdia
2-3 Baixa Mdia Alta
>3 Mdia Alta Alta
Tabela 10: Atribuio de complexidade para SES.
Consulta Externa
Uma Consulta Externa (CE) um processo elementar que
recuperam 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:
1. A lgica de processamento nica, diferente daquela executada
por outras CEs;
2. O conjunto de elementos de dados identificado diferente
daqueles identificados para outras CEs;
3. 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:
1. Telas de log-on para autenticao de usurios;
2. Ajuda on line. Nesse caso, cada nvel de ajuda (tela, campo)
conta como uma CE distinta;
3. 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
100100 UNIDADE 02
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.
TAR TED 1-5 6-19 >19

<2 Baixa Baixa Mdia
2-3 Baixa Mdia Alta
>3 Mdia Alta Alta
Tabela 11: Atribuio de complexidade para CES.
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 s 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 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 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.
Contagem de funes de dados

Nossa contagem se inicia pelas funes de dados. Nosso sistema
exemplo, mesmo no sendo complexo, possui diversas classes. Temos
Esta seo apresenta um
que proceder com a contagem desses elementos. Utilizaremos como
exemplo de contagem
estimativa para funes de base o diagrama de classes exibido na Figura 36.
dados. Voc dever fazer Iniciando pela classe Projeto, podemos perceber que ela um ALI
o mesmo para um exemplo
contendo 9 TEDs. Ela no possui nem um agrupamento interno, devendo
escolhido por voc.
cont-la como um ALI com apenas um TER. De acordo com a Tabela 8,
Projeto uma ALI simples.
Continuando pela classe Membro, comeamos a 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
102102 UNIDADE 02
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 outro TER. Com isso, temos
que Membro um ALI que possui 2 TERs. Com relao quantidade de
campo, possumos as seguintes quantidades:
1. Membro possui 4 campos;
2. Usurio possui 2 campos;
3. 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, 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 com
complexidade baixa.
A classe Caso de uso provavelmente o item mais complexo do
exemplo. Ela possui diversos TERs:
1. Caso de uso com 6 campos;
2. Alterao com 1 campo;
3. Prottipo com 2 campos;
4. Fluxos com 2 campos;
5. Fluxos alternativos com 1 campo.
No total, Caso de uso um ALI com 5 TERs 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 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.
Seq. Nome ALI TER TED Complexidade

1 Projeto 1 1 9 Baixa
2 Membro (Usurio, Alterao) 1 2 10 Baixa
3 Requisito (Alterao) 1 2 10 Baixa
4 Ator (Alterao) 1 2 5 Baixa
Caso de uso (Fluxo, Fluxo
5 Alternativo, Prottipo, Alte- 1 5 18 Baixa
rao)
6 Reviso (item de reviso) 1 2 13 Baixa
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.
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, faremos uma contagem bastante
104104 UNIDADE 02
simplificada. Utilizaremos com base para contagem de TEDs apenas
os campos visveis aos 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 De forma similar seo
para EE, SE e CE (Tabela 9, Tabela 10, Tabela 11). anterior, apresentamos
um exemplo de con-
A contagem das funes de transao vai seguir a ordem dos
tagem estimativa para
casos de uso na Especificao de Requisitos do ReqG. O primeiro caso
funes de transao.
de uso o Cadastro de Projeto. A pesquisa por projeto faz com que 2 Voc dever fazer o
campos cruzem a fronteira do sistema. Esses campos so de dois ALIs mesmo para um exemplo
diferentes: Projeto e Membro (gerente). Assim, a pesquisa uma CE que escolhido por voc.
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 das 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.
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 tm referncia 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 enviada e cruza a fronteira da aplicao.
Assim, no devemos contar os campos que no cruzam a fronteira da
aplicao.
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 e alterao
referenciam Projeto, Reviso, Critrio, Requisitos, Caso de uso e Membro.
A funo Reabertura apenas altera um campo de Reviso, indicando se
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 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
106106 UNIDADE 02
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 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.
Tabela 13: Resumo da contagem de funes de transao.

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.
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
O uso de APF permite
o acompanhamento da em pontos de funo : Produtividade = PF/PM (ponto de funo por
produtividade, bem como pessoa-ms). Mas como calcular isso? Basta contar quantos pontos de
seu uso para a realizao
funo foram desenvolvidos por uma equipe em um ms de trabalho. Se
de estimativas de custo e
esforo. 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.
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, gerando um problema. Um exemplo a comunicao:
grandes equipes tm 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
108108 UNIDADE 02
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.
Viso crtica da APF

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:
1. 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.
2. 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 indicado
como mtrica para clculo da produo e definio de pagamentos.
3. 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.
4. Podem ser usados para comparaes. Com o uso do APF
podemos comparar a efetividade de tecnologias diferentes (Java x
Delphi), alm de permitir a comparao de empresas (A x B), analisando
quem produz mais em menos tempo.
5. 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.
6. Frum para troca de informao. Existem muitos fruns para
eliminao de dvidas associados com respostas efetivas e em tempos
reduzidos.
No entanto, mesmo tendo essas vantagens, existem diversas
desvantagens associadas.
1. 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.
2. Contagem no pode ser facilmente automatizada. Existe muita
interpretao associada contagem de PF. Isso dificulta sua automao
por completo, visto que essas interpretaes so difceis de serem
automatizadas por completa.
3. Existem variantes do mtodo. Existem algumas variaes do
mtodo que utilizam 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.
4. 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, recuperao da informao, no so
adequadas. Assim, qualquer aplicao em contextos diferentes requer
A APF possui vrias van- adaptaes para os produtos a serem contados.
tagens e desvantagens
5. A contagem rigorosa difcil. Existem muitas regras associadas.
associadas. No entanto,
ela ainda uma forma Por conta disso fizemos uma contagem bastante simplificada. As regras
muito utilizada no mundo. so muito extensas e difceis de serem seguidas em detalhes.
6. Requer profissional especializado. Uma contagem detalhada
exige um profissional 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:
1. 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 para sua construo. No previsto o
reuso de componentes, de cdigo legado, de cdigo herdado de verses
anteriores.
2. difcil seu uso para contagem de alteraes de requisitos.
110110 UNIDADE 02
3. 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 as medidas
para controlar nosso trabalho. Como foi dito pelo famoso escritor Tom
DeMarco: No se consegue controlar o que no se consegue medir.
exerccios propostos
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?
5. Por que linhas de cdigo no so utilizadas 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 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.
22. Como podemos utilizar APF para estimar um projeto?
23. Cite vantagens e desvantagens do uso de APF.
112112 UNIDADE 02
Referncias da WEB
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/

UNIDADE 3
Exemplo 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.
EXEMPLO DE ARTEFATOS 115

Exemplo de Especificao
de Requisitos
Anexo
Fictcia Solues em Informtica
Especificao dos Requisitos

do Software ReqG 1.0
Autores: Equipe Fictcia

Teresina - PI
Dezembro de 2010
Aprovao
Aprovamos o documento de Especificao de Requisitos do projeto ReqG

1.0.
Responsvel Instituio Data Assinatura

Gildsio Guedes
UAPI 08/12/2010
Fernandes
Lus Cludio
Demes da Mata UAPI 08/12/2010
Souza
Pedro de Alcn-
FICTCIA 08/12/2010
tara dos S. Neto
Verses revisadas anteriores
Responsvel Verso Data Descrio

Pedro de Alcntara dos Finalizao da verso
1.0 07/12/2010
S. Neto inicial.
Especificao dos Requisitos do Software

Gerenciador de Requisitos 1.0
Sumrio
Introduo................................................................................................. 119
Nome do produto....................................................................................... 119
Escopo do produto.................................................................................... 119
Limites do produto..................................................................................... 119
Definies e siglas....................................................................................120
Definio dos Requisitos........................................................................... 120
Requisitos Funcionais............................................................................... 142
Requisitos No-Funcionais....................................................................... 121
Detalhamento dos Requisitos................................................................... 121
Diagrama de contexto............................................................................... 121
Casos de uso............................................................................................122
Atores........................................................................................................123
118 UNIDADE 03
Especificao dos Casos De Uso............................................................. 123
Cadastro de Projeto..................................................................................123
Gesto de Gerentes.................................................................................. 125
Gesto de Membros.................................................................................. 127
Controle de Projetos.................................................................................. 130
Gesto de Requisitos................................................................................ 131
Gesto de Atores.......................................................................................134
Gesto de Casos de Uso......................................................................... 135
Gesto de Critrios.................................................................................. 139
Reviso.................................................................................................... 141
Gerao da Especificao....................................................................... 145
Relatrio de Acompanhamento................................................................ 146
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
Java Server Faces. Tecnologia para
1. JSF construo da camada de apresenta-
o de um sistema Web.
Framework para persistncia de da-
2. Hibernate
dos em Java.
Banco de dados livre bastante popular
3. MySQL
no mundo.
Definio dos Requisitos

Requisitos Funcionais
O sistema deve permitir cadastrar
e controlar todos os aspectos
relacionados aos requisitos de um
RF1 Requisitos projeto, permitindo visualizar isso e
acompanhar sua evoluo, incluindo
as pessoas que trabalharam no projeto,
os analistas e gerente do projeto.
O sistema deve possibilitar a
especificao dos casos de uso,
registrando sua descrio, atores,
RF2 Casos de uso
prottipos de tela associados,
relacionando aos requisitos que deram
origem ao caso de uso.
Deve ser possvel realizar uma
reviso dos requisitos e casos de uso,
RF3 Reviso utilizando critrios definidos pelos
prprios gerentes de projetos, de forma
independente aos demais projetos.
Deve ser possvel que os clientes
possam acompanhar a evoluo
RF4 Acompanhamento dos clientes
do projeto a qualquer momento,
consultando tudo o que foi feito.
Deve ser possvel liberar o acesso ao
sistema por projeto, indicando o seu
gerente. Assim, para se ter acesso
ao sistema, dever ser adquirido uma
licena para um projeto. A partir disso,
o gerente ficar responsvel por definir
RF5 Liberao de acesso por projeto
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.
Deve ser possvel gerar a especificao
RF6 Gerao da documentao na forma de um documento, contendo
todos os dados registrados do projeto.
120 UNIDADE 03
Requisitos No-Funcionais
O sistema deve funcionar em ambiente
Web, sendo compatvel com os
RNF1 Ambiente principais navegadores do momento:
Internet Explorer, Firefox, Safari e
Chroma.
O sistema deve ser desenvolvido
RNF2 Linguagem utilizando-se a linguagem Java com as
tecnologias JSF e Hibernate.
O sistema deve utilizar o banco de
RNF3 Banco de dados
dados MySQL.
O sistema deve ser construdo
para funcionar com 100 usurios
RNF4 Desempenho
simultneos com respostas de at 5s
quando utilizado em rede local.
O sistema deve restringir o acesso
por meio de senhas. Deve-se ter
RNF5 Segurana um controle no registro de senha
de forma a impedir o uso de senhas
consideradas fceis.
Um usurio com conhecimento bsico
em informtica e conhecimento nos
RNF6 Usabilidade conceitos de requisitos deveria ser
capaz de operar o sistema com um
curso de 30 minutos.
Detalhamento dos Requisitos

Diagrama de contexto

Casos de uso
ID Caso de Requisito associado Descrio

uso
Cadastro de requisitos fun-
Gesto de
UC1 RF1 cionais e no funcionais as-
Requisitos
sociados ao projeto.
Gesto de Cadastro de todos os en-
UC2 RF1
Membros volvidos no projeto.
Gesto de
Definio dos casos de uso
UC3 Casos de RF2
do projeto.
Uso
Gesto de Definio dos atores que iro
UC4 RF2
Atores interagir no projeto.
Reviso de um requisito ou
de um caso de uso, obser-
UC5 Reviso RF3 vando os critrios pr-esta-
belecidos no projeto para a
reviso.
Gesto de
Cadastro de critrios a serem
UC6 Critrios de RF3
utilizados em uma reviso.
Reviso
Cadastro de um projeto com
Cadastro de definio do seu gerente
UC7 RF5
Projeto feito pelo administrador do
sistema.
Cadastro de um gerente de
Gesto de
UC8 RF5 projeto feito pelo administra-
Gerentes
dor do sistema.
Controle do projeto, com de-
Controle de talhamento de informaes
UC9 RF5
Projetos sobre o mesmo feito pelo ge-
rente do projeto.
Gerao da especificao de
Gerao da requisitos, utilizando um for-
UC10 especifica- RF6, RF4 mato pr-definido, contendo
o todos os dados registrados
no projeto.
Emisso de um relatrio
Relatrio de contendo uma indicao do
UC11 Acompanha- RF4, RF6 estado do projeto, a partir do
mento estado de cada caso de uso
que o compe.
122 UNIDADE 03
Atores
N Ator Descrio
Clientes de um projeto, normalmente respon-
4. Cliente svel pelo fornecimento de informaes para
moldagem do produto.
Responsvel pelo controle do uso do sistema,
5. Administrador liberando acesso aos Gerentes a partir do ca-
dastramento de um projeto.
Responsvel pelo controle de um projeto, de-

6. Gerente
finindo a equipe e suas tarefas.
Pessoa que faz parte da equipe que trabalha

7. Membro
no projeto.
Tcnico com formao em Engenharia de Soft-
ware, capaz de identificar e descrever requi-
Engenheiro de Req-
8. sitos, utilizando as prescries de Engenharia
uisito
de Requisitos existentes e implementadas no
sistema.
Especificao dos Casos De Uso

Cadastro de Projeto
Prottipo de Tela de Cadastro de Projetos
Cadastro de Projetos
Pesquisa por Projetos
Nome SystemG (texto com at 30 caracteres)
Gerente Silio Silvestre Ferreira Freitas (Texto com at 100 caracteres)
<Pesquisar>
Sigla Gerente
SystemG Silio Silvestre Ferreira Freitas
Frigo Alberto Sobrinho Arajo
TecnoComp Silio Silvestre Ferreira Freitas
<Novo><Alterar><Visualizar><Excluir>
Dados do Projeto
Sigla* ReqG 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
Pr-condies
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

Pr-condies 1- O Administrador acionou o comando Novo.
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.
Passos
4. O ReqG salva os dados do projeto.
5. O ReqG envia um email ao gerente do projeto informando o
cadastramento do projeto.
Fluxo alternativo Alterao de um Projeto

1. O Administrador selecionou um Projeto na lista de Projetos Recu-
perados.
Pr-condies
2. O Administrador acionou o comando Alterar.
1. O ReqG recupera e exibe Dados do Projeto.

2. O Administrador altera os Dados do Projeto que desejar.
Passos 5. O ReqG verifica que no existe um projeto com sigla informada.
7. O ReqG envia um email ao gerente do projeto informando a alter-
ao no projeto.
124 UNIDADE 03
Fluxo alternativo Visualizao de Dados de um Projeto
1. O Administrador selecionou um projeto na lista de Projetos Recu-

perados.
Pr-condies
2. O Administrador acionou o comando Visualizar.
1. 1. O ReqG recupera e exibe os Dados do Projeto somente para

Passos
leitura.
Fluxo alternativo Excluso de um Projeto

1. O Administrador selecionou um projeto na lista de Projetos Recu-
Pr-condies perados.
2. O Administrador acionou o comando Excluir.
1. O ReqG verifica que no h dados associado ao projeto selecio-
nado, como requisitos, casos de uso, membros e revises.
2. O ReqG exclui o projeto selecionado.
Passos
3. O ReqG envia um email ao gerente do projeto informando a
excluso do projeto.
Gesto de Gerentes
Prottipo de Tela de Gesto de Gerentes
Gesto de Gerentes
Pesquisa por Gerentes
Nome Silio Silvestre Ferreira Freitas (texto com at 100 caracteres)
Projeto Ferrare 1.0 (texto com at 30 caracteres)
<Pesquisar>
Gerentes recuperados
Nome Login Email Projeto
Silio
Silvestre
Silio siliosffreitas@gmail.com Ferrare 1.0, ReqG 1.0
Ferreira
Freitas
Joo
Jos
Almeida jj jjacavalcante@hotmail.com Genesis 2.0
Caval-
cante
Dados do Gerente
Nome* Silio Silvestre Ferreira Freitas (texto com at 100 caracteres)
Email* siliosffreitas@gmail.com (email vlido)
Telefone (86) 3224-3678 (texto at 100 caracteres)

Login* siliosffreitas (texto at 20 caracteres)
Senha* 12345678 (texto at 20 caracteres)
<Salvar>
Pr-condies
No aplicvel.
Fluxo principal
4. O ReqG exibe a Tela de Gesto de Gerentes.
5. O Administrador informa os dados para pesquisa por Gerentes.
7. 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

Pr-condies 8. O Administrador acionou o comando Novo.
9. O Administrador preenche os Dados do Gerente.
11. O ReqG verifica que no existe um Gerente com email e login
Passos
informados.
12. O ReqG salva os Dados do Gerente.
Fluxo alternativo Alterao de um Gerente

1. O Administrador selecionou um Gerente na lista de Gerentes recu-
perados.
Pr-condies
2. O Administrador acionou o comando Alterar.
1. O ReqG recupera e exibe Dados do Gerente.

2. O Administrador altera os Dados do Gerente que desejar.
Passos 4. O ReqG verifica que no existe um Gerente com email e login
informados.
5. O ReqG salva os Dados do Gerente.
126 UNIDADE 03
Fluxo alternativo Visualizao de Dados de um Gerente
1. O Administrador selecionou um Gerente na lista de Gerentes
recuperados.
Pr-condies
2. O Administrador acionou o comando Visualizar.
1. O ReqG recupera e exibe os Dados do Gerente somente para

Passos
leitura.
1. Fluxo alternativo Excluso de um Gerente

1. O Administrador selecionou um Gerente na lista de Gerentes
recuperados.
Pr-condies
2. O Administrador acionou o comando Excluir.
1. O ReqG verifica que no h nenhum projeto que tenha o Ge-

rente selecionado como Gerente do projeto.
Passos
2. O ReqG exclui o Gerente selecionado.
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)
[Analista, Programador, Designer, Arquiteto de Software, Fornecedor
Cargo
de Requisitos]
<Pesquisar>
Membros do Projeto
Nome Email Projeto Telefone Papel
Ferrare
Pedro Pedro@email.com (12) 1212-1212 Analista
1.0
Quantum
Lucas lucassld@gmail.com (23) 3443-3433 Design
2.0
Adriana Adriana12@hotmail.com XMen 1.1 (34) 4554-5445 Programador
Dados do Membro
Nome* Thiago Alves (texto com at 100 caracteres)
Email* tt@gmail.com (email vlido)
Telefone (086) 9999-9999 (telefone vlido)
Papel* Cliente; Engenheiro de Requisitos
Login Thiago (texto com at 20 caracteres)
Dados do Membro
Senha* Senha (texto com at 20 caracteres)

[Lista de projetos pr-cadastrados no sistema e associados ao usurio cor-
rente]
Projeto* ...
[Lista de projetos pr-cadastrados no sistema e associados ao usurio cor-
rente
<Salvar>

Pr-condies
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

Pr-condies 1.O Gerente acionou o comando Novo.
1. O Gerente preenche os Dados do Membro.
2.O Gerente aciona o comando Salvar.
3. O ReqG verifica que no existe um membro cadastrado com login e
email informados.
Passos
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

1.O Gerente selecionou um Membro na lista de Membros Re-
cuperados.
Pr-condies
2. O Gerente acionou o comando Alterar.
1. O ReqG recupera e exibe Dados do Membro.

2. O Gerente altera os Dados do Membro que desejar.
3. O Gerente aciona o comando Salvar.
4. O ReqG verifica que no existe um membro com login e email
Passos
informados.
5. O ReqG salva os dados do Membro.
6. O ReqG envia um email para o membro informando as alteraes.
128 UNIDADE 03
Fluxo alternativo Visualizao de Dados de um Membro
1. O Gerente selecionou um Membro na lista de Membros Recuperados
Pr-condies
2. O Gerente acionou o comando Visualizar.
1.O ReqG recupera e exibe os Dados do Membro somente para

Passos leitura.
Fluxo alternativo Excluso de um Membro

1. O Gerente selecionou um Membro na lista de Membros Recuperados
Pr-condies
2. O Gerente acionou o comando Excluir.
1. O ReqG verifica se que o Membro no trabalhou no projeto,

fornecendo informaes a respeito do levantamento de requisi-
tos tais como registrando requisitos, detalhando casos de uso,
Passos prottipos, realizando revises, etc..
2. O ReqG exclui o Membro selecionado.
Controle de Projetos
Prottipo de Tela de Controle de Projetos
Controle do Projeto
Pesquisa por projetos
Projeto Estocando (texto com at 30 caracteres)
<Pesquisar>
Sigla Gerente
SystemG Silio Silvestre Ferreira Freitas
Frigo Alberto Sobrinho Arajo
TecnoComp Silio Silvestre Ferreira Freitas
<Alterar><Visualizar>
Dados do Projeto
Projeto SystemG
Gerente Silio Silvestre Ferreira Freitas
Sistema de apoio e controle de requisitos (texto com at
Escopo*
2000 caracteres)
Diagrama de Contexto SystemG_DiagramaContexto.jpg (Imagem)
O sistema no ter monitoramento on line (rea de texto com at
Limites do produto
2000 caracteres)
Instituio responsvel
Ficttica Solues em Informtica (texto com at 100 caracteres)
pela execuo

Instituio cliente Biriba Comrcio (texto com at 100 caracteres)
12/05/2009 (data passada ou atual vlida no formato dd/mm/
Data de incio*
aaaa)
Data de Trmino 12/05/2011 (data futura vlida no formato dd/mm/aaaa)
Membros do Projeto
Nome Email Projeto Celular Cargo
Pedro@email. Ferrare
Pedro com 1.0 (12) 1212-1212 Analista
lucassld@ Quantum
Lucas gmail.com 2.0 (23) 3443-3433 Design
Adriana12@ Programa-
Adriana hotmail.com XMen 1.1 (34) 4554-5445 dor
<Salvar>
Pr-condies
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.
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, orde-
nados 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
Gesto de Requisitos
Pesquisa por requisitos
Requisito Linguagem (texto com at 30 caracteres)
<Pesquisar>
Requisitos recuperados
130 UNIDADE 03
Nome Descrio Prioridade Projeto
Desenvolvido em
Linguagem Java Alta Ferrare 1.0
Java
Gesto de Proje- Gesto de
Mdia Quantum 2.0
tos Projetos
Reviso dos
Reviso Baixa XMen 1.0
Requisitos
Dados do Requisito
Identificador* RF1 (formato RFn para funcionais ou RNFn para no fun-
cionais, onde n o prximo nmero natural no associado
a um requisito)
Nome* Linguagem Java (texto at 100 caracteres)
Descrio* O Sistema deve ser desenvolvido em Java para a Web
(texto at 2000 caracteres)
Tipo* [Funcional; No Funcional]
Prioridade* [Alta; Mdia; Baixa]
Complexidade* [Alta; Mdia; Baixa]
Situao* [Identificado; Detalhado; Implementado; Homologado]
<Salvar>
Histrico de Alterao
Data Responsvel Papel Email
10/05/2010 Joaquim Parente Analista joa@gmail.com
15/05/2010 Astulfo Alves Analista astoa@gmail.com
10/07/2010 Silio Silvestre Gerente silio@gmail.com

Pr-condies
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 cor-
rente, ordenados pelo Nome em ordem crescente.

Fluxo alternativo Incluso de Novo Requisito
Pr-condies 1. O Engenheiro de Requisitos acionou o comando Novo.
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 requi-
sitos 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
Passos
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

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

2. O Engenheiro de Requisitos altera os Dados do Requisito que de-
sejar.
4. ReqG verifica que todos os casos de uso relacionados ao requisito
Passos
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

Pr-condies
2. O Engenheiro de Requisitos acionou o comando Visualizar.
1. O ReqG recupera e exibe os Dados do Requisito somente para

Passos leitura.
Fluxo alternativo Excluso de Requisito

Pr-condies
2. O Engenheiro de Requisitos acionou o comando Excluir.
132 UNIDADE 03
1. O ReqG verifica que no existe nenhum caso de uso ou reviso
associado ao Requisito.
Passos
2. O ReqG exclui o requisito selecionado.
Gesto de Atores
Prottipo de Tela de Gesto de Atores
Gesto de Atores
Pesquisa por Ator
Ator Gerente(texto com at 30 caracteres)
<Pesquisar>
Atores recuperados
Nome Descrio Caso de Uso Projeto
Usurio que abre e fecha
Caixeiro UC6,UC8 Estocando
compra
Fiscaliza entrada e sada
Fiscal de ponto UC1 Estocando
de
Reviso Reviso dos Requisitos UC2 Ferrare 1.0
Dados do Ator
Nome* Caixeiro (texto at 50 caracteres, nico)
Responsvel pela venda de mercadorias (texto at 100 carac-
Descrio*
teres)
[Lista de caso de uso cadastrado no projeto]
Caso de uso
...
associado*
[Lista de caso de uso cadastrado no projeto]
<Salvar>
Histrico de Alterao

Pr-condies
O usurio corrente deve ser um Engenheiro de Requisitos ou o Gerente do Projeto.

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 par-
metros de pesquisa informados e que tenham como Membro no projeto o usurio corrente,
ordenados pelo Nome em ordem crescente.
Fluxo alternativo de Alterao do Ator

1. O Engenheiro de Requisitos selecionou um Ator na lista de Atores
recuperados.
Pr-condies
2. O Engenheiro de Requisitos acionou o comando Alterar.
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
Passos
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.
Pr-condies
2. O Engenheiro de Requisitos acionou o comando Visualizar.
1. O ReqG recupera e exibe os Dados do Ator somente para leitura.

Passos
Fluxo alternativo Excluso de Ator

recuperados.
Pr-condies
2. O Engenheiro de Requisitos acionou o comando Excluir.
1. O ReqG verifica que o ator no est associado a nenhum caso de

uso.
Passos 2. O ReqG exclui o ator selecionado.
.
Gesto de Casos de Uso

Prottipo de Tela de Gesto de Casos de Uso
Gesto de Casos de Uso
Pesquisa por Casos de Uso
134 UNIDADE 03
Caso de uso Criao de Projetos (texto at 30 caracteres)
<Pesquisar>
Casos de Uso recuperados
Nome Descrio Requisitos Projeto
Gesto de
Criao de Projetos RF01,RF03 Estocando
Projetos
Controle de Gerentes por
Gesto de Gerentes RF01 Estocando
um projeto.
Controle de membros de
Gesto de Membros RF02 Ferrare 1.0
uma equipe
Dados do Caso de Uso
UC1 (formato UCn, onde n o prximo nmero natural no as-
Identificador*
sociado a um caso de uso)
Nome* Cadastrar Projeto (texto at 100 caracteres)
Cria a conta no sistema para o gerenciamento dos requisitos de
Descrio*
um projeto (texto at 2000 caracteres)
[Lista de atores pr-cadastrados para o projeto]
Ator* ...
[Lista de atores pr-cadastrados para o projeto]
Prioridade* [Alta; Mdia; Baixa]
Complexidade* [Alta; Mdia; Baixa]
Situao* [Identificado; Detalhado; Implementado; Homologado]
Fluxo Principal
Usurio logado no Sistema como Gerente (Texto com at 500 car-
Pr-condio*
acteres)
O ReqG exibe a Tela de Gesto de Casos de Uso.
O ReqG recupera e exibe todos os casos de uso cadastrados.
Passos*
(rea de texto com at 2000 caracteres)
Fluxo Alternativos
Nome Pr-condies Passos
O ReqG faz isso.
Incluso de caso de O usurio acionou o co- O ReqG faz aquilo.
uso mando novo. ReqG salva tudo.
Excluso de caso de O usurio acionou o co-

O ReqG remove tudo.
uso mando excluir.
<Adicionar fluxo><Excluir fluxo>
Subfluxos
Nome Passos
O ReqG faz isso.
O ReqG faz aquilo.
Atualizao de algo
ReqG salva tudo.

O ReqG faz isso.
O ReqG faz aquilo.
Atualizao de algo
ReqG salva tudo.
Dados Subfluxos
Incluso de usurio (texto com at 100 caracteres, nico por pro-
Nome*
jeto)
O ReqG exibe a Tela de Gesto de Casos de Uso.
O ReqG recupera e exibe todos os casos de uso cadastrados.
Passos*
(rea de texto com at 2000 caracteres)
<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
Tela de incluso de usurio (texto com at 100 caracteres, nico
Nome*
por projeto)
Arquivo* Tela.jpg (arquivo com imagem)
<Adicionar prottipo><Excluir prottipo>
<Salvar>
Histrico de Alterao

Pr-condies
O usurio corrente deve ser um Engenheiro de Requisitos ou o Gerente
do Projeto.
136 UNIDADE 03
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.
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

1. O Engenheiro de Requisitos acionou o comando
Pr-condies
Novo.
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.
Passos 4.O Engenheiro de Requisitos aciona o comando Salvar.
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
1. O Engenheiro de Requisitos acionou o comando
Novo.
Pr-condies
2. O Engenheiro de Requisitos acionou o comando Al-
terar.

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.
4. O Engenheiro de Requisitos aciona o comando Sal-
Passos var.
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
1. O Engenheiro de Requisitos selecionou um Caso de

Pr-condies Uso na lista de Casos de Uso recuperados.
2. O Engenheiro de Requisitos acionou o comando Vi-
sualizar.
1. O ReqG recupera e exibe os Dados do Caso de Uso
Passos
somente para leitura.
Fluxo alternativo Excluso de Caso de Uso
1. O Engenheiro de Requisitos selecionou um Caso de

Pr-condies Uso na lista de Caso de Uso recuperado.
2. O Engenheiro de Requisitos acionou o comando Ex-
cluir.
1. O ReqG solicita confirmao da excluso.

Passos
2. O ReqG exclui o caso de uso.
138 UNIDADE 03
Gesto de Critrios
Prottipo de Tela de Critrios
Gesto de Critrios
Pesquisa por Critrios
Projeto Estocando (texto at 30 caracteres)

Critrio 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 Requisito
sentido semntico
Ferrare 1.0 Clareza Apresenta uma interpreta- Requisito
o direta e clara
ReqG 1.0 Completude O Caso de uso est com- Caso de uso
pleto
Dados do Critrio
Projeto [Lista de Projetos cadastrados e que o usurio corrente Membro]

Nome* Ambigidade (texto at 50 caracteres)
Descrio* Apresenta mais de um sentido (texto at 2000 caracteres)
Tipo* [Requisito; Caso de Uso]
<Salvar>

Pr-condies
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
rente, ordenados pelo Nome em ordem crescente.
Fluxo alternativo Incluso de Novo Critrio

Pr-condies 1. O Gerente acionou o comando Novo.

1. O Gerente preenche os Dados do Critrio.
Passos 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

1. O Gerente selecionou um Critrio na lista de Critrios recuperados.
Pr-condies 2. O Gerente acionou o comando Alterar.
1. OReqG recupera e exibe Dados do Critrio.

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

Pr-condies 2. O Gerente acionou o comando Visualizar.
1. O ReqG recupera e exibe os Dados do Critrio somente para lei-

Passos
tura.
Fluxo alternativo Excluso de Critrio

Pr-condies
2. O Gerente acionou o comando Excluir.
1. O ReqG verifica que no existe nenhuma reviso cadastrada e que
utilize o critrio.
Passos
2. O ReqG exclui o Critrio selecionado.
Reviso
Prottipo de Tela de Reviso
Reviso
Pesquisar por Revises
Reviso Reviso preliminar de levantamento (texto com at 30 caracteres ).
<Pesquisar>
140 UNIDADE 03
Revises recuperadas
Projeto Identificador da Reviso Data
SystemG 1.0 Reviso preliminar de levantamento de 31/10/2009
requisitos
SystemG 1.0 Reviso final de detalhamento de requisitos 31/11/2009
SystemG 2.0 Reviso preliminar de levantamento de 17/10/2010
requisitos
SystemG 2.0 Reviso final de detalhamento de requisitos 14/11/2010
ProjetoX 1.0 Reviso inicial de requisitos 12/12/2010
<Nova Reviso><Alterar Reviso><Visualizar Reviso><Reabrir reviso>
Dados da Reviso
Projeto* [Lista de Projetos que possuem o usurio corrente como membro]
Identificador* Reviso preliminar de requisitos (texto at 50 caracteres)
Descrio* Reviso preliminar de requisitos (texto at 50 caracteres)
Data* 12/12/2010 (data no formato dd/mm/aaaa)
Participantes dos
...
desenvolvedores*
Participantes dos ...

clientes
Situao* Situao* [Aberta; Fechada]

Requisitos/Casos de uso Avaliados
Requisito/Caso de Critrio Atende? Observaes
uso
Banco de dados Ambuiguidade Sim -
Clareza No No ficou claro o
banco a ser uti-
lizado.
Preciso No No foi definida com
preciso a verso
do banco a ser
utilizado.
Gesto de membros Ambuiguidade Sim -
Clareza Sim -
Preciso Sim -
Reviso 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 [Lista de requisitos cadastrados no projeto]
avaliado
Critrio Atende? Observaes
Ambuiguidade [sim; no] (texto com at 100
caracteres)
Clareza [sim; no] (texto com at 100
caracteres)
Preciso [sim; no] (texto com at 100
caracteres)
<Adicionar Avaliao de Requisito>
Avaliao de Critrios para Casos de Uso
Caso de uso a ser [Lista de Casos de uso cadastrados no projeto]
avaliado
Critrio Atende? Observaes
Ambuiguidade [sim; no] (texto com at 100
caracteres)
Clareza [sim; no] (texto com at
100 caracteres)
Preciso [sim; no] (texto com at
100 caracteres)
<Adicionar Avaliao de Caso de uso>
<Salvar>

Pr-condies
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
rente, ordenados pelo Projeto e Identificador da reviso em ordem crescente.
142 UNIDADE 03
Fluxo alternativo Incluso de Nova Reviso
Pr-condies 1. O Engenheiro de Requisito acionou o comando Nova Reviso.
Passos 1. O Gerente preenche os Dados da Reviso
2. Para cada Requisito a ser avaliado:
1. O ReqG executa o Subfluxo Avaliao de Requisito.
3. Para cada Caso de uso a ser avaliado:
1. O ReqG executa o Subfluxo Avaliao de Caso de uso.
4. Se desejar excluir alguma avaliao de requisito ou caso de uso:
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
alguma 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 crit-
rios associados a casos de uso cadastrados no projeto.
3. O Engenheiro de Requisitos informa se o critrio foi atendido e, se desejar, preenche
alguma 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.
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

1. O Engenheiro de Requisitos selecionou uma Reviso da Lista
de Revises recuperadas.
2. O Engenheiro de Requisitos acionou o comando Alterar Re-
Pr-condies
viso.
3. A Reviso no se encontra no estado fechado.

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 Gerentepreenche os Dados da Reviso.
3. Para cada Requisito a ser avaliado:
1. O ReqG executa o Subfluxo Avaliao de Requisito.
4. Para cada Caso de uso a ser avaliado:
1. O ReqG executa o Subfluxo Avaliao de Caso de uso.
Passos 5. Se desejar excluir alguma avaliao de requisito ou caso de
uso:
1. O ReqG executa o Subfluxo
7. O ReqG verifica que no existe uma reviso cadastrada para o
projeto com o mesmo identificador.
8. O ReqG salva os dados da Reviso.
Fluxo alternativo Visualizao de Reviso

Pr-condies 1. O Engenheiro de Requisitos selecionou uma Reviso da Lista de
Revises recuperadas.
2. O Engenheiro de Requisitos 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

1. O Engenheiro de Requisitos selecionou uma Reviso da Lista de
Revises recuperadas.
2. O Engenheiro de Requisitos acionou o comando Reabrir Reviso.
Pr-condies
3. A Reviso encontra-se no estado fechado.
1. O ReqG altera o status da reviso para Aberta.

Passos 2. O ReqG salva os dados da Reviso.
Prottipo de Tela de Gerao da Especificao
Gerao da Espe- SystemG (texto com at 30 caracteres)
cificao
Informaes do Silio Silvestre Ferreira Freitas (Texto com at 100 caracteres)
Projeto
<Pesquisar>
144 UNIDADE 03
SystemG Criao de um sistema X Silio Silvestre Fer-
reira Freitas
Frigo Projeto muito interessante Alberto Sobrinho
Arajo
TecnoComp Manuteno de algo Silio Silvestre Fer-
reira Freitas
<Gerar Especificao>

Pr-condies
No aplicvel.
Fluxo principal
O ReqG exibe a Tela de Gerao da Especificao.
rente, 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.
Relatrio de Acompanhamento
Prottipo da Tela de Relatrio de Acompanhamento
Gerente Silio Silvestre Ferreira Freitas (Texto com at 100 caracteres)
<Pesquisar>
Silio Silvestre Fer-
SystemG Criao de um sistema X
reira Freitas
Alberto Sobrinho
Frigo Projeto muito interessante
Arajo
Silio Silvestre Fer-
TecnoComp Manuteno de algo
reira Freitas
<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%)
acompanhamento 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%)
acompanhamento 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%

Pr-condies
No aplicvel.
146 UNIDADE 03
Fluxo principal
O ReqG exibe a Tela de Relatrio de Acompanhamento.
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, calcu-
lado 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 Ho-
mologado (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.
Se no:
O ReqG calcula o percentual de concluso do requisito a partir do estado do requi-
sito.
O ReqG calcula o percentual de concluso do projeto a partir da soma de todos os per-
centuais dos requisitos divididos pela quantidade de requisitos existentes.
ANEXO II Exemplo de Agenda de Oficina de Levantamento de Requi-

sitos
Agenda de Oficina de Levantamento de Requisitos
Projeto NomeDoProjeto
Data: Horrio: Local:

10/05/10 11:00 - 11:30h Nome Local:
Participante do Cliente: Nome do Desenvolvedor 1
Nome do Desenvolvedor 2
Participante do Desenvolvedor: Nome do Cliente 1

Nome do Cliente 2
Nome do Cliente 3
Pauta Prevista:
N Assunto Descrio
1. Apresentao inicial Apresentao do calendrio (programa-
o de datas e pautas) das oficinas;

1 Apresentao inicial Apresentao do cronograma do levan-
tamento inicial e detalhamento dos req-
uisitos.
2 Sees iniciais da ERSw Determinao do Escopo do produto
Descrio Geral do Produto
Levantamento das Funes
Pauta adicional:
N Assunto Descrio
1 Assunto 1 Pauta adicional, para ser discutida caso
haja tempo na reunio, apenas uma
forma de preveno.
Documentos necessrios para a realizao da oficina
Pelo Cliente: Algum documento necessrio para se
chegar a alguma funo do sistema, como
normas, leis, exemplos, etc.
Pelos Desenvolvedores: 1. Algum documento ou artefato que pode
ajudar no levantamento de requisitos.
Pendncias a serem checadas:
N Descrio Responsvel
1 1. - -
Observaes:
A Pauta Adicional ser discutida apenas se houver disponibilidade de tempo.
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) em tempo, tal fato deve ser comunicado, no mnimo, com um dia de an-
tecedncia da reunio.
Convocado por: Data:

Nome da Organizao Desenvolvedora 10/05/10
Nome da Equipe
148 UNIDADE 03
ANEXO III Exemplo de Ata de Oficina de Levantamento de Requisitos
Ata de Reunio de Levantamento de Requisitos

Projeto Nome Do Projeto
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

Tpicos discutidos
N Assunto Descrio
1. Apresentao inicial 1. O planejamento inicial foi apresentado aos
usurios.
2. Sees iniciais da ERSw 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 Descrio Responsvel Prazo
5. Agendar uma data para apre- UFPI Em aberto
sentao do trabalho que est
sendo feito para os envolvidos
do cliente.
6. Rever perodo de reviso da UFPI
ERSw pelos usurios.
7. Rever Pautas previstas das ofi- UFPI
cinas.
Data de envio da ata para o cliente

Anexo IV Reviso da Especificao de Requisitos
Objetivos do Documento
Registrar os problemas encontradas durante a reviso da Especificao de Requisitos (ER)
do projeto ReqG juntamente com as providncias adotadas para solucionar tais problemas.

Revisores
Nome email Telefone
Pedro pasn@ufpi.edu.br 8816-7070

Data 13.01.11

Critrios
Ambiguidade Cada requisito ou caso de uso especificado no possui mais de
um sentido, permitindo assim uma interpretao dbia sobre o seu
significado.
Clareza As regras de negcio e informaes associadas aos requisitos so
claras, permitindo seu entendimento.
Completude Os requisitos esto completamente descritos. No h lacunas que
impossibilitem o entendimento.
No conflitante Existem requisitos com especificao de conceitos conflitantes
com outros requisitos, deixando claro que existe algo errado na
especificao.
150 UNIDADE 03
Nr. Requisito Caso de Ambiguidade Clareza Completude No conflitante Conflitos Defeito Providncia
Uso
1 RF1 - Aprovado Aprovado Aprovado Aprovado - - -
Em relao a
ambiguidade, o O requisito foi
acompanhamento reescrito para
dos clientes e detalhar o que
Parece que
gerao da ER o acompan-
o RF4 e RF6
parecem ter hamento. Isso
tratam da
muitos aspectos o diferenciou
mesma coisa,
em comum. Em da gerao da
4 RF4 - No aprovado No aprovado Aprovado Aprovado embora no
relao clareza, especificao,
haja uma clara
no ficou claro evitando a
definio do
o que acom- ambiguidade e
que realmente
panhamento do deixando claro
se trata.
projeto, por conta o que est
disso a super- associado a tal
posio com o requisito.
RF6.

A especificao
do requisito,
A alterao do
O requisito quando com-
RF4 o deixou
parece ter su- parado ao RF4
diferente do
perposio com parece demon-
RF6, resolven-
6 RF6 - No aprovado Aprovado Aprovado Aprovado o RF4. Aparente- strar que os
do o problema
mente os dois dois tratam da
da ambiguidade
descrevem a mesma coisa,
existente entre
mesma coisa. gerando uma
os dois.
duplicidade de
interpretao.
EXEMPLO DE ARTEFATOS
151
152
Caso de
Nr. Requisito Ambiguidade Clareza Completude No conflitante Conflitos Defeito Providncia
Uso
UNIDADE 03
7 RNF1 Aprovado Aprovado Aprovado Aprovado - - -
Foi detalhado
como deveria
No foi possvel Falta a de-
ser o padro
entender o que scrio do que
11 RNF5 Aprovado No aprovado Aprovado Aprovado de senhas para
significa uma uma senha
evitar senhas
senha fcil. fcil.
consideradas
fceis.
13 RF1 UC1 - - -
No foi
No foi especifi-
especificada
cada a ordem
a ordem em
14 RF1 UC2 Aprovado Aprovado No aprovado Aprovado em que os re-
que os resul-
sultados devem
tados devem
ser exibidos.
ser exibidos.
15 RF2 UC3 Aprovado Aprovado No aprovado Aprovado - - -
16 RF2 UC4 Aprovado Aprovado Aprovado Aprovado - - -
Adicionado
No existe a
Identificar o ao prottipo a
especificao
projeto as- informao do
17 RF3 UC5 Aprovado Aprovado Aprovado Aprovado do projeto
sociado ao projeto a ter
associado ao
requisito. um requisito
requisito.
cadastrado.
Caso de
Nr. Requisito Ambiguidade Clareza Completude No conflitante Conflitos Defeito Providncia
Uso
Adicionado
No existe a Identificar o ao prottipo a
especificao projeto as- informao do
18 RF3 UC6 Aprovado Aprovado Aprovado Aprovado projeto a ter um
do projeto asso- sociado ao
ciado ao Ator. ator. ator cadas-
trado.
Adicionado
No existe a Identificar o ao prottipo a
especificao do projeto asso- informao do
19 RF5 UC7 Aprovado Aprovado Aprovado Aprovado
projeto associado ciado ao caso projeto a ter um
ao Caso de uso. de uso. caso de uso
cadastrado.
20 RF5 UC8 No aprovado Aprovado Aprovado Aprovado - -
21 RF5 UC9 Aprovado Aprovado Aprovado Aprovado -
22 RF4, RF6 UC10 Aprovado Aprovado Aprovado Aprovado -

23 RF4, RF6 UC11 Aprovado Aprovado Aprovado Aprovado -
153
Anexo V
Reviso do Modelo de Anlise
Objetivos do Documento
Registrar os problemas encontradas durante a reviso do Modelo de Anlise do projeto
ReqG juntamente com as providncias adotadas para solucionar tais problemas.

Revisores
Nome email Telefone
Pedro pasn@ufpi.edu.br 8819-7070
Data 13.01.11
Critrios
Ambiguidade Cada classe identificada ou realizao no
possui mais de um sentido, nem existem
diferentes representaes para coisas simil-
ares, que permitam uma interpretao dbia
sobre o seu significado.
Clareza As classes e realizaes so claras per-
mitindo seu entendimento.
Completude Os atributos dos prottipos que devam ser
armazenados esto completamente descri-
tos nas entidades. As realizaes possuem
todos os objetos utilizados. No h lacunas
que impossibilitem o entendimento.
No conflitante As realizaes no possuem conceitos con-
flitantes com outras realizaes. As classes
no possuem atributos conflitantes. Dia-
gramas em diferentes pacotes no contm
modelagens diferentes.
154 UNIDADE 03
Nr. Elemento Ambiguidade Clareza Completude No conflitante Conflitos Defeito Providncia
1 Classe Aprovado Aprovado Aprovado Aprovado - - -
Alteracao
2 Classe Aprovado Aprovado Aprovado Aprovado - - -
Usuario
Foi extrada uma
Os atributos de No estava claro
classe usurio,
usurio estavam o suficiente que
Classe Mem- separando-a de
3 Aprovado No aprovado Aprovado Aprovado dentro da classe os membros do
bro membro. Isso
membro, dificultando projeto eram
tornou mais claro
o entendimento. usurios.
o diagrama.
Foi includo o
relacionamento
No havia a
No havia a modela- de projeto com
Classe modelagem dos
4 Aprovado Aprovado No aprovado Aprovado gem dos membros de membros,
Projeto membros de um
um projeto. representando
projeto.
os participantes,
alm do gerente.
5 Classe Ator Aprovado Aprovado Aprovado Aprovado - - -
Classe Caso
6 Aprovado Aprovado Aprovado Aprovado - - -
de Uso
7 Classe Fluxo Aprovado Aprovado Aprovado Aprovado - - -
Classe Fluxo
Alternativo
No havia
necessidade
Foi removida a
de termos uma
Subfluxo no acres- classe e criada
classe subfluxo,
centava nenhuma uma nova as-
Classe Sub- uma vez que
9 No aprovado Aprovado Aprovado Aprovado informao adicional sociao entre
fluxo um subfluxo
a fluxo, sua classe caso de uso
um fluxo e no
genrica. e fluxo, com o
possui qualquer
nome subfluxos.
caracterstica
adicional.
155
156
Nr. Elemento Ambiguidade Clareza Completude No conflitante Conflitos Defeito Providncia
Classe Pro-
UNIDADE 03
totipo
Classe
Requsiito
Classe
Criterio
No havia um atributo
Falta do campo Foi adicionado o
Classe Item para as observaes
13 Aprovado Aprovado No aprovado Aprovado observao na campo classe
de Revisao relacionadas a avalia-
avaliao. Item de Reviso.
o de um critrio.
Classe
Revisao
Diagrama de
Entidades
Realizao
16 Controle de Aprovado Aprovado Aprovado Aprovado - - -
Projetos
ALISTAIR, COCKBURN, Escrevendo Casos De Uso Eficazes, Editora
Bookman, 2003.
BERTRAND MEYER, Object-oriented Software Construction, Prentice-Hall,

2a edio, 1997.
DAVID GARMUS, DAVID HERRON, Function Point Analysis: Measure-

ment Practices for Successful Software Projects, Addison-Wesley, 2000.
IAN SOMMERVILLE, Engenharia de Software, 6a. Edio, Addison-Wes-

ley, 2005.
J. RUMBAUGH, I. JACOBSON, G. BOOCH.The Unified Modeling Lan-

guage Reference Manual, Addison Wesley, 1999.
JANE WOOD, SILVER DENISE, Joint Application Development, John

Wiley & Sons Inc, ISBN 0-47104-299-4.
KENDALL SCOTT, Processo Unificado Explicado, Editora Bookman,

2003.
KENT BECK, Extreme Programming Explained: embrace change. Bos-

ton: AddisonWesley/Longman, 1999.
ROGER S. PRESSMAN, Engenharia de Software, 5a. Edio, McGraw-

Hill, So Paulo, 2002.
WILSON DE PDUA PAULA FILHO, Engenharia de Software: Fundamen-

tos, Mtodos e Padres, Editora LTC, 2 Edio, 2003.
WILSON DE PDUA PAULA FILHO, Engenharia de Software: Fundamen-

tos, Mtodos e Padres, Editora LTC, 2 Edio, 2003.

CV. http://lattes.cnpq.br/3452982259415951
Possui graduao em Bacharelado em Cincia da Com-

putao pela Universidade Federal do Piau (1995).
Mestrado em Cincia da Computao pela Universi-
dade Federal de Pernambuco (1999) e doutorado em
Cincia da Computao pela Universidade Federal de
Minas Gerais (2006). Atualmente, professor da Uni-
versidade Federal do Piau. Tem experincia na rea
de Engenharia de Software, atuando principalmente na automao de
testes, desenvolvimento de software utilizando metodologias geis e en-
genharia de software experimental.
158 UNIDADE 03

Requisitos de Software PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Requisitos de Software PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Federal do Piau

Centro de Educao Aberta e a Distncia

Pedro de Alcntara dos Santos Neto

EQUIPE DE DESENVOLVIMENTO CONSELHO EDITORIAL DA EDUFPI

S237 Neto, Pedro de Alcntara dos Santos

1- Requisito de Software 2 - CPU. 3 - Motivao

1.1 O Fluxo de Requisitos .......................................................... ....13

2.1 A Linguagem UML ................................................................ ....55

1.2 Atividades do Fluxo de Requisitos

Figura 1: Atividades do Fluxo de Requisitos

As atividades do Fluxo de Requisitos so exibidas na Figura

Gerenciar os requisitos de um projeto de software, registrando todos os dados

Na definio acima, podemos notar que o trabalho a ser realizado

1. O ReqG no controlar a execuo de tarefas no projeto, apenas registrar os dados

Podemos notar que os requisitos exibidos na Tabela 1 so simples

O desenvolvimento de software pode ser entendido como uma

Detalhamento dos Requisitos

Figura 2: Exemplo de ator e caso de uso.

A Figura 2 exibe um exemplo de como representado um caso de

O sistema deve permitir cadastrar e controlar todos os aspectos relacionados

De acordo com o texto do requisito, o sistema deve possibilitar o

A Tabela 3 exibe a lista de casos de uso identificados no sistema,

ID Caso de uso Requisito associado Descrio

Definio dos casos de

Definio dos atores

A Tabela 4 exibe a lista de atores identificados. importante

Responsvel pelo controle de um projeto, definindo a

Pessoa que faz parte da equipe que trabalha no

Tabela 4: Lista de atores do Projeto

Dando prosseguimento ao nosso trabalho relacionado ao Software

Detalhamento dos Casos de uso

Os fluxos so comumente descritos em linguagem natural na

Prcondies 1 - O Administrador acionou o comando Novo.

1 - O Administrador preenche os Dados do Gerente.

Esse exemplo possui alguns pontos interessantes. Ele possui

Definio dos Prottipos de Interface

Projeto Descrio Gerente

A Figura 4 exibe um exemplo de um prottipo simples para uma

Na Tabela 5 mostrado que o formato de cada campo altervel

O ReqG exibe a Tela de Gerao da Especificao.

Ainda no prottipo exibido na Figura 5, podemos notar que o campo

[Lista de Tipos de Ingresso pr-cadastrados no sistema]

Reviso dos Requisitos

No prximo captulo apresentaremos de forma detalhada uma

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?

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? Descreva-as

9. O que o escopo de um projeto?

10. Por que importante definir os limites do produto?

11. Como deve ser a abordagem em uma instituio para se levantar

requisitos junto aos clientes?

13. Cite 3 exemplos de requisitos funcionais para um Sistema

14.Cite 3 exemplos de requisitos no-funcionais para um Sistema

15. O que um caso de uso, segundo requisitos do software?

16. O que so os atores, segundo requisitos do software?

17. Como identificar atores?

18. O que devemos fazer para identificarmos casos de uso?