Documentacao Geral

Glossrio
Glossrio
Pgina 1 de 5
Artefatos >
Conjunto de Artefatos de Requisitos >
Glossrio >
rup_gloss.htm
<Nome do Projeto> Glossrio

Verso <1.0>
[Observao: O template a seguir fornecido para uso com o Rational Unified Process (RUP). O texto em azul exibido entre colchetes e em itlico (style=InfoBlue) foi includo para orientar o autor e deve ser excludo antes da publicao do documento. Qualquer pargrafo inserido aps esse estilo ser definido automaticamente como normal (estilo=BodyText).]
file://E:\7AOJ\UML\Templates_PT\Glossrio.htm
14/9/2010
Glossrio
Pgina 2 de 5
Histrico da Reviso
Data <dd/mmm/aa> Verso <x.x> Descrio <detalhes> <nome> Autor
14/9/2010
Glossrio
Pgina 3 de 5
ndice Analtico
1. Introduo 1.1 Finalidade 1.2 Escopo 1.3 Referncias 1.4 Viso Geral 2. Definies 2.1 <aTerm> 2.2 <anotherTerm> 2.3 <aGroupOfTerms> 2.3.1 <aGroupTerm> 2.3.2 <anotherGroupTerm> 2.4 <aSecondGroupOfTerms> 2.4.1 <yetAnotherGroupTerm> 2.4.2 <andAnotherGroupTerm> 3. Esteretipos de UML
14/9/2010
Glossrio
Pgina 4 de 5
Glossrio
1. Introduo
[A introduo do Glossrio fornece uma viso geral de todo o documento. Apresente todas as informaes que podero ser necessrias para que o leitor compreenda o documento nesta seo. Este documento usado para definir a terminologia especfica do domnio do problema, explicando termos que podem ser desconhecidos do leitor das descries de caso de uso ou de outros documentos do projeto. Freqentemente, este documento poder ser usado como um dicionrio de dados informal, capturando definies de dados para que as descries de caso de uso e outros documentos do projeto possam concentrar-se no que o sistema deve fazer com as informaes. Este documento dever ser salvo em um arquivo denominado Glossrio.] 1.1 1.2 Finalidade [Especifique a finalidade deste Glossrio.] Escopo [Uma breve descrio do escopo deste Glossrio; a que Projeto(s) ele est associado e tudo o mais que seja afetado ou influenciado por este documento.] Referncias [Esta subseo fornece uma lista completa de todos os documentos mencionados em qualquer outra parte do Glossrio. Identifique cada documento por ttulo, nmero do relatrio (se aplicvel), data e organizao de publicao. Especifique as fontes a partir das quais as referncias podem ser obtidas. Essas informaes podem ser fornecidas por um anexo ou outro documento.] Viso Geral [Esta subseo descreve o que o restante do Glossrio contm e explica como o documento est organizado.]
1.3
1.4
2.
Definies
[Os termos definidos aqui so a essncia do documento. Eles podero ser definidos na ordem desejada, mas geralmente a ordem alfabtica propicia maior acessibilidade.]
2.1
<aTerm> [A definio de <aTerm> apresentada aqui. Voc dever apresentar quantas informaes forem necessrias para que o leitor compreenda o conceito.]
2.2
<anotherTerm> A definio de <anotherTerm> apresentada aqui. Voc dever apresentar quantas informaes forem necessrias para que o leitor compreenda o conceito
2.3
<aGroupofTerms> [s vezes, til organizar os termos em grupos para aprimorar a legibilidade. Por exemplo, se o domnio do problema contiver termos relacionados a contabilidade e a construo de prdios (como seria o caso se estivssemos desenvolvendo um sistema para gerenciar projetos de construo), apresentar os termos dos dois subdomnios diferentes poder gerar confuso para o leitor. Para resolver o problema, utilizamos agrupamentos de termos. Ao apresentar os agrupamentos de termos, fornea uma breve descrio que ajude o leitor a compreender o que <aGroupOfTerms> representa. Os termos apresentados no grupo devero ser organizados alfabeticamente para possibilitar um fcil acesso.]
2.3.1
<aGroupTerm> [A definio de <aGroupTerm> apresentada aqui. Apresente quantas informaes forem necessrias para que o leitor compreenda o conceito.]
2.3.2
<anotherGroupTerm> [A definio de <anotherGroupTerm> apresentada aqui. Apresente quantas informaes forem necessrias para que o leitor compreenda o conceito.] <aSecondGroupofTerms> <yetAnotherGroupTerm> [A definio do termo apresentada aqui. Apresente quantas informaes forem necessrias para que o leitor compreenda o conceito.] <andAnotherGroupTerm> [A definio do termo apresentada aqui. Apresente quantas informaes forem necessrias para que o leitor
2.4 2.4.1
2.4.2
14/9/2010
Glossrio
Pgina 5 de 5
compreenda o conceito.]
3.
Esteretipos de UML
[Esta seo contm ou faz referncia a especificaes de esteretipos de Linguagem de Modelagem Unificada (UML) e suas implicaes semnticas - uma descrio textual do significado e da importncia dos esteretipos e de quaisquer limitaes de seu uso - para esteretipos j conhecidos ou que se mostraram importantes para o sistema que est sendo modelado. O uso desses esteretipos pode ser simplesmente recomendado ou at mesmo obrigatrio; por exemplo, quando o uso desses esteretipos for exigido por um padro imposto ou quando se considerar que o uso facilitar em muito o entendimento. Esta seo poder ficar em branco se no for considerado necessrio nenhum esteretipo adicional alm dos predefinidos pela UML e pelo Rational Unified Process.]
14/9/2010
CSPS Glossary 1.0
Pgina 1 de 2
Sistema de Mensagens do Collegiate Sports Glossary

Verso 1.0
Histrico da Reviso
Data 12 de outubro de 1999
ndice Analtico
Verso 1.0
Descrio Verso inicial
Autor Integrao do Contexto
Introduo Definies
Introduo
Finalidade O glossrio contm as definies de funcionalidade de todas as classes do Sistema de Mensagens do Collegiate Sports. Este glossrio ser expandido durante toda a vida do projeto. Escopo Este glossrio trata de todos os termos que possuem significados especficos neste projeto. Os atores no esto listados aqui porque sero descritos de forma mais detalhada nas definies de caso de uso.
Definies
Contedo O contedo consiste em toda a mdia pela qual uma reportagem de notcias ou de evento esportivo pode ser transmitida a um usurio. Isso pode incluir texto, elementos grficos, vdeo ou som. Pager O pager um dispositivo capaz de receber uma mensagem alfanumrica. Um telefone celular pode agir como pager, assim como o e-mail. Neste projeto, todos esses dispositivos sero considerados pagers. Assinatura Uma assinatura um acordo entre um cliente e o WebNewsOnLine de entregar pginas quando ocorrerem eventos em reas especficas relacionadas a esporte (como
file://E:\7AOJ\UML\Templates_PT\CSPS Glossary 1_0.htm
14/9/2010
CSPS Glossary 1.0
Pgina 2 de 2
o NCAA Basketball). Site na Web O site na Web do Sistema de Mensagens do Collegiate Sports um sistema de computador que um usurio acessa usando softwares comerciais de navegador da Web. Os assinantes recebero telas personalizadas do contedo que podem acessar.
Copyright 1987 -2001 Rational Software Corporation
file://E:\7AOJ\UML\Templates_PT\CSPS Glossary 1_0.htm
14/9/2010
Relatrio Sinttico
Relatrio Sinttico de Modelo de Casos de Uso do CSPS
Pgina 1 de 12
Sistema de Mensagens do Collegiate Sports Relatrio Sinttico de Modelo de Casos de Uso

