Consideraes sobre Pontos de Funo (APF)

O que Anlise de Pontos de Funo? E o que Ponto de Funo?

Anlise de Pontos de Funo (APF) uma tcnica de medio das funcionalidades fornecidas
por um software do ponto de vista de seus usurios. Ponto de funo (PF) a sua unidade
de medida, que tem por objetivo tornar a medio independente da tecnologia utilizada para
a construo do software. Ou seja, a APF busca medir o que o software faz, e no como ele
foi construdo.

Portanto o processo de medio (tambm chamado contagem de pontos de funo)

baseado em uma avaliao padronizada dos requisitos funcionais do usurio. Este
procedimento padro est descrito pelo IFPUG em seu Manual de Prticas de Contagem.

As principais tcnicas de estimativa de projetos de desenvolvimento de software assumem

que o tamanho de um software um vetor importante para a determinao do esforo para
sua construo. Logo, saber o seu tamanho um dos primeiros passos do processo de
estimativa de esforo, prazo e custo.

Da importante destacar que pontos de funo no medem diretamente esforo,

produtividade ou custo. exclusivamente uma medida de tamanho funcional do software.
Este tamanho, em conjunto com outras variveis, que poder ser usado para derivar
produtividade, estimar esforo e custo do projeto de software.

Para saber um pouco mais, assista s vdeo aulas introdutrias sobre:

Lio - O que a Anlise de Pontos de Funo (0:20) - Apresenta a definio do que

a Anlise de Pontos de Funo; quem so os responsveis pela sua manuteno e
evoluo; e qual o objeto da medio (o que medido e considerado na anlise).

Lio - Objetivos da Anlise de Pontos de Funo (0:15) - Apresenta os quatro

objetivos da anlise de pontos de funo e do processo de medio, explicando os
conceitos subjacentes necessrios ao entendimento dos mesmos.

No Brasil, alguns usam o termo original do ingls: FPA - Function Point Analisys. Outros
usam termos parecidos como "Anlise de Pontos por Funo", "Anlise por Pontos de
Funo", ou "Anlise por Pontos por Funo", que so tradues ligeiramente diferentes da
traduo oficial - Anlise de Pontos de Funo.

Quais os benefcios da Anlise de Pontos de Funo?

As organizaes usam pontos de funo muitas vezes com diferentes propsitos Pode-se
destacar vrios benefcios da aplicao da anlise de pontos de funo nas organizaes:

- Uma ferramenta para determinar o tamanho de um pacote adquirido, atravs da contagem

de todas as funes includas.

- Prov auxlio aos usurios na determinao dos benefcios de um pacote para sua
organizao, atravs da contagem das funes que especificamente correspondem aos seus
requisitos. Ao avaliar o custo do pacote, o tamanho das funes que sero efetivamente
utilizadas, a produtividade e o custo da prpria equipe possvel realizar uma anlise do tipo
"make or buy".

- Suporta a anlise de produtividade e qualidade, seja diretamente ou em conjunto com

outras mtricas como esforo, defeitos e custo. Porm se o processo de desenvolvimento da
organizao for catico (cada projeto desenvolvido de forma diferente), mesmo que a
contagem dos pontos de funo do projeto e o registro do esforo tenham sido feitos de
forma correta, a anlise da produtividade entre os projetos ser prejudicada.

- Apia o gerenciamento de escopo de projetos. Um desafio de todo gerente de projetos

controlar o "scope creep", ou aumento de seu escopo. Ao realizar estimativas e medies dos
pontos de funo do projeto em cada fase do seu ciclo de vida possvel determinar se os
requisitos funcionais cresceram ou diminuram; e se esta variao corresponde a novos
requisitos ou a requisitos j existentes e que foram apenas mais detalhados.

- Complementa o gerenciamento dos requisitos ao auxiliar na verificao da solidez e

