<Nome do Projeto>
Glossário de Negócios
Versão <1.0>
[Observação: O template a seguir é fornecido para uso com o Rational Unified Process (RUP). O texto em azul exibido entre colchetes e em itálico (style=InfoBlue) foi incluído para orientar o autor e deve ser excluído antes da publicação do documento. Qualquer parágrafo inserido após esse estilo será definido automaticamente como normal (estilo=BodyText).]
Histórico da Revisão
|
Data |
Versão |
Descrição |
Autor |
|
<dd/mmm/aa> |
<x.x> |
<detalhes> |
<nome> |
Índice Analítico
Glossário de Negócios
[A introdução do Glossário de Negócios deve fornecer uma visão geral de todo o documento. Apresente todas as informações de que o leitor pode precisar para entender o documento nesta seção. Este documento é usado para definir a terminologia específica do domínio de problema, explicando termos que podem não ser familiares para o leitor das descrições de casos de uso ou de outros documentos do projeto. Geralmente, este documento pode ser usado como um dicionário de dados informal, capturando definições de dados para que as descrições de casos de uso e outros documentos do projeto possam se concentrar no que o sistema deve fazer com as informações. Este documento deve ser salvo em um arquivo denominado Glossário de Negócios.]
[Especifique a finalidade deste Glossário de Negócios.]
[Uma breve descrição do escopo deste Glossário de Negócios; o(s) Projeto(s) ao(s) qual(is) ele está associado e tudo o que é afetado ou influenciado por este documento.]
[Esta subseção deve apresentar uma lista completa de todos os documentos mencionados no Glossário de Negócios. Cada documento deve ser identificado por título, número de relatório (se aplicável), data e organização responsável pela publicação. Especifique as fontes das quais é possível obter referências. Essas informações podem ser fornecidas por um anexo ou outro documento.]
[Esta subseção deve descrever o conteúdo restante do Glossário de Negócios e explicar como o documento está organizado.]
[Os termos definidos aqui são a essência do documento. Eles poderão ser definidos na ordem desejada, mas geralmente a ordem alfabética propicia maior acessibilidade.]
[A definição de <aTerm> é apresentada aqui. Você deverá apresentar quantas informações forem necessárias para que o leitor compreenda o conceito.]
A definição de <anotherTerm> é apresentada aqui. Você deverá apresentar quantas informações forem necessárias para que o leitor compreenda o conceito
[Às vezes é útil organizar os termos em grupos para melhorar a leitura. Por exemplo, se o domínio de problema contém termos relacionados a contabilidade e construção civil (como seria o caso se estivéssemos desenvolvendo um sistema para gerenciar projetos de construção), a apresentação dos termos dos dois subdomínios diferentes pode ser confusa para o leitor. Para resolver esse problema, utilizamos grupos de termos. Ao apresentar os grupos de termos, forneça uma pequena descrição para ajudar o leitor a entender o que representa <aGroupOfTerms>. Os termos apresentados dentro do grupo devem ser organizados em ordem alfabética para facilitar o acesso.]
2.3.1 <aGroupTerm>[A definição de <aGroupTerm> é apresentada aqui. Apresente quantas informações forem necessárias para que o leitor compreenda o conceito.]
2.3.2 <anotherGroupTerm>[A definição de <anotherGroupTerm> é apresentada aqui. Apresente quantas informações forem necessárias para que o leitor compreenda o conceito.]
<aSecondGroupOfTerms>
2.3.3 <yetAnotherGroupTerm>[A definição do termo é apresentada aqui. Apresente quantas informações forem necessárias para que o leitor compreenda o conceito.]
2.3.4 <andAnotherGroupTerm>[A definição do termo é apresentada aqui. Apresente quantas informações forem necessárias para que o leitor compreenda o conceito.]
[Esta seção contém ou faz referência a especificações de estereótipos na Linguagem Unificada de Modelagem (UML) e às respectivas implicações semânticas - uma descrição textual do significado e do sentido do estereótipo e quaisquer limitações de uso - de estereótipos já conhecidos ou descobertos como importantes no aspecto do negócio que está sendo modelado. O uso desses estereótipos pode ser simplesmente recomendado ou até mesmo obrigatório; por exemplo, quando o uso desses estereótipos for exigido por um padrão imposto ou quando se considerar que o uso facilitará em muito o entendimento. Esta seção poderá ficar em branco se não for considerado necessário nenhum estereótipo adicional além dos predefinidos pela UML e pelo Rational Unified Process.]