Verso 1.0
Histrico da Reviso
Data 13 de outubro de 1999 Verso 1.0 Descrio Verso inicial Autor Integrao do Contexto
ndice Analtico
Introduo Catlogo de Atores Aprovar a Reportagem Editar o Perfil Pagar Taxa com Carto de Crdito Imprimir Relatrios do Anunciante Fornecer Feedback Colocar Contedo Publicitrio Ler Contedo no Site da Web Enviar Contedo Enviar Pgina Assinar Relatrio Sinttico de Modelo de Casos de Uso
Introduo
Finalidade Este relatrio faz uma descrio abrangente do modelo de casos de uso, mostrando o modo como ele est estruturado em pacotes e os casos de uso e os atores que existem nele. Escopo Esse Relatrio Sinttico de Modelo de Casos de Uso aplica-se ao Sistema de Mensagens do Collegiate Sports, que ser desenvolvido pela Integrao de Contexto. Esse sistema permitir que os assinantes sejam notificados de eventos relacionados a equipes ou esportes universitrios dos quais eles fizeram uma assinatura, e permitir que eles vejam o contedo que assinaram. Definies, Acrnimos e Abreviaes Consulte Glossrio.
file://E:\7AOJ\UML\Templates_PT\Relatrio Sinttico de Modelo de Casos de Uso do ... 14/9/2010
Pgina 2 de 12
Referncias Nenhuma.
Catlogo de Atores
Nome Assinante Descrio Um Assinante um indivduo que paga a WebNewsOnLine para enviar contedo personalizado e pginas alfanumricas quando ocorrerem eventos de seu interesse. Os Assinantes especificam, atravs de um perfil, em quais categorias de contedo eles esto interessados. O Anunciante uma entidade que paga a WebNewsOnLine para exibir contedo publicitrio a assinantes e assinantes potenciais. Os anunciantes tambm colocam contedo publicitrio no site da Web. O Editor um funcionrio da WebNewOnLine que categoriza, modifica, aprova ou rejeita contedo e contedo publicitrio. O Servio de Mensagens um sistema que transmite pginas alfanumricas para dispositivos de mensagens. O Gateway de Pager um sistema que junta as pginas a serem enviadas aos assinantes, as formata e as transmite para o servio de mensagens. O sistema atualmente fornece notcias no personalizadas on-line e contedo sobre esporte. Um Assinante Potencial uma pessoa que ainda no assinante do Sistema de Mensagens do Collegiate Sports, mas que pode vir a ser.
Anunciante
Editor
Servio de Mensagens
Gateway de Pager
Sistema Atual da WebNewsOnLine Assinante Potencial
Aprovar a Reportagem
Breve Descrio Este Caso de Uso ocorre quando um editor aprova uma reportagem para ser includa no Sistema de Mensagens do Collegiate Sports. Algumas reportagens sero propagadas automaticamente a partir do sistema da WebNewsOnLine existente, mas algumas precisaro da interveno do editor (porque o assunto no est claro ou as categorias a que a reportagem pertence no esto claras). Esse fluxo tambm usado para aprovar o contedo publicitrio que est sendo colocado.
Pgina 3 de 12
Fluxo de Eventos
Fluxo Bsico 1. 2. 3. 4. O sistema coloca uma reportagem no fluxo de trabalho "tarefas" do editor. O editor visualiza a reportagem. O editor categoriza a reportagem e a marca como aprovada. O sistema inclui a reportagem e dispara o incio das mensagens de pager.
Fluxos Alternativos 1. Rejeitar o Contedo 1. O editor visualiza a reportagem. 2. O editor marca a reportagem como rejeitada 3. O sistema notifica o originador do contedo que a reportagem foi rejeitada 2. Modificar o Contedo 1. O editor seleciona "Modify Story" 2. O sistema exibe os ttulos de todas as reportagens disponveis 3. O editor seleciona um ttulo especfico 4. O sistema exibe as caractersticas da reportagem 5. O editor atualiza as caractersticas 6. O editor seleciona "Save" 7. O sistema recoloca a reportagem, disparando a atividade de mensagens se necessrio 3. Aprovar o Contedo Publicitrio 1. O editor visualiza o contedo publicitrio 2. O editor o marca como aprovado. 3. O sistema inclui o contedo publicitrio para exibio 4. O sistema marca o registro de faturamento preliminar como aprovado 4. Rejeitar o Contedo Publicitrio 1. O editor visualiza o contedo publicitrio 2. O editor o marca como rejeitado e fornece um motivo para a rejeio 3. O sistema notifica o anunciante (por e-mail) da rejeio e do motivo 5. Reportagem no visualizvel Se a reportagem tiver sido excluda por outro editor e no puder ser visualizada no momento, o caso de uso ser finalizado.
Requisitos Especiais
Durante a prxima iterao sero definidos os requisitos especiais.
Precondies
O editor deve estar conectado.
Ps-condies
Durante a prxima iterao sero definidas as ps-condies.
Pontos de Extenso
Os pontos de extenso do caso de uso sero identificados durante a Fase de Elaborao.
Pgina 4 de 12
Editar o Perfil
Breve Descrio Este caso de uso ocorre quando um assinante deseja mudar as informaes do seu perfil ou quando um novo assinante deseja se inscrever.
Fluxo de Eventos
Fluxo Bsico 1. O usurio seleciona "Edit Profile" 2. O sistema exibe as categorias de perfil (selees pessoais, de preferncias, de informaes de pager, de "coloque-me na pgina quando"). 3. O usurio seleciona a categoria 4. O sistema exibe os detalhes 5. O usurio atualiza os detalhes e pressiona "OK" 6. O sistema valida os dados conforme necessrio e atualiza o perfil do assinante. Fluxos Alternativos Se esse for um assinante novo, o caso de uso "Pagar Taxa com Carto de Crdito" ser disparado seguindo o passo 5 acima.
Durante a prxima iterao sero definidos os requisitos especiais. Isso precisa estar protegido porque as informaes de carto de crdito podem estar no perfil.
Precondies
Durante a prxima iterao sero definidas as precondies.
Ps-condies
Pontos de Extenso
Pagar Taxa com Carto de Crdito

Breve Descrio Este caso de uso ocorre quando um novo assinante deseja pagar sua taxa de assinatura anual especificando um nmero de carto de crdito e uma senha. Isso tambm ocorre quando um assinante existente deseja renovar (consulte o fluxo alternativo 1)
Pgina 5 de 12
Fluxo de Eventos
Fluxo Bsico 1. O assinante seleciona "pay fee with credit card" 2. O sistema pede ao assinante o nmero do carto de crdito, a data de vencimento e (opcionalmente) a senha 3. O sistema envia as informaes do carto de crdito para o sistema externo para validao e aplicao da despesa 4. Ao receber a validao, o sistema atualiza o registro do assinante para indicar a nova data de vencimento Fluxos Alternativos
O assinante renova a assinatura
Quando isso acontece, o fluxo segue desta forma: 1. 2. 3. 4. O assinante seleciona "pay fee with credit card" O sistema exibe as informaes atuais do carto de crdito O usurio aceita essas informaes ou as atualiza O sistema envia as informaes do carto de crdito para o sistema externo para validao e aplicao da despesa 5. Ao receber a validao, o sistema atualiza o registro do assinante para indicar a nova data de vencimento
Informaes invlidas do carto de crdito
Se as informaes fornecidas pelo assinante no forem validadas pelo sistema externo, ser exibida uma mensagem de erro e o registro do assinante NO ser atualizado (de forma que os ltimos passos dos fluxos acima no sero executados).
Durante a prxima iterao sero definidos os requisitos especiais. Problema - as especificaes de interface para o sistema externo de carto de crdito precisam ser verificadas.
Precondies
Ps-condies
Pontos de Extenso
Pgina 6 de 12
Imprimir Relatrios do Anunciante

Breve Descrio Este caso de uso ocorre quando um anunciante acessa o Sistema de Mensagens do Collegiate Sports para obter relatrios de como o seu contedo publicitrio foi visualizado.
Fluxo de Eventos
Fluxo Bsico 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. O anunciante seleciona "Print Reports" O sistema exibe todo o contedo publicitrio fornecido pelo anunciante O anunciante seleciona uma ou mais partes do contedo a ser relatado O sistema exibe uma lista de relatrios para o anunciante O anunciante seleciona um ou mais relatrios a serem gerados O anunciante seleciona o formato (Word, Excel ou para a janela do navegador) O sistema cria o primeiro relatrio e solicita que o usurio salve ou visualize O anunciante salva ou visualiza o relatrio, seleciona "Next Report" O sistema cria o prximo relatrio e solicita que o usurio salve ou visualize Os fluxos 8) e 9) so repetidos at acabarem todos os relatrios
Fluxos Alternativos Nenhum
Durante a prxima iterao sero definidos os requisitos especiais. Problemas - o que fazemos com contedo obsoleto? At quando permitiremos a gerao de relatrios sobre contedo no mais disponvel no site da Web? Precisamos criptografar essa transmisso?
Precondies
O usurio est conectado e validado como um anunciante.
Ps-condies
Pontos de Extenso
Fornecer Feedback
Breve Descrio
Pgina 7 de 12
Este caso de uso ocorre quando um usurio do sistema (anunciante, assinante ou assinante potencial) deseja fazer comentrios sobre o servio ou o site da Web.
Fluxo de Eventos
Fluxo Bsico 1. O usurio seleciona "Provide Feedback" 2. O sistema procura os nmeros de telefone centrais para suporte ao usurio. 3. O sistema exibe os nmeros de telefone e d ao usurio a opo de enviar e-mail imediatamente 4. O usurio seleciona a opo de e-mail 5. O sistema procura o endereo de e-mail do servio ao cliente e o passa ao navegador. 6. O sistema inicializa o cliente do navegador de e-mail 7. O usurio digita a mensagem e pressiona "Send" 8. O cliente de e-mail do navegador envia a mensagem. Fluxos Alternativos Nenhum
Precondies
Ps-condies
Pontos de Extenso
Colocar Contedo Publicitrio

Breve Descrio Este caso de uso ocorre quando um anunciante deseja colocar contedo publicitrio (anncios em faixas) no site da Web e especificar quais perfis de assinante devem ser usados para a exibio.
Fluxo de Eventos
Fluxo Bsico 1. O anunciante seleciona "Post Content" 2. O sistema valida as informaes de faturamento da conta para assegurar que o novo
Pgina 8 de 12
contedo ser aceito 3. O sistema solicita o contedo 4. O anunciante carrega o contedo em formato GIF 5. O sistema exibe as categorias possveis para a exibio do anncio (baseadas nas opes de perfil do assinante) 6. O anunciante seleciona as categorias para as quais esse anncio deve ser mostrado 7. O sistema exibe os preos e as freqncias possveis para o anncio 8. O anunciante seleciona a freqncia desejada para esse anncio 9. O sistema cria o registro de faturamento preliminar para esse anncio 10. O sistema coloca o contedo no fluxo de trabalho "tarefas" do editor para obter aprovao Fluxo Alternativo
Informaes Invlidas da Conta
1. O anunciante seleciona "Post Content" 2. O sistema valida as informaes de faturamento da conta para assegurar que o novo contedo ser aceito 3. As informaes da conta so invlidas, o anunciante avisado para contatar.
Precondies
O usurio est conectado e validado como um anunciante. A conta do anunciante existe.
Ps-condies
Pontos de Extenso
Ler Contedo no Site da Web

