Trabalho Lab

SIS CO
Especificação de Software
Versão <9.0>
Autores:
Luiz Henrique Figueiredo
Período: 5°
Professora: Maísa Cristina de Souza Dias

Mestre em Informática – PUC Minas
Ipatinga – MG, <Data>

APROVAÇÃO DO PROJETO
Aprovamos o documento de Especificação de Requisitos do projeto.
RESPONSÁVEL CARGO DATA ASSINATURA
CONTRATANTE1 Gerente Empresa X 25/01/2015
CONTRATADO Responsável Empresa X 25/01/2015
Luiz Analista Banco de Dados 25/01/2015
Luiz 25/01/2015
HISTÓRICO DA REVISÃO
DATA VERSÃO DESCRIÇÃO AUTOR

Capítulos do Projeto que sofreram
28/06/2017 1.0 Luiz
alterações: 3.0
28/06/2017 2.0 Luiz
alterações: 1.0
29/06/2017 3.0 Luiz
alterações: 4.0
29/06/2017 4.0 Luiz
alterações: 5.1, 5.2, 5.3
30/06/2017 5.0 Luiz
alterações: 8.1, 8.2, 8.2.1, 8.2.2
30/06/2017 6.0 Luiz
alterações: 6.1, 6.1.1, 6.1.2, 6.2
30/06/2017 7.0 Luiz
alterações: 8.6, 8.6.1, 8.6.2.
30/06/2017 8.0 Luiz
alterações: 5.4.
SUMÁRIO
1 Introdução ........................................................................................................................... 6
1.1 Objetivo ................................................................................................................... 6
1.2 Público – Alvo .......................................................................................................... 6
1.3 Benefícios esperados do produto. ........................................................................... 6
2 Glossário – Definições e Siglas ............................................................................................ 7
3 Descrição do Mini-mundo do Projeto ................................................................................. 8
4 Envolvidos no projeto ......................................................................................................... 9
5 Delimitação do Projeto ..................................................................................................... 10
5.1 Lista de funções do Projeto ................................................................................... 10
5.2 Restrições do Projeto (Limites do Produto) ............................................................ 11
5.3 Necessidades de Hardware e Software ................................................................. 11
5.4 Análise de Risco do Projeto ................................................................................... 11
6 Cronograma ....................................................................................................................... 12
6.1 Período do projeto ................................................................................................. 12
6.1.1 Período mínimo .............................................................................................. 12
6.1.2 Período máximo ............................................................................................. 12
6.2 Cronograma........................................................................................................... 12
7 Preço de Venda do Produto .............................................................................................. 13
7.1 Custos do Projeto .................................................................................................. 13
7.2 Preço do Projeto .................................................................................................... 14
8 Documentação do Projeto ................................................................................................ 15
8.1 Materiais de Referência ......................................................................................... 15
8.2 Requisitos de Software .......................................................................................... 15
8.2.1 Requisitos Funcionais..................................................................................... 15
8.2.2 Requisitos Não Funcionais ............................................................................. 21
8.3 Casos de Uso ........................................................................................................ 21
8.3.1 Especificação dos casos de uso ..................................................................... 21
8.4 Diagrama de Classes ............................................................................................ 22
8.5 Diagramas de Sequência....................................................................................... 22
8.6 Modelo de Análise – Projeto de Dados .................................................................. 22
8.6.1 DER (Deve existir em todos os projetos que envolvem banco de dados) ....... 25
8.6.2 Modelo de dados ............................................................................................ 25
9 Projeto de Interface .......................................................................................................... 28
10 Modelo do Plano de Testes do Projeto: ............................................................................ 29
10.1 Introdução ............................................................................................................. 29
10.1.1 Objetivos ........................................................................................................ 29
10.1.2 Escopo ........................................................................................................... 29
10.1.3 Identificação do Projeto .................................................................................. 30
10.2 REQUISITOS A SEREM TESTADOS.................................................................... 30
10.2.1 Teste do Banco de Dados .............................................................................. 30
10.2.2 Teste Funcional .............................................................................................. 30
10.2.3 Teste do Ciclo de Negócios ............................................................................ 31
10.2.4 Teste da Interface do Usuário ......................................................................... 31
10.2.5 Perfil da Performance ..................................................................................... 31
10.2.6 Teste de Carga ............................................................................................... 31
10.2.7 Teste de Stress .............................................................................................. 32
10.2.8 Teste de Segurança e de Controle de Acesso ................................................ 32
10.2.9 Teste de Falha/Recuperação .......................................................................... 32
10.2.10 Teste de Instalação ..................................................................................... 32
10.3 Estratégia de Teste................................................................................................ 32
10.3.1 Tipos de Teste ................................................................................................ 33
10.4 Ferramentas .......................................................................................................... 37
10.5 Equipe ................................................................................................................... 37
10.5.1 Equipe de teste............................................................................................... 38
10.5.2 Infraestrutura .................................................................................................. 39
10.6 Cronograma........................................................................................................... 39
10.7 Documentação complementar ............................................................................... 40
Apresenta-se uma relação dos documentos pertinentes ao projeto. Exemplo: ................. 40
11 CONCLUSÕES ..................................................................................................................... 41
11.1 Análise da Implantação do Projeto ........................................................................ 41
11.2 Análise Conclusiva sobre o Projeto ....................................................................... 41
11.1 Análise da Implantação do Projeto ........................... Error! Bookmark not defined.
11.2 Análise Conclusiva sobre o Projeto .......................... Error! Bookmark not defined.
Referências Bibliográficas ......................................................................................................... 42
ApêndiceS ................................................................................................................................. 43
Apêndice A – QUESTIONÁRIO DE ENTREVISTAS ...................................................................... 43
Apêndice B – CÁLCULO DA ESTIMATIVA DE CUSTO ................................................................. 44
12 AnexoS ............................................................................................................................... 45
Proposta de Desenvolvimento do Projeto de Engenharia de Software 6
1 INTRODUÇÃO
Nesse projeto será estudado um comercio especifico que passa com problemas de controle
de estoques e rendimentos, nele iremos realizar um estudo detalhado de como podemos
melhorar isso, desenvolvendo um software para que possa beneficiar o Dono do Comércio. E
nos tornamos mais capacitados na área do estudo de Engenharia de Software.
Objetivo
O objetivo do trabalho é ampliar os conhecimentos técnicos e analíticos, na área de
Engenharia de Software.
Público – Alvo
Comércios, Lojas em geral.
Benefícios esperados do produto.

