CNP2011007-Projeto Básico.pdf - BRb

Projeto Básico
Aquisição de Solução Multicanal
SUSIS/GENEG
JULHO/2011
Projeto Básico SUSIS/GENEG 2011/003 1

Sumário
1 OBJETO......................................................................................................................4
1.1 AQUISIÇÃO DA SOLUÇÃO DE MULTICANAL...............................................................4
1.2 TRANSFERÊNCIA DE TECNOLOGIA DA SOLUÇÃO ADQUIRIDA E ADAPTADA AO NEGÓCIO
BRB...........................................................................................................................4
1.3 SERVIÇOS OPERACIONAIS DE PRODUÇÃO E DE SUPORTE DA SOLUÇÃO DE MULTICANAL
NO AMBIENTE BRB ......................................................................................................4
2 FASES DA EXECUÇÃO DO CONTRATO.............................................................................5
2.1 PRIMEIRA FASE ....................................................................................................5
2.2 SEGUNDA FASE ....................................................................................................5
2.3 TERCEIRA FASE ....................................................................................................5
2.4 QUARTA FASE ......................................................................................................5
3 PANORAMA DA AUTOMAÇÃO BANCÁRIA E CANAIS DE ATENDIMENTO.................................6
3.1 CANAIS DE ATENDIMENTO.....................................................................................6
3.2 AUTORIZADOR DE TRANSAÇÕES.............................................................................7
3.3 SISTEMAS DE INFRAESTRUTURA.............................................................................7
4 PROBLEMAS ATUALMENTE ENFRENTADOS.......................................................................7
4.1 OBSOLESCÊNCIA TECNOLÓGICA.............................................................................7
4.2 DESENVOLVIMENTO DE DEMANDAS.........................................................................8
4.3 DESCENTRALIZAÇÃO DE REGRAS............................................................................8
4.4 ESCASSEZ DE DOCUMENTAÇÃO .............................................................................8
5 SOLUÇÃO PROPOSTA....................................................................................................8
5.1 CEN - CENTRALIZADOR e AUTORIZADOR................................................................8
5.2 ATUALIZAÇÃO TECNOLÓGICA.................................................................................9
5.3 GAB – MÓDULO GERAL DE GERENCIAMENTO DA AUTOMAÇÃO BANCÁRIA....................9
5.4 CANAIS DE ATENDIMENTO.....................................................................................9
5.5 DOCUMENTAÇÃO ..................................................................................................9
6 DESCONTINUIDADE DE SISTEMAS...............................................................................10
7 ESPECIFICAÇÃO TÉCNICA...........................................................................................10
7.1 Requisitos Gerais:................................................................................................10
7.2 CAIXA AGÊNCIA E CORRESPONDENTES..................................................................12
7.3 IBK – INTERNET BANKING (PESSOA FÍSICA E JURÍDICA) E TELEBANCO....................13
7.4 MBK – MOBILE BANKING......................................................................................15
7.5 MPY – MOBILE PAYMENT.......................................................................................15
7.6 MSM – MOBILE SMART MESSAGE..........................................................................16
7.7 AUB – SISTEMA DE AUTOMAÇÃO BANCÁRIA – ATENDIMENTO, GERÊNCIA E
RETAGUARDA............................................................................................................16
7.8 AAT - AUTOATENDIMENTO....................................................................................16
7.9 REX – REDES EXTERNAS......................................................................................17
7.10 REC – REDES CONVENIADAS..............................................................................17
7.11 SAT – SISTEMA DE AGENDAMENTO DE TRANSAÇÕES.............................................17
7.12 FLT – FLUXO DE TEDs.........................................................................................18
7.13 MMC – MONITOR DO MULTICANAL.......................................................................18
7.14 CON – CONCILIAÇÂO.........................................................................................19
7.15 SIA – SISTEMAS DE INFRAESTRUTURA DA AUTOMAÇÃO BANCÁRIA.........................19
7.16 BASE DE DADOS................................................................................................19
7.17 PROCESSADOR DE DÉBITOS E CRÉDITOS.............................................................19
8 ADAPTAÇÃO DA SOLUÇÃO AO NEGÓCIO BRB.................................................................22
8.1 Obrigações da CONTRATADA.................................................................................22
...........................................................................................................................22
8.2 TREINAMENTOS...................................................................................................23
9 REMUNERAÇÃO .........................................................................................................23
9.1 PERCENTUAL DE REMUNERAÇÃO PARA PROJETOS COM PONTOS DE FUNÇÃO..............24
Projeto Básico SUSIS/GENEG 2011/003 2

10 PADRÕES DE SEGURANÇA.........................................................................................25
11 CONECTIVIDADE......................................................................................................26
12 ANEXOS..................................................................................................................27
12.1 Anexo 1 – Relação de Funcionalidades..................................................................27
12.2 Anexo 2 – Sistemas e Serviços Descontinuados:....................................................28
12.3 Anexo 3 – Arquivos do Método de Acesso.............................................................29
12.4 Anexo 4 – Relação das funcionalidades previstas para o Mobile Banking...................31
12.5 Anexo 5 – Relação das funcionalidades previstas para o GPW..................................31
13 GLOSSÁRIO.............................................................................................................32
Projeto Básico SUSIS/GENEG 2011/003 3

PROJETO BÁSICO SUSIS/GENEG 2011/003
Brasília, 13 de julho de 2011
Assunto : PROJETO BÁSICO MULTICANAL
Este projeto tem por objetivo principal subsidiar a avaliação da atual estrutura da automação
bancária, destacando suas fragilidades, além de propor a adoção de uma nova solução, mais
robusta e com novas tecnologias, de forma a alinhar os Sistemas que a compõem à visão de
negócio com maior agilidade e menor custo, visando atender os preceitos da missão do Banco
de “Oferecer atendimento com excelência e soluções financeiras inovadoras, contribuindo para o
desenvolvimento socioeconômico do DF e regiões de influência”, permitindo atingir sua visão
que é “Ser reconhecida como a melhor instituição financeira do DF e regiões de influência”, com
respeito aos valores de foco no cliente, responsabilidade social, comprometimento, ética,
solidez, valorização dos colaboradores e empreendedorismo.
1 OBJETO
O objeto do Edital será a aquisição de Sistema Multicanal para tratamento de transações
financeiras, abrangendo desde o CEN – centralizador e autorizador até os canais de Internet
Banking (Portal de Serviços Bancários) e Telebanco, Caixa (agência e correspondente),
Atendimento/retaguarda, Mobile Banking, Mobile Payment e Mobile Smart Message além de
outros serviços que serão descritos neste projeto básico.
1.1 AQUISIÇÃO DA SOLUÇÃO DE MULTICANAL
Consiste na aquisição de solução Multicanal com cessão de uso permanente, sendo item
integrante da aquisição a Transferência de Tecnologia de Produção e Desenvolvimento, com
entrega dos programas fontes, bibliotecas, documentos e outras atividades descritas neste
Projeto Básico.
1.2 TRANSFERÊNCIA DE TECNOLOGIA DA SOLUÇÃO ADQUIRIDA E ADAPTADA AO
NEGÓCIO BRB
Consiste no fornecimento de todos os subsídios para que as equipes técnicas da Área de
Tecnologia do BRB obtenham os conhecimentos necessários ao perfeito entendimento da
solução de Multicanal – arquitetura, dados, objetos, funções e construção da solução, estando
capacitados ao final do contrato a Manter e Produzir o descrito.
1.3 SERVIÇOS OPERACIONAIS DE PRODUÇÃO E DE SUPORTE DA SOLUÇÃO DE
MULTICANAL NO AMBIENTE BRB
Consiste na produção da solução de Multicanal adaptada ao Negócio BRB em ambiente interno
do BRB na cidade de Brasília, DF, e será feita pela equipe de produção da CONTRATADA, de
acordo com o definido no quadro abaixo, que deverão manter a solução em operação
permanente 24h X 7 dias/semana X 365 dias/ano durante o período de vigência do contrato,
incluindo dias úteis, fins de semana e feriados, mantendo a solução operacional conforme
Acordo de Nível de Serviço a ser firmado.
Serão delimitados a seguir alguns parâmetros que irão compor o Acordo de Nível de Serviço –
ANS (do inglês, SLA). Esses indicadores contar-se-ão a partir do momento do acionamento por
parte do banco.
Tabela de Impacto x Tempo de Solução
Impacto Tempo de Solução Descrição
1 1 hora consecutiva Serviço indisponível
Projeto Básico SUSIS/GENEG 2011/003 4

2 2 horas consecutivas Serviço impactado, funcionando
com graves restrições
3 6 horas úteis Serviço impactado, funcionando
com pequenas restrições
4 20 horas úteis Outros tipos de
incidentes/requisições, mudanças
padrão e dúvidas
5 30 dias consecutivos Requisições de mudanças (RDM)
O enquadramento da gravidade do impacto é prerrogativa exclusiva e incontestável do Banco.
A CONTRATADA deverá prestar o suporte técnico da solução por telefone e e-mail, durante a
vigência do contrato em horário comercial. Se ficar constatada a necessidade por parte do
CONTRATANTE, o suporte técnico poderá ser requisitado para fora do horário de expediente
bancário, inclusive nos finais de semana e feriados, em regime de sobreaviso, sem custos
adicionais ao contratado.
2 FASES DA EXECUÇÃO DO CONTRATO
2.1 PRIMEIRA FASE
Prazo limite de até 6 meses contados da data de assinatura do contrato para a entrega dos
seguintes serviços, módulos e canais:
• CEN – Centralizador (M)
• GAB – Módulo geral de gerenciamento do multicanal (M)
• MMC – Monitor do multicanal (M)
• IBK – Internet Banking e Telebanco (C)
• MBK – Mobile Banking ©
• SIA – Sistema de infraestrutura da automação bancária
2.2 SEGUNDA FASE
Prazo limite de até 12 meses contados da data de assinatura do contrato para a entrega dos
seguintes serviços, módulos e canais:
• CIX – Caixa Agência e Correspondente (C)
• AUB – Sistema de automação bancária (C)
• AAT – Autoatendimento (S)
• REX – Redes Externas (S)
• REC – Redes Conveniadas (S)
• CON – Conciliação (M)
2.3 TERCEIRA FASE
Prazo limite de até 18 meses contados da data de assinatura do contrato para a entrega dos
seguintes serviços, módulos e canais:
• SAT – Sistema de Agendamento de transações (M)
• FLX – Fluxo de TEDs (M)
2.4 QUARTA FASE
Prazo limite de até 24 meses contados da data de assinatura do contrato para a entrega dos
seguintes serviços, módulos e canais:
• MPY – Mobile Payment (C)
• MSM – Mobile Smart Message (C)
Obs: Para que cada módulo/canal seja considerado entregue todos os requisitos gerais e
específicos que se enquadram para o referido módulo devem ter sido atendidos além do
Projeto Básico SUSIS/GENEG 2011/003 5

