<Nome do Produto>

Relatório de Projeto

Autores
Matrícula Nome
Matrícula Nome
Matrícula Nome
Matrícula Nome
Matrícula Nome

Alegrete, RS
<Data>
 Relatório de Projeto

Sumário

Sumário
1INTRODUÇÃO.................................................................................................................................... 3

1.1PROPÓSITO DESTE DOCUMENTO....................................................................................................................... 3

1.2ESCOPO DO PRODUTO.................................................................................................................................. 3
1.2.1Nome do produto e de seus componentes principais...................................................................3
1.2.2Missão do produto........................................................................................................................3
1.2.3Limites do produto........................................................................................................................3
1.2.4Benefícios do produto...................................................................................................................4
1.3DEFINIÇÕES, ACRÔNIMOS E ABREVIAÇÕES............................................................................................................. 4
1.4REFERÊNCIAS............................................................................................................................................ 4

2VISÃO GERAL DO SISTEMA................................................................................................................. 5

3REQUISITOS....................................................................................................................................... 6

3.1REQUISITOS FUNCIONAIS E REQUISITOS NÃO FUNCIONAIS ASSOCIADOS............................................................................. 6

3.2REQUISITOS SUPLEMENTARES.......................................................................................................................... 7

4REQUISITOS ORGANIZADOS............................................................................................................... 8

4.1DESCRIÇÃO DOS CASOS DE USO...................................................................................................................... 8

4.2DIAGRAMA DE CASOS DE USO........................................................................................................................ 9

5PROJETO EXTERNO.......................................................................................................................... 10

5.1ASPECTOS GERAIS DE PROCESSO..................................................................................................................... 10

5.1.1Caracterização dos usuários.......................................................................................................10
5.1.2Participação dos usuários no desenho das interfaces................................................................10
5.2ASPECTOS GERAIS DO PRODUTO..................................................................................................................... 10
5.2.1Funções do Produto....................................................................................................................10
5.2.2Tratamento dos erros do usuário...............................................................................................11
5.2.3Tratamento da ajuda ao usuário................................................................................................11
5.3COMPONENTES DAS INTERFACES DE USUÁRIO...................................................................................................... 11
5.3.1Interface <Nome da interface>...................................................................................................11

6PROJETO INTERNO .......................................................................................................................... 13

6.1MODELO CONCEITUAL............................................................................................................................... 13
6.1.1Operações...................................................................................................................................13
6.2CLASSES SECUNDÁRIAS .............................................................................................................................. 13
6.2.1Classe <Nome da classe> ...........................................................................................................14
6.3DIAGRAMA DE CLASSE RESUMIDO................................................................................................................... 14

7 ANEXOS.......................................................................................................................................... 15

7.1 DOCUMENTAÇÃO DO CÓDIGO....................................................................................................................... 15

2 / 15
 Relatório de Projeto

1 Introdução
1.1 Propósito deste documento

<Inserir aqui a proposta inicial do documento. Funciona semelhante a

uma introdução. Falar do que trata o documento, que ele organiza e relaciona
toda a documentação e levantamento dos requisitos do sistema que se está
sendo elaborado. Pode-se incluir também neste item uma descrição bem
simples do sistema.>.
<Introdução>
<Público Alvo: Descrever os beneficiados diretamente com o programa
(quem vai usar ou quem vai se beneficiar com a utilização do mesmo), Ex.:
Supermercado: quem usa o sistema é o atendente do caixa e não o cliente.>.
Público-alvo:<público-alvo>

1.2 Escopo do produto

1.2.1 Nome do produto e de seus componentes principais

<incluir o nome escolhido para o produto>

Nome do Produto: <nome do produto>
<Componentes de Software que formam o produto, se for o caso>.
Componentes Principais: <componentes principais>

1.2.2 Missão do produto

<Descrever aqui o que o sistema se propõe a fazer, de forma resumida,

incluindo algumas informações básicas para melhor entendimento da solução
que está sendo proposta>.
<Missão do Produto>

1.2.3 Limites do produto

<Descrever as limitações do produto, o que ele proporciona em relação

