15
UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA ESPECIFICAÇÃO DE REQUISITOS E VALIDAÇÃO DE SISTEMAS Especificação de Requisitos Coteaqui RECIFE 29 de Abril de 2016

UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

  • Upload
    others

  • View
    0

  • Download
    0

Embed Size (px)

Citation preview

Page 1: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMÁTICA ESPECIFICAÇÃO DE REQUISITOS E VALIDAÇÃO DE SISTEMAS

Especificação de Requisitos Coteaqui

RECIFE

29 de Abril de 2016

Page 2: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMÁTICA ESPECIFICAÇÃO DE REQUISITOS E VALIDAÇÃO DE SISTEMAS

Coteaqui

Equipe: Brunno Rafael Barros de Castro (brbc) José Luciano Mendonça Melo(jlmm) Justan Luiz Vasconcelos Barbosa(jlvb) Pedro Henrique Dias da Silva (phds)

Professor: Jaelson Castro

Graduação em Ciência da Computação e em Engenharia da Computação

Page 3: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

Sumário 1. Introdução ................................................................................................... 4 1.1. Descrição da empresa ................................................................................. 4 1.2. Descrição do problema ............................................................................... 4 2. Requisitos do sistema .................................................................................... 6 2.1 Requisitos Organizacionais ......................................................................... 6 2.2 Requisitos Funcionais .................................................................................. 6 2.3. Requisitos Não Funcionais…………………………………………………….. 10 3. Modelagem de Processos de Negócios (BPMN) …………………………….. 12 4. Modelagem I star (i*) ………………………………………………………………. 13 5. Conclusão …………………………………………………………………………... 15

Page 4: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

1. Introdução

Este documento consiste no relatório de execução do projeto da disciplina de Especificação de Requisitos e Validação de Sistemas (IF716), em que se especifica um sistema para a empresa Coteaqui, com o objetivo de auxiliar na interação entre fornecedoras de materiais de construção e construtoras de modo a diminuir custos e trabalho manual. O sistema proposto pretende automatizar atividades críticas que compõem os processos atuais, como gerenciamento de solicitações de cotação de material de construção, relacionamentos entre fornecedores e construtoras, relatórios internos, entre outros. Para especificação do sistema supracitado, foram utilizadas diversas técnicas de modelagem aprendidas na disciplina, como modelagem social com a abordagem i* e modelagem de processos de negócio com BPMN. 1.1 Descrição da empresa

A Coteaqui é uma empresa que visa auxiliar empresas de construção para que as mesmas consigam economizar em materiais de construção e, desta maneira, também auxilia também fornecedores que estejam cadastrados em seu sistema com a oportunidade de vender mais material para mais construtoras. 1.2 Descrição do problema

Diversos problemas podem ser encontrados na interação entre construtoras e fornecedores. O diretor, que na maioria dos casos é também o dono da empresa, aloca um comprador para uma determinada compra de material de construção. A partir desta alocação, a responsabilidade pela transação é do comprador e quase todo o processo se torna manual. Entre os problemas encontrados podemos citar:

O principal problema encontrado que consiste na dificuldade de construtoras

decidirem qual fornecedor oferece um determinado material de construção que seja o mais barato dentre os existentes no mercado de forma fácil e prática, uma vez que muitas construtoras se mantém com os mesmos fornecedores pelo conhecimento da qualidade de seu produto mas podendo estar pagando mais caro que o valor mais baixo encontrado no mercado.

Há a necessidade de se enviar muitos emails para várias empresas fornecedoras

para que estas possam responder com suas respectivas propostas, podendo então gerar um grande fluxo de emails na caixa de email do comprador de origens

Page 5: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

distintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado.

Também existe o problema de tempo de espera de resposta de cada empresa, que pode vir a fornecer o material de construção necessário para o comprador. Como o comprador não tem uma maneira de saber quanto tempo deve esperar antes de decidir qual fornecedor possui o produto mais barato e que seja confiável, ele acaba decidindo pelo produto que conhece melhor, isto é, de uma fornecedora de quem ele já tenha comprado outras vezes.

Por fim, também pode ser citada a falta de padrão nos envios de propostas de valor

de materiais de construção provenientes das fornecedoras para as construtoras. Como cada fornecedor envia seu próprio email, muitas vezes alguma informação fica faltando, aumentando o tempo necessário para que o comprador retorne um email pedindo a informação para então o fornecedor enviar um email com a informação necessária.

Page 6: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

2. Requisitos do Sistema

Os requisitos do sistema identificam o que é solicitado ao sistema fazer e com quais limitações o sistema operar. Os requisitos podem ser divididos em requisitos organizacionais, funcionais e não funcionais, e são detalhados abaixo. 2.1 Requisitos Organizacionais

Os requisitos organizacionais buscam definir as metas da organização, especificando o que deve ser atingido com o desenvolvimento e implantação do sistema. Para o Coteaqui, o sistema em questão busca:

Automatizar algumas tarefas que são realizadas manualmente pelos compradores da construtora e vendedores do fornecedor, evitando gasto de tempo por parte das mesmas;

