Especificação de Requisitos e Validação de Sistemas

Transcrição

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 1

2 Sumário 1.1 Motivação Sobre a Organização O Problema Identificado Convenções para Identificação dos requisitos Convenções para Identificação dos casos de uso Estrutura dos Casos de Uso Prioridades dos Casos de Uso Descrição dos atores Requisitos Organizacionais Requisitos Funcionais Requisitos Comuns aos Usuários [RF01] Autenticar Usuário [RF02] Efetuar Logoff Requisitos do Analista [RF03] Cadastrar Itens para Análise do Gerente [RF04] Cadastrar URL do pregão no sistema [RF05] Cadastrar data e hora de início do pregão [RF06] Realizar Proposta Inicial [RF07] Analisar Valores [RF08] Disputar Item [RF09] Enviar Documentação online [RF10] Enviar Documentação pelos correios Requisitos de Gerente [RF11] Validar Itens Pendentes no Sistema Requisitos de Contador [RF12] Gerar relatório contábil [RF13] Gerar relatório financeiro Requisitos do Órgão Público [RF14] Fornecer Parecer [RF15] Confirmar Recebimento Requisitos Não Funcionais Requisitos de Processo [NFR01] Utilizar o framework Ruby on Rails [NFR02] Utilizar o banco de dados MySQL [NFR03] Utilizar o SCRUM como metodologia de desenvolvimento

3 4.2 Requisitos de Produto [NRF04] Disponibilidade [NFR05] Interface Intuitiva [NFR06] Tutoriais [NFR07] Integridade [NFR08] Backup [NFR09] Tempo de Resposta [NFR10] Restrição de Acesso [NFR11] Mensagens de Erro [NFR12] Padronização Requisitos Externos [NFR13] Orçamento [NFR14] Tempo de Desenvolvimento [NFR15] Integração com Sistema Externo Descrição de Casos de Uso [UC01] Autenticar Usuário [UC02] Cadastrar Itens para Análise do Gerente [UC03] Validar Itens Pendentes no Sistema [UC06] Cadastrar Pregão [UC07] Disputar Leilão [UC06] Enviar Documentação [UC07] Enviar Parecer [UC08] Confirmar Recebimento [UC09] Efetuar Logoff [UC10] Gerar Relatórios Modelagem de Comportamento do Sistema (Statechart) Modelagem de Processo de Negócio (BPMN) Modelagem de Requisitos Não Funcionais (NFR Framework) Modelagem de Caso de Uso Modelagem Organizacional (i*) Conclusão Relatório da Equipe Apêndices Entrevista Realizada para levantamento de requisitos não funcionais Glossário com termos utilizados no negócio

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

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: ) 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 5

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. 6

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 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 Prioridades dos Casos de Uso Os casos de uso são identificados como: : 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 Descrição dos atores são: Os atores são aqueles que interagem de alguma forma com o sistema. Eles 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. 7

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 [RF01] Autenticar Usuário [RF01] [UC01] 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 [RF02] Efetuar Logoff [RF02] Efetuar Logoff [UC09] Permite que o usuário saia do sistema. 8

9 3.2 Requisitos do Analista [RF03] Cadastrar Itens para Análise do Gerente [RF03] [UC02] 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 [RF04] Cadastrar URL do pregão no sistema [RF04] [UC04] Escolhido o leilão, cadastrar a URL do mesmo no sistema [RF05] Cadastrar data e hora de início do pregão [RF05] [UC04] Escolhido o leilão, cadastrar a data e hora do mesmo no sistema. 9

10 3.2.4 [RF06] Realizar Proposta Inicial [RF06] [UC04] Escolhido o leilão, realizar proposta no site do órgão responsável pelo pregão [RF07] Analisar Valores [RF06] [UC05] Decidir se fará uma nova proposta durante o pregão [RF08] Disputar Item [RF08] [UC05] 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 [RF09] Enviar Documentação online [RF09] [UC06] Enviar para o órgão público responsável os documentos requisitados durante a licitação via online. 10

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

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

13 4. Requisitos Não Funcionais 4.1 Requisitos de Processo [NFR01] Utilizar o framework Ruby on Rails [NRF01] Utilizar o Framework Ruby on Rails Todos Para o controle de cotação para lance de uma licitação será feito um sistema utilizando o framework Ruby on Rails [NFR02] Utilizar o banco de dados MySQL [NFR02] Utilizar o banco de dados MySQL Todos 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 [NFR03] Utilizar o SCRUM como metodologia de desenvolvimento [NFR03] Utilizar o SCRUM como metodologia de desenvolvimento Todos O SCRUM é uma metodologia de desenvolvimento ágil que se adequa bem ao framework de desenvolvimento e ao sistema proposto. 13

