in1020 engenharia de requisitos especificação de

IN1020 – Engenharia de Requisitos

Especificação de requisitos para sistema de integração de processos

em empresa de crédito Projeto II – Statechart, Casos de Uso e NFR

Professor: Jaelson Castro

Grupo 3:

Bruno de Souza Jeronimo – [email protected]

Priscila Lyra Cabral – [email protected]

Renato Atouguia Leite – [email protected]

Rodrigo Cosmo Silva da Costa – [email protected]

Recife, 11 de novembro de 2019

mailto:[email protected]




Sumário

Introdução 3

EAC 3

Funcionamento EAC 3

Stakeholders 4

Identificação do problema 5

Solução proposta 5

Objetivos da organização 5

Metodologia utilizada 6

Sistema proposto 6

Requisitos Organizacionais 7

Convenções 7

Requisitos funcionais (RF) 7

Requisitos não-funcionais 9

Casos de Uso 10

Convenções 10

Modelagens 17

Diagramas de casos de uso 17

NFR Framework (modelagem de requisitos não funcionais) 19

Segurança 21

Confiabilidade 22

Usabilidade 23

Portabilidade 24

Performance 25

Mantenabilidade 26

Statecharts 27

Conclusão 33

Contribuições dos membros 34

1. Introdução O presente trabalho visa apresentar a especificação de requisitos para um projeto

de um sistema de informação vinculado a uma empresa real através da identificação de

uma problemática de processo e de uma solução proposta. O produto final será a

modelagem de um sistema que atenda às necessidades do cliente apresentado nas

notações de Statechart, Casos de Uso e NFR framework.

1.1. EAC Por questões de NDA, trataremos o case como uma empresa anônima,

denominada de "Empresa Anônima de Crédito LTDA - EAC LTDA". A EAC é um

correspondente bancário, com sede em Goiás, que atua no mercado brasileiro como

promotora de crédito pessoal nas modalidades Crédito Direto ao Consumidor - CDC e

pessoal consignado.

1.1.1. Funcionamento EAC

A operação consiste basicamente em ações de levantamento e captação de

potenciais clientes para concessão de crédito. As atividades básicas são o recebimento

da base de contato de clientes (mailing) e contato via call center oferecendo tal serviço.

Em caso de sucesso na captação destes clientes, são elaborados contratos de

empréstimos para envio aos bancos, para que seja concluída a operação de crédito.

As ações realizadas para atividade da empresa são:

1. A empresa recebe lista de clientes por meio de planilhas (mailing) ou notificação

de contratos a renovar (CRM);

2. Consulta margem via sistemas de consulta online dos bancos;

3. Identifica os potenciais clientes para realizar contato;

4. Liga-se para o cliente oferecendo o serviço;

5. Realiza-se o contrato;

6. Comunica-se ao banco a liberação de crédito;

7. Banco credita valor em conta via TED;

No modelo atual de funcionamento da empresa, são utilizados, para a realização

de suas tarefas, editor de planilhas para manipular a relação de clientes (feito por

funcionário manualmente); PABX/URA (Call Center ativo); sistemas on-line dos bancos

para consulta de margem; processador de texto para elaboração dos contratos (feito

por funcionário manualmente); CRM para acompanhamento de contratos próximos a

finalizar (renovação).

À semelhança de outras empresas promotoras de crédito, a EAC serve como

intermediário no negócio de venda de crédito bancário a aposentados e pessoas físicas.

Esse modelo existe desde a formalização do correspondente bancário no brasil pela lei

3.954/2011. A EAC é remunerada, essencialmente, pelas comissões dos contratos

realizados. Adicionalmente, possuem uma base para marketing composta pelos

contatos dos clientes, que também possuem valor de mercado. Como forma de se

transformar, a EAC busca canais alternativos de captação de clientes, dentre eles a

LandingPage na Figura 1 abaixo, equipamentos de autoatendimento e um aplicativo

para instalação direto no equipamento do cliente.

Figura 1. Exemplo de plataforma online utilizada pela EAC LTDA.