O Comercio conseguira administrar o estabelecimento de forma mais inteligente,
rápida e moderna.
2 GLOSSÁRIO – DEFINIÇÕES E SIGLAS
RF– Requisito Funcional
Nf- Requisitos não funcionais
Indpdt – índice do produto
Nmpdt – nome do produto
cdpdt – código do produto

f
Dtinclude – data de inclusão de registro
Qtd- quantidade
Valorpdt- valor do produto
N- numero
D- data
T- Texto
Dt- data
Indcontacess- índice de controle de acesso
Nmuser– número do usuário
Cdfornecedor – código do fornecedor
Estoquepdt – controle de estoque dos produtos
SIGE – Sistema Integrado de Gerência Empresarial;

8
3 DESCRIÇÃO DO MINI-MUNDO DO PROJETO
Sistema para um Comércio

O Comércio é um bar que está localizado, Av. Geraldo Inácio em Coronel
Fabriciano, o estabelecimento funciona a quase 8 anos.
Atualmente ele passa por um problema de controle de estoque. O dono do

comércio nunca sabe exatamente quantos produtos ele tem em seu estoque, por
causa disso ele acaba comprando a mais para não deixar faltar, existe até um certo
de controle, porém ele é feito por uma estimativa de cabeça e nunca exata. Outro
problema se o comerciante gasta sem saber quanto de estoque tem de produtos,
acabando perdendo um pouco do seu lucro que ele poderia está economizando.
O sistema deverá fazer um controle total e exato de quantos produtos o

comercio tem no seu estoque, cadastro de todos os produtos que estão no estoque
e os novos que irão ser comprado e antes fazer uma nova compra o sistema terá
que dizer quanto de produtos o comercio precisa em seu estoque para que ele não
faça uma compra desnecessária e quanto de lucro isso vai gerar para ele fazendo a
compra, e sistema deverá informar ao usuário qual produto está faltando no estoque
e precisa ser comprado e qual produto é desnecessário para fazer a compra e se ele
está fazendo uma compra a mais ou menos.
4 ENVOLVIDOS NO PROJETO
DISPONIBILIDADE DE
NOME FUNÇÃO NO GRUPO CONTATO
HORÁRIO
Luiz Henrique Desenvolvedor 31 987307023 8:00 até 17:00
5 DELIMITAÇÃO DO PROJETO
Lista de funções do Projeto
Foi identificada a seguinte lista de funções para este produto:

Número de Tipo Nome da função Descrição Tempo Tempo Complexidade Prioridade
ordem Estimado Realizado
(Horas) (Horas)
RF [01] 1 Produto Cadastro de produtos Simples Alta
RF [02] 1 Usuário Acesso da conta Simples Alta
RF [03] 2 Caixa Controla o rendimento Médio Ba

RF [04] 3 Rendimentos períodos Rendimentos por períodos Médio Alta
RF [05] 3 Fornecedor Quantidade de fornecedores Simples Alta
RF [06] 3 Estoque de produtos Controle de estoques Médio Alta
RF [07] 1
Tipo: 1 – Cadastro 2 – Controle 3 – Relatório 4 – Controle de Acesso
Complexidade: Simples, médio, complexo
Prioridade: baixa, média, alta
O tempo estimado deve estar em horas e compõem o tempo de implementação de cada funcionalidade.
11
Restrições do Projeto (Limites do Produto)
 Não irá gerar automaticamente Notas Fiscal

 Não terá ajuda on-line;
 Não terá comunicação com a internet;
 Não realizara cadastros de clientes
 Não será usado por usuários públicos,
 Não terá controle de recursos humanos
Necessidades de Hardware e Software
Hardware= Processador Dual Core, 4GB de RAM, 30GB disponíveis em disco.
Software= Windows 7 X86 ou X64 ou superior, leitor de PDF, IDE (para desenvolver
o software),MySql, programas de diagramas.
Análise de Risco do Projeto
Probabilidade
Riscos Estratégias redução de riscos
ocorrer
Dificuldades para aprendizagem de linguagem Disponibilizar contato com algum
Média
de programação conhecedor da linguagem.
Não ter disponíveis softwares necessários Baixa Buscar softwares alternativos
Separar o tempo necessário para se
Disponibilidade de tempo Baixa
dedicar ao projeto.
Melhorar os conhecimentos, em algo
Complexidade Média
especifico, seja ele o software ou analise.
12
6 CRONOGRAMA
Período do projeto
6.1.1 Período mínimo

30/06/2017 a 05/10/2017
6.1.2 Período máximo

30/06/2017 a 30/11/2017
Cronograma
O projeto seguirá as seguintes etapas, distribuídas conforme a abaixo:
TEMPO PREVISTO
ATIVIDADE
EM HORAS
1. Entrevista com o proprietário da empresa; 2 horas
1. 2. Levantamento e Especificação dos Requisitos do sistema 3 horas
3.
2. Projeto de banco de dados 25 horas
4. Desenvolvimento do cadastro de produtos 60 horas
5. Desenvolvimento do Usuário (Acesso a conta) 60 horas
6. Desenvolvimento do Controle do Caixa 60 horas
7. Desenvolvimento Rendimentos por períodos 60 horas
8. Desenvolvimento do Controle de estoque de produtos 60 horas
9. Desenvolvimento Fornecedores 60 horas
10. Desenvolvimento dos relatórios 40 horas
11. Teste do software 150 horas
12. Implementação do cadastro de produtos 50 horas
13. Implementação do Usuário (Acesso a conta) 50 horas
14. Implementação do Controle do Caixa 50 horas
15. Implementação do Rendimentos por períodos 50 horas
16. Implementação do Controle de estoque de produtos 50 horas
17. Implementação Fornecedores 50 horas
18. Implementação dos relatórios 30 horas
13
Cronograma físico (baseado em todos os itens citados anteriormente).
Itens/ Mês Ago Set Out Nov Dez Jan Fev Mar Abr Mai Jun Jul
1
2
3
4
10
11
12
13
14
15
16
17
18
7 PREÇO DE VENDA DO PRODUTO
Custos do Projeto
<Faça uma estimativa (em reais) de quanto você julga que seu sistema custaria>
Deve-se estimar:
O tempo de desenvolvimento (soma das horas do item 4 multiplicado pelo valor da hora)
O custo operacional da empresa (água/luz/telefone/aluguel/limpeza/secretária) – estimar