Breve Descrio Este caso de uso ocorre quando um assinante ativo ou um usurio no registrado se conecta ao sistema para visualizar informaes.
Fluxo de Eventos
Fluxo Bsico 1. O sistema examina a lista "arquivada" de contedo. Qualquer reportagem mais antiga que dois dias movida para trs na categoria geral
Pgina 9 de 12
2. O sistema exibe anncios em faixa, categorias gerais de contedo e verses especficas cujas pginas foram enviadas. 3. O assinante visualiza as reportagens 4. Cada reportagem paginada marcada como visualizada e colocada em uma categoria "arquivada" Fluxos Alternativos
O usurio no um assinante registrado
1. O sistema exibe anncios em faixas e categorias gerais de contedo 2. O sistema fornece a opo para que o usurio faa uma assinatura 3. O usurio visualiza as reportagens
Precondies
Nenhuma.
Ps-condies
Pontos de Extenso
Enviar Contedo
Breve Descrio Este caso de uso ocorre quando um contedo colocado no site existente da WebNewsOnLine. Algumas reportagens sero rotuladas para serem transmitidas ao Sistema de Mensagens do Collegiate Sports, e sero enviadas para que sejam procuradas e exibidas.
Fluxo de Eventos
Fluxo Bsico 1. O editor de contedo coloca o contedo no site da WebNewsOnLine 2. Para obter o contedo de esportes universitrios, o sistema verifica categorizao e/ou ttulo 3. Para as categorias conhecidas pelo Sistema de Mensagens do Collegiate Sports, as reportagens so transmitidas junto com informaes de categoria 4. A reportagem colocada no Sistema de Mensagens do Collegiate Sports para que possa ser procurada. Fluxos Alternativos
Pgina 10 de 12
O contedo no est categorizado
Se o contedo no estiver categorizado, a reportagem ser colocada no fluxo de trabalho "tarefas" do editor.
Precondies
Ps-condies
Pontos de Extenso
Enviar Pgina
Breve Descrio Este caso de uso ocorre quando o novo contedo colocado no Sistema de Mensagens do Collegiate Sports.
Fluxo de Eventos
Fluxo Bsico 1. O sistema verifica as categorias para o novo contedo 2. O sistema verifica as listas de assinantes para determinar se algum assinante deseja ser colocado na pgina desta categoria de contedo 3. O sistema gera uma mensagem de texto baseada no ttulo 4. O sistema constri uma srie de mensagens de e-mail 5. O sistema envia mensagens de e-mail aos assinantes (que as recebero como uma pgina alfanumrica) Fluxos Alternativos Nenhuma.
Precondies
Pgina 11 de 12
O contedo foi colocado, o ttulo est disponvel, a categorizao est disponvel.
Ps-condies
Pontos de Extenso
Assinar
Breve Descrio Este caso de uso ocorre quando um assinante potencial deseja assinar o servio.
Fluxo de Eventos
Fluxo Bsico 1. 2. 3. 4. 5. O sistema procura os termos de contrato atuais e as opes de servio disponveis O sistema exibe os termos de contrato e as opes de servio O assinante potencial reconhece os termos e seleciona as opes de servio O sistema registra as opes de servio atualmente selecionadas O sistema dispara o caso de uso "Editar o Perfil"
Fluxos Alternativos
O usurio rejeita os termos do contrato
Se o assinante potencial no reconhecer os termos do contrato, o caso de uso ser finalizado.
Precondies
Nenhuma.
Ps-condies
Pontos de Extenso
Pgina 12 de 12
Viso
Viso
Pgina 1 de 10
Artefatos >
Viso >
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).]
file://E:\7AOJ\UML\Templates_PT\Viso.htm
14/9/2010
Viso
Pgina 2 de 10
Histrico da Reviso
14/9/2010
Viso
Pgina 3 de 10
ndice Analtico
1. Introduo 1.1 Finalidade 1.2 Escopo 1.3 Definies, Acrnimos e Abreviaes 1.4 Referncias 1.5 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 Demografia dos Mercados 3.2 Resumo dos Envolvidos 3.3 Resumo dos Usurios 3.4 Ambiente do Usurio 3.5 Perfis dos Envolvidos 3.5.1 <Nome do Envolvido> 3.6 Perfis dos Usurios 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 Perspectiva do Produto 4.2 Resumo dos Recursos 4.3 Suposies e Dependncias 4.4 Custos e Preos 4.5 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 Padres Aplicveis 9.2 Requisitos do Sistema 9.3 Requisitos de Desempenho 9.4 Requisitos Ambientais 10. Requisitos de Documentao 10.1 Manual do Usurio 10.2 Ajuda On-line 10.3 Guias de Instalao e de Configurao, e Arquivo Leiame 10.4 Rotulao e Embalagem A Atributos de Recursos
14/9/2010
Viso
Pgina 4 de 10
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 usurios-alvo 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. 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:] O problema de afeta cujo impacto uma boa soluo seria [descreva o problema] [os envolvidos afetados pelo problema] [qual o impacto do problema?] [liste alguns dos principais benefcios de uma boa soluo]
2.3 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:] [cliente-alvo] [indique a necessidade ou oportunidade] um(a) [categoria do produto] [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.] Para Que O (nome do produto) Que
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 mercado-alvo. Avalie o tamanho e o crescimento do mercado utilizando o nmero de usurios em potencial ou o montante que seus
14/9/2010
Viso
Pgina 5 de 10
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?] 3.2 Resumo dos Envolvidos [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 encontra-se na seo 3.3.)] Nome [Especifique o nome do tipo de envolvido.] Descrio [Descreva brevemente o envolvido.] Responsabilidades [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] 3.3 Resumo dos Usurios [Apresente uma lista resumida de todos os usurios identificados.] Nome [Informe o tipo de usurio.] Descrio [Descreva brevemente o que ele representa no que diz respeito ao sistema.] Responsabilidades [Liste as principais responsabilidades do usurio em relao ao sistema que est sendo desenvolvido; por exemplo: - percebe os detalhes - elabora relatrios - coordena o trabalho - e assim por diante] 3.4 Ambiente do Usurio [Descreva o ambiente de trabalho do usurio-alvo. 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.] 3.5 Perfis dos Envolvidos [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 Envolvido [Se o usurio no for representado diretamente, identifique o envolvido responsvel por representar os interesses dele.]
14/9/2010
Viso
Pgina 6 de 10
Descrio Tipo
Responsabilidades Critrios de Sucesso Envolvimento
documentado em outro lugar.) Especifique aqui o nome da pessoa.] [Breve descrio do tipo de envolvido.] [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.] [Liste as principais responsabilidades do envolvido no que diz respeito ao sistema que est sendo desenvolvido - ou seja, seu interesse como envolvido.] [Como o envolvido define sucesso? De que forma o envolvido recompensado?] [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.] [Existem outros produtos liberados exigidos pelo envolvido? Eles podem ser produtos liberados do projeto ou sadas do sistema em desenvolvimento.] [Os problemas que interferem no bom andamento do projeto e outras informaes relevantes sero relacionados aqui.]
Produtos Liberados Comentrios / Problemas
3.6 Perfis dos Usurios [Descreva cada usurio nico do sistema preenchendo a seguinte tabela para cada tipo de usurio. Lembre-se 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 refere-se ao Envolvido que representa o conjunto de usurios como, por exemplo, Envolvido: Envolvido1.] [Uma breve descrio do tipo de usurio.] [Qualifique a experincia do usurio, sua formao tcnica e grau de sofisticao ou seja, guru, usurio eventual etc.] [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.] [Como o usurio define o sucesso? Como o usurio recompensado?] [Como o usurio est envolvido no projeto? Faa referncia, quando possvel, aos papis exercidos no Rational Unified Process - ou seja, Revisor de Requisitos etc.] [O usurio produz algum produto que liberado? Em caso positivo, para quem?] [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.]
Descrio Tipo Responsabilidades
Critrios de Sucesso Envolvimento Produtos Liberados Comentrios / Problemas
3.7 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 Transmitir mensagens Prioridade Preocupaes Soluo Atual Solues Propostas
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
14/9/2010
Viso
Pgina 7 de 10
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.] 3.8.1 3.8.2 <aCompetitor> <anotherCompetitor>
4.
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]
4.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 auto-suficiente, 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.] 4.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 4-1 Sistema de Suporte ao Cliente Benefcio para o Cliente Recursos de Suporte Novas equipes de suporte podero ficar Uma base de conhecimentos ajuda o pessoal de rapidamente informadas do processo. 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 Os relatrios de tendncias e de distribuio de problemas e estimar a carga de permitem revises de nvel superior do status dos trabalho da equipe. problemas. Equipes de suporte distribudas podem Um servidor de duplicao permite que as trabalhar em conjunto para solucionar informaes atuais do banco de dados sejam problemas. compartilhadas pela empresa. Os clientes tm autonomia para resolver Uma base de dados pode ser disponibilizada na seus problemas, o que reduz os custos Internet. Ela contm recursos de pesquisa de de suporte e melhora o tempo de hipertexto e um mecanismo de consulta grfico. resposta. Suposies e Dependncias 4.3 [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 o hardware projetado para o produto de software. Se o sistema operacional no estiver disponvel, o documento Viso ter que ser alterado.] 4.4 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 CD-ROMs, 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.5 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
14/9/2010
Viso
Pgina 8 de 10
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. Trata-se 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 compreend-lo. 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. Concentre-se 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.] 5.1 5.2 <aFeature> <anotherFeature>
6. 7.
Restries Intervalos de Qualidade
[Mencione quaisquer restries de design, restries externas ou outras dependncias.] [Defina os intervalos de qualidade para desempenho, robustez, tolerncia a erros, usabilidade e caractersticas semelhantes que no so capturadas no Conjunto de Recursos.]
8. 9.
Precedncia e Prioridade Outros Requisitos do Produto
[Defina a prioridade dos diferentes recursos do sistema.] [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 [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 bem-sucedida de aplicativos.]
14/9/2010
Viso
Pgina 9 de 10
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 On-line [Muitos aplicativos fornecem um sistema de ajuda on-line 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 on-line um projeto que est contido em outro projeto, beneficiando-se 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.]
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.] 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.] [Recursos que so considerados teis e viveis, e cuja implementao foi aprovada pelo canal oficial.] ] [Recursos incorporados baseline do produto em um momento especfico no tempo.]
Aprovado Incorporado
A.2 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 implementados no release ou a programao ser retardada.] [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.] [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.]
Importante
til
A.3 Esforo [Definido pela equipe de desenvolvimento. Como algumas funcionalidades necessitam de mais tempo e de mais recursos do que
14/9/2010
Viso
Pgina 10 de 10
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 medindo-se 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 Release-alvo [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 Release-alvo estiver definido. Quando ocorrer o gerenciamento de escopo, o Nmero da Verso do Release-alvo 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.]
14/9/2010
CSPS Vision
Pgina 1 de 9
Sistema de Mensagens do Collegiate Sports Vision

Verso 1.0
Histrico da Reviso
Data 6 de outubro de 1999 Verso 1.0 Descrio Verso inicial Autor Integrao do Contexto
ndice Analtico
Introduo Posicionamento Descries dos Envolvidos e Usurios Viso Geral do Produto Caractersticas do Produto Restries Limites de qualidade Precedncia e Prioridade Outros Requisitos do Produto Requisitos da Documentao
Introduo
A finalidade deste documento coletar, analisar e definir as caractersticas e necessidades de alto nvel do Sistema de Mensagens do Collegiate Sports. Ele se concentra nos recursos necessrios aos envolvidos e aos usurios-alvo e nas razes que levam a essas necessidades. Os detalhes de como o Sistema de Mensagens do Collegiate Sports atinge essas necessidades so descritos no caso de uso e nas especificaes suplementares. Finalidade A finalidade deste documento definir os requisitos de alto nvel do em termos de necessidades dos usurios finais. Escopo Este Documento de Viso refere-se ao Sistema de Mensagens do Collegiate Sports, que ser desenvolvido pela Integrao do Contexto. Esse sistema permitir que os assinantes sejam notificados de eventos relacionados a equipes ou esportes universitrios dos quais eles fizeram uma assinatura, e permitir que eles vejam o contedo que assinaram. Definies, Acrnimos e Abreviaes
file://E:\7AOJ\UML\Templates_PT\CSPS Vision.htm
14/9/2010
CSPS Vision
Pgina 2 de 9
Consulte o documento Glossrio. Referncias Nenhuma.
Posicionamento
Oportunidade de Negcios A WebNewsOnLine no momento fornece notcias na World Wide Web e impressas. Ela atualmente detm uma forte posio na categoria Esportes Universitrios e procura formas de expandir a base da sua receita. Nas palavras de Maria Scirpo, CEO: Vamos impulsionar a fora da WebNewsOnLine na cobertura de esportes locais e universitrios oferecendo um servio de pginas por assinatura. Os assinantes, por uma taxa anual de R$15, podem escolher divises universitrias, times ou mesmo atletas individuais que eles desejam acompanhar. Por exemplo, um assinante pode acompanhar os times de basquetebol do NCAA Pac Ten (Cal, Stanford, UCLA etc). Toda vez que for produzida uma reportagem sobre essa diviso, o assinante receber uma pgina alfanumrica. Depois de receber a pgina, o assinante pode, quando conveniente, acessar o site na Web. L, em uma home page personalizada, alm dos links e reportagens padro, existiriam URLs correspondentes a cada pgina alfanumrica recebida pelo assinante. Por trs dessas URLs haver reportagens, udio e vdeo relacionados pgina. Esse servio ser promovido em campi universitrios e atravs de vrias revistas de associaes de alunos. Os benefcios previstos dessa abordagem incluem: 1. Isso colocar em relevo o poder da WebNewsOnLine na cobertura de esportes universitrios (isto , j tem a maior parte desse contedo disponvel) 2. Uma assinatura de R$15/ano significa que apenas 200.000 assinantes sero necessrios para uma receita lquida de R$3 milhes/ano. Esse ponto de equilbrio foi considerado fcil de atingir. 3. Uma gama de novos anunciantes desejaro pagar por espao publicitrio associado a esse servio. Por exemplo, imagina-se que vendedores de carro locais, restaurantes, butiques etc. desejaro pagar para serem vistos por esse conjunto de usurios afluentes e direcionados. Por exemplo, vrias esferas de atividade de Napa j demonstraram interesse em comprar espao para os assinantes do Pac Ten. Descrio do Problema O problema afeta O seu impacto Estar atualizado dos eventos esportivos universitrios Pessoas de negcios itinerantes Que elas no podem acompanhar sua universidade (ou outro esporte universitrio no qual elas esto
14/9/2010
CSPS Vision
Pgina 3 de 9
interessadas) sem gastar muito tempo pesquisando notcias na sua rea de interesse especfico. Uma soluo ideal seria Notific-las quando aparecerem notcias nessas reas de interesse, e oferecer a elas um lugar para obter as notcias que solicitaram.
Sentena de Posio do Produto Para Quem Pessoas de negcios itinerantes Quiser acompanhar grupos ou eventos especficos de esportes universitrios um software
O Sistema de Mensagens do Collegiate Sports Que
Notifica os assinantes quando notcias relacionadas s suas reas de interesse aparecem e esto disponveis O estado atual que requer que eles verifiquem as notcias on-line regularmente para encontrar aquelas de seu interesse. Notifica o assinante quando aparecem notcias de sua rea de interesse, permitindo que eles as verifiquem somente quando houver contedo a ser lido.
Diferente de
Nosso produto
Descries dos Envolvidos e Usurios

Demografia do Mercado O mercado-alvo desse sistema compreende um segmento da sociedade de alto nvel, intelectual, interessado e itinerante - mas itinerante a palavra-chave, significando tanto as pessoas que se mudaram de Cincinnati para Atlanta, quanto aquelas que so itinerantes em termos de estilo de vida ou de suas ocupaes. Resumo dos Envolvidos Nome Representa Papel
14/9/2010
CSPS Vision
Pgina 4 de 9
Assinante
Consumidores finais do contedo fornecido pela WebNewsOnLine. Firmas que pagam para anunciar para clientes-alvo no site da Web.
Criar perfis, receber pginas, ler contedo personalizado e fazer assinatura usando cartes de crdito. Selecionar grupos de consumidores-alvo, fornecer contedo publicitrio, receber relatrios sobre visualizao dos anncios. Colocar contedo no site da Web, categorizar o contedo.
Anunciante
Editor
Canal de proviso de contedo da WebNewsOnLine.
Resumo dos Usurios Nome Assinante Descrio Seleciona as categorias para notificao por pager, l o contedo no site, l a publicidade no site. Obtm informaes sobre distribuio de publicidade do sistema para acompanhamento ou aes de controle. Coloca o contedo no site da Web, identifica as categorias a que pertence o contedo. Envolvidos Auto-representado.
Anunciante
Auto-representado.
Editor
Auto-representado.
Ambiente do usurio As pessoas recebero pginas atravs de pagers alfanumricos ou telefones celulares quando ocorrer um evento na sua rea de interesse. Quando for conveniente, eles estabelecero uma conexo com o site e vero seu contedo. Os padres de uso no so previsveis nesse momento, embora haja previso de volumes maiores durante os torneios de esportes universitrios, como o March Madness. Supe-se que os usurios tenham um dispositivo capaz de receber uma mensagem ou uma pgina alfanumrica, e que tenham um dispositivo habilitado por navegador para visualizao do contedo. Se eles tiverem dispositivos capazes de receber clipes de vdeo ou udio, esse contedo tambm estar disponvel ao usurio. Os anunciantes devero ter um dispositivo habilitado por navegador para verificar o uso do material publicitrio. Os editores devero ter um dispositivo habilitado por navegador para categorizar o contedo e/ou visualizar o status do sistema.
14/9/2010
CSPS Vision
Pgina 5 de 9
Perfis dos Envolvidos

Assinante
Descrio
Pessoa que paga para receber pginas e contedo personalizado relacionado a categorias especficas de esportes universitrios. Usurio primrio Consumidor bsico dos servios e do contedo oferecidos. Capacidade de definir um perfil de notcias e ser notificado das ltimas notcias nas reas de interesse especificadas. Fornece revises das verses beta do software, fornece feedback regular aps o release do produto.
Tipo Responsabilidades Critrios de Sucesso Envolvimento Produtos Liberados Comentrios/Problemas

Anunciante
Nenhum.
Descrio
Pessoas que fornecem contedo direcionado para ser visualizado pelo segmento de mercado especificado, e que verificam os padres de visualizao do contedo publicitrio. Usurio experiente. Revisar os requisitos e os designs da Interface de Usurio. Capacidade de especificar o segmento de mercado-alvo e de verificar que o contedo foi visualizado. Revisor de Requisitos. Relatrios de uso/visualizao. Nenhum.
Tipo Responsabilidades Critrios de Sucesso Envolvimento Produtos Liberados Comentrios/Problemas

Editor
Descrio Tipo Responsabilidades
Pessoa que fornece contedo para o site da Web e o categoriza. Usurio experiente. Precisa ser capaz de colocar e categorizar contedo rapidamente, bem como verificar o contedo e as categorias no site da Web.
14/9/2010
CSPS Vision
Pgina 6 de 9
Critrios de Sucesso Envolvimento Produtos Liberados Comentrios/Problemas
Capacidade de colocar o contedo no mximo cinco minutos aps a disponibilidade desse contedo. Revisor de Requisitos. Nenhum. O desempenho durante perodos de pico de uso talvez seja um problema.
Perfis de Usurios Consulte a seo anterior Necessidades dos Principais Envolvidos/Usurios Necessidade Especificar perfil Prioridade Alta Preocupaes Nvel de granularidade Soluo Atual Nenhuma (ler todas as notcias para encontrar os itens de seu interesse) Nenhum Solues Propostas Permitir vrios nveis de seleo de pginas
Receber pginas quando aparecem notcias Ler as notcias referentes s reas do perfil
Alta
Nveis de volume e tempo de resposta Nenhuma
Usar arquitetura em camadas para permitir a escalabilidade Fornecer links em uma pgina da Web para os itens de notcias direcionadas Mapear a distribuio do contedo publicitrio para os atributos de perfil
Mdia
Nenhuma (ler todas as notcias)
Direcionar os anncios
Alta
Capacidade de segmentar os indivduos do mercado
Selecionar canais de propaganda para atingir indiretamente os segmentos do mercado Nenhuma
Verificar a distribuio de publicidade para estimar a eficincia
Mdia
Nenhuma
Fornecer relatrios aos anunciantes sobre o nmero de visualizaes do contedo publicitrio
14/9/2010
CSPS Vision
Pgina 7 de 9
Alternativas e Concorrncia No momento, no existe um concorrente direto para esse servio. ESPNET Sportzone fornece notcias direcionadas mas no envia mensagem para os assinantes quando surge uma determinada notcia. news breaks.
Viso Geral do Produto

Perspectiva do Produto Este produto impulsionar a atual liderana da WebNewsOnLine em notcias de esportes universitrios, mas apresentar uma interface de usurio atravs de um sistema separado. Graficamente, o sistema pode ser visto desta forma:
Resumo dos Recursos Tabela 1 - Caractersticas do Sistema de Mensagens do Collegiate Sports Benefcio para o Cliente O assinante pode especificar quais notcias ele deseja receber O assinante pode ler apenas as notcias em que tem interesse Recursos de Suporte Capacidade do perfil dentro do sistema Pginas da Web dinmicas e personalizadas para cada assinante, com links para reportagens sobre as quais ele foi informado por mensagem Distribuio de publicidade com
Os anunciantes podem
14/9/2010
CSPS Vision
Pgina 8 de 9
direcionar o contedo No necessrio contedo novo
base nos perfis dos assinantes Link com contedo sobre esportes baseado na Web
Pressupostos e Dependncias Qualquer contedo existente considerado disponvel para visualizao no site. A integrao do contedo atual com o novo site necessria para que as informaes sobre esportes universitrios sejam prontamente disponibilizadas. Custo e Preo As taxas de assinatura so inicialmente definidas em R$15 por assinante por ano. Com apenas 200.000 assinantes, isso gerar $3 milhes de receita por ano, que mais do que suficiente para cobrir o custo incremental do sistema. Os anunciantes pagaro taxas adicionais (inicialmente definidas em 5% acima do normal) para ter acesso a uma populao-alvo definida. Licenciamento e Instalao N/D. Todo o software personalizado est no servidor e de propriedade da WebNewsOnLine.
Caractersticas do Produto
Elas sero fornecidas durante a fase de Elaborao do projeto.
Restries
O sistema dever estar disponvel at maro de 2000. A operao do sistema no pode custar mais do que R$2 milhes por ano. O sistema precisa utilizar o contedo esportivo existente no site da WebNewsOnLine.
Limites de Qualidade
Nenhum especificado.
Precedncia e Prioridade
1. O sistema dever estar disponvel at maro de 2000. 2. O sistema precisa utilizar o contedo esportivo existente no site da WebNewsOnLine na Web. 3. A operao do sistema no pode custar mais do que R$2 milhes por ano.
Outros Requisitos do Produto

Padres Aplicveis O sistema deve ser compatvel com os padres da Web existentes (HTML, Java, TCP/IP etc.).
14/9/2010
CSPS Vision
Pgina 9 de 9
Requisitos do Sistema Nenhum especificado. Requisitos de Desempenho O sistema deve enviar uma mensagem para o assinante, no mximo, cinco minutos depois que o novo contedo foi colocado no site. O sistema precisa poder administrar 200.000 assinantes. Requisitos Ambientais Nenhum especificado.
Requisitos da Documentao
Manual do Usurio
No necessrio - o sistema deve ser suficientemente fcil de usar para que no haja necessidade de um manual do usurio.
Ajuda on-line
Ajuda geral e especfica de um contexto estar disponvel para todas as funes contidas no sistema.
Guias de Instalao, Configurao, Arquivo LeiaMe
Ser fornecido um manual de instalao. Alm disso, um plano formal de Transferncia de Conhecimento ser desenvolvido para assegurar que a equipe seja capaz de manter o sistema em funcionamento.
Rotulao e Empacotamento
No aplicvel.
Copyright 1987 - 2001 Rational Software Corporation
14/9/2010
Especificao Suplementar
Pgina 1 de 6
Artefatos >
Especificaes Suplementares >
rup_sspec.htm
<Nome do Projeto> Especificao Suplementar

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).]
file://E:\7AOJ\UML\Templates_PT\Especificao Suplementar.htm
14/9/2010
Pgina 2 de 6
Histrico da Reviso
14/9/2010
Pgina 3 de 6
ndice Analtico
1. Introduo 1.1 Finalidade 1.2 Escopo 1.3 Definies, Acrnimos e Abreviaes 1.4 Referncias 1.5 Viso Geral Funcionalidade 2.1 3. <Requisito Funcional Um>
2.
Usabilidade 3.1 <Requisito de Usabilidade Um>
4.
Confiabilidade 4.1 <Requisito de Confiabilidade Um>
5.
Desempenho 5.1 <Requisito de Desempenho Um>
6.
Suportabilidade 6.1 <Requisito de Suportabilidade Um>
7.
Restries de Design 7.1 <Restrio de Design Um>
8. 9. 10.
Requisitos de Sistema de Ajuda e de Documentao de Usurio On-line Componentes Comprados Interfaces 10.1 10.2 10.3 10.4 Interfaces de Usurio Interfaces de Hardware Interfaces de Software Interfaces de Comunicaes Requisitos de Licenciamento Observaes Legais, de Direitos Autorais etc Padres Aplicveis
11. 12. 13.
14/9/2010
Pgina 4 de 6
1. Introduo
[A introduo da Especificao Suplementar deve fornecer uma viso geral de todo o documento. Ela deve incluir a finalidade, o escopo, as definies, os acrnimos, as abreviaes, as referncias e a viso geral desta Especificao Suplementar.] A Especificao Suplementar captura os requisitos de sistema que no so capturados imediatamente nos casos de uso do modelo de casos de uso. Entre os requisitos esto includos: Requisitos legais e reguladores, incluindo padres de aplicativo. Atributos de qualidade do sistema a ser criado, incluindo requisitos de usabilidade, confiabilidade, desempenho e suportabilidade. Outros requisitos, como sistemas operacionais e ambientes, requisitos de compatibilidade e restries de design.] 1.1 1.2 Finalidade [Especifique a finalidade desta Especificao Suplementar.] Escopo [Uma breve descrio do escopo desta Especificao Suplementar; a que Projeto(s) ela est associada e tudo o mais que seja afetado ou influenciado por este documento.] Definies, Acrnimos e Abreviaes [Esta subseo deve fornecer as definies de todos os termos, acrnimos e abreviaes necessrias adequada interpretao da Especificao Suplementar. Essas informaes podem ser fornecidas mediante referncia ao Glossrio do projeto.] Referncias [Esta subseo deve fornecer uma lista completa de todos os documentos mencionados em qualquer outra parte da Especificao Suplementar. Cada documento deve ser identificado por ttulo, nmero do relatrio (se aplicvel), data e organizao de publicao. Especifique as fontes a partir das quais as referncias podem ser obtidas. Essas informaes podem ser fornecidas por um anexo ou outro documento.] Viso Geral [Esta subseo deve descrever o que o restante da Especificao Suplementar contm e deve explicar como o documento est organizado.]
1.3
1.4
1.5
2.
Funcionalidade
[Esta seo descreve os requisitos funcionais do sistema que so expressos no estilo de linguagem natural. Para muitos aplicativos, isso poder constituir o volume do Pacote SRS e deve-se refletir muito para organizar esta seo. Normalmente, ela organizada por recurso, mas mtodos de organizao alternativos como, por exemplo, organizao por usurio ou organizao por subsistema, tambm podem ser apropriados. Entre os requisitos funcionais podem estar includos conjuntos de recursos, capacidades e segurana. Quando as ferramentas de desenvolvimento de aplicativos, como ferramentas de requisitos, ferramentas de modelagem, entre outras, forem utilizadas para capturar a funcionalidade, esta seo far referncia disponibilidade desses dados, indicando o local e o nome da ferramenta usada para capturar os dados.]
2.1
<Requisito Funcional Um> [A descrio do requisito deve ser feita aqui.]
3.
3.1
Usabilidade
[Esta seo deve incluir todos os requisitos que afetam a usabilidade. Estes so alguns exemplos: especifique o tempo de treinamento necessrio para que usurios normais e usurios com conhecimentos avanados se tornem produtivos em operaes especficas especifique perodos de tempo mensurveis para tarefas tpicas ou especifique requisitos que estejam em conformidade com os padres comuns de usabilidade como, por exemplo, os padres CUA da IBM ou os padres GUI da Microsoft]
<Requisito de Usabilidade Um> A descrio do requisito.
14/9/2010
Pgina 5 de 6
4.

