1

Professor:
Geraldo Xexo

Contedo:

Proposta Inicial

O que vamos ver

Como fazer uma proposta inicial do
sistema
O desafio ter pouca informao
sobre o que deve ser feito
A necessidade fornecer uma
proposta tcnica e comercial ao cliente

Como tudo comea

O Cliente pede alguma coisa
O Cliente tem algum problema
Sua empresa precisa de algo
Sua empresa tem algum problema
Sua empresa o cliente
Cliente interno !

Clientes Externos ou Internos

Existem duas posies tpicas de trabalho
para um analista de sistemas
Ele trabalha em uma empresa de produo de
software que realiza produtos para terceiros
O Cliente externo

Ele trabalha na rea de TI de uma empresa cujo

negcio outro e desenvolve produtos para auxiliar
esse negcio
O Cliente interno

Todos so clientes!

A solicitao do cliente
Normalmente o cliente, ao solicitar um
software, tem idia do que necessita que esse
software faa
Algumas vezes existe um documento
descrevendo essa idia
Algumas vezes existe um sistema j funcionando

A partir desses objetos e das entrevistas

iniciais, que o analista deve procurar as
principais motivaes e necessidades do
cliente.

A solicitao do cliente
sempre importante focalizar nas
necessidades de negcio do cliente.
As vezes nem o cliente est fazendo isso

Muitas vezes o cliente acredita precisar

de um sistema para resolver um
problema em seu negcio, quando na
verdade precisa de outro.
Deixando claras as expectativas,
teremos clientes mais contentes.

Que tipos de solicitaes?

Telefonema, Conversa
Informal, pouca ou nenhuma informao

E-mail, Carta, Pedidos

Informal, pouca informao
Formal, alguma informao

RFP : Request for Proposal

Formal, bastante informao

Como responder a solicitao

Registrar a solicitao
Avaliar os verdadeiros problemas do cliente
Negociar uma soluo
Se comprometer com a melhoria do negcio
do cliente
Fazer a proposta tcnica da soluo
Fazer a proposta comercial/de investimento
da soluo

Como obter dados suficientes

Entrevistas e reunies com gerentes e
diretores
Usar ou acompanhar o uso do sistema
atual (se existir)
Visitar as instalaes e acompanhar o
funcionamento e uso do sistema
Conversar com usurios
Entrevistas e reunies com usurios

A maioria dos projetos exige

que voc responda primeiro:
Qual a viso do projeto?

Quais as expectativas de resultados

realizvel?
economicamente vivel?
Melhorar o atual ou fazer outro?
Comprar um pronto ou construir do incio?
Quanto vai custar?

1
0

Isso exige uma certa dose de

anlise de requisitos!

11

Mas ainda no estamos contratados ou

designados para realmente fazer essa
tarefa
Estamos em fase de prospeco ou
negociao
No cliente externo ou interno

Durao
Muitas vezes no temos tempo hbil
Decida se o projeto merece uma
anlise, mas no faa toda a anlise!
A experincia faz diferena
O uso de tcnicas especficas faz
diferena

1
2

Recursos Necessrios

1
3

Os recursos necessrios para obter os

requisitos iniciais de um sistema, antes
do incio de sua execuo, j foram
avaliados em 8% adicionais aos
recursos necessrios para o seu
desenvolvimento
O custo do sistema continua sendo 100%
O total 108%

Itens mais importantes

Problemas atuais
Objetivo do sistema proposto
Metas a serem alcanadas pelo novo
sistema
Oportunidades
Viso do novo sistema

1
4

Mapa de Influncias

1
5

Tecnologia
Ambiente
Problemas

Oportunidades
Solues

Sistema

Metas
Mtricas

Objetivo

Objetivo do Sistema

1
6

Uma sentena de poucas linhas que permite

identificar imediatamente sua finalidade
A sentena deve ser clara, de forma a
permitir uma definio rpida do seu escopo,
isto , da fronteira que define o que faz parte e o
que no faz parte do sistema.

Deve tambm esclarecer a razo do projeto

existir e ser necessrio.

Objetivo: Exemplos

1
7

O Sistema dever controlar a recepo e