A Figura 2 apresenta um organograma resumido da hierarquia da empresa. O

Marketing da empresa é terceirizado e, portanto, não consta no organograma direto da

empresa.

Figura 2. Organograma Empresa Anônima de Crédito LTDA - EAC LTDA.

1.1.2. Stakeholders

Os Atores interessados no processo são os descritos abaixo:

Stakeholder Descrição Função (tarefas) Expectativas

Empresa (Agente de crédito)

Quem faz o trabalho de busca e negociação dos empréstimos com

seus clientes

Analisar a base de dados com o cadastro de clientes selecionando os potenciais

para fazer contato; realizar o contato via telefone com os clientes a serem captados;

Negociar e convencer o cliente a realizar a

contratação do crédito.

Busca sucesso em suas captações de clientes com a finalidade de

rentabilizar o seu negócio através da

concessão de empréstimos.

Cliente Pessoa a quem se deseja conceder o

crédito.

Recebe o contato do agente de crédito e negocia o

empréstimo; Capta o recurso financeiro perante o banco.

Espera que a negociação e a

margem de crédito atendam seus

objetivos financeiros para que decida captar

o recurso.

Banco É o agente detentor dos

recursos financeiros e

quem realiza os pagamentos dos empréstimos aos

clientes e as comissões à EAC

Ltda.

Repassar a base de dados de clientes; realizar os

desembolsos financeiros dos créditos concedidos

Espera da EAC o cumprimento de

metas de captação de clientes visando

conceder mais crédito que contribuirão para

seus resultados financeiros.

1.2. Identificação do problema O problema chave detectado na empresa estudada é a falta de integração entre

seus processos, gerando pouco controle das etapas, sendo impossível o monitoramento

do que acontece, que tipo de sinergias são trocadas, causas de sucesso ou fracasso,

criação de relatórios e outras ferramentas para gestão da empresa.

O encadeamento de processos é majoritariamente manual, com as etapas de

troca de mensagens entre sistemas sendo realizadas de forma manual, com extenso uso

de papel e envio de arquivos por e-mail, gerando atrasos entre as ações de oferta,

consulta, negociação e conclusão da concessão de crédito. O conjunto de processos

realizados de forma manual inviabilizam a gestão efetiva das atividades e do negócio,

além de inviabilizar o aumento da escala de atendimento.

1.

1.3. Solução proposta

1.3.1. Objetivos da organização

Os principais objetivos e desejos da organização, com a inserção de um sistema

de automatização, são ganhos de escala, com possibilidade de extrapolar as limitações

do call center em termos de atraso, dar celeridade a este processo, ampliar o número

de atendimentos e solucionar o abismo informacional entre cada um dos agentes

envolvidos nos processos, eliminando etapas manuais, automatizando rotinas, gerando

relatórios concisos e em tempo real, com estatísticas e métricas acionáveis.

1.3.2. Metodologia utilizada

O estudo envolveu a aplicação de técnicas e ferramentas de modelagem de

sistemas. Foram realizadas entrevistas com um funcionário da empresa (agente de

crédito) para compreensão do cenário atual e expectativas quanto da solução a ser

proposta. Foram levantadas informações através de coleta de dados da própria empresa

e de empresas que operam no setor de crédito como forma de realizar benchmarking.

1.3.3. Sistema proposto

O sistema proposto consiste em uma aplicação de celular (app) visando

centralizar e automatizar o maior número de etapas possíveis dentre o processo de

concessão de crédito. Para isso, foram estudados os processos da empresa e suas

interconexões com os clientes e demais atores identificando etapas no processo de

concessão de crédito.

2. Requisitos Organizacionais A empresa espera que a solução proposta facilite a sua operação de concessão

de crédito permitindo que as tarefas necessárias estejam todas integradas e

automatizadas, sem a necessidade de ações realizadas de forma manual. Com a solução

em forma de APP ela pretende ganhar escala atingindo o maior número de clientes e

com isso aumentar seus resultados financeiros.