o custo mensal dividir pelo número de projetos desenvolvidos pela empresa (Aplica-se um
percentual e multiplica-se pelo número de meses previsto no desenvolvimento do
projeto.)
Custo de Ferramentas (Softwares/Hardware) – Estima-se o custo dos itens do tópico 3.4 e

determina-se uma depreciação sobre o custo das ferramentas.
14
Custo de Infra-estrutura: (Registro de Domínios / Hospedagem de Sites / Servidores /

Redes...)
Preço do Projeto
Utilizar a estimativa de custos do item 5.1 e determinar o preço do projeto:
Determinar a margem de Lucro sobre seus custos e repassar aos clientes os custos de infra-
estrutura que terão
15
8 DOCUMENTAÇÃO DO PROJETO
Materiais de Referência
Tipos de Material Referência

Atas de Entrevista Realizada com o Dono do estabelecimento
Documento Ficha contendo seus dados pessoais
Relatório Plano do Projeto
Requisitos de Software
8.1.1 Requisitos Funcionais

Especificar todos os requisitos descritos no quadro do tópico 5.1 conforme o modelo abaixo:
Requisito Funcional [RF 01] – Gestão dos Produtos
Objetivo: Permite aos usuários incluir, alterar, excluir ou consultar informações dos
produtos.
Requisitos: [Quais requisitos Funcionais?]
Permite aos usuários incluir, alterar, excluir ou consultar usuários.
Prioridade: [Qual a prioridade no desenvolvimento?]
Alta
Pré-condições: Informações dos produtos à serem incluídos, alterados, excluídos ou
consultados.
Pós-condições: [Qual o estado posterior do sistema?]
Informações dos produtos que foram incluídos, alterados, excluídos ou
consultados e mensagens de sucesso ou erro.
Fluxo principal: Para inclusão:
 O usuário entra com os dados do produto que deseja incluir/alterar no
sistema.
 As informações são armazenadas no sistema.
 É exibida uma mensagem de sucesso.
Para alteração:
 O usuário informa o produto, o código ou a data do que foi feita um
cadastro e deseja consultar.
 É exibida uma lista de produtos com informações semelhantes aos
dados informados.
 O usuário seleciona o produto desejado para alteração.
 O usuário entra com as novas informações do produto.
 As informações são armazenadas no sistema para consulta.
Para consulta:
 O usuário informa o produto, o código ou a data que o produto foi
cadastro que deseja consultar.
16
 .
dados informados.
 O usuário seleciona o produtos que deseja obter informações.
 As informações são exibidas para o usuário.
Para exclusão:
 O usuário informa o produto, o código ou a data que o produto foi
cadastro que deseja excluir.
dados informados.
 O usuário seleciona o produtos que deseja excluir.
Fluxo secundário: Informações do produtos inválidas ou insuficientes:

Todas informações inseridas no sistema são verificadas, caso essa informação já
exista, seja insuficiente, ou esteja incorreta aparecerá uma mensagem de erro,
como “produto existente”, “dados insuficientes” ou “informações incorretas”.
Requisito Funcional [RF 02] – Gestão Usuário

Objetivo: Permite aos usuários incluir, alterar, excluir ou consultar informações dos
produtos.
Alta
Pré-condições: Informação do usuário para acesso a conta à serem incluídos, alterados,
excluídos ou consultados.
Informação do usuário que foram incluídos, alterados, excluídos ou consultados
e mensagens de sucesso ou erro.
 O usuário entra com os dados do usuário que deseja incluir/alterar no
sistema.
Para alteração:
 O usuário informa o nome ou CPF do usuário que deseja alterar.
 É exibida uma lista de usuários com informações semelhantes aos
dados informados.
 O usuário seleciona o usuário desejado para alteração.
 O usuário entra com as novas informações do usuário
 As informações são armazenadas no sistema
Para consulta:
17
 O usuário informa o nome ou CPF do usuário que deseja consultar.

dados informados.
 O usuário seleciona o usuário que deseja obter informações.
Para exclusão:
 O usuário informa o nome ou CPF do usuário que deseja excluir.
dados informados.
 O usuário seleciona o usuário que deseja excluir
Fluxo secundário: Informações do usuários inválidas ou insuficientes:
como “produto existente”, “dados insuficientes” ou “informações incorretas”.
Requisito Funcional [RF 03] – Gestão de Caixa

Objetivo: Informações de movimentações financeiras à serem incluídos, alterados,
Essencial
Pré-condições: Informação de movimentações financeiras á serem incluídos, alterados,
Informação de movimentações financeiras á serem incluídos, alterados,
 O usuário entra com os dados da movimentação financeira que deseja
incluir/alterar no sistema.
Para alteração:
Para alteração:
 O usuário informa o código ou data da movimentação financeira que
deseja alterar.
 É exibida uma lista de movimentações financeiras com informações
semelhantes aos dados informados.
 O usuário seleciona a movimentação desejada para alteração.
 O usuário entra com as novas informações da movimentação.
Para consulta:
deseja consultar.
18

 O usuário seleciona a movimentação que deseja obter informações.
Para exclusão:
deseja excluir.
 O usuário seleciona a movimentação que deseja excluir
Fluxo secundário: Informações da movimentação financeira inválidas ou insuficientes:
como “movimentação existente”, “dados insuficientes” ou “informações
incorretas”.
Requisito Funcional [RF 04] – Gestão de Rendimentos por períodos

Objetivo: Informações de rendimentos por períodos à serem incluídos, alterados,
Alta
Pré-condições: Informação dos rendimentos por períodos á serem incluídos, alterados,
Informação dos rendimentos por períodos dos á serem incluídos, alterados,
 O usuário entra com os dados dos rendimentos por períodos que
deseja incluir/alterar no sistema.
Para alteração:
 O usuário informa o código ou data dos rendimentos por períodos que
deseja alterar.
 É exibida uma lista dos rendimentos por períodos com informações
 O usuário seleciona dos rendimentos por períodos para alteração.
 O usuário entra com as novas informações dos rendimentos por
períodos
Para consulta:
deseja consultar.
19
 semelhantes aos dados informados.

 O usuário seleciona o dos rendimentos que deseja obter informações.
