Sistema de Leilão Eletrônico

1
Especificação de Requisitos e Validação
de Sistemas
PREGÃO ELETRÔNICO
COELHO INFO - LicitSys
CURSO: CIÊNCIA DA COMPUTAÇÃO
DATA: 22/06/2015
NOME(S) DO(S) ALUNO(S):
Amintas Dutra Coelho
Fernando Maranhão Pessoa Nazareth
Guilherme Leite de Moura de Paiva
Edson Barboza de Lima
PROFESSOR:
Jaelson Freire Brelaz de Castro

2
Sumário
1.1 Motivação.................................................................................................................... 5
1.2 Sobre a Organização................................................................................................... 5
1.3 O Problema Identificado .............................................................................................. 6
1.4 Convenções para Identificação dos requisitos............................................................. 6
1.5 Convenções para Identificação dos casos de uso ....................................................... 6
1.5.1 Estrutura dos Casos de Uso ................................................................................. 7
1.5.2 Prioridades dos Casos de Uso.............................................................................. 7
1.5.3 Descrição dos atores ............................................................................................ 7
2. Requisitos Organizacionais ........................................................................................... 8
3. Requisitos Funcionais ................................................................................................... 8
3.1 Requisitos Comuns aos Usuários................................................................................ 8
3.1.1 [RF01] Autenticar Usuário..................................................................................... 8
3.1.2 [RF02] Efetuar Logoff............................................................................................ 8
3.2 Requisitos do Analista ................................................................................................. 9
3.2.1 [RF03] Cadastrar Itens para Análise do Gerente................................................... 9
3.2.2 [RF04] Cadastrar URL do pregão no sistema........................................................ 9
3.2.3 [RF05] Cadastrar data e hora de início do pregão................................................. 9
3.2.4 [RF06] Realizar Proposta Inicial.......................................................................... 10
3.2.5 [RF07] Analisar Valores ...................................................................................... 10
3.2.6 [RF08] Disputar Item ........................................................................................... 10
3.2.7 [RF09] Enviar Documentação online................................................................... 10
3.2.8 [RF10] Enviar Documentação pelos correios ...................................................... 11
3.3 Requisitos de Gerente............................................................................................... 11
3.3.1 [RF11] Validar Itens Pendentes no Sistema........................................................ 11
3.4 Requisitos de Contador ............................................................................................. 11
3.4.1 [RF12] Gerar relatório contábil ............................................................................ 11
3.4.2 [RF13] Gerar relatório financeiro......................................................................... 12
3.5 Requisitos do Órgão Público ..................................................................................... 12
3.5.1 [RF14] Fornecer Parecer..................................................................................... 12
3.5.2 [RF15] Confirmar Recebimento........................................................................... 12
4. Requisitos Não Funcionais.............................................................................................. 13
4.1 Requisitos de Processo............................................................................................. 13
4.1.1 [NFR01] Utilizar o framework Ruby on Rails ....................................................... 13
4.1.2 [NFR02] Utilizar o banco de dados MySQL......................................................... 13
4.1.3 [NFR03] Utilizar o SCRUM como metodologia de desenvolvimento.................... 13

3
4.2 Requisitos de Produto ............................................................................................... 14
4.2.1 [NRF04] Disponibilidade...................................................................................... 14
4.2.2 [NFR05] Interface Intuitiva................................................................................... 14
4.2.3 [NFR06] Tutoriais................................................................................................ 14
4.2.4 [NFR07] Integridade............................................................................................ 15
4.2.5 [NFR08] Backup.................................................................................................. 15
4.2.6 [NFR09] Tempo de Resposta.............................................................................. 15
4.2.7 [NFR10] Restrição de Acesso ............................................................................. 15
4.2.8 [NFR11] Mensagens de Erro............................................................................... 16
4.2.9 [NFR12] Padronização........................................................................................ 16
4.3 Requisitos Externos................................................................................................... 16
4.3.1 [NFR13] Orçamento............................................................................................ 16
4.3.2 [NFR14] Tempo de Desenvolvimento.................................................................. 17
4.3.3 [NFR15] Integração com Sistema Externo .......................................................... 17
5. Descrição de Casos de Uso............................................................................................ 17
5.1 [UC01] Autenticar Usuário ......................................................................................... 17
5.2 [UC02] Cadastrar Itens para Análise do Gerente....................................................... 18
5.3 [UC03] Validar Itens Pendentes no Sistema.............................................................. 19
5.4 [UC06] Cadastrar Pregão .......................................................................................... 19
5.5 [UC07] Disputar Leilão............................................................................................... 20
5.6 [UC06] Enviar Documentação ................................................................................... 21
5.7 [UC07] Enviar Parecer............................................................................................... 21
5.8 [UC08] Confirmar Recebimento................................................................................. 22
5.9 [UC09] Efetuar Logoff................................................................................................ 22
5.10 [UC10] Gerar Relatórios .......................................................................................... 23
6. Modelagem de Comportamento do Sistema (Statechart)................................................ 23
7. Modelagem de Processo de Negócio (BPMN) ................................................................ 25
8. Modelagem de Requisitos Não Funcionais (NFR Framework) ........................................ 29
9. Modelagem de Caso de Uso........................................................................................... 30
10. Modelagem Organizacional (i*) ..................................................................................... 32
11. Conclusão..................................................................................................................... 34
12. Relatório da Equipe....................................................................................................... 34
13. Apêndices..................................................................................................................... 34
13.1. Entrevista Realizada para levantamento de requisitos não funcionais.................... 34
13.2. Glossário com termos utilizados no negócio........................................................... 35