2.1. Convenções Cada requisito deverá ter um nome e um código identificador, uma descrição,

um nível de prioridade e deve estar relacionado a algum uso de caso. O código

identificador é composto por RF##, para requisitos funcionais, e RNF##, para requisitos

não-funcionais, nos quais ## representa um número. A Tabela 1 mostra o leiaute para

os requisitos. Os níveis de prioridade possíveis são:

● Essencial: Requisito indispensável, sem o qual o sistema fica comprometido, não

atinge às expectativas do cliente.

● Importante: Requisitos sem os quais o sistema funciona, mas o cliente não fica

completamente satisfeito.

● Desejável: Requisito dispensável, sua implementação deixa o sistema mais

completo.

Tabela 1. Template dos requisitos Organizacionais

[Identificador] Nome

Descrição

Prioridade

UC Relacionado

2.2. Requisitos funcionais (RF) Segue abaixo os requisitos funcionais propostos para o sistema de aplicativo para

a empresa EAC-LTDA.

[RF01] Gerenciar perfis de Usuário

Descrição O sistema deverá ser capaz de lidar com perfis de usuário e permissões, sendo possível a gestores, agentes de crédito e clientes, dentro de suas necessidades, se conectarem a plataforma através de sessões logadas e autenticadas com usuário e senha, realizar tarefas permitidas aos seus papéis, e manter histórico de operações, bem como solicitar a exclusão de seus perfis. Somente gestores podem excluir perfis de usuário.

Prioridade Essencial

UC Relacionado

UC01, UC02, UC05, UC09, UC12

[RF02] Produzir ofertas de crédito

Descrição O sistema deverá se alimentar dos dados pré-existentes da EAC, além de absorver dados de outras fontes, como inputs dos gestores, agentes de crédito, clientes, e ferramenta de mailing, com a finalidade de produzir ofertas de crédito para potenciais clientes


UC Relacionado

UC10

[RF03] Gerenciar contratos

Descrição O sistema deve permitir aos gestores e agentes de crédito realizarem a gestão (acompanhamento e possíveis renovações) dos contratos, sendo possível visualizar os contratos ativos dos clientes, gerar novas minutas, corrigir contratos, autorizar ou negar novos contratos, verificar contratos pendentes e cancelar contratos. Aos clientes, será possível acompanhar a situação dos seus contratos, assinar contratos, solicitar correções, e cancelar contratos pendentes.


UC Relacionado

UC03, UC08, UC11, UC13, UC14, UC15, UC16, UC17

[RF04] Realizar simulação de crédito

Descrição O sistema deve permitir aos agentes de crédito e clientes realizarem a simulações de crédito, verificando as margens mínimas e máximas oferecidas, limites disponíveis, taxas de juros praticadas, tipos de empréstimo disponível por instituição financeira, condições de parcelamento e custos efetivos da transação.


UC Relacionado

UC04

[RF05] Visualizar relatórios gerenciais

Descrição O sistema deve permitir aos gestores e agentes de crédito emitir relatórios que cruzem dados estatísticos sobre temas de interesse da gestão. Deverão ser acessíveis relatórios dos seguintes indicadores de performance: Número de contratos realizados por horizonte de tempo, número de clientes ativos na plataforma por horizonte de tempo, taxa de captação de novos clientes por horizonte de tempo, número de contratos cancelados e motivos do cancelamento, quantidade de contratos renovados por horizonte de tempo, número de contratos realizados por agente de crédito, número de contratos por instituição financeira, número de contratos por região/localidade, número de acessos de clientes na

plataforma, quantidade de downloads realizados da aplicação. Os relatórios poderão ser impressos, e exportados para PDF ou xls.


UC Relacionado

UC06, UC07

2.3. Requisitos não-funcionais

Os requisitos que representam os aspectos não-funcionais do sistema serão

apresentados a seguir.

[RNF01] Segurança

Descrição O sistema deve garantir proteção dos dados dos usuários e acesso à ferramenta através de senha criptografada. Deve se comunicar com sistemas externos de fornecedores e parceiros. Este acesso deve ser seguro, com autenticação e uso de criptografia.


