Requirements Specification

< nome do projeto ou descrição OS>

Revision History
Date Version Status Prepared by Comments

Document Control
Role Name Telephone
Preparer
Reviewer

Approval
Role Name Signature Date
Sponsor
Business Leader
Project Manager
Team Member
Team Member

Aqui deverão ser registrados todas as versão oficiais do documento, cada nova versão deverá ser devidamente aprovada pelos
envolvidos no projeto. Os aprovadores padrões serão o Sponsor, Business Leader e o Project Manager e adicionamente poderão ser
incluídos outros aprovadores conforme áreas chaves envolvidos em cada projeto. No caso de OS a parte relacionada a aprovação
poderá ser descartada.
GENERAL CONTENTS

1 INTRODUCTION......................................................................................................4

2 FUNCTIONAL REQUIREMENTS............................................................................4
2.1 In Scope.........................................................................................................4
2.2 Out of Scope..................................................................................................4

3 NON-FUNCTIONAL REQUIREMENTS...................................................................4
3.1 Data Conversion............................................................................................4
3.2 Security..........................................................................................................4
3.3 Audit and Regulatory Controls......................................................................4
3.4 Availability......................................................................................................5
3.5 Performance..................................................................................................5
3.6 Capacity.........................................................................................................5

4 DELIVERABLES......................................................................................................5

5 APPENDIX................................................................................................................5
5.1 Appendix 01...................................................................................................5
5.2 Appendix 02...................................................................................................5
1 INTRODUCTION
O processo envolve em reestruturar a transação de interface de faturamento para que não ocorra faturamento
com o mesmo chassi para a interface AG e da mesma série para interface de CE. Esses bloqueios já existem,
porém não estão atendente totalmente a necessidade, sendo que os bloqueio atuais recusam os faturamento
com número de série já cadastrado no floor plan anteriormente para segmento de agrícola, e para segmento
de construção exite o bloqueio para não acatar número de chassi já cadastrado no floor plan anteriormente.
Esses bloqueios podem ser eliminados através da transação no floor plan de cancelamento de bem já
cadastrados, porém isso ocorre por meio de autorização.
Uma visão geral do que este projeto / processo envolve.

2 FUNCTIONAL REQUIREMENTS

2.1 In Scope
Para atenter a nossa expectativa, deverá ocorrer o(s) bloqueio(s) da(s) máquina(s) AG com o mesmo chassi,
assim como, o(s) bloqueio(s) da(s) máquina(s) CE com o mesmo número de série após interface, ou seja,
quando processar o arquivo de faturamento de máquina AG, enviado pela fábrica, houver a verificação que
existe número de chassi que já foi faturado anteriormente pela revenda X, deve ocorrer o bloqueio e seja
inserido a mensagem de erro constando o nome desta revenda X. O mesmo deverá ocorre quando se tratar
de faturamento máquinas CE, ao processar o arquivo deverá ocorrer a mensagem de erro que o número da
série que está sendo lido no arquivo já foi faturado anteriormente pela revenda X. As mensagens de erro
devera ocorrer também no relatório gerado após o faturamento, tanto na versão impressa quanto na versão
em CSV. Para que os encarregados da analise do faturamento possam verificar se o refaturamento do
equipamento foi permitido de acordo com regras de cancelamento ou o mesmo deverá ser devolvido para
CNH como inconsistência. Se houver expressa autorização, o cancelamento do bem ocorrerá através da
transação no floor plan de cancelamento de bem já cadastrados, assim possibilitando novo faturamento da
máquina. Habilitar o sistema para que recuse o faturamento de títulos que o campo série e/ou chassi esteja
em branco.
Detalhar todos os itens que serão atendidos pelo projeto / processo. Esses itens deverão ser descritos abaixo de forma que fique o mais claro
possível a todos que terão acesso a esta documentação.

2.2 Out of Scope

< Incluir o texto >

Descrever os itens que possuem alguma relação com as atividades mas que não foram incluídos no escopo do projeto seja em função de
custos, benefícios ou prazo.

3 NON-FUNCTIONAL REQUIREMENTS
< Incluir o texto >
Descreve O QUÊ o projeto / processo necessita para atendimento a alguma restrição que o mesmo possua. Comos esses itens não são
negociais eles poderão ser descritos em conjunto com a área de Tecnologia. Caso o item não seja aplicável ao seu projeto / processo incluir a
nota padrão de “Não se aplica”.
3.1 Data Conversion
< Incluir o texto >
Se você responder SIM para alguma destas questões; você tem um requisito de conversão de dados que precisa ser descrito.

- Essa mudança envolve alterações em formato das informações já armazenadas na base de dados ?

- Envolve mudança de dados para um novo ambiente ou nova estrutura na base de dados ?

3.2 Security
< Incluir o texto >
Caso este projeto / processo necessite de algum item adicional que saia dos padrões de segurança já estabelecidos para os sistemas e
procedimentos do banco.

3.3 Audit and Regulatory Controls

< Incluir o texto >
Descreve alguma particularidade necessária ao sistema para atender algum requisito de auditoria ou definição regulatória. Por exemplo:
informações de clientes deverão ser armazenadas por 14 anos ao invés de 7.

3.4 Availability
< Incluir o texto >
Define os requisitos necessários para a disponibilidade do sistema. Por exemplo se ele deverá operar 24x7, se em horário comercial,
qual o período máximo que ele poderá ficar indisponível. Quantas vezes.

3.5 Performance
< Incluir o texto >
Define parâmetros de performance que são necessários para atendimento a uma necessidade do negócio. Pode ser expressa de
diversas formas, algums exemplos : tempo de resposta de uma transção não pode ser superior a 5 segundos. O processamento batch
de uma informação deverá ser completada numa janela máxima de 2 horas de processamento. Transferência de arquivos deverão ser
concluídas em até 15 minutos.

3.6 Capacity
< Incluir o texto >
Define os parâmetros de capacidade de um determinado produto / sistema / serviço. As informações a serem repassadas aqui serão
base para definição de funcionamento, processamento, armazenamento e performance de uma determinada funcionalidade. Alguns
exemplos: número de usuários de um determinado sistema. Volume de processamento mensal de uma funcionalidade. Número de
transações por segundo esperado numa funcionalidade.

4 DELIVERABLES
< Incluir o texto >
Descrever as entregas do projeto. A maioria dos projetos irá possuir uma única implantação mas conforme necessidade negocial ou
prioridade em determinadas funcionalidades o projeto poderá ser dividido em mais de uma entrega.
5 APPENDIX
Segue abaixo o modelo de mensagem deverá aparecer na crítica:
 Segue a baixo a tela para cancelar o registro de bem já cadastrado BCNH:

Obs: esse recurso utilizado quando re-faturamento autorizado pelo BCNH.

Este item pode ser utilizado para incluir qualquer informação adicional ou documentos que possam dar um melhor esclareciment sobre
os itens descritos acima. Caso não seja necessário incluir nenhum anexo ele pode ser excluído da documentação.

5.1 Appendix 01
< Incluir o texto >

5.2 Appendix 02
< Incluir o texto >