4
13.3. Documento de proposta da Coelho Info que utilizamos para compreender melhor o
processo.......................................................................................................................... 36
13.4. Contrato social da Coelho Info, necessário para conheceremos os dados da
empresa .......................................................................................................................... 36

5
1. Introdução
O Objetivo deste documento é descrever o problema que foi identificado e
especificar os requisitos para a solução encontrada durante a fase de estudo de
viabilidade realizada previamente. Essa solução tem como objetivo principal o
desenvolvimento de um sistema web que deve ser construído a partir das
informações capturadas pela utilização de algumas técnicas que serão descritas
posteriormente.
O objetivo deste estudo é propor um sistema que diminua o trabalho manual
realizado por funcionários da empresa de comércio varejista COELHO INFO. A
partir do levantamento prévio com o proprietário da empresa, a implantação do
sistema proposto almeja aumentar a eficiência operacional e por consequência
aumento nos lucros da empresa.
1.1 Motivação
As atividades realizadas na empresa COELHO INFO são em sua grande
maioria manuais. No entanto, há uma excelente oportunidade de automação de
processos com objetivo de ganho operacional. Diversas oportunidades são
desperdiçadas por sobrecarga ou falta de atenção humana. Por isso a proposta de
se automatizar por meio de um sistema web o gerenciamento de um pregão
eletrônico, desde o início da disputa dos itens até o momento em que a empresa
envia os documentos que são necessários para efetivar sua classificação.
1.2 Sobre a Organização
A COELHO INFO (CNPJ: 13.641.994.0001-77) registrado como pessoa
jurídica AMINTAS C. M. DUTRA COMERCIO DE ELETRÔNICOS localizada em
Recife, no bairro de Afogados, é uma pequena empresa de comércio varejista
especializado em equipamentos e suprimentos de informática. Atualmente conta
com 5 funcionários sendo três analistas, um gerente e um contador. A empresa
executa suas vendas predominantemente através de Pregões Eletrônicos para
autarquias e órgãos públicos municipais, estaduais e federais.
Atualmente a COELHO INFO disputa licitações sobre os portais: Compras
Net, Banco Brasil, Caixa Econômica Federal e Rede Compras PE. De forma sucinta,
a empresa prospecta oportunidades em todo território nacional, identificando
tecnicamente as configurações solicitadas nas licitações. Mediante o conhecimento
dos equipamentos necessários e empresa realiza uma cotação no mercado a
procura do fornecedor buscando a condição mais competitiva que atenda ao
produto solicitado. Após a identificação do preço a COELHO INFO providencia o
cadastro de propostas nos respectivos portais de disputa e caso saiam

6
arrematantes, devem atender mais duas etapas respectivamente: Adjudicação e
Homologação de proposta.
A primeira etapa consiste no envio de documentos via correio eletrônico e em
alguns casos via correio convencional. A segunda etapa é a confirmação por parte
do órgão pedinte em questão. Mesmo não sendo arrematantes os concorrentes
remanescentes podem ser convocados, devido algum problema por parte do
arrematante sobre alguma dessas duas etapas durante o processo. Assim, os
demais remanescentes devem acompanhar os chamados dos órgãos públicos
mesmo após arrematação.
Após Homologação, a empresa aguarda ser gerado o “Empenho”, de forma
que vale ressaltar que os pregões podem ser pelo Sistema de Registro de Preços
quanto Pregão, ou seja, Empenho do pedido todo item de uma só vez ou
parceladamente.
1.3 O Problema Identificado
O objetivo do desenvolvimento deste sistema é aumentar a eficiência
operacional da empresa supracitada, utilizando da mesma força de trabalho
disposta atualmente.
Após entrevista com o proprietário da empresa, o Sr. José Amintas, foi
entendido o funcionamento da empresa bem como os principais pontos que a
empresa almeja melhorar. Disto posto, a sobrecarga e erros por falta de atenção
humana foram identificados como sendo os principais fatores que impedem que a
empresa possa auferir um lucro maior com a mesma capacidade de pessoal.
A conclusão feita pelo proprietário da empresa é de que se alguns processos
forem automatizados e gerenciados por um sistema, a empresa poderá melhorar
sua eficiência operacional e diminuir certos gargalos e problemas já identificados.
1.4 Convenções para Identificação dos requisitos
Por convenção, os requisitos são indicados e referenciados por um indicador
no formato [RFXX], para os requisitos funcionais, e no formato [RNFXX], para os
não funcionais, onde XX se refere ao número do requisito. Os requisitos também
possuirão os nomes dos casos de uso relacionados.
1.5 Convenções para Identificação dos casos de uso
Por convenção, os casos de uso são indicados e referenciados por um
indicador no formato [UCXX], onde XX se refere ao número do caso de uso.

