Levantamento de Requisitos

Atlas Schindler

Projeto:

Versão 1.0
Informações
 Projeto: Base_ SAO_ Supply Approval System (SAF),
PO: Lilia Ramos Carneiro Versão do documento: 1.0
Líder Técnica: Data da versão do documento: 04/03/2024
Desenvolvedores: Data de preparação: 1.0
Resp. Área Negócio: Marcos Vinicius Victor Versão Modelo Documento: 1.0

Lista de Distribuição
De Data
Stefanini - Squad 04/03/2024

Para Ação* Até

Atlas Schindler Validação do 15/03/2024
Levantamento de
Requisitos

Histórico
Ver. No. Data ver. Descrição
1.0 04/03/2024 Versão inicial

Sumário
1. Visão Geral do Projeto................................................................................................................................. 4

2. Objetivos do Projeto.................................................................................................................................... 4

3. Contexto do Projeto..................................................................................................................................... 4

4. Stakeholders................................................................................................................................................ 4

5. Escopo do Sistema....................................................................................................................................... 5

6. Requisitos Funcionais................................................................................................................................... 6

7. Requisitos Não Funcionais.......................................................................................................................... 13

8. Cronograma do Projeto.............................................................................................................................. 14

9. Procedimentos de Implantação.................................................................................................................. 14

10. Lista de Verificação Pré-Implantação...................................................................................................... 14

Levantamento de Requisitos -

1. Visão Geral do Projeto

O projeto tem como objetivo desativar o Lotus Notes e transferir a base, propondo a utilização
do SharePoint Power Platform, incluindo PowerApps e PowerAutomate. O documento /Projeto
mencionado, chamado SAO_ Supply Approval System (SAF), visa fornecer uma visão abrangente
dos requisitos para o desenvolvimento do projeto. Este levantamento é crucial para
compreender as necessidades e expectativas dos stakeholders, estabelecendo assim a base
necessária para o desenvolvimento bem-sucedido do sistema.

2. Objetivos do Projeto
O projeto tem como objetivo refazer a aplicação do Lotus Notes em SharePoint Online com uso
de PowerPlatform, transferindo os dados já existentes na atual base, visando a substituição da
ferramenta mencionada.

A seguir, apresentam-se de forma resumida os requisitos Funcionais e não Funcionais e o

propósito do projeto, enfatizando os principais objetivos e as metas a serem alcançadas.

3. Contexto do Projeto

O aplicativo consiste em uma integração técnica entre os departamentos de Qualidade,

Engenharia e Compras. Permite a criação de solicitações de itens com cenários especificados e
propostos. Todas as informações relevantes, como anexos, fotos, quantidade de entrega, prazo de
entrega, material alvo e plantas, são coletadas de maneira abrangente.
Após a criação da solicitação, é iniciado um fluxo de aprovação, e um registro detalhado (log) é
gerado e mantido ao longo de todo o processo.
Essa abordagem visa facilitar a comunicação e a colaboração eficiente entre os diferentes
departamentos, garantindo um rastreamento completo e transparente das atividades relacionadas
à solicitação de itens.

4. Stakeholders
É importante identificar claramente os stakeholders envolvidos no projeto. Neste caso, os
principais stakeholders são:

Página 4
https://stefanini.com/
Levantamento de Requisitos -

Usuário Interno: Representando aqueles que utilizarão diretamente o sistema ou as

ferramentas propostas, eles desempenham um papel crucial na definição dos requisitos
funcionais e na validação do sistema.

Administrador: Este stakeholder provavelmente será responsável pela configuração,

manutenção e gerenciamento geral do ambiente, garantindo que tudo funcione de maneira
eficiente.

Aprovadores: Estes podem ser indivíduos ou grupos que têm autoridade para aprovar o
projeto, suas fases e resultados. Eles desempenham um papel fundamental na validação e na
tomada de decisões estratégicas.

5. Escopo do Sistema
O Escopo do projeto consiste nos seguinte itens abaixo:

1. Gestão de Dados Mestre de Fornecedores:

 Criação, edição e exclusão de registros mestres de fornecedores.
2. Responsáveis por Área:
 Adição, edição e exclusão de responsáveis por área: Qualidade, Engenharia, Compras
e Gestão, responsáveis pela aprovação.
3. Definição de Prazo:
 Estabelecimento de prazos em dias para a aprovação do documento, ajustados de
acordo com as áreas designadas.
4. Notificações por Email:
 Envio automatizado de e-mails utilizando templates específicos de acordo com o
fluxo de trabalho.
5. Formulário de Solicitação:
 Criação de formulário de solicitação com campos de dados e suporte para anexos e