completeza dos requisitos especificados. O processo de contagem de pontos de funo
favorece uma anlise sistemtica e estruturada da especificao de requisitos e traz
benefcios semelhantes ao de uma reviso em pares do mesmo.

- Um meio de estimar custo e recursos para o desenvolvimento e manuteno de software.

Atravs da realizao de uma contagem ou estimativa de pontos de funo no incio do ciclo
de vida de um projeto de software, possvel determinar seu tamanho funcional. Esta
medida pode ser ento utilizada como entrada para diversos modelos de estimativa de
esforo, prazo e custo.

- Uma ferramenta para fundamentar a negociao de contratos. Pode-se utilizar pontos de

funo para gerar diversos indicadores de nveis de servio (SLA - "Service Level
Agreement") em contratos de desenvolvimento e manuteno de sistemas. Alm disso
permite o estabelecimento de contratos a preo unitrio - pontos de funo - onde a unidade
representa um bem tangvel para o cliente. Esta modalidade possibilita uma melhor
distribuio de riscos entre o cliente e o fornecedor.

- Um fator de normalizao para comparao de software ou para a comparao da

produtividade na utilizao de diferentes tcnicas. Diversas organizaes, como o ISBSG,
disponibilizam um repositrio de dados de projetos de software que permitem a realizao de
benchmarking com projetos similares do mercado.

Qual o preo de um ponto de funo?

O valor R$/PF ir variar de acordo com o trabalho exigido para a entrega das funcionalidades
do software de acordo com o padro tcnico e de qualidade solicitado pelo cliente, como
tambm conforme a quantidade de entregveis (artefatos, documentos, modelos, etc)
exigidos pelo cliente. Em resumo, tudo aquilo que afeta custo de forma significativa mas que
no tem relao direta com o tamanho medido pela APF acaba sendo computado no preo do
ponto de funo.

Exemplo 1: ao se contratar uma empresa apenas para o trabalho de codificao e testes de

um sistema espera-se que o preo do ponto de funo seja inferior ao caso da contratao
da mesma empresa para a realizao de todo o ciclo de desenvolvimento do sistema, desde
o levantamento de requisitos at a implantao.

Exemplo 2: o preo do ponto de funo para a entrega apenas do software certamente

inferior ao preo do ponto de funo onde, alm do software, devem ser entregues vrios
documentos (subprodutos) como: modelos da UML, manual de usurio, ajuda on-line,
prottipos, casos e planos de testes, etc.

Exemplo 3: atualmente a gama de tecnologias disponveis para desenvolvimento de sistemas

enorme, cada uma delas podendo influenciar diretamente na produtividade (tanto
positivamente quanto negativamente) do trabalho a ser realizado. Sendo assim bastante
comum no mercado a diferenciao do R$/PF de acordo com a plataforma tecnolgica
(mainframe, web, cliente-servidor, etc) e/ou linguagem de programao (cobol, C, java, .net,
etc).

Exemplo 4: A APF, segundo o padro IFPUG, mede manutenes desconsiderando o tamanho

da manuteno que a funo sofrer. Geralmente o esforo para se manter uma funo
costuma ser inferior ao de se desenvolv-la. Sendo assim, pode haver diferenciao de preo
do ponto de funo em projetos de melhoria para funcionalidades novas, alteradas e
excludas.

Em resumo, no existe um preo nico para ponto de funo. Deve-se avaliar o conjunto de
atividades relativas disponibilizao das funcionalidades medidas em pontos de funo, o
modelo de contrato que ditar a remunerao de um ponto de funo e tambm os aspectos
no funcionais que so desconsiderados na medio dos pontos de funo para obter uma
referncia confivel. A melhor alternativa para obter esta referncia analisar os projetos j
realizados. Para projetos j concludos uma informao certamente disponvel o quanto se
pagou ou se cobrou por cada projeto e quais atividades estavam compreendidas. Caso o
tamanho funcional (PF) dos projetos no esteja disponvel, pode-se obt-lo rapidamente
atravs de uma medio ou de uma estimativa; basta analisar seus requisitos. Tendo o preo
do projeto e o seu tamanho em pontos de funo, obtm-se o seu preo por ponto de funo
(R$/PF). No entanto provvel que sua organizao empreenda projetos de diferentes tipos.
Neste caso deve-se proceder a anlise do R$/PF para cada categoria de projetos, pois
dificilmente um preo nico ser representativo para projetos de tipos distintos.

possvel obter informaes de preo do PF dos contratos governamentais, pois so dados

pblicos. Na tabela seguinte,http://www.fattocs.com.br/editais.asp, apresentamos algumas
referncias para fins de ilustrao. Pode-se observar que a variao dos nmeros muito
significativa, com valores orbitando de R$100/PF a R$1.000/PF. Para entender parte destas
discrepncias necessrio olhar com ateno o objeto de contratao do servio para
identificar as diferenas tcnicas e de complexidade de cada contrato.

Que tipos de software podem ser medidos pela APF?

A Anlise de Pontos de Funo (APF) uma tcnica para medir as funcionalidades oferecidas
por um software para seus usurios. E esta medio sempre feita numa perspectiva
externa; do ponto de vista dos usurios. Porm cabe destacar que o conceito de usurio para
a APF no apenas do usurio final do software. Usurio para APF qualquer pessoa ou
coisa que interage com o software a qualquer momento. Ou seja, usurio para APF pode ser
tanto uma pessoa agindo como usurio final do software ou tambm outro software que
utiliza servios do software em anlise.

Considerando que todo e qualquer software existe para oferecer um ou mais servios
(funes) para algum (pessoa ou coisa); ento conclui-se que todo e qualquer software
pode ser medido pela APF.

Um equvoco comum de alguns iniciantes com a APF usar como ponto de vista da anlise
apenas o usurio final. Neste caso alguns softwares sero parcialmente (ou completamente)
"invisveis" para este usurio. E da o iniciante conclui equivocadamente que a APF no serve
para medir aquele software. O mais comum o iniciante aprender os princpios da APF
aplicada a sistemas com telas e relatrios. Porm quando este se depara com softwares que
no possuem telas, softwares com processamento batch, middlewares, softwares bsicos,
natural sentir dificuldade em fazer a medio.

Vamos imaginar que o objetivo fosse medir um driver de impressora. Ora, no h um usurio
final (pessoa) para este tipo de software. Nesta perspectiva, o driver de impressora
"invisvel" para o usurio final. Porm o driver de impressora existe para oferecer servios a
algum; no caso o sistema operacional. Analisando portanto o driver de impressora na
perspectiva do sistema operacional, possvel enxergar funes; por exemplo: funes para
iniciar a impressora, informar a situao geral do dispositivo, ejetar uma folha, imprimir,
alertar tinta prxima do final, dentre outras.
Como o processo de contagem de pontos de funo?

Resumidamente o processo de contagem de pontos de funo composto pelos seguintes

passos:

1. Identificao do propsito da contagem.

Neste passo, o objetivo deixar bem claro o que se pretende atingir com a
contagem que ser feita; qual o problema que se pretende resolver com ela. A
forma como os passos seguintes so conduzidos depende diretamente desse
propsito.

2. Determinao do tipo de contagem.

Existem trs tipos de contagem de pontos de funo. A diferena no

procedimento adotado entre esses tipos de contagem est nas frmulas aplicadas
no passo final da contagem.

- projeto de desenvolvimento: mede todas as funes que o projeto entregar e

eventuais funes de converso de dados.

- projeto de melhoria: mede as funes alteradas, includas e excludas pelo projeto

e eventuais funes de converso de dados.

- aplicao: mede as funes de um software instalado.

3. Identificao da fronteira da aplicao e do escopo da contagem.

A fronteira da aplicao a interface conceitual entre o software e o usurio. Ela

delimita o software e o mundo externo. um elemento essencial para a correta
identificao das funes do tipo dado e transao nos passos seguintes. O escopo
da contagem define o que far parte da contagem de pontos de funo.

4. Contagem das funes tipo dado.

As funes do tipo dado representam requisitos de armazenamento do usurio.

So classificadas em:

- Arquivos Lgicos Internos (ALI): grupos de dados logicamente relacionados (do

ponto de vista do usurio) e mantidos pela prpria aplicao.

- Arquivos de Interface Externa (AIE): grupos de dados logicamente relacionados

(do ponto de vista do usurio) e apenas referenciados de outras aplicaes.

Nesse passo so identificados todos os ALIs/AIEs do sistema. As complexidades

so determinadas com base em dois parmetros (tipos de dado e tipos de registro)
e; associada a cada complexidade existe uma quantidade de pontos de funo
correspondente.
5. Contagem das funes tipo transao.

As funes do tipo transao representam requisitos de processamento do

usurio. So classificadas em:

- Entradas Externas (EE): transaes com o objetivo de atualizar arquivos lgicos

internos ou modificar o comportamento do sistema.

- Consultas Externas (CE): transaes que representam simples recuperao de

dados de arquivos lgicos internos e/ou arquivos de interface externa.

- Sadas Externas (SE): transaes com o objetivo de apresentao de informao,

porm envolvendo lgica de processamento adicional a uma consulta externa.

Nesse passo so identificadas todas as transaes do sistema. Suas complexidades

so determinadas com base em dois parmetros (tipos de dado e arquivos
referenciados) e; associada a cada complexidade existe uma quantidade de pontos
de funo correspondente.

6. Clculo do fator de ajuste.

O fator de ajuste representa a influncia de requisitos tcnicos e de qualidade no

tamanho do software. calculado com base nas 14 Caractersticas Gerais do
Sistema (CGS) listadas a seguir:

( 1) Comunicao de Dados

( 2) Processamento Distribudo

( 3) Performance

( 4) Configurao Altamente Utilizada

( 5) Volume de Transaes

( 6) Entrada de Dados On-Line

( 7) Eficincia do Usurio Final

( 8) Atualizao On-Line

( 9) Complexidade de Processamento

(10) Reutilizao

(11) Facilidade de Instalao

(12) Facilidade de Operao

(13) Mltiplos Locais

(14) Facilidade de Mudanas

Cada uma dessas caractersticas deve ser analisada com relao ao seu nvel de
influncia sobre o sistema e pontuada de 0 (nenhuma influncia) a 5 (grande
influncia). Ento se soma todas essas pontuaes para obter o nvel total de
influncia (TDI). Da basta aplicar a seguinte frmula para obter o fator de ajuste:
VAF = (TDI x 0,01) + 0,65.

Atualmente esse um passo opcional do processo de contagem. Muitas

organizaes desconsideram o fator de ajuste e usam apenas a medio dos pontos
de funo no ajustados. Ainda assim, as orientaes para determinao do VAF
pode ser teis para ajudar a distinguir requisitos funcionais de requisitos tcnicos e
de qualidade.

7. Clculo dos pontos de funo ajustados.

O clculo final dos pontos de funo ajustados consiste basicamente em

multiplicar o fator de ajuste pelos pontos de funo no ajustados. Porm existem
frmulas especficas para cada tipo de contagem:

- projeto de desenvolvimento: DFP = (UFP + CFP) x VAF, onde:

UFP - pontos de funo da aplicao a ser instalada

CFP - pontos de funo das funcionalidades de converso de dados

VAF - valor do fator de ajuste

- projeto de melhoria: EFP = [(ADD + CHGA + CFP) x VAFA] + (DEL x VAFB), onde:

ADD - pontos de funo das funcionalidades adicionadas

CHGA - pontos de funo das funcionalidades alteradas

CFP - pontos de funo das funcionalidades de converso de dados

VAFA - valor do fator de ajuste do software aps o projeto de melhoria

DEL - pontos de funo das funcionalidades excludas

VAFB - valor do fator de ajuste do software antes do projeto de melhoria

- aplicao: AFP = ADD x VAF

Qual indicador de produtividade (pontos de funo / homem-ms) ou taxa de
entrega (horas / ponto de funo) deve ser utilizado para estimar o esforo de
projetos de software?

H uma tentao muito grande entre os profissionais envolvidos em estimativas de usar

indicadores ditos "de mercado" para suas estimativas baseadas em pontos de funo.
Certamente existem vrias fontes onde possvel obter nmeros relacionados
produtividade com pontos de funo para diversos contextos tecnolgicos. O ISBSG
(International Software Benchmarking Standards Group) uma delas. No entanto, usar
essas fontes desconsiderando o contexto de como aqueles nmeros foi obtido e o contexto
de sua prpria organizao um erro grave. Estimativas obtidas dessa maneira dificilmente
tero a confiabilidade necessria ou alguma utilidade prtica.

A melhor forma de obter indicadores de produtividade que realmente sejam teis nas
estimativas com pontos de funo apurar esse indicador atravs dos projetos
desenvolvidos pela organizao. Mas como fazer isto?

O primeiro passo recuperar dos projetos passados as duas grandezas que compe o
indicador de produtividade: o tamanho (em pontos de funo) e o esforo (horas). Com
estes dois dados tem-se de forma direta a produtividade daquele projeto. Mas se cada
projeto tiver um nmero de produtividade diferente, qual deve ser empregado no projeto a
ser estimado?

Certamente que cada projeto pode apresentar um nmero distinto, mas se este
procedimento for repetido para um conjunto maior de projetos ser possvel observar que
para determinados subconjuntos a produtividade bastante similar. Isso acontece quando os
projetos tm caractersticas similares em relao aos fatores que afetam diretamente o
esforo para desenvolv-los. Logo, razovel concluir que dependendo da natureza dos
projetos desenvolvidos pela organizao, no haver um nico indicador de produtividade
para todos os projetos da organizao; mas sim indicadores de produtividade por grupos de
projeto similares. Sendo assim, o primeiro passo para estimar um novo projeto enquadr-
lo em algum grupo de projetos e s ento usar o indicador de produtividade adequado. Mas
quais so os fatores que definem esses grupos de projetos?

Qualquer varivel que tenha capacidade de produzir um impacto significativo no esforo do

projeto deve ser levada em considerao nessa anlise de segmentao de grupos de
projeto. Convm destacar que os fatores podem ser diferentes de organizao para
organizao. Por exemplo: o uso ou no de uma determinada metodologia de
desenvolvimento de sistemas no projeto pode afetar sua produtividade. No entanto se em
uma determinada empresa todos os projetos seguem a mesma metodologia, este fator ser
constante e no ter relevncia para a segmentao de projetos.

Sem a pretenso de estabelecer uma lista completa, pode-se citar os seguintes fatores:

- tipo de projeto: desenvolvimento, melhoria, migrao, redesenvolvimento, etc;

- plataforma tecnolgica: mainframe, web, cliente x servidor, sistema embutido, etc;
- ordem de grandeza dos projetos;
- tamanho da equipe de desenvolvimento;
- ferramentas de desenvolvimento;
- metodologia empregada;
- rea de negcio;
- nmero de usurios.
Quantos pontos de funo um analista conta em um dia?

H uma variao grande na produtividade da contagem de pontos de funo por dia para um
profissional, causada principalmente por:

1. Conhecimento do negcio sobre o qual o projeto/sistema atua: se o analista de mtricas

tem conhecimento do negcio, ter facilidade para efetuar a medio, mesmo at que a
documentao do projeto/sistema no esteja com boa qualidade.

2. Qualidade da documentao disponvel: a principal fonte de informao para a contagem

a documentao do projeto/sistema. Se a documentao estiver incompleta ou ambgua,
mais tempo ser consumido para elucidao de dvidas referentes aos requisitos.
Documentao insuficiente para a medio um problema mais comum para contagens de
aplicao e projetos de melhoria.

3. Experincia dos contadores: quanto mais experincia o analista adquire em contagens,

mais gil ele na anlise dos requisitos. Ele aprende a buscar quais informaes so
relevantes para a medio na documentao e a desprezar aquilo que no interessa
(poupando tempo de anlise de algo que no afetar a medio). A experincia acumulada
tambm evita que se tenha que consumir tempo em anlise de situaes que ele j lidou
anteriormente.

4. Disponibilidade dos usurios: muitas vezes mesmo com documentao disponvel do

sistema, necessrio entrevistar usurios para complementar alguma necessidade de
informao que no foi documentada ou documentada de forma no clara. Para sistemas
legados que no possuem documentao, a nica forma de med-los com o apoio dos
usurios. Se no h um usurio disponvel para suprir informaes, o analista de mtricas
ficar aguardando essa disponibilidade para poder dar prosseguimento medio.

5. Propsito da contagem: dependendo da questo que se deseja responder com a contagem

a ser realizada, a preciso da contagem e sua rastreabilidade podem no ser questes
primrias. Assim pode se analisar de forma mais superficial a documentao e tambm
evitar um esforo adicional na documentao da prpria contagem. Ou seja, pode-se optar
por uma estimativa de tamanho em vez de propriamente a medio. Mesmo a medio pode
ser feita com diferentes nveis de documentao, o qual influenciam o tempo gasto nesta
atividade.

6. Automao do processo: softwares de apoio podem agilizar a contagem, principalmente

das partes do processo que no envolvem anlise.

7. Tipo de contagem: em geral a produtividade para contar projeto de melhoria maior do

que de projeto de desenvolvimento ou contagem de aplicao; principalmente se a aplicao
que estiver sofrendo manuteno (objeto do projeto de melhoria) j tiver sido contada. Mas
o inverso pode tambm ocorrer, se a medio for para um projeto de melhoria de uma
aplicao que nunca foi medida e que tenha pouca documentao disponvel.

8. Guia de Contagem: o guia de contagem um documento que simplifica e contextualiza as

regras do IFPUG para as situaes especficas de uma organizao. Para analistas com pouca
experincia ou com pouco conhecimento do contexto da organizao, o guia facilitar
bastante o trabalho de medio, proporcionando agilidade.

Analisando um cenrio de pior caso, onde os fatores citados anteriormente estariam

influenciando de forma negativa o trabalho de medio, um limite inferior para a
produtividade seria 100 PF/dia. Para um cenrio de melhor caso seria razovel considerar
1.000 PF/dia. Cabe destacar que a produtividade mdia no est no meio desta faixa, mas
mais perto do cenrio de pior caso, que corresponde s situaes mais comuns de se
encontrar no dia a dia. Dependendo das especificidades que uma organizao possui, ela
pode eventualmente apresentar nmeros fora da faixa citada, mas no seria um
comportamento tpico esperado. Produtividade abaixo de 100 PF/dia sinal de problema,
deve-se investigar e atacar as suas causas. Muitas vezes o analista de mtricas executa
atividades de anlise de requisitos, devido falta de documentao ou baixa qualidade da
mesma. No seria correto computar este esforo como o de medio, mas sim de anlise de
requisitos.

Convm destacar que a produtividade no constante durante todo o processo. O tempo de

preparao, anlise da documentao, esclarecimento de dvidas mais predominante no
incio da contagem do que a prpria contagem em si. Aps essas etapas o normal que a
contagem flua mais rapidamente.

Quais as principais causas para erros em uma contagem de pontos de funo?

A maioria dos erros encontrados em uma contagem de pontos de funo de um sistema

causada por quatro fatores:

- Desconhecimento da tcnica: ainda h um grande nmero de profissionais que so

designados para contar pontos de funo de um sistema sem o conhecimento necessrio do
processo de contagem. Talvez isto ocorra por haver uma idia generalizada de que a APF
seja muito simples. E na realidade ela , porm isto no significa que seja desnecessrio
treinamento profissional ou um estudo mais dedicado da tcnica. Com apenas um
conhecimento superficial da APF bem provvel que o analista cometa erros bsicos. Sobre
este aspecto, o IFPUG estabeleceu o seu programa de certificao profissional CFPS, que visa
garantir que o profissional certificado conhece todas as definies e regras do seu Manual de
Prticas de Contagem em sua verso mais recente.

- Deixar a contagem ser "contaminada" pela implementao: a APF uma tcnica para medir
requisitos funcionais de um software. Ou seja, mede o que o usurio solicita e recebe do
software independente do como este foi implementado. Logo, o resultado de uma contagem
de pontos de funo tem que ser o mesmo, seja qual for a soluo de implementao
(processo, arquitetura, ferramentas, ambiente computacional, etc) adotada pelo
desenvolvedor. Contar pontos de funo de um sistema um exerccio de abstrao do
problema de negcio do usurio que o software deve atender. Porm nem sempre isto uma
tarefa fcil e mesmo analistas de pontos de funo experientes podem desviar o foco da
contagem para a soluo de implementao do desenvolvedor. Muitas vezes o analista
induzido neste caminho por falta de documentao adequada.

- Falta de conhecimento do negcio: no adianta ser especialista na APF e no conhecer o

negcio do usurio. Para que a contagem de pontos de funo seja feita de forma correta, ou
seja, do ponto de vista do usurio, necessrio que o analista de pontos de funo busque o
entendimento do negcio primeiro e somente depois realize a contagem de pontos de
funo. Muitas vezes no h tempo disponvel para que o analista de pontos de funo
busque este conhecimento. Neste caso ele ir atuar em parceria com um analista de negcio
ou com um usurio para poder realizar a contagem de pontos de funo.

- Qualidade dos requisitos disponveis: muito se fala na engenharia de software sobre a

importncia do levantamento de requisitos e do impacto que isto tem em todo o projeto
quando esta tarefa no bem executada. Para a contagem de pontos de funo isto no
diferente. Se os documentos de onde o analista de pontos de funo extrai os requisitos do
usurio para realizar a contagem esto ambguos, incompletos ou mal escritos, certamente o
resultado da contagem ser afetado.

Esta relao de fatores no est apresentada em nenhuma ordem especfica, mas bastante
representativa dos principais fatores que causam contagem de pontos de funo incorreta.
Qual a importncia dos requisitos do software para a APF?

Os requisitos do software so fundamentais para a APF, pois o processo de medio

baseado exclusivamente neles. O insumo bsico da medio so os requisitos do sistema.
Convm destacar que a APF mede apenas uma parte dos requisitos do usurio para o
sistema: os requisitos funcionais. Os requisitos no funcionais no so medidos pela APF.
Porm num modelo de estimativa de custo baseado em PF (custo = tamanho x $/PF), ambos
os tipos de requisitos (funcionais e no funcionais) so considerados: o primeiro ir afetar o
tamanho funcional e o segundo afetar o custo unitrio ($/PF).

Devido a esta importncia dos requisitos para a APF, quanto melhor a qualidade dos
requisitos, mais fcil e gil torna-se o processo de medio, e mais preciso o resultado.
Requisitos de qualidade ruim afetam negativamente todo o projeto de software, inclusive a
atividade de medio. Porm um efeito colateral benfico do processo de medio
justamente evidenciar falhas nos requisitos. Quanto mais cedo no projeto estas falhas forem
identificadas, menor o custo de corrig-las e maior a chance de sucesso do projeto.