7
1.5.1 Estrutura dos Casos de Uso
Cada caso de uso terá o seguinte formato:
● Atores: Os modelos de usuário que utilizarão os casos de uso;
● Prioridade: Prioridade de implementação deste caso de uso;
● Entradas: Variáveis que serão passadas ao sistema;
● Pré-condições: Condições que devem ser satisfeitas antes de o caso de uso
ser executado, quando for o caso;
● Fluxo de eventos: O passo a passo das ações realizadas para que o caso
de uso seja concluído, podendo incluir fluxos de eventos secundários e/ou
alternativos;
● Saídas: Saídas que devem ser fornecidas pelo sistema quando o caso de
uso for executado;
● Pós-condições: Condições que devem ser satisfeitas depois do caso de uso
ser finalizado.
1.5.2 Prioridades dos Casos de Uso
Os casos de uso são identificados como:
● Essencial: É o caso de uso indispensável ao funcionamento do sistema.
Esse tipo de caso de uso deve ser implementado impreterivelmente, caso
contrário, o projeto perderá sua utilidade.
● Importante: Sem este caso de uso, o sistema ainda é capaz de ser utilizado.
Contudo, essa utilização se dá de forma não satisfatória para o cliente.
● Desejável: Esse tipo de caso de uso poderá ser implementado em versões
posteriores do sistema, visto que, mesmo sem sua implementação, o sistema
atende suas funcionalidades básicas.
1.5.3 Descrição dos atores
Os atores são aqueles que interagem de alguma forma com o sistema. Eles
são:
● Analista: Funcionários da empresa responsáveis pelas tarefas que envolvem
o pregão.
● Gerente: Funcionário que também pode atuar como Analista, porém com
outras atribuições como autorizar a participação de determinados itens no
leilão.
● Contador: Funcionário responsável pela parte financeira da empresa.
● Órgão público: Órgão do governo ofertante da licitação.

8
2. Requisitos Organizacionais
Os requisitos organizacionais devem satisfazer os objetivos da organização e
definir porque o sistema é necessário. Esses requisitos são:
● Diminuir a quantidade de tarefas manuais a serem executadas;
● Aumento de eficiência e por consequência abrangência maior de itens
arrematados por pregão.
3. Requisitos Funcionais
Nesta seção são definidas as funções que o sistema deve realizar. Os
requisitos são agrupados de acordo com seus atores, exceto o primeiro grupo que
são os requisitos de autenticação do sistema.
3.1 Requisitos Comuns aos Usuários
3.1.1 [RF01] Autenticar Usuário
Identificação: [RF01]
Casos de Usos
Relacionados:
[UC01]
Descrição: Valida os dados do usuário e permite que o usuário
tenha acesso ao sistema. Para isso, o usuário deve
informar o login e a senha. Esta é a única forma de
entrar no sistema.
Prioridade: Essencial
3.1.2 [RF02] Efetuar Logoff
Identificação: [RF02] Efetuar Logoff
Casos de Usos
Relacionados:
[UC09]
Descrição: Permite que o usuário saia do sistema.

9
3.2 Requisitos do Analista
3.2.1 [RF03] Cadastrar Itens para Análise do Gerente
Casos de Usos
Relacionados:
[UC02]
Descrição: O Analista abre o site do responsável pelo leilão e
escolhe quais itens deseja disputar. Gera uma lista
de itens em seguida cadastra no sistema. Em
seguida cadastra os itens no sistema.
3.2.2 [RF04] Cadastrar URL do pregão no sistema
Casos de Usos
Relacionados:
[UC04]
Descrição: Escolhido o leilão, cadastrar a URL do mesmo no
sistema.
3.2.3 [RF05] Cadastrar data e hora de início do pregão
Casos de Usos
Relacionados:
[UC04]
Descrição: Escolhido o leilão, cadastrar a data e hora do
mesmo no sistema.

10
3.2.4 [RF06] Realizar Proposta Inicial
Casos de Usos
Relacionados:
[UC04]
Descrição: Escolhido o leilão, realizar proposta no site do
órgão responsável pelo pregão.
3.2.5 [RF07] Analisar Valores
Casos de Usos
Relacionados:
[UC05]
Descrição: Decidir se fará uma nova proposta durante o
pregão.
3.2.6 [RF08] Disputar Item
Casos de Usos
Relacionados:
[UC05]
Descrição: Avaliar se existem itens a serem disputados. Em
caso que sim esperar o sinal do sistema quando
houver mudanças no status do pregão. Em caso de
não dar prosseguimento ao processo licitatório.
3.2.7 [RF09] Enviar Documentação online
Casos de Usos
Relacionados:
[UC06]
Descrição: Enviar para o órgão público responsável os
documentos requisitados durante a licitação via
online.

