manual_do_sistema-20140923213926 fatec€¦ · web viewnome do aluno. modelo de manual de...

FACULDADE DE TECNOLOGIA DE PRESIDENTE PRUDENTE

NOME DO ALUNO

MODELO DE MANUAL DE SISTEMA COMO TRABALHO DE CONCLUSÃO DE CURSO

Presidente Prudente2014


NOME DO ALUNO


Manual de sistema apesentado como trabalho de conclusão de curso de graduação de Tecnologia em Análise e Desenvolvimento de Sistemas da Faculdade de Tecnologia de Presidente Prudente.Ou no caso de um pré-projeto:Pré-projeto de pesquisa apresentado à Faculdade de Tecnologia de Presidente Prudente como parte das exigências da disciplina de Metodologia de Pesquisa.

Presidente Prudente2014


NOME DO ALUNO


Aprovado em ___/___/______

Trabalho de Graduação realizado como parte das exigências para obtenção do diploma de tecnólogo em Análise e Desenvolvimento de Sistemas da Faculdade de Tecnologia de Presidente Prudente.

_______________________________________Prof. Fulano de Tal (Sigla da Instituição)

_______________________________________Profa. Cicrana de Tal (Sigla da Instituição)

_______________________________________Prof. Beltrano de Tal (Sigla da Instituição)

LISTA DE FIGURAS

LISTA DE TABELAS

SUMÁRIO

1. INTRODUÇÃO........................................................................................................51.1 OBJETIVO.............................................................................................................51.2 ESCOPO...............................................................................................................51.3 DEFINIÇÕES, SIGLAS E ABREVIAÇÕES............................................................61.4 REFERÊNCIAS.....................................................................................................61.5 VISÃO GERAL.......................................................................................................6

2. DESCRIÇÃO GERAL DO PRODUTO....................................................................82.1 ESTUDO DE VIABILIDADE...................................................................................82.2 PERSPECTIVA DO PRODUTO............................................................................82.3 FUNÇÕES DO PRODUTO....................................................................................92.3.1 Funções Básicas...........................................................................................................102.3.2 Funções Fundamentais.................................................................................................102.3.3 Funções de Saída..........................................................................................................102.4 CARACTERÍSTICAS DO USUÁRIO...................................................................102.5 LIMITES, DEPENDÊNCIAS E SUPOSIÇÕES...................................................112.6 REQUISITOS ADIADOS....................................................................................12

3. REQUISITOS ESPECÍFICOS (Paradigma Estruturado).....................................133.1 MODELO AMBIENTAL.......................................................................................133.1.1 Diagrama de Contexto..................................................................................................133.1.2 Lista de Eventos...........................................................................................................133.1.3 DFDs Particionados e Refinamentos............................................................................133.1.4 Dicionário de Dados.....................................................................................................133.2 REQUISITOS DE INTERFACES EXTERNAS....................................................13

4. PROJETO DE SOFTWARE (Paradigma Estruturado).......................................144.1 DIAGRAMA DE ESTRUTURA MODULAR.........................................................144.2 PSEUDOCÓDIGO (opcional).............................................................................144.3 LAYOUT DE TELAS...........................................................................................144.4 TABELA DE CRUZAMENTO..............................................................................14

3. REQUISITOS ESPECÍFICOS (Paradigma Orientado a Objetos).......................153.1 CASOS DE USO.................................................................................................153.1.1 Diagrama de Casos de Uso..........................................................................................153.1.2 Especificação de Casos de Uso...................................................................................153.1.3 Diagrama de Atividades................................................................................................153.1.4 Diagramas de Sequência de Análise............................................................................153.2 MODELO CONCEITUAL....................................................................................163.3 REQUISITOS DE INTERFACES EXTERNAS....................................................16

4. PROJETO DE SOFTWARE (Paradigma Orientado a Objetos).........................174.1 DIAGRAMAS DE INTERAÇÃO..........................................................................174.2 DIAGRAMA DE CLASSES.................................................................................174.3 MAPEAMNTO OO-RELACIONAL......................................................................174.4 LAYOUT DE TELAS...........................................................................................174.5 MODELO NAVEGACIONAL (Apenas para sistemas web).................................17