[RNF02] Confiabilidade

Descrição O sistema deve estar disponível em 99% das situações em que for demandado acesso e com taxa de falhas “próximo de zero”.


[RNF03] Usabilidade

Descrição O sistema de ser intuitivo, com facilidade de operação pelos usuários. Deverá possuir design amigável, com cores, fontes e botões seguindo um mesmo modelo e padrão entre telas.


[RNF04] Portabilidade

Descrição Deverá ser desenvolvido de forma a possibilitar sua instalação em sistemas android e IOS visando atender o máximo possível de clientes (ser escalável).


[RNF05] Performance

Descrição O sistema deve processar as simulações de crédito de forma rápida, sem travamento e de forma consistente.


[RNF06] Mantenabilidade

Descrição Deve permitir fácil atualização, reparo e melhorias, sem provocar a necessidade de ficar “fora do ar”.


3. Casos de Uso

3.1. Convenções Os casos de uso deste documento deverão possuir um identificador único do tipo

UC##, onde ## representa um número. Os casos de uso seguem o leiaute mostrado na

Tabela 2.

Tabela 2. Template dos Casos de Uso

[Identificador] Nome

Descrição

Ator

Prioridade

Pré-Condição

Pós-Condição

Fluxo Principal

Fluxo Secundário

RF Relacionado

Segue abaixo a lista de casos de uso para o sistema de aplicativo proposto à

empresa EAC-LTDA.

[UC01] Cadastrar Usuário

Descrição Novos usuários devem ser capazes de criar uma conta no sistema.

Ator Cliente, Agente de crédito da EAC, Gerente da EAC


Pré-Condição Usuário não possuir cadastro no sistema.

Pós-Condição Usuário ter permissão para acessar o sistema.

Fluxo Principal 1. Usuário navega até a página de cadastro. 2. Usuário informa seu nome, CPF, telefone, e-mail e senha. 3. Usuário espera a validação dos campos informados. 4. Usuário é redirecionado para a página de Log In.

Fluxo Secundário

No passo 2, caso o e-mail e o CPF informados já estejam cadastrados, uma mensagem é exibida informando que o e-mail ou o CPF já está cadastrado e o usuário é redirecionado para a página de Log In.

RF Relacionado RF01

[UC02] Realizar Log In

Descrição O usuário já cadastrado deve entrar em sua conta do sistema



Pré-Condição Usuário possuir cadastro

Pós-Condição Usuário tem acesso ao sistema

Fluxo Principal 1. Usuário realiza Log In, utilizando e-mail e/ou CPF juntamente com a senha, na tela de início. 2. Usuário espera a validação dos campos informados. 3. Usuário é redirecionado para a página de pessoal.

Fluxo Secundário

No passo 2, caso o e-mail e/ou CPF e/ou senha informados não correspondam aos dados cadastrados, uma mensagem é exibida informando que alguma informação está errada e o usuário é redirecionado para a página de Log In.

RF Relacionado

RF01

[UC03] Renovação de contratos

Descrição Contratos vigentes, com validade próxima ao fim, podem ser renovados

Ator Agente de crédito da EAC, gerente EAC

Prioridade Importante

Pré-Condição O contrato existir e estar vigente

Pós-Condição Novo contrato com condições atualizadas

Fluxo Principal 1. Agente de crédito acessa lista de contratos a vencer 2. Agente entra em contato com cliente 3. Agente negocia com cliente 4. Agente atualiza o contrato com as novas condições e/ou

valores

Fluxo Secundário

No passo 2, o cliente pode se recusar a negociar, encerrando o processo de renovação de contrato.

RF Relacionado RF03

[UC04] Simular crédito

Descrição O usuário pode realizar simulações de contrato de crédito.

Ator Cliente, Agente de crédito


Pré-Condição Usuário ter acesso ao sistema

Pós-Condição Usuário tem informações necessárias para decidir se irá realizar contrato

