Você está na página 1de 9

12/08/2015

Viso

<Nome do Projeto> Viso


Verso <1.0>
[Observao: O template a seguir fornecido para uso com o Rational Unified Process (RUP). O texto entre colchetes e exibido
em itlico, em azul (estilo=InfoBlue), fornecido para orientar o autor e dever ser excludo antes da publicao do documento.
Qualquer pargrafo inserido aps esse estilo ser definido automaticamente como normal (estilo=BodyText).]

Histrico da Reviso
Data

<dd/mmm/aa>

Verso

<x.x>

Descrio

<detalhes>

Autor

<nome
>

ndice Analtico
1. Introduo
1.1.
1.2.
1.3.
1.4.
1.5.

Finalidade
Escopo
Definies, Acrnimos e Abreviaes
Referncias
Viso Geral

2. Posicionamento
2.1. Oportunidade de Negcios
2.2. Descrio do Problema
2.3. Sentena de Posio do Produto
3. Descries dos Envolvidos e dos Usurios
3.1.
3.2.
3.3.
3.4.
3.5.

Demografia dos Mercados


Resumo dos Envolvidos
Resumo dos Usurios
Ambiente do Usurio
Perfis dos Envolvidos
3.5.1.<Nome do Envolvido>
3.6. Perfis dos Usurios
http://www.wthreex.com/rup/webtmpl/templates/req/rup_vision.htm

1/9

12/08/2015

Viso

3.6.1.<Nome do Usurio>
3.7. Principais Necessidades dos Usurios ou dos Envolvidos
3.8. Alternativas e Concorrncia
3.8.1.<aCompetitor>
3.8.2.<anotherCompetitor>
4. Viso Geral do Produto
4.1.
4.2.
4.3.
4.4.
4.5.

Perspectiva do Produto
Resumo dos Recursos
Suposies e Dependncias
Custos e Preos
Licenciamento e Instalao

5. Recursos do Produto
5.1. <aFeature>
5.2. <anotherFeature>
6. Restries
7. Intervalos de Qualidade
8. Precedncia e Prioridade
9. Outros Requisitos do Produto
9.1.
9.2.
9.3.
9.4.

Padres Aplicveis
Requisitos do Sistema
Requisitos de Desempenho
Requisitos Ambientais

10. Requisitos de Documentao


10.1. Manual do Usurio
10.2. Ajuda Online
10.3. Guias de Instalao e de Configurao, e Arquivo Leiame
10.4. Rotulao e Embalagem
A

Atributos de Recursos

Viso
1.

Introduo

[A finalidade deste documento coletar, analisar e definir necessidades e recursos de nvel superior do <<Nome do
Sistema>>. Ele se concentra nos recursos necessrios aos envolvidos e aos usuriosalvo e nas razes que levam a essas
necessidades. Os detalhes de como o <<Nome do Sistema>> satisfaz essas necessidades so descritos no caso de uso e nas
especificaes suplementares.]
[A introduo do documento Viso fornece uma viso geral de todo o seu contedo. Ela deve incluir a finalidade, o escopo, as
definies, os acrnimos, as abreviaes, as referncias e a viso geral deste documento Viso.]
1.1

Finalidade

[Especifique a finalidade deste documento Viso.]


1.2
Escopo
[Uma breve descrio do escopo deste documento Viso a que Projeto(s) ele est associado e tudo o mais que seja afetado ou
influenciado por este documento.]
1.3

Definies, Acrnimos e Abreviaes

[Esta subseo fornece as definies de todos os termos, acrnimos e abreviaes necessrias adequada interpretao do
documento Viso. Essas informaes podem ser fornecidas fazendo referncias ao Glossrio do projeto.]
1.4
Referncias
[Esta subseo fornece uma lista completa de todos os documentos mencionados em qualquer outra parte do documento
Viso. Identifique cada documento por ttulo, nmero do relatrio (se aplicvel), data e organizao de publicao.
http://www.wthreex.com/rup/webtmpl/templates/req/rup_vision.htm

2/9

12/08/2015

Viso

Especifique as fontes a partir das quais as referncias podem ser obtidas. Essas informaes podem ser fornecidas por um
anexo ou outro documento.]
1.5
Viso Geral
[Esta subseo descreve o que o restante do documento Viso contm e explica como o documento est organizado.]