11
3.2.8 [RF10] Enviar Documentação pelos correios
Casos de Usos
Relacionados:
[UC06]
Descrição: Caso necessário enviar via correios os documentos
requisitados em um segundo momento.
Prioridade: Importante
3.3 Requisitos de Gerente
3.3.1 [RF11] Validar Itens Pendentes no Sistema
Casos de Usos
Relacionados:
[UC03]
Descrição: O gerente da empresa valida os produtos do
pregão eletrônico a serem arrematados e cadastra
no sistema.
3.4 Requisitos de Contador
3.4.1 [RF12] Gerar relatório contábil
Casos de Usos
Relacionados:
[UC10]
Descrição: Utilizar as informações do sistema para gerar
relatórios de contabilidade.

12
3.4.2 [RF13] Gerar relatório financeiro
Casos de Usos
Relacionados:
[UC10]
Descrição: Utilizar as informações do sistema para gerar
relatórios de finanças.
3.5 Requisitos do Órgão Público
3.5.1 [RF14] Fornecer Parecer
Casos de Usos
Relacionados:
[UC07]
Descrição: Enviar a lista de documentos necessários que
devem ser entregues via correios.
3.5.2 [RF15] Confirmar Recebimento
Casos de Usos
Relacionados:
[UC07]
Descrição: Enviar confirmação de recebimento de documentos
requisitados.

13
4. Requisitos Não Funcionais
4.1 Requisitos de Processo
4.1.1 [NFR01] Utilizar o framework Ruby on Rails
Identificação: [NRF01] Utilizar o Framework Ruby on Rails
Casos de Usos
Relacionados:
Todos
Descrição: Para o controle de cotação para lance de uma
licitação será feito um sistema utilizando o
framework Ruby on Rails.
4.1.2 [NFR02] Utilizar o banco de dados MySQL
Identificação: [NFR02] Utilizar o banco de dados MySQL
Casos de Usos
Relacionados:
Todos
Descrição: Para armazenamento das informações necessárias
será utilizado o banco de dados MySQL por sua
viabilidade financeira e boa integração com o
framework.
4.1.3 [NFR03] Utilizar o SCRUM como metodologia de desenvolvimento
Identificação: [NFR03] Utilizar o SCRUM como metodologia de
desenvolvimento
Casos de Usos
Relacionados:
Todos
Descrição: O SCRUM é uma metodologia de desenvolvimento
ágil que se adequa bem ao framework de
desenvolvimento e ao sistema proposto.

14
4.2 Requisitos de Produto
4.2.1 [NRF04] Disponibilidade
Identificação: [NRF04] Disponibilidade
Casos de Usos
Relacionados:
Todos
Descrição: Se o sistema ficar fora do ar o trabalho deve ser
feito manualmente. No entanto é desejável uma
disponibilidade maior entre 9h e 11h, por serem
horários de maior movimentação.
4.2.2 [NFR05] Interface Intuitiva
Identificação: [NFR05] Interface Intuitiva
Casos de Usos
Relacionados:
Todos
Descrição: Tanto funcionários com habilidades com
computador quanto funcionários com dificuldade,
usarão o sistema. Portanto a interface deve ser
clara e objetiva.
4.2.3 [NFR06] Tutoriais
Identificação: [NFR06] Tutoriais
Casos de Usos
Relacionados:
Todos
Descrição: Dado que os usuários são diversos, um tutorial de
como usar o sistema é necessário.

15
4.2.4 [NFR07] Integridade
Identificação: [NFR07] Integridade
Casos de Usos
Relacionados:
Todos
Descrição: Os dados deverão ser corretos tendo em vista a
entrada do usuário. De suma importância, pois
envolve impacto econômico na empresa.
4.2.5 [NFR08] Backup
Identificação: [NFR08] Backup
Casos de Usos
Relacionados:
Todos
Descrição: Deve haver algumas cópias dos dados em
servidores diferentes para evitar a perda de dados.
O backup deve ser feito duas vezes ao dia.
4.2.6 [NFR09] Tempo de Resposta
Identificação: [NFR09] Tempo de Resposta
Casos de Usos
Relacionados:
Todos
Descrição: O tempo de resposta não deve ultrapassar 15
segundos, pois é crítico para o momento de
encerramento aleatório.
4.2.7 [NFR10] Restrição de Acesso
Identificação: [NFR10] Restrição de Acesso
Casos de Usos
Relacionados:
Todos
Descrição: Cada tipo de usuário deve ter acesso apenas às
funções designadas para ele.

16
4.2.8 [NFR11] Mensagens de Erro
Identificação: [NFR11] Mensagens de Erro
Casos de Usos
Relacionados:
Todos
Descrição: O sistema deve apresentar mensagem de erro,
quando for o caso, de forma clara o objetiva.
4.2.9 [NFR12] Padronização
Identificação: [NFR12] Padronização
Casos de Usos
Relacionados:
Todos
Descrição: Todas as informações devem respeitar o padrão
especificado em lei
4.3 Requisitos Externos
4.3.1 [NFR13] Orçamento
Identificação: [NFR13] Orçamento
Casos de Usos
Relacionados:
Todos
Descrição: O custo do sistema não pode superar o estimado
em R$ 20.000,00

