~~ODT~~

O código PHP permite apresentação da data de ultima atualização alinhada a direita. E deve ser adicionado em todos as especificações.

<PHP>
echo "<div style='display:block;float:right;'>"; 
echo "Última atualização: ";
ver('', false);
echo "</div>";
</PHP>

Exemplo de como fica: 
https://docs.info.ufrn.br/doku.php?id=desenvolvimento:especificacoes:sipac:contratos:casos_de_uso:alteracao_contratual:alteracoes:alterar_operacoes

====== Projetos por Unidade Solicitante ======

Na denominaçao é importante que seja feita uma breve descrição,indicação dos envolvidos e pré-condições.

<Descrição: A breve descrição do caso de uso deve consistir em um texto que reflita a proposta central do caso de uso -
objetivo, contexto, finalidade>

<Envolvidos:  Listar o público alvo do caso de uso.

Por exemplo:
   Em requisições de material os envolvidos são secretárias de unidades administrativas com o devido perfil para isso. 
   No empenho pode ser o Departamento de Contabilidade e Finanças (DCF) para a administração central e os Setores de Execução Orçamentária nos âmbitos dos centros. 
   Matricula-online: Alunos de graduação, técnico e pós-graduação. Tutores de educação a distância. 
>

<Pré-condições:  Indicar se há alguma condição para execução do caso de uso. 

Por exemplo: 
  * Para a chefia homologar  férias  a pré-condição é que o servidor já a tenha marcado.
  * Para realizar a matrícula on-line é preciso que o calendário acadêmico esteja no prazo de matrícula on-line.
  * Para efetivar uma requisição de diárias e passagens é preciso que o afastamento do servidor esteja homologado.
>

===== Descrição do Caso de Uso =====
< Adicionar caminho da funcionaldiade indicando SISTEMA-> MÓDULO-> CAMINHO -> FUNCIONALIDADE, Por exemplo: Este caso de uso
inicia quando o usuário acessa a opção: //SIPAC -> Módulo Contratos -> Aba Geral -> Contratos a Vencer//.>

< A descrição deve ser escrita usando linguagem simples e direta. Pode descrever
os dados manipulados pelo caso de uso, os passos e sua descrição.>

<Quando os passos se apresentarem auto-explicativos, a explicação de cada um poderá ser opcional
e o esquema passo a passo já será suficiente para o entendimento do fluxo de eventos. Alguns critérios
para tomar essa decisão podem ser: que não se perceba inconsistência entre os usuários leitores sobre 
o que o caso de uso se refere e os designers e testadores estejam confortáveis com o nível de detalhe
fornecido pelo formato passo a passo.>

<As especificações que tiverem arquivos anexos de layout devem ser adicionadas no fluxo da especificação.>

<Diagramas de Atividades: Quando a especificação de caso de uso se tornar muito complexa, 
a criação do diagrama de atividades é uma boa opção para representar visualmente
o caso de uso em termos de seqüências e ações. Neste caso, é necessário mencionar neste
item da especificação de caso de uso, que para um melhor entendimento foi criado um 
diagrama de atividades na ferramenta de modelagem Jude. Se adicionar o diagrama , anexe também o arquivo fonte>

Ao final do caso de uso indicar término, sugestão: o caso de uso é finalizado.

===== Principais Regras de Negócio =====

< Regras de Negócio são todas as regras existentes num sistema de informação, que 
ditam seu comportamento, suas restrições e validações. Os detalhes são importantes
para uma validação completa. Para facilitar a referência a alguma regra de negócio 
é interessante que elas sejam listadas com o mnemônico **RN01**. Essas regras devem ser 
referenciadas no fluxo de Descrição do caso de Uso também utilizando-se o mnemônico RN01
que identifica o número da regra em negrito.>

Por exemplo:

  * **RN01** - Essa opção estará disponível caso o funcionário esteja devidamente afastado de sua função.

==== Resoluções/Legislações Associadas ====

Quando não houver, informar com texto "Não se Aplica".  
Porém, em situações de existência colocar toda a informação associada ou simplesmente anexar o documento nesta seção.

===== Classes Persistentes e Tabelas Envolvidas =====

< Cite as classes e as tabelas envolvidas diretamente no processo de negócio para
que testes possa usá-la. >

Obs.: Classes Persistentes são aquelas que implementam as entidades de domínio de negócio. 
Nesse caso, devem ser colocadas as classes de domínio envolvidas diretamente no caso de uso.

^ Classe ^ Tabela |
| < Ex.: br.ufrn.sigaa.biblioteca.processos_tecnicos.dominio.Assinatura > | < Ex.:sigaa.biblioteca.assinatura > |


===== Plano de Teste =====

Sistema: <Nome do sistema> ex.: SIGPRH

Módulo: <Nome do módulo> ex.: DAP

Link(s): <Menus utilizados para alcançar a funcionalidade> ex.: Chefia -> Cursos e Concursos

Usuário: <Para cada papel descrito fornecer pelo menos um usuário que realmente utilizará o caso de uso, e não logins genéricos como gleydson e raphaela.
 Informação Obrigatória>
          Exemplos: 
             gizelealmeida (projetos de cursos e concursos), 
             simonelopes (capacitação)>

Papel que usuário deve ter: <Denominação dos papéis. Preenchimento obrigatório. Ex.: SigrhPapeis.GESTOR_PROJETO_CURSOS_CONCURSOS >

===== Cenários de Teste =====
<É a definição de um conjunto específico de entradas de teste, condições de execução e 
resultados esperados, identificados com a finalidade de avaliar um determinado aspecto de um Item a ser testado.>


===== Dados para o Teste =====

< Descreve como obter os dados que serão usados para o teste do caso de uso.>

Se for necesário descrever um script, usar a tag: <code sql>