2.

Posicionamento

2.1
Oportunidade de Negcios
[Faa uma breve descrio da oportunidade de negcios atendida por este projeto.]
2.2

Descrio do Problema

[Fornea uma descrio resumindo o problema que est sendo resolvido pelo projeto. Poder ser usado este formato:]

2.3

O problema de

[descreva o problema]

afeta

[os envolvidos afetados pelo problema]

cujo impacto

[qual o impacto do problema?]

uma boa soluo seria

[liste alguns dos principais benefcios de uma boa soluo]

Sentena de Posio do Produto

[Fornea uma sentena geral resumindo, no nvel mais alto, a posio exclusiva que o produto pretende ocupar no mercado.
Poder ser usado este formato:]
Para

[clientealvo]

Que

[indique a necessidade ou oportunidade]

O (nome do produto)

um(a) [categoria do produto]

Que

[indique o principal benefcio ou seja, a razo convincente que


motiva a compra]

Diferente de

[principal alternativa da concorrncia]

Nosso produto

[indique a principal diferena]

[Uma sentena de posio do produto comunica o objetivo do aplicativo e a importncia do projeto para todo o pessoal envolvido.]

3.

Descries dos Envolvidos e dos Usurios

[Para fornecer, de maneira eficiente, produtos e servios que atendam s reais necessidades dos usurios e dos envolvidos,
necessrio identificar e considerar todos os envolvidos como parte do processo de Modelagem de Requisitos. necessrio tambm
identificar os usurios do sistema e assegurar que a comunidade de envolvidos os represente adequadamente. Esta seo fornece
um perfil dos envolvidos e dos usurios que integram o projeto, e dos principais problemas que, de acordo com o ponto de vista
deles, podero ser abordados pela soluo proposta. Ela no descreve as solicitaes ou os requisitos especficos dos usurios e dos
envolvidos, j que eles so capturados em um artefato individual de solicitaes dos evolvidos. Em vez disso, ela fornece a base e a
justificativa que explicam por que os requisitos so necessrios.]
3.1
Demografia dos Mercados
[Resuma as principais demografias do mercado que motivam as decises do produto. Descreva e posicione os segmentos do
mercadoalvo. Avalie o tamanho e o crescimento do mercado utilizando o nmero de usurios em potencial ou o montante que seus
clientes gastam tentando suprir necessidades que podem ser atendidas pelo seu produto ou melhoria. Revise as principais
tendncias e tecnologias do setor. Responda a estas perguntas estratgicas:
Qual a reputao de sua organizao nesses mercados?
Qual voc gostaria que fosse?
De que maneira este produto ou servio o ajuda a atingir suas metas?]
Resumo dos Envolvidos

1.

[H uma srie de envolvidos que se interessam pelo desenvolvimento e nem todos eles so usurios finais. Apresente uma lista
resumida desses envolvidos que no so usurios. (O resumo dos usurios encontrase na seo 3.3.)]
Nome

Descrio

http://www.wthreex.com/rup/webtmpl/templates/req/rup_vision.htm

Responsabilidades

3/9

12/08/2015

Viso

[Especifique o nome do tipo de [Descreva brevemente o envolvido.]


envolvido.]

[Resuma as principais
responsabilidades do envolvido no
que diz respeito ao sistema que est
sendo desenvolvido ou seja, seu
interesse como envolvido. Por
exemplo, este envolvido:
assegura que o sistema poder ser
mantido
assegura que haver uma demanda de
mercado pelos recursos do produto
monitora o andamento do projeto
aprova financiamentos
e assim por diante]

Resumo dos Usurios

1.

[Apresente uma lista resumida de todos os usurios identificados.]


Nome
[Informe
tipo
usurio.]

o
de

Descrio

Responsabilidades

Envolvido

[Descreva
brevemente o que
ele representa no
que diz respeito ao
sistema.]

[Liste as principais
responsabilidades do usurio em relao ao
sistema que est sendo desenvolvido por
exemplo:

[Se o usurio no for representado


diretamente, identifique o envolvido
responsvel por representar os
interesses dele.]

percebe os detalhes
elabora relatrios
coordena o trabalho
e assim por diante]

Ambiente do Usurio

1.