fotos.
6. Regras de Negócio Dinâmicas:
 Configuração de campos dinâmicos, que aparecem ou não com base em regras de
negócio específicas.
7. Gestão de Rejeição:
 Notificação ao criador do documento em caso de rejeição em qualquer etapa,
encerrando o fluxo correspondente.
8. Registro Detalhado:
 Manutenção de um registro completo para cada etapa do fluxo de trabalho,
incluindo data, hora e identificação do responsável pela ação.

Página 5
https://stefanini.com/
Levantamento de Requisitos -

Essas funcionalidades do atual sistema foram concebidas para oferecer uma gestão eficiente e
transparente do processo, incentivando a colaboração entre as diferentes áreas envolvidas. O
objetivo é facilitar a comunicação, otimizar a aprovação de documentos e manter um registro
detalhado de todas as etapas do fluxo de trabalho. Isso contribui para uma operação mais
tranquila, promovendo uma integração mais eficaz entre os setores.

6. Requisitos Funcionais
Esta seção deve detalhar as funcionalidades específicas que o sistema deve fornecer. Use casos
de uso, diagramas de sequência, e descrições narrativas para esclarecer as operações esperadas do
sistema.

RF001: Definir perfil de usuário:

Descrição:
Como administrador, deve-se realizar o cadastro de usuários e suas respectivas funções, a fim de
disponibilizar as atividades de maneira adequada para os usuários."

Pré-condições: A utilização da base requer que o usuário possua conhecimento das regras de
negócio associadas.

Fluxo Principal:

1. Os requisitos de registro do usuário devem conter os seguintes campos:

 Nome: Nome completo do solicitante.

 Departamento: Preenchimento com o nome do departamento solicitante.
 Planta: Opção para selecionar entre KG ou KW, representando o tipo de unidade.
 Telefone: Número de telefone do usuário.
 E-mail: Endereço de e-mail do usuário.
 Papel: Função do usuário, permitindo que cada usuário tenha no mínimo três funções,
incluindo:
 Administrador.
 Solicitante.
 Aprovador de Compras.
 Aprovador de Engenharia.
 Aprovador da Qualidade.

2. Permissões no aplicativo SAF para a função de Administrador:

Página 6
https://stefanini.com/
Levantamento de Requisitos -

 Criar: Sim
 Visualizar: Sim, todos os SAFS criados.
 Editar: Todos os SAFS, com exceção dos SAFSs fechados (aprovados e
reprovados), além de texto aprovado e decisões tomadas.

3. Permissões na aplicação SAF para a função de Solicitante:

 Criar: Sim
 Visualizar: Sim, todos os RIAIs criados.
 Editar: Restrito ao que estiver em nome e função do próprio solicitante.
4. Permissões na aplicação SAF para as funções de Aprovadores (Engenharia,
Qualidade, Armazém, Emissão de Fatura):
 Criar: Não
 Visualizar: Sim, todos os SAFS criados.
 Editar: Restrito ao que estiver em nome e função do próprio aprovador

RF002: Cadastrar dados Mestre do Fornecedor

Descrição: No caso de Solicitante, à necessidade de estabelecer um registro contendo os dados

cadastrais do fornecedor, com o intuito de possibilitar a criação de SAF (Solicitação de
Aquisição de Materiais) em colaboração com o referido fornecedor.

Pré-condições: A utilização da base requer que o usuário possua conhecimento das regras de
negócio associadas.

Fluxo Principal:

1. Campos essenciais para os dados cadastrais do fornecedor:

 Fornecedor: Nome ou identificação do fornecedor.

 Contato: Pessoa responsável pelo fornecedor.

 Número de Telefone: Contato telefônico principal.

 Celular: Número de celular para contato.

 E-mail: Endereço de e-mail do fornecedor.

2. Deve possuir botões de comando para realizar as seguintes ações:

 Incluir: Adicionar um novo registro.

 Modificar: Editar as informações de um registro existente.
 Salvar: Confirmar e salvar as alterações feitas.
 Fechar Base: Encerrar o sistema ou a visualização atual.

Página 7
https://stefanini.com/
Levantamento de Requisitos -

3. Deve oferecer a opção de pesquisa para os seguintes campos:

 Fornecedor: Permite buscar fornecedores específicos.
 Contato: Facilita a busca com base nas pessoas de contato.
 E-mail: Possibilita localizar registros por meio do endereço de e-mail
associado.

4. Deve incluir a opção de exportar dados, possibilitando a criação de um arquivo

Excel para importação.

RF003:Tela Cadastrar SAF

Descrição: Objetivo de desenvolver uma interface de criação de SAF, permitindo o cadastro