Confiabilidade
[Os requisitos de confiabilidade do sistema devem ser especificados aqui. Abaixo, algumas sugestes: Disponibilidade - especifique a porcentagem de tempo disponvel ( xx.xx%), as horas de uso, o acesso manuteno, as operaes de modo degradado etc. Tempo Mdio entre Falhas (MTBF) - normalmente especificado em horas, mas tambm poder ser especificado em termos de dias, meses ou anos. Tempo Mdio para Reparo (MTTR) - quanto tempo o sistema poder ficar sem funcionar aps uma falha? Exatido - especifique a preciso (resoluo) e exatido (atravs de algum padro conhecido) necessrias na sada dos sistemas. Taxa mxima de erros ou defeitos - geralmente expressa em termos de erros/KLOC (thousands of lines of code, milhares de linhas de cdigo) ou de erros/ponto de funo. Taxa de erros ou defeitos - categorizados em termos de erros pouco importantes, importantes e crticos: o (s) requisito(s) devem definir o que se entende por um erro "crtico" (ex: perda total de dados ou total incapacidade de usar determinadas partes da funcionalidade do sistema).]
4.1
<Requisito de Confiabilidade Um> [A descrio do requisito deve ser feita aqui.]
5.
Desempenho
[As caractersticas de desempenho do sistema devem ser descritas nesta seo. Inclua tempos de resposta especficos. Quando aplicvel, faa referncia, por nome, aos Casos de Uso relacionados. Tempo de resposta de uma transao (mdio, mximo) Taxa de transferncia (ex: transaes por segundo) Capacidade (ex: o nmero de clientes ou de transaes que podem ser acomodados pelo sistema) Modos de degradao (o modo aceitvel de operao quando o sistema tiver sido degradado de alguma maneira) Utilizao de recursos: memria, disco, comunicaes etc.]
5.1
<Requisito de Desempenho Um> [A descrio do requisito deve ser feita aqui.]
6.
Suportabilidade
[Esta seo indica todos os requisitos que aprimoraro a suportabilidade ou manutenibilidade do sistema que est sendo criado, incluindo padres de codificao, convenes de nomeao, bibliotecas de classes, acesso manuteno e utilitrios de manuteno.]
6.1
<Requisito de Suportabilidade Um> [A descrio do requisito deve ser feita aqui.]
7.
Restries de Design
[Esta seo deve indicar todas as restries de design referentes ao sistema que est sendo criado. As restries de design representam decises de design que foram impostas e devem ser obedecidas. Entre os exemplos desse tipo de restrio esto linguagens de software, requisitos de processo de software, uso prescrito de ferramentas de desenvolvimento, restries de design e de arquitetura, componentes comprados, bibliotecas de classes etc.]
7.1
<Restrio de Design Um> [A descrio do requisito deve ser feita aqui.]
8.
Requisitos de Sistema de Ajuda e de Documentao de Usurio On-line