Fluxo Principal 1. Usuário insere informações adicionais 2. Sistema consulta bancos 3. Sistema apresenta simulação de crédito, apresentando

margens mínimas e máximas oferecidas, limites disponíveis, taxas de juros praticadas, tipos de empréstimo disponível por instituição financeira, condições de parcelamento e custos efetivos da transação.

4. Usuário conclui simulação

Fluxo Secundário

No passo 4, o usuário pode solicitar nova simulação, retornando para o passo 1.

RF Relacionado RF04

[UC05] Cadastro Novo Cliente

Descrição Agente de crédito pode cadastrar novos clientes



Pré-Condição Agente estar logado, cliente não possuir cadastro

Pós-Condição Agente tem acesso a simulações e contratos do cliente; Cliente tem cadastro e pode acessar o aplicativo

Fluxo Principal 1. Agente de crédito entra em contato com possível cliente 2. Agente coleta dados de potencial cliente 3. Agente realiza o cadastro

Fluxo Secundário

Não se aplica.

RF Relacionado

RF01

[UC06] Relatórios e estatísticas

Descrição Geração de relatórios e gráficos estatísticos



Pré-Condição Agente estar logado no sistema

Pós-Condição Agente ter acesso a informações referentes ao seu desempenho em determinado período de tempo.

Fluxo Principal 1. Agente de crédito escolhe tipo de relatório (Número de contratos, número de clientes ativos, taxa de captação de novos clientes, número de contratos cancelados e motivos do cancelamento, quantidade de contratos renovados, número de contratos por instituição financeira, número de contratos por região/localidade, número de acessos de clientes na plataforma, quantidade de downloads realizados da aplicação) e período de análise

2. Agente solicita geração de relatórios 3. Sistema apresenta relatório ao agente 4. Agente imprime relatório

Fluxo Secundário

No passo 4, o agente pode imprimir fisicamente, digitalmente ou apenas consultar o relatório

RF Relacionado

RF05

[UC07] Relatórios de gestão

Descrição Geração de relatórios e gráficos estatísticos

Ator Gerente da EAC

Prioridade Desejável

Pré-Condição Gerente estar logado no sistema

Pós-Condição Gerente ter acesso a informações referentes ao desempenho da equipe em determinado período de tempo.

Fluxo Principal 1. Gerente escolhe tipo de relatório, período, funcionário para análise 2. Gerente solicita geração de relatórios 3. Sistema apresenta relatório ao gerente 4. Gerente imprime relatório

Fluxo Secundário

No passo 4, o gerente pode imprimir fisicamente, digitalmente ou apenas consultar o relatório

RF Relacionado

RF05

[UC08] Assinar contrato

Descrição Cliente confirma contratação de crédito

Ator Cliente


Pré-Condição Cliente aceitar proposta da simulação, sistema gerar contrato

Pós-Condição Cliente tem contrato finalizado

Fluxo Principal 1. Sistema apresenta contrato 2. Cliente confirma interesse 3. Sistema apresenta resumo das informações contratuais 4. Cliente confirma interesse

Fluxo Secundário

Nos passos 2 e 4, o cliente pode desistir da operação e retornar à tela de início

RF Relacionado

RF03

[UC09] Visualizar histórico de operações

Descrição Usuários visualizam histórico de operações (minutas, contratos, aceites, recusas e etc)

Ator Cliente, Agente de crédito e gerente da EAC.


Pré-Condição Usuário estar logado.

Pós-Condição Usuário possui acesso ao histórico.

Fluxo Principal 1. Usuário seleciona visualizar histórico 2. Usuário selecionar retornar após visualizar histórico.

Fluxo Secundário

No passo 2, o usuário pode exportar informações.

RF Relacionado RF01

[UC10] Produzir oferta de crédito

Descrição O sistema produz ofertas de crédito para potenciais clientes

Ator Agente de crédito e gerente da EAC.


Pré-Condição Inputs dos gestores, agentes de crédito

Pós-Condição Oferta de crédito a ser divulgada para potenciais clientes.