4. CRONOGRAMA DE ATIVIDADES (Apenas para a Qualificação).....................18Apêndice A – Alternativa rejeitada do Estudo de Viabilidade.............................19Apêndice B – Procedimentos de instalação do Banco de Dados e do Software...................................................................................................................................19

Anexo 1 ... N – Referências (documentos apresentar no item 1.4) e Manual do Usuário.....................................................................................................................19Anexo N+1 – Modelo para Casos de Uso CRUD...................................................20Anexo N+2 – Modelo para Casos de Uso Estendidos..........................................24Anexo N+3 – Modelo para Casos de Alto Nível.....................................................25

1. INTRODUÇÃO

Atenção:Todo texto marcado em vermelho neste modelo consiste em regulamentos e

textos auxiliares, não fazendo parte do manual do sistema (ERS – Especificação de

Requisitos de Sistema).

Paradigmas de Desenvolvimento:

Os capítulos 3 e 4 do manual do sistema estão relacionados ao paradigma de

desenvolvimento selecionado pelo aluno – Estruturado ou Orientado a Objetos.

Independentemente do paradigma, o sistema deverá ter o help on-line no qual será

descrito cada elemento de cada tela do sistema e o significado e ação a ser

realizada relacionada a cada mensagem de erro/advertência do sistema.

1.1 OBJETIVO

Descrever aqui o objetivo deste documento – manual do sistema:

Delinear o objetivo da ERS;

Especificar o público alvo (cliente, analista e desenvolvedor).

1.2 ESCOPO

5

Descrever aqui o escopo do produto de software a ser desenvolvido,

inserindo os objetivos, como o sistema auxilia o processo de negócio e os benefícios

do sistema:

O escopo deve coincidir com as funções do produto (item 2.3);

Identificar pelo nome o produto do software a ser produzido (1º parágrafo da

seção);

Explicar o que o produto de software fará e o que não (se for o caso);

Descrever a aplicação do software incluindo benefícios relevantes e os objetivos

específicos.

1.3 DEFINIÇÕES, SIGLAS E ABREVIAÇÕES

Definição dos temos, siglas e abreviações utilizados neste documento:

Fornecer as definições de termos, siglas e abreviações necessárias para

interpretar apropriadamente a ERS.

o Podem ser fornecidas por referência a apêndices na ERS ou a outros

documentos

1.4 REFERÊNCIAS

Inserir uma tabela que descreva as referências adquiridas irão auxiliá-lo no

entendimento do processo de negócio (documentos, planilhas, relatórios utilizados

pelo cliente etc.):

Fornecer uma lista completa de todos os documentos referenciados;

Identificar cada documento por título, nº, data etc.;

Especificar as origens das referências (quem forneceu);

o Os documentos referenciados devem estar em um Anexo.

6

1.5 VISÃO GERAL

Descrever como está organizado este documento a partir do Capítulo 2:

Descrever o que contém a ERS;

Explicar como a ERS está organizada.

7

2. DESCRIÇÃO GERAL DO PRODUTO

Este capítulo descreve fatores gerais do produto e seus requisitos, mas não

requisitos específicos. Fornece apenas um background para esses requisitos, que

serão detalhados no Capítulo 3.

2.1 ESTUDO DE VIABILIDADE

Aqui deve ser inserida a alternativa selecionada pelo cliente e a justificativa

por tal escolha. A alternativa rejeitada deve ser colocada como um apêndice no final

do manual.

2.2 PERSPECTIVA DO PRODUTO

Considerar aqui as interfaces externas de maneira sucinta – interface do

sistema, do software, de hardware, do usuário, de comunicação, operações, níveis

de acesso, backup, restauração etc.:

Deve ser descrita de maneira resumida, de forma textual, sem detalhamento;

o 1/2 página, no máximo, pois trata-se de uma descrição geral), pois as

interfaces mencionadas nessa seção serão detalhadas na seção

Requisitos de Interface Externa (Item 3.2);

O produto é colocado em perspectiva com outros produtos relacionados. Pode incluir:

o Interfaces do Sistema: com quais outros sistemas o produto de software

interage (se houver);

o Interfaces do Usuário: formatos de telas, relatórios ou consulta, formatos

