Estudo de Viabilidade - Rômulo César – Consultoriaromulocesar.com.br/.../uploads/2015/08/Template_ES_UII1.docx · Web viewO supervisor realiza o que chamamos de triagem, que consiste

Especificação de Requisitos

Disciplina: Engenharia de Software IIUniversidade de PernambucoSistemas de InformaçãoProfessor: Rômulo César Dias de AndradeAlunos:

Sumário1. Introdução..............................................................................................................................6

1.1 Motivação........................................................................................................................6

1.2 O Problema Identificado..................................................................................................6

1.3 Sobre a Organização.........................................................................................................6

1.3.1 Propostas para cartão de crédito..................................................................................7

1.4 Convenções para Identificação dos Requisitos....................................................................8

1.5 Convenções para Identificação dos Casos de Uso................................................................8

1.5.1 Estrutura dos casos de uso............................................................................................8

1.5.2 Prioridades dos casos de uso........................................................................................8

1.5.3 Descrição dos Atores.....................................................................................................8

2. Requisitos Organizacionais.....................................................................................................8

3. Requisitos Funcionais.............................................................................................................9

3.1 [RF01] Efetuar logon........................................................................................................9

3.2 [RF02] Efetuar logoff........................................................................................................9

3.3 [RF03] Inserir Projeto.......................................................................................................9

3.4 [RF04] Remover Projeto.................................................................................................10

3.5 [RF05] Atualizar Projeto.................................................................................................10

3.6 [RF06] Listar Projetos.....................................................................................................10

4. Requisitos Não Funcionais...............................................................................................11

4.1 Requisitos de Processo...................................................................................................11

4.1.2 [NFR02] - Desenvolvimento em Java...........................................................................11

4.1.3 [NFR03] – Utilizar Banco de Dados MySql...................................................................11

4.2 Requisitos de Externos...................................................................................................11

4.2.1 [NRF04] - Tempo de Desenvolvimento........................................................................11

4.2.2 [RNF05] - Custo de Desenvolvimento..........................................................................12

4.3 Requisitos de Produto....................................................................................................12

4.3.1 [RNF06] - Permissão....................................................................................................12

4.3.2 [RNF07] - Backup.........................................................................................................12

4.3.3 [RNF08] - Mensagens de Retorno...............................................................................12

4.3.4 [RNF09] - Menus bem Estruturados............................................................................12

5. Conclusão.............................................................................................................................13

Referências..............................................................................................................................13

Relatório da Equipe..................................................................................................................13

Anexo A – Status das propostas e Controle Atual...................................................................14

Anexo B – Descrição dos Casos de Uso...................................................................................15

[UC01] Efetuar logon............................................................................................................15

[UC02] Efetuar logoff...........................................................................................................15

[UC03] Inserir Projeto..........................................................................................................16

[UC04] Remover Projeto......................................................................................................16

[UC05] Atualizar Projeto......................................................................................................17

[UC06] Listar Projetos..........................................................................................................18

Anexo C – Glossário.................................................................................................................19

Índice de Figuras

Figura 1 Modelagem de Dependência Estratégica....................................20

Figura 2 Modelagem de Estratégico da Razão. 20

Figura 3 Modelo estratégico da razão com ator correspondente bancário expandido. 21

Figura 4 Modelo estratégico da razão com ator banco expandido. 22

Figura 5 Modelo estratégico da razão com ator Cliente expandido. 22

Índice de Tabelas

Tabela 1 Porcentagem de esforço dos membros da equipe........................29

1. Introdução O objetivo desde documento é descrever o problema que foi identificado e

especificar os requisitos para a solução encontrada durante a fase de estudo de viabilidade realizada previamente. Essa solução tem como centro um sistema de informação que deve ser construído a partir das informações capturadas pela utilização de algumas técnicas descritas adiante.

O nosso objeto de estudo é um correspondente bancário, onde tem como finalidade maior organizar as informações e diminuir o retrabalho. Tendo em vista o grande número de tarefas a ser realizadas pelos funcionários, o projeto vem com o objetivo de ajudar a mesma no gerenciamento das informações.

1.1 MotivaçãoGrande parte das empresas sejam elas de pequeno, médio ou grande porte,