17
4.3.2 [NFR14] Tempo de Desenvolvimento
Identificação: [NFR14] Tempo de Desenvolvimento
Casos de Usos
Relacionados:
Todos
Descrição: O tempo de desenvolvimento não pode ultrapassar
3 meses e 10 dias, que é o valor acordado no
estudo de viabilidade somado com o tempo de
possíveis eventualidades.
4.3.3 [NFR15] Integração com Sistema Externo
Identificação: [NFR15] Integração com Sistema Externo
Casos de Usos
Relacionados:
Todos
Descrição: O sistema precisa ser integrado com o sistema
fornecido pelo governo federal brasileiro.
5. Descrição de Casos de Uso
Neste capítulo, os requisitos descritos anteriormente são modelados através
de diagramas de casos de uso, para isso, foi utilizada a ferramenta Astash. O
detalhamento dos casos de uso se encontra abaixo bem como o diagrama de casos
de uso.
5.1 [UC01] Autenticar Usuário
Identificação: [UC01]
Descrição: Validar os dados de usuário e senha para que o
funcionário tenha acesso ao sistema.
Atores: Gerente, analista, contador.
Pré-condições O ator deve possuir cadastro no sistema
Pós-condições O ator estará logado no sistema

18
Fluxo de Eventos 1. O ator deve entrar no website do sistema
2. O ator deve escrever o seu usuário e senha
nos devidos campos
3. O sistema realizará a validação dos dados
do usuário
4. O ator será direcionado para a pagina de
menu do sistema
Fluxo Secundário 1. O ator deve entrar no website do sistema
2. O ator deve escrever o seu usuário e senha
nos devidos campos
3. O sistema emitirá uma mensagem
informando que os dados não são de um
usuário válido e que o ator deve digitar
valores corretos de usuário e senha
5.2 [UC02] Cadastrar Itens para Análise do Gerente
Descrição: O ator deve escolher os itens do leilão para o qual
deseja realizar lances e cadastrar no sistema para
que sejam posteriormente autorizados pelo
Gerente.
Atores: Analista, Gerente
Pré-condições O Analista deve estar logado no sistema
Pós-condições O banco de dados do sistema irá armazenar os
itens para que posteriormente o Gerente autorize
os lances.
Fluxo de Eventos 1. O ator deve procurar no menu do sistema a
opção “Cadastrar Lances”
2. O ator deve digitar o número do leilão
referente
3. O ator deve digitar todos os números
referentes ao itens do leilão referenciado
4. O ator deve clicar em “Confirmar o registro”
e em seguida clicar em “Sim” para o pop-up
requisitando a confirmação da operação
5. O ator será direcionado para o menu do
sistema
6. Caso haja outros números de leilões para
serem cadastrados o ator deve reiniciar o
ciclo 1

19
5.3 [UC03] Validar Itens Pendentes no Sistema
Descrição: O Gerente deve validar os itens do leilão pendentes
no sistema que poderão ser dados lances e em
seguida uma mensagem será encaminhada para o
com a lista dos itens aprovados.
Atores: Gerente, Analista
Pré-condições O Gerente deve estar logado no sistema e haver
itens pendentes para aprovação
Pós-condições Os itens validados estarão aptos para serem
enviados. Caso não haja itens validados uma
mensagem será direcionado para o Analista.
Fluxo de Eventos 1. O Gerente deve procurar no menu do
sistema a opção “Validar Itens de Leilão”
2. O Gerente deve analisar e marcar uma das
opções ao lado dos itens: “Autorizar” ou
“Não Autorizar” para os itens ele deseja
permitir a emissão de lances..
3. O Gerente deve clicar em “Confirmar
autorização” e em seguida clicar em “Sim”
para a tela requisitando a confirmação da
operação.
4. O gerente será direcionado para o menu do
sistema e a lista de itens aprovados será
direcionada para o Analista.
Fluxo Secundário 1. O Gerente deve procurar no menu do
sistema a opção “Validar Itens de Leilão”
2. Caso o gerente marque a opção “Não
autorizar” para todos os itens pendentes. E
confirmar o processo.
3. O gerente será direcionado para o menu do
sistema e o analista receberá uma
mensagem do sistema avisando que todos
seus itens foram reprovados.
5.4 [UC06] Cadastrar Pregão
Descrição: O Analista deve cadastrar a URL do site e data de
início do pregão no sistema. Em seguida deve

20
realizar uma proposta inicial.
Atores: Analista
Pré-condições O ator deve estar logado no sistema e os itens
terem sidos autorizados pelo Gerente.
Pós-condições O ator estará apto para receber informações do
sistema sobre os leilões cadastrados em tempo
real.
Fluxo de Eventos 1. O ator deve dirigir-se a “Cadastrar Pregão”
no menu do sistema
2. Na tela haverá uma lista de leilões e seus
respectivos itens que foram validados e um
campo em branco aonde será digitado a
URL do leilão.
3. O ator deve digitar a URL do leilão referente.
4. Clicar no botão “Confirmar” e quando a tela
do pop-up aparecer clicar em “Sim”.
5.5 [UC07] Disputar Leilão
Descrição: O Analista deve aguardar o sistema sinalizando o
início do leilão e analisar ciclicamente mensagens
do sistema para decidir se irá realizar novos
propostas.
Atores: Analista
Pré-condições O leilão deve estar cadastrado no sistema e o
Analista de logado no sistema.
Pós-condições O leilão referente terá finalizado.
Fluxo de Eventos 1. O Analista aguarda o sinal de início de
Leilão.
2. Assim que iniciar o leilão o analista analisará
as propostas vigentes e irá decidir se irá
realizar uma nova proposta ou não.
3. O analista irá aguardar um novo sinal do
sistema. Em caso de um sinal de mudança
de propostas pelos concorrentes ir para
etapa 4 ou em caso de fim de leilão ir para