de mensagens, acesso por níveis de usuário;

8

o Interfaces de Hardware: como o produto interage com os dispositivos de

hardware; características de configuração;

o Interfaces de Software: deve especificar o uso de outros softwares

necessários (BD, SO, software p/ capturar imagem etc.);

o Interfaces de Comunicação: especificar os protocolos de redes locais,

protocolos de comunicação para sistemas multicamadas etc.;

o Limites de Memória: especificar as características e os limites de

memória primária e secundária (limite mínimo);

o Operações: deve especificar requisitos de operações normais e especiais

como rotinas de inicialização (definir os níveis de acesso), processamento,

backups e restauração;

o Requisitos para adaptação de situação: especificar situações em que o

software deve ser adaptado antes da instalação (qualquer sequência de

inicialização);

2.3 FUNÇÕES DO PRODUTO

Inserir aqui as funções do produto agrupadas em Funções Básicas,

Fundamentais e de Saída. Para cada uma das funções, especificar os itens de

informação necessários e as regras de negócio relacionadas:

• Serão descritas todas as funções do produto, e para cada função devem ser

descritos os itens de entrada (dados/informação) e os itens de saída necessários,

além das regras de negócio. Essas funções serão classificadas em:

• Funções Básicas: referem-se às operações CRUD necessárias para a

execução das funções fundamentais. Esse conjunto de operações pode

ser denominado Gerenciar;

• Funções Fundamentais: referem-se às transações de negócio

(movimentações);

9

• Funções de Saída: referem-se às funções que geram informações de

saída relevantes para atender às necessidades do cliente

(consultas/relatórios com cruzamento de informações). Nesse caso,

devem ser descritos não só os itens de entrada (filtros), mas também os

itens de saída (informação) pertinentes;

• É importante que cada função tenha um identificador, a fim de facilitar a

rastreabilidade desse requisito nesse documento. Sugere-se que seja utilizado

RF (requisito funcional) seguido de um underline, uma letra indicando se é

função básica, fundamental ou saída externa (B, F, S) e um número sequencial;

• Ex: RF_B1. e RF_B2. para funções básicas, RF_F1., RF_F2. para funções

fundamentais e RF_S1., RF_S2. para funções de saída externa;

• Não devem ser citados aqui os campos das possíveis tabelas do sistema, tais

como, códigos sequenciais criados para facilitar na implementação. Aqui deverão

ser citados apenas os itens de informação relacionados às funções do sistema;

• As funções de gerenciamento do usuário, backup e restauração do sistema não

serão citadas aqui, uma vez que já foram descritas no item Perspectiva do

Produto;

2.3.1 Funções Básicas

2.3.2 Funções Fundamentais

2.3.3 Funções de Saída

2.4 CARACTERÍSTICAS DO USUÁRIO

10

Inserir aqui o perfil atual dos futuros usuários do sistema:

• Descrever o nível educacional dos usuários do sistema, bem como a sua

experiência e o conhecimento sobre informática para que seja diagnosticada a

necessidade de treinamento específico.

2.5 LIMITES, DEPENDÊNCIAS E SUPOSIÇÕES

Inserir aqui quaisquer limites, dependências e suposições a serem

consideradas no desenvolvimento e implantação do software (ex.: quem é o

responsável por realizar os backups e de quanto em quanto tempo; supondo que o

cliente ficou responsável por adquirir um leitor de código de barras, deixar claro aqui

que caso não seja adquirido, o sistema não terá o mesmo desempenho, etc.):

• Deve fornecer uma descrição geral de qualquer outro item que limitará as opções

do desenvolvedor

• Ex: Normas reguladoras; Limitações do hardware; Interfaces com outras

aplicações; Linguagem de programação; Protocolos; Requisitos de

segurança, etc.;

• Deve fornecer uma lista de fatores que afetam os requisitos expressos na

ERS;

• Exemplo:

• O limite para que um certo sistema não tenha sua funcionalidade completa

seria a não aquisição do ponto eletrônico;

• A suposição é de que será adquirido o ponto eletrônico;

• O desempenho total do sistema depende da satisfação dessa suposição,

pois a não aquisição do ponto eletrônico fará com que a entrada de dados

seja feita manualmente, inserindo somente as exceções do ponto diário,