Fluxo Principal 1. Usuário insere dados de potenciais clientes 2. Sistema retorna com oferta de crédito 3. Usuário compartilha oferta com potencial cliente

Fluxo Secundário

Não se aplica.

RF Relacionado RF02

[UC11] Gerar novas minutas

Descrição Gerar novas minutas



Pré-Condição Usuário estar logado

Pós-Condição Nova minuta gerada

Fluxo Principal

Fluxo Secundário

RF Relacionado RF03

[UC12] Solicitar exclusão de perfil

Descrição O usuário deve poder solicitar a exclusão de seu perfil.



Pré-Condição Usuário possuir cadastro no sistema.

Pós-Condição Usuário não possuir cadastro

Fluxo Principal 1. Usuário solicita exclusão de seu perfil 2. Usuário aguarda confirmação

Fluxo Secundário

O passo 2 pode acontecer em segundo plano, podendo o usuário navegar em outras seções do aplicativo.

RF Relacionado RF01

[UC13] Corrigir contratos

Descrição Usuário deve poder corrigir contratos

Ator Gerente da EAC.


Pré-Condição Usuário estar logado e cliente ter realizado solicitação para correção de contrato.

Pós-Condição Contrato corrigido

Fluxo Principal 1. Gerente avalia a solicitação de correção de contrato

2. Gerente realiza alterações 3. Gerente envia notificação ao cliente

Fluxo Secundário

No passo 2, o gerente pode recusar a solicitação

RF Relacionado RF03

[UC14] Cancelar contrato

Descrição Usuário pode cancelar contratos




Pós-Condição Contrato cancelado

Fluxo Principal 1. Usuário seleciona contrato 2. Usuário cancela contrato 3. Usuário registra motivo do cancelamento

Fluxo Secundário

No passo 2, o usuário pode desistir da operação

RF Relacionado RF03

[UC15] Verificar contratos pendentes

Descrição O usuário pode verificar contratos pendentes

Ator Cliente, Agente de crédito e gerente da EAC.



Pós-Condição O contrato ser visualizado

Fluxo Principal 1. O usuário acessa lista de contratos pendentes 2. Usuário seleciona contrato para visualização 3. Usuário confirma contrato

Fluxo Secundário

No passo 3, o usuário pode cancelar o contrato ou retornar à Home

RF Relacionado RF03

[UC16] Solicitar correções

Descrição O cliente deve solicitar correções

Ator Cliente


Pré-Condição Cliente ter contrato válido, pendente ou a renovar.

Pós-Condição Contrato enviado para correção

Fluxo Principal 1. Cliente seleciona contrato de sua lista 2. Cliente solicita alterações no contrato 3. Contrato é enviado para análise e correção

Fluxo Secundário

Em qualquer passo o usuário pode cancelar o processo

RF Relacionado RF03

4. Modelagens

4.1. Diagramas de casos de uso A Figura 3 apresenta os casos de uso do aplicativo a ser criado para empresa EAC

– LTDA. Os casos de uso já foram descritos na seção 3. Podemos agrupá-los de acordo

com a necessidade do ator, assim, o Cliente poderá realizar seu Cadastro Pessoal, seu

Login, uma ou mais simulações de crédito, assinar o contrato, solicitar exclusão de perfil,

visualizar histórico de operações e verificar contratos pendentes; o Agente de Crédito

da empresa EAC pode Cadastrar Novos Clientes, Realizar seu próprio Cadastro Pessoal,

seu Login, Renovar contratos, Gerar Novas Minutas, Simular Crédito, Gerar Relatórios e

Estatísticas, Verificar contratos pendentes, Visualizar histórico de operações, Solicitar

exclusão de perfil, cancelar contratos e produzir oferta de crédito;

O Gerente da empresa, é um ator filho do Agente de Crédito, portanto, pode

realizar qualquer um dos usos do agente além de ter acesso a relatórios de gestão, em

que poderá acompanhar a produtividade dos agentes e da empresa, e corrigir contratos.

Diversas etapas do sistema tem entradas do “Bot” que realizará pesquisas externas com

