Tabela de conteúdos

~~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.

Última atualização: 2017/04/03 18:21 (edição externa)

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:

>

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:

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>