Para exclusão:
deseja excluir.
 O usuário seleciona os rendimentos que deseja excluir
Fluxo secundário: Informações dos rendimentos por períodos inválidas ou insuficientes:
incorretas”.
Requisito Funcional [RF 05] – Gestão de Fornecedores

Objetivo: Informações do fornecedor à serem incluídos, alterados, excluídos ou
consultados.
Alta
Pré-condições: Informação do fornecedor serem incluídos, alterados, excluídos ou consultados.
Pós-condições: [Qual o estado posterior do sistema? ]
Informação do fornecedor á serem incluídos, alterados, excluídos ou
consultados.
 O usuário entra com os dados fornecedor que deseja incluir/alterar no
sistema.
Para alteração:
 O usuário informa o código do fornecedor que deseja alterar.
 É exibida uma lista dos fornecedores com informações semelhantes aos
dados informados.
 O usuário seleciona o fornecedor para alteração.
 O usuário entra com as novas informações do fornecedor
Para consulta:
 O usuário informa o código do fornecedor que deseja consultar.
dados informados.
 O usuário seleciona o fornecedor que deseja obter informações.
Para exclusão:
20
 O usuário informa o código do fornecedor que deseja excluir.

dados informados.
 O usuário seleciona o fornecedor que deseja excluir
Fluxo secundário: Informações do fornecedor inválidas ou insuficientes:

incorretas”.
Requisito Funcional [RF 05] – Gestão de Estoque

Objetivo: Informações do Estoque à serem incluídos, alterados, excluídos ou consultados.
Alta
Pré-condições: Informação do Estoque serem incluídos, alterados, excluídos ou consultados.
Pós-condições: [Qual o estado posterior do sistema? ]
Informação Estoque a serem incluídos, alterados, excluídos ou consultados.
 O usuário entra com o código do estoque que deseja incluir/alterar no
sistema.
Para alteração:
 O usuário informa o código do estoque que deseja alterar.
 É exibida uma lista do estoque com informações semelhantes aos
dados informados.
 O usuário seleciona o estoque para alteração.
 O usuário entra com as novas informações do estoque
Para consulta:
 O usuário informa o código do estoque que deseja consultar.
 É exibida uma lista dos estoques com informações semelhantes aos
dados informados.
 O usuário seleciona o estoque que deseja obter informações.
Para exclusão:
 O usuário informa o código do estoque que deseja excluir.
 É exibida uma lista dos estoques com informações semelhantes aos
dados informados.
 O usuário seleciona o estoque que deseja excluir
21
Fluxo secundário: Informações do estoque inválidas ou insuficientes:

incorretas”.
8.1.1.1 Descrição dos Atores
Frequência de Proficiência em
Num. Nome Descrição
Uso Informática
É um usuário comum que procura uma
forma de melhorar seus lucros e
1 Comerciante Diária Baixa
gerenciar seu comercio de uma forma
mais inteligente e eficiente.
8.1.2 Requisitos Não Funcionais
REQUISITOS NÃO FUNCIONAIS

Atributo Detalhes ou condição limite
Tempo de Resposta Condição Limite:
 O Sistema deverá ser ágil e leve. O tempo de resposta aceitável do sistema
será de no máximo 2 segundos, exceto em geração de relatórios, onde o
tempo de resposta aceitável será de no máximo 10 segundos.
Tipo de Interface Detalhe:
 Usar formulários para entrada de dados;
 Aumentar a facilidade de uso via mouse ao invés do teclado.
Tolerância a falhas Condição Limite:
 Todas as variáveis de entrada terão valores default e os valores serão
usados sempre que dados de entrada estiverem faltando ou inválidos.
Plataformas Operacionais Detalhe:
 Operar nas plataformas Windows 2000 ou acima;
Casos de Uso
Acrescentar o diagrama de caso de uso
8.1.3 Especificação dos casos de uso

22
Devem ser documentadas todas as funções relacionadas aos casos de uso. Detalhamento ou
descrição do caso de uso.
Diagrama de Classes
Acrescentar o diagrama de classe do seu sistema
Diagramas de Sequência
<Aqui deverá constar o diagrama de sequência do projeto do sistema. No caso de cadastros

básicos, não há a necessidade de criar todos os diagramas de sequência.
Modelo de Análise – Projeto de Dados
Seguir o modelo abaixo de Padrão de Documentação (exclui-lo do projeto ao término desta

atividade):
Modelo padrão de documentação de Banco de Dados
Nome de Bancos: Máximo de 12 caracteres.

10 primeiros caracteres = Livre
Penúltimo caracter = símbolo _ (underline)
Último caracter = Ambiente do Banco. T (Teste) ou P(Produção)
Ex: Orcamento_P
Nome de Tabelas: 8 Caracteres.

2 primeiros caracteres = sigla do sistema
3º caracter = Tipo da tabela. C = Cadastro; T = Tabela; D = Derivada; W = Visão
Restante dos caracteres = Livre. Algo que identifique o nome da tabela.
Ex: EICALUNO
23
Nome de Campos: Máximo de 9 caracteres.

2 primeiros caracteres = Tipo de campo. Veja Anexo1.
Restante dos caracteres = Livre. Algo que identifique o nome do campo.
Ex: CDALUNO, NUCHAMADA
Valor Default: Valores Padrões para um determinado campo. Ex.: Data Corrente. Será
colocado automaticamente a data corrente no campo caso o mesmo não seja preenchido.
Domínio: Valores válidos para um determinado campo. Ex: [M, F]. Sexo Masculino ou
Feminino.
Chave Primária: Para criação de nome da chave primária, no banco de dados, o padrão é:
pk_nome da tabela.
Ex: pk_eicaluno.
Chave Secundária: Para criação de nome da chave secundária banco de dados, o padrão é:
Fk_nome da tabela onde está a chave secundária_nome da tabela onde está a chave de
referência.
Ex: fk_eicaluno_eitserie.
Tipos de Campos
CD – Código. Ex: CDALUNO (Código Aluno)
NM – Nome. Ex: NMALUNO (Nome Aluno)
DS – Descrição. Ex: DSOBERVAC (Descrição da Observação)
NU – Número. Ex: NUMATRICU (Número da Matrícula)
VL – Valor. Ex: VLDESPESA (Valor Despesa)
ID – Identificador. Ex: IDATIVO (Indica se registro está ativo ou não)
AA – Ano. Ex: AALETIVO (Ano Letivo)
MM - Mês. Ex: MMATUAL (Mês Atual)
DD - Dia. Ex: DDLETIVO (Dia Letivo)
DT – Data. Ex: DTCADASTR (Data Cadastro)
TP – Tipo. Ex: TPLOGRADO (Tipo Logradouro)
24
TS – Timestamp (Data e Hora) . Ex: TSCADASTRO (Data e Hora do Cadastro)