[Descreva os requisitos, se houver, de documentao de usurio on-line, sistemas de ajuda, observaes sobre ajuda etc.]
9.
Componentes Comprados
[Esta seo descreve todos os documentos comprados a serem usados no sistema, quaisquer restries de utilizao ou de licenciamento aplicveis e quaisquer padres associados de compatibilidade/interoperabilidade ou de interface.]
10.
Interfaces
14/9/2010
Pgina 6 de 6
[Esta seo define as interfaces que devem ser suportadas pelo aplicativo. Ela deve conter especificidades, protocolos, portas e endereos lgicos adequados, entre outros, para que o software possa ser desenvolvido e verificado em relao aos requisitos de interface.] 10.1 10.2 Interfaces de Usurio [Descreva as interfaces de usurio que devero ser implementadas pelo software.] Interfaces de Hardware [Esta seo define todas as interfaces de hardware que devem ser suportadas pelo software, incluindo a estrutura lgica, os endereos fsicos, o comportamento esperado etc. ] 10.3 Interfaces de Software [Esta seo descreve as interfaces de software com outros componentes do sistema de software. Podero ser componentes comprados, componentes reutilizados de outro aplicativo ou componentes que esto sendo desenvolvidos para subsistemas fora do escopo desta SRS, mas com os quais esse aplicativo de software deve interagir.] 10.4 Interfaces de Comunicaes [Descreva todas as interfaces de comunicaes com outros sistemas ou dispositivos como, por exemplo, redes locais, dispositivos seriais remotos etc.]
11.
Requisitos de Licenciamento
[Esta seo define todos os requisitos de imposio de licenciamento ou outros requisitos de restrio de utilizao que devem ser exibidos pelo software.]
12.
Observaes Legais, de Direitos Autorais etc

