Engenharia de Software

6
1 – DESCRIÇÃO DA EQUIPE PROFESSOR: Elvys Soares TURMA: 513-A EQUIPE: Nº: André Luiz de Oliveira Cezário 03 Elisângela Cabral da Silva 07 Thayná Vieira Wanderlei da Costa 34

description

Especificação de Requisitos e casos de uso

Transcript of Engenharia de Software

Page 1: Engenharia de Software

1 – DESCRIÇÃO DA EQUIPE

PROFESSOR: Elvys Soares

TURMA: 513-A

EQUIPE: Nº:

André Luiz de Oliveira Cezário 03

Elisângela Cabral da Silva 07

Thayná Vieira Wanderlei da Costa 34

Page 2: Engenharia de Software

2 – REQUISITOS FUNCIONAIS

Cadastrar de clientes (os clientes têm acesso ao sistema através de um cadastramento em caixas eletrônicos, internet ou no próprio banco, onde criam seus logins e senhas de acesso).

Efetuar login (para entrar no sistema via Internet, o cliente informa o login e a senha de acesso).

Fazer investimentos (o cliente que deseja fazer investimento no mercado de ações deve se cadastrar informando sua agência e número da conta).

Realizar consultas bancárias

o Consultar Extrato (consultas tipo extrato podem ser feitas escolhendo-se o tipo:

conta corrente ou poupança, permitindo ao usuário verificar as transações que foram realizadas em sua conta por um certo período com suas respectivas datas e valores).

o Consultar Saldo (Verifica a quantia que o cliente tem no banco naquele momento

em sua conta corrente ou poupança).

Efetuar transferências bancárias (entre contas correntes, conta corrente e poupança, poupança e conta corrente e entre uma conta do banco Qualiti e uma outra conta de outro banco (DOC eletrônico)).

Efetuar pagamento Qualiti Card (cartão de crédito)

Realizar operações com talões de cheque (solicitar, desbloquear e consultar talões de cheque).

Alterar senha de acesso

Realizar compra e venda de ações (do mercado brasileiro e internacional e ao comprar ações o valor da compra é debitado da conta corrente do cliente).

Disponibilizar consultas às cotações (apresentando um gráfico opcional com dados históricos e as informações disponíveis no sistema referentes às cotações não podem estar desatualizadas há mais de 5 minutos).

Page 3: Engenharia de Software

3 – REQUISITOS NÃO FUNCIONAIS

Usabilidade

Durante a fase de beta-testes, a interface deve ser considerada amigável e de fácil assimilação por 80% dos usuários envolvidos nos testes.

Confiabilidade

O sistema deve estar disponível 24 horas por dia, 7 dias por semana, com não mais que 2% do tempo com o sistema fora do ar.

Desempenho

1. O servidor Web do sistema deve suportar até 150 conexões simultâneas. 2. A escalação das tarefas não deve ser superior a 5 segundos.

Segurança

Para ter acesso ao sistema o cliente deve ter sua conta habilitada para uso do QIB através de cadastro em terminal eletrônico ou nas próprias agências do banco.

Se o usuário ficar 10 minutos sem realizar nenhuma operação no sistema, ele será desconectado do sistema (sua sessão será encerrada).

O sistema deve utilizar algum protocolo para envio de dados confidenciais pela Internet.

Hardware e software

1. O sistema deve integrar-se com o sistema de Operação do Qualiti Card, do Banco Qualiti, usando RMI.

2. A interface do usuário deve ser baseada na Web.

3. O sistema operacional utilizado deve oferecer suporte ao gerenciamento de processos, threads e escalonamento de tarefas.

4 – DIAGRAMAS DE CASOS DE USO

Page 4: Engenharia de Software

5 – ESPECIFICAÇÃO DE CASOS DE USO

1 – EFETUAR LOGIN

Este caso de uso é responsável por permitir o acesso do cliente ao sistema, que é feito mediante digitação da senha Internet Banking, login e número da agência e da conta. Este login é feito toda vez que o cliente acessa o Internet Banking.

Ator: Usuário

Prioridade: Essencial Importante Desejável

Requisitos Não Funcionais Associados: Disponibilidade, tempo de acesso, segurança do sistema.

Pré-condição: Usuário cadastrado no sistema e acessando a Internet.

Pós-condição: Usuário habilitado a usar o sistema.

Fluxo de eventos principal

1. O usuário escolhe a opção de Acesso a Conta.2. Ele digita o número da agência, número da conta, seu login e sua senha de acesso.

3. O sistema autentica o usuário e permite seu acesso.

Fluxos secundários

Autenticação do usuário

No passo 2, caso qualquer um dos dados digitados pelo usuário estejam incorretos, o sistema informará, através de uma mensagem, que os dados digitados estão incorretos e pedirá ao usuário que ele digite novamente seus dados.

Vender Ações

Page 5: Engenharia de Software

2 - COMPRAR AÇÕES

Este caso de uso é responsável por realizar a compra de ações.

Ator: Cliente e Mercado de Ações.

Prioridade: Essencial Importante Desejável

Requisitos Não Funcionais Associados: Disponibilidade, tempo de acesso, segurança do sistema, interface gráfica e desempenho.

Pré-condição: o cliente deve estar conectado ao sistema (ter efetuado o login) e estar cadastrado para comprar e vender ações.

Pós-condição: o valor da compra debitado na conta do cliente.

Fluxo de eventos principal

1. O cliente informa os dados necessários para a realização da compra:

De quem ele quer comprar as ações (BOVESPA, NASDAQ, MERVAL);

A quantidade de ações;

2. O sistema calcula o valor das ações a serem compradas.

3. O sistema verifica se o saldo da conta do cliente é suficiente para a realização da compra.

4. O sistema envia a compra à operadora do mercado de ações.

5. O valor é debitado da conta do cliente.

6. O QIB registra a ocorrência desta transação (uma compra de ações).

7. Emite-se um comprovante da compra para o usuário, contendo os dados da conta do usuário, data, valor da compra e de quem as ações foram compradas.

Fluxos secundários

No passo 3, se o saldo disponível na conta do usuário for menor que o valor da compra, o sistema informa que o saldo é insuficiente e retorna ao passo 1 do fluxo principal de eventos.

No passo 4, se a operadora do mercado de ações estiver inativa ou se ocorrer algum erro de comunicação que impeça a efetivação da transação, o sistema emite uma mensagem para o cliente e aborta a transação.

Em qualquer momento o usuário pode cancelar a operação.