SG – Sigla. Ex: SGSETOR (Sigla do Setor)
DC – Documento. Ex: DCCPF (Número do Documento CPF)
ED – Endereço. Ex: EDEMAIL (Endereço de Email)
IM – Imagem. Ex: IMFOTOALU (Imagem da Foto do Aluno)
QT – Quantidade. Ex: QTREGISTR (Quantidade de Registros)
SQ – Sequencial. Ex: SQREGISTR (Número Sequencial do Registro)
Obs: Em todos os nomes deve ser observado o seguinte: Não são permitidos acentos ou
qualquer tipo de caracter especial, exceto o símbolo _(underline) que é utilizado na
definição do nome do banco.
25
8.1.4 DER
8.1.5 Modelo de dados

Relação dos Atributos das Entidades
ENTIDADE Produto
Descrição: Produto
Nome do Índice Atributos Único (Sim, Não)
Índices: IND_PDT_NMPDT NMPDT SIM
Descrição: Tabela que contém todos os produtos oferecidos pelo Comercio.
Atributos:
Nome do Atributo Tipo Tamanho Descrição Máscara Regra de Valores Integridade
Validação Válidos Referencial
CDPDT N 5,0 Código do Produto 99.999 >0
NMPDT T 50 Nome do Produto Obrigatório
DTINCREG D 10 Data Inclusão Registro 99/99/9999 < = date ( )
QTD N 5,0 Quantidade de produto incluído 999 >0
VLRPDT N 5,0 Valor unitário do produto 99.999.00 >0
ENTIDADE Usuário
Descrição: Usuário
Índices: IND_USER_NMUSER NMUSER SIM
Descrição: Tabela que contém todos os usuários.
Atributos:
26

CDUSER N 5,0 Código do usuário 99.999 >0
NMUSER T 50 Nome do usuário Obrigatório
DADOSUSER N 5,0 Dados do usuário 999 >0
ENTIDADE CAIXA
Descrição: CAIXA
Índices: IND_CAIXA_CAIXACONTROL CAIXACONTROL SIM
Descrição: Tabela que contém o controle do caixa.
Atributos:
CDCAIXACONTROL N 5,0 Código do controle de caixa 99.999 >0
CAIXARENDI N 50 Rendimentos do Caixa Obrigatório
ENTIDADE Fornecedor
Descrição: Fornecedor
Índices: IND_FORN_FORNNM FORNNM SIM
Descrição: Tabela que contém os Fornecedores
Atributos:
CDFORN N 5,0 Código do Fornecedor 99.999 >0
NMFORN N 50 Números de fornecedores Obrigatório
DADOSFORN N 10 Dados dos fornecedores
27
ENTIDADE Estoque
Descrição: Estoque
Índices: IND_ESTOQUE_ESTOQUEPDT ESTOQUEPDT SIM
Descrição: Tabela que contém os Fornecedores
Atributos:
CDESTOQUE N 5,0 Código do Estoque de produtos 99.999 >0
NMESTOQUEPDT N 50 Números de Estoques de produtos Obrigatório
VRLESTOQUE N 50 Valores dos Estoques de produtos
28
9 PROJETO DE INTERFACE
<Apresentar aqui os layouts das telas do seu sistema. No caso de cadastros básicos, basta
apenas o protótipo de uma tela. No caso dos controles, gerar o layout para todas as telas.
Para os relatórios, basta gerar um layout para cada modelo.>
Nº Nome Descrição
1 Tela de Usuários Interface para inclusão, consulta, alteração
exclusão de usuários.
2 Tela de Produtos Interface para inserção, alteração, consulta
exclusão de produtos.
3 Tela de Caixa Interface para consultar os lucros
4 Tela de Rendimentos por Interface para consultar os rendimentos
períodos por períodos.
Tela de Estoques de Produtos Interface para consultar quantidade de
produtos no estoque
5 Relatório de Fornecedores Lista dos fornecedores do comercio
29
10 MODELO DO PLANO DE TESTES DO PROJETO:
Gerenciador de Serviços Automotivos
Introdução
Contém uma identificação do projeto, descrição dos objetivos do documento, o público
ao qual ele se destina e escopo do projeto a ser desenvolvido. Pode adicionalmente
conter termos e abreviações usadas, além de informar como o plano deve evoluir.
10.1.1 Objetivos
O documento do Plano de Testes do software GSA (Gerenciador de Serviços
Automotivos) tem como objetivo listar os Requisitos que serão testados
recomendando e descrevendo as estratégias a serem empregadas nesses testes. Este
documento também identifica os recursos necessários e disponibiliza uma estimativa
dos esforços de teste.
10.1.2 Escopo
O Gerenciador de Serviços Automotivos deverá ser submetido a testes de unidade,
integração, sistema e aceitação.
Os testes de unidade avaliarão isoladamente o banco de dados, a interface gráfica, e

todos os outros componentes do projeto.
O teste de integração testa os componentes, previamente testados isoladamente,

acoplados. O objetivo é identificar possíveis falhas nos acoplamentos.
Os testes de sistema avaliarão o funcionamento e o desempenho do sistema como

um todo, verificando a eficácia e segurança, além da compatibilidade e integração do
software em diferentes ambientes.
Os testes de aceitação apresentarão o produto final para o usuário para validação e

últimos ajustes.
30
Para realizar os testes serão utilizadas máquinas com as configurações mais próximas
o possível das máquinas que serão utilizadas pelo usuário final, tentando assim,
simular o ambiente final em que o programa será executado.
10.1.3 Identificação do Projeto