envio de pacotes pelo setor de cargas de uma
empresa de alimentos congelados.
O Sistema permitir o gerenciamento de
cardpios em uma rede de restaurantes
populares, definindo pratos e receitas e
verificando sua aceitao.
O Sistema controlar a entrada e sada de
funcionrios, realizando o servio de ponto e
fornecendo dados para a folha de pagamento.

Objetivo

1
8

O objetivo deve identificar junto ao cliente,

de forma mais padronizada possvel frente ao
mercado, que tipo de sistema est sendo
desenvolvido.
Ao mesmo tempo, deve fornecer
informaes suficientes que caracterizem de
que forma esse sistema especial.
Desenvolver um sistema de controle de vendas
para uma loja de materiais de construo que
permita encomenda de mercadorias.

Objetivo

1
9

No devemos dar vrios objetivos a um

sistema.
Quando isso parece necessrio, temos
a forte indicao que estamos tratando
de mais de um sistema.
Ao declarar um objetivo devemos evitar
o uso das conjunes e e tambm, ou
ainda outra construo que leve a
representar mais de uma idia.

Objetivo - Resumo
Uma frase
Um objetivo
Afirmar o que igual
Afirmar o que diferente
Caracterizar o cliente

2
0

Explicando

2
1

O Sistema permitir o gerenciamento

de cardpios em uma rede de
restaurantes populares, definindo pratos
e receitas e verificando sua aceitao

Oportunidades
Ofertas que fazemos ao nosso cliente, no
includas em suas necessidades originais.
Devem produzir resultados teis para a
empresa
acelerar processos,
eliminar passos desnecessrios,
reduzir erros na entrada e
sada de dados,
aumentar a integrao entre sistemas,
aumentar a satisfao do usurio e
facilitar a interao com os parceiros
externos da organizao
(fornecedores, representantes e clientes)

2
2

Oportunidades

2
3

Oportunidade tecnolgica
a oferta de uma tecnologia especfica de
implementao que oferecer alguma
vantagem ao cliente.

Oportunidade de negcio
alguma funcionalidade no prevista pelo
cliente, mas que sabemos ser possvel
implementar
Provavelmente observadas em um
concorrente

Oportunidades
Devemos ter muito cuidado com
oportunidades de negcio, pois elas podem
ser, na verdade, falsos requisitos.
Uma oportunidade de negcio deve ser
exaustivamente discutida com o cliente de
forma a ficar claro que:
realmente traz benefcios
esses benefcios so considerveis
o risco do projeto no aumenta muito
ser realmente utilizada.

2
4

Stakeholders

2
5

interessante levantar todos os stakeholders

de um sistema e mapear, de alguma forma,
seus interesses e interaes com o mesmo.
Abordagens simplificadas permitem identificar
imediatamente trs tipos de stakeholders:
desenvolvedores, compradores e usurios.

Uma investigao mais profunda pode achar

muitos outros interessados, como:
gerentes dos usurios finais, auditores,
responsveis pela operao, responsveis pela
manuteno, usurios de sistemas que enviam ou
recebem dados para o sistema especfico, etc.

Stakeholders

2
6

Usurios so todos aqueles que usam o

sistema com algum objetivo.
Interpretao restrita: apenas aqueles usurios
finais, isto , que realmente usam o sistema dentro
do escopo do seu objetivo
Interpretao ampla: todos aqueles que usam o
sistema de alguma forma, o que inclui tambm os
desenvolvedores.

interessante definir uma tabela indicando

que objetivos cada usurio e que interesse
cada stakeholder tem no sistema.

2
7

Objetivos e Interesses
Agente ou
Interessado

Objetivo

Interesse

Prioridade

Cliente

Fazer pedido

Receber o produto
pedido

Cliente

Obter status do
pedido

Prever o prazo de
chegada do pedido

Gerente

Obter lista de pedidos

diria

Saber a produo
diria

Metas

2
8

Justificam a sua existncia para o

negcio.
Um efeito positivo no negcio do cliente
esperado com a implantao do novo
sistema

Benefcios trazidos pelo novo sistema ao

negcio

