Upload
duongnhi
View
217
Download
0
Embed Size (px)
Citation preview
FACULDADE DE TECNOLOGIA DE PRESIDENTE PRUDENTE
NOME DO ALUNO
MODELO DE MANUAL DE SISTEMA COMO TRABALHO DE CONCLUSÃO DE CURSO
Presidente Prudente2014
FACULDADE DE TECNOLOGIA DE PRESIDENTE PRUDENTE
NOME DO ALUNO
MODELO DE MANUAL DE SISTEMA COMO TRABALHO DE CONCLUSÃO DE CURSO
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
FACULDADE DE TECNOLOGIA DE PRESIDENTE PRUDENTE
NOME DO ALUNO
MODELO DE MANUAL DE SISTEMA COMO TRABALHO DE CONCLUSÃO DE CURSO
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)
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)
Os sub-itens deste capítulo se aplicam ao paradigma de desenvolvimento
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)
Os sub-itens deste capítulo se aplicam ao paradigma de desenvolvimento
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:
Ator Principal:Interessados e Interesses:
Referências Cruzadas:
Pré-condições:
Pós-condições:
Fluxo Básico:
Ação do Ator Resposta do Sistema1 ... 2 ...
3 ... 4 ...
Fluxos Alternativos:
24