[Esta seo descreve todos os avisos legais necessrios, garantias, observaes sobre direitos autorais, observaes sobre patentes, logomarcas, marcas comerciais ou problemas de conformidade com logotipos referentes ao software.]
13.
Padres Aplicveis
[Esta seo descreve, por meio de referncias, todos os padres aplicveis e as sees especficas desses padres que se aplicam ao sistema que est sendo descrito. Entre esses padres esto includos, por exemplo, padres reguladores, de qualidade e legais, padres de indstria referentes usabilidade, interoperabilidade, internacionalizao, compatibilidade com o sistema operacional etc.]
14/9/2010
CSPS Supplementary Specification 1.0
Pgina 1 de 3
Sistema de Mensagens do Collegiate Sports Supplementary Specification

Verso 1.0
Histrico da Reviso
ndice Analtico
Verso 1.0
Introduo Funcionalidade Usabilidade Confiabilidade Desempenho Suportabilidade Restries de Design Requisitos de Sistema de Ajuda e de Documentao de Usurio On-line Componentes Adquiridos Interfaces Requisitos de Licenciamento Observaes Legais, de Copyright e Outras Padres Aplicveis
Introduo
Finalidade A finalidade deste documento definir os requisitos do Sistema de Mensagens do Collegiate Sports. Esta Especificao Suplementar lista os requisitos que no so imediatamente capturados nos casos de uso do modelo de casos de uso. As Especificaes Suplementares e o modelo de casos de uso, juntos, capturam um conjunto completo de requisitos do sistema. Escopo Esta Especificao Suplementar se aplica ao Sistema de Mensagens do Collegiate Sports que ser desenvolvido pela Integrao de Contexto. O Sistema de Mensagens do Collegiate Sports permitir que os assinantes sejam notificados via mensagem alfanumrica (ou por telefone celular ou e-mail) sobre eventos em reas de interesse especfico e, em seguida, permitir que eles acessem contedo atravs de uma interface individualizada da Web. Essa especificao define os requisitos no-funcionais do sistema, como confiabilidade, usabilidade, desempenho e suportabilidade, bem como os requisitos funcionais comuns a vrios casos de uso. (Os requisitos funcionais so definidos nas Especificaes de Caso de Uso.)
file://E:\7AOJ\UML\Templates_PT\CSPS Supplementary Specification 1_0.htm
14/9/2010
Pgina 2 de 3
Definies, Acrnimos e Abreviaes Consulte o Glossrio. Referncias 1. CSPS Vision 1.0 2. CSPS Requirements Management Plan 1.0
Funcionalidade
Os requisitos funcionais so capturados atravs dos casos de uso definidos.
Usabilidade
Facilidade de uso O sistema exigir do usurio apenas que ele saiba utilizar um navegador da Web. Isso ser verificado pelos testes de usabilidade executados durante o perodo beta.
Confiabilidade
Disponibilidade A ser definida nas fases subseqentes.
Desempenho
Volume de assinantes O sistema ser capaz de suportar 200.000 assinantes e fornecer um mecanismo de escala para manipular 500.000 assinantes. Latncia das mensagens Quando uma nova histria enviada ao sistema, as mensagens devem ser transmitidas ao gateway de mensagens em, no mximo, 5 minutos.
Suportabilidade
Software do assinante O assinante ser capaz de utilizar o sistema atravs de um software de navegador comercialmente disponvel. No ser necessrio que nenhum software personalizado resida no PC do assinante.
Restries de Design
Aparncia do WebNewsOnLine O sistema estar em conformidade com os padres de design do site do WebNewsOnLine existente na Web.
14/9/2010
Pgina 3 de 3
Conexo de sistema existente do WebNewsOnLine O sistema se comunicar com o site do WebNewsOnLine existente na Web para receber o contedo da histria.
Documentao On-line do Usurio e Requisitos do Sistema de Ajuda