ainda se utilizam de planilhas de calculo para o seu controle, organização e planejamento de negócio. Correspondentes bancários recebem semanalmente de bancos e instituições financeiras para as quais prestam serviço, planilhas contendo informações do comissionamento a receber, em pagamento aos serviços de encaminhamento de propostas para abertura de contas e cartões de crédito. Controlar todas as propostas contidas nessas planilhas é um grande desafio, e esse projeto propõe desenvolver uma ferramenta para auxiliar o gerenciamento dessas pelos seus encarregados.

1.2 O Problema Identificado Uma mesma proposta de cartão pode estar presente em mais de uma planilha

de comissionamento disponibilizada a cada semana, o que dificulta o acompanhamento do histórico de cada proposta, o seu status atual, e a auditoria do que foi realizado por cada vendedor de campo, pois a comissão do vendedor só deve ser paga se a proposta feita por ele for aprovada pelo banco.

Diante dessas informações, constatamos que o tempo que se gasta para extrair alguma informação sobre uma proposta ou um conjunto de propostas é muito grande, pois é necessário consultar manualmente todos os comissionamentos recebidos até então, bem como os romaneios enviados ao banco, para afirmar com certeza o status atual de uma proposta, e as datas em que foram atualizadas.

1.3 Sobre a OrganizaçãoAs principais atividades do correspondente bancário é atuar como agente

intermediário entre os bancos e instituições financeiras autorizadas pelo BC (Banco Central) e clientes interessados em empréstimos, financiamentos, crédito pessoal e serviços bancários.

A lei que regulamenta essa atividade é a Resoluções BACEN n.º 3110 e 3156, ambas de 2003, ela estabelece que correspondentes bancários podem exercer alguns serviços específicos para bancos e instituições financeiras autorizadas pelo Banco Central do Brasil. São eles:

Encaminhamento de propostas de abertura de contas de depósitos à vista, a prazo ou poupança;

Podem receber e pagar de contas, aplicação e resgates em fundos de investimentos;

Efetuar ordens de pagamentos; Fazer pedidos de empréstimos e financiamentos; Fazer analise de crédito e cadastro; Terceirizar serviços de cobranças; Enviar pedidos de cartões de créditos; Atuar no processamento de dados.

O foco do nosso estudo está no controle dos comissionamentos pagos pelo serviço de encaminhamento de propostas para cartão de crédito. Por motivos de sigilo, a empresa preferiu não ter seu nome descrito no trabalho, portanto nos referenciaremos a ela apenas como empresa correspondente bancária.

1.3.1 Propostas para cartão de créditoUma das atividades de uma empresa que presta o serviço de correspondente

bancário é o encaminhamento de propostas para cartão de crédito ao banco ou instituição financeira para qual presta esse serviço. Para tanto, ela põe funcionários em campo para vender os cartões aos servidores públicos, de acordo com os convênios fechados pela empresa e alguns órgãos. No entanto, nem todas as propostas produzidas em campo são aprovadas pelo banco, podendo gerar pendências, represamentos e cancelamentos de propostas.

Para controle do correspondente, o banco disponibiliza uma planilha informando às propostas que foram pagas no comissionamento da semana, bem como as propostas que foram identificadas pendências, as que entraram em represamento e as que foram canceladas. O correspondente por sua vez, examina a planilha recebida e conferi se todas as propostas que ele enviou no romaneio para o banco foram pagas, quais entraram em pendência, represamento ou cancelamento.

Mais informações sobre os status que uma proposta pode assumir e de como o controle é realizado atualmente estão descritos no Apêndice A.

1.4 Convenções para Identificação dos Requisitos Por convenção, os requisitos são indicados e referenciados por um indicador no formato [RFxx], para os requisitos funcionais, e no formato [RNFxx], para os não funcionais, onde xx se refere ao número do requisito. Os requisitos também possuirão os nomes dos casos de uso relacionados.

1.5 Convenções para Identificação dos Casos de Uso Por convenção, os casos de uso são indicados e referenciados por um indicador no formato [UCxx], onde xx se refere ao número do caso de uso.

1.5.1 Estrutura dos casos de uso Cada caso de uso terá o seguinte formato:

Atores: Os modelos de usuário que utilizarão o caso de uso; Prioridade: Prioridade de implementação deste caso de uso; Entradas: Variáveis que serão passadas ao sistema; Pré-condições: Condições que devem ser satisfeitas antes de o caso de uso ser

executado; Fluxo de eventos: O passo a passo das ações realizadas para que o caso de uso

seja concluído, podendo incluir fluxos de eventos secundários e/ou alternativos; Saídas: Saídas que devem ser fornecidas pelo sistema quando o caso de uso for