Metas - Benefcios

2
9

A anlise das metas permite ao cliente

verificar qual a relao custo/benefcio da
implantao de um novo sistema
Baseado nas metas o cliente capaz de
fazer uma avaliao econmico-financeira,
comparando o preo do sistema, ou melhor,
ainda, com o custo total de propriedade (TCO
Total Cost of Ownership) do sistema, com o
valor equivalente dos benefcios trazidos pelo
sistema.

Mtrica

3
0

Uma medida objetiva que permite

comprovar que a meta foi alcanada
Metas que no possuem mtricas objetivas,
como "satisfao do cliente", devem ser
evitadas ou devem ser associadas a um
instrumento de medida que permita verificar
conceitos subjetivos

Se no possvel nenhuma medida, no

ser possvel tambm saber se a meta foi
alcanada, o que a torna suprflua.

Metas/Mtricas - Vantagens

3
1

A principal vantagem de associar

metas ao sistema que no fazem parte
dos requisitos do sistema demonstrar
a utilidade do sistema, isto , como o
sistema faz o cliente ganhar mais
dinheiro ou realizar melhor sua tarefa.

Armadilhas

3
2

muito comum que um cliente deseje

uma meta que no pode ser alcanada
por um sistema com o objetivo definido.
Meta que afetada por muitas coisas
alm do sistema
negociar a mudana da meta ou negociar
a mudana do objetivo.

Metas Subjetivas

3
3

possvel que sejam definidas metas no

mensurveis de forma objetiva. Isso pode ser
resolvido por meio de avaliaes subjetivas.
Por exemplo, uma meta comum melhorar o
atendimento ao usurio.
Essa meta pode, em alguns casos, ser transformada em
outra meta, como diminuir o tempo de atendimento,
diretamente mensurvel.
Mas tambm pode ser medida por meio de entrevistas,
com avaliaes subjetivas, ou observao do servio.

Descrevendo o Sistema Atual

3
4

Uma das tarefas mais importantes

compreender como funciona o sistema atual.
Desprezar o sistema atual, por mais antigo
ou mal feito que ele seja, um dos erros mais
freqentes dos desenvolvedores.
S podemos criar um sistema novo aps
conhecer o sistema atual, como funciona e
porque funciona dessa forma.

Descrevendo o Sistema Atual

3
5

Uma descrio em portugus pode ser

bastante satisfatria para sistemas pequenos.
Para sistemas maiores pode ser necessrio
indicar outras fontes de obteno de
informao, como manuais existentes e os
prprios programas.
Quanto tempo temos?

Viso do Novo Sistema

3
6

Descrio simples de como vai

funcionar o novo sistema linguagem
corrente.
Incluir no s o funcionamento do
sistema, mas tambm expectativas de
comportamento e de efeitos do sistema
no negcio

Viso do Novo Sistema

3
7

Essa viso deve ser escrita com forte apoio

do cliente, seno pelo prprio cliente.
Normalmente a Viso e a descrio do
sistema atual tm o mesmo nvel de abstrao
dentro de uma mesma proposta inicial.
A viso pode incluir o prottipo de algumas
telas do novo sistema,
com a finalidade de mostrar a diferena do
sistema novo para o velho ou ainda mostrar como
ser o comportamento de uma nova finalidade.

Viso do Sistema

3
8

A viso do sistema inclui tambm os

requisitos j detectados, informalmente,
pelo analista.
requisitos funcionais
requisitos de informao
requisitos no funcionais.
Oportunidades

Obviamente,s estamos interessados

em requisitos verdadeiros.

Requisitos Preliminares

3
9

importante registrar todos os

requisitos que forem percebidos durante
essa fase inicial do contato com o cliente.
Esses requisitos aparecem
informalmente, mas devem ser anotados
diligentemente, pois talvez sejam at
mesmo esquecidos por parte do cliente
o que no garante que sejam menos
importantes, apesar de ser um indicativo.

Escopo: Lista in/out

4
0

Uma boa estratgia complementar a

especificao dos requisitos preliminares a
definio do escopo por meio de uma lista
Dentro/Fora (in/out list)
Simplesmente uma tabela contendo tpicos
e a indicao se aquele tpico est dentro ou
no do escopo do sistema.