o banco.

Dentro da notação são visíveis os relacionamentos de inclusão entre os casos de:

● Gerar novas minutas e Cadastro Usuário

● Cadastro Usuário e Realizar Login

Figura 3. Diagrama de Casos de Uso para aplicativo da EAC - LTDA

4.2. NFR Framework (modelagem de requisitos não funcionais)

Os requisitos não funcionais (identificados na seção 2.3) estão relacionados aos aspectos qualitativos de uso da ferramenta e a preocupação da EAC será satisfazer como foco principal, em termos de experiência de usuário, os clientes finais. Estes requisitos dizem respeito a como as funcionalidades serão entregues ao usuário do software. Após a análise de que RNFs seriam os mais importantes para a aplicação, preferiu-se dar foco nos aspectos de segurança, confiabilidade, usabilidade, portabilidade, performance e mantenibilidade, os quais estão classificados no framework com seus respectivos atributos e contribuições.

Figura 4. Diagrama de Requisitos Não-funcionais para aplicativo da EAC - LTDA

4.2.1. Segurança

O Requisito segurança leva em consideração que a aplicação deve contemplar

regras e protocolos de proteção para criação e manutenção de usuários e senhas. Por

isso softgoals como Integridade, confidencialidade e disponibilidade são essenciais na

execução de ações como cadastramento de usuário, realizar login, gerar contrato e

simular crédito, pois envolvem dados privativos dos usuários e comunicação da

ferramenta com sistemas de bancos parceiros. Apesar de serem operacionalmente

vantajosos para Segurança esses dois itens são telas a mais no fluxo, gerando um trade-

off negativo com Usabilidade.

2.

4.2.2. Confiabilidade

A aplicação deve conter políticas de backup do sistema e seus dados, para que

nos momentos de processamento de operações e cálculos das simulações de crédito,

não ocorram (ou ocorram em percentual bem reduzido) erros que prejudiquem as

operações, e mesmo ocorrendo, possam ser sanados rapidamente, e para isso a

ferramenta deve ser tolerante e responsiva a falhas proporcionando confiança aos

usuários. Essa uma característica que possui uma relação positiva com a disponibilidade

do sistema.

3.

4.2.3. Usabilidade

Ao interagir com a ferramenta, os usuários não devem sentir dificuldade em

operá-la. Devem ser priorizados softgoals como acessibilidade e intuitividade,

operacionalizados através de utilização de cores, fontes e botões que facilite a UX e para

que também facilite o aprendizado do manuseio da ferramenta. Um fluxo de tela mais

enxuto também é operacionalmente vantajoso para aplicação no sentido da

intuitividade e da usabilidade. Entretanto, gera um trade-off negativo com a segurança,

pois itens excessivos de login geram telas adicionais e ameaçam o nível de interesse do

usuário.

4.2.4. Portabilidade

Outro requisito a ser atendido como essencial é a portabilidade da aplicação para

que a mesma possa ser utilizada pela maior gama de usuários possível, e isso só será

possível com o sistema operacional desenvolvido para que seja compatível com android

e IOS. Isto permitirá que a ferramenta ganhe capacidade de distribuição e escalabilidade

a uma infinidade de usuários.

4.2.5. Performance

Um fator que pode fazer o usuário desistir de utilizar a aplicação com certeza é

relacionado à performance. Este é um requisito chave, pois com a garantia de

performance a ferramenta terá consistência na execução do processamento das ações

evitando travamento da aplicação como também agilidade na resposta das simulações

e na geração do contrato.

4.2.6. Mantenabilidade

Um RNF indispensável para uma ferramenta com escopo financeiro é sua

capacidade de ser posta em constante manutenção para atualização de software, seja

para implantação de melhorias (evolutividade), seja para atualização de bases de dados,

sem que a ferramenta entre em indisponibilidade, prejudicando a atividade da empresa.

4.3. Statecharts A Figura 5 mostra o diagrama de estados, Statechart para sistema a ser