21
etapa 5.
4. O analista irá analisar se fará uma nova
proposta. Retornar para etapa 3.
5. Ao termino do leilão em caso de vitória
iniciar o processo de “Enviar Documentação”
e no caso de derrota iniciar o processo de
“Aguardar alerta do CHAT”.
5.6 [UC06] Enviar Documentação
Descrição: Consiste no envio dos documentos para o órgão
público responsável.
Atores: Analista
Pré-condições O leilão deve ter sido finalizado e pelo menos um
item arrematado.
Pós-condições Fim do pregão.
Fluxo de Eventos 1. O Analista deve enviar para o órgão público
os documentos requisitados durante o
processo de licitação via online.
2. O Analista deve aguardar a mensagem do
órgão público com a lista de itens de
documentos que devem ser entregues via
correios
3. O Analista deve enviar os documentos
requisitados por carta registada via correios.
Fluxo Secundário 1. O Analista deve enviar para o órgão público
os documentos requisitados durante o
processo de licitação via online.
2. O Analista deve aguardar a mensagem do
órgão público com a lista de itens de
documentos que devem ser entregues via
correios. Caso não seja necessário nenhum
envio. O processo se encerra.
5.7 [UC07] Enviar Parecer
Descrição: O órgão público deve enviar para o arrematador a
lista de documentos que serão necessários serem

22
enviados via correios.
Atores: Órgão Público
Pré-condições O ator deve receber via online os documentos
requisitos durante a licitação.
Pós-condições O ator está apto para o recebimento dos
documentos via correios.
Fluxo de Eventos 1. O órgão enviará uma lista de documentos
que devem ser entregues via correios.
5.8 [UC08] Confirmar Recebimento
Descrição: O órgão público deve enviar para o arrematador a
confirmação do recebimento dos documentos via
correios.
Atores: Órgão Público
Pré-condições O ator deve receber via correios os documentos
requisitos pelo órgão público.
Pós-condições O processo de licitação estará encerrado.
Fluxo de Eventos 1. O órgão deve confirmar via carta registrada
a entrega dos documentos requisitados.
5.9 [UC09] Efetuar Logoff
Descrição: O ator sairá do sistema.
Atores: Analista, Gerente, Contador
Pré-condições O ator deve estar logado no sistema
Pós-condições O ator não estará mais logado no sistema.
Fluxo de Eventos 1. A qualquer momento o ator pode clicar em “Sair”
e dessa forma ele não estará mais logado no

23
sistema.
5.10 [UC10] Gerar Relatórios
Descrição: Gerar relatórios tanto financeiros quanto de
contabilidade.
Atores: Contador
Pré-condições O ator deve estar logado no sistema
Pós-condições O sistema irá gerar relatórios em Excel.
Fluxo de Eventos 1. O ator deve clicar em “Gerar Relatório
Financeiro” ou “Gerar Relatório de Contabilidade”
em seguida o sistema irá pedir uma série de
parâmetros e gerar um relatório em Excel.
6. Modelagem de Comportamento do Sistema (Statechart)
A modelagem do comportamento do sistema foi realizada em Statechart para
descrever detalhadamente como o sistema deve operar quando realizada as
atividades presentes nos casos de uso, descritos anteriormente.
● Cadastrar Pregão
Figura 6.1 – Modelo statechart (cadastrar pregão)

24
Nesta atividade o analista é responsável por cadastrar um novo pregão no sistema,
dados os valores da URL e a data e hora em que o pregão foi realizado.
● Sistema e Monitoramento de Disputa
Figura 6.2 - Modelo statechart (Sistema e Monitoramento de disputa)
A modelagem deste comportamento indica que inicialmente um item começa
com o status de fechado. Então, independente da ação que modifica o item para o
fechado ou aberto, o item continua em monitoramento até que seja disparado algum
evento de mensagem específica. Caso a mensagem específica seja encerramento
dinâmico, o item é encerrado aleatoriamente e então volta para o status de
monitorando. Se a mensagem for de aviso de iminência, o item entra em estado de
iminência e então volta a ser monitorado novamente.
Enquanto o item não for encerrado, continua-se com o estado de
monitoramento do item. Se o item for encerrado, o fim do monitoramento automático
é atingido. Então, caso o item for arrematado, entramos no estado de enviar o alerta
ao analista da documentação.
Por fim, o estado de monitoramento do chat é atingido caso o item não seja
arrematado ou ao sinal de alerta enviado a partir do estado de alertar o analista.