desenvolvimento das funcionalidades previstas para aquele módulo/canal conforme anexo 1.
(M) – Módulo com o cadastramento das funcionalidades descritas neste documento.
(C) – Canal
(S) – Somente o cadastramento das funcionalidades no CEN.
O BRB não exige que a solução Multicanal da empresa possua módulos específicos para o
atendimento das necessidades descritas neste projeto básico.
3 PANORAMA DA AUTOMAÇÃO BANCÁRIA E CANAIS DE ATENDIMENTO
A atual estrutura da automação bancária, de forma simplificada, é composta dos seguintes
itens:
3.1 CANAIS DE ATENDIMENTO
São sistemas transacionais, de interfaceamento com clientes, sejam eles internos ou externos.
Possuem característica principal de prover serviços que, posteriormente, se integrarão com os
sistemas de grande porte (legado). Os atuais canais de atendimento da automação bancária
são:
BRB BANKNET
Sistema de Internet Banking desenvolvido no início do ano de 2003, que permite a realização
de transações de transferência eletrônica para contas do BRB, TEDs, DOCs, agendamentos e
pagamentos de títulos, agendamentos e pagamentos de arrecadações públicas e de
concessionárias, manutenção de contratos de débito automático, consulta de extratos e recibos,
aplicações financeiras, empréstimos, cadastramento e utilização dos serviços do DDA, entre
outros, que serão melhor detalhados no Anexo 1 - RELAÇÃO DE FUNCIONALIDADES.
Este canal foi desenvolvido na linguagem Java, utilizando-se do framework proprietário
iWorkPlace, fornecido pela empresa Infonet. Possui também um Módulo Administrativo que
permite o gerenciamento e controle do Banknet e Aplicativo CRBRB, por meio de auditorias,
controle de usuários, parametrização de transações, dentre outros.
APLICATIVO CRBRB
Aplicativo desenvolvido em Delphi em 2003, que é responsável por trocar bilhetes entre a
estrutura tecnológica da Call Center do BRB com o Mainframe, utilizando os recursos da
Unidade de Resposta Audível – URA e o Gateway EAP e que, com base no bilhete enviado,
recebido e confirmado, proverá a abertura de funcionalidades no web-browser a ele acoplado.
Tais funcionalidades são uma adaptação do Internet Banking para viabilizar o funcionamento do
BRB Telebanco, preservando portanto quase todos os recursos do BRB Banknet, além de
compartilhar sua base de informações.
ABA-VÍDEO
Sistema desenvolvido em Delphi na década de 90, utilizado por empregados do Banco,
estagiários e prestadores de serviço autorizados, destinado a operações dos setores de
atendimento e retaguarda, que possui recursos para investimentos, lançamentos financeiros
extra-caixa, transferências eletrônicas, manutenção de cadastro de contas autorizadas para
emissão de TED/Doc, Ordens Bancárias, relatórios diversos, manutenção de cadastro do DDA,
dentre outras informadas no Anexo 1 - RELAÇÃO DE FUNCIONALIDADES.
ATB-CAIXA
É um canal de atendimento desenvolvido na década de 2000, utilizando Delphi, que tem por
finalidade permitir aos caixas das agências efetuarem transações financeiras quando
Projeto Básico SUSIS/GENEG 2011/003 6

demandados por algum cliente. Destacam-se as transações de saque, depósito, saldo, Doc e
TED, sendo as demais detalhadas no Anexo 1 - RELAÇÃO DE FUNCIONALIDADES. Possui um
diferencial quando tratamos do conceito de Supertransação, que permite a um operador iniciar
vários recebimentos de documentos diversos, gerando ao final um único recebimento de
valores, seja ele através de dinheiro, liquidação de cheque ou débito autorizado, de forma a
poupar substancialmente o tempo do cliente e também do operador.
ATC-CORRESPONDENTE
Similar e originário do ATB - Caixa, que evoluiu com distinção de algumas regras, de forma a
atender às especificidades do seu público alvo, que são os usuários dos Correspondentes nãobancários.
AUTO ATENDIMENTO
Canal de atendimento eletrônico redesenvolvido em 2009, que atualmente está sob o Contrato
de outsourcing celebrado pelo BRB com a empresa Perto, tanto de sistema quanto de hardware
e que permite ao cliente efetuar várias operações de consulta, como extratos, saldos, recibos e
também transações financeiras, como saque, transferência, agendamentos, e pagamentos
diversos, além de serviços ofertados pelo BRB em conjunto com seus parceiros CEB, Caesb,
TJDFT, Cartão BRB e Sefaz. Detalhes sobre as transações estão disponíveis no Anexo 1 -
RELAÇÃO DE FUNCIONALIDADES. Possui também rotina de conciliação. As regras de negócio
estão atualmente no sistema ABX, de controle do BRB.
REDES EXTERNAS
São canais eletrônicos de atendimento, onde transitam transações das bandeiras Visa e
Mastercard/Maestro, além de transações em redes compartilhadas, como Banco 24h, RVA e
Banco do Brasil. A execução dos serviços disponibilizados nessas redes é assegurada por um
sistema centralizador desenvolvido na linguagem Java, denominado HRX. Possui também rotina
de conciliação.
3.2 AUTORIZADOR DE TRANSAÇÕES
Atualmente composto por um único sistema, denominado ABX, desenvolvido na década de
2000, com o propósito de ser um proxy entre os demais sistemas, além de conter, inicialmente,
as regras negociais para o canal autoatendimento. Com o passar do tempo, evoluiu-se o
conceito inicial, expandindo o gerenciamento das regras de forma a permitir que outros canais
utilizem-se de sua estrutura.
3.3 SISTEMAS DE INFRAESTRUTURA
Suite de aplicativos criados em momentos diferentes, entre a década de 80 e a de 2000, com
finalidades diversas, tecnologias e arquiteturas diferentes e que, em alguns casos, conflitam nos
serviços ofertados. São aplicativos responsáveis por carregar em uma base de arquivos
indexados com os dados das contas, produtos, tabelas de parâmetros e clientes do banco, além
de manipular tais informações sob demanda dos canais ou sistemas com os quais a automação
bancária se integra. As informações armazenadas por estes aplicativos são persistidas através
do conceito de Método de Acesso a Arquivos, tecnologia em estágio avançado de obsolescência,
pois foi implantada no BRB no final da década de 80.
4 PROBLEMAS ATUALMENTE ENFRENTADOS
4.1 OBSOLESCÊNCIA TECNOLÓGICA
Os sistemas da automação bancária passam por vários estágios de obsolescência, desde sua
linguagem, passando por sua arquitetura, até sua infraestrutura.
Projeto Básico SUSIS/GENEG 2011/003 7

A defasagem tecnológica prejudica a integração desses sistemas com novas ferramentas, além
de por vezes inviabilizar o desenvolvimento de novos serviços ou produtos, devido à
incompatibilidade com novos recursos tecnológicos. A principal consequência dessa defasagem
é o elevado tempo requerido para o desenvolvimento de novas demandas e para a realização de
manutenções nas demandas já implantadas.
4.2 DESENVOLVIMENTO DE DEMANDAS
O desenvolvimento de demandas é prejudicado pela defasagem tecnológica, à medida que a
grande diversidade de arquiteturas, linguagens e padrões adotados exige que os recursos
humanos sejam especialistas naquele assunto, dificultando a mineração de novos profissionais
para atuar nessas demandas, sem a necessidade de prévio treinamento. Esse treinamento, haja
vista a falta de documentação que será abordada posteriormente, exige disponibilidade de
outros recursos humanos que detém o conhecimento de forma tácita, tanto técnico quanto
negocialmente, prejudicando o andamento dos trabalhos.
4.3 DESCENTRALIZAÇÃO DE REGRAS
Atualmente cada canal de atendimento possui suas regras de negócio, que por vezes são
desnecessariamente replicadas, em alguns casos conflitantes, dificultando a rastreabilidade do
processo, prejudicando substancialmente o gerenciamento, compatibilização e alteração dessas
regras em tempo hábil, de forma a atender a necessidade do negócio.
Com a descentralização, tornam-se necessários mais recursos especialistas para o atendimento
de uma mesma demanda, além de acréscimo no tempo e, por consequência, no custo.
Ademais, o gerenciamento do atendimento dessas alterações em cada canal tem sua
complexidade aumentada, dadas as diferentes prioridades e peculiaridades desses canais. Na
atual conjuntura o quadro de recursos humanos, tanto do Núcleo quanto da Coordenação são
insuficientes para darem vazão às demandas prioritárias que fazem parte do atual e crescente
backlog da automação bancária.
4.4 ESCASSEZ DE DOCUMENTAÇÃO
A escassez ou quase nula documentação torna os processos não gerenciáveis por parte dos
gestores negociais e prejudica as manutenções, os rastreamentos das regras vigentes e dos
pontos correlatos a cada uma delas, haja vista a necessidade de um trabalho de engenharia
reversa para cada manutenção, o que pode gerar incorreta ou incompleta interpretação das
regras, aumentando o risco de impactos quando de sua publicação em ambiente de produção,
gerando retrabalho, prejuízos financeiros mensuráveis e de imagem para a Instituição.
5 SOLUÇÃO PROPOSTA
A solução proposta tem por objetivo resolver os principais problemas enfrentados e justificados
neste documento, atendendo as premissas descritas a seguir, sendo uma solução que não tenha
custo atrelado ao quantitativo de transações, devendo ser contratada sob modalidade de licença
de uso perpétua, com entrega dos fontes ao Banco, através da completa transferência de
tecnologia, podendo este a qualquer tempo proceder as alterações que lhe forem convenientes,
sem necessidade de prévia autorização, podendo inclusive ser feita por outra equipe diversa da
CONTRATADA, sem que isto caracterize descumprimento contratual.
5.1 CEN - CENTRALIZADOR e AUTORIZADOR
Criar um ponto único para processamento transacional, o qual chamaremos de CEN -
Centralizador, que também deverá permitir cadastramento das regras de negócio a serem
utilizadas pelos canais, que permita reutilização e padronização de processos de negócio,
agilizando atendimento das demandas e permitindo ao gestor participar interativamente do
processo, desde a fase de concepção até a fase de implantação, permitindo também que ele
Projeto Básico SUSIS/GENEG 2011/003 8

faça alterações nos processos já existentes, sem a necessidade de intervenção técnica. Visa
também manter a consistência das regras negociais em todos os canais, evitando que cada
canal tenha um comportamento diferenciado para o mesmo processo. Para atendimento desta
necessidade, propõe-se a utilização de BPM.
Exemplo de reutilização de processos:
Processo A: Saque
Subprocesso: Validar cartão
Subprocesso: Autenticar senha
Subprocesso: Debitar Conta
Processo B: Extrato
Subprocesso: Validar cartão (subprocesso reutilizado)
Subprocesso: Autenticar senha (subprocesso reutilizado)
Subprocesso: Emitir Extrato
5.2 ATUALIZAÇÃO TECNOLÓGICA
Prover arquitetura padronizada, utilizando-se de conceitos mais modernos, como orientação a
serviço (SOA), amparada por frameworks de mercado, linguagem mais moderna, recursos que
permitam escalabilidade, maior interoperabilidade e portabilidade com menor esforço possível.
5.3 GAB – MÓDULO GERAL DE GERENCIAMENTO DA AUTOMAÇÃO BANCÁRIA
Será um conjunto de aplicações que conterão todas as tarefas de parametrização e auditoria da
solução proposta, tanto a nível macro quanto aos parâmetros individualizados por canal. Deverá
também possuir a base de perfis por sistema/canal e seus respectivos usuários autorizados.
5.4 CANAIS DE ATENDIMENTO
Deverão atuar como interface entre cliente/usuário e os demais sistemas do Banco. Cada canal
deverá, no momento do acionamento de uma transação ou de um processo, buscar as regras
no CEN para montagem da tela, tais como campos e seus tipos, validações de preenchimento
em tela, informações a serem apresentadas, leiaute (estilo a ser utilizado, disposição dos itens
na tela, etc). Ao submeter a transação, deverá ser feita a comunicação com o CEN, que validará
as informações com base no cadastramento previamente realizado e autorizará ou não a
efetivação da operação.
Os canais deverão, também, permitir gerenciamento de conteúdo de forma interativa,
utilizando-se, para tanto, do recurso gerenciador de conteúdo.
5.5 DOCUMENTAÇÃO
Deverá ser armazenada através de um software GED, integrado ao processo de
desenvolvimento, permitindo armazenamento de documentação originária dos códigos fontes e
geradas através de mecanismos automatizados disponíveis nas ferramentas a serem utilizadas,
além de documentos adicionais que não são gerados de forma automatizada. Deverá também
possuir integração com o BPM, gerando também a documentação negocial.
Deverão ser utilizados artefatos previstos na linguagem UML, em sua versão mais recente.
Espera-se o fornecimento de, no mínimo, os seguintes artefatos, quando aplicáveis: Documento
de Visão, Diagrama de Caso de Uso, Especificação de Caso de Uso, Diagrama de Sequência,
Diagrama de Atividade, Diagrama de Estado, Diagrama de Colaboração e Roteiro de
Homologação. Adicionalmente podem ser solicitados quaisquer artefatos previstos na
Metodologia de Manutenção e Desenvolvimento de Software adotada pelo Banco, estando
quaisquer documentos sujeitos à aprovação do BRB.
Projeto Básico SUSIS/GENEG 2011/003 9