eficiente de novos SAFS.

Pré-condições: A utilização da base requer que o usuário possua conhecimento das regras de
negócio associadas.

Fluxo Principal:

1. Campos obrigatórios para dados cadastrais do fornecedor:

 Fornecedor: "Fornecedor"
 Contato: "Contato"
 Número de telefone: "Telefone"
 Celular: "Celular"
 E-mail: "E-mail"

2. O sistema deve incluir os seguintes botões de comando:

 Incluir: Para adicionar novos registros.

 Modificar: Para editar informações de registros existentes.
 Salvar: Para salvar as alterações feitas nos registros.
 Fechar Base: Para encerrar o acesso à base de dados.

3. O sistema deve incluir opções de pesquisa para os seguintes campos:

 Fornecedor: "Fornecedor"
 Entre em contato com: "Contato"
 E-mail: "E-mail"

4. Campos obrigatórios para identificação do produto:

 "Produto" - nome do produto (texto grande ex: Braket assy - left Transon...).

Página 8
https://stefanini.com/
Levantamento de Requisitos -

 “Código” – Id do material (ex: 51956538).

 “Versão” – versão em desenho (ex: 02).

 "Aplicação" - Aplicação do produto (ex: Front Wall Var 15).

 "Ordem de compra"- Número do pedido de compra, podendo haver mais de um

pedido (ex: 4502610414-1/ 4502520020-2).

 “Planta” - deve ser preenchido automaticamente, a partir dos dados do solicitante

5. O formulário terá um campo "Observações" com capacidade de texto ilimitado para

inserção de informações detalhadas conforme necessário.

6. Devera existir um botão de pesquisa para exibir a lista de opções disponíveis ao aprovar
desvios.

7. Devera existir um campo para anexar documentos, denominado "Anexos", com um botão
para procurar arquivos a serem exibidos no aplicativo, geralmente nos formatos PDF, JPG
ou ZIP.

8. O campo "Especificado" será um campo de texto que permite a inclusão de requisitos de

especificação do produto, possibilitando a inserção de texto, figuras coladas e tabelas com
edições, cores e configurações de texto.

9. O campo "Proposto" será um campo de texto destinado a apresentar o desvio das

características do produto do fornecedor para aprovação, permitindo a inclusão de texto,
figuras coladas e tabelas com edições, cores e configurações de texto.

10. Os campos de nomes de aprovadores devem incluir uma opção de consulta para cada um
deles, mostrando a seleção com base nos dados dos usuários, considerando "função=tipo
de aprovador" e "Planta=site solicitante". As categorias de aprovadores e suas respectivas
funções incluem:

 Compras - "Aprovação de Compras".

 Engenharia - "Aprovadores de Engenharia".
 Qualidade - "Aprovadores de Qualidade

Página 9
https://stefanini.com/
Levantamento de Requisitos -

RF004: Aprovador de Compras

Descrição:
Como aprovador de compras, é necessário dispor de opções de aprovação para realizar o
processo de aprovação de acordo com as exigências específicas.

Pré-condições: A utilização da base requer que o usuário possua conhecimento das regras de
negócio associadas.

Fluxo Principal:

1. Primeiro: "Compras" – Aprovador de Compras.

 Deve ser fornecido um campo de texto com tamanho ilimitado.

2. Ao concluir a ação selecionando "Enviar", o status deverá ser automaticamente alterado

para "Em análise pela Engenharia".

RF005: Efetuar Aprovação de Engenharia

Descrição: Como aprovador de Engenharia, é necessário ter opções de aprovação para efetuar a
aprovação técnica.

Pré-condições: A utilização da base requer que o usuário possua conhecimento das regras de
negócio associadas.

Fluxo Principal:

1. Como Aprovador de Engenharia, e necessário um espaço de aprovação para confirmar a

devolução de material. Este espaço deve incluir um campo de texto de tamanho ilimitado
e oferecer opções de escolha exclusiva entre os status: 'Aprovado', 'Aprovado com
Restrição' e 'Reprovado' por meio de botões."

2. "Após a conclusão da ação de seleção 'Enviar', o status deve ser automaticamente

atualizado para 'Em análise pela Qualidade'. Além disso, o fluxo de trabalho de aprovação
deve enviar um e-mail para o próximo aprovador, contendo um link direto para a RIAI
em questão."

Página 10
https://stefanini.com/
Levantamento de Requisitos -

RF006: Detalhar aprovação de qualidade

Descrição: Na condição de Aprovador de Qualidade, e necessário uma área dedicada à

aprovação de qualidade, a fim de incorporar análises específicas relacionadas à qualidade.