25
7. Modelagem de Processo de Negócio (BPMN)
Foram modelados os processos englobados no contexto entre o sistema
LICITSYS, o site Pregão, o órgão Público e a empresa COELHO INFO que contem
Gerente, Analista e Contador. Utilizamos a ferramenta Bizagi [3], seguindo o tutorial
do BPMN [1].
Começamos pelo processo de autenticar o usuário no sistema (Figura 6.1). O
usuário deve fornecer a senha e o login no site para que o servidor possa então
realizar a validação dos dados. Caso os as credenciais existam no sistema, busca-
se no banco de dados o perfil do usuário na empresa, fornecendo acesso a Analista
ou Gerente de acordo com cada perfil.
Com o analista autenticado, ele poderá cadastrar itens para a análise do
gerente (Figura 6.2).
Figura 7.1 - Modelo BPMN (Autenticação de usuário)

26
Figura 7.2 - Modelo BPMN (Cadastrar item)
O gerente logo após se autenticar, deve receber uma lista de itens
cadastrados pelo analista. Daí, o gerente prossegue com a validação de itens
pendentes no sistema, confirmando em uma lista quais itens podem ser disputados.
Se os itens foram todos recusados, uma mensagem por e-mail é enviada ao
analista. Caso contrário, o gerente envia uma lista com os itens aprovados para o
analista, então logo após receber esta lista de itens um novo pregão é cadastrado
com os itens aprovados pelo gerente (Figura 6.3).
Figura 7.3 - Modelo BPMN (Lista de itens e cadastrar pregão)

27
O processo de cadastrar um pregão consiste em cadastrar a URL do pregão
no sistema, inserindo posteriormente a data e hora do início do pregão. Por fim,
realiza-se uma proposta inicial para o pregão (Figura 6.4).
Figura 7.4 - Modelo BPMN (Cadastrar Pregão)
Em seguida, começamos a fase de disputa de pregão (figura 6.5). Se algum
item foi arrematado, então o analista envia a documentação exigida para o site do
pregão eletrônico. Caso algum item não tenha sido arrematado, então o analista
aguarda o alerta do chat. Após o alerta do chat, se houver convocação do item, o
analista envia a lista de documentos exigidos. Se não, acaba-se o pregão sem
arremate.
Figura 7.5 - Modelo BPMN (Fluxo geral com disputa de pregão)

28
Do lado do sistema LICITSYS, ao cadastrar um pregão o processo de
monitoramento de disputa começa a ser iniciado em busca de saber quais itens
foram encerrados a fim de obter o arremate (figura 6.6)
Figura 7.6 - Modelo BPMN (Monitoramento de disputa)
No monitoramento de disputa, o sistema deve acessar a URL do pregão para
então monitorar o status do item. Enquanto o status estiver fechado ou aberto, o
sistema continua monitorando. Se o status do item for “Aviso de Iminência”, um item
é enviado para disputar o pregão em aviso de iminência, continuando o
monitoramento dos outros itens. Caso o status for encerramento aleatório, um item
em encerramento aleatório é enviado para a disputa do pregão. Se todos os itens
não foram encerrados, o sistema continua a fazer o monitoramento. Caso contrário,
o sistema passa para a fase de arremate do item. Nesta etapa um aviso é enviado
ao analista para que este providencie a documentação, caso algum item seja
arrematado.
Figura 7.7 - Modelo BPMN (Monitoramento de disputa)

29
Ao fim do processo, o sistema inicia o monitoramento em chat até que
encerre o pregão.
O monitoramento em chat inicia logo após a disputa de pregão, o sistema
acessa a URL do chat para então verificar a convocação do cliente para envio de
documentação online. Se o cliente foi convocado, então o sistema envia uma
mensagem de notificação. Caso contrário, continua a verificação. Após esse
processo de verificação online, inicia-se o processo de verificação física de forma
análoga.
Figura 7.8 - Modelo BPMN (Monitoramento de chat)
8. Modelagem de Requisitos Não Funcionais (NFR Framework)
Este capítulo contém os refinamentos dos requisitos não funcionais, descreve suas
interdependências e operacionalizações. Para construir esse diagrama foi utilizada a
ferramenta Microsoft Visio [2].

30
Figura 8.1. Modelagem de Requisitos Não Funcionais
9. Modelagem de Caso de Uso
O diagrama de casos de uso serve para dar uma visão externa do sistema
facilitando seu entendimento e neste documento foram agrupados em pacotes, de
forma que os diagramas representem as atividades do fluxo principal divididas em
“licitação” e “homologação”.

31
Figura 9.1 – Pacote dos casos de uso da disputa licitatória