[Descreva o ambiente de trabalho do usurioalvo. A seguir so apresentadas algumas sugestes:


Nmero de pessoas envolvidas na execuo da tarefa? Isso est mudando?
Qual a durao de um ciclo de tarefas? Qual o tempo gasto em cada atividade? Isso est mudando?
Quaisquer restries ambientais exclusivas: telefone celular, ambientes ao ar livre, uso em aeronaves e assim por
diante?
Quais plataformas de sistema esto sendo utilizadas atualmente? Plataformas futuras?
Que outros aplicativos esto em uso? necessrio que o seu aplicativo interaja com eles?
Nesse ponto, voc poder incluir textos provenientes do Modelo de Negcios para descrever a tarefa e os trabalhadores de negcio
envolvidos, entre outros.]
Perfis dos Envolvidos

1.

[Descreva aqui cada envolvido no sistema preenchendo a tabela abaixo para cada um deles. Lembre se de que os tipos de
envolvidos podero ser os mais diversos como, por exemplo, usurios, departamentos e desenvolvedores tcnicos. Um perfil
completo deve abranger os tpicos abaixo para cada tipo de envolvido.] 3.5.1
<Nome do Envolvido>
Representante

[Quem o representante do envolvido no projeto? (Opcional se j estiver


documentado em outro lugar.) Especifique aqui o nome da pessoa.]

Descrio

[Breve descrio do tipo de envolvido.]

Tipo

[Qualifique a habilidade, a formao tcnica e o grau de sofisticao do envolvido ou


seja, se ele um guru, executivo, especialista, usurio eventual e assim por diante.]

http://www.wthreex.com/rup/webtmpl/templates/req/rup_vision.htm

4/9

12/08/2015

Viso

Responsabilidades

[Liste as principais responsabilidades do envolvido no que diz respeito ao sistema


que est sendo desenvolvido ou seja, seu interesse como envolvido.]

Critrios de Sucesso

[Como o envolvido define sucesso?


De que forma o envolvido recompensado?]

Envolvimento

[Qual o grau de comprometimento do envolvido no projeto? Faa referncia,


quando possvel, aos papis exercidos no Rational Unified Process ou seja, Revisor
de Requisitos etc.]

Produtos Liberados

[Existem outros produtos liberados exigidos pelo envolvido? Eles podem ser
produtos liberados do projeto ou sadas do sistema em desenvolvimento.]

Comentrios /
Problemas

[Os problemas que interferem no bom andamento do projeto e outras informaes


relevantes sero relacionados aqui.]

Perfis dos Usurios

1.

[Descreva cada usurio nico do sistema preenchendo a seguinte tabela para cada tipo de usurio. Lembrese de que os tipos de
usurio podero ser os mais diversos como, por exemplo, gurus e principiantes. Por exemplo, um guru poder precisar de uma
ferramenta flexvel sofisticada com suporte a plataformas cruzadas, enquanto um principiante poder precisar de uma ferramenta
amigvel e de fcil utilizao. Um perfil completo abranger os seguintes tpicos para cada tipo de usurio.] 3.6.1
<Nome
do Usurio>
Representante

[Quem o representante do usurio no projeto? (Opcional se estiver documentado


em outro lugar.) Freqentemente referese ao Envolvido que representa o conjunto
de usurios como, por exemplo, Envolvido: Envolvido1.]

Descrio

[Uma breve descrio do tipo de usurio.]

Tipo

[Qualifique a experincia do usurio, sua formao tcnica e grau de sofisticao ou


seja, guru, usurio eventual etc.]

Responsabilidades

[Liste as principais responsabilidades do usurio no que diz respeito ao sistema que


est sendo desenvolvido ou seja, se ele captura detalhes, produz relatrios, coordena
o trabalho etc.]

Critrios de Sucesso

[Como o usurio define o sucesso?


Como o usurio recompensado?]

Envolvimento

[Como o usurio est envolvido no projeto? Faa referncia, quando possvel, aos
papis exercidos no Rational Unified Process ou seja, Revisor de Requisitos etc.]

Produtos Liberados

[O usurio produz algum produto que liberado? Em caso positivo, para quem?]

Comentrios /
Problemas

[Problemas que interferem no sucesso e quaisquer outras informaes


relevantes devem ser especificados aqui. Entre eles podero estar includas
tendncias que facilitam ou dificultam o trabalho do usurio.]

1.

