ModelodeDocumentaoPI_20200326135652

Prévia do material em texto

Modelo de documentação de Sistemas
<<TÍTULO DO PROJETO>>
<<MÊS DE INICIO DO PROJETO>>
Histórico de Versões do sistema
	Data Alteração
	Versão
	Descrição
	Autor
	
	
	
	
	
	
	
	
	
	
	
	
Sumário
Histórico de Versões do sistema	2
1.	Descrição do Sistema	4
1.1.	Objetivos do Sistema	4
1.2.	Principais Envolvidos e suas responsabilidades	4
1.3.	Restrições e Regras de negócios	4
2.	Requisitos do Sistema	5
2.1.	Requisitos Funcionais - RF	5
2.2.	Requisitos não funcionais	5
2.3.	Não Requisitos – requisitos fora do escopo	5
2.4.	Recursos e Cronograma de Projeto e Desenvolvimento do Sistema	5
3.	Análise e Projeto do Sistema	6
3.1.	Diagrama de Caso de Uso	6
3.2.	Documentação dos Casos de Uso e Protótipo de Telas	6
Descrição do Caso de uso - <<Nome do Caso de Uso>>	6
Protótipo de tela referente ao caso de uso <<Nome do caso de uso>>	7
Definição de tipos e restrições dos campos da tela<< XXX>>– Caso de Uso<<Nome do Caso de Uso>>	7
3.3.	Diagrama de Classes Conceitual e de Implementação do Sistema	7
3.4.	Modelo Lógico de Banco de Dados - DER	8
3.5.	Modelo Físico de Banco de Dados – Scripts de criação do BD	8
3.6.	Diagramas de Sequência	8
4.	Planejamento e Execução de Testes de Sistema	9
5.	Manual de Implantação	10
6.	Manual do Sistema	10
ANEXO 1	11
<<Título do anexo>>	11
1. Descrição do Sistema
<<[footnoteRef:2]Descrever de forma geral o que é o sistema, qual sua finalidade, suas funções e a quem se destina (cliente e usuário). >> [2: Todo o texto entre <<>> deve ser usado como direcionamento para a documentação do sistema e deve ser retirado da versão final da documentação.] 
1.1. Objetivos do Sistema
<< Descrever os objetivos gerais e específicos almejados pelo sistema como um todo. Este item visa o entendimento global do projeto. >>
1.2. Principais Envolvidos e suas responsabilidades 
<<Apontar na Tabela 1 as pessoas envolvidas direta e indiretamente no desenvolvimento do sistema e suas responsabilidades. Veja exemplos na tabela, a qual lista os principais envolvidos em um projeto.>>
Tabela 1 Lista de envolvidos no desenvolvimento do projeto e suas respectivas responsabilidades.
	Envolvidos
	Responsabilidades
	Pessoa Envolvida
	Usuário final
	- Acessar sistema XXX via web, para solicitar o boletim de ocorrência referente a um acidente de trânsito sem vítima;
- Fornecer as informações relacionadas ao acidente;
- Imprimir o BO através da web;
- Repassar o n° do BO para os interessados, por exemplo, a seguradora do veículo.
	Condutores de veículos que tenham se envolvido em algum acidente de trânsito sem vítima no município de Uberlândia. Usuário podem possuir pouco ou nenhum conhecimento de tecnologias.
	Cliente
	..
	...
	...
	...
	...
1.3. Restrições e Regras de negócios 
<<Listar na Tabela 2 todas as regras de negócios e restrições relacionadas ao negócio que devem ser atendidas pelo sistema.>>
Tabela 2 Regras de negócios e restrições relacionadas ao negócio no qual o sistema se insere
	RN1
	
	RN2
	...
	....
	
	
	
