Vous êtes sur la page 1sur 45

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
Capítulos do Projeto que sofreram
28/06/2017 2.0 Luiz
alterações: 1.0
Capítulos do Projeto que sofreram
29/06/2017 3.0 Luiz
alterações: 4.0
Capítulos do Projeto que sofreram
29/06/2017 4.0 Luiz
alterações: 5.1, 5.2, 5.3
Capítulos do Projeto que sofreram
30/06/2017 5.0 Luiz
alterações: 8.1, 8.2, 8.2.1, 8.2.2
Capítulos do Projeto que sofreram
30/06/2017 6.0 Luiz
alterações: 6.1, 6.1.1, 6.1.2, 6.2
Capítulos do Projeto que sofreram
30/06/2017 7.0 Luiz
alterações: 8.6, 8.6.1, 8.6.2.
Capítulos do Projeto que sofreram
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.
Proposta de Desenvolvimento do Projeto de Engenharia de Software 7

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.
Proposta de Desenvolvimento do Projeto de Engenharia de Software 9

4 ENVOLVIDOS NO PROJETO

DISPONIBILIDADE DE
NOME FUNÇÃO NO GRUPO CONTATO
HORÁRIO
Luiz Henrique Desenvolvedor 31 987307023 8:00 até 17:00
Proposta de Desenvolvimento do Projeto de Engenharia de Software 10

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.
 É exibida uma mensagem de sucesso.

Para consulta:
 O usuário informa o produto, o código ou a data que o produto foi
cadastro que deseja consultar.
16

 .
 É exibida uma lista de produtos com informações semelhantes aos
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.
 É exibida uma lista de produtos com informações semelhantes aos
dados informados.
 O usuário seleciona o produtos que deseja excluir.
 É exibida uma mensagem de sucesso.

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.
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ção do usuário para acesso a conta à serem incluídos, alterados,
excluídos ou consultados.
Pós-condições: [Qual o estado posterior do sistema?]
Informação do usuário 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 usuário 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 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
 É exibida uma mensagem de sucesso.

Para consulta:
17

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


 É exibida uma lista de usuários com informações semelhantes aos
dados informados.
 O usuário seleciona o usuário que deseja obter informações.
 As informações são exibidas para o usuário.
Para exclusão:
 O usuário informa o nome ou CPF do usuário que deseja excluir.
 É exibida uma lista de usuários com informações semelhantes aos
dados informados.
 O usuário seleciona o usuário que deseja excluir
 É exibida uma mensagem de sucesso.
Fluxo secundário: Informações do usuários 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 03] – Gestão de Caixa


Objetivo: Informações de movimentações financeiras à serem incluídos, alterados,
excluídos ou consultados.
Requisitos: [Quais requisitos Funcionais?]
Permite aos usuários incluir, alterar, excluir ou consultar usuários.
Prioridade: [Qual a prioridade no desenvolvimento?]
Essencial
Pré-condições: Informação de movimentações financeiras á serem incluídos, alterados,
excluídos ou consultados.
Pós-condições: [Qual o estado posterior do sistema?]
Informação de movimentações financeiras á serem incluídos, alterados,
excluídos ou consultados.
Fluxo principal: Para inclusão:
 O usuário entra com os dados da movimentação financeira que deseja
incluir/alterar no sistema.
 As informações são armazenadas 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.
 As informações são armazenadas no sistema.
 É exibida uma mensagem de sucesso.

Para consulta:
 O usuário informa o código ou data da movimentação financeira que
deseja consultar.
 É exibida uma lista de movimentações financeiras com informações
18

semelhantes aos dados informados.


 O usuário seleciona a movimentação que deseja obter informações.
 As informações são exibidas para o usuário.

Para exclusão:
 O usuário informa o código ou data da movimentação financeira que
deseja excluir.
 É exibida uma lista de movimentações financeiras com informações
semelhantes aos dados informados.
 O usuário seleciona a movimentação que deseja excluir
 É exibida uma mensagem de sucesso.
Fluxo secundário: Informações da movimentação financeira 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 “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,
excluídos ou consultados.
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ção dos rendimentos por períodos á serem incluídos, alterados,
excluídos ou consultados.
Pós-condições: [Qual o estado posterior do sistema?]
Informação dos rendimentos por períodos dos á serem incluídos, alterados,
excluídos ou consultados.
Fluxo principal: Para inclusão:
 O usuário entra com os dados dos rendimentos por períodos que