Principais Necessidades dos Usurios ou dos Envolvidos

[Liste os principais problemas com as solues existentes conforme o ponto de vista do envolvido. Esclarea as seguintes questes
referentes a cada problema:
Quais so as causas deste problema?
Como ele est sendo resolvido agora?
Que solues o envolvido ou o usurio deseja?]
[ importante compreender a importncia relativa exercida pelo usurio ou pelo envolvido na resoluo de cada problema. As
tcnicas de ordenao e votao cumulativa indicam os problemas que devem ser resolvidos versus problemas que eles
gostariam que fossem resolvidos.
Preencha a tabela a seguir se estiver usando o Rational RequisitePro para capturar as Necessidades, pode ser um fragmento ou
relatrio dessa ferramenta.]
Necessidade

Prioridade

Preocupaes

http://www.wthreex.com/rup/webtmpl/templates/req/rup_vision.htm

Soluo Atual

Solues Propostas
5/9

12/08/2015

Viso

Transmitir mensagens

3.8

Alternativas e Concorrncia

[Identifique as alternativas disponveis consideradas pelos envolvidos. Isso inclui adquirir um produto do concorrente, desenvolver
uma soluo prpria ou simplesmente manter o estado atual. Liste todas as opes conhecidas que a concorrncia oferece ou que
podem se tornar disponveis. Inclua os principais pontos fortes e pontos fracos de cada concorrente segundo o ponto de vista do
envolvido ou do usurio final.]

4.

1.

<aCompetitor>

2.

<anotherCompetitor>

Viso Geral do Produto

[Esta seo fornece uma viso de nvel superior dos recursos, interfaces com outros aplicativos e configuraes de sistemas do
produto. Ela geralmente constituda destas trs subsees:

Perspectiva do produto

Funes do produto

Suposies e dependncias]
1.

Perspectiva do Produto

[Esta subseo do documento Viso analisa o produto em relao a outros produtos relacionados e ao ambiente do usurio. Se o
produto for independente e totalmente autosuficiente, exponha isso aqui. Se o produto for um componente de um sistema maior,
esta subseo relatar como esses sistemas interagem e identificar as interfaces relevantes entre os sistemas. Uma maneira fcil de
exibir os principais componentes do sistema maior, suas interconexes e interfaces externas atravs de um diagrama de bloco.]
2.

Resumo dos Recursos

[Resuma os principais benefcios e recursos que o produto fornecer. Por exemplo, um documento Viso referente a um
sistema de suporte ao cliente poder usar esta parte para abordar a documentao de problemas, o roteamento e a
elaborao de relatrios de status sem mencionar a quantidade de detalhes necessria a cada uma dessas funes.
Organize as funes de modo que a lista possa ser compreendida pelo cliente ou por qualquer pessoa que esteja lendo o
documento pela primeira vez. Uma tabela simples relacionando os principais benefcios e seus recursos de suporte poder ser
suficiente. Por exemplo:]
Tabela 41 Sistema de Suporte ao Cliente
Benefcio para o Cliente

Recursos de Suporte

Novas equipes de suporte podero ficar


rapidamente informadas do processo.

Uma base de conhecimentos ajuda o pessoal de


suporte a identificar rapidamente aes corretivas
e solues conhecidas.

A satisfao do cliente melhorada Os problemas so relacionados como itens nicos,


porque nada negligenciado.
classificados e monitorados ao longo de todo o
processo de resoluo. So emitidas notificaes
automticas para os problemas que tm seus
prazos expirados.
O gerenciamento pode identificar reas
de problemas e estimar a carga de
trabalho da equipe.

Os relatrios de tendncias e de distribuio


permitem revises de nvel superior do status
dos problemas.

Equipes de suporte distribudas podem


trabalhar em conjunto para solucionar
problemas.

Um servidor de duplicao permite que as


informaes atuais do banco de dados sejam
compartilhadas pela empresa.

Os clientes tm autonomia para resolver Uma base de dados pode ser disponibilizada na
seus problemas, o que reduz os custos de Internet. Ela contm recursos de pesquisa de
suporte e melhora o tempo de resposta.
hipertexto e um mecanismo de consulta grfico.
1.

Suposies e Dependncias