Documento Criado ou Disponível Recebido ou Revisado
Especificação de Requisitos Sim Não Sim Não
Plano de Projeto Sim Não Sim Não
Modelo de Análise Sim Não Sim Não
Modelo de Projeto Sim Não Sim Não
Documento de Arquitetura Sim Não Sim Não
Protótipo Sim Não Sim Não
Manual do Usuário Sim Não Sim Não
Lista de Riscos Sim Não Sim Não
REQUISITOS A SEREM TESTADOS
Esta seção descreve em linhas gerais o conjunto de requisitos a serem testados no

projeto a ser desenvolvido, comunicando o que deve ser verificado. Exemplos de
requisitos a serem testados são: Estabilidade, desempenho, segurança, interface de
usuário, controle de acesso, funcionalidades.
10.1.4 Teste do Banco de Dados
Verifique se as informações sobre departamentos, funcionários, clientes, serviços e

automóveis podem ser inseridas ou modificadas do Banco de Dados
Verifique se as informações obtidas no Banco de Dados consistem com as
informações reais sobre departamentos, funcionários, clientes, serviços e automóveis.
Verifique que as informações cadastradas possam ser consultadas.
10.1.5 Teste Funcional

31
Verifique que qualquer usuário cadastrado possa acessar o sistema através de um

login e senha.
Verifique se o nível de acesso às funcionalidades do sistema a cada tipo de usuário
está correto.
10.1.6 Teste do Ciclo de Negócios
 Verifique se os relatórios estão sendo gerados corretamente.

 Verifique se o tratamento de exceções está correto
 Verifique se os campos obrigatórios estão sendo preenchidos em cada formulário
 Verifique se os campos estão sendo preenchidos com informações no formato
correto em cada formulário
10.1.7 Teste da Interface do Usuário
 Verifique se cada tela de interface gráfica pode ser facilmente entendida e

utilizada.
 Verifique que se os relatórios são apresentados corretamente na tela.
 Verifique se os formulários de cadastro e edição estão pegando os dados inseridos
pelo usuário corretamente.
10.1.8 Perfil da Performance
 Verifique o tempo de resposta de consultar/inserção/edição no banco de dados.

 Verifique o tempo de resposta da troca de informações entre servidor e terminais.
10.1.9 Teste de Carga
Verificar a resposta do sistema com 5 usuários.

32
10.1.10 Teste de Stress
 Verifique como o sistema se comporta em situações onde são realizados várias

operações (inserir/editar/remover) simultâneas no banco de dados.
 Verifique como o sistema se comporta em situações onde há pouca memória RAM
disponível e/ou pouca memória em disco.
10.1.11 Teste de Segurança e de Controle de Acesso
 Verificar que apenas usuários cadastrados podem acessar informações e

funcionalidades do sistema.
 Verificar que somente o administrador tem acesso a cadastrar/editar/remover e
consultar departamentos e funcionários.
 Verificar que todos usuários cadastrados no sistema possam
cadastrar/editar/remover e consultar informações sobre clientes, serviços e
automóveis.
10.1.12 Teste de Falha/Recuperação

Nenhum.
10.1.13 Teste de Instalação
Verifique que a instalação do sistema ocorre normalmente em todas as máquinas

que possuam os requisitos mínimos.
Verifique que a ferramenta possa ser instalada em diferentes ambientes (ex:
Windows XP ou Windows Vista)
Verifique que a atualização dos dados no servidor se reflete em todos os terminais.
Estratégia de Teste
Apresenta um conjunto de tipos de testes a serem realizados, respectivas técnicas

empregadas e critério de finalização de teste. Além disso, é listado o conjunto de
33
ferramentas utilizadas.
10.1.14 Tipos de Teste

10.1.14.1 Teste de Integridade de Dados e do Banco de Dados
Objetivo do Teste: Garantir que o acesso ao banco de dados funciona
adequadamente e sem inconsistência dos dados.
Técnica:  Invocar cada método de acesso ao banco de dados,
alimentando cada um com dados válidos e inválidos.
 Inspecionar o banco de dados e verificar se os dados nas
tabelas estão de acordo com as ações realizadas
Critério de Todos os métodos e processos de acesso à base de dados
Finalização: funcionam como projetados e sem nenhuma corrupção de dados.
Considerações O teste pode necessitar de um ambiente de
Especiais: desenvolvimento ou drivers de SGBD para inserir ou
modificar os dados diretamente na base de dados.
Processos devem ser invocados manualmente
10.1.14.2 Teste de Função

Objetivo do Teste: Garantir que as funcionalidades do sistema, especificadas
nos casos de usos, estão gerando os resultados esperados.
Técnica: Executar cada caso de uso funcional através de seu fluxo
principal e secundário, usando dados válidos e inválidos, para
verificar o seguinte:
 Os resultados esperados ocorrem quando dados válidos
são usados.
 As mensagens de erro ou aviso apropriadas são exibidas
quando dados inválidos são usados.
 Cada regra de negócio é aplicada apropriadamente.
Critério de  Todos os testes planejados foram executados.
Finalização:  Todos os defeitos identificados foram tratados.
34
Considerações Nenhum
Especiais:
10.1.14.3 Teste da Interface do Usuário

Objetivo do Teste:  Verificar se a navegação através dos alvos de teste reflete
as funções e os requisitos do negócio apropriadamente.
 Objetos e características da janela, tais como menus,
tamanho, posição, estado e foco conformam-se aos padrões.
Técnica:  Criar ou modificar os testes para cada janela para verificar a
navegação e os estados de objeto apropriados para cada
janela e objetos da aplicação.
 Observar grupos de usuários usando a interface, analisando a
taxa de aprendizado dos mesmos com o sistema e a aceitação
da interface pelos usuários.
Critério de  É verificado que cada janela permanece consistente com a
Finalização: versão de comparação ou dentro de padrões aceitáveis.
 É verificado que o usuário consegue usar a interface sem
precisar de treinamento e a considera agradável.
Considerações Nem todas as propriedades para objetos personalizados e
Especiais: terceirizados podem ser acessadas.
10.1.14.4 Teste de Performance

Objetivo do Teste: Verificar os comportamentos do sistema em relação à sua
performance sob as seguintes condições:
Carga de trabalho normal prevista
Carga de trabalho no pior caso prevista
35
Técnica:  Usar Procedimentos de Teste desenvolvidos para Teste da

