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
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
Prioridade Essencial
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.
Prioridade Essencial
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.
Prioridade Essencial
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.
Prioridade Essencial
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.
Prioridade Essencial
[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”.
Prioridade Essencial
[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.
Prioridade Essencial
[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).
Prioridade Essencial
[RNF05] Performance
Descrição O sistema deve processar as simulações de crédito de forma rápida, sem travamento e de forma consistente.
Prioridade Essencial
[RNF06] Mantenabilidade
Descrição Deve permitir fácil atualização, reparo e melhorias, sem provocar a necessidade de ficar “fora do ar”.
Prioridade Essencial
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
Prioridade Essencial
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
Ator Cliente, Agente de crédito da EAC, Gerente da EAC
Prioridade Essencial
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
Prioridade Essencial
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
Ator Agente de crédito da EAC, gerente EAC
Prioridade Essencial
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
Ator Agente de crédito da EAC, gerente EAC
Prioridade Essencial
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
Prioridade Essencial
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.
Prioridade Essencial
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.
Prioridade Essencial
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
Ator Agente de crédito e gerente da EAC.
Prioridade Essencial
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.
Ator Cliente, Agente de crédito da EAC, Gerente da EAC
Prioridade Essencial
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.
Prioridade Essencial
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
Ator Agente de crédito e gerente da EAC.
Prioridade Essencial
Pré-Condição Usuário estar logado
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.
Prioridade Essencial
Pré-Condição Usuário estar logado
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
Prioridade Essencial
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%