implementado pela EAC-LTDA. O propósito do Statechart é demonstrar o possíveis

caminhos a serem percorridos dentro da possíveis contextos que a aplicação pode

assumir. Essa representação torna confortável o entendimento por parte do time de

implementação de quais serão as pilhas de interação junto ao usuário e até mesmo na

concepção de user experience.

O aplicativo tem início no Standby, enquanto aguarda que o usuário escolha se

será um cliente ou um agente de crédito, essa divisão direta foi introduzida para que os

estados fossem definidos isoladamente dentro de cada região sem compartilhamento

de estados, como login. Essa divisão trouxe simplicidade ao desenho da solução e

flexibilidade para se pensar em fluxos distintos desde a forma como se autentica no

sistema, usando-se se for preciso métodos mais rebuscados ao agente de crédito. Uma

vez escolhida a opção o aplicativo segue um fluxo diferente para cada usuário,

considerando suas nuances de alçada e gerando uma pilha baseada nos seus processos

de negócio específicos.

O usuário contratante de crédito, chamado e representado na área "Cliente"

permite a visualização das etapas principais do processo de negócio do contratante:

Simulação e Confirmação. Essa etapas possuem estados intermediários entre si, sendo

ambas descritas anteriormente na ordem possível de ativação desses estados. Os

estados como são sequenciados na imagem podem e são relacionados a telas que

solicitam dados, como a de simulação e os exibem, como os estados iniciados por

"Mostra". Importante frisar a existência de estados "paralelos" ao final do processo de

contratação, nesse momento o estado padrão é o notificação da confirmação e

simultaneamente, o estado de processamento do contrato é iniciado.

Na região associada ao agente de crédito da EAC estão presente estados

associados a tarefas táticas e operacionais, dentre elas se destacam na operação: o

monitoramento das simulações e finalização do contrato. Em efeito gerencial, a

aplicação pode assumir o estado de "Exibir Relatórios e Estatísticas", ou simplesmente

um Dashboard com KPI's correlacionados às simulações (fonte de Leads) e contratação.

É necessário destacar que o estado de confirmação depende do usuário confirmar a

segunda parte da contratação. Nesse transição, o estado padrão é dado como aguardar,

mas paralelo a ele é criado um estado latente que é deixado para trás assim que é

recebida uma notificação, dando seguimento a renovação do contrato.

A concepção do statechart, como dito, está associada a UX e consequentemente

ao front end da solução, sendo um bom artefato a ser seguido pelo time de

desenvolvimento na construção do storyboard da interface de usuário.

Figura 5a. Statechart para aplicativo da EAC - LTDA

Figura 5b. Recorte Agente de Crédito (parte 1) Statechart para aplicativo da EAC - LTDA

Figura 5c. Recorte Agente de Crédito (parte 2) Statechart para aplicativo da EAC - LTDA

Figura 5d. Recorte Cliente Statechart para aplicativo da EAC - LTDA

5. Conclusão Neste documento foram especificados, dentro do contexto elicitado no Projeto

inicial, os requisitos funcionais, não funcionais, casos de uso e diagramas de estado do

sistema a ser implementado, garantindo que o produto a ser desenvolvido seja

compreendido de todos os ângulos.

Para a EAC, ficam claros os objetivos / funcionalidades contratadas em relação

ao produto em ser. Para os desenvolvedores, todos os parâmetros são claros os

suficientes para implementação, com as restrições e qualidades esperadas.

Por fim, destacamos a importância de praticar os conceitos apresentados na

disciplina, assim como uso das ferramentas relacionadas num caso real, enriquecendo

nossa formação.

6. Contribuições dos membros

Nome do membro Papel Esforço na equipe (%)

Assinatura

Bruno de Souza Jeronimo

Requisitos, Relatório, Casos de uso

25%

Priscila Lyra Cabral Requisitos, Relatório, Casos de uso e Statechart

25%

Renato Atouguia Leite

Statechart 25%

Rodrigo Cosmo S. da Costa

NFR 25%

in1020 engenharia de requisitos especificação de

Documents