Cada funo principal fornecida pelo sistema ter sua prpria funo de ajuda on-line.
Componentes Adquiridos
A serem definidos nas fases subseqentes.
Interfaces
Interfaces do Usurio Consulte os documentos de design criativo: 1. CSPS Creative Design Brief 1.0 2. CSPS Design Comps 1.0 3. CSPS Navigation Map 1.0 Interfaces de Hardware A serem definidas nas fases subseqentes. Interfaces de Software A serem definidas nas fases subseqentes. Interfaces de Comunicao A serem definidas nas fases subseqentes.
Requisitos de Licenciamento
No necessria nenhuma licena de cliente.
Observaes Legais, de Copyright e Outras

As declaraes de copyright que indicam a propriedade do contedo sero includas no contedo conforme exigido pela poltica.
Padres Aplicveis
A serem definidos nas fases subseqentes.
14/9/2010
Especificao de Caso de Uso
Especificao de Caso de Uso: <Nome do Caso de Uso>
Pgina 1 de 5
Artefatos >
Modelo de Casos de Uso... >
Caso de Uso >
rup_ucspec.htm
<Nome do Projeto> Especificao de Caso de Uso: <Nome do Caso de Uso>

Verso <1.0>
[Observao: O template a seguir fornecido para ser usado no Rational Unified Process. 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).]
file://E:\7AOJ\UML\Templates_PT\Especificao de Caso de Uso Nome do Caso de U... 14/9/2010
Pgina 2 de 5
Histrico da Reviso
Pgina 3 de 5
ndice Analtico
1. Nome do Caso de Uso 1.1 Breve Descrio 2. Fluxo de Eventos 2.1 Fluxo Bsico 2.2 Fluxos Alternativos 2.2.1 < Primeiro Fluxo Alternativo > 2.2.2 < Segundo Fluxo Alternativo > 3. Requisitos Especiais 3.1 < Primeiro Requisito Especial > 4. Condies Prvias 4.1 < Condio Prvia Um > 5. Condies Posteriores 5.1 < Condio Posterior Um > 6. Pontos de Extenso 6.1 <Nome do Ponto de Extenso>
Pgina 4 de 5
Especificao de Caso de Uso <Nome do Caso de Uso>

1. Nome do Caso de Uso
[O template a seguir fornecido para uma Especificao de Caso de Uso, que contm as propriedades de texto do caso de uso. Este documento usado com uma ferramenta de gerenciamento de requisitos, como o Rational RequisitePro, para especificar e marcar os requisitos contidos nas propriedades do caso de uso. Os diagramas do caso de uso podem ser desenvolvidos em uma ferramenta de modelagem visual, como o Rational Rose. Um relatrio de caso de uso (com todas as propriedades) pode ser gerado com o Rational SoDA. Para obter mais informaes, consulte os mentores de ferramentas do Rational Unified Process.] 1.1 Breve Descrio [A descrio relata brevemente a finalidade do caso de uso. Para tanto, ser suficiente um nico pargrafo.]
2.
2.1
Fluxo de Eventos
Fluxo Bsico [Este caso de uso iniciado quando o ator faz algo. Um ator sempre inicia os casos de uso. O caso de uso descreve o que o ator faz e o que o sistema faz em resposta. Ele deve ser elaborado como um dilogo entre o ator e o sistema. O caso de uso descreve o que acontece dentro do sistema, mas no o porqu nem como. Se forem trocadas informaes, seja especfico no que diz respeito ao contedo que passado e retornado. Por exemplo, no muito esclarecedor dizer que o ator fornece informaes do cliente. melhor dizer que ele fornece o nome e o endereo do cliente. Freqentemente til fazer uso de um Glossrio de Termos para manter a complexidade do caso de uso sob controle poder ser conveniente definir termos como, por exemplo, informaes do cliente nesse glossrio, a fim de evitar que o caso de uso fique repleto de detalhes. As alternativas simples podero ser apresentadas no texto do caso de uso. Se forem necessrias apenas algumas frases para descrever o que acontece quando h uma alternativa, faa essa descrio diretamente na seo Fluxo de Eventos. Se o fluxo alternativo for mais complexo, use uma seo separada para descrev-lo. Por exemplo, uma subseo Fluxo Alternativo explica como descrever alternativas mais complexas. s vezes, uma figura vale por mil palavras, embora no haja nada que possa substituir uma redao clara e organizada. Se for mais esclarecedor, sinta-se vontade para colar representaes grficas de interfaces do usurio, fluxos de processo ou outras imagens no caso de uso. Se um fluxograma for til para apresentar um processo complexo de decises, utilize-o sem nenhuma dvida! Semelhantemente no que diz respeito a comportamentos dependentes de estado, um diagrama de transio de estado geralmente esclarece o comportamento de um sistema muito mais do que pginas e pginas de texto. Use o meio de apresentao certo para o problema, mas procure evitar o uso de terminologia, notaes ou imagens que o pblico possa deixar de compreender. Lembre-se de que sua finalidade esclarecer e no obscurecer.]
2.2 2.2.1
Fluxos Alternativos < Primeiro Fluxo Alternativo > [As alternativas mais complexas so descritas em uma seo separada, a que feita referncia na subseo Fluxo Bsico da seo Fluxo de Eventos. Pense nas subsees Fluxo Alternativo como comportamentos alternativos cada fluxo alternativo representa um comportamento alternativo geralmente devido a excees que ocorrem no fluxo principal. O tamanho desses fluxos poder ser to extenso quanto o necessrio para descrever os eventos associados ao comportamento alternativo. Quando um fluxo alternativo termina, os eventos do fluxo principal de eventos so retomados a menos que seja especificado de outra maneira.]
2.2.1.1 < Um Subfluxo Alternativo > [Os subfluxos alternativos, por sua vez, podero ser divididos em subsees para aprimorar a clareza.] 2.2.2 < Segundo Fluxo Alternativo > [Poder haver, e muito provavelmente haver, uma srie de fluxos alternativos em um caso de uso. Mantenha cada fluxo alternativo separado para aprimorar a clareza. O uso de fluxos alternativos melhora a legibilidade do caso de uso e tambm evita que os casos de uso sejam decompostos em hierarquias de casos de uso. Lembrese de que os casos de uso so apenas descries textuais e que sua finalidade principal documentar o comportamento de um sistema de maneira clara, concisa e compreensvel.]
3.
[Normalmente um requisito especial um requisito no funcional que especfico de um caso de uso, mas que no especificado, de maneira fcil ou natural, no texto do fluxo de eventos do caso de uso. Entre os exemplos
Pgina 5 de 5
de requisitos especiais esto includos requisitos legais e reguladores, padres de aplicativo e atributos de qualidade do sistema a ser criado incluindo requisitos de usabilidade, confiabilidade, desempenho ou suportabilidade. Alm disso, outros requisitos como sistemas operacionais e ambientes, requisitos de compatibilidade e restries de design devero ser capturados nesta seo.] 3.1 < Primeiro Requisito Especial >
4.
Condies Prvias
[Uma condio prvia de um caso de uso o estado do sistema que deve estar presente antes de um caso de uso ser realizado.]
4.1
< Condio Prvia Um >
5.
Condies Posteriores
[Uma condio posterior de um caso de uso uma lista dos possveis estados em que o sistema poder se encontrar imediatamente depois do trmino de um caso de uso.]
5.1
< Condio Posterior Um >
6.
6.1
Pontos de Extenso
[Pontos de extenso do caso de uso.] <Nome do Ponto de Extenso> [Definio da localizao do ponto de extenso no fluxo de eventos.]
CSPS Use Case : Approve Story 1.0
Pgina 1 de 2
Sistema de Mensagens do Collegiate Sports Use Case Specification: Approve Story