às necessidades do cliente, de forma que quem leia este subitem consiga
entender o que o sistema irá efetivamente fazer e o que o sistema NÃO irá
fazer>.
<Limites do produto>

3 / 15
 Relatório de Projeto

1.2.4 Benefícios do produto

<Incluir aqui quais são os benefícios/vantagens em se utilizar este produto, atribuindo

um valor que pode ser: alto, médio ou baixo, de acordo com o grau de importância
para o cliente. >

Número de Benefício Valor para o cliente

ordem
01
02
03
04

1.3 Definições, acrônimos e abreviações.

<Termos/Siglas que foram citadas no decorrer do documento devem ser der

devidamente definidas, de forma a esclarecer os seus significados >.

Número de Termo Definição

ordem
01
02
03
04

1.4 Referências

<Referências que foram utilizadas na elaboração deste documento>

Número de Tipo do Referência bibliográfica

ordem material
01 Artefato Visão Geral do Sistema
02 Livro WAZLAWICK, R. Análise e Projetos de Sistemas de Informação
Orientados a Objetos. 1ª Ed. Rio de Janeiro: Campus, 2004.
03
04
05
06

4 / 15
 Relatório de Projeto

2 Visão Geral do Sistema

<Resumo do sistema, em forma de texto, descrever tudo o que o
sistema abrange, utilizando uma linguagem menos técnica e mais acessível ao
“cliente” que está comprando o “produto”. Pode-se citar algumas informações
do sistema, como ocorre o fluxo das informações, etc.>.

<Nome do produto>

<Descrição do Produto>

5 / 15
 Relatório de Projeto

3 Requisitos
3.1 Requisitos funcionais e requisitos não funcionais associados

< Os requisitos podem ser classificados em duas grandes categorias: -

os requisitos funcionais correspondem à listagem de tudo que o sistema deve
fazer; - os requisitos não funcionais são restrições colocadas sobre como o
sistema deve realizar seus requisitos funcionais. Os requisitos funcionais
podem ser classificados em dois grupos:
a) requisitos funcionais evidentes, que são efetuados com
conhecimento do usuário. Esses requisitos usualmente corresponderão a
eventos do sistema e respostas do sistema, ou seja, qualquer troca de
informação que ocorram pela interface do sistema com o meio exterior;
b) requisitos funcionais ocultos, que são efetuados pelo sistema sem o
conhecimento explícito do usuário.
Os requisitos não funcionais podem ser classificados em obrigatórios e
desejados, isto é, aqueles que devem ser obtidos de qualquer maneira e
aqueles que podem ser obtidos de qualquer maneira e aqueles que podem ser
obtidos caso isso não cause maiores transtornos no processo de
desenvolvimento. Além disso, os requisitos não funcionais podem ser
classificados por atributo (categoria): se são requisitos de interface, de
implementação, de eficiência, de tolerância a falhas, etc.
Ainda em relação aos requisitos não funcionais, existem aqueles
diretamente associados a uma função e outros que são gerais para o sistema
(suplementares). Uma última classificação útil para os requisitos não funcionais
indicará se são permanentes ou transitórios. O requisito permanente nunca
mudará com o tempo (por exemplo, a interface feita por meio de janelas), já o
requisito transitório poderá sofrer alterações no futuro (por exemplo, a forma de
calcular impostos).>.

Oculto ( ) <Se o a ação do requisito é visível ou não

FX - < Título do Requisito>
ao usuário do Sistema>
Descrição: <Descrição do que o requisito trata; o que ele faz no contexto do sistema>.
Requisitos não funcionais
Nome Restrição Categoria DesejávelPermanente
<Classificação
< descrever a restrição
NF X. 1 <Nome do em que o
colocada sobre como o
Requisito não funcional requisito não ( ) ( )
sistema deve realizar o
associado> funcional se
requisito funcional>
enquadra>
<Classificação
< descrever a restrição
NF X. 2 <Nome do em que o
colocada sobre como o
Requisito não funcional requisito não ( ) ( )
sistema deve realizar o
associado> funcional se
requisito funcional>
enquadra>

6 / 15
 Relatório de Projeto

3.2 Requisitos suplementares