Pré-condições: A utilização da base requer que o usuário possua conhecimento das regras de
negócio associadas.

Fluxo Principal:

1. "Qualidade" - Função de Qualidade

Esta função deve incluir um campo de texto com tamanho ilimitado.
Deve conter dois botões, com a seleção de apenas um deverá ser permitido (não é
possível escolher ambos): "Aprovado" e "Reprovado".
Com base na análise técnica, o aprovador da qualidade deve escolher entre aprovar ou
reprovar a solicitação.

2. Se a opção "Aprovar" for selecionada, o status será alterado para "Aprovado" assim que a
ação for concluída ao selecionar "Enviar". Após essa alteração, um e-mail automático
contendo o SAF aprovado em anexo será enviado ao fornecedor e ao solicitante. Com
isso, o fluxo de trabalho de aprovação do SAF será concluído.

3. Se a opção "Rejeitar" for selecionada, o status será automaticamente alterado para

"Reprovado". Após essa alteração, um e-mail automático contendo o SAF rejeitado em
anexo será enviado ao fornecedor e ao solicitante. Com isso, o fluxo de trabalho de
aprovação do SAF será concluído.

RF007: Verificar SAF Criado

Descrição:
Como solicitante, é importante poder ver o SAF que foi criado. Ter a facilidade de visualizar
todos os SAFs que já existem e encontrar um específico quando necessário,

Pré-condições: A utilização da base requer que o usuário possua conhecimento das regras de
negócio associadas.

Fluxo Principal:

1. Deve haver opções para exibir todos os SAFs criados, classificados por diferentes status.
O sistema apresentará colunas com campos detalhados de acordo com o status

Página 11
https://stefanini.com/
Levantamento de Requisitos -

selecionado. Abaixo estão os campos específicos para cada status, conforme as telas
impressas anexas:

 Status: "Em criação”:

o Campos: "Código", "Dados", "Emitente", "Departamento".

 Status: "Em aprovação de Compras"

o Campos: "Aprovador", "Dados", "Nº SAF", "Código", "Emitente",

"Departamento", "Fornecedor".
 Status: "Em análise pela Engenharia"

o Campos: "Aprovador", "Dados", "Nº SAF", "Código", "Emitente",

"Departamento", "Fornecedor".
 Status: "Em análise pela Qualidade"

o Campos: "Aprovador", "Dados", "Nº SAF", "Código", "Emitente",

"Departamento", "Fornecedor".
 Status: "Aprovado"

o Campos: "Emitente", "Dados", "Nº SAF", "Código", "Aprovador",

"Departamento", "Fornecedor".
 Status: "Reprovado"

o Campos: “Dados”, “Nº SAF”, “Código”, “Emitente”, “Departamento”,

“Fornecedor”.

7. Requisitos Não Funcionais

 Responsabilidade e Limitação

Este aplicativo foi concebido com o propósito de facilitar a tomada de decisões pelos usuários e
responsáveis, especificamente em relação ao material em consideração. Qualquer outra
informação de suporte necessária será obtida manualmente a partir do sistema SAP.

Descrição: O sistema deve responder a todas as solicitações do usuário em menos de 1 segundo.

 Requisitos de Dados:

Página 12
https://stefanini.com/
Levantamento de Requisitos -

Para documentos finalizados, os dados serão retidos e permanecerão disponíveis pelo período de
até 5 anos.

 Requisitos de disponibilidade:

O sistema estará disponível sete dias por semana, durante o período das 07:00h às 19:00h, no
fuso horário de São Paulo.
Para documentos finalizados, os dados serão retidos e permanecerão disponíveis pelo período de
até 5 anos.

 Requisitos de Desempenho:

O tempo médio para realizar operações de edição, criação, exclusão e atualização não excederá 8
segundos.

A princípio, foram definidos diferentes níveis de serviço para requisitos comuns de desempenho,
interfaces e disponibilidade. Isso possibilita a escolha e, possivelmente, envolve a inclusão de um
campo para especificar variações correspondentes (verificando a identificação desse campo
específico). Qual seria este campo?

 Requisição de Segurança:

Implementar a mesma configuração de segurança utilizada em outras aplicações internas,

conforme recomendado pela área de segurança, considerada suficiente para o contexto.

 Requisitos de Dispositivos:

A aplicação deve ser acessível para utilização em dispositivos móveis e navegadores Windows.

8. Cronograma do Projeto

Página 13
https://stefanini.com/
Levantamento de Requisitos -

9. Procedimentos de Implantação

10. Lista de Verificação Pré-Implantação

Página 14
https://stefanini.com/