[Liste cada fator que afeta os recursos especificados no documento Viso. Liste as suposies que, se sofrerem mudanas, alteraro
o documento Viso. Por exemplo, uma suposio poder estabelecer que um sistema operacional especfico estar disponvel para
http://www.wthreex.com/rup/webtmpl/templates/req/rup_vision.htm

6/9

12/08/2015

Viso

o hardware projetado para o produto de software. Se o sistema operacional no estiver disponvel, o documento Viso ter que ser
alterado.]
3.

Custos e Preos

[Para produtos vendidos para clientes externos e para muitos aplicativos internos, as questes de custos e preos podero exercer
impacto direto na definio e na implementao dos aplicativos. Nesta seo, registre quaisquer restries de custo e de preos que
sejam relevantes. Por exemplo, os custos de distribuio (nmero de disquetes, nmero de CDROMs, masterizao de CDs) ou
outras restries de custo de produtos vendidos (manuais, embalagem) podero ser importantes para o xito dos projetos, ou
irrelevantes, dependendo da natureza do aplicativo.]
4.

Licenciamento e Instalao

[As questes de licenciamento e de instalao podero exercer impacto direto no esforo de desenvolvimento. Por exemplo, a
necessidade de suportar a serializao, a segurana das senhas ou o licenciamento de rede criar requisitos adicionais do sistema
que devero ser considerados no esforo de desenvolvimento.
Os requisitos de instalao tambm podero afetar a codificao ou criar a necessidade de softwares de instalao individual.]

5.

Recursos do Produto

[Liste e descreva brevemente os recursos do produto. Tratase dos recursos de nvel superior do sistema que so necessrios para
propiciar benefcios aos usurios. Cada recurso um servio desejado externamente que normalmente exige uma srie de entradas
para alcanar os resultados desejados. Por exemplo, um dos recursos de um sistema de rastreamento de problemas poder ser a
capacidade de fornecer relatrios de tendncias. medida que o modelo de casos de uso for desenvolvido, atualize a descrio
para fazer referncia aos casos de uso.
Como o documento Viso revisado por uma ampla variedade de pessoas envolvidas, o nvel de detalhamento ter que ser
genrico o bastante para que todos possam compreendlo. No entanto, devem estar disponveis detalhes suficientes para fornecer
equipe as informaes necessrias para criar um modelo de casos de uso.
Para gerenciar a complexidade dos aplicativos de maneira eficiente, recomendvel para qualquer sistema novo, ou para uma
adio que complemente um sistema existente, que seja utilizado um grau de abstrao de nvel suficientemente elevado de modo
a resultar em 25 a 99 recursos. Esses recursos sero a base fundamental do gerenciamento do projeto, do gerenciamento do
escopo e da definio do produto. Cada recurso ser descrito mais detalhadamente no modelo de casos de uso.
Em toda esta seo, cada recurso ser percebido externamente por usurios, operadores ou outros sistemas externos. Esses
recursos devero incluir uma descrio da funcionalidade e de todas as questes de usabilidade relevantes que devero ser
abordadas. As seguintes diretrizes se aplicam:
Evite o design. Mantenha as descries dos recursos em um nvel geral. Concentrese nos recursos necessrios e no porqu (e no
em como) eles devero ser implementados.
Se estiver usando o kit de ferramentas do Rational RequisitePro, tudo ter que ser selecionado como requisitos de tipo para
facilitar a consulta e o rastreamento.]
1.

<aFeature>

2.

<anotherFeature>

6.
Restries
[Mencione quaisquer restries de design, restries externas ou outras dependncias.]

7.

Intervalos de Qualidade
[Defina os intervalos de qualidade para desempenho, robustez, tolerncia a erros, usabilidade e caractersticas semelhantes que no
so capturadas no Conjunto de Recursos.]

8.

Precedncia e Prioridade

[Defina a prioridade dos diferentes recursos do sistema.]

9.

Outros Requisitos do Produto

[Em um nvel superior, liste padres aplicveis, requisitos de hardware ou de plataforma, requisitos de desempenho e requisitos
ambientais.]
9.1

Padres Aplicveis

[Liste todos os padres com os quais o produto dever estar em conformidade. Entre eles, podero estar includos padres
legais e reguladores (FDA, UCC), padres de comunicaes (TCP/IP, ISDN), padres de conformidade com plataformas
(Windows, UNIX etc) e padres de qualidade e de segurana (UL, ISO, CMM).]
9.2