6 DESCONTINUIDADE DE SISTEMAS
Com a nova solução haverá a descontinuidade de diversos sistemas e serviços, que serão
detalhados no Anexo 2 – Sistemas e Serviços Descontinuados.
7 ESPECIFICAÇÃO TÉCNICA
Objetiva prover informações detalhadas sobre as especificações técnicas gerais e suas
peculiaridades para cada componente da solução.
7.1 Requisitos Gerais:
Não haver tarifação atrelada ao número de transações.
Os aplicativos devem ser desenvolvidos totalmente em linguagem Java 6 ou superior.
Utilizar arquitetura multicamada orientada a serviço (SOA).
Todos os canais que fazem parte da solução de multicanal e o centralizador devem possuir
formas distintas de acesso, seja por login de rede, seja por usuário e senha, ou de outras
formas a serem detalhadas nos canais além de possuir opções gerais de administração dos
canais e customização do CEN. Essa solução poderá ser apresentada através de Portal.
Permitir desenvolvimento, teste, homologação e implantação em produção, de forma individual
dos processos de negócio.
Os aplicativos devem permitir a segregação dos ambientes, a critério do BRB, sendo possíveis
os ambientes de Produção, Homologação, Desenvolvimento e Simulação.
Permitir que o usuário parametrize os processos de negócio no CEN através do BPM, permitindo
também a implantação de manutenções nos processos de negócio nos ambientes citados no
item 4, a qualquer tempo, sem a interrupção do serviço.
Permitir que os aplicativos sejam instalados em qualquer equipamento servidor, independente
do número de processadores, sem variação de custo.
Os códigos-fonte devem ser mantidos no ambiente do Banco, utilizando-se do repositório
Subversion, fornecido pelo Banco.
De acordo com as características do canal requisitante, o CEN devolverá a resposta (relatório,
mensagem, recibos, etc) indicando através de metadados como o canal deverá se comportar.
Cabe à CONTRATADA executar os projetos visuais e de navegabilidade especificados neste
projeto básico, de acordo com a linha de estética e marketing definida pelo Banco.
Todas consultas devem suportar critérios de filtragem e ordenação pelos campos exibidos, tanto
na requisição inicial quanto na filtragem e na ordenação em tela. Deve também possuir recurso
para impressão, exportação em formatos PDF, TXT, OFC, OFX e gráficos, quando possível.
A solução deverá suportar 3.000 (três mil) requisições por segundo.
O tempo de resposta às requisições feitas não deve ultrapassar 1 segundo, considerando o
tempo gasto internamente para o processamento na nova solução, seja ela canal, CEN ou banco
de dados.
Suportar os padrões Febraban CNAB 240 e ISO8583.
O CEN deverá possuir mecanismos que permitam dotar os canais de informações para que em
tempo de execução, possam exibir informações adicionais pré-cadastradas para cada metadado,
que auxiliem o usuário no preenchimento e interpretação de cada campo, utilizando-se para
tanto textos explicativos em formato a ser definido pelo Banco.
Em qualquer canal o campo que estiver com o foco, bem como os campos obrigatórios deverão
possuir estilo diferenciado, a ser carregado na inicialização da transação, com base em consulta
ao CEN.
Projeto Básico SUSIS/GENEG 2011/003 10

Os canais deverão carregar as máscaras dos campos e aplicá-las, de acordo com o metadado
cadastrado no CEN.
Quando possível, utilizar-se de hints e metáforas.
Atender ao requisito de portabilidade, sendo compatível com os sistemas operacionais Windows
2003, 2008 ou superior e Linux.
Permitir alteração, no menor esforço e quando possível de forma interativa, da disposição dos
itens em tela (menus, botões, campos, etc).
Permitir a publicação de campanhas de forma individualizada por canal e em múltiplos canais
simultaneamente, utilizando se possível recurso de gerenciamento de conteúdo. Permitir
também que as campanhas sejam direcionadas por perfis de clientes.
Quando for aplicação de interface web, esta deverá ser compatível com os browsers Internet
Explorer 6, Firefox 3, Safari 4, Opera 10 e Chrome 5, além de suas versões posteriores.
Utilizar padrões Java Blueprint e Javasoft, devemdo ser utilizada ferramenta automatizada para
validação quanto aos requisitos do Javasoft.
Manter documentação de código através de Javadoc.
Utilizar prototipação, quando possível.
Possuir ferramenta free, integrada ou não à solução, que permita o gerenciamento de bugs.
Fazer utilização de Portlet Container open-source que atenda aos padrões JSR 286 e
especificação WSRP 2.0.
Quanto a aplicação web, deverá ser implementado utilizando a framework Struts 2 ou JSF, que
propiciará diversas vantagens, com destaque para o fato de ser um framework baseado em
ações, opção de utilizar configuração via XML e anotações (tecnologia annotations), ações
baseadas em POJO, que permitem maior facilidade ao testar, integração com Spring, SiteMesh e
Tiles, bibliotecas baseadas em temas e tags em AJAX, possibilidade de criar taglibs próprias,
atende ao modelo MVC/MVC-2, que separa claramente camada de visão das demais camadas.
Utilizar o framework de persistência Hibernate, que permite o mapeamento objeto-relacional,
através de configurações em XML e/ou Annotations, permitindo a persistência dos objetos em
banco de dados, de forma transparente para a aplicação, bastando apenas as configurações
específicas e os drivers para cada banco, atendendo, por exemplo, o banco Oracle (na versão
10g, que é utilizado no BRB), banco IBM-DB2, entre outros. A independência entre aplicação e
banco de dados é vantajosa, por exemplo, caso a Instituição opte pela troca do fornecedor do
SGBD, auxiliando também em caso de atualização da versão do banco de dados, cujo upgrade
será menos traumático. O Hibernate é o arcabouço de persistência melhor conceituado no
mercado, de uso livre e que implementa JPA, com diversos profissionais capacitados, além de
ampla documentação.
Utilizar Jboss Seam.
Permitir a integração com pelo menos três frameworks de mercado para utilização de Ajax,
sendo ao menos duas sob licença free.
Disponibilizar recursos para web-chat, podendo ser ativado em qualquer canal a qualquer
tempo, conforme necessidade do Banco.
Possuir um único ponto central de comunicação, que suporte protocolo TCP/IP, com os padrões
ABX (proprietário do BRB) e JSON (mantido pelo JSON.org) e mensagens posicionais para
comunicação com alta plataforma. Para essas mensagens posicionais deve-se possuir uma base
com metadados, de forma a permitir a criação e/ou alteração do conjunto de mensagens a ser
utilizado. Permitir tráfego de mensagens nos padrões já descritos, XML e arquivos texto,
utilizando comunicação por web-service. Esse ponto unificado deverá também suprir funções de
gateway que permita o tráfego de mensagens entre diversos sistemas, de forma
parametrizável, inclusive em ambiente DMZ, além de validar se a mensagem trafegada atende
ao padrão definido no protocolo por ela utilizada, sendo possível também a monitoração do
tráfego em tempo real e também com séries históricas, que deverão ser acessadas e mantidas
através do MMC, sistema de monitoração que será tratado adiante.
Projeto Básico SUSIS/GENEG 2011/003 11

O CEN deverá ser capaz de tratar um processo utilizado por mais de um canal, de forma a
atender as especificidades de cada canal, não devendo replicar processos e sim tratar as
exceções como parte do fluxo.
Ser compatível com arquitetura de barramento 32 e 64 bits.
Toda a solução de canais deverá possuir contingenciamento, que funcione também em cluster,
com recursos de balanceamento de carga, permitindo o controle da carga de cada servidor que
faça parte do nó e também a migração das instâncias de um servidor ao outro, quando um
destes for desabilitado.
Deverá ser possível disponibilizar o CEN em várias instâncias de um mesmo servidor ou em
servidores diferentes.
Garantir a integridade e consistência das transações executadas, efetuando automaticamente o
estorno/rollback da transação com falha.
Deverá possuir recurso de espelhamento de base.
Possuir base centralizada de recibos de transações.
Prover a migração dos recibos atualmente existentes em bases de dados diferenciadas para a
nova base centralizada.
Possuir controle de duplicidade no dia para pagamentos e recebimento de cheques.
Possuir controle de transações, perfis e limites por canal, perfil e PA.
Possuir controle de valores acumulados por conta, perfil, canal, transação e usuário, permitindo
limites diferenciados inclusive com base em horários.
Controlar a execução das transações por horário, que deve ser diferenciado por canal e ou PA.
Todas as transações deverão estar preparadas para execução em lote, de forma que o gestor
defina a habilitação ou não das transações em lote com base na transação, canal e perfil de
usuário, podendo ser processos diferentes.
Permitir transações com um débito para vários créditos e um crédito para vários débitos, de
forma parametrizável no processo.
Todos os canais e o CEN deverão gravar todos eventos de acionamento de transações, tempo de
resposta, mensagem de erro ou sucesso, armazenamento da tela da transação, mensagens
saintes e entrantes, conclusão da transação, informação sobre transação abortada pelo usuário,
abortada pelo sistema por falha genérica ou regra de negócio. Todos os parâmetros da auditoria
serão definidos pelo Banco.
A auditoria deverá ser uma transação do CEN que será disponibilizada nos canais definidos pelo
banco e para os perfis também definidos.
A nova solução deverá permitir tratamento de diferentes fuso-horários.
Permitir a utilização de e-commerce.
Permitir transações de pagamento online originários de e-commerce de empresas parceiras,
com vistas a prover pagamento de compras on-line feitas pelo cliente, com débito em conta ou
ainda contratando uma linha de empréstimo pré-aprovado a ser definida pelo Banco.
Permitir a autenticação através de certificados digitais emitidos pela ICP-Brasil.
7.2 CAIXA AGÊNCIA E CORRESPONDENTES
Deverá funcionar em ambiente web.
Deverá possuir interface com padrão definido pelo Banco, que permita acesso a quaisquer das
funcionalidades em, no máximo, três teclas ou cliques.
Permitir acesso a qualquer serviço ou transação através do teclado numérico, usando de atalhos
simplificados, parametrizáveis pelo gestor.
Projeto Básico SUSIS/GENEG 2011/003 12

Disponibilizar as transações mais utilizadas com acesso em uma tecla, através de atalhos com
teclas especiais (F7, F8, etc), parametrizáveis, podendo ser feito inclusive com junção de teclas,
a critério do gestor. Deverá também possuir menu com todas as funcionalidades, em formato a
ser definido pelo Banco.
A comunicação com os periféricos do caixa deve seguir o padrão de API específica dos
equipamentos utilizados pelo BRB, podendo inclusive coexistir mais de um padrão para um
mesmo periférico.
Implementar todas as funcionalidades especificadas para os canais Caixa e Correspondente no
Anexo 1 - RELAÇÃO DE FUNCIONALIDADES deste documento.
Implementar Bobina Eletrônica com recursos de: navegação, localização de transações, zoom,
impressão, uso do mouse, duplo clique para consulta ou estorno da transação, uso de
paginação. Permitir exportação automatizada da bobina para formato TXT, de forma a ser
carregada por outros sistemas. A bobina bem como os recursos de localização deverão ser
providos pelo CEN, devendo estar no canal apenas os recursos de impressão, zoom, exportação
e outros de interação direta com o usuário.
Possuir calculadora com, no mínimo, as operações de soma, subtração, multiplicação, divisão,
percentual, memória (limpar, somar, subtrair, recuperar), zerar calculadora, copiar e colar, com
registro das operações na bobina eletrônica.
Permitir, no momento de um recebimento qualquer, quando a forma de pagamento for dinheiro
e/ou cheque, informar separadamente cada quantidade de cada cédula ou cheque e valor em
moedas, devendo tal recebimento ser contabilizado e registrado na bobina eletrônica, tal qual
um cálculo feito pela calculadora, sendo porém uma informação cuja obrigatoriedade seja
manipulável por parâmetro pelo gestor. Deve, também, armazenar essas informações junto à
transação, permitindo consulta a qualquer tempo.
Implementar log de falha de acesso aos periféricos, devendo estar disponível para consultas
através do aplicativo de monitoração.
Criar um módulo Supervisor Remoto de Transações, que permita a autorização de transações
pendentes, seu bloqueio e desbloqueio, de forma remota.
Todas as ações devem ser gravadas para auditoria.
7.3 IBK – INTERNET BANKING (PESSOA FÍSICA E JURÍDICA) E TELEBANCO
Deverá possuir cadastramento por CPF, de forma a permitir a operação de múltiplas contas.
O login deverá ser iniciado através da página inicial do BRB, que passará o CPF por parâmetro
para o canal, que deverá exibir as iniciais do nome do cliente na tela, juntamente ao Teclado
Virtual do BRB, onde será informada a senha para o prosseguimento do login.
As transações deverão ser autorizadas mediante uso do dispositivo de segurança utilizado pelo
Banco denominado Token, quando assim estiver definido no processo de negócio.
Deverá permitir a customização da página inicial pelo usuário.
Deverão ser exibidas apenas as funcionalidades à qual aquele usuário tem permissão de acesso,
tomando como base o perfil da conta e do tipo de usuário.
Após o login o usuário deverá visualizar os saldos de suas contas e os lançamentos futuros em
formato de abas. Deverá existir uma opção para que o usuário selecione a conta que deseja
operar e, só então, os menus devem ser carregados. O usuário poderá a qualquer tempo alterar
a conta a ser operada, sem a necessidade de efetuar login novamente.
Além do tipo de usuário titular, deverá existir outro que chamaremos de sub-usuário, que é um
terceiro não titular da conta, cujas permissões de acesso são definidas pelo titular, sendo
permitidas no máximo as mesmas opções do titular.
Quando uma transação for feita por um sub-usuário, o CEN deverá gravar a transação como
pendente.
Projeto Básico SUSIS/GENEG 2011/003 13

Quando uma conta for não-solidária as transações só poderão ser concluídas após a anuência
de um número mínimo de titulares com a permissão para a confirmação (sócios gerente, por
exemplo), sendo estes titulares definidos no cadastramento da conta no IBK, não podendo ser
em número inferior a 2.
As transações pendentes não poderão ser autorizadas por sub-usuário, devendo ser autorizadas
por usuário diferente do que a incluiu, até o horário limite para aquela transação no mesmo dia.
Se não autorizadas em tempo hábil, estas serão descartadas, mas deverão ser disponibilizadas
para consulta, com status que indique sua não-realização por falta da autorização.
Ao acessar a conta, caso existam transações pendentes de aprovação, deverá ser sinalizado
para o cliente.
Deverá existir um indicador por vinculação cliente/conta que indique se aquela ordem poderá
executar transações financeiras.
A disposição dos itens em tela (menus, banners, etc) devem ter fácil alteração, sem
necessidade de intervenção técnica.
Permitir a criação de enquetes personalizadas por tipo de cliente ou geral, com data de início e
fim.
Toda e qualquer tarefa administrativa a ser realizada para funcionamento desse canal deverá
ser feita dentro do Portal.
Deverá existir um módulo de comunicação através de mensagens, que permita ao Banco o
envio de mala-direta geral, por perfil ou ainda o envio de mensagens individualizadas, sejam
elas originadas pelo gerente da agência, pelo gestor do canal ou ainda pela área de marketing.
Permitir também que o cliente inicie a comunicação, enviando a mensagem para avaliação da
Central de Relacionamento, que dará o atendimento inicial, podendo encerrá-la ou encaminhá-la
para outras áreas, que visualizarão e poderão dar prosseguimento a sendo para tanto
necessária a criação de um workflow.
Possibilitar integração com a ferramenta de web-chat da DirectTalk.
Possibilitar integração com diversos simuladores (empréstimos, seguros, etc).
Possibilitar integração ao sistema de Ouvidoria e SAC, permitindo ao próprio cliente a geração
de ocorrências.
Permitir a veiculação de avisos para diferentes perfis e também avisos gerais.
Deverá gravar todos os passos feitos pelo usuário como forma de auditoria, permitindo a busca
dos detalhes da interação de cada evento entre o usuário e o sistema.
Permitir o encadeamento de processos. Ex.: Insuficiência de saldos durante uma transação
deve-se permitir, a critério do gestor, que haja encadeamento com determinada transação de
empréstimo, de forma parametrizável.
O Módulo Administrativo deverá possuir as funcionalidades de cadastramento de usuários do
próprio Módulo, cadastramento de contas/ordens autorizadas a movimentar, cadastramento de
usuários do Telebanco (Aplicativo CRBRB), cadastramento de telefones autorizados, Token, SMS
e contas pré-autorizadas para envio de TED/Doc. Possuirá também transações para consultas
diversas como extratos, e saldos e recibos, inclusive gerados nos diversos canais, auditoria,
busca de contas com filtros diversos, relatórios gerenciais, entre outros previstos para o canal
Módulo Administrativo do Banknet no Anexo 1 - RELAÇÃO DE FUNCIONALIDADES.
Projeto Básico SUSIS/GENEG 2011/003 14

O Aplicativo CR será responsável por fazer a interface entre a chamada telefônica repassada
pela URA/EAP e o operador, permitindo a este que faça transações financeiras ou não para
aquele cliente já autenticado. Esse aplicativo já existe atualmente e é desenvolvido em Delphi e
basicamente fará a escuta de determinada porta de comunicação à espera de um bilhete vindo
do EAP. Após o recebimento desse bilhete o Aplicativo oferecerá ao operador a possibilidade de
acatá-lo ou não. Se acatado, tal Aplicativo fará uma chamada ao Internet Banking, que
possuirá interface e código de canal diferenciados quando a origem for o Aplicativo CR, já
quando ocorrer a finalização da ligação na URA, a requisição do EAP deverá ser aceita e
automaticamente realizará a desconexão do aplicativo do operador. Possuirá também
transações com fluxos diferentes, tratáveis em nível de CEN, além de formas diferenciadas de
autenticação e autorização de transações. Deve possibilitar a integração junto ao Sistema de
Atendimento Virtual – SAV da Central de Relacionamento, a fim de que o operador possa
efetuar registro de solicitações do cliente autenticado.
Deverá permitir a leitura de código de barras por meio de leitoras CMC7.
Todas as ações devem ser gravadas para auditoria.
Implementar todas as funcionalidades especificadas para os canais Banknet, Telebanco e
Módulo Administrativo do Banknet no Anexo 1 - RELAÇÃO DE FUNCIONALIDADES deste
documento e GPW no Anexo 5 – Relação de Funcionalidades do GPW.
7.4 MBK – MOBILE BANKING
Interface gráfica intuitiva e amigável.
Solução que não tenha dependência da operadora ou que passe pela mesma de forma
transparente para o BRB.
Deverá permitir o login através de CPF e a mesma senha do Internet Banking.
Suportar autenticação através do cadastro do aparelho e/ou número do celular origem.
Todas as informações devem trafegar de forma segura, com padrão de criptografia a ser
definido pelo Banco.
Todas as transações, à exceção das consultas, deverão ser confirmadas com utilização da
senha do cartão bancário.
Deverá possuir ampla cobertura aos diversos aparelhos comercializados no mercado nacional.
Deverá funcionar pelo menos nos sistemas iPhone, Windows Mobile, Symbian, BlackBerry, Palm
OS, Pocket e Android, em suas versões mais recentes, mantendo compatibilidade com suas
versões anteriores, exceto se o suporte e atualização tenham sido descontinuados pelo
mantenedor do sistema operacional.
Deverá suportar também as plataformas Brew, J2ME e Wap (1.0 e 2.0).
Deverá dar suporte a dispositivos GSM e CDMA.
Prover acesso via browser do aparelho (wap), sem a necessidade de instalação de software.
Implantar todas as funcionalidades especificadas no Anexo 4. Relação de Funcionalidades do
Mobile Banking.
Todas as ações devem ser gravadas para auditoria.
7.5 MPY – MOBILE PAYMENT
Interface gráfica intuitiva e amigável.
Solução que não tenha dependência da operadora ou que passe pela mesma de forma
transparente para o BRB.
Permitir efetuar operações financeiras de pagamento através do dispositivo móvel, dispensando
o uso de cartões.
Permitir transações remotas ou por proximidade (tecnologia NFC – Near Field Communication).
Projeto Básico SUSIS/GENEG 2011/003 15

Suportar autenticação através do cadastro do aparelho e/ou número do celular de origem.
Todas as informações devem trafegar de forma segura, com padrão de criptografia a ser
definido pelo Banco.
Permitir a customização de transações permitidas, bloqueadas e valores máximo, tanto de
forma global, por perfil, quanto por cliente.
Deverá funcionar pelo menos nos sistemas IOS (iPhone, iPad, iPod e iPod Touch), Windows
Mobile (Pocket), Symbian, BlackBerry, Safari, Palm OS e Android, em suas versões mais
recentes, mantendo compatibilidade com suas versões anteriores, exceto se o suporte e
atualização tenham sido descontinuados pelo mantenedor do sistema operacional.
Deverá suportar também as plataformas Brew, J2ME e Wap (1.0 e 2.0), e versões superiores.
Deverá dar suporte a dispositivos GSM, CDMA e GPRS.
Prover acesso via browser do aparelho (wap), sem a necessidade de instalação de software.
Deverá suportar transações a débito em conta (on-line) ou a crédito para lançamento em fatura
de cartão.
O aplicativo de pagamento móvel deve ser amigável com o cliente leigo. O usuário deve ter
também a capacidade de personalizar o aplicativo de acordo com a sua conveniência.
Todas as ações devem ser gravadas para auditoria.
7.6 MSM – MOBILE SMART MESSAGE
Permitir transações de consulta e financeiras através de comandos previamente definidos pelo
Banco enviados por SMS.
Autenticação através de registro do aparelho e/ou número do telefone.
Permitir a customização de transações permitidas, bloqueadas e valores máximo, tanto de
forma global, por perfil, quanto por cliente.
Todas as ações devem ser gravadas para auditoria.
7.7 AUB – SISTEMA DE AUTOMAÇÃO BANCÁRIA – ATENDIMENTO, GERÊNCIA E
RETAGUARDA
Deverá possuir login através de usuário logado na rede, sendo autenticado de forma integrada
ao sistema gerenciador de acessos (SGA).
Deverá implementar as transações do Anexo 1 - RELAÇÃO DE FUNCIONALIDADES definidas
para o canal Vídeo, com suas regras definidas no CEN.
Deverá implementar, por meio do CEN, mecanismos de controle de alçadas, autorização de
transações por parte de supervisor.
Todas as ações devem ser gravadas para auditoria.
7.8 AAT - AUTOATENDIMENTO
Implementar a parte servidor das transações previstas para o canal Autoatendimento no Anexo
1 - RELAÇÃO DE FUNCIONALIDADES.
Tratar as mensagens ISO8583 vindas da ATM conforme manual de mensagens ISO utilizada
pelo Banco.
Para as operações do autoatendimento não serão utilizados metadados e nem repassado
comportamento do processo para o canal, visto que as operações são tratadas pela própria
empresa fornecedora do outsourcing.
Todas as ações devem ser gravadas para auditoria.
7.9 REX – REDES EXTERNAS
Projeto Básico SUSIS/GENEG 2011/003 16

Desenvolver as transações das redes externas descritas abaixo conforme manual específico de
cada rede.
• Visa;
• Mastercard;
• Banco24horas e Rede Compartilhada – Tecban;
• Compartilhamento do Banco do Brasil;
• Fidelity.
7.10 REC – REDES CONVENIADAS
Desenvolver interface de comunicação com os serviços descritos no Anexo 1 - RELAÇÃO DE
FUNCIONALIDADES com as seguintes redes conveniadas:
• Sefaz
• Ceb
• Caesb
• TJDFT
• DI2S
7.11 SAT – SISTEMA DE AGENDAMENTO DE TRANSAÇÕES
Aplicativo back-end com capacidade de agendar as transações efetuadas nos canais quando o
cliente informa uma data maior que a data corrente.
Possuir reconhecimento quando a data for final de semana e/ou feriado nacional ou local, de
acordo com o calendário estabelecido pelo BRB.
Disponibilizar consulta de transações agendadas, pagas e canceladas.
Deverá ser um módulo do CEN, devendo disponibilizar manipulação das informações para
inserção, atualização, exclusão e consulta através da mesma forma que o CEN proverá para as
demais funcionalidades, ou seja, utilizando-se de metadados, com processos definidos por BPM.
Permitir integração com os sistemas back-end para efetivar a transação na data pré-agendada.
Permitir agendamentos múltiplos, associados a um lote ou não.
Permitir a parametrização dos horários de integração com os sistemas de back-end, por canal,
transação, agência da conta e agência origem, permitindo também a inicialização da rotina de
forma manual a qualquer tempo.
As transações deverão ser processadas com base na parametrização citada no item anterior,
permitindo também repescagem até o horário limite para a transação. Em caso de transação em
lotes, o horário a ser seguido também deverá ser o parametrizado para a repescagem, porém
levando em consideração a transação cujo horário é o menor dentre as que compõe o lote.
Permitir para agendamento em lote que seja informado horário da execução, sendo que caso
seja informado, esse lote não entrará na rotina de repescagem.
Somente poderão ser cancelados os agendamentos, tanto individuais quanto em lotes, cujos
status estejam como “agendado”.
Agendamentos já efetivados poderão ser estornados por solicitação do cliente desde que sejam
documentos passíveis de estorno. Para lotes, permitir-se-á o estorno completo ou individual
daqueles lançamentos.
Integrar com o Provisionador de Saldos, de forma a deixar o saldo aprovisionado na conta do
cliente para garantia da efetivação da transação, desde que não seja agendamento em lote com
horário pré-definido, cuja responsabilidade quanto aos saldos será do cliente.
Os agendamentos realizados deverão gerar seus recibos na base única de recibos do CEN.
7.12 FLT – FLUXO DE TEDs
Projeto Básico SUSIS/GENEG 2011/003 17

Integrar com o sistema de mensageria do SPB (MSG), através de biblioteca própria do MSG.
Deverá ser capaz de trabalhar com máquina de “status”, de forma a tratar cada requisição
individualmente, permitindo mensagens diferenciadas para cada uma, tanto para TEDs enviadas
como recebidas.
Deverá permitir o tratamento de confirmação de envio de TED’s.
Deverá permitir a integração com o CEN de forma a possibilitar a validação de informações e
também efetivação da transação financeira, no caso de TED recebida ou busca de TEDs a enviar
para processamento.
Deverá permitir o acatamento de mensagens vindas do MSG sem que ocorra travamento da fila,
ou seja, mesmo que a mensagem seja inválida, esta deverá ser acatada pelo FLT, que possuirá
um serviço que validará a mensagem e prosseguirá com o tratamento.
Deverá permitir o armazenamento versionado do Catálogo de Mensagens do SPB, em forma de
metadados armazenados no CEN. Deverá permitir a criação de nova versão do catálogo de
forma interativa por parte do gestor, podendo reaproveitar mensagens, criar novas ou alterar
outras, com o menor esforço possível.
Permitir a consulta de mensagens para versões anteriores do Catálogo.
Criar-se um módulo de gestão, integrado ao MMC, que permita monitorar o envio e recebimento
de mensagens. Esse módulo deverá permitir consultas unitárias e totalizadas, por período,
canal, conta, status, mensagem ou outros filtros definidos pelo Banco.
O módulo gestor deverá permitir a alteração de informações da mensagem, de forma a permitir
o reprocessamento daquelas que tenham sido recebidas com alguma inconsistência.
Deverá ser permitida a alteração da disponibilidade do canal de TEDs, seja para envio ou para
recebimento, de forma interativa, a nível de canal, perfil de cliente, PA, horário e data.
Deverá permitir a geração manual de TEDs através do módulo gestor.
Permitir a geração periódica ou eventual de relatórios em tela ou geração de arquivos para
integração com outros sistemas, em formato a ser definido pelo Banco.
7.13 MMC – MONITOR DO MULTICANAL
Deverá monitorar a disponibilidade de todos os canais, sistema SIA, CEN, GAB, serviços,
barramento de comunicação. Permitir o cadastramento de novos serviços a serem monitorados
de forma parametrizável.
Monitorar o volume transacional em tempo real por canal, CEN, volume de mensagens no
barramento, por terminal, armazenando as informações em base de dados a ser definida pelo
Banco, exibindo-as em forma numérica e gráficos, além de gerar alertas em tela, por e-mail e
SMS (integrando ao sistema de envios de SMS), com base em métricas parametrizáveis de
forma a identificar queda elevada no movimento e índice acima do esperado no número de
erros. Deverá permitir a consulta por data e horário, filtrando ou não por canal, conta, cartão,
resposta do sistema e transação.
Deverá possuir interface web, utilizando os preceitos já definidos nos itens gerais.
Monitorar os programas de alta plataforma que integram com a automação bancária, exibindo
status de habilitação, fila e número de mensagens, classificando-os em ativo, em fila, fila crítica
ou desabilitado, gerando alertas tais quais previstos no item 2.
Possuir integração com o sistema SGA, armazenando informações de acessos e consultas,
permitindo sua auditoria.
7.14 CON – CONCILIAÇÂO
Projeto Básico SUSIS/GENEG 2011/003 18

O CON deverá ser capaz de realizar conciliações tais como Visa, Master, Tecban,
Autoatendimento modelo outsourcing, Compartilhamento BB, conforme regras definidas por
essas redes, devendo cada conciliação gerar informações em tempo real da situação de cada
arquivo, devendo ser possível ao gestor ter visibilidade macro, porém com possibilidade de
aumentar a granularidade do detalhe a ser observado.
Deverá, também, possuir integração com o MMC, de forma a alarmar qualquer inconformidade.
Deverá ser criado também no CON um Módulo Gestor para o Compartilhamento BB, integrado à
rotina de conciliação desta rede, de forma a permitir ao gestor a realização de contestação de
transações, bem como o acatamento de contestações realizadas por aquele Banco.
Deve ser possível estender esse módulo gestor para as outras redes, se necessário.
7.15 SIA – SISTEMAS DE INFRAESTRUTURA DA AUTOMAÇÃO BANCÁRIA
7.16 BASE DE DADOS
Criar e manter base de dados de dados financeiros e de consulta/cadastro que serão utilizados
para a autorização de transações. Essa base de dados será gerenciada única e exclusivamente
pelo CEN. Ou seja, somente processos do CEN poderá executar inserção, alteração, exclusão e
consulta neste banco de dados.
O modelo de dados deverá ser criado e normalizado a partir de layout dos arquivos .TXT
utilizados atualmente pelo BRB. A lista de arquivos que serão carregados para banco de dados
está presente no anexo 4 deste documento.
O modelo de dados deverá ser validado pela área de administração de dados do BRB.
Os arquivos .TXT são gerados pelos sistemas legados e disponibilizados quase que diariamente
para a automação bancária. Obedecendo essa regra deverá ser criado um mecanismo de carga
destes arquivos, não normalizados, para o ambiente de banco de dados, normalizado.
O processo de carga deve ser inserido no MMC – Monitor do Multicanal.
Praticamente todas as transações da automação bancária geram log. Esse log deve ser
armazenado em tabela própria no mesmo banco de dados do SIA.
Criar um serviço responsável por realizar a subida on-line dos logs do banco de dados do SIA
para a alta plataforma obedecendo layout de comunicação definido pelo BRB.
Criar um processo no CEN que permita o atual Método de Acesso da automação bancária
realizar todas as suas operações atualizando essa base de dados. Dessa forma, o Método de
Acesso será apenas um roteador das transações dos atuais canais da automação bancária
permitindo a migração da estrutura antiga para a solução de Multicanal.
7.17 PROCESSADOR DE DÉBITOS E CRÉDITOS
Projeto Básico SUSIS/GENEG 2011/003 19

Criar um processador responsável por receber arquivos financeiros dos sistemas legados e
processá-los diretamente na base de dados do SIA. Esses arquivos são em formato .TXT.
O processador deve utilizar layout definido pelo BRB.
Os arquivos recebidos em diretório específico deverão ser carregados no banco de dados do
SIA. Após carregar o arquivo no banco de dados uma procedure deverá buscar os registros não
processados e atualizar a tabela financeira do MAC.
Gerar arquivo retorno obedecendo layout estabelecido pelo BRB.
Todos os status dos arquivos e de cada registro deste arquivo devem ser registrados no MMC.
Esse processo abrange desde a disponibilização do arquivo em diretório específico, passando
pela importação do arquivo para banco de dados, pelo processamento dos registros, até a
geração e envio do arquivo retorno para o sistema legado.
O processador deve ser capaz de processar vários arquivos simultaneamente.
O processador deve ser capaz de processar milhares de registros em poucos minutos permitindo
assim que o BRB possa trabalhar com créditos e débitos quase que on-line. Assim sendo o
serviço que carregará os arquivos em banco de dados deverá ser capaz que realizar a carga de
um arquivo com, por exemplo, 100.000 registros, em menos de 10 minutos. Após carregar
esses registros o outro processo que atualizará o arquivo financeiro deverá ser capaz de
processar todos esses registros nos mesmos 10 minutos. O terceiro e último processo
responsável pela geração do arquivo retorno terá, no máximo, mais 10 minutos para concluir a
geração e envio deste arquivo. Com isso, o tempo total de processamento de um arquivo com
100.000 registros será de 30 minutos.
O processador deverá funcionar em 24X7.
O processador não poderá permitir que o processamento de um arquivo seja iniciado em D0 e
concluído em D+1.
Projeto Básico SUSIS/GENEG 2011/003 20

IBK
Internet
Banking e
Telebanco
GAB
Módulo
de
Gerenciamento
CIX
Caixa e
Correspondente
CEN
Centralizador
E
Autorizador
Desenho da solução Multicanal
MBK
Mobile
Banking
BARRAMENTO
CON
Conciliação
MMC – Monitor do Multicanal
AUB
Sistema de
Automação
Bancária
SAT
Sistema
De
Agendamentos
SIA – Sistema de Infraestrutura da automação
LEGADO
BAIXA
PLATAFORMA
BARRAMENTO
LEGADO
ALTA
PLATAFORMA
MPY
Mobile
Payment
FLX
Fluxo
De
TEDs
MSM
Mobile
Smart
Message
AAT
Auto
Atendimento
REX
Redes
Externas
REC
Redes
Conveniadas
Projeto Básico SUSIS/GENEG 2011/003 21

8 ADAPTAÇÃO DA SOLUÇÃO AO NEGÓCIO BRB
A emissão do termo de aceite será dada por módulo entregue e ocorrerá, em até 05 (cinco) dias
úteis, após a homologação do referido módulo adaptado às características e serviços descritos
nos itens deste Projeto Básico.
Auxiliar o BRB na validação dos dados, desempenhando as atividades necessárias de detecção
de erros tanto nas bases recebidas como nos programas de migração.
Construir os programas de migração conversores de logs, arquivos, base de dados, e demais
arquivos de houverem, quando necessário, da atual solução de automação bancária do BRB
para o modelo de dados proposto pela Contratada e validado pela área de Tecnologia do BRB.
Preparar os testes da solução de Multicanal com as equipes de homologação de processos do
BRB.
Executar as atividades de escrever, corrigir, compilar, testar em seu ambiente, e encaminhar
para a homologação os softaware integrantes da Solução utilizando o link de comunicação
disponibilizado pelo BRB, que conecta o ambiente de desenvolvimento da contratada ao
ambiente de desenvolvimento BRB, para envio dos serviços executados da Solução de
Multicanal adaptado ao Negócio BRB.
Obs: Esse link de comunicação ficará ativo até 1 mês após a implantação do último pacote de
módulos, canais e serviços.
Desenvolvimento/Manutenção durante a fase de adaptação da Solução de Multicanal (sob
demanda).
A transferência de Tecnologia ocorrerá durante todo o período de vigência do contrato.
8.1 Obrigações da CONTRATADA
Realizar e cumprir acordo de nível de serviço entre as partes para a Transferência da Tecnologia
durante a execução das fases do Contrato.
Realizar reuniões técnicas e/ou gerencias de Ponto de Controle, mensalmente, ou quando
houver necessidade e prestar esclarecimentos às equipes do BRB sobre questões relativas a
documentação e a implementação da solução – Adquirida e Adaptada.
Formatar e fornecer o conteúdo da Transferência de Tecnologia utilizando os instrumentos
conceituais descritos na tabela abaixo.
ANÁLISE ORIENTADA A OBJETO
a) Modelo de Entidade e Relacionamento - Dados
b) Dicionário de Dados
c) Diagrama de Classes
d) Diagrama de Casos de Uso
e) Casos de Uso do Projeto
f) Diagrama de Sequência
g) Ambiente de Hardware e Software
CÓDIGOS FONTE
a) Camada de Apresentação
b) Camada de Aplicação – descrevendo o objetivo da aplicação e arquivos utilizados
c) Camada de Dados
MANUAL DE PRODUÇÃO
a) Fluxos de produção
b) Especificação básica das rotinas operacionais
MANUAL DE USUÁRIO
a) Apresentação resumida do sistema
b) Modelo de Preenchimento dos documentos e arquivos para processamento
c) Tratamento e resultado gerado em cada uma das fases do sistema
d) Descrição de rotinas por ambiente
Projeto Básico SUSIS/GENEG 2011/003 22

e) Relatórios do sistema
f) Informação de Central de Atendimento ao Cliente
g) Tabela de apoio (parâmetros do sistema)
Instalar a solução do Multicanal Adaptada nos ambientes de Desenvolvimento, Homologação de
Processos e de Produção do BRB.
8.2 TREINAMENTOS
Os treinamentos ocorrerão, na cidade de Brasília, somente após o aceite formal do BRB sobre a
solução do Multicanal adaptado.
Deverá ser ofertado, sem ônus adicional à CONTRATANTE, treinamento para capacitação inicial
de até 30 (trinta) pessoas sobre a instalação, utilização e adaptação do produto para as
aplicações alvo, a ser realizado em datas e horários a serem definidos pelo CONTRATANTE, em
suas dependências, em número de turmas a ser definido pelo CONTRATANTE, sendo mínimo de
5 (cinco) participantes e no máximo a capacidade de lotação da dependência que o
CONTRATANTE designar para tal treinamento ou, a critério da CONTRATADA, limitar o número
máximo de participantes de forma a manter a qualidade do treinamento. Esse treinamento
deverá ser ministrado até 20 dias antes da entrega final do primeiro pacote.
Poderá ser requisitado pelo CONTRATANTE por até 4 (quatro) vezes durante a vigência do
contrato, desde que com aviso prévio de 60 (sessenta) dias e também sem ônus ao
CONTRATANTE, treinamento de outras pessoas, em turmas de no mínimo 5 (cinco) participantes
e no máximo a capacidade de lotação da dependência que o CONTRATANTE designar para tal
treinamento, limitadas cumulativamente à outras solicitações ao total de 20 (vinte) pessoas,
não sendo cumulativo entretanto ao treinamento inicial de até 30 (trinta) pessoas.
O CONTRATANTE poderá, a seu critério, acatar sugestões da CONTRATADA para alteração no
local, data, horário e capacidade das turmas do treinamento, desde que respeitado o número
máximo de pessoas previsto para o treinamento durante a vigência do contrato.
É prerrogativa do CONTRATANTE, por sua exclusiva conveniência, determinar que esses
treinamentos sejam realizados em local e com recursos a serem oferecidos pela CONTRATADA.
9 REMUNERAÇÃO
A remuneração será por fase do projeto e ocorrerá 20 dias após a implantação da fase. Essa
remuneração será composta da seguinte forma:
Remuneração: (custo do módulo/canal adaptado) + (custo do desenvolvimento das
funcionalidades do canal previstas no anexo 1)
O custo do módulo/canal a engloba a adaptação de todos os requisitos gerais e específicos
descrito neste projeto básico para o referido módulo/canal, com exceção das funcionalidades
descritas no anexo 1. O preço do módulo/canal será fixo.
A construção das funcionalidades daquele módulo/canal constantes no anexo 1 será feita pela
equipe técnica da CONTRATADA. A remuneração neste caso se dará através da contagem de
PONTOS DE FUNÇÃO conforme regras definidas no item 9.1 deste projeto básico.
Projeto Básico SUSIS/GENEG 2011/003 23

Aquisição Módulo/Canal Funcionalidades (Ponto
Adaptado
de Função)
PRIMEIRA FASE
CEN – Centralizador Sim Não
GAB – Módulo geral de gerenciamento do Sim
multicanal
Não
MMC – Monitor do multicanal Sim Sim
IBK – Internet Banking e Telebanco Sim Sim
MBK – Mobile Banking Sim Sim
SIA – Sistemas de infraestrutura da Não
automação bancária
SEGUNDA FASE
Sim
CIX – Caixa Agência e Correspondente Sim Sim
AUB – Sistema de automação bancária Sim Sim
AAT – Autoatendimento Não Sim
REX – Redes Externas Não Sim
REC – Redes Conveniadas Não Sim
CON - Conciliação
TERCEIRA FASE
Sim Não
SAT – Sistema de Agendamento de Sim
transações
Sim
FLX – Fluxo de TEDs
QUARTA FASE
Sim Sim
MPY – Mobile Payment Sim Sim
MSM – Mobile Smart Message Sim Sim
9.1 PERCENTUAL DE REMUNERAÇÃO PARA PROJETOS COM PONTOS DE FUNÇÃO.
O custo do ponto de função será um dos fatores determinantes para a escolha da empresa
vencedora do certame.
Conforme sinalizado no item 4.4 os atuais sistemas de automação bancária não possuem uma
documentação que permita uma estimativa de pontos de função necessários para a construção
das funcionalidades no centralizador e adequação do canal para estas funcionalidades.
Como critério para estimar a quantidade de pontos de função será adotar a mesma quantidade
prevista no contrato de prestação de serviços DIRAD/DESEG-2011/005 que trata da
manutenção dos sistemas de automação bancária e de escritório.
Nesse contrato são previstos 4.200 pontos de função para um período de 12 meses.
Para a solução de multicanal será adotada a seguinte escala:
FASE DURAÇÃO DA FASE QTD. PONTOS DE FUNÇÃO
PRIMEIRA FASE 6 MESES 2100
SEGUNDA FASE 6 MESES 1050
TERCEIRA FASE 6 MESES 525
QUARTA FASE 6 MESES 260
Como a solução multicanal prevê o reutilização de processos então a tendência é que as outras
fases utilizem uma quantidade menor de pontos de função para a implementação das
funcionalidades.
A contagem de Pontos de Função será efetuada no repasse dos serviços (Contagem Estimativa)
e na conclusão dos serviços (Contagem Final) pela Contratada, cabendo ao BRB efetuar a
validação dessas contagens. Esses serviços ou funcionalidades estão descritos no anexo 1.
Projeto Básico SUSIS/GENEG 2011/003 24

A contagem de Pontos de Função será baseada na metodologia descrita no Manual de Praticas e
Contagens (Counting Practices Manual Release 4.2), publicado pelo IFPUG (International
Function Point Users Group), em 2005 ou a que for vigente a época da contratação.
A especificação de requisitos é de obrigação exclusiva da CONTRATADA. Essa especificação será
realizada através de entrevistas e reuniões com os gestores de negócio do BRB e com a equipe
técnica da área de informática do BRB.
A contagem estimativa de Pontos de Função será efetuada pela Contratada após a captura dos
requisitos junto ao BRB. A contagem estimativa, poderá ser feita de acordo com as técnicas de
contagem estimativa definidas pela NESMA - Netherlands Software Metrics Users Association, a
critério da Contratada desde que ela informe a metodologia utilizada em cada caso.
Caso ocorram alterações sobre os requisitos do sistema, objeto dos serviços de mensuração, no
período de execução desses serviços, ficará caracterizada mudança de escopo, devendo ser
reavaliada a dimensão dos serviços para efeito do faturamento.
A distribuição percentual de Pontos de Função por fase do processo de desenvolvimento de
aplicativos adotada pelo BRB e apresentada na tabela abaixo.
Fases % de Distribuição
Definição do Sistema 3%
Especificação de Requisitos 13%
Elaboração do Modelo Lógico 11%
Elaboração do Projeto Detalhado 28%
Construção 34%
Integração e Homologação 7%
Implantação 4%
Caso haja divergências iguais ou superiores a 5% entre o BRB e a Contratada em relação as
contagens de pontos de função do serviço efetuado, representantes do BRB e da Contratada
deverão se reunir para resolver as divergências. Caso as divergências sejam inferiores a 5%,
prevalecerá a contagem arbitrada pelo BRB.
A Contratada após fazer a contagem detalhada, disponibilizará o resultado em conjunto com a
documentação dos fatores que embasaram a contagem. A critério do BRB pode ser solicitada a
Contratada documentação adicional para a validação da contagem.
No caso de haver alteração de escopo, após a estimativa, deve ser gerado um documento
contendo dados que registrem a alteração de escopo e uma avaliação comparativa da
precificação antes e depois da alteração, enfatizando o impacto decorrente da alteração.
Todos e quaisquer produtos desenvolvidos pela Contratada para a execução dos serviços objeto
deste projeto básico, serão de propriedade do BRB, incluindo-se arquivos em meio magnético,
códigos fonte, códigos executáveis, documentação e outros gerados no contexto dos serviços.
O desenvolvimento das funcionalidades devem cumprir os prazos previstos no item 2.
Para o desenvolvimento das funcionalidades a CONTRATADA deverá gerar os artefatos previstos
no item 5.5.
10 PADRÕES DE SEGURANÇA
Os empregados da CONTRATADA terão acesso ao ambiente BRB, respeitados os padrões de
Projeto Básico SUSIS/GENEG 2011/003 25

Controle de Acesso Lógico e Sistemas Computacionais.
11 CONECTIVIDADE
Será disponibilizada para e empresa CONTRATADA a conectividade ao ambiente de
Desenvolvimento do BRB que processará a solução de Multicanal, no sites de contingência
localizados no SIG – Setor de Indústrias Gráfica e no SCN – Setor Comercial Norte.
O acesso será feito pela Extranet do BRB e da CONTRATADA, com todos os recursos
tecnológicos inerentes a esse tipo de ambiente (DMZ), considerado altamente critico, como
exemplo: Filtros em roteadores, uso de Firewall, Software de detecção de intrusão, Antivírus,
Serviços de FTP segregados, onde haverá a autenticação dos empregados da empresa
CONTRATADA.
Pode ser necessária a utilização de recursos de NAT (Network Adress Translation) no ambiente
da empresa que se autenticará na Extranet, a critério do BRB.
Após a autenticação ma Extranet do BRB, a empresa terá acesso aos sistemas de acordo com a
necessidade dos serviços.
A conectividade detalhada neste item será utilizada pela empresa CONTRATADA para transmitir
ao BRB os códigos fonte das Adaptações, Desenvolvimento e Manutenções efetuadas.
Projeto Básico SUSIS/GENEG 2011/003 26

12 ANEXOS
12.1 Anexo 1 – Relação de Funcionalidades
Projeto Básico SUSIS/GENEG 2011/003 27

12.2 Anexo 2 – Sistemas e Serviços Descontinuados:
• ABA e AbaAdmin: Aplicativo de Vídeo utilizado em Pontos de Atendimento e Áreas da
Direção Geral relacionadas com rotinas operacionais e seu Módulo Administrador.
• ABX: Autorizador utilizado pelo autoatendimento e para outras funcionalidades de outros
canais eletrônicos.
• APB: Utilizado para envio e recebimento de TED’s, através das diversas mensagens
previstas no SPB.
• ATB: Aplicativo de Caixa – Agências e Pabs.
• ATC: Aplicativo de Caixa – Correspondentes não Bancários.
• BKT/TLB: Internet Banking e BRB Telebanco.
• Gateway ABX: Gateway para envio das requisições ao ABX.
• Gateway CBR: Gateway para comunicação com os sistemas CBR, CHM e APS.
• Gateway SadsXP: Utilizado para comunicação com sistemas do BRB02 em plataforma
intermediária – Entre o Mainframe e Baixa Plataforma.
• Gateway Sefaz: Utilizado na comunicação do ABX com a Sefaz para informações sobre
IPTU e IPVA.
• Gateway Redes Externas: Em ambiente DMZ interagindo com o HRX para redes externas
e autoatendimento.
• Gateway URA: Utilizado na comunicação da URA com o ABX.
• GPW: Gerenciador de Pagamentos WEB para Pessoa Jurídica.
• HRX: Utilizado para redes externas e conciliações.
• PRJ Monitor/MON: Utilizado na monitoração da automação bancária.
• PTL: Portal utilizado para gerenciamento do Internet Banking.
• Serviço de Busca em Traces: Utilizado para consulta aos traces gerados pelo ABX.
• Roteador TCP: Utilizado para roteamento de mensagens entre ABX e CEB.
• SIA – Sistema de Infraestrutura da automação bancária e Método de Acesso.
Projeto Básico SUSIS/GENEG 2011/003 28

12.3 Anexo 3 – Arquivos do Método de Acesso
Tabela Descrição
• AGE Tabela de agências
• ARU cadastro de arrecadações unificado
• ASB Bancos Interligados à ASBACE - Rede Verde/Amarela
• BNF Arquivo Financeiro de INSS
• BNS Arquivo de controle de movimentações em conta para sincronismo com o arquivo
de carga do BNF. Delta do BNF
• CCA Arquivo financeiro de Contas Corrente e Contas Investimento
• CCS Arquivo de controle de movimentações em conta para sincronismo com o arquivo
de carga do CCA. Delta do CCA
• CDA Cadastro de empresas conveniadas para débito automático
• CDG Cadastro de códigos de transação
• CEC Cadastro das características dos produtos. Não é utilizado mais
• CHS Cadastro de cheques sustados
• CLT Cadastro de clientes
• CNT Cadastro de contas
• CRG Arquivo de controle da carga dos arquivos
• CTM Cadastro de cartões magnéticos
• CTS Arquivo de controle de movimentações em conta para sincronismo com o arquivo
de carga do CTM. Delta do CTM.
• DET Arquivo utilizado para guardar dados do Detran nas consultas de débitos
• DRF Arquivo de cadastro de empresas para recebimento de DARFs
• DPS Arquivo de Cadastro do Ponto de Atendimento. Possui apenas as agências de cada
SuperAgência. Equivale às agências cadastradas no LSTPTASUPER.ini
• FAP Saldo de fundos de aplicação
• FCC Faixa de códigos de clientes e faixa de depósitos
• FER Cadastro de feriados locais e nacionais
• FFA Cadastro de fundos de aplicação
• FIN Cadastro da finalidade da conta. Utilizado para impressão de nome diferente do
cliente em folhas de cheques
• FXD Faixas de depósito de produtos
• GCO Cadastro de gerentes de contas
• GPS Cadastro dos códigos de pagamento permitidos para GPS
• IDC Cadastro de identificadores de conta. Utilizado para Depósito Judicial pelo APB em
consulta ao ABX
• INE Índices econômicos
• LOG Logs do movimento diário da automação
• LOX Logs do movimento diário da automação. Apenas transações utilizadas para
relatórios e/ou extrações
• LPA Cadastro de limites de pré-aprovado
• LPD Logs de pendência de transações de destino
• LPO Logs de pendencias na origem
• MON Logs utilizado para a Monitoração da Automação
• NIF Arquivo de controle da última Agência utilizada
• OPS Cadastro de operadores
• PPA Arquivo financeiro de conta poupança
• PPS Arquivo de controle de movimentações em conta para sincronismo com o arquivo
de carga do PPA. Delta do PPA
• PRM Arquivo de parâmetros dos sistemas da automação
• PRO Arquivo de cadastro de profissões
• RCC Arquivo de relacionamento entre conta corrente e código do cliente
• ORG Cadastro de órgãos pagadores
Projeto Básico SUSIS/GENEG 2011/003 29

• TCP Cadastro de tipos de contas
• TPC Cadastro das praças de compensação
• TSI Arquivo de relacionamento entre a praça de compensação e o Sirc
• SRV Cadastro dos trancodes de mensagens
Projeto Básico SUSIS/GENEG 2011/003 30

12.4 Anexo 4 – Relação das funcionalidades previstas para o Mobile Banking
MOBILE BANKING
• Saldo de Conta Corrente
• Saldo de Poupança
• Saldo de Poupança Integrada
• Extrato de Conta Corrente
• Extrato de Poupança
• Extrato de Poupança Integrada
• Extrato de Cheques Compensados
• Extrato de Lançamentos Futuros
• DDA – Título Eletrônico
• Títulos do BRB
• Títulos de Outros Bancos
• Tarifas Públicas/Privadas e Impostos
• Fatura de Cartão BRB (pelo número do cartão)
• Cancelamento de pagamento no dia
• Cancelamento de agendamentos
• Transferência entre contas do BRB
• Aplicação em fundos de investimento
• Resgate parcial em fundos de investimento
• Resgate total em fundos de investimento
• Cancelamento de aplicação/resgate
12.5 Anexo 5 – Relação das funcionalidades previstas para o GPW
• GPW
• Abertura de conta salário
• Pagamento de salário em lote
• Pagamento de fornecedores
• Folha de pagamento por arquivo
• TED em lote
• Pagamento de títulos em lote
• Pagamento de títulos on-line
• Crédito Consignado
• Contracheque no Auto Atendimento
Projeto Básico SUSIS/GENEG 2011/003 31

13 GLOSSÁRIO
Acordo de níveis de serviços – ANS
São acordos firmados para identificar a performance dos serviços, por meio de indicadores
mensuráveis e procedimentos de execução de atividades entre as partes.
Agência Origem
Agência onde foi realizada a transação.
Agendamento
Lançamento financeiro para data futura.
Ajax
Acrônimo em língua inglesa de Asynchronous Javascript and XML, que é o uso metodológico das
tecnologias Javascript e XML, para tornar as páginas web mais interativas com o usuário,
utilizando-se de requisições assíncronas de informações ao servidor, ou seja, sem a necessidade
de submeter a página por completo, o que provê ganhos substanciais em performance dentre
outros itens favoráveis.
Ambiente de Desenvolvimento
Ambiente de desenvolvimento e implementação de regras de negócio, para validação dos
serviços solicitados.
Ambiente de Homologação
Ambiente de testes e validação dos serviços solicitados, para posterior disponibilização em
ambiente de produção, utilizando massa de testes gerada pelo Gestor.
Ambiente de Produção
Ambiente onde se encontram as bases de produção e onde são executados os programas de
sistemas batch e on-line já homologados e aceitos.
Análise de Pontos de Função
Método padrão para mensuração de desenvolvimento de software, do ponto de vista do usuário.
(IFPUG – International Function Point Users Group).
Annotations
Recurso da Plataforma Java desenvolvido a partir de sua versão 1.5, que permite o uso de
metadado ao longo do código para posterior interpretação por um compilador, para então
executar uma tarefa pré-definida. Evita, em muitos casos, a criação de arquivos XML de
configuração, que dificultam a compreensão e manutenibilidade do sistema. Ajuda também na
automatização de algumas tarefas, como o mapeamento de persistência com o banco de dados
e a geração de web-services.
API
Application Programming Interface (ou Interface de Programação de Aplicações) é um conjunto
de rotinas e padrões estabelecidos por um software ou hardware, para a utilização de suas
funcionalidades por programas aplicativos, de forma a não necessitar envolvimento em detalhes
de implementação de software, além de otimizar o prazo, evitando redesenvolvimento de
soluções.
Aplicativo CR
Aplicativo desenvolvido em Delphi que consiste em interface de comunicação socket do lado
cliente, que fica aguardando requisições vindas do EAP. Essas requisições informam sobre o
atendimento de um novo cliente e, se acatado pelo operador, gerarão o acesso a um endereço
web dentro de um dos web-browsers do Aplicativo. Permite também a simulação de
recebimento de bilhetes.
ATM
Sigla inglêsa para designar Automatic Teller Machine, que nada mais é que um caixa eletrônico.
Backlog
É utilizado para designar uma lista de espera para ações, em geral demandas ou atividades,
com prioridades definidas.
Banco do Brasil
Instituição financeira brasileira com a qual o BRB mantém acordo para compartilhamento de
rede de ATM’s.
Banco24horas
Rede de ATM’s mantida pela empresa Tecban que é compartilhada por diversas instituições
bancárias.
Projeto Básico SUSIS/GENEG 2011/003 32

Barramento de Serviços
Nome utilizado para designar onde os canais serão conectados para acesso a funcionalidades ou
roteamento de mensagens. É por onde passarão todas as requisições da nova solução.
Barramento 32 e 64 bits
Refere-se à dimensão dos registradores internos de um processador, que irá definir com
quantos bits por vez esse processador trabalhará. Atualmente utilizam-se 32 e 64 bits.
BB
Ver Banco do Brasil.
BPM
Gerenciamento do Processo de Negócio (em inglês Business Process Management). É um
conceito que reúne gestão de negócios e tecnologia da informação, com foco na otimização do
resultado da organização, por meio da melhoria dos processos de negócio, através de métodos,
técnicas e ferramentas que permitam analisar e modelar o processo de negócio, tendo reflexo
imediato em ambiente tecnológico. As ferramentas que permitem a customização dos processos
sem intervenção em códigos fontes, são denominadas de sistema de gestão de processos de
negócio (BPMS).
Bug
Erro no funcionamento comum de um software, causando discrepâncias no objetivo ou
impossibilidade de realização da ação desejada.
Caesb
Companhia de saneamento ambiental do Distrito Federal. Empresa pública com a qual o BRB
mantém parceria para prestação de serviços, atualmente no autoatendimento.
Container
Em programação, traduz-se como um objeto que contém outros objetos, podendo estes serem
incluídos ou removidos dinamicamente.
Canal
Nomenclatura utilizada para designar canais de atendimento, que são os meios de interação
com o cliente, seja por intermédio de um operador autorizado pelo Banco, ou seja de forma
eletrônica.
Cartão BRB
Empresa de cartões do grupo conglomerado BRB.
CEB
Companhia Energética de Brasília. Empresa pública a qual o BRB mantém parceria para
prestação de serviços, atualmente no autoatendimento.
Cielo
Empresa brasileira (antiga Visanet) responsável pela captura e transmissão de transações com
cartões de crédito e débito.
Cliente
Aquele que se relaciona com o banco de qualquer forma, seja como correntista, poupador,
beneficiário INSS ou beneficiário de programas sociais, por meio da utilização de serviços como
agendamentos, pagamentos, depósitos ou serviços de entidades parceiras.
Cluster
É um conjunto de computadores que utiliza um sistema operacional configurado de forma
especial a trabalhar como um sistema distribuído. Em nosso contexto, trata-se de dois tipos, a
saber: Cluster de alta disponibilidade: permite a permanência do sistema ativo por longos
períodos de tempo e em plena condição de uso. Cluster de balanceamento de carga: tem função
de controlar a distribuição equilibrada do processamento.
CNAB240
A sigla CNAB provem de Centro Nacional de Automação Bancária (atual Ceneaban), que é um
núcleo da Febraban responsável por padronizar normas e leiautes das cobranças eletrônicas. O
CNAB240 é um padrão para intercâmbio de informações entre bancos e empresas.
Código Fonte
Código original de um aplicativo desenvolvido utilizado para geração e atualização das versões
do mesmo.
Conta
É um produto oferecido pela instituição financeira que pode ser de vários tipos, sendo os mais
comuns conta corrente e poupança.
Projeto Básico SUSIS/GENEG 2011/003 33

Delphi
IDE fornecida pela empresa Embarcadero (antiga CodeGear, Inprise ou Borland) para
desenvolvimento na linguagem (Object) Pascal.
DI2S
Nome fantasia da Empresa Data Interchange Information Solutions, detentora da Tecnologia de
veiculação de Torpedos e Mensagens, contratada pelo BRB para o envio de mensagens de email
e SMS por demanda.
DMZ
DeMillitarized Zone ou “zona desmilitarizada”. A DMZ é uma rede situada entre uma rede
confiável e uma não confiável, com função de manter todos os serviços que possuem acesso
externo separados da rede local, limitando assim o potencial de dano em caso de
comprometimento de algum destes serviços por um invasor.
DirectTalk
Empresa contratada pelo BRB para fornecimento de solução de web-chat, que permite o contato
de clientes de um determinado perfil, com atendentes e gerentes do BRB, por meio de chat.
EAP
Componente lógico da Unidade de Resposta Audível – URA, classificado como Gateway,
responsável pela validação das informações do cliente nos Sistemas do BRB, para o
direcionamento das ligações entrantes para determinada cabine, contendo as informações
financeiras e cadastrais do cliente.
Estorno
Cancelamento de uma ação.
Enfileiramento
Quando há requisições a um sistema ou programa, que gera gargalhos no tratamento dessas
requisições.
Fidelity
Empresa que administra a função de crédito dos cartões do banco, além de ser responsável pela
geração do plástico.
Fila
Denomina-se fila a quantidade de requisições a aguardar tratamento.
Fila Crítica
Chamamos fila crítica quando um enfileiramento toma grandes proporções.
Framework
Também referenciadas na literatura como arcabouço. É um conjunto de classes implementadas
em uma linguagem específica, usadas para auxiliar o desenvolvimento do software.
Freeware
É qualquer programa de computador, cuja utilização não implica o pagamento de licenças de
uso ou royalties para seus idealizadores.
Gateway
Ponto intermediário em uma comunicação geralmente destinado a interligar redes, separar
domínios ou traduzir protocolos. Também chamado de porta de ligação.
GED
Gerenciador Eletrônico de Documentos. Software utilizado para gestão eletrônica de
documentos, que prevê a geração, controle, armazenamento, compartilhamento e recuperação
de informações existentes em documentos, de forma ágil e segura, sendo possível a geração de
workflow, para controle do fluxo desses documentos.
Gestor
Usuário ou área do banco responsável pela gestão técnica, funcional ou negocial do sistema ou
produto.
Hibernate
Framework open source de mapeamento objeto-relacional para linguagem Java, que facilita o
mapeamento dos atributos entre uma base tradicional de dados relacionais e o modelo objeto
de uma aplicação, através de arquivos de configuração XML ou Annotations. O Hibernate
implementa JPA.
Hints
Dicas rápidas que aparecem ao passar o cursor do mouse sobre determinado item.
HSM
Projeto Básico SUSIS/GENEG 2011/003 34

Host Security Module. Fabricado na França e Fornecido pela empresa Thales-esecurity, é um
Módulo de segurança baseado em hardware, para redes de intercâmbio que é utilizado pelo BRB
e várias outras instituições no Brasil e no Mundo (Visa, Master, Amex, etc). É fisicamente
seguro, possui processador criptográfico (DES, 3DES e RSA). É dirigido a aplicação, com suporte
a várias funções padrão, além de possuir várias opções de conectividade com o Host. No Brasil
a Empresa fabricante e fornecedora é representada pela Empresa First Tech, que fornece,
configura e presta suporte técnico e operacional.
IBM-DB2
Banco de dados relacional mantido pela empresa IBM.
ISO8583
Padrão ISO para troca de mensagens.
iWorkPlace
Framework adquirido pelo Banco e mantido pela empresa Infonet, para o desenvolvimento e
funcionamento do atual Internet Banking.
Java
Linguagem de programação orientada a objeto desenvolvida na década de 90 pela empresa Sun
Microsystems.
JavaBean
É um POJO que segue definições rígidas de estrutura (construtor default sem argumentos,
atributos privados ou protegidos e métodos que seguem o padrão getters e setters para seus
atributos).
JavaBluePrints
É um guia de melhores práticas e padrões da Sun Microsystems, para desenvolvimento na
Plataforma Java.
JavaDoc
É um gerador de documentação criado pela Sun Microsystems, utilizado para documentar o
código fonte, com resultado extraído para HTML.
JavaSoft
Padrão de codificação para a linguagem Java.
JbossSeam
Framework criado pela JBoss/Red Hat para aumentar a produtividade de aplicações Java que
usam principalmente JSF e EJB 3.
JPA
Java Persistence API. É uma API padrão do Java para persistência que deve ser implantada por
frameworks que queiram seguir o padrão.
JSF
JavaServer Faces é um framework open source que adota do modelo MVC para o
desenvolvimento de aplicações web de forma visual, ou seja, arrastando e soltando
componentes na tela e definindo suas propriedades. É considerada por muitos a última palavra
em termos de desenvolvimento para web em Java.
Json
JavaScript Object Notation. É um formato leve para intercâmbio de dados que vem ganhando
espaço frente ao XML, dada sua melhor otimização e facilidade de uso. Se utilizado em conjunto
com Ajax, traz grandes ganhos de performance. Pode, porém, ser utilizado para outras
comunicações entre sistemas, também apresentando ganhos.
JSR 286
Especificação Java para desenvolvimento de portlets.
Leiaute - “Layout”
Distribuição física de elementos num determinado espaço.
Libras
Língua Brasileira de Sinais é uma linguagem gestual usada pela maioria dos deficientes
auditivos. Não é apenas a gestualização da língua portuguesa e sim uma língua à parte,
composta de fonologia, morfologia, sintaxe e semântica, regulamentada no Brasil por legislação
própria.
Login
Palavra inglesa utilizada para descrever o ato de acessar um sistema. Utilizado também para
designar o nome de usuário para acesso ao sistema.
Projeto Básico SUSIS/GENEG 2011/003 35

Lotes
Conjunto de registros a serem processados.
Master/Mastercard/Maestro
Rede de cartões de débito e de crédito operados pela empresa Mastercard.
Metáforas
Imagens que fazem a ligação entre palavras e seus significados, de forma a torná-los mais
claros e visíveis. Ex.: E-mail simboliza-se com o desenho de uma carta, enquanto uma busca
simboliza-se com uma lupa.
Mobile Payment
Engloba todo tipo de operação que envolva um dispositivo móvel para iniciar, ativar ou
confirmar um pagamento. Os dispositivos móveis mais comuns são os telefones celulares, mas
aqueles que já são usuários de smartphones e PDAs têm sido os primeiros a usar esse meio de
pagamento.
MVC
Model- view-controller. Padrão de arquitetura de software que visa separar a lógica de negócio
da lógica de apresentação.
MVC-2
Idem ao MVC, com a diferença de que o MVC-2 possui um único controller responsável por
redirecionar as requisições.
OFC
Open Financial Connectivity - formato para arquivo de conciliação financeira utilizado pelo
Software Microsoft Office Money. É considerado obsoleto e foi substituído pelo formato OFX.
OFX
Open Financial Exchange - formato aberto para troca de informações financeiras para permitir a
conciliação financeira.
Oracle
Empresa fornecedora do banco de dados relacional de mesmo nome.
Outsourcing
Modalidade de contratação de prestação de serviços especializados para realização das
chamadas atividades meio, que consiste no fornecimento de todos os itens da solução (Software
Básico, Software Aplicativo e Equipamentos) pela contratada.
PDF
Portable Document Format. É um formato aberto de arquivo desenvolvido pela Adobe Systems,
para representar documentos de maneira independente do aplicativo, hardware ou sistema
operacional, de forma inviolável.
POJO
Plain Old Java Objects são objetos Java que seguem um desenho simplificado.
PA
Sigla de Ponto de Atendimento, que no BRB define de forma genérica uma Agência ou Posto de
Atendimento Bancário – PAB.
Perto
Empresa atual fornecedora da solução de Autoatendimento disponibilizado pelo BRB a seus
clientes. Composta por ATMs, Software Básico, Software Aplicativo e equipamentos
denominados ATM.
Ponto de Função
Unidade de medida de sistemas que quantifica as funcionalidades proporcionadas aos usuários,
independente de aspectos de implementação.
Provisionador de Saldos
Serviço que permite aos sistemas legados informarem à automação bancária, da necessidade
de bloqueio de determinado valor do saldo do cliente, na véspera de crédito de salário, para
permitir débitos em sua conta, garantindo liquidação de operações contratadas.
Proxy
É um software de controle de dados que atende às requisições, repassando os dados do cliente
à frente.
Redeshop
Rede adquirida pela Mastercard, que passou a operar como Mastercard Maestro, após sua
unificação à Maestro.
Projeto Básico SUSIS/GENEG 2011/003 36

RollBack
Ação de desfazer as mudanças efetuadas em um Banco de Dados, por um processo de
atualização que não tenha sido concluído, devolvendo a esse banco de dados o status quo de
antes do início desse processo.
Sefaz
Secretaria de Fazenda do Distrito Federal. Órgão ao qual o BRB é vinculado e mantém convênio
para o oferecimento de serviços, como por exemplo a consulta de IPTU e IPVA para pagamento.
SGA
Sistema Gerenciador de Acesso, utilizado no BRB para gerenciar usuários e perfis, que processa
por meio de requisições que devolvem a permissão ou não, para acesso a determinado sistema.
SMS
Short Message Service. É um serviço de envio de mensagens curtas, destinado para
recebimento em aparelhos celulares. É utilizado pelo BRB, entre outros usos, para aviso sobre
movimentação financeira em conta.
SOA
Service Oriented Architecture. Pode ser traduzido como Arquitetura Orientada a Serviços, e é
um estilo de arquitetura de software, cujo princípio fundamental prega que as funcionalidades
implementadas pelas aplicações devem ser disponibilizadas na forma de serviços,
frequentemente disponibilizados em um barramento de serviços (enterprise service bus, em
inglês) que disponibiliza as interfaces ou contratos, acessíveis por web-service ou outra forma
de comunicação entre sistemas.
Spring
É uma framework open source, que define que o container se encarrega de “instanciar” classes
de uma aplicação Java, definindo suas interdependências através de configuração em XML,
Annotations ou inferências do framework. Possui arquitetura baseada em POJO e interfaces,
fornecendo aos POJOs características de segurança e controle de transações.
Struts 2
Framework open source que é uma evolução do framework Webwork, onde do original Struts
praticamente herdou-se só o nome. Utiliza o padrão MVC-2, é facilmente integrável a outros
frameworks para persistência, controle transacional e para camada de visão (utilizando Ajax). É
uma alternativa ao JSF.
Subusuário
Utilizado para descrever um usuário autorizado a consultar ou pré-gerar transações em uma
conta através de um canal, mesmo que não seja um cliente vinculado à conta.
Subversion
Também conhecido por SVN é um repositório para controle de versões.
Taglib
Define uma biblioteca a ser utilizada necessitando apenas chamar a partir de um prefixo.
Tecban
Empresa mantenedora do Banco24horas e Rede Compartilhada.
Teclado Virtual
Applet Java utilizado para digitação de senha em ambiente web nos portais do BRB.
TJDFT
Tribunal de Justiça do Distrito Federal e Territórios. Órgão do Poder Judiciário ao qual o BRB
mantém acordo para consulta processual através de canal eletrônico.
Tiles
Solução para organização, padronização e estruturação da navegação e leiaute das páginas de
um site. Originou-se no framework Struts, mas pode ser utilizado por outros frameworks.
Titular
É aquele que faz parte das ordens de uma conta, autorizado a movimentá-la.
Transferência de Tecnologia
Contrato em que se transfere o conhecimento industrial. Este pode ser conceituado como o
saber imprescindível à produção de um bem destinado à comercialização. As cláusulas de tal
contrato eram impostas pelo Instituto Nacional de Propriedade Industrial (INPI), mas com a
resolução no. 20-91, do próprio INPI ficam as partes contratantes liberadas para a forma
contratual que melhor lhes convier, exigindo-se apenas a averbação do contrato no próprio
INPI, para efeitos fiscais. São modalidades de transferência de tecnologia:
Projeto Básico SUSIS/GENEG 2011/003 37

a) licença de uso de privilégio industrial (exploração de patente)
b) licença de uso de registro industrial (uso de marca)
c) fornecimento de tecnologia
d) prestação de serviço de assistência técnica e científica
No contexto deste contrato está sendo utilizada a modalidade: “c” Fornecimento de Tecnologia
Token
Código randômico enviado para e-mail ou celular pré-cadastrado e liberado, de forma a permitir
ao cliente a autorização de uma transação financeira.
TXT
Arquivo magnético no formato de texto.
UML
Unified Modeling Language. É uma linguagem de modelagem não proprietária que permite que
os desenvolvedores visualizem os produtos de seu trabalho em artefatos padronizados.
URA
Unidade de Resposta Audível.
Usuário
Utilizado para denominar o usuário de uma aplicação.
Visa
Bandeira de cartões detentora da Cielo.
XML
eXtensible Markup Language. É utilizado para escrever diversos tipos de dados, com propósito
principal de facilidade de compartilhamento de informações através de redes de comunicação.
WSRP 2.0
Web Services for Remote Portlet. É uma especificação aberta que define a forma para interação
entre serviços web que oferecem portlets. Pode ser utilizada junto à JSR 268.
Worklfow
Fluxo de Trabalho. É a sequência de passos necessários para que se possa atingir a automação
de processos de negócio, de acordo com um conjunto de regras definidas, permitindo que
possam ser transferidos de uma pessoa ou área à outra, por meio de regras pré-definidas.
Projeto Básico SUSIS/GENEG 2011/003 38