2. Requisitos do Sistema
<<Nesta seção devem ser descritas todas as funcionalidades e restrições que o cliente espera que contenha no sistema, assim como as funcionalidades que não estarão no escopo do mesmo. As funcionalidades devem ser descritas na seção 2.1, as restrições na seção 2.2 e as funcionalidades fora do escopo do sistema na seção . 
2.1. Requisitos Funcionais - RF
<<Na Tabela 3 liste e descreva brevemente todas as funcionalidades que devem ser implementadas no sistema. Vide exemplo na tabela.>>
Tabela 3 Lista dos requisitos funcionais (funcionalidades) do sistema.
	RF001
	Cadastrar Ocorrência
	Cadastra as ocorrências de acidentes de transito quem que não haja nenhum tipo de vítima, que não seja relacionada a roubo de veículos e 
	RF002
	...
	...
	...
	
	
2.2. Requisitos não funcionais
<<Os requisitos não funcionais devem representar restrições do sistema a nível de: serviços, tecnologias, desempenho, qualidade, usabilidade, robustez, segurança, configuração de ambientes, etc. Abaixo segue uma tabela que apresenta os tipos de requisitos não funcionais, os quais devem ser usados para direcionar o levantamento desses requisitos.>>
2.3. Não Requisitos – requisitos fora do escopo
<<Listar as funcionalidades que não serão implementados no sistema.>>
2.4. Recursos e Cronograma de Projeto e Desenvolvimento do Sistema
<< Estimar os esforços necessários em termos de recursos alocados e tempo para a entrega do Projeto (e futuramente do produto de software), contemplando esta documentação preenchida. >>
3. Análise e Projeto do Sistema
3.1. Diagrama de Caso de Uso
<<Colar o modelo de caso de uso, o qual pode ser modelado em qualquer ferramenta CASE de utilização livre.>>
3.2. Documentação dos Casos de Uso e Protótipo de Telas
<<Cada um dos casos de usos definidos no diagrama da seção anterior devem ser descritos seguindo o modelo abaixo. 
As regras de negócio, descritas na seção Erro: Origem da referência não encontrada, devem ser referenciadas nos casos de uso nos quais estas devem ser verificadas. Cada caso de uso descrito deve ser acompanhado pelo seu protótipo de tela, assim como a definição dos tipos e validação dos campos da tela, quando for necessário. >>
Descrição do Caso de uso - <<Nome do Caso de Uso>>
	Breve descrição:
	<<utilizar a mesma da seção 2.1>>
	Ator do caso de uso:
	<<ator que interage com o caso de uso>>
	Pré-condições:
	<<Listagem das condições que se devem verificar quando o ator inicia este caso de uso. Quando não existir nenhuma condição, coloque o texto “Não se aplica”>>
	Pós-condições:
	<<Descrição do estado do sistema após a execução deste caso de uso. Quando não existir nenhuma condição, coloque o texto “Não se aplica”>>>>
	Regras de negócio envolvidas[footnoteRef:3]: [3: As regras de negócios devem ser citadas aqui, porém devem ser referenciadas nos fluxos, no momento em que devem ser validadas.] 
	<<Citar as regras e restrições de negócio, identificadas na seção Erro: Origem da referência não encontrada, que este caso de uso deve atender. >>
	Fluxo Principal
	<<Descrever as ações do ator e do sistema para a realização deste caso de uso. No fluxo principal descreve apenas as ações relacionadas ao cenário perfeito de utilização do caso de uso. O cenário perfeito corresponde à parte positiva de um fluxo de decisão (se...senão...). 
Os fluxos alternativos devem ser referenciados aqui, e descritos nas próximas linhas da tabela. >>
OBS: seja objetivo na descrição do caso de uso. Lembre-se de usa aro protótipo de tela como apoio da descrição.
	Fluxo Alternativo 1:
	<<Descreve o cenário de verificação (se...senão) que desvia o caso de uso de seu cenário principal de utilização.>>
	Fluxo Alternativo N[footnoteRef:4]: [4: Deverão ser descritos tantos quantos fluxos alternativos e de exceção existirem no caso de uso] 
	