4
1

Escopo: Lista In/Out

Escopo do Sistema
Tpico
Receber pedido do cliente

Dentro

Fora

Enviar nota fiscal

Atender pedido parcialmente

Analisar crdito

Pontos Crticos de Sucesso

4
2

Questes que, no estando diretamente relacionada

ao desenvolvimento propriamente dito, so essenciais
para o bom andamento do projeto.
Exemplos: compromisso de certos funcionrios,
fornecimento de certa informao, chegada de alguma
mquina ou software, compromisso de entrega de dados ou
equipamentos pelo cliente, etc.

Os pontos crticos devem ser levantados

detalhadamente
Os compromissos do desenvolvedor s podero ser
cumpridos caso os PCS sejam resolvidos
satisfatoriamente.

Restries

4
3

Muitos sistemas tm restries, que devemos

considerar em nossas propostas. Um tipo
importante de restries so as exigncias de
implementao, como banco de dados,
linguagem, sistema operacional, etc.
Quanto mais cedo forem detectadas as
restries, mais cedo o analista evitar que haja
desperdcio de recursos pela equipe de
desenvolvimento.

Riscos

4
4

Todo projeto envolve um conjunto de

que deve ser tratado convenientemente
para garantir o seu sucesso.
A anlise de riscos tem sido usada nos
ltimos anos como uma das melhores
prticas de desenvolvimento de
software.

Riscos

4
5

Em projetos de software encontramos

riscos ligados a vrios fatores:
tamanho, impacto do projeto no negcio,
ao processo escolhido, ao comprador e
clientes do projeto, tecnologia utilizada,
aos ambientes de desenvolvimento, de
testes e operacionais, equipe e outros.

Riscos - Caractersticas

4
6

Incerteza: pois no sabemos se vai acontecer ou no

Perda: associada ao seu acontecimento.
Ao analisar um risco, devemos nos preocupar com
vrias caractersticas, criando uma tabela de risco que
descreva:
o risco propriamente dito,
uma categoria para cada risco,
uma probabilidade e um
impacto (incluindo a perda financeira associada realizao
do risco).
Normalmente o impacto classificado em quatro nveis:
desprezvel, marginal, crtico e catastrfico (quando envolve a
destruio de pessoas fsicas ou jurdicas).

Riscos

4
7

Devemos priorizar o risco.

As melhores prticas indicam que devemos
vigiar atentamente os 10 riscos principais.
comum classificar os riscos multiplicando
suas probabilidades pelos seus impactos.
Ao longo do projeto os riscos sero tratados.
Para isso, principalmente em grandes projetos,
criado um plano de gerenciamento de riscos, que
inclui medidas para evitar, mitigar seus efeitos e
monitorar os riscos.

Glossrio

4
8

Uma das atividades mais importantes da anlise

compreender o domnio da aplicao.
Essa compreenso s pode acontecer se o analista
souber o significado exato das palavras tpicas do
negcio do cliente.
Assim, desde o incio da anlise o analista deve
construir um glossrio, ou seja, um dicionrio
especializado nos termos do negcio do cliente.
No podemos enfatizar demais a importncia de
aprender a linguagem do negcio do cliente. Isso no
s facilita a comunicao como d ao cliente uma
confiana maior no analista.

Um Documento
Sumrio Executivo
Solicitao do cliente
Objetivo
Problemas
Oportunidades
Stakeholders
Objetivos de Negcio e Interesses

Metas e Mtricas
Sistema atual
Viso do novo sistema
Escopo

Requisitos preliminares
Requisitos funcionais preliminares
Requisitos de informao preliminares
Requisitos no funcionais preliminares

Pontos crticos (ou pontos chave)

Restries
Riscos
Glossrio

4
9

Sumrio Executivo

5
0

Texto breve, claro, explicativo.

No possui formato pr-definido.
Serve como base para a compreenso
do sistema e seus limites

Se o cliente ler a proposta,

s isso que vai ler

Professor:
Geraldo Xexo

Contedo:

Proposta Inicial

5
1