Diminuir risco de falhas humanas, evitando repetição de tarefas, gasto de tempo dos funcionários e economia de recursos da empresa;

Disponibilizar acesso aos dados da empresa de forma remota, facilitando o gerenciamento por parte da gerente de compras.

2.2 Requisitos Funcionais

Requisitos funcionais descrevem as funcionalidades que o sistema deve ter. Nesse relatório, descrevemos os requisitos funcionais identificados até o momento. Cada um deles é identificado por código, nome, descrição e prioridade.

[RF01] Efetuar login

Descrição

Para garantir que apenas funcionários autorizados irão possuir acesso ao sistema, é necessário que exista uma autenticação antes de acessar outras funcionalidades.

Prioridade Desejável

Page 7: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

[RF02] Efetuar logout

Descrição Para garantir que indivíduos não autorizados não acessem as informações de usuários que já fizeram login.

Prioridade Desejável

[RF03] Cadastrar lista de materiais

Descrição

As construtoras precisam ter acesso a colocar sua lista de necessidades no sistema, para que os fornecedores tenham acesso posteriormente.

Prioridade Essencial

[RF04] Enviar lista de materiais aos fornecedores

Descrição

Para que os fornecedores possam ter acesso a lista de materiais, o sistema deverá enviar as listas entradas pelas construtoras.

Prioridade Essencial

Page 8: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

[RF05] Analisar propostas de fornecedores

Descrição

O sistema deverá poder analisar se as propostas dos fornecedores estão no formato correto e se não existem elementos faltando nas propostas tais como valor excessivamente alto ou peso do material não informado.

Prioridade Essencial

[RF06] Enviar propostas em horários pré­determinados

Descrição

O sistema deve ser capaz de enviar propostas revisadas todos os dias para que o comprador seja atualizado sobre possíveis novos fornecedores.

Prioridade Desejável

[RF07] Compilar propostas

Descrição

O sistema deve conseguir compilar todas as propostas que forem enviadas e que estejam no formato padrão, sem nenhuma informação faltando.

Prioridade Desejável

[RF08] Enviar problemas encontrados em propostas

Page 9: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

Descrição

O sistema deve possuir a capacidade de enviar os erros encontrados nas propostas que não estiverem no padrão para os fornecedores, permitindo a estes corrigirem e reenviarem uma proposta corrigida.

Prioridade Importante

[RF09] Enviar notificação de escolha para os fornecedores

Descrição

O sistema deve ser capaz de enviar notificações para os fornecedores que forem escolhidos pelo comprador que representa a construtora.

Prioridade Desejável

Page 10: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

2.3 Requisitos Não funcionais

Requisitos nãofuncionais dizem respeito às restrições relativas ao desenvolvimento do sistema e aspectos de qualidade, como segurança, manutenibilidade, usabilidade, etc. Os requisitos não funcionais estão descritos abaixo.

[RNF01] Disponibilidade

Descrição O sistema precisa ter um alto nível de disponibilidade, para garantir o acesso dos clientes a qualquer momento.

Prioridade Essencial

[RNF02] Confidencialidade

Descrição Por tratar de dados confidenciais da empresa, é essencial que o

sistema garanta a segurança dos dados, isto é, só serão

acessados por funcionários com permissão.

Prioridade Essencial

[RNF03] Mantenabilidade

Descrição

O sistema deve ser capaz de lidar facilmente com possíveis atualizações de manutenção. Para isso, a modularização deve ser garantida, além da utilização de padrões de projeto.

Page 11: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

Prioridade Essencial

[RNF04] Eficiência

Descrição O sistema deve funcionar de forma rápida, para que a utilização não seja afetada por problemas técnicos.

Prioridade Essencial

Page 12: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

3. Modelagem de Processos de Negócios (BPMN)

São mostrados abaixo os diagramas BPMN dos processos de negócio do sistema relativos a preenchimento da lista de materiais, recebimento dos orçamentos, entre outras atividades realizadas pelos atores.

Figura 3.1: Esquema BPMN

Figura 3.2: Subprocesso “Cadastrar a lista de materiais”

Page 13: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

4. Modelagem I star (i*)

São mostrados abaixo os diagramas em dependência estratégica (SD), que descreve as dependências entre os atores, e os diagramas de Raciocínio estratégico, que explica como os atores alcançam suas metas.

Figura 4.1: Esquema SD

Page 14: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

Figura 4.1: Esquema SR

Page 15: UNIVERSIDADE FEDERAL DE PERNAMBUCOif716/projetos/2016-1/Grupo1.pdfdistintas, e assim, o email de alguma fornecedora pode acabar sendo perdido ou passar como spam e não ser visualizado

5. Conclusão

Ao fim do projeto pudemos oferecer ao Coteaqui um sistema que, baseado nos requisitos levantados durante a fase de pesquisa, contribuem para o melhor funcionamento da empresa. O esquema aqui exposto, utilizando diferentes modelos visa abordar os problemas identificados em duas frentes diferentes, permitindo assim a equipe realizar a implementação tendo a maior quantidade de recursos possíveis para garantir a qualidade do projeto.