Protótipo de tela referente ao caso de uso <<Nome do caso de uso>>
<<Colar aqui o protótipo de tela. A ferramenta usada para o protótipo deve ser definida pelos professores e o aluno envolvido projeto. Os arquivos referentes aos protótipos também deverão ser anexados à documentação.>>
Definição de tipos e restrições dos campos da tela<< XXX>>– Caso de Uso<<Nome do Caso de Uso>>
	Campo
	Tipo do campo
	Preenchimento Obrigatório
	Observações
	Nome
	String
	SIM
	Nome Completo
	Endereço
	String
	SIM
	Puxar endereço da tabela de Ceps dos correios
	...
	...
	
	
3.3. Diagrama de Classes Conceitual e de Implementação do Sistema
<< Num primeiro momento deve ser apresentado o modelo conceitual do diagrama de classes. Posteriormente, esse diagrama deve ser validado e complementado de modo a obter o diagrama de implementação . Os diagramas de classes podem ser modelados em qualquer ferramenta CASE de utilização livre.
Definição sobre cada modelo:
Modelo conceitual: Representa os conceitos do domínio do sistema, cuja modelagem é destinada ao cliente e aos gerentes/coordenadores do projeto, os quais nem sempre tem conhecimento sobre desenvolvimento de sistemas. Neste modelo devem ser identificadas asprincipais classes, seus atributos e os relacionamentos entre essas classes.
Modelo de Implementação: representa a estrutura do sistema a nível de implementação, cuja modelagem se destina a equipe de desenvolvimento. Neste modelo desse ser identificadas todas as classes, atributos, métodos, relacionamentos e dependências entre as classes do sistema. >>
3.4. Modelo Lógico de Banco de Dados - DER
<<Cole aqui o DER referente ao modelo lógico do sistema. O dados do DER devem ser normalizados.>>
3.5. Modelo Físico de Banco de Dados – Scripts de criação do BD
<<Disponibilizar os scripts utilizados para a criação das tabelas no banco de dados. Os scripts devem ser apresentados seguindo a ordem em que devem ser executados. >>
3.6. Diagramas de Sequência
 Modelo de documentação de Sistemas
 Modelo de documentação de Sistemas
<<Cole aqui os diagramas de sequência de cada caso de uso proposto neste documento do sistema. Tais diagramas devem respeitar a ordem de execução descrita no caso de uso e os objetos devem ter sido contemplados no diagrama de classes. >>
Página 8 / 11
4. Planejamento e Execução de Testes de Sistema
<<A Tabela 4 deve ser usada para o planejamento e a execução dos testes de sistema. É recomendável que o teste não seja executado pela mesma pessoa que desenvolveu o sistema.>>
Tabela 4 Tabela de testes de sistema
 Modelo de documentação de Sistemas
Página 9 / 11
5. Manual de Implantação
<<O manual deve conter a descrição passo-a-passo de como deve ser realizada a instalação do sistema. Se possível, use figuras para demonstrar o processo.>>
6. Manual do Sistema
<<Manual a ser disponibilizado no sistema, para auxilio do usuário quanto à utilização do sistema.>>
ANEXO 1
<<Título do anexo>>
Atualizada em --/--/----
Página 11 / 11
Plan1
	Nome do Sistema	ID do Teste	Funcionalidade Testada	Cenário de Teste	Resultado Esperado	Resultado Obtido	Status	Observação
	Sentran Online	<<CT001>>	<<UC 001- Cadastrar Ocorrência>>	<<Cadastrar uma ocorrência para acidentes com vitímas>>	<<O sistema de recusar o cadastro e redirecionar o usuário para a página inicial do sistema>>	<<descrever resultado obtido do teste>>	[Aprovado/Reprovado]	Preencher em caso de reprovação da funcionalidade
Plan2
Plan3
Nome do Sistema ID do Teste Funcionalidade Testada Cenário de Teste Resultado Esperado Resultado Obtido Status Observação
Sentran Online <<CT001>>
<<UC 001- Cadastrar 
Ocorrência>>
<<Cadastrar uma ocorrência para 
acidentes com vitímas>>
<<O sistema de recusar o cadastro e 
redirecionar o usuário para a página 
inicial do sistema>>
<<descrever resultado obtido 
do teste>>
[Aprovado/
Reprovado]
Preencher em caso de 
reprovação da funcionalidade