deseja incluir/alterar no sistema.
 As informações são armazenadas 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
semelhantes aos dados informados.
 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
 As informações são armazenadas no sistema.
 É exibida uma mensagem de sucesso.

Para consulta:
 O usuário informa o código ou data dos rendimentos por períodos que
deseja consultar.
 É exibida uma lista dos rendimentos por períodos com informações
19

 semelhantes aos dados informados.


 O usuário seleciona o dos rendimentos que deseja obter informações.
 As informações são exibidas para o usuário.

Para exclusão:
 O usuário informa o código ou data dos rendimentos por períodos que
deseja excluir.
 É exibida uma lista dos rendimentos por períodos com informações
semelhantes aos dados informados.
 O usuário seleciona os rendimentos que deseja excluir
 É exibida uma mensagem de sucesso.
Fluxo secundário: Informações dos rendimentos por períodos 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 “movimentação existente”, “dados insuficientes” ou “informações
incorretas”.

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


Objetivo: Informações do fornecedor à serem incluídos, alterados, excluídos ou
consultados.
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çã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.
Fluxo principal: Para inclusão:
 O usuário entra com os dados fornecedor que deseja incluir/alterar no
sistema.
 As informações são armazenadas 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
 As informações são armazenadas no sistema.
 É exibida uma mensagem de sucesso.

Para consulta:
 O usuário informa o código do fornecedor que deseja consultar.
 É exibida uma lista dos fornecedores com informações semelhantes aos
dados informados.
 O usuário seleciona o fornecedor que deseja obter informações.
 As informações são exibidas para o usuário.

Para exclusão:
20

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


 É exibida uma lista dos fornecedores com informações semelhantes aos
dados informados.
 O usuário seleciona o fornecedor que deseja excluir
 É exibida uma mensagem de sucesso.

Fluxo secundário: Informações do fornecedor 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 “movimentação existente”, “dados insuficientes” ou “informações
incorretas”.

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


Objetivo: Informações do Estoque à serem incluídos, alterados, excluídos ou consultados.
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çã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.
Fluxo principal: Para inclusão:
 O usuário entra com o código do estoque que deseja incluir/alterar no
sistema.
 As informações são armazenadas 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
 As informações são armazenadas no sistema.
 É exibida uma mensagem de sucesso.

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.
 As informações são exibidas para o usuário.

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
 É exibida uma mensagem de sucesso.
21

Fluxo secundário: Informações do estoque 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 “movimentação existente”, “dados insuficientes” ou “informações
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
Nome do Índice Atributos Único (Sim, Não)
Índices: IND_USER_NMUSER NMUSER SIM
Descrição: Tabela que contém todos os usuários.
Atributos:
26

Nome do Atributo Tipo Tamanho Descrição Máscara Regra de Valores Integridade


Validação Válidos Referencial
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
Nome do Índice Atributos Único (Sim, Não)
Índices: IND_CAIXA_CAIXACONTROL CAIXACONTROL SIM
Descrição: Tabela que contém o controle do caixa.
Atributos:
Nome do Atributo Tipo Tamanho Descrição Máscara Regra de Valores Integridade
Validação Válidos Referencial
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
Nome do Índice Atributos Único (Sim, Não)
Índices: IND_FORN_FORNNM FORNNM SIM
Descrição: Tabela que contém os Fornecedores
Atributos:
Nome do Atributo Tipo Tamanho Descrição Máscara Regra de Valores Integridade
Validação Válidos Referencial
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
Nome do Índice Atributos Único (Sim, Não)
Índices: IND_ESTOQUE_ESTOQUEPDT ESTOQUEPDT SIM
Descrição: Tabela que contém os Fornecedores
Atributos:
Nome do Atributo Tipo Tamanho Descrição Máscara Regra de Valores Integridade
Validação Válidos Referencial
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.


Verificar a resposta do sistema com 10 usuários.
Verificar a resposta do sistema com 20 usuários.
Verificar a resposta do sistema com 30 usuários.
Verificar a resposta do sistema com 40 usuários.
32

Verificar a resposta do sistema com 50 usuários.

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>