ou seja, a falta dos funcionários.

11

2.6 REQUISITOS ADIADOS

Explicitar aqui os requisitos do sistema que não serão contemplados neste

documento, se for o caso:

• Identificar os requisitos que podem ser adiados até às versões futuras do sistema

12

3. REQUISITOS ESPECÍFICOS (Paradigma Estruturado)

Os sub-itens deste capítulo se aplicam ao paradigma de desenvolvimento

ESTRUTURADO. O capítulo deve conter todos os requisitos do software com um

nível de detalhamento suficiente para possibilitar aos projetistas e desenvolvedores

projetar um sistema que atenda a esses requisitos.

3.1 MODELO AMBIENTAL

3.1.1 Diagrama de Contexto

3.1.2 Lista de Eventos

3.1.3 DFDs Particionados e Refinamentos

3.1.4 Dicionário de Dados

3.2 REQUISITOS DE INTERFACES EXTERNAS

Inserir com detalhes o conteúdo descrito no item 2.2

13

4. PROJETO DE SOFTWARE (Paradigma Estruturado)


ESTRUTURADO. O capítulo deve conter todos os itens de projeto de software com

um nível de detalhamento suficiente para possibilitar aos projetistas e

desenvolvedores codificar um sistema que atenda a esses itens de projeto.

4.1 DIAGRAMA DE ESTRUTURA MODULAR

4.2 PSEUDOCÓDIGO (opcional)

4.3 LAYOUT DE TELAS

4.4 TABELA DE CRUZAMENTO

Inserir uma tabela de cruzamento: Programas x Tabelas BD x Tipo de

Acesso. Tipo de Acesso pode ser L (para leitura) ou G (para gravação) ou L/G

(leitura e gravação).

14

3. REQUISITOS ESPECÍFICOS (Paradigma Orientado a Objetos)


ORIENTADO A OBJETOS. O capítulo deve conter todos os requisitos do software

com um nível de detalhamento suficiente para possibilitar aos

projetistas/desenvolvedores projetar um sistema que atenda a esses requisitos.

3.1 CASOS DE USO

3.1.1 Diagrama de Casos de Uso

3.1.2 Especificação de Casos de Uso

Utilizar os modelos fornecidos nos apêndices deste documento. Para os

casos de uso CRUD, especificar apenas 1 deles pelo modelo estendido para CRUD,

e as demais CRUDs como caso de uso de alto nível.

3.1.3 Diagrama de Atividades

Apenas para os casos de uso mais complexos. Não é necessário para as

CRUDs.

3.1.4 Diagramas de Sequência de Análise

Apenas para os casos de uso mais complexos. Não é necessário para as

CRUDs.

15

3.2 MODELO CONCEITUAL

3.3 REQUISITOS DE INTERFACES EXTERNAS

Inserir com detalhes o conteúdo descrito no item 2.2.

16

4. PROJETO DE SOFTWARE (Paradigma Orientado a Objetos)

4.1 DIAGRAMAS DE INTERAÇÃO

Não é necessário especificar as CRUDs.

4.2 DIAGRAMA DE CLASSES

4.3 MAPEAMNTO OO-RELACIONAL

4.4 LAYOUT DE TELAS

4.5 MODELO NAVEGACIONAL (Apenas para sistemas web)

17

4. CRONOGRAMA DE ATIVIDADES (Apenas para a Qualificação)

Inserir uma tabela com as atividades concluídas para qualificação e as

atividades a serem realizadas para a defesa. Ex.:

ANOATIVIDADES Abr Ma

iJun Jul Ago Set Out Nov Dez

Levantamento de Requisitos Ok Ok Ok XManual do Sistema Ok X X X X XAnálise do Sistema X XProjeto do Sistema X XDesenvolvimento X X XTestes X X X XManual do Usuário X X

18

Apêndice A – Alternativa rejeitada do Estudo de Viabilidade

Apêndice B – Procedimentos de instalação do Banco de Dados e do Software

Anexo 1 ... N – Referências (documentos apresentar no item 1.4) e Manual do UsuárioO manual do usuário deverá conter um índice com uma nova numeração de páginas, independente da numeração do manual do sistema, iniciando da página 1.