32
Figura 9.1 – Pacote dos casos de uso da homologação
10. Modelagem Organizacional (i*)
A modelagem organizacional do sistema foi realizada em i* para descrever as
dependências dos atores do sistema e como este deve operar segundo os objetivos gerais
definidos nos casos de uso e na notação BPMN.
Para que o gerente realize obrigações financeiras e contábeis, ele precisa de
relatórios confiáveis por parte do contador. Para fornecer os relatórios o contador precisa
dos dados que o gerente pode disponibilizar.
O gerente precisa que o lucro seja maximizado, o que só poder ser realizado pelo
analista no momento de disputar o pregão.
Para que os itens sejam cadastrados e os alertas enviados, é preciso que o sistema
esteja disponível.
Para que o analista consiga disputar o pregão com confiança, é necessário que os
alertas emitidos sejam confiáveis.
Por fim, os documentos devem ser enviados pelo analista para o órgão publico, o
qual deve dar o parecer se esses documentos estão de acordo com o que foi exigido.

33
Figura 10.1 – Diagrama i*

34
11. Conclusão
O objetivo inicial deste documento foi entender o funcionamento e os
gargalos da empresa de comércio varejista com ênfase em pregões eletrônicos
COELHO INFO para que seja possível propor uma solução. Foram então mostrados
os requisitos funcionais e não funcionais que foi inferido a partir das interações com
o cliente.
Depois desta etapa, são mostrados vários diagramas que usam as notações
padrões que permitem uma melhor visualização dos requisitos do sistema, de forma
que haja um ganho no que concerne a uma análise clara e precisa do produto a ser
desenvolvido.
12. Relatório da Equipe
Nesta última seção, segue a porcentagem de esforço de cada membro da
equipe. As responsabilidades da construção deste estudo foram compartilhadas por
todos os membros do grupo, e houve cooperação na complementariedade e no
entendimento do problema bem como na construção da solução.
Nome Esforço Assinatura
Guilherme Paiva 25%
Fernando Maranhão 25%
Amintas Coelho 25%
Edson Barboza 25%
13. Apêndices
13.1. Entrevista Realizada para levantamento de requisitos não
funcionais
1 - Qual a tolerância (em segundos) que o nosso sistema pode ficar fora do ar
durante o dia?
- 7200 segundos no horário comercial. Fora do horário comercial ele não
precisa funcionar.
2 - Quantas vezes o sistema pode cair em um dia?
- Duas vezes ao dia.
3 - Qual o tempo máximo tolerável para o sistema voltar "ao ar"?
- 1 hora (3600 segundos).
4 - Qual o horário mais crítico? (ex.: de 8h as 18h)

35
- 9h às 11h.
5 - O nosso sistema precisa ter um tempo de resposta rápido? Se sim, qual o tempo
máximo que se esperaria para a tela carregar?
- 15 segundos, pois é crítico para o momento de encerramento aleatório.
6 - Os funcionários precisam de treinamento para usar o nosso software? Se sim, de
quanto tempo? Um tutorial básico servia?
- Devido à simplicidade do sistema, um tutorial é o suficiente.
7 - O software será web, app móvel ou desktop?
- Web.
8 - Como os usuários deste sistema se autenticam no nosso sistema?
- Usuário e senha.
9 - A empresa tem servidor próprio? Ou é preciso contratar um serviço de cloud
computing?
- Servidor próprio.
10 - Qual o custo máximo que a empresa pretende gastar para obter o software?
- R$ 350,00.
11 - O software será evoluído e terá atualizações?
- Se apresentar problemas precisará de atualizações com as devidas
correções.
12 - A empresa possui área de suporte de TI?
- Não possui.
13 - Existe alguma restrição quanto à linguagem de desenvolvimento ou framework?
- Não.
14 - O software precisa ser homologado por algum órgão regulador?
- Não.
15 - O software precisa ser seguro ou ter alguma proteção?
- Não, pois a segurança fica por conta do site onde a licitação ocorre. O
aplicativo só precisa monitorar o site, sem necessidade de segurança.
16 - O software precisa se comunicar (se integrar) com outros sistemas online?
- Sim, com o site onde a licitação ocorre.
17 - Existe alguma legislação que o software precisa obedecer, ou seja, precisa
estar em conformidade com algum aspecto legal?
- Não.
13.2. Glossário com termos utilizados no negócio
Licitação: A licitação é o meio administrativo pelo qual o poder público adquire os
bens, obras e serviços indispensáveis ao cumprimento de suas obrigações.
Pregão eletrônico: é uma modalidade licitatória utilizada pelo governo brasileiro para
contratar bens e serviços, independentemente do valor estimado.
Fase de homologação: é a fase na qual o órgão público avalia a documentação
enviada pelo fornecedor para saber se está de acordo com o que foi exigido.
Arrematar: No contexto da licitação significa ser o vencedor imediato do item. Ainda
será necessário passar pela fase de homologação.

36
Disputar pregão: Ato de acessar o pregão eletrônico e enviar lances para
determinados itens no intuito de ser o arrematante
13.3. Documento de proposta da Coelho Info que utilizamos para
compreender melhor o processo
COELHO INFO
PROPOSTA 153278 12011.doc
13.4. Contrato social da Coelho Info, necessário para
conheceremos os dados da empresa
COELHO INFO
CONTRATO E IE.pdf

Sistema de Leilão Eletrônico

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Sistema de Leilão Eletrônico

Semelhante a Sistema de Leilão Eletrônico (20)

Sistema de Leilão Eletrônico