<Importantes ao software, porém, não se enquadram, nem como

requisito funcional, ou como requisito não funcional. Trata-se de tipos de
restrições tecnológicas ou lógicas que se aplicam a todo o sistema, e não
apenas a alguma parte dele.>.
Nome Restrição Categoria DesejávelPermanente

S1 <Nome do <Restrição aplicada pelo <Categoria do

( ) ( )
Requisito> requisito> Requisito>

S2 ( ) ( )

S3 ( ) ( )

7 / 15
 Relatório de Projeto

4 Requisitos Organizados
<Uma vez que os requisitos tenham sido levantados, cabe organizá-los
em grupos correlacionados, de forma a abordá-los nos ciclos iterativos. Os
requisitos podem ser agrupados do seguinte modo: casos de uso, conceitos e
consultas. Na fase de concepção é necessário identificar os grandes processos
da empresa. As operações elementares (consultas e alterações de dados)
possivelmente estarão inseridas dentro desses processos. Os casos de uso, ou
grandes processos de negócio da empresa, devem cobrir as principais
atividades da empresa ligadas ao sistema que será implementado. O objetivo
de listar os casos de uso é levantar informações sobre como o sistema interage
com possíveis usuários e quais consultas e transformações da informação são
necessárias além daquelas já identificadas na fase de levantamento de
requisitos.
Para descobrir os casos de uso, devem-se identificar os atores
envolvidos com o sistema. Para tanto, o analista deve responder algumas
perguntas, como as seguintes:
a) quem usa o sistema?
b) quem mantém ou configura o sistema?
c) quais outros sistemas de informação utilizam ou são utilizados pelo
sistema?
d) quem busca informações no sistema?
e) quem provê informações para o sistema? >

4.1 Descrição dos Casos de Uso

<É uma forma de sistematizar e organizar os requisitos. Tem como

objetivo levantar as informações sobre como o sistema interage com possíveis
usuários e quais consultas e transformações da informação são necessárias
para que processos completos de interação sejam executados. Cada caso de
uso (Nome) será associado a um conjunto de requisitos funcionais do sistema
(Ref. Cruzada). Para descobrir os casos de uso, deve-se identificar os Atores
envolvidos com o sistema e, a partir dos atores, identifica-se os principais
processos de negócio de que eles participam (Descrição).>

Nome Atores Descrição Ref. Cruzadas

< Requisitos
<Nome do caso de <atores
<Descrição dos Casos de Uso> relacionados ao
uso> envolvidos>
caso de uso>

8 / 15
 Relatório de Projeto

4.2 Diagrama de Casos de Uso

<Inserir aqui o Diagrama de Casos de Uso. Neste diagrama, as elipses

representam casos de uso, os bonecos representam atores (usuários) e o
retângulo representa a fronteira do sistema ou subsistemas. Deve-se evitar que
o diagrama tenha um conjunto muito grande de elipses, pois, nesse caso, fica
inviável compreendê-lo. Assim, deve-se caracterizar muito bem o que são
casos de uso para evitar que esse diagrama tenha, por um lado, processos
demais, excessivamente detalhados, ou, por outro lado, processos de menos,
faltando funcionalidades importantes do sistema.
Via de regra, a solução é representar no diagrama apenas os
processos que podem ser executados isoladamente. Processos parciais que
são executados necessariamente dentro de outros processos não devem ser
representados nesse diagrama>.

<Inserir o diagrama de casos de uso>

9 / 15
 Relatório de Projeto

5 Projeto externo

5.1 Aspectos gerais de processo

5.1.1 Caracterização dos usuários

5.1.1.1 Atores

<Inserir aqui a descrição dos atores e suas ações no sistema.>.

<Nome do ator>: <Descrição das ações>.

5.1.1.2 Detalhes da caracterização

<Descrever aqui os atores, suas permissões de acesso no sistema, a sua frequência de
uso, o nível de instrução, proficiências.>.

Número Atores Permissão Frequência Proficiência Proficiência em

de de acesso de uso na aplicação informática
ordem
1. <Nome <Total, <Frequente, <Básico, <Básico, médio,
do parcial, esporádica, médio, avançado>.
usuário somente etc.> avançado>.
> consulta>.