19

Anexo N+1 – Modelo para Casos de Uso CRUD

Este padrão é utilizado para a documentação dos requisitos de operações de manutenção em sistemas de informação, por meio do uso de modelos e especificações de casos de uso. Os requisitos de operações de manutenção são caracterizados por operações de Inclusão, Consulta, Alteração e Exclusão.

EstruturaFluxo básico

1. O caso de uso inicia quando o <nome do ator> necessita fazer a manutenção (inclusão, alteração, exclusão ou consulta) de um <nome da entidade>.

<descrever a condição de início do caso de uso>

2. De acordo com o tipo de operação de manutenção desejado pelo <nome do ator>, um dos subfluxos é executado:

a. Se o <nome do ator> deseja incluir um novo <nome da entidade>, o subfluxo Incluir <nome da entidade> é executado.

b. Se o <nome do ator> deseja alterar informações de um <nome da entidade> já cadastrada, o subfluxo Alterar <nome da entidade> é executado.

c. Se o <nome do ator> deseja excluir um <nome da entidade> já cadastrado, o subfluxo Remover <nome da entidade> é executado.

d. Se o <nome do ator> deseja consultar informações sobre um ou mais<nome da entidade> cadastrados, o subfluxo Consultar <nome da entidade> é executado.

Subfluxo Incluir <nome da entidade>1. Este subfluxo inicia quando o <nome do ator> solicita incluir um <nome da entidade>;

2. O sistema solicita ao <nome do ator> o preenchimento dos seguintes atributos:

- <lista de atributos>

3. O <nome do ator> preenche os atributos anteriores e confirma a inclusão;

4. O sistema realiza a inclusão dos dados informados pelo <nome do ator> no passo 3;

5. O sistema exibe uma mensagem informando que a inclusão da <nome da entidade> foi efetivada com sucesso;

Subfluxo Alterar <nome da entidade>1. Este subfluxo inicia quando o <nome do ator> solicita alterar um <nome da entidade>;

2. O <nome do ator> seleciona um único <nome da entidade>;

3. O sistema solicita a alteração dos atributos:

- <lista de atributos que podem ser alterados>

4. O <nome do ator> altera os dados desejados e confirma a alteração;

20

5. O sistema realiza a alteração dos dados informados no passo 4;

6. O sistema exibe uma mensagem de confirmação informando que a alteração do <nome da entidade> foi efetivada com sucesso;

Subfluxo Remover <nome da entidade>1. Este subfluxo inicia quando o <nome do ator> solicita remover uma ou mais <nome da

entidade>;

2. O <nome do ator> seleciona quais <nome da entidade> deseja remover e solicita a remoção;

3. O sistema solicita a confirmação para remoção;

4. O <nome do ator> confirma a remoção;

5. O sistema remove os <nome da entidade> confirmados;

6. O sistema exibe uma mensagem informando que a remoção dos <nome da entidade> foi efetivada com sucesso;

Subfluxo Consultar <nome da entidade>1. Este subfluxo inicia quando o <nome do ator> solicita consultar <nome da entidade>;

2. O sistema solicita o preenchimento dos seguintes filtros:

- <lista de filtros>

3. O <nome do ator> preenche os filtros e solicita a consulta;

4. O sistema apresenta as seguintes informações dos <nome da entidade> obtidos na consulta:

- <lista de atributos>

Validações e regras de negócio- Esta regra se aplica a todos os subfluxos. Atributos obrigatórios. Se algum atributo obrigatório

não tiver sido preenchido, <descrever que ações o sistema deve tomar, por exemplo, “o sistema não completará a operação e notificará ao <nome do ator>, solicitando o preenchimento”>;

- Esta regra se aplica a todos os subfluxos. Atributos com valores não permitidos. Se algum atributo for preenchido com valor não permitido, <descrever que ações o sistema deve tomar, por exemplo, “o sistema não completará a operação e notificará ao <nome do ator>, solicitando o preenchimento”>;

- No subfluxo Remover, o sistema valida os <nome da entidade> selecionados de acordo com as seguintes regras:

o <regras de remoção>

EXEMPLOEste exemplo apresenta o caso de uso Manter Cliente de uma aplicação de CallCenter.