Verso 1.0
Histrico da Reviso
ndice Analtico
Verso 1.0
Autor Integrao de Contexto
Aprovar Histria Fluxo de Eventos Requisitos Especiais Precondies Ps-condies Pontos de Extenso
Aprovar Histria
Breve Descrio Este Caso de Uso ocorre quando um editor aprova uma histria para ser includa no Sistema de Mensagens do Collegiate Sports. Algumas histrias sero propagadas automaticamente a partir do sistema existente, mas precisaro da interveno do editor (porque o assunto no est claro ou as categorias s quais a histria pertence no esto claras). Esse fluxo tambm usado para aprovar o contedo publicitrio que est sendo enviado.
Fluxo de Eventos
Fluxo Bsico 1. 2. 3. 4. O sistema inclui uma histria no fluxo de trabalho "to-do" do editor. O editor visualiza a histria. O editor classifica a histria e a marca como aprovada. O sistema inclui a histria e dispara o incio das mensagens.
Fluxos Alternativos 1. Rejeitar Contedo 1. O editor visualiza a histria. 2. O editor marca a histria como rejeitada. 3. O sistema informa ao autor do contedo que a histria foi rejeitada. 2. Modificar Contedo 1. O editor seleciona "Modify Story". 2. O sistema exibe os ttulos de todas as histrias disponveis. 3. O editor seleciona o ttulo especfico.
file://E:\7AOJ\UML\Templates_PT\CSPS Use Case Approve Story 1_0.htm
14/9/2010
CSPS Use Case : Approve Story 1.0
Pgina 2 de 2
O sistema exibe as caractersticas da histria. O editor atualiza as caractersticas. O editor seleciona "Save". O sistema envia a histria novamente, disparando a atividade de mensagens quando necessrio. 3. Aprovar Contedo Publicitrio 1. O editor exibe o contedo publicitrio. 2. O editor o marca como aprovado. 3. O sistema inclui o contedo publicitrio para exibio. 4. O sistema marca o registro de cobrana preliminar como aprovado. 4. Rejeitar Contedo Publicitrio 1. O editor exibe o contedo publicitrio. 2. O editor o marca como rejeitado e informa o motivo da rejeio. 3. O sistema informa ao anunciante (via e-mail) que o contedo foi rejeitado e informa o motivo. 5. A histria no pode ser visualizada Se a histria tiver sido excluda por outro editor e no puder ser visualizada no momento, o caso de uso ser encerrado.
4. 5. 6. 7.
Os requisitos especiais sero determinados durante a prxima iterao.
Precondies
Ps-condies
As ps-condies sero determinadas durante a prxima iterao.
Pontos de Extenso
Os pontos de extenso do caso de uso sero identificados durante a fase de elaborao.
file://E:\7AOJ\UML\Templates_PT\CSPS Use Case Approve Story 1_0.htm
14/9/2010
CSPS Use Case : Pay Fee with Credit Card 1.0
Pgina 1 de 2
Sistema de Mensagens do Collegiate Sports Use Case Specification: Pay Fee with Credit Card
Verso 1.0
Histrico da Reviso
ndice Analtico
Verso 1.0
Pagar Taxa com Carto de Crdito Fluxo de Eventos Requisitos Especiais Precondies Ps-condies Pontos de Extenso
Pagar Taxa com Carto de Crdito

Breve Descrio Este caso de uso ocorre quando um novo assinante deseja pagar sua taxa de assinatura anual especificando um nmero de carto de crdito e uma senha. Isso tambm ocorre quando um assinante existente deseja renovar (consulte o fluxo alternativo 1)
Fluxo de Eventos
Fluxo Bsico 1. O assinante seleciona "pay fee with credit card" 2. O sistema pede ao assinante o nmero do carto de crdito, a data de vencimento e (opcionalmente) a senha 3. O sistema envia as informaes do carto de crdito para o sistema externo para validao e aplicao da despesa 4. Ao receber a validao, o sistema atualiza o registro do assinante para indicar a nova data de vencimento Fluxos Alternativos
O assinante renova a assinatura
Quando isso acontece, o fluxo segue desta forma: 1. O assinante seleciona "pay fee with credit card" 2. O sistema exibe as informaes atuais do carto de crdito 3. O usurio aceita essas informaes ou as atualiza
file://E:\7AOJ\UML\Templates_PT\CSPS Use Case Pay Fee with Credit Card 1_0.htm
14/9/2010
CSPS Use Case : Pay Fee with Credit Card 1.0
Pgina 2 de 2
4. O sistema envia as informaes do carto de crdito para o sistema externo para validao e aplicao da despesa 5. Ao receber a validao, o sistema atualiza o registro do assinante para indicar a nova data de vencimento
Informaes invlidas do carto de crdito
Se as informaes fornecidas pelo assinante no forem validadas pelo sistema externo, ser exibida uma mensagem de erro e o registro do assinante NO ser atualizado (de forma que os ltimos passos dos fluxos acima no sero executados).
Requisitos especiais
Durante a prxima iterao sero definidos os requisitos especiais. Problema - as especificaes de interface para o sistema externo de carto de crdito precisam ser verificadas.
Precondies
Ps-condies
Pontos de Extenso
file://E:\7AOJ\UML\Templates_PT\CSPS Use Case Pay Fee with Credit Card 1_0.htm
14/9/2010

Documentacao Geral

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

Documentacao Geral

Enviado por

Direitos autorais:

Formatos disponíveis

Glossrio

Conjunto de Artefatos de Requisitos >

<Nome do Projeto> Glossrio

CSPS Glossary 1.0

Sistema de Mensagens do Collegiate Sports Glossary

Descrio Verso inicial

Autor Integrao do Contexto

file://E:\7AOJ\UML\Templates_PT\CSPS Glossary 1_0.htm

CSPS Glossary 1.0

Copyright 1987 -2001 Rational Software Corporation

file://E:\7AOJ\UML\Templates_PT\CSPS Glossary 1_0.htm

Relatrio Sinttico de Modelo de Casos de Uso do CSPS

Sistema de Mensagens do Collegiate Sports Relatrio Sinttico de Modelo de Casos de Uso

file://E:\7AOJ\UML\Templates_PT\Relatrio Sinttico de Modelo de Casos de Uso do ... 14/9/2010

Relatrio Sinttico de Modelo de Casos de Uso do CSPS

Sistema Atual da WebNewsOnLine Assinante Potencial

file://E:\7AOJ\UML\Templates_PT\Relatrio Sinttico de Modelo de Casos de Uso do ... 14/9/2010

Relatrio Sinttico de Modelo de Casos de Uso do CSPS

file://E:\7AOJ\UML\Templates_PT\Relatrio Sinttico de Modelo de Casos de Uso do ... 14/9/2010

Relatrio Sinttico de Modelo de Casos de Uso do CSPS

Pagar Taxa com Carto de Crdito

file://E:\7AOJ\UML\Templates_PT\Relatrio Sinttico de Modelo de Casos de Uso do ... 14/9/2010

Relatrio Sinttico de Modelo de Casos de Uso do CSPS

Informaes invlidas do carto de crdito

file://E:\7AOJ\UML\Templates_PT\Relatrio Sinttico de Modelo de Casos de Uso do ... 14/9/2010

Relatrio Sinttico de Modelo de Casos de Uso do CSPS

Imprimir Relatrios do Anunciante

Fluxos Alternativos Nenhum

file://E:\7AOJ\UML\Templates_PT\Relatrio Sinttico de Modelo de Casos de Uso do ... 14/9/2010

Relatrio Sinttico de Modelo de Casos de Uso do CSPS

Colocar Contedo Publicitrio

file://E:\7AOJ\UML\Templates_PT\Relatrio Sinttico de Modelo de Casos de Uso do ... 14/9/2010

Relatrio Sinttico de Modelo de Casos de Uso do CSPS

Ler Contedo no Site da Web

file://E:\7AOJ\UML\Templates_PT\Relatrio Sinttico de Modelo de Casos de Uso do ... 14/9/2010

Relatrio Sinttico de Modelo de Casos de Uso do CSPS

file://E:\7AOJ\UML\Templates_PT\Relatrio Sinttico de Modelo de Casos de Uso do ... 14/9/2010

Relatrio Sinttico de Modelo de Casos de Uso do CSPS

O contedo no est categorizado

file://E:\7AOJ\UML\Templates_PT\Relatrio Sinttico de Modelo de Casos de Uso do ... 14/9/2010

Relatrio Sinttico de Modelo de Casos de Uso do CSPS

O contedo foi colocado, o ttulo est disponvel, a categorizao est disponvel.

Se o assinante potencial no reconhecer os termos do contrato, o caso de uso ser finalizado.

file://E:\7AOJ\UML\Templates_PT\Relatrio Sinttico de Modelo de Casos de Uso do ... 14/9/2010

Relatrio Sinttico de Modelo de Casos de Uso do CSPS

Copyright 1987 -2001 Rational Software Corporation

file://E:\7AOJ\UML\Templates_PT\Relatrio Sinttico de Modelo de Casos de Uso do ... 14/9/2010

Conjunto de Artefatos de Requisitos >

<Nome do Projeto> Viso

Descries dos Envolvidos e dos Usurios

Responsabilidades Critrios de Sucesso Envolvimento

Produtos Liberados Comentrios / Problemas

Descrio Tipo Responsabilidades

Critrios de Sucesso Envolvimento Produtos Liberados Comentrios / Problemas

Viso Geral do Produto

Restries Intervalos de Qualidade

Precedncia e Prioridade Outros Requisitos do Produto

Sistema de Mensagens do Collegiate Sports Vision

Consulte o documento Glossrio. Referncias Nenhuma.

O Sistema de Mensagens do Collegiate Sports Que

Descries dos Envolvidos e Usurios

Canal de proviso de contedo da WebNewsOnLine.

Perfis dos Envolvidos