executado; Pós-condições: Condições que devem ser satisfeitas depois de o caso de uso ser

finalizado.

1.5.2 Prioridades dos casos de uso Os casos de uso são classificados como:

Essencial: É o caso de uso indispensável ao funcionamento do sistema. Esse tipo de caso de uso deve ser implementado impreterivelmente, caso contrário, o projeto perderá sua utilidade.

Importante: Sem este caso de uso, o sistema ainda é capaz de ser utilizado. Contudo, essa utilização se dá de forma não satisfatória pelo cliente.

Desejável: Esse tipo de caso de uso poderá ser implementado em versões posteriores do sistema, visto que, mesmo sem a sua implementação, o sistema atende as suas funcionalidades básicas.

1.5.3 Descrição dos Atores Os atores são aqueles que interagem de alguma forma com o sistema. Eles são bancos e instituições financeiras.

2. Requisitos Organizacionais Os requisitos organizacionais devem satisfazer os objetivos da organização e definir porque o sistema é necessário. Esses requisitos são:

Facilitar comunicação bancos e instituições financeiras – tornar a comunicação entre as partes mais ágil e tranqüila;

Fornecer informações sobre as correspondências bancárias – tornar transparentes informações do processo envolvido;

Obter maior controle das parcelas dos clientes em relação à inadimplência.

3. Requisitos Funcionais Neste capítulo são definidas as funções que o sistema deve realizar. Os requisitos estão agrupados de acordo com suas características.

3.1 [RF01] Efetuar logon

Identificação: [RF01] Efetuar logon

Casos de Uso relacionados: [UC 01]

Descrição:Permite que um usuário tenha acesso a informações pertencentes ao software. Para isso, o usuário deve informar login e senha. Não deve haver outra maneira de entrar no sistema diferente desta.

Prioridade: Essencial Importante Desejável

3.2 [RF02] Efetuar logoff

Identificação: [RF02] Efetuar logoff

Casos de Uso relacionados: [UC 02]Descrição: Permite que o usuário saia do sistema.


3.3 [RF03] Inserir Projeto

Identificação: [RF03] Inserir Projetos


Descrição:

O administrador do sistema insere um novo projeto no banco de dados do sistema. Um projeto tem os dados: Nome do projeto, banco relacionado, Comissão paga pelo banco por cada proposta enviada, Previsão do total de clientes que o projeto pode atender, período de vigência do projeto.


3.4 [RF04] Remover Projeto

Identificação: [RF04] Remover Projetos


Descrição:

O administrador do sistema remove um projeto no banco de dados do sistema. Ao realizar essa operação o sistema deve também remover todos os clientes desse projeto.

Um pedido de confirmação deve ser requerido ao administrador, juntamente com uma mensagem informando que o projeto e os clientes associados serão excluídos.


3.5 [RF05] Atualizar Projeto

Identificação: [RF05] Atualizar Projeto

Casos de Uso relacionados: [UC 05]Descrição: O administrador do sistema atualiza os dados de um projeto


3.6 [RF06] Listar Projetos

Identificação: [RF06] Listar Projetos

Casos de Uso relacionados: [UC 06]Descrição: Lista projetos por banco e período de vigência do projeto.


4. Requisitos Não Funcionais Descreveremos a seguir, os requisitos que envolvem restrições e aspectos de

qualidade do sistema de controle de propostas de cartão, SisProposta. Os requisitos não funcionais serão classificados em: requisitos de processo, requisitos externos e requisitos de produto.

4.1 Requisitos de Processo

4.1.1 [RNF01] Utilizar SCRUM como Metodologia de Desenvolvimento

Identificação [NFR01] – Desenvolvimento em SCRUMCasos de Uso relacionados Todos.Descrição O SCRUM será a metodologia empregada, pois permite

agilidade e participação ativa dos stakeholders. Além disso, como o sistema será gerenciado pela empresa desenvolvedora, não será necessária a geração de uma documentação formal extensa.

Prioridade Essencial Importante Desejável

4.1.2 [NFR02] - Desenvolvimento em JavaIdentificação [NFR02] – Desenvolvimento em JavaCasos de Uso relacionados Todos.Descrição O sistema deve ser desenvolvido utilizando a linguagem

Java compatível com o servidor Apache Tomcat 7.0.Prioridade Essencial Importante Desejável