Função e Ciclo de Negócio.
 Scripts devem ser rodados em uma máquina (melhor caso
para comparar um único usuário, uma única transação) e
ser repetidas com múltiplos clientes (virtual ou real, ver
Considerações Especiais abaixo).
Critério de Único usuário ou transação: finalização com sucesso sem
Finalização: nenhuma falha e dentro do tempo especificado
Múltiplos usuários ou transações: finalização bem sucedida
sem qualquer falha e dentro do tempo especificado.
Considerações Um teste abrangente de performance inclui ter uma carga de
Especiais: trabalho no servidor.
Há vários métodos que podem ser usados para executar isso,
incluindo:
 “Direcionar transações” diretamente para o servidor,
usualmente na forma de chamadas SQL.
 Criar carga de usuário “virtual” para simular muitos
clientes, normalmente várias centenas. Ferramentas de
Emulação de Terminal Remoto (RTE) são usadas para
atingir essa carga. Essa técnica também pode ser usada
para carregar uma rede com “tráfego”.
 Usar múltiplos clientes físicos, cada um rodando scripts de
teste para gerar uma carga no sistema.
O teste de performance deve ser executado em uma máquina
dedicada ou em um tempo dedicado. Isso permite controle
total e mensuração precisa.
As bases de dados usadas para o Teste de Performance
devem ser ou do tamanho real ou proporcionalmente iguais.
10.1.14.5 Teste de Carga

bjetivo do Teste: Verificar o funcionamento do sistema sobrecarregado.
36
Usar testes desenvolvidos para o Teste do Ciclo de Negócio ou

Função, aumentando o tamanho da carga de dados inseridos e
Técnica: verificados no servidor, ate encontrar o limite de funcionamento
do servidor. Verificando a seguir a compatibilidade dos dados e as
regras de negócios.
Uma sobrecarga possível para o ambiente para o qual o ambiente
Critério de
está sendo desenvolvido deve ser suportada corretamente e sem
Finalização:
comprometer a eficiência do sistema.
10.1.14.6 Teste de Segurança e Controle de Acesso

Objetivo do Teste: Verificar que apenas aqueles usuários com acesso ao sistema e
aplicações têm permissão de acessá-los. Este usuário pode
acessar apenas aquelas funções ou dados para os quais o seu tipo
de usuário tem permissão.
Técnica:  Segurança do Nível de Aplicação: Identifique e liste cada
tipo de usuário e as funções ou dados para os quais cada tipo
tem permissão.
 Crie testes para cada tipo de usuário e verifique cada
permissão criando transações específicas para cada tipo de
usuário.
 Modifique o tipo de usuário e repita os testes para os
mesmos usuários. Em cada caso, verifique que funções ou
dados adicionais estão corretamente disponíveis ou negados.
 Acesso de Nível de Sistema: Ver Considerações Especiais
abaixo.
Critério de Para cada tipo de ator conhecido as funções ou dados
Finalização: apropriados estão disponíveis, e todas as transações
funcionam como esperado e rodam nos Testes de Função
anteriores.
37
Considerações O Acesso ao sistema deve ser revisado ou discutido com o

Especiais: administrador de rede ou de sistema apropriado. Esse teste
pode não ser necessário já que ele pode ser uma função da
administração da rede ou sistema.
10.1.14.7 Teste de Instalação

Objetivo do Teste: Verifique que os alvos de teste instalam apropriadamente em
cada configuração de hardware necessária sobre as seguintes
condições:
 Uma nova instalação, em uma nova máquina, que nunca
fora anteriormente instalada.
 Atualização, numa máquina onde o software já fora
previamente instalado, para a mesma versão.
 Atualização, numa máquina que já disponha do software
instalado, de uma versão mais velha.
Técnica: Começar ou executar a instalação.
Critério de As transações do software executam de forma bem sucedida,
Finalização: sem falha.
Considerações Saber antecipadamente quais transações do software devem
Especiais: ser selecionadas para abranger um teste de confiança de que a
aplicação foi instalada de forma bem sucedida e que nenhum
componente importante de software está faltando.
Ferramentas
As seguintes ferramentas serão empregadas para esse projeto:
Equipe
Contém descrição da equipe e da infraestrutura utilizada para o desenvolvimento das

atividades de testes, incluindo: pessoal, equipamentos, software de apoio, materiais,
dentre outros. Isto visa garantir uma estrutura adequada para a execução das atividades
de testes previstas no plano.
38
10.1.15 Equipe de teste

Essa tabela mostra as suposições de recrutamento para o projeto.
Recursos Humanos
Trabalhador Recursos Mínimos Responsabilidades Específicas ou
Recomendados Comentários
Gerente de Teste, Ricardo Rolim Fornece supervisionamento gerencial.
Gerente do Projeto de Responsabilidades:
Teste provê direcionamento técnico
adquire recursos apropriados

fornece relatórios de gerenciamento
Test Designer Lamartine Teixeira Identifica, prioriza, e implementa os
casos de teste.
Responsabilidades:
gera o plano de teste
cria o modelo de teste
avalia a efetividade do esforço de teste
Testador Erick Lopes Executa os testes.
Bruno Bourbon Responsabilidades:
 executar os testes
 registrar os resultados
 reestabelecer-se dos erros
 documentar solicitações de
mudança
Administrador do Ricardo Rolim Garante que o ambiente e os bens de
Sistema de Teste teste sejam gerenciados e mantidos.
Responsabilidades:
 administrar o sistema de
gerenciamento teste
 instalar e gerenciar o acesso do
trabalhador ao sistema de testes
39
Gerente do Banco de Bruno Bourbon Garante que o ambiente e bens de teste

Dados, de dados (banco de dados) sejam
Administrador do gerenciados e mantidos.
Banco de Dados Responsabilidades:
 administrar os dados de teste (base
de dados)
Designer Erick Lopes Identifica e define as operações,
atributos, e associações das classes de
teste.
Responsabilidades:
identificar e definir as classes de teste
identificar e definir os pacotes de teste
Implementador Lamartine Teixeira Implementa e faz os testes unitários das
classes e pacotes de teste.
Responsabilidades:
 cria as classes e pacotes de teste