Requisitos do Sistema

http://www.wthreex.com/rup/webtmpl/templates/req/rup_vision.htm

7/9

12/08/2015

Viso

[Defina todos os requisitos do sistema necessrios para suportar o aplicativo. Entre eles, podero estar includos os sistemas
operacionais de host e as plataformas de rede suportados, configuraes, memria, perifricos e software fornecido.]
9.3
Requisitos de Desempenho
[Use esta seo para descrever os requisitos de desempenho. Os problemas de desempenho podem abranger itens como fatores de
carga do usurio, largura de banda ou capacidade de comunicao, taxa de transferncia, preciso e confiabilidade ou tempos de
resposta em uma srie de condies de carregamento.]
9.4

Requisitos Ambientais

[Descreva os requisitos ambientais quando necessrio. Para sistemas baseados em hardware, as questes ambientais podero
incluir temperatura, choques, umidade, radiao etc. Para aplicativos de software, os fatores ambientais podem incluir condies de
uso, ambiente do usurio, disponibilidade de recursos, problemas de manuteno, e recuperao e tratamento de erros.]

10.

Requisitos de Documentao

[Esta seo descreve a documentao que dever ser desenvolvida para suportar a implantao bemsucedida de aplicativos.]
10.1
Manual do Usurio
[Descreva a finalidade e o contedo do Manual do Usurio. Discuta questes como o tamanho desejado, o nvel de
detalhamento, a necessidade de um ndice, o uso de um glossrio de termos, estratgia de tutorial versus de manual de
referncia etc. As restries de formatao e de impresso tambm devero ser identificadas.]
10.2

Ajuda Online

[Muitos aplicativos fornecem um sistema de ajuda online para auxiliar o usurio. A natureza desses sistemas exclusiva do
desenvolvimento do aplicativo j que eles combinam aspectos de programao (hyperlinks etc) com aspectos de escrita tcnica
como, por exemplo, organizao e apresentao. Muitos perceberam que o desenvolvimento de um sistema de ajuda online um
projeto que est contido em outro projeto, beneficiandose do gerenciamento adiantado do escopo e da atividade de planejamento.]
10.3

Guias de Instalao e de Configurao, e Arquivo Leiame

[Um documento que inclua instrues de instalao e diretrizes de configurao importante para se oferecer uma soluo
completa. Alm disso, um arquivo Leiame normalmente includo como um componente padro. O arquivo Leiame poder incluir
uma seo "O Que H de Novo Neste Release" e uma discusso dos problemas de compatibilidade em relao aos releases
anteriores. A maior parte dos usurios tambm considera desejvel que o arquivo Leiame documente erros e solues conhecidos.]
10.4
Rotulao e Embalagem
[Os aplicativos modernos atuais apresentam uma aparncia consistente que percebida inicialmente na embalagem do produto e se
propaga pelos menus de instalao, telas iniciais, sistemas de ajuda, caixas de dilogo GUI etc. Esta seo define as necessidades e
os tipos de rotulao a serem incorporados no cdigo. Como exemplos, podemos citar observaes sobre direitos autorais e
patentes, logotipos corporativos, cones padronizados, outros elementos grficos etc.] A
Atributos de Recursos
[So designados atributos para os recursos que podem ser usados para avaliar, rastrear, priorizar e gerenciar os itens do produto
cuja implementao foi proposta. Todos os atributos e tipos de requisitos so descritos no Plano de Gerenciamento de Requisitos.
No entanto, talvez seja conveniente listar e descrever brevemente os atributos referentes aos recursos que foram escolhidos. As
subsees a seguir representam um conjunto de atributos de recursos sugeridos.]
A.1

Status

[Definido pela equipe de gerenciamento do projeto aps a negociao e a reviso. Controla o andamento durante a definio da
baseline do projeto.]

A.2

Proposto

[Usado para descrever recursos que esto sendo discutidos, mas que ainda
no foram revisados e aceitos pelo "canal oficial" como, por exemplo, um
grupo de trabalho formado por representantes da equipe do projeto, do
gerenciamento do produto e da comunidade de usurios ou de clientes.]

Aprovado

[Recursos que so considerados teis e viveis, e cuja implementao foi


aprovada pelo canal oficial.] ]

Incorporado