5.1.2 Participação dos usuários no desenho das interfaces

<Descrever como foi e de que forma os usuários participaram da

criação e do desenvolvimento das interfaces. OBS: as interfaces podem ser
gráficas ou de linha de comando>.

<Descrição da participação do usuário>.

5.2 Aspectos gerais do produto

5.2.1 Funções do Produto

Identificador Caso de Uso Descrição

1. <Nome do caso de uso> <Descrição do Caso de Uso>
2.
3.
10 / 15
 Relatório de Projeto

4.
5.

5.2.2 Tratamento dos erros do usuário

<Descrever aqui como será feito o tratamento dos erros.>.

<Tratamento de erros>.

5.2.3 Tratamento da ajuda ao usuário

<Descrever aqui como será disponibilizado a ajuda aos usuários.>.

<Ajuda aos usuários>.

5.3 Componentes das interfaces de usuário

5.3.1 Interface <Nome da interface>

<Inserir imagens, quando for o caso, e descrever como será a

interação do usuário com a interface. Observação: o uso do termo interface
nesta seção não significa que deva existir interface gráfica. Se for o caso, as
mensagens trocadas com o usuário, por linha de comando, também devem ser
descritas nesta seção. >

5.3.1.1 Campos
Nº Nome Valores válidos Formato Restrições

1. <nome do <valores <Formato válido> <Valores não aceitos no

campo> aceitáveis no campo>
campo>

2.

3.

11 / 15
 Relatório de Projeto

5.3.1.2 Comandos

Lista de comandos
Número Nome Estilo Ação

1. <nome do comando> <tipo de Comando> <Ação feita pelo comando>

2.

3.
< O estilo do comando numa das interfaces pode ser Botão, Menu,
Item de Menu, etc.; em se tratando de linha de comando, pode ser: mensagem
geral, mensagem para entrada de valor, mensagem para saída, mensagem de
erro, etc. >
< A ação do comando em uma interface seria a descrição do que o
comando faz.>.

< ATENÇÃO: repetir os subtítulos 5.3.1 e seus subtítulos: 5.3.1.1 e

5.3.1.2 tantas vezes quantas forem necessárias para representar todas as
interfaces com o usuário do sistema. >

12 / 15
 Relatório de Projeto

6 Projeto interno
6.1 Modelo Conceitual

6.1.1 Operações

< Para cada classe identificada no modelo conceitual descrever as operações

que são de cada uma delas, apenas indicando o nome, parâmetros e retorno,
quando houver. >

Identificador Pertence a Nome da Parâmetros Retorno

Classe operação

1.

2.

3.

4.

5.

6.2 Classes Secundárias

< Aqui serão indicadas outras classes que não são parte dos conceitos
indicados no Modelo Conceitual. Estas classes representam interfaces, formas
de armazenamento, segurança de acesso, etc. >.
Neste ponto (esboço do relatório final de projeto), além de representar
os principais conceitos envolvidos no sistema, também será considerada a
solução física que virá a ser adotada, implicando na representação dos
elementos da solução, isto é, todos os conceitos que se referem a
computadores como: interfaces, formas de armazenamento, segurança de
acesso, comunicação, etc. >.

<Nome da classe secundária>: <Funcionalidade>.

6.2.1 Classe <Nome da classe>

13 / 15
 Relatório de Projeto

< Incluir aqui uma breve Descrição da classe, seus atributos e

operações. >
< ATENÇÃO: repetir os subtítulos 6.2.1 tantas vezes quantas forem
necessárias para representar todas as classes que não pertencem ao modelo
conceitual do sistema. >

6.3 Diagrama de classe resumido

< Incluir um diagrama de classe sem detalhamento, apenas com o

nome das classes e as associações entre elas. Neste diagrama as classes que
não fazem parte do modelo conceitual também devem ser mostradas. Quando
necessário, indicar a qual pacote um conjunto de classes faz parte. >

14 / 15
 Relatório de Projeto

7 Anexos

7.1 Documentação do código

<Inserir aqui o javadoc das classes implementadas.>.

15 / 15