4.1.3 [NFR03] – Utilizar Banco de Dados MySqlIdentificação [NFR03] - Utilizar Banco de Dados MySqlCasos de Uso relacionados Todos.Descrição A empresa dispõe de um serviço de banco de dados em

MySql, contratado e não utilizado. Portanto, a aplicação deverá fazer desse serviço ocioso para persistência dos dados.


4.2 Requisitos de Externos

4.2.1 [NRF04] - Tempo de DesenvolvimentoIdentificação [NRF04] - Tempo de DesenvolvimentoCasos de Uso relacionados Todos.Descrição O tempo para desenvolvimento do sistema não deve

ultrapassar o prazo previsto no documento de viabilidade, visto a urgência da solução descrita no mesmo documento.

Dessa forma, o tempo de desenvolvimento total não pode ser superior a 2 meses.


4.2.2 [RNF05] - Custo de DesenvolvimentoIdentificação [NRF05] - Custo de DesenvolvimentoCasos de Uso relacionados Todos.Descrição O custo de desenvolvimento não deve ultrapassar o valor

estimado no documento de viabilidade. Então, para o trabalho de 2 meses temos que não se deve ultrapassar o valor de R$ 5.998,60.


4.3 Requisitos de Produto

4.3.1 [RNF06] - PermissãoIdentificação [NRF06] - PermissãoCasos de Uso relacionados Todos.Descrição Cada usuário só poderá realizar ações que foram

permitidas a ele na hora do seu cadastro.Prioridade Essencial Importante Desejável

4.3.2 [RNF07] - BackupIdentificação [NRF07] - BackupCasos de Uso relacionados Todos.Descrição O sistema deverá disparar Backups agendados a fim de

aumentar a segurança em caso de perda de dados pela empresa contratada para o serviço de hospedagem do banco.


4.3.3 [RNF08] - Mensagens de RetornoIdentificação [NRF08] – Mensagens de RetornoCasos de Uso relacionados Todos.Descrição O sistema deverá exibir uma mensagem na tela para toda

ação do usuário, seja ela bem sucedida ou não, bem como uma descrição do motivo quando for necessário.


4.3.4 [RNF09] - Menus bem EstruturadosIdentificação [NRF09] – Menus bem EstruturadosCasos de Uso relacionados Todos.Descrição Os menus devem ser bem estruturados de modo a permitir

uma navegação simples e intuitiva, proporcionando uma interface simples, melhorando a usabilidade.


Figura 1 Modelagem de Requisitos Funcionais (Casos de Uso)

5. Conclusão Através do documento de requisitos, foi possível entender, através de uma breve descrição, o problema a ser resolvido com o sistema SisProposta.

Em seguida foram apresentados todos os requisitos funcionais do sistema, isto é, todos os serviços que o SisProposta deve oferecer aos seus usuários, segundo a definição do cliente.

Seguindo os requisitos funcionais, foram apresentados os requisitos não-funcionais, que irão definir restrições de como o sistema irá funcionar baseado em seus requisitos funcionais.

Também foi abordada a modelagem organizacional do sistema usando a notação i*, em que foram incluídos os modelos de dependência estratégica (SD) e o modelo estratégico de razão (SR) com os atores.

Dando continuidade à modelagem de requisitos funcionais, através do diagrama de casos de uso, foram descritos os casos de uso do sistema, incluindo seus fluxos de eventos e dependências entre si.

Finalmente, foi feita a modelagem dos requisitos não-funcionais utilizando a plataforma NFR, mostrando os refinamentos deles, explicitando operacionalizações e interdependências entre eles.

Referências[Disciplina] Disciplina de Especificação de Requisitos e Validação de Sistemas. Disponível em: <https://sites.google.com/a/cin.ufpe.br/if716/>. Acesso em: 05 mai. 11.

Site de Empréstimos Consignados: <http://www.emprestimoconsignado.com.br/servicos-bancarios/correspondente-bancario-para-emprestimos/>

Site Atigonal, Artigos Gratuitos: <http://www.artigonal.com/administracao-artigos/como-se-tornar-correspondente-bancario-2381049.html>

[Sommerville] G. Kotonya and I. Sommerville, Requirements Engineering : Processes and Techniques , John Wiley & Sons, 1998.

Relatório da Equipe

Nesta última seção, segue a porcentagem de esforço de cada membro da equipe. As atividades realizadas por cada um estão descritas no Histórico de Revisões deste documento.

Nome Esforço da equipe (%) Assinatura

https://sites.google.com/a/cin.ufpe.br/if716/