implementados no modelo de teste
10.1.16 Infraestrutura
A tabela seguinte expõe os recursos do sistema para o projeto de teste.
Recursos do Sistema
Servidor de Banco de Dados
— MySQL DataBase Server
Terminais Clientes
—2 PCs (conectados via LAN)
—1 PC com tela sensível ao toque (conectado a uma LAN e à internet)
Repositório de Testes
—1 PC
—3 PCs de Desenvolvimento de Teste
Cronograma
40
Contém uma descrição de marcos importantes (milestones) das atividades (incluindo as

datas de início e fim da atividade). Apenas marcos relevantes devem ser listados, ou
seja, aqueles que contribuirão nas atividades de testes. Por exemplo: projeto de testes,
execução de testes ou avaliação de testes.
ATIVIDADE Início Final

Planejamento de Testes 10/04/2009 30/04/2009
Projetar Testes 10/04/2009 30/04/2009
Implementar Testes 20/05/2009 25/05/2009
Execução de Testes 26/05/2009 28/05/2009
Avaliação de Testes 28/05/2009 01/06/2009
Documentação complementar
Apresenta-se uma relação dos documentos pertinentes ao projeto.

Exemplo:
1. Documento de Requisitos do Sistema Exemplo, Versão 00.01 22/05/2009.

2. Ata de Reunião – Levantamento de Requisitos do Módulo A do Sistema Exemplo,
12/05/2009.
3. Ata de Reunião – Levantamento de Requisitos do Módulo B do Sistema Exemplo,
13/05/2009.
4. Ata de Reunião – Levantamento de Requisitos do Módulo C do Sistema Exemplo,
14/05/2009.
5. Ata de Reunião – Validação de Requisitos do Sistema Exemplo, 15/05/2009.
6. Plano de Projeto do Sistema Exemplo.
41
11 CONCLUSÕES
Análise da Implantação do Projeto

<Descrever aqui o plano de implantação do seu sistema>
Análise Conclusiva sobre o Projeto

<Apresentar e discutir as dificuldades encontradas para a elaboração e resultados>
42
REFERÊNCIAS BIBLIOGRÁFICAS
Plano de Teste:
FILHO, Antônio M da S. Plano de Teste. Revista Engenharia de Software, São Paulo, Ano 2, n.
15, p. 42-45, 2009.
Exemplo Adaptado do modelo de testes disponível em:

www.cin.ufpe.br/~if682/projetos/.../Plano %20de%20Testes%20GSA.doc. Acesso em:
11.jun.15
43
APÊNDICES
<Todo material desenvolvido pelo próprio aluno, é uma informação complementar, com o
intuito de complementar argumentação e desenvolvimento do projeto>
APÊNDICE A – QUESTIONÁRIO DE ENTREVISTAS
<Especifique aqui o questionário utilizado para o levantamento de requisitos.>

44
APÊNDICE B – CÁLCULO DA ESTIMATIVA DE CUSTO
<Especifique aqui o cálculo realizado para a estimativa de custo e prazo do projeto.>

45
12 ANEXOS
<Documento não elaborado pelo autor, que serve de fundamentação, comprovação e
ilustrações. Exemplo: documento usado como suporte para estabelecer requisitos e os
modelos do projeto no sub-tópico do capítulo 6 que trata de Materiais de Referência>

Trabalho Lab

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Trabalho Lab

Transféré par

Droits d'auteur :

Formats disponibles

SIS CO

Professora: Maísa Cristina de Souza Dias

Ipatinga – MG, <Data>

Aprovamos o documento de Especificação de Requisitos do projeto.

RESPONSÁVEL CARGO DATA ASSINATURA

CONTRATANTE1 Gerente Empresa X 25/01/2015

CONTRATADO Responsável Empresa X 25/01/2015

Luiz Analista Banco de Dados 25/01/2015

DATA VERSÃO DESCRIÇÃO AUTOR

Benefícios esperados do produto.

2 GLOSSÁRIO – DEFINIÇÕES E SIGLAS

RF– Requisito Funcional

Nf- Requisitos não funcionais

Indpdt – índice do produto

Nmpdt – nome do produto

cdpdt – código do produto

Valorpdt- valor do produto

Indcontacess- índice de controle de acesso

Nmuser– número do usuário

Cdfornecedor – código do fornecedor

Estoquepdt – controle de estoque dos produtos

SIGE – Sistema Integrado de Gerência Empresarial;

3 DESCRIÇÃO DO MINI-MUNDO DO PROJETO

Sistema para um Comércio

Atualmente ele passa por um problema de controle de estoque. O dono do

O sistema deverá fazer um controle total e exato de quantos produtos o

Lista de funções do Projeto

Foi identificada a seguinte lista de funções para este produto:

RF [02] 1 Usuário Acesso da conta Simples Alta

RF [03] 2 Caixa Controla o rendimento Médio Ba

Restrições do Projeto (Limites do Produto)

 Não irá gerar automaticamente Notas Fiscal

Necessidades de Hardware e Software

Hardware= Processador Dual Core, 4GB de RAM, 30GB disponíveis em disco.

Análise de Risco do Projeto

6.1.1 Período mínimo

6.1.2 Período máximo

Cronograma físico (baseado em todos os itens citados anteriormente).

O custo operacional da empresa (água/luz/telefone/aluguel/limpeza/secretária) – estimar

Custo de Ferramentas (Softwares/Hardware) – Estima-se o custo dos itens do tópico 3.4 e

Custo de Infra-estrutura: (Registro de Domínios / Hospedagem de Sites / Servidores /

Utilizar a estimativa de custos do item 5.1 e determinar o preço do projeto:

Tipos de Material Referência

8.1.1 Requisitos Funcionais

Fluxo secundário: Informações do produtos inválidas ou insuficientes:

Requisito Funcional [RF 02] – Gestão Usuário

 O usuário informa o nome ou CPF do usuário que deseja consultar.

Requisito Funcional [RF 03] – Gestão de Caixa

semelhantes aos dados informados.

Requisito Funcional [RF 04] – Gestão de Rendimentos por períodos

 semelhantes aos dados informados.

Requisito Funcional [RF 05] – Gestão de Fornecedores

 O usuário informa o código do fornecedor que deseja excluir.

Fluxo secundário: Informações do fornecedor inválidas ou insuficientes:

Requisito Funcional [RF 05] – Gestão de Estoque

Fluxo secundário: Informações do estoque inválidas ou insuficientes:

8.1.1.1 Descrição dos Atores

8.1.2 Requisitos Não Funcionais

REQUISITOS NÃO FUNCIONAIS

Acrescentar o diagrama de caso de uso

8.1.3 Especificação dos casos de uso

Acrescentar o diagrama de classe do seu sistema