21

Fluxo básico

.

.

.

Subfluxo Incluir <nome da entidade>1. Este subfluxo inicia quando o Operador de Telemarketing solicita incluir um cliente;

2. O sistema solicita ao Operador de Telemarketing o preenchimento dos seguintes atributos:

- Nome *

- Logradouro. Descreve a rua ou a avenida em que o cliente reside;

- Número

- Bairro

- Cidade

- Estado (campo de escolha fechada. Valores possíveis: todos os estados cadastrados no sistema);

- CPF *

- Sexo (campo de escolha fechada. Valores possíveis: feminino e masculino).

3. O Operador de Telemarketing preenche os atributos anteriores e confirma a inclusão;

4. O sistema realiza a inclusão dos dados informados pelo Operador de Telemarketing no passo 3;

5. O sistema exibe uma mensagem informando que a inclusão do cliente foi efetivada com sucesso;

(*) atributos obrigatórios

Subfluxo Alterar <nome da entidade>1. Este subfluxo inicia quando o Operador de Telemarketing solicita alterar um cliente;

2. O Operador de Telemarketing seleciona um único cliente;

3. O sistema solicita a alteração dos atributos listados no passo 2 do subfluxo Icluir.

4. O Operador de Telemarketing altera os dados desejados e confirma a alteração;

5. O sistema realiza a alteração dos dados informados no passo 4;

6. O sistema exibe uma mensagem de confirmação informando que a alteração do cliente foi efetivada com sucesso;

Subfluxo Remover <nome da entidade>

22

1. Este subfluxo inicia quando o Operador de Telemarketing solicita remover um ou mais clientes;

2. O Operador de Telemarketing seleciona quais clientes deseja remover e solicita a remoção;

3. O sistema solicita a confirmação para remoção;

4. O Operador de Telemarketing confirma a remoção;

5. O sistema remove os clientes confirmados;

6. O sistema exibe uma mensagem informando que a remoção dos clientes foi efetivada com sucesso;

Subfluxo Consultar <nome da entidade>1. Este subfluxo inicia quando o Operador de Telemarketing solicita consultar clientes;

2. O sistema solicita o preenchimento dos seguintes filtros:

- nome

- CPF

3. O Operador de Telemarketing preenche os filtros e solicita a consulta;

4. O sistema apresenta as seguintes informações dos clientes obtidos na consulta:

- Nome, logradouro, número, bairro, cidade, estado, CPF e sexo.

Validações e regras de negócio- Esta regra se aplica a todos os subfluxos. Atributos obrigatórios. Se algum atributo obrigatório

não tiver sido preenchido, o sistema não completará a operação e notificará ao Operador de Telemarketing, informando quais campos obrigatórios não foram preenchidos e solicitando o preenchimento dos mesmos;

- Esta regra se aplica a todos os subfluxos. Atributos com valores não permitidos. Se algum atributo for preenchido com valor não permitido, o sistema não completará a operação e notificará ao Operador de Telemarketing, informando quais campos foram preechidos com valores inválidos e solicitando o preenchimento correto;

- No subfluxo Remover, o sistema valida os clientes selecionados de acordo com as seguintes regras:

o Cliente que tiver algum chamado em aberto não poderá ser removido.

23

Anexo N+2 – Modelo para Casos de Uso Estendidos

Estes padrões são utilizados para os demais casos de uso que não sejam CRUD.

Caso de Uso:

Ator Principal:Interessados e Interesses:

Referências Cruzadas:

Pré-condições:

Pós-condições:

Fluxo Básico:

1 ...

2 ...

3 ...

Fluxos Alternativos:

Padrão com fluxo básico em 2 colunas:

Caso de Uso:



Pré-condições:

Pós-condições:

Fluxo Básico:

Ação do Ator Resposta do Sistema1 ... 2 ...

3 ... 4 ...

Fluxos Alternativos:

24

Anexo N+3 – Modelo para Casos de Alto Nível

Este padrão é utilizado para os demais casos CRUD que não são especificados pelo modelo de caso

de uso CRUD.

Caso de Uso:



Visão Geral:

25

manual_do_sistema-20140923213926 fatec€¦ · web viewnome do aluno. modelo de manual de...

Documents