14 4.2 Requisitos de Produto [NRF04] Disponibilidade [NRF04] Disponibilidade Todos 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. Importante [NFR05] Interface Intuitiva [NFR05] Interface Intuitiva Todos Tanto funcionários com habilidades com computador quanto funcionários com dificuldade, usarão o sistema. Portanto a interface deve ser clara e objetiva [NFR06] Tutoriais [NFR06] Tutoriais Todos Dado que os usuários são diversos, um tutorial de como usar o sistema é necessário. 14

15 4.2.4 [NFR07] Integridade [NFR07] Integridade Todos 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 [NFR08] Backup [NFR08] Backup Todos 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 [NFR09] Tempo de Resposta [NFR09] Tempo de Resposta Todos O tempo de resposta não deve ultrapassar 15 segundos, pois é crítico para o momento de encerramento aleatório [NFR10] Restrição de Acesso [NFR10] Restrição de Acesso Todos Cada tipo de usuário deve ter acesso apenas às funções designadas para ele. 15

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

17 4.3.2 [NFR14] Tempo de Desenvolvimento [NFR14] Tempo de Desenvolvimento Todos 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 [NFR15] Integração com Sistema Externo [NFR15] Integração com Sistema Externo Todos 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 [UC01] Atores: Pré-condições Pós-condições Validar os dados de usuário e senha para que o funcionário tenha acesso ao sistema. Gerente, analista, contador. O ator deve possuir cadastro no sistema O ator estará logado no sistema 17

18 Fluxo de Eventos 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 realizará a validação dos dados do usuário 4. O ator será direcionado para a pagina de menu do sistema 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 [UC02] Atores: Pré-condições Pós-condições Fluxo de Eventos 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. Analista, Gerente O Analista deve estar logado no sistema O banco de dados do sistema irá armazenar os itens para que posteriormente o Gerente autorize os lances. 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 18

19 5.3 [UC03] Validar Itens Pendentes no Sistema [UC03] Atores: Pré-condições Pós-condições Fluxo de Eventos Fluxo Secundário 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. Gerente, Analista O Gerente deve estar logado no sistema e haver itens pendentes para aprovação Os itens validados estarão aptos para serem enviados. Caso não haja itens validados uma mensagem será direcionado para o Analista. 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. 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 [UC04] O Analista deve cadastrar a URL do site e data de início do pregão no sistema. Em seguida deve 19

20 realizar uma proposta inicial. Atores: Pré-condições Pós-condições Fluxo de Eventos Analista Importante O ator deve estar logado no sistema e os itens terem sidos autorizados pelo Gerente. O ator estará apto para receber informações do sistema sobre os leilões cadastrados em tempo real. 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 Atores: Pré-condições Pós-condições Fluxo de Eventos [UC05] 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. Analista O leilão deve estar cadastrado no sistema e o Analista de logado no sistema. O leilão referente terá finalizado. 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 20

21 etapa O analista irá analisar se fará uma nova proposta. Retornar para etapa 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 Atores: Pré-condições Pós-condições Fluxo de Eventos Fluxo Secundário [UC06] Consiste no envio dos documentos para o órgão público responsável. Analista O leilão deve ter sido finalizado e pelo menos um item arrematado. Fim do pregão. 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. 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 [UC07] O órgão público deve enviar para o arrematador a lista de documentos que serão necessários serem 21

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

23 sistema [UC10] Gerar Relatórios Atores: Pré-condições Pós-condições Fluxo de Eventos [UC10] Gerar relatórios tanto financeiros quanto de contabilidade. Contador Importante O ator deve estar logado no sistema O sistema irá gerar relatórios em Excel. 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) 23

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 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. 24

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, buscase 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 Modelo BPMN (Autenticação de usuário) 25

26 Figura 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 é 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 Modelo BPMN (Lista de itens e cadastrar pregão) 26

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 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 Modelo BPMN (Fluxo geral com disputa de pregão) 27

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 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 Modelo BPMN (Monitoramento de disputa) 28

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 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]. 29

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. 30

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

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. 32

33 Figura 10.1 Diagrama i* 33

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 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? 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) 34

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 Qual o custo máximo que a empresa pretende gastar para obter o software? - R$ 350, O software será evoluído e terá atualizações? - Se apresentar problemas precisará de atualizações com as devidas correções A empresa possui área de suporte de TI? - Não possui Existe alguma restrição quanto à linguagem de desenvolvimento ou framework? - Não O software precisa ser homologado por algum órgão regulador? - Não 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 O software precisa se comunicar (se integrar) com outros sistemas online? - Sim, com o site onde a licitação ocorre Existe alguma legislação que o software precisa obedecer, ou seja, precisa estar em conformidade com algum aspecto legal? - Não 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. 35

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