[Recursos incorporados baseline do produto em um momento especfico


no tempo.]

Benefcio

[Definido pelo departamento de marketing, pelo gerente do produto ou pelo analista de negcios. Todos os requisitos diferem entre
si. A classificao dos requisitos por seu benefcio relativo para o usurio final inicia um dilogo com os clientes, analistas e
membros da equipe de desenvolvimento. Usado no gerenciamento do escopo e na determinao da prioridade de
desenvolvimento.]
Crtico

[Recursos essenciais. Sua no implementao implica que o sistema no


atender s necessidades do cliente. Todos os recursos crticos devero ser

http://www.wthreex.com/rup/webtmpl/templates/req/rup_vision.htm

8/9

12/08/2015

Viso

implementados no release ou a programao ser retardada.]

A.3

Importante

[Recursos importantes para a eficcia e a eficincia do sistema da maior


parte dos aplicativos. A funcionalidade no poder ser fornecida facilmente
de outra maneira. Caso um recurso importante no seja includo, a satisfao
do cliente ou do usurio, ou at a receita, podero ser afetadas, mas isso no
retardar o release.]

til

[Os recursos que so teis em aplicativos menos tpicos ou para os quais


possam se obter solues razoavelmente eficientes sero usados com menor
freqncia. No se pode esperar nenhum impacto significativo na receita ou
na satisfao do cliente se esse tipo de recurso no for includo em um
release.]

Esforo

[Definido pela equipe de desenvolvimento. Como algumas funcionalidades necessitam de mais tempo e de mais recursos do que
outras, estimar o nmero de semanas de participao de cada pessoa ou equipe, as linhas de cdigo necessrias ou os pontos de
funo, por exemplo, a melhor maneira de avaliar a complexidade e definir expectativas do que poder ou no ser feito em um
determinado perodo de tempo. Usado no gerenciamento do escopo e na determinao da prioridade de desenvolvimento.]
A.4

Risco

[Definido pela equipe de desenvolvimento com base na probabilidade de ocorrerem eventos indesejveis no projeto como, por
exemplo, custos excessivos, atrasos na programao ou at cancelamentos. A maior parte dos gerentes de projeto considera que a
categorizao dos riscos em altos, mdios e baixos suficiente, embora sejam possveis gradaes ainda mais especficas.
Freqentemente os riscos podero ser avaliados indiretamente medindose o grau de incerteza (intervalo) da estimativa de
programao da equipe dos projetos.]
A.5
Estabilidade
[Este atributo definido pelo analista e pela equipe de desenvolvimento com base na probabilidade de o recurso sofrer mudanas
ou na probabilidade de a equipe vir a compreender o recurso de uma forma diferente. usado para ajudar a estabelecer
prioridades de desenvolvimento e determinar os itens para os quais uma averiguao adicional a prxima ao apropriada.]
A.6

Releasealvo

[Registra a verso planejada do produto em que o recurso aparecer pela primeira vez. Este campo poder ser usado para alocar
recursos de um documento Viso em um release de baseline especfico. Quando for usado em conjunto com o campo de status, sua
equipe poder propor, registrar e discutir vrios recursos do release sem que tenham que ser necessariamente desenvolvidos.
Somente sero implementados os recursos cujo Status estiver definido como Incorporado e cujo Releasealvo estiver definido.
Quando ocorrer o gerenciamento de escopo, o Nmero da Verso do Releasealvo poder ser aumentado de modo que o item
permanea no documento Viso, mas seja programado para um release posterior.]
A.7

Atribudo a

[Em muitos projetos, os recursos sero atribudos a "equipes de recursos" responsveis por averiguar e por escrever os requisitos
do software, e tambm por sua implementao. Esta lista suspensa simples ajudar a todos da equipe do projeto a
compreenderem melhor suas responsabilidades.]
A.8
Razo
[Este campo de texto usado para rastrear a origem do recurso solicitado. Os requisitos existem devido a razes especficas. Este
campo registra uma explicao ou uma referncia a uma explicao. Por exemplo, a referncia poder ser ao nmero de uma linha
e de uma pgina de uma especificao de requisitos do produto ou a um minsculo marcador em um vdeo de uma entrevista com
um cliente importante.]

http://www.wthreex.com/rup/webtmpl/templates/req/rup_vision.htm

9/9