Philippe Pereira das Neves 50%

Rômulo César Dias de Andrade

50%

Tabela 1 Porcentagem de esforço dos membros da equipe

Anexo A – Status das propostas e Controle Atual

Ao fechar uma proposta de cartão com um cliente, o vendedor deve extrair uma série de informações como nome, endereço, idade, etc. Deve pedir também cópias de documentos como RG, CPF, comprovante de residência, entre outros. No final do dia o vendedor retorna a loja onde o projeto está sendo executado, e entrega a sua produção ao supervisor da loja.

O supervisor realiza o que chamamos de triagem, que consiste de uma conferencia dos dados e documentos coletados para cada proposta. Caso encontre algum problema como, por exemplo, assinatura da proposta não conferi com a assinatura do RG, ou RG não está legível, ou o cliente não possui margem para reservar ao serviço de crédito, entre outros pontos a serem analisados, a proposta é dita com pendência, não é enviada ao banco, e retorna as mãos do vendedor responsável para a regularização da mesma. Caso a proposta seja aprovada na triagem feita pelo supervisor, ela é adicionada ao romaneio que será enviado ao banco, junto com toda sua documentação e é feito um romaneio eletrônico enviado para o administrativo da empresa, que serve também como capa do romaneio de envio ao banco.

O banco por sua vez, ao receber o romaneio, realiza a primeira triagem do total de duas, para analisar a corretude das propostas recebidas pelo correspondente bancário. Caso encontre algum problema com uma proposta, ela não será aprovada, se não encontrar nenhum problema, a proposta será aprovada e poderá seguir dois caminhos, ou será encaminhada ao setor financeiro, que deverá efetuar o pagamento do comissionamento por aquela proposta aprovada ao correspondente bancário, ou será represada, ou seja, não será pago o comissionamento, para compensar quantitativamente outras propostas que entraram em pendência na segunda triagem do banco, que é realizada algum tempo depois da primeira, em média 30 dias.

Dessa forma, já identificamos 4 status possíveis para uma proposta. Resta ainda mais um status a considerar. As propostas que foram canceladas, e pelas quais o correspondente já foi pago. Quando isso acontece, o banco irá subtrair do comissionamento do correspondente o valor relativo às propostas canceladas.

Toda essa informação do que está acontecendo com as propostas é enviada pelo banco ao seu correspondente em uma planilha semanalmente. Hoje, ao receber o arquivo do banco, um funcionário do administrativo atualiza uma outra planilha de sua autoria, onde vai separando por status, cada proposta contida no arquivo semanal do banco. Ao final, ele poderá tirar posicionamento sobre o andamento de cada projeto realizado, e repassar a gerencia os números atuais.

Anexo B – Descrição dos Casos de Uso

[UC01] Efetuar logon Identificador: [UC 01]

Descrição: Autentica o usuário no sistema.

Atores: Supervisor e Vendedor.

Prioridade: Essencial

Pré-condições: Não se aplica.

Pós-condições: O ator terá acesso às funcionalidades do sistema que lhe dizem respeito.

Fluxo de Eventos Principal

1. Estando na tela inicial do sistema, o ator deve preencher os campos “login” e “senha”;

2. O ator então clica no botão “OK”.

Fluxo Secundário 1

1. O ator fornece um login não cadastrado no sistema;

2. A mensagem “Usuário inexistente” é exibida.

Fluxo Secundário 2

1. O ator fornece um login e uma senha não correspondentes;

2. A mensagem “Senha incorreta” é exibida.

Requisitos Não Funcionais Específicos

-

[UC02] Efetuar logoffIdentificador: [UC 02]

Descrição: Finaliza o acesso ao sistema.

Atores: Supervisor e Vendedores


Pré-condições: O ator deve estar logado no sistema no momento da execução dessa operação.

Pós-condições: O ator deixa de ter acesso às funcionalidades do sistema. O sistema retorna à tela inicial.


1. O ator clica no botão “Sair”;

2. O sistema finaliza todas as operações que estão em execução devido às requisições feitas por esse ator.


-

[UC03] Inserir ProjetoIdentificador: [UC 03]

Descrição: Insere um projeto no sistema.

Ator: Administrador do sistema.


Pré-condições: O ator deve estar logado no sistema. Não deve haver nenhum projeto já cadastrada com o mesmo nome.

Pós-condições: Haverá um novo projeto cadastrado no sistema.


1. O ator seleciona no menu “Projeto” a opção “Cadastrar”;

2. O sistema exibe o formulário de cadastro de um novo Projeto;

3. O ator informa os dados do projeto a ser cadastrado;

4. O ator clica no botão “OK”;

5. O sistema cadastra as informações na base e retorna para o formulário de cadastro apresentando os campos limpos.

[UC04] Remover ProjetoIdentificador: [UC 04]

Descrição: Remove um projeto do sistema e todos os registros relativos a ele.



Pré-condições: O projeto que se deseja remover deve estar cadastrado no sistema.

Pós-condições: O registro do projeto e todos os outros registros relativos não se encontrarão mais no sistema.


1. Incluir o fluxo de eventos do caso de uso “[UC06] Listar Projeto”;

2. O ator seleciona o ícone de remoção de uma das entradas presentes na lista de Projeto;

3. O sistema exibe uma tela contendo um formulário com as informações do respectivo projeto e o botão “Excluir”;

4. O ator seleciona o botão “Excluir”;

5. O sistema exibe uma mensagem informando que o projeto e outros registros relacionados a ele serão removidos do sistema e pede a confirmação do usuário;

6. O ator confirma a exclusão;

7. O sistema remove os devidos registros e retorna para a tela de listar projetos.

Fluxo Secundário 1

1. No passo quatro do fluxo principal, o ator seleciona o botão “Cancelar”;

2. O sistema retorna para a tela de listar projetos.

Fluxo Secundário 21. No passo seis do fluxo principal, o ator não confirma a exclusão;

2. O sistema retorna para a tela de listar de projetos.


-

[UC05] Atualizar Projeto

Identificador: [UC 05]

Descrição: Atualiza as informações de um Projeto.


Prioridade: Importante

Pré-condições: O Projeto a ser alterado deve estar presente no sistema.

Pós-condições: Os dados do Projeto informado na alteração serão persistidos no sistema.


1. Incluir o fluxo de eventos do caso de uso “[UC06] Projetos”;

2. O ator seleciona o ícone de alteração de uma das entradas presentes na lista de Projetos;

3. O sistema exibe uma tela contendo um formulário com as informações do respectivo projeto e o botão “Alterar”;

4. O ator altera as informações desejadas;

5. O ator seleciona o botão “Alterar”;

6. O sistema persiste os novos dados do projeto e volta para a tela de projetos.

Fluxo Secundário 1

1. No passo cinco do fluxo principal, o ator seleciona o botão “Cancelar”;

2. O sistema retorna para a tela de listar projetos.

Fluxo Secundário 21. No passo quatro do fluxo principal, o ator altera os dados do projeto deixando-os

iguais ao de outra já cadastrada;

2. O sistema exibe uma mensagem avisando que já existe um projeto cadastrado com esses dados e permanece na mesma tela com os campos preenchidos.


-

[UC06] Listar Projetos

Identificador: [UC 06]

Descrição: Lista os projetos que estão cadastradas no sistema.



Pré-condições: O usuário deve estar logado no sistema.

Pós-condições: Nenhum registro do sistema deve ser alterado pela realização dessa funcionalidade.


1. O ator seleciona no menu “Projeto” a opção “Listar”;

2. O sistema exibe uma tela com a lista completa dos projetos ordenada alfabeticamente por: nome do projeto, banco.

Fluxo Secundário 21. No primeiro passo do fluxo principal, não há nenhum projeto cadastrado;

2. O sistema permanece na mesma tela e exibe uma mensagem informando que não existe nenhum projeto cadastrado.


-

Anexo C – Glossário

• Banco de dados MySQL: O programa 'MySQL' é um sistema de gerenciamento de banco de dados relacionais baseado em comandos SQL (Structured Query Language - Linguagem Estruturada para Pesquisas) que vem ganhando grande popularidade, sendo atualmente um dos bancos de dados mais populares, com mais de 4 milhões de instalações.

• Login: Trata-se de uma seqüência de caracteres utilizada para identificar um usuário de forma única.

• Log on: Termo utilizado para demonstrar a ação de um usuário quando entra no sistema dom login e senha.

• Log off: Termo utilizado para demonstrar a ação de um usuário quando este sai do sistema.

Documents

Estudo de Viabilidade - Rômulo César – Consultoriaromulocesar.com.br/.../uploads/2015/08/Template_ES_UII1.docx · Web viewO supervisor realiza o que chamamos de triagem, que consiste