SOL Informática
Soluções On Line
BGMStadium – Sistema de Cobrança
Documento de Requisitos
Autores:Artur Winter
Claudio SantosHelena MendesJuliana Abadia
Rodrigo MachadoVictor Leandro
Wesley Fernandes
Versão 1.6Histórico de Revisão
Data Versão Descrição Autor
16/03/2010 1.1 Desenvolvimento da introdução deste documento Helena Mendes
17/03/2010 1.1 Desenvolvimento dos requisitos funcionais Victor Leandro
18/03/2010 1.2 Inclusão das Convenções, termos e abreviações Helena Mendes
18/03/2010 1.2 Descrição dos usuários Wesley Pedro
18/03/2010 1.2 Desenvolvimento dos requisitos não funcionais Juliana Abadia
18/03/2010 1.3 Descrição geral do sistema Rodrigo Machado
23/03/2010 1.4 Revisão de Conteúdo dos requisitos Helena Mendes
25/03/2010 1.5 Revisão ortográfica, introdução de vocábulos no glossário Artur Winter
26/03/2010 1.6 Correção ortográfica, divisão de perfil, formatação de texto e introdução de vocábulo no glossário Victor Leandro
Versão 1.6 Março/2010
SOL Informática
Soluções On Line
25/05/2010 1.6 Revisão de conformidade de RF com caso de uso Artur/Helena
Versão 1.6 Março/2010
Sumário
Visão geral deste documento...................................................................................................1
Convenções, termos e abreviações.........................................................................................1NF001................................................................................................................................ 2Usabilidade- Consistência na Interface...................................................................................2NF002................................................................................................................................ 2Segurança – Criptografia......................................................................................................21. Identificação dos Requisitos.......................................................................................32. Prioridades dos Requisitos.........................................................................................4
Referências................................................................................................................................ 4
Abrangência e sistemas relacionados.....................................................................................1
Descrição dos usuários............................................................................................................2
Usabilidade................................................................................................................................ 1Usabilidade.NF001 - Consistência na Interface................................................................1Usabilidade.NF002 - Aparência.........................................................................................1
Confiabilidade............................................................................................................................ 1Confiabilidade.NF003 – Falhas Transitórias e Permanentes............................................1Confiabilidade.NF004 – Falhas Recuperáveis e Irrecuperáveis........................................1Confiabilidade.NF005 – Falhas de Corrompimento e Não corrompimento.......................1
Desempenho.............................................................................................................................. 2Desempenho.NF006 – Tempo de Resposta.....................................................................2Desempenho.NF007 – Tempo Real..................................................................................2
Segurança.................................................................................................................................. 2Segurança.NF008 – Perfis do Usuário..............................................................................2Segurança.NF009 – Criptografia.......................................................................................2Segurança.NF010 – Autenticação.....................................................................................2
Distribuição................................................................................................................................ 3Distribuição.NF011 – Versão.............................................................................................3
Padrões...................................................................................................................................... 3Padrões.NF012 – Padrões Utilizados...............................................................................3
Hardware e software.................................................................................................................. 3Hardware e Software.NF013 – Banco de Dados...............................................................3Hardware e Software.NF014 – Linguagem.......................................................................3
Manutenibilidade....................................................................................................................... 4Manutenibilidade.NF015...................................................................................................4Manutenibilidade.NF016...................................................................................................4
Versão 1.6 Março/2010
Documento de Requisitos Introdução – P1 / 1
Introdução
Este documento especifica o sistema BGMStadium – Sistema de Cobrança, fornecendo aos desenvolvedores as informações necessárias para o projeto e implementação, assim como para a realização dos testes e homologação do sistema.Além disso, tal documento pode ser visto como um contrato entre o cliente e o gerente de projeto, pois valida a conformidade segundo a especificação de requisitos do cliente para definição do escopo.
“ Os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais. Esses requisitos refletem as necessidades dos clientes de um sistema que ajuda a resolver algum problema, por exemplo, controlar um dispositivo, enviar um pedido ou encontrar informações. O processo de descobrir, analisar, documentar e verificar esses serviços e restrições é chamado de Engenharia de Requisito(RE – Requeriments Engenharia)”
Sommerville.Ian, Engenharia de software 8.ed.2007.
Visão geral deste documentoEsta introdução fornece as informações necessárias para fazer um bom uso deste documento, explicitando seus objetivos e as convenções que foram adotadas no texto, além de conter uma lista de referências para outros documentos relacionados. As demais seções apresentam a especificação do sistema BGMStadium e estão organizadas como descrito abaixo. Capitulo 1 – Descrição geral do sistema: apresenta uma visão geral do sistema,
caracterizando qual é o seu escopo e descrevendo seus usuários. Capitulo 2 – Requisitos funcionais (casos de uso): especificam todos os requisitos
funcionais do sistema, descrevendo os fluxos de eventos, prioridades, atores, entradas e saídas de cada caso de uso a ser implementado.
Capitulo 3 – Requisitos não funcionais: especifica todos os requisitos não funcionais do sistema, divididos em requisitos de usabilidade, confiabilidade, desempenho, segurança, distribuição, adequação a padrões e requisitos de hardware e software.
Convenções, termos e abreviaçõesA correta interpretação deste documento exige o conhecimento de algumas convenções e termos específicos, que são descritos a seguir:Convencionou-se que usaríamos o padrão IEEE/ANSI 830-1993, que propõe que o documento seja estruturado da seguinte forma:
Introdução: propósito do documento, visão geral do documento, convenções, termos e abreviações, referências;
Descrição geral: perspectiva do produto, funções, características do usuário, restrições de ordem geral, opções de projeto e dependências;
Requisitos específicos: devem ser especificados requisitos funcionais e não funcionais do sistema;
Índice.Por convenção, a referência a requisitos é feita através do nome da subseção na qual eles estão descritos, seguido do identificador do requisito, de acordo com o esquema do item 1.Para estabelecer a prioridade dos requisitos foram adotadas as denominações “essencial”, “importante” e “desejável” definições no item 2.
Versão 1.6 Março/2010
Documento de Requisitos Introdução – P2 / 2
Termos e abreviações
Descrição:
Versão 1.6 Março/2010
Documento de Requisitos Introdução – P3 / 3
Casos de uso Identificação e relacionamento das funcionalidades
Desenvolvedores Profissionais que tem a função de codificar o sistema
Dispositivo São também denominados periféricos. Eles permitem a interação do processador com o homem, possibilitando a entrada e/ou a saída de dados
Engenharia de Requisito
Processo para identificação e controle dos requisitos por meio do levantamento e análise
Escopo Documento que define as diretrizes de um projeto
Hardware Parte física dos equipamentos de informática
Homologação Validação e aceite do cliente
Implementação É a elaboração e preparação dos módulos necessários à sua execução.
Login É a chave de acesso à um determinado sistema computacional, onde o usuário possui um nome de usuário e uma senha para validação.
MySQL É um sistema de gerenciamento de banco de dados (SGBD), que utiliza a linguagem SQL (Linguagem de Consulta Estruturada, do inglês Structured Query Language) como interface. É atualmente um dos bancos de dados mais populares, com mais de 10 milhões de instalações pelo mundo.
NF001 Usabilidade- Consistência na Interface
NF002 Usabilidade- Aparência
NF003 Confiabilidade–Falhas Transitóriase Permanentes
NF005 Confiabilidade – Falhas de Corrompimento e Não corrompimento
NF006 Desempenho – Tempo de Resposta
NF007 Desempenho – Tempo Real
NF008 Segurança – Perfis do UsuárioNF009 Segurança – Criptografia
NF010 Segurança – Autenticação
NF011 Distribuição – Versão
NF012 Padrões
NF013 Hardware e Software – Banco de Dados
NF014 Hardware e Software – Linguagem
Requisitos Necessidades funcionais e não funcionais do cliente
RF Requisito FuncionalRF001 Manter clientes
RF002 Manter devedores
RF003 Manter funcionários
RF004 Manter perfil dos funcionários
RF005 Controlar movimentações de documentos
RF006 Visualizar relatórios de devedores
RF007 Visualizar relatórios de clientes
Versão 1.6 Março/2010
Documento de Requisitos Introdução – P4 / 4
RF008 Controlar Sistema financeiro
RF009 Visualizar situação jurídica
RF010 Controlar sistema de atendimento
RF011 Manter carga automática de dados dos clientes
RF012 Emitir relatórios estatísticos
RF013 Supervisionar funcionários cobradores
RF014 Manter Histórico
RF015 Emitir boletos
RF016 Manter a segurança do sistema
RF017 Manter rotinas de lote
SAC Serviço de Atentimento ao Consumidor
Software É uma sequência de instruções a serem seguidas e/ou executadas, na manipulação, redirecionamento ou modificação de um dado/informação ou acontecimento.
1. Identificação dos Requisitos Em termos gerais, os requisitos são classificados em dois tipos:Requisitos funcionais e Requisitos não funcionais:
Alencar (1999: 26) refere-se aos funcionais da seguinte forma:“dizem respeito à definição das funções que um sistema ou um componente de sistema deva fazer. Ou seja, descrevem as transformações a serem realizadas nas entradas de um sistema ou em um de seus componentes, a fim de que se produzam saídas”.
Já em relação aos requisitos não funcionais, o autor informa que eles“dizem respeito a restrições, aspectos de desempenho, interfaces com o usuário, confiabilidade, segurança manutenibilidade, portabilidade, padrões etc., bem como aspectos sociais e políticos” (ALENCAR, 1999:26). De forma geral, poderse-ia associar o conceito de requisitos não funcionais à idéia de restrição sobre como os requisitos funcionais são implementados. Em outras palavras, os requisitos funcionais descrevem o que o sistema deve fazer, enquanto os não funcionais descrevem como os requisitos funcionais são implementados.
Apud WAGNER ZAPAROLIMestre em Ciência da Computação - MACKENZIE; Consultor de Sistemas; Colunista em Ciência e Tecnologia do jornal Gazeta de Bebedouro; Professor de Lógica de Programação na UNINOVE
Por convenção, a referência aos requisitos é feita por meio do nome da subseção onde eles estão descritos, seguido do identificador do requisito, de acordo com o esquema abaixo:
[nome da subseção.identificador do requisito]Por exemplo, o requisito [Manter Clientes.RF001] está descrito em uma subseção chamada “Manter Clientes”, em um bloco identificado pelo número [RF001]. Já o requisito não funcional [Tempo de resposta.NF006] está descrito na seção de requisitos não funcionais de Desempenho, em um bloco identificado por [NF006].
Versão 1.6 Março/2010
Documento de Requisitos Introdução – P5 / 5
2. Prioridades dos RequisitosPara estabelecer a prioridade dos requisitos foram adotadas as denominações “essencial”, “importante” e “desejável”. Essencial é o requisito sem o qual o sistema não entra em funcionamento. Requisitos
essenciais são requisitos imprescindíveis, que têm que serem implementados impreterivelmente.
Importante é o requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema poderá ser implantado e usado mesmo assim.
Desejável é o requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis são requisitos que podem ser deixados para versões posteriores do sistema, caso não haja tempo hábil para implementá-los na versão que está sendo especificada.
Referências
1. ALENCAR, F. M. R. Mapeando a Modelagem Organizacional em
Especificações Precisas. 1999. Tese de doutorado. Centro de Informática.UFPE,Recife.
2. IEEE/ANSI 830-1993
3. Pressman, Roger S. Engenharia de Software ; São Paulo : Pearson mackon, 1995.
4. Sommerville. Ian Engenharia de software, 8ª edição/ São Paulo: Pearson Addison Wesley,2007.
5. WAGNER ZAPAROLI: Mestre em Ciência da Computação - MACKENZIE; Consultor de Sistemas; Colunista em Ciência e Tecnologia do jornal Gazeta de Bebedouro; Professor de Lógica de Programação na UNINOVE.
Versão 1.6 Março/2010
Documento de Requisitos Requisitos funcionais – C2. P1 / 1
Capítulo
Descrição geral do sistema
O BGMStadium está sendo desenvolvido com o objetivo de viabilizar o total controle de carteiras de cobrança em andamento. O software é eficiente na otimização da cobrança e apresenta grande agilidade na prestação de contas por meio de relatórios completos e personalizados.
Além disso, você poderá facilmente fornecer informações on-line sobre o posicionamento das carteiras de cobrança ao seu credor, gerando qualidade na prestação de serviço. O sistema é dividido em dois módulos: o módulo Web e o módulo Administrativo. O módulo Web permite ao devedor acompaunhar suas dívidas junto ao sistema e sanar suas dúvidas por meio de um serviço de atendimento ao consumidor. O módulo Administrativo é responsável pelos módulos cliente, administrador, financeiro, atendimento e relatório.
Abrangência e sistemas relacionados1.1 Módulo clientes
No módulo clientes será realizado o cadastro de informações de pessoas físicas e jurídicas dos nossos clientes e seus devedores.
1.2 Módulo financeiroIntegra todos os subsistemas que compõem e envolvem o gerenciamento de valores, são eles:
Cadastro de Contas Bancárias: Por meio do cadastro de contas bancárias será realizado a inclusão das contas bancárias utilizadas pela empresa no sistema, identificando o nome e número do banco, número da agência, número da conta, data de abertura e praça (comp), nome do gerente, telefone, etc.
Cadastro de Tipos de Documento: Por meio do cadastro de tipos de documentos serão inseridos as formas de faturamento e pagamento da empresa, tais como boleto bancário, fatura, cupom fiscal, Cheque à vista, cheque a prazo, cartão de credito, cartão de débito depósito em conta, entre outros de acordo com a política da empresa.
Cadastro de Despesas: Por meio da tela de cadastro de despesas será possível fazer o cadastro dos gastos da empresa. É recomendável o cadastro de todas e quaisquer despesas para que não haja deficiência no controle financeiro dos lançamentos efetuados pela BGMStadium.
Contas a Pagar: Listagem das despesas em aberto no sistema a serem pagas.
Contas a Receber: Listagem das duplicatas em aberto no sistema a serem recebidas. Tais duplicatas serão geradas por meio do cadastro de receitas e dos serviços prestados.
Lançamentos Financeiros: Por meio da tela de lançamentos é possível visualizar todas as parcelas (duplicatas) que foram quitadas no sistema. Além de inclusão de
Versão 1.6 Março/2010
Documento de Requisitos Requisitos funcionais – C2. P2 / 2
lançamentos avulsos, edição de duplicatas (parcelas) quitadas e transferência de valores entre as contas bancárias cadastradas.
Fluxo de Caixa: Por meio da tela de fluxo de caixa serão gerados as provisões de saldo final por período. A geração do fluxo de caixa será a principal funcionalidade dentro de um sistema financeiro, permitindo à BGMStadium o controle do saldo bancário.
1.3 Módulo RelatórioO módulo relatório disponibilizará para o cliente todos os dados que ele necessitará para uma futura análise estatística.
1.4 Módulo AdministradorO módulo Administrador terá os seguintes itens em destaques:
Cadastro de Tipos de Pefil: Por meio deste cadastro será possível criar os perfis de acesso ao sistema, definindo quais telas serão visualizadas bem como as ações para os registros relacionados (visualização, edição, inclusão, alteração e exclusão de registros).
Cadastro de Usuários: Por meio do cadastro de usuários será feito o cadastro das informações relevantes aos usuários do sistema, tais como login, senha, e-mail e departamento ao qual o usuário pertence.
Cadastro de Tipos de Agenda: Por meio do cadastro de tipos de agenda será possível relacionar um agendamento com o seu "assunto" (ex. reúnião, almoço, visita) definindo assim qual a finalidade do agendamento.
Cadastro de Prioridades de Agenda: Por meio do cadastro de prioridades de agenda será possível associar um agendamento cadastrado no sistema com a prioridade que o mesmo necessita (ex. baixa, média, alta), definindo assim, para o usuário, a urgência do agendamento.
Cadastro de Tipos de Contato: Por meio do cadastro de tipos de contatos será possível cadastrar varias observações a serem utilizadas no processo de cadastro de contatos para clientes, categorizando assim, os contatos de acordo com os departamentos ao qual cada um pertence dentro da empresa no qual o contato atua.
1.5 Módulo AtendimentoNo módulo atendimento será criado um sistema de SAC, para que os clientes possam sanar suas dúvidas quanto ao processo ou ao sistema, também quanto ao valor devido.
Descrição dos usuáriosOs usuários do sistema BGMStadium – Sistema de Cobrança serão dividios em 5 classes, no qual cada um terá um grau de acessibilidade compatível com a sua função e necessidade, os perfis são:
Administrador – Tem a função de administrar todos os módulos, podendo fazer alterações nos mesmos e impressão de todos os relatórios fornecidos pelo sistema, possibilitando uma administração clara para tomadas de decisões em tempo hábil.
Versão 1.6 Março/2010
Documento de Requisitos Requisitos funcionais – C2. P3 / 3
Supervisor – Tem a função de monitorar os recuperadores de credito, fornecendo relatórios de resultados por atendente, por clientes e por devedores.
Financeiro – Supervisiona o departamento financeito em todas as suas diretrizes. Suas permissões são de inclusão e alteração somente dos registros do módulo financeiro.
Administrativo – Gerencia o departamento administrativo controlando as atividades administrativas para que as mesmas tenham êxito em seus objetivos.
Cliente – Pessoa física ou jurídica que utiliza o sistema BGMStadium – Sistema de Cobrança, este terá acesso via web aos relatórios que demonstra o andamento de sua carteira de devedor.
Devedor – É o inadimplente da BGMStadium, que terá acesso via web permitindo assim o acompanhamento de sua dívida, possibilitando também a impressão de boletos bancários.
Cobrador – Funcionário da empresa que terá acesso ao sistema e conhecimento das regras de negócios dos clientes mantenedores.
Capítulo
Requisitos funcionais (casos de uso)
Segundo Sommerville Ian(2007,2), “Requisitos Funcionais são as declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais podem também estabelecer explicitamente o que o sistema não deve fazer.”
RF001: Manter pessoa (clientes)
Este requisito irá fornecer as funcionalidades de inclusão, alteração, consulta e inatividade de um cliente.
Atores: Funcionário e Administrador
Prioridade: Essencial Importante Desejável
RF002: Manter pessoa devedores
Este requisito irá fornecer as funcionalidades de inclusão, alteração, consulta e inatividade de um devedor.
Atores: Funcionário e Administrador
Versão 1.6 Março/2010
Documento de Requisitos Requisitos funcionais – C2. P4 / 4
Prioridade: Essencial Importante Desejável
RF003: Manter funcionários
Este requisito irá fornecer as funcionalidades de inclusão, alteração, consulta e inatividade de um funcionário.
Atores: Administrador
Prioridade: EEssencial Importante Desejável
RF004: Manter perfil/cargo
Este requisito irá registrar e definir o nível de permissão dos funcionários da empresa.
Atores: Administrador
Prioridade: Essencial Importante Desejável
RF005: Manter documentos
Este requisito irá controlar todo o sistema de movimentação documental relativos a todas as operações de controle, bem como, cheques e acordos.
Atores: Funcionário e Administrador
Prioridade: Essencial Importante Desejável
RF006: Consultar devedor
Este requisito irá consultar o devedor e sua situação dentro da empresa
Atores: Funcionário, Cliente e Administrador
Prioridade: Essencial Importante Desejável
RF007 Consultar clientes mantenedores
Este requisito por meio dos funcionários irá consultar os clientes mantenedores que possuem contrato com a empresa
Atores: Funcionário e Administrador
Prioridade: Essencial Importante Desejável
Versão 1.6 Março/2010
Documento de Requisitos Requisitos funcionais – C2. P5 / 5
RF008: Manter Sistema financeiro
Este requisito irá controlar todas as entradas e saídas referentes ao caixa da empresa. Servirá também para controle de renegociações.
Atores: Administrador
Prioridade: Essencial Importante Desejável
RF009: Consultar situação jurídica
Este requisito irá servir como meio de consulta da situação jurídica do inadimplente.
Atores: Funcionário e Administrador.
Prioridade: Essencial Importante Desejável
RF010: Manter sistema de atendimento
Este requisito irá oferecer suporte ao atendente da empresa, como também, controlar os atos do mesmo e com o objetivo focado em oferecer o suporte para o nosso cliente.
Atores: Funcionário e Administrador
Prioridade: Essencial Importante Desejável
RF011: Carga automática dos dados pessoa (devedor)
Este requisito irá oferecer suporte à importação de dados da empresa que já possui sistema de controle de devedores.
Atores: Administrador
Prioridade: Essencial Importante Desejável
RF012: Imprimir relatórios:
Funcionalidade que dará acesso às impressões de relatórios disponíveis referente ao perfil.
Atores: Funcionário, Cliente e Administrador
Prioridade: Essencial Importante Desejável
RF013: Supervisionar funcionários Recuperadores de Crédito.
Versão 1.6 Março/2010
Documento de Requisitos Requisitos funcionais – C2. P6 / 6
Este requisito irá oferecer suporte ao funcionário supervisor na tarefa de controle e orientação dos Recuperadores de Crédito da empresa, como também, controlar a distribuição de suas tarefas.
Atores: Funcionário e Administrador
Prioridade: Essencial Importante Desejável
RF014: Manter histórico
Este requisito irá controlar todos os atendimentos da empresa bem como qualquer operação feira nos documentos do cliente, mantendo dados atualizados e disponíveis para decisões futuras ou relatórios estatísticos.
Atores: Supervisor e Atendente.
Prioridade: Essencial Importante Desejável
RF015: Emitir / Imprimir boletos
Este requisito irá gerar e imprimir uma cobrança mensal conforme contrato.
Atores: Funcionário, Devedor e Administrador
Prioridade: Essencial Importante Desejável
RF016: Manter backup/integridade do sistema
Este requisito irá oferecer funcionalidades de agendamento e consulta de backup
Atores: Administrador
Prioridade: Essencial Importante Desejável
RF017 Manter as rotinas de batch.
Este requisito irá oferecer suporte ao envio automático de mensagens com lembretes variados de eventos a acontecer e baixa automática de títulos bancários agendados.
Atores: Administrador
Prioridade: Essencial Importante Desejável
Versão 1.6 Março/2010
Documento de Requisitos <Opcional> Descrição da interface com o usuário – C4. P1 / 1
Capítulo
Requisitos não funcionais
Requisitos não funcionais, segundo KIRNER & DAVIS (1996), representam requisitos adicionais que definem as qualidades globais ou atributos a serem exibidos pelo sistema resultante. Segundo TURINE & MASIERO (1996), os requisitos não funcionais, também denominados requisitos de qualidade, incluem tanto limitações no produto (desempenho, confiabilidade e segurança) como limitações no processo de desenvolvimento (custos, métodos a serem adotados no desenvolvimento e componentes a serem reutilizados).Para CYSNEIROS (1997), os requisitos não funcionais, ao contrário dos funcionais, não expressam nenhuma função a ser realizada pelo software, e sim comportamentos e restrições que este software deve satisfazer.
Usabilidade
Usabilidade.NF001 - Consistência na InterfaceA interface com o usuário é de vital importância para o sucesso do sistema. Deverá ter uma interface amigável ao usuário primário sem se tornar cansativa aos usuários mais experientes.
Prioridade: Essencial Importante Desejável
Usabilidade.NF002 - AparênciaA tela seguirá o padrão de desenvolvimento com tela cinza e botões 3D
Prioridade: Essencial Importante Desejável
Confiabilidade
Confiabilidade.NF003 – Falhas Transitórias e Permanentes O sistema deverá identificar as falhas de inserção de entrada de dados, utilizando padrão de mensagens.
Prioridade: Essencial Importante Desejável
Confiabilidade.NF004 – Falhas Recuperáveis e Irrecuperáveis O sistema deverá identificar as falhas de cunho da intervenção da ação do usuário.
Prioridade: Essencial Importante Desejável
Confiabilidade.NF005 – Falhas de Corrompimento e Não corrompimento O sistema deverá identificar as falhas de inconsistência, pois o problema poderá ser da rede ou físico do equipamento.
Prioridade: Essencial Importante Desejável
Versão 1.6 Março/2010
Documento de Requisitos <Opcional> Descrição da interface com o usuário – C4. P2 / 2
Desempenho
Desempenho.NF006 – Tempo de RespostaAs páginas web não devem levar mais de 05 segundos para serem carregadas no navegador durante o uso normal do sistema.
Prioridade: Essencial Importante Desejável
Desempenho.NF007 – Tempo RealO sistema deverá agir de acordo com o tempo de sincronismo da plataforma cliente/ servidor.
Prioridade: Essencial Importante Desejável
Segurança
Segurança.NF008 – Perfis do UsuárioOs perfis do usuário para acessar o sistema são:a) Administrador – Irá administrar todos os módulos e terá permissão para inclusão,
exclusão, consulta e alteração de todo e qualquer registro.
b) Supervisor – Terá a permissão de inclusão, exclusão, consulta e alteração somente dos registros criados pelo o mesmo e poderá consultar e alterar registros criados por membros de seu departamento.
c) Cliente – Fará consultas e/ou inserção de devedores no Sistema BGMStadium via Web.
d) Devedor – Terá acesso somente às consultas do andamento processual de seus negócios, via Web.
e) Cobrador – Funcionário da empresa que irá efetuar o cadastro dos atendimentos, podendo incluir, alterar e consultar os registros.
Prioridade: Essencial Importante Desejável
Segurança.NF009 – CriptografiaAs senhas serão criptografadas para segurança do cliente.
Prioridade: Essencial Importante Desejável
Segurança.NF010 – AutenticaçãoA cada 5 minutos sem utilização dos sistema o mesmo solicitará autenticação do usuário.
Prioridade: Essencial Importante Desejável
Versão 1.6 Março/2010
Documento de Requisitos <Opcional> Descrição da interface com o usuário – C4. P3 / 3
Distribuição
Distribuição.NF011 – VersãoO versionamento do sistema será realizado, após uma cadeia/ conjunto de mudanças indicados por marcadores (checkpoint).
Prioridade: Essencial Importante Desejável
Padrões
Padrões.NF012 – Padrões UtilizadosO sistema deve obedecer aos seguintes padrões:a) Lei do Software – 9.609b) W3C Webc) IEEE 829d) Plataforma de Acessibilidade Padrão (norma ISO-9386-1 / NBR15655-1).
Prioridade: Essencial Importante Desejável
Hardware e software
Hardware e Software.NF013 – Banco de Dados
O sistema deverá utilizar banco de dados MySQL.
Prioridade: Essencial Importante Desejável
Hardware e Software.NF014 – Linguagem
Visando criar um produto com maior extensibilidade, reusabilidade e flexibilidade, deve ser adotada como linguagem principal de desenvolvimento Java, seguindo cuidadosamente as técnicas de orientação a objetos. Entretanto, outras linguagens também poderão ser usadas quando indicações técnicas recomendem. O uso da linguagem Java permite não especificar qual será o sistema operacional e a máquina em que o programa irá executar. No entanto, essa máquina deverá se comunicar com um sistema de banco de dados.
Prioridade: Essencial Importante Desejável
Versão 1.6 Março/2010
Documento de Requisitos <Opcional> Descrição da interface com o usuário – C4. P4 / 4
Manutenibilidade
Manutenibilidade.NF015Manutenções no aplicativo não descritos nesse documento será de responsabilidade do cliente.
Prioridade: Essencial Importante Desejável
Manutenibilidade.NF016Treinamento será efetuado a cargo da empresa desenvolvedora.
Prioridade: Essencial Importante Desejável
Versão 1.6 Março/2010
Top Related