flowchart LR
    A[Solicitante] --> B[Gestor]
    B --> C[Financeiro]
    C --> D[ERP]
    C --> E[Banco]
    D --> F[Contabilidade]
    C --> G[Auditoria]
```---
## 24.4 Como escrever uma declaração de problema

Uma boa declaração de problema deve conter contexto, dor, impacto e necessidade.

**Modelo:**

> Atualmente, [área/usuário] realiza [processo] por meio de [forma atual]. Isso causa [dor/risco/ineficiência], impactando [indicador/resultado]. É necessário [mudança desejada] para [benefício esperado].

**Exemplo:**

> Atualmente, a área financeira recebe solicitações de pagamento por e-mail, WhatsApp e planilhas. Isso causa perda de histórico, dificuldade de priorização e risco de pagamento duplicado, impactando o tempo de aprovação e a rastreabilidade. É necessário centralizar o fluxo em um sistema com regras de alçada, anexos, aprovação e auditoria para reduzir retrabalho e aumentar controle.

---

## 24.5 Perguntas estratégicas antes da solução

### Sobre negócio

- Qual objetivo da empresa?
- Qual indicador deve melhorar?
- Qual risco precisa ser reduzido?
- Qual custo operacional existe hoje?
- O problema é recorrente ou pontual?

### Sobre usuários

- Quem executa?
- Quem aprova?
- Quem consulta?
- Quem audita?
- Quem é impactado indiretamente?

### Sobre processo

- Qual é o fluxo atual?
- Quais exceções ocorrem?
- Quais etapas são manuais?
- Quais decisões dependem de regra?
- Onde há retrabalho?

### Sobre dados

- Quais dados entram?
- Quais dados são obrigatórios?
- Quais dados são sensíveis?
- Qual é a origem confiável?
- Quem pode alterar?

### Sobre tecnologia

- Quais sistemas participam?
- Existe API?
- Existe banco compartilhado?
- Existe planilha crítica?
- Existe sistema legado?
- A solução precisa escalar?

---

## 24.6 Estudo de caso: automação de atendimento com IA e GLPI

**Situação inicial:** a empresa recebe muitas mensagens repetidas no WhatsApp: dúvidas de horário, status de chamados, solicitações de acesso, problemas de sistema e pedidos de suporte.

**Sintoma:** equipe de suporte sobrecarregada.

**Problema:** ausência de triagem automatizada, base de conhecimento integrada e abertura padronizada de chamados.

**Causas possíveis:**

- usuários não sabem onde procurar informação;
- não há classificação automática;
- solicitações chegam fora do GLPI;
- não existe integração entre WhatsApp, base de conhecimento e service desk;
- falta SLA por categoria.

**Solução estruturada:**

- chatbot para triagem inicial;
- integração com base de conhecimento;
- abertura automática de chamados no GLPI;
- classificação por intenção;
- encaminhamento humano para casos críticos;
- logs e métricas de atendimento;
- regras de horário e escalonamento.

O ganho não está apenas no chatbot. Está na **reorganização do processo de atendimento**.

---

## Nota Zettelkasten

**ZK-024 — Problema de Negócio**

Um problema de negócio é uma necessidade, dor, risco ou oportunidade que exige mudança em processo, sistema, dados, tecnologia ou comportamento organizacional.

**Conexões:**

- ZK-001 — Sistema
- ZK-002 — Pensamento Sistêmico
- ZK-016 — Arquitetura de Software
- ZK-025 — Engenharia de Requisitos
- ZK-030 — BPMN
- ZK-031 — Arquitetura Corporativa

---

## Active Recall — Capítulo 24

1. Qual é a diferença entre sintoma e problema?
2. Por que iniciar pela tecnologia pode gerar desperdício?
3. Como uma declaração de problema deve ser estruturada?
4. O que significa analisar impactos sistêmicos?
5. Quais perguntas você faria antes de criar uma automação?

---

## Referências recomendadas do capítulo

- WEINBERG, Gerald M. *Are Your Lights On? How to Figure Out What the Problem Really Is*. Dorset House.
- CHECKLAND, Peter. *Systems Thinking, Systems Practice*. Wiley.
- SENGE, Peter M. *The Fifth Discipline*. Currency.
- BABOK Guide — *A Guide to the Business Analysis Body of Knowledge*. IIBA.
- ROSS, Jeanne W.; WEILL, Peter; ROBERTSON, David C. *Enterprise Architecture as Strategy*. Harvard Business Review Press.

---

# Capítulo 25 — Engenharia de Requisitos

## Objetivos de aprendizagem

Ao final deste capítulo, você será capaz de:

- definir requisitos funcionais, não funcionais, de negócio, de usuário e de sistema;
- reconhecer requisitos ambíguos e melhorá-los;
- aplicar critérios de qualidade a requisitos;
- compreender rastreabilidade, priorização e mudança;
- preparar especificações para desenvolvimento e testes.

---

## 25.1 O que são requisitos?

Requisitos são descrições estruturadas de necessidades, restrições, comportamentos e qualidades esperadas de um sistema.

Eles respondem a perguntas como:

- o que o sistema deve fazer?
- quem pode fazer?
- em quais condições?
- quais dados são necessários?
- quais regras se aplicam?
- qual desempenho é esperado?
- como o sistema deve se comportar em erro?
- quais integrações são obrigatórias?
- quais critérios indicam que a entrega está correta?

Um requisito é uma ponte entre negócio, tecnologia, teste, implantação e operação.

---

## 25.2 Tipos de requisitos

### Requisitos de negócio

Expressam objetivos organizacionais.

**Exemplo:**

> Reduzir em 40% o tempo médio de aprovação de compras em até seis meses.

### Requisitos de usuário

Descrevem necessidades de grupos de usuários.

**Exemplo:**

> Como gestor, quero aprovar solicitações pelo celular para evitar atrasos quando estiver fora da empresa.

### Requisitos funcionais

Descrevem funcionalidades ou comportamentos.

**Exemplo:**

> O sistema deve permitir abertura de chamado com título, descrição, categoria, prioridade e anexos.

### Requisitos não funcionais

Descrevem qualidades, restrições ou atributos de qualidade.

**Exemplo:**

> O sistema deve registrar 99,5% de disponibilidade mensal para usuários internos.

### Requisitos de domínio

Vêm de regras específicas do setor, área ou legislação.

**Exemplo:**

> Solicitações jurídicas devem manter documentos anexos com controle de acesso restrito.

### Requisitos de interface e integração

Descrevem comunicação com outros sistemas.

**Exemplo:**

> O sistema deve enviar chamados aprovados para o GLPI por API REST utilizando autenticação por token.

---

## 25.3 Requisito bom x requisito ruim

| Requisito ruim | Problema | Requisito melhor |
|---|---|---|
| O sistema deve ser rápido. | Ambíguo. | A tela inicial deve carregar em até 3 segundos para 95% das requisições em rede corporativa. |
| O sistema deve ser seguro. | Genérico. | Administradores devem autenticar com MFA e todas as alterações de permissão devem ser auditadas. |
| O relatório deve ser completo. | Não define campos. | O relatório deve conter ID, título, categoria, solicitante, técnico, status, data de abertura, data de solução e SLA. |
| O usuário poderá anexar arquivos. | Falta tipo/tamanho. | O sistema deve aceitar PDF, PNG e JPG de até 10 MB por arquivo. |
| Deve integrar com ERP. | Falta fluxo. | Após aprovação financeira, o sistema deve enviar número da solicitação, centro de custo, valor e fornecedor ao ERP. |

---

## 25.4 Características de bons requisitos

Um bom requisito tende a ser:

- **necessário:** ligado a um objetivo real;
- **claro:** sem ambiguidade;
- **completo:** contém condições, dados e exceções;
- **verificável:** pode ser testado;
- **rastreável:** conectado a origem, regra ou objetivo;
- **priorizado:** importância definida;
- **viável:** tecnicamente e economicamente possível;
- **consistente:** não contradiz outros requisitos.

---

## 25.5 Rastreabilidade de requisitos

Rastreabilidade é a capacidade de acompanhar um requisito desde sua origem até sua entrega.
```mermaid
flowchart LR
    A[Objetivo de Negócio] --> B[Requisito]
    B --> C[História de Usuário]
    C --> D[Critério de Aceite]
    D --> E[Caso de Teste]
    E --> F[Entrega Validada]
```Exemplo:
| Origem | Requisito | Critério | Teste |
|---|---|---|---|
| Auditoria interna | Registrar alterações de aprovação | Toda aprovação deve gerar log | Verificar log após aprovar solicitação |
| Financeiro | Evitar pagamento duplicado | Bloquear duplicidade por fornecedor, valor e vencimento | Tentar cadastrar pagamento duplicado |
| Diretoria | Reduzir tempo de aprovação | Notificar gestor pendente | Medir SLA antes/depois |

---

## 25.6 Priorização

Nem todo requisito tem o mesmo valor. Uma técnica simples é **MoSCoW**:

| Categoria | Significado |
|---|---|
| Must have | Obrigatório para a entrega fazer sentido |
| Should have | Importante, mas pode esperar |
| Could have | Desejável, se houver tempo |
| Won't have now | Fora desta entrega |

Exemplo para sistema de solicitações:

- Must: abrir solicitação, aprovar, registrar histórico, controlar permissão.
- Should: anexos, notificações por e-mail, relatórios.
- Could: dashboard avançado, chatbot.
- Won't now: aplicativo mobile nativo.

---

## 25.7 Requisitos não funcionais e atributos de qualidade

Requisitos não funcionais costumam definir a qualidade da solução. Eles devem ser mensuráveis.

| Atributo | Pergunta | Exemplo |
|---|---|---|
| Desempenho | Quão rápido? | 95% das consultas em até 2 segundos. |
| Disponibilidade | Quanto tempo online? | 99,5% ao mês. |
| Segurança | Como proteger? | MFA para administradores e logs de ações críticas. |
| Usabilidade | É fácil usar? | Usuário deve abrir solicitação em até 3 minutos sem treinamento formal. |
| Manutenibilidade | É fácil evoluir? | Regras de alçada devem ser configuráveis sem alteração de código. |
| Escalabilidade | Cresce com demanda? | Suportar 5.000 usuários ativos sem redesign. |
| Observabilidade | É monitorável? | Registrar métricas, logs e rastreamento de requisições. |

---

## 25.8 Antipadrões de requisitos

Evite:

- requisito que descreve solução antes de problema;
- requisito que mistura várias funcionalidades;
- requisito sem dono;
- requisito sem critério de aceite;
- requisito que não pode ser testado;
- requisito que contradiz regra existente;
- requisito informal preso em conversa ou e-mail;
- requisito “óbvio” que ninguém documentou.

---

## Nota Zettelkasten

**ZK-025 — Engenharia de Requisitos**

Disciplina responsável por elicitar, analisar, especificar, validar e gerenciar requisitos ao longo do ciclo de vida de uma solução.

**Conexões:**

- ZK-024 — Problema de Negócio
- ZK-026 — Elicitação
- ZK-027 — História de Usuário
- ZK-028 — Critério de Aceite
- ZK-035 — Testes
- ZK-040 — Backlog

---

## Active Recall — Capítulo 25

1. Qual é a diferença entre requisito funcional e não funcional?
2. Por que “o sistema deve ser rápido” é um requisito fraco?
3. O que é rastreabilidade?
4. Por que requisitos devem ser verificáveis?
5. Como a técnica MoSCoW ajuda um projeto?

---

## Referências recomendadas do capítulo

- WIEGERS, Karl; BEATTY, Joy. *Software Requirements*. Microsoft Press.
- ROBERTSON, Suzanne; ROBERTSON, James. *Mastering the Requirements Process*. Addison-Wesley.
- SOMMERVILLE, Ian. *Software Engineering*. Pearson.
- PRESSMAN, Roger S.; MAXIM, Bruce R. *Software Engineering: A Practitioner's Approach*. McGraw-Hill.
- POHL, Klaus. *Requirements Engineering: Fundamentals, Principles, and Techniques*. Springer.
- IEEE/ISO/IEC. *29148 — Systems and Software Engineering — Life Cycle Processes — Requirements Engineering*.
- BABOK Guide — *A Guide to the Business Analysis Body of Knowledge*. IIBA.

---

# Capítulo 26 — Elicitação de Requisitos

## Objetivos de aprendizagem

Ao final deste capítulo, você será capaz de:

- conduzir entrevistas de descoberta;
- aplicar observação direta, workshops, análise documental e prototipação;
- identificar requisitos explícitos, implícitos e ocultos;
- reconhecer stakeholders;
- estruturar perguntas por objetivo, processo, dados, regras, integração e segurança.

---

## 26.1 O que é elicitação?

Elicitação é o processo de descobrir, revelar e compreender necessidades. O usuário muitas vezes conhece a dor, mas não sabe expressar o requisito de forma técnica.

Exemplo:

> “Quero um botão para exportar.”

Possíveis significados ocultos:

- precisa enviar relatório para diretoria;
- precisa trabalhar offline;
- precisa cruzar dados em Excel;
- o sistema atual não tem filtros adequados;
- a auditoria exige evidência;
- o usuário não confia no dashboard.

O analista precisa entender o motivo antes de especificar a solução.

---

## 26.2 Stakeholders

Stakeholder é qualquer pessoa, área ou sistema afetado pela solução.

| Tipo | Exemplo | Interesse |
|---|---|---|
| Usuário final | colaborador | facilidade de uso |
| Gestor | gerente de área | controle e indicadores |
| Operação | suporte/TI | estabilidade e manutenção |
| Segurança | equipe de segurança | acesso, logs, riscos |
| Jurídico | jurídico interno | conformidade |
| Diretoria | liderança | resultado de negócio |
| Sistema externo | ERP/GLPI/CRM | integração confiável |

---

## 26.3 Técnicas de elicitação

### Entrevistas

Conversas individuais ou em pequenos grupos. Podem ser abertas, semiestruturadas ou estruturadas.

**Boas práticas:**

- preparar roteiro;
- perguntar sobre processo real, não apenas ideal;
- pedir exemplos concretos;
- explorar exceções;
- confirmar entendimento ao final;
- registrar decisões e pendências.

**Roteiro inicial:**

1. Qual problema você enfrenta?
2. Como o processo funciona hoje?
3. Quais sistemas participa?
4. Quais etapas geram retrabalho?
5. Quais erros acontecem com frequência?
6. Quem aprova?
7. Quais dados são obrigatórios?
8. Quais exceções existem?
9. Que relatórios são necessários?
10. Como saberemos que a solução funcionou?

---

### Observação direta

O analista observa o usuário executando o trabalho.

Exemplo: ao observar a abertura de uma solicitação de compras, você descobre que o usuário:

- consulta saldo em planilha;
- procura fornecedor em e-mail;
- confere contrato em pasta de rede;
- pede autorização via WhatsApp;
- anexa comprovante manualmente;
- cadastra dados repetidos no ERP.

A observação revela o que a entrevista não captura.

---

### Workshop

Reunião colaborativa com várias áreas. Útil quando o processo cruza departamentos.

**Cuidados:**

- definir objetivo;
- limitar escopo;
- usar quadro visual;
- separar problema de solução;
- registrar conflitos;
- validar decisões;
- definir próximos passos.

---

### Análise documental

Estuda materiais existentes:

- políticas internas;
- formulários;
- planilhas;
- manuais;
- relatórios;
- e-mails;
- normas;
- contratos;
- fluxos antigos;
- chamados registrados.

Essa técnica ajuda a descobrir regras esquecidas.

---

### Prototipação

Prototipar é transformar entendimento em algo visual.

Pode ser:

- wireframe no papel;
- tela simples em HTML;
- protótipo no Figma;
- fluxo navegável;
- mockup de relatório.

O protótipo não substitui requisitos, mas ajuda a validar entendimento.

---

## 26.4 Técnicas complementares

### Brainstorming

Útil para levantar ideias rapidamente, sem julgamento inicial.

### Questionários

Úteis quando há muitos usuários e é necessário coletar padrões.

### Shadowing

O analista acompanha o usuário durante parte da rotina de trabalho.

### Análise de logs e dados

Permite descobrir volume, frequência, gargalos e comportamento real.

Exemplo: analisar chamados do GLPI para identificar categorias mais recorrentes.

### Benchmarking

Comparar o processo com soluções ou práticas de mercado.

---

## 26.5 Perguntas poderosas por dimensão

### Objetivo

- O que precisa melhorar?
- Qual indicador será afetado?
- Qual é o custo de não resolver?

### Processo

- Onde começa?
- Onde termina?
- Quais etapas existem?
- O que acontece se algo der errado?
- Existe prazo?

### Regras

- Quem pode aprovar?
- Existe limite por valor?
- Existe exceção?
- A regra muda por área, cargo ou categoria?

### Dados

- Quais campos são obrigatórios?
- Qual é a fonte oficial?
- Quem pode alterar?
- Existe dado sensível?

### Integrações

- O processo depende de ERP, CRM, GLPI, AD, e-mail ou planilha?
- Existe API?
- A integração precisa ser síncrona ou assíncrona?
- O que acontece se o sistema externo estiver fora?

### Segurança

- Quem acessa?
- Quem altera?
- Quem exclui?
- O que deve ser auditado?
- Há requisitos de LGPD?

---

## 26.6 Resultado esperado da elicitação

A elicitação deve produzir:

- lista de stakeholders;
- mapa do processo atual;
- dores e oportunidades;
- requisitos preliminares;
- regras de negócio;
- restrições;
- integrações;
- riscos;
- dúvidas abertas;
- próximos passos.

---

## Nota Zettelkasten

**ZK-026 — Elicitação de Requisitos**

Processo de descobrir necessidades reais por meio de entrevistas, observação, workshops, análise documental, prototipação e análise de dados.

**Conexões:**

- ZK-024 — Problema de Negócio
- ZK-025 — Engenharia de Requisitos
- ZK-030 — Documentação Funcional
- ZK-032 — Stakeholder
- ZK-033 — Regra de Negócio

---

## Active Recall — Capítulo 26

1. Por que o usuário nem sempre sabe expressar requisitos?
2. Qual a diferença entre entrevista e observação direta?
3. Quando usar workshop?
4. Que tipos de documentos devem ser analisados?
5. Como logs podem ajudar na elicitação?

---

## Referências recomendadas do capítulo

- ROBERTSON, Suzanne; ROBERTSON, James. *Mastering the Requirements Process*. Addison-Wesley.
- WIEGERS, Karl; BEATTY, Joy. *Software Requirements*. Microsoft Press.
- COHN, Mike. *Agile Estimating and Planning*. Prentice Hall.
- BABOK Guide — *A Guide to the Business Analysis Body of Knowledge*. IIBA.
- GOODWIN, Kim. *Designing for the Digital Age*. Wiley.
- GOTHELF, Jeff; SEIDEN, Josh. *Lean UX*. O’Reilly.

---

# Capítulo 27 — Histórias de Usuário e Critérios de Aceite

## Objetivos de aprendizagem

Ao final deste capítulo, você será capaz de:

- escrever histórias de usuário orientadas a valor;
- evitar histórias vagas ou técnicas demais;
- criar critérios de aceite em formato claro;
- aplicar INVEST;
- relacionar histórias, requisitos e testes.

---

## 27.1 O que é uma história de usuário?

História de usuário é uma forma curta de expressar uma necessidade a partir da perspectiva de quem recebe valor.

Formato clássico:

> Como **[tipo de usuário]**, quero **[ação ou capacidade]**, para **[benefício]**.

Exemplo:

> Como colaborador, quero abrir um chamado com anexos, para enviar evidências do problema ao suporte.

A história não é a documentação completa. Ela é um item de conversa e planejamento.

---

## 27.2 O que torna uma história boa?

A técnica **INVEST** ajuda:

| Letra | Significado | Pergunta |
|---|---|---|
| I | Independent | Pode ser entregue com pouca dependência? |
| N | Negotiable | Permite conversa, não é contrato rígido? |
| V | Valuable | Entrega valor claro? |
| E | Estimable | Dá para estimar? |
| S | Small | É pequena o bastante? |
| T | Testable | Dá para testar? |

---

## 27.3 Exemplos melhores

### Ruim

> Como usuário, quero uma tela de chamados.

Problema: foca em tela, não em valor.

### Melhor

> Como colaborador, quero acompanhar meus chamados por status, para saber quais solicitações estão pendentes, em atendimento ou concluídas.

### Ruim

> Como gestor, quero relatório completo.

Problema: não define conteúdo.

### Melhor

> Como gestor de TI, quero visualizar os 10 tipos de chamados mais recorrentes no mês, para priorizar ações de melhoria.

---

## 27.4 Critérios de aceite

Critérios de aceite definem as condições para considerar a história concluída.

Podem ser escritos em lista:

1. O usuário deve informar título e descrição.
2. O sistema deve impedir criação sem título.
3. O sistema deve aceitar anexos PDF, PNG e JPG de até 10 MB.
4. Após criar o chamado, deve exibir número de protocolo.
5. O chamado deve aparecer em “Meus chamados”.

Ou no formato **Given / When / Then**:
```gherkin
Cenário: Criar chamado com dados válidos
Dado que o colaborador está autenticado
E preencheu título e descrição
Quando clicar em "Enviar"
Então o sistema deve criar o chamado
E exibir o número de protocolo
E listar o chamado em "Meus chamados"
```---
## 27.5 Relação com testes

Critérios de aceite orientam casos de teste.
```mermaid
flowchart LR
    A[História de Usuário] --> B[Critérios de Aceite]
    B --> C[Cenários de Teste]
    C --> D[Validação pelo Usuário]

flowchart LR
    Colaborador((Colaborador)) --> UC1[Abrir chamado]
    Colaborador --> UC2[Acompanhar chamado]
    Tecnico((Técnico)) --> UC3[Atender chamado]
    Gestor((Gestor)) --> UC4[Aprovar solicitação]
    Gestor --> UC5[Gerar relatório]
    Admin((Administrador)) --> UC6[Gerenciar usuários]

Classe: Chamado
- id: inteiro
- titulo: texto
- descricao: texto
- status: StatusChamado
- prioridade: Prioridade
- dataAbertura: data/hora
- dataSolucao: data/hora

Relacionamentos:
- Chamado pertence a Usuário
- Chamado possui Categoria
- Chamado pode possuir muitos Anexos
- Chamado possui Histórico

classDiagram
    class Usuario {
        +int id
        +string nome
        +string email
        +string perfil
    }

    class Chamado {
        +int id
        +string titulo
        +string descricao
        +string status
        +datetime dataAbertura
    }

    class Categoria {
        +int id
        +string nome
    }

    class Anexo {
        +int id
        +string nomeArquivo
        +string caminho
    }

    Usuario "1" --> "0..*" Chamado
    Categoria "1" --> "0..*" Chamado
    Chamado "1" --> "0..*" Anexo
```---
## 28.5 Diagrama de Sequência

Mostra a ordem das mensagens entre atores e componentes.

Exemplo: abertura de chamado.
```mermaid
sequenceDiagram
    actor Usuario
    participant Frontend
    participant API
    participant Banco
    participant Notificacao

    Usuario->>Frontend: Preenche formulário
    Frontend->>API: POST /chamados
    API->>API: Valida campos e permissões
    API->>Banco: Salva chamado
    Banco-->>API: Retorna ID
    API->>Notificacao: Envia e-mail/alerta
    API-->>Frontend: Confirma protocolo
    Frontend-->>Usuario: Exibe sucesso
```---
## 28.6 Diagrama de Atividades

Mostra fluxo de atividades e decisões.
```mermaid
flowchart TD
    A[Início] --> B[Usuário preenche solicitação]
    B --> C{Dados obrigatórios preenchidos?}
    C -- Não --> D[Exibir mensagem de erro]
    D --> B
    C -- Sim --> E[Registrar solicitação]
    E --> F{Valor acima da alçada?}
    F -- Sim --> G[Enviar para diretoria]
    F -- Não --> H[Enviar para gestor]
    G --> I[Fim]
    H --> I
```---
## 28.7 Boas práticas com UML

- Modele para comunicar, não para decorar.
- Use o nível de detalhe adequado ao público.
- Evite diagramas enormes.
- Combine texto e diagrama.
- Atualize diagramas importantes.
- Não use UML para substituir conversa com usuário.
- Priorize diagramas que reduzem ambiguidade.

---

## Nota Zettelkasten

**ZK-028 — UML**

Linguagem visual de modelagem usada para representar estrutura e comportamento de sistemas, facilitando comunicação entre negócio, análise, desenvolvimento e testes.

**Conexões:**

- ZK-017 — Arquitetura em Camadas
- ZK-025 — Engenharia de Requisitos
- ZK-030 — Documentação Funcional
- ZK-042 — Casos de Uso
- ZK-043 — Diagrama de Sequência

---

## Active Recall — Capítulo 28

1. O que é UML?
2. Qual a diferença entre diagrama estrutural e comportamental?
3. Para que serve um diagrama de casos de uso?
4. Quando usar um diagrama de sequência?
5. Por que diagramas devem ser mantidos simples?

---

## Referências recomendadas do capítulo

- FOWLER, Martin. *UML Distilled*. Addison-Wesley.
- BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. *The Unified Modeling Language User Guide*. Addison-Wesley.
- COCKBURN, Alistair. *Writing Effective Use Cases*. Addison-Wesley.
- LARMAN, Craig. *Applying UML and Patterns*. Prentice Hall.
- AMBLER, Scott W. *The Elements of UML 2.0 Style*. Cambridge University Press.

---

# Capítulo 29 — BPMN: Modelagem de Processos de Negócio

## Objetivos de aprendizagem

Ao final deste capítulo, você será capaz de:

- diferenciar BPMN de UML;
- identificar eventos, atividades, gateways, piscinas e raias;
- representar processos atuais e futuros;
- mapear exceções, aprovações, prazos e responsabilidades;
- usar BPMN como ferramenta de análise e automação.

---

## 29.1 O que é BPMN?

BPMN significa **Business Process Model and Notation**. É uma notação para representar processos de negócio.

Enquanto UML costuma modelar sistemas, BPMN modela o **trabalho organizacional**.

Exemplo: processo de compras.

1. Solicitante abre requisição.
2. Gestor aprova.
3. Compras cota fornecedores.
4. Financeiro valida orçamento.
5. Jurídico analisa contrato.
6. Pedido é emitido.
7. Produto é recebido.
8. Nota fiscal é lançada.

---

## 29.2 Elementos básicos

| Elemento | Função | Exemplo |
|---|---|---|
| Evento | Inicia, altera ou termina processo | Solicitação recebida |
| Atividade | Tarefa executada | Analisar contrato |
| Gateway | Decisão ou divisão de fluxo | Valor acima de R$ 10.000? |
| Piscina | Participante maior | Empresa, fornecedor |
| Raia | Área ou papel | Financeiro, Jurídico |
| Fluxo de sequência | Ordem das atividades | Tarefa A → Tarefa B |
| Fluxo de mensagem | Comunicação entre participantes | Empresa → Fornecedor |

---

## 29.3 BPMN textual: processo de compras
```text
Evento inicial: Necessidade de compra identificada

Raia Solicitante:
1. Preencher requisição
2. Anexar justificativa

Raia Gestor:
3. Avaliar necessidade
4. Gateway: aprovado?
   - Não: informar rejeição e encerrar
   - Sim: enviar para Compras

Raia Compras:
5. Cotar fornecedores
6. Selecionar melhor proposta

Raia Financeiro:
7. Validar orçamento
8. Gateway: orçamento disponível?
   - Não: retornar ao solicitante
   - Sim: seguir

Raia Jurídico:
9. Analisar contrato quando aplicável

Raia Compras:
10. Emitir pedido

Evento final: Pedido aprovado e registrado
```---
## 29.4 Processo AS-IS e TO-BE

| Tipo | Significado |
|---|---|
| AS-IS | Processo atual, como acontece hoje |
| TO-BE | Processo futuro, como deve funcionar após melhoria |

O erro comum é desenhar apenas o TO-BE sem entender o AS-IS. Isso cria soluções bonitas, mas desconectadas da operação real.

---

## 29.5 BPMN e automação

Nem todo processo deve ser automatizado imediatamente. Primeiro, deve ser entendido e melhorado.

Sequência recomendada:

1. Mapear processo atual.
2. Identificar gargalos.
3. Eliminar etapas desnecessárias.
4. Padronizar regras.
5. Definir responsabilidades.
6. Automatizar o que faz sentido.
7. Medir resultados.

Automatizar um processo ruim apenas torna o erro mais rápido.

---

## 29.6 Exemplo aplicado: atendimento via WhatsApp, IA e GLPI
```mermaid
flowchart TD
    A[Mensagem recebida no WhatsApp] --> B[Identificar intenção]
    B --> C{É dúvida simples?}
    C -- Sim --> D[Responder com base de conhecimento]
    C -- Não --> E{É solicitação de suporte?}
    E -- Sim --> F[Abrir chamado no GLPI]
    E -- Não --> G{É caso crítico?}
    G -- Sim --> H[Encaminhar para humano]
    G -- Não --> I[Solicitar mais informações]
    F --> J[Enviar protocolo ao usuário]
    D --> K[Fim]
    H --> K
    I --> K
    J --> K
```---
## 29.7 Boas práticas de BPMN

- Use verbo + objeto para nomear atividades: “Validar orçamento”, “Enviar contrato”.
- Evite fluxos grandes demais em uma página.
- Modele exceções relevantes.
- Use raias para responsabilidades.
- Valide com quem executa o processo.
- Diferencie processo atual e futuro.
- Não transforme BPMN em desenho decorativo: ele deve apoiar decisão.

---

## Nota Zettelkasten

**ZK-029 — BPMN**

Notação para modelar processos de negócio com eventos, atividades, decisões e participantes, permitindo análise, padronização e automação.

**Conexões:**

- ZK-024 — Problema de Negócio
- ZK-026 — Elicitação
- ZK-030 — Documentação Funcional
- ZK-044 — Processo AS-IS
- ZK-045 — Processo TO-BE

---

## Active Recall — Capítulo 29

1. Qual a diferença entre UML e BPMN?
2. O que é um gateway?
3. Para que servem raias?
4. Por que mapear AS-IS antes do TO-BE?
5. Por que automatizar um processo ruim pode ser perigoso?

---

## Referências recomendadas do capítulo

- SILVER, Bruce. *BPMN Method and Style*. Cody-Cassidy Press.
- DUMAS, Marlon; LA ROSA, Marcello; MENDLING, Jan; REIJERS, Hajo A. *Fundamentals of Business Process Management*. Springer.
- HARMON, Paul. *Business Process Change*. Morgan Kaufmann.
- SHARP, Alec; MCDERMOTT, Patrick. *Workflow Modeling*. Artech House.
- OMG. *Business Process Model and Notation (BPMN) Specification*.

---

# Capítulo 30 — Documentação Funcional

## Objetivos de aprendizagem

Ao final deste capítulo, você será capaz de:

- estruturar uma documentação funcional completa;
- separar objetivo, escopo, regras, fluxos, requisitos e critérios;
- documentar campos, permissões, integrações e exceções;
- escrever documentação útil para desenvolvimento, testes e validação;
- evitar documentos longos sem clareza.

---

## 30.1 O que é documentação funcional?

Documentação funcional descreve como uma funcionalidade, processo ou sistema deve se comportar do ponto de vista do negócio e do usuário.

Ela responde:

- qual problema será resolvido?
- qual é o objetivo?
- quem usa?
- o que está dentro e fora do escopo?
- quais fluxos existem?
- quais regras devem ser respeitadas?
- quais telas e campos são necessários?
- quais integrações existem?
- quais exceções devem ser tratadas?
- quais relatórios são exigidos?
- quais critérios definem sucesso?

A documentação funcional não é burocracia. Ela é **memória, contrato de entendimento e ferramenta de alinhamento**.

---

## 30.2 Estrutura recomendada
```text
1. Identificação do documento
2. Histórico de versões
3. Objetivo
4. Contexto
5. Problema de negócio
6. Escopo
7. Fora de escopo
8. Stakeholders
9. Atores e perfis de acesso
10. Processo atual AS-IS
11. Processo futuro TO-BE
12. Requisitos funcionais
13. Requisitos não funcionais
14. Regras de negócio
15. Protótipos ou wireframes
16. Campos, validações e mensagens
17. Integrações
18. Permissões e auditoria
19. Relatórios e indicadores
20. Exceções e fluxos alternativos
21. Critérios de aceite
22. Riscos e premissas
23. Pendências
24. Glossário
25. Aprovações
```---
## 30.3 Exemplo funcional: abertura de chamado com categoria automática

### Objetivo

Permitir que colaboradores abram chamados e que o sistema sugira automaticamente uma categoria com base no título e na descrição.

### Atores

| Ator | Responsabilidade |
|---|---|
| Colaborador | Abre e acompanha chamados |
| Técnico | Atende chamados |
| Gestor | Consulta indicadores |
| Administrador | Configura categorias e permissões |

### Requisitos funcionais

| ID | Requisito |
|---|---|
| RF01 | O sistema deve permitir abertura de chamado com título e descrição. |
| RF02 | O sistema deve permitir anexar arquivos PDF, PNG e JPG de até 10 MB. |
| RF03 | O sistema deve sugerir categoria automaticamente com base no conteúdo informado. |
| RF04 | O usuário deve poder alterar a categoria sugerida antes do envio. |
| RF05 | O sistema deve registrar a categoria sugerida e a categoria final escolhida. |
| RF06 | O chamado criado deve gerar protocolo. |
| RF07 | O sistema deve enviar notificação ao usuário após abertura. |

### Requisitos não funcionais

| ID | Requisito |
|---|---|
| RNF01 | A sugestão de categoria deve ser retornada em até 3 segundos para 95% dos chamados. |
| RNF02 | Apenas usuários autenticados podem abrir chamados. |
| RNF03 | O sistema deve registrar logs de abertura, alteração e categorização. |
| RNF04 | O sistema deve manter disponibilidade mínima de 99,5% em horário comercial. |

### Regras de negócio

| ID | Regra |
|---|---|
| RN01 | Chamados sem título ou descrição não podem ser enviados. |
| RN02 | Arquivos acima de 10 MB devem ser recusados. |
| RN03 | Categorias críticas devem gerar notificação imediata ao gestor da fila. |
| RN04 | Se a IA não tiver confiança suficiente, a categoria deve ficar como “Triagem Manual”. |
| RN05 | O usuário não pode alterar chamado encerrado. |

### Critérios de aceite
```gherkin
Cenário: Abertura de chamado com categoria sugerida
Dado que o colaborador está autenticado
E informou título e descrição
Quando clicar em "Enviar"
Então o sistema deve criar o chamado
E sugerir uma categoria
E exibir o número de protocolo
E registrar histórico da sugestão
```---
## 30.4 Campos e validações

| Campo | Tipo | Obrigatório | Regra |
|---|---|---|---|
| Título | Texto | Sim | mínimo 5 e máximo 120 caracteres |
| Descrição | Texto longo | Sim | mínimo 20 caracteres |
| Categoria | Lista | Sim | pode ser sugerida automaticamente |
| Prioridade | Lista | Sim | padrão “Média” |
| Anexo | Arquivo | Não | PDF, PNG, JPG até 10 MB |
| Unidade | Lista | Sim | conforme perfil do usuário |

---

## 30.5 Permissões

| Perfil | Pode abrir | Pode atender | Pode encerrar | Pode reabrir | Pode configurar |
|---|---:|---:|---:|---:|---:|
| Colaborador | Sim | Não | Não | Sim, se for autor | Não |
| Técnico | Sim | Sim | Sim | Sim | Não |
| Gestor | Sim | Sim | Sim | Sim | Não |
| Administrador | Sim | Sim | Sim | Sim | Sim |

---

## 30.6 Integrações

| Sistema | Direção | Tecnologia | Observação |
|---|---|---|---|
| GLPI | Saída | API REST | criar chamado quando categoria for suporte |
| E-mail | Saída | SMTP/API | enviar protocolo e notificações |
| Active Directory | Entrada | LDAP/OAuth | autenticação e perfis |
| Base de Conhecimento | Entrada | API/SQL | sugerir artigos relacionados |
| IA | Entrada/Saída | API/Ollama/OpenAI | classificar intenção e categoria |

---

## 30.7 Erros comuns em documentação funcional

- documentar tela sem regra;
- esquecer exceções;
- não definir permissões;
- não especificar mensagens de erro;
- deixar relatório como “completo”;
- não documentar integrações;
- não definir critérios de aceite;
- não registrar decisões;
- escrever documento que ninguém consegue validar.

---

## Nota Zettelkasten

**ZK-030 — Documentação Funcional**

Documento que traduz necessidades de negócio em especificações compreensíveis para usuários, desenvolvedores, testadores, gestores e operação.

**Conexões:**

- ZK-025 — Engenharia de Requisitos
- ZK-027 — História de Usuário
- ZK-028 — UML
- ZK-029 — BPMN
- ZK-046 — Critérios de Aceite
- ZK-047 — Regras de Negócio

---

## Active Recall — Capítulo 30

1. Qual a finalidade da documentação funcional?
2. Por que é importante definir fora de escopo?
3. Como documentar uma regra de negócio?
4. Que informações devem existir em uma integração?
5. Por que campos e validações devem ser especificados?

---

## Referências recomendadas do capítulo

- WIEGERS, Karl; BEATTY, Joy. *Software Requirements*. Microsoft Press.
- ROBERTSON, Suzanne; ROBERTSON, James. *Mastering the Requirements Process*. Addison-Wesley.
- COCKBURN, Alistair. *Writing Effective Use Cases*. Addison-Wesley.
- COHN, Mike. *User Stories Applied*. Addison-Wesley.
- ADZIC, Gojko. *Specification by Example*. Manning.
- BABOK Guide — *A Guide to the Business Analysis Body of Knowledge*. IIBA.

---

# Capítulo 31 — Arquitetura Corporativa

## Objetivos de aprendizagem

Ao final deste capítulo, você será capaz de:

- diferenciar arquitetura de software e arquitetura corporativa;
- compreender visões de negócio, dados, aplicações, tecnologia e integração;
- mapear sistemas corporativos;
- reconhecer riscos de arquitetura fragmentada;
- relacionar estratégia, processos e tecnologia.

---

## 31.1 O que é arquitetura corporativa?

Arquitetura corporativa é a disciplina que organiza a relação entre:

- estratégia;
- capacidades de negócio;
- processos;
- dados;
- aplicações;
- integrações;
- infraestrutura;
- segurança;
- governança.

Ela responde:

> **Como a tecnologia sustenta, limita ou acelera a estratégia da organização?**

---

## 31.2 Arquitetura de software x arquitetura corporativa

| Dimensão | Arquitetura de Software | Arquitetura Corporativa |
|---|---|---|
| Escopo | Um sistema ou produto | Ecossistema organizacional |
| Foco | Componentes, código, bancos, APIs | Estratégia, processos, dados, aplicações e tecnologia |
| Exemplo | Sistema de chamados | GLPI, ERP, CRM, AD, BI, e-mail, integrações |
| Decisões | Framework, banco, deploy, padrões | Mapa de aplicações, governança, integração, dados mestres |
| Horizonte | Projeto/produto | Organização |

---

## 31.3 Camadas da arquitetura corporativa
```mermaid
flowchart TB
    A[Estratégia e Objetivos] --> B[Capacidades de Negócio]
    B --> C[Processos]
    C --> D[Dados]
    D --> E[Aplicações]
    E --> F[Integrações]
    F --> G[Tecnologia e Infraestrutura]
    G --> H[Segurança e Governança]
```---
## 31.4 Visão de negócio

Mapeia:

- áreas;
- objetivos;
- processos;
- indicadores;
- capacidades;
- riscos;
- prioridades.

Exemplo de capacidade:

> Gestão de atendimento interno.

Essa capacidade pode envolver GLPI, chatbot, base de conhecimento, e-mail, relatórios e equipe de suporte.

---

## 31.5 Visão de dados

Mapeia:

- entidades principais;
- dados mestres;
- origem oficial;
- qualidade;
- propriedade;
- sensibilidade;
- ciclo de vida;
- retenção.

Exemplo:

| Entidade | Origem oficial | Sistemas consumidores |
|---|---|---|
| Colaborador | RH/AD | GLPI, Portal, BI |
| Cliente | CRM | ERP, atendimento, financeiro |
| Chamado | GLPI | BI, chatbot, base de conhecimento |
| Produto | ERP | portal, e-commerce, relatórios |

---

## 31.6 Visão de aplicações

Mapeia o portfólio de sistemas:

| Sistema | Finalidade | Dono | Integrações | Risco |
|---|---|---|---|---|
| ERP | Operação financeira e comercial | Financeiro/TI | BI, banco, portal | Alto |
| GLPI | Gestão de chamados | TI | Chatbot, e-mail, BI | Médio |
| CRM | Relacionamento com cliente | Comercial | ERP, e-mail | Médio |
| KnowledgeBase | Base de conhecimento | TI/Inovação | BookWave, IA | Médio |
| n8n | Automação | TI/Inovação | APIs diversas | Alto se sem governança |

---

## 31.7 Visão de integração

Identifica como sistemas conversam:

- API REST;
- SOAP;
- webhooks;
- mensageria;
- arquivos CSV/XML;
- ETL/ELT;
- banco compartilhado;
- RPA;
- conectores SaaS.

Uma arquitetura madura evita “integrações invisíveis”, como planilhas críticas enviadas manualmente por e-mail sem controle.

---

## 31.8 Riscos comuns em arquitetura corporativa

- sistemas duplicados;
- dados divergentes;
- dependência de planilhas;
- integrações manuais;
- falta de dono do dado;
- ausência de logs;
- automações sem governança;
- APIs sem versionamento;
- usuários com permissões excessivas;
- sistemas legados sem documentação;
- decisões técnicas desconectadas da estratégia.

---

## 31.9 TOGAF, capacidades e governança

Frameworks como TOGAF ajudam a organizar arquitetura corporativa, mas o valor não está em decorar o framework. O valor está em criar clareza:

- quais capacidades a empresa precisa fortalecer?
- quais sistemas sustentam essas capacidades?
- quais dados são críticos?
- quais riscos existem?
- quais investimentos têm prioridade?
- quais padrões tecnológicos devem ser adotados?

---

## Nota Zettelkasten

**ZK-031 — Arquitetura Corporativa**

Disciplina que conecta estratégia, processos, dados, aplicações, integração, tecnologia e governança em uma visão integrada da organização.

**Conexões:**

- ZK-014 — Cloud
- ZK-016 — Arquitetura de Software
- ZK-019 — Integração entre Sistemas
- ZK-025 — Engenharia de Requisitos
- ZK-048 — Governança de TI

---

## Active Recall — Capítulo 31

1. Qual a diferença entre arquitetura de software e arquitetura corporativa?
2. O que é uma capacidade de negócio?
3. Por que dados mestres são importantes?
4. Quais riscos surgem em arquiteturas fragmentadas?
5. Como governança ajuda a reduzir risco?

---

## Referências recomendadas do capítulo

- ROSS, Jeanne W.; WEILL, Peter; ROBERTSON, David C. *Enterprise Architecture as Strategy*. Harvard Business Review Press.
- LANKHORST, Marc. *Enterprise Architecture at Work*. Springer.
- BERNARD, Scott A. *An Introduction to Enterprise Architecture*. AuthorHouse.
- THE OPEN GROUP. *TOGAF Standard*. The Open Group.
- VERNADAT, François. *Enterprise Modeling and Integration*. Chapman & Hall.
- FOWLER, Martin. *Patterns of Enterprise Application Architecture*. Addison-Wesley.

---

# Capítulo 32 — Transformando Fundamentos em Projeto Real

## Objetivos de aprendizagem

Ao final deste capítulo, você será capaz de:

- conduzir um fluxo profissional de análise;
- conectar requisitos, processos, arquitetura e implantação;
- construir um pacote mínimo de documentação;
- especificar um projeto corporativo real;
- preparar transição para o Volume II.

---

## 32.1 Fluxo profissional de análise

Um fluxo realista de trabalho:
```mermaid
flowchart TD
    A[Entender problema] --> B[Identificar stakeholders]
    B --> C[Mapear AS-IS]
    C --> D[Levantar dores e riscos]
    D --> E[Elicitar requisitos]
    E --> F[Priorizar escopo]
    F --> G[Modelar TO-BE]
    G --> H[Documentar funcionalmente]
    H --> I[Validar com usuários]
    I --> J[Apoiar arquitetura técnica]
    J --> K[Planejar testes]
    K --> L[Acompanhar desenvolvimento]
    L --> M[Validar entrega]
    M --> N[Apoiar implantação]
    N --> O[Medir resultados]
```---
## 32.2 Pacote mínimo de documentação profissional

Para projetos pequenos ou médios, um bom pacote pode conter:

1. Declaração do problema.
2. Objetivo de negócio.
3. Escopo e fora de escopo.
4. Stakeholders.
5. Processo AS-IS.
6. Processo TO-BE.
7. Requisitos funcionais.
8. Requisitos não funcionais.
9. Regras de negócio.
10. Histórias de usuário.
11. Critérios de aceite.
12. Modelo inicial de dados.
13. Integrações.
14. Permissões.
15. Relatórios.
16. Riscos.
17. Plano de testes.
18. Plano de implantação.

---

## 32.3 Exemplo aplicado: sistema corporativo de solicitações internas

### Problema

Solicitações internas chegam por e-mail, WhatsApp, planilhas e conversas informais, dificultando rastreabilidade, priorização, SLA e auditoria.

### Objetivo

Centralizar solicitações internas de TI, RH, Financeiro, Jurídico, Compras e Facilities em uma plataforma única com fluxos, permissões, anexos, aprovações, histórico e relatórios.

### Atores

- Colaborador;
- Gestor;
- Analista da área;
- Administrador;
- Auditor;
- Sistema externo.

### Requisitos funcionais iniciais

| ID | Requisito |
|---|---|
| RF01 | O sistema deve permitir que colaboradores abram solicitações por categoria. |
| RF02 | O sistema deve permitir anexar documentos. |
| RF03 | O sistema deve direcionar solicitações para a área responsável. |
| RF04 | O sistema deve permitir aprovação por gestor quando aplicável. |
| RF05 | O sistema deve registrar histórico de alterações. |
| RF06 | O sistema deve enviar notificações de mudança de status. |
| RF07 | O sistema deve permitir relatórios por área, status, categoria e SLA. |
| RF08 | O sistema deve permitir integração com GLPI para solicitações de TI. |
| RF09 | O sistema deve permitir configuração de regras por categoria. |
| RF10 | O sistema deve permitir pesquisa na base de conhecimento antes da abertura. |

### Requisitos não funcionais

| ID | Requisito |
|---|---|
| RNF01 | O sistema deve autenticar usuários por conta corporativa. |
| RNF02 | O sistema deve registrar logs de ações críticas. |
| RNF03 | O sistema deve carregar telas principais em até 3 segundos para 95% dos acessos. |
| RNF04 | O sistema deve aplicar controle de acesso por perfil e área. |
| RNF05 | O sistema deve manter backup diário da base de dados. |
| RNF06 | O sistema deve operar com disponibilidade mínima de 99,5% em horário comercial. |

### Regras de negócio

| ID | Regra |
|---|---|
| RN01 | Solicitações jurídicas só podem ser visualizadas por Jurídico, solicitante e aprovadores. |
| RN02 | Solicitações financeiras acima de determinado valor exigem aprovação do gestor. |
| RN03 | Solicitações de TI classificadas como incidente devem poder gerar chamado no GLPI. |
| RN04 | Solicitações encerradas só podem ser reabertas pelo solicitante dentro de prazo definido. |
| RN05 | Toda alteração de status deve gerar histórico. |

---

## 32.4 Modelo inicial de dados
```mermaid
erDiagram
    USUARIO ||--o{ SOLICITACAO : abre
    AREA ||--o{ CATEGORIA : possui
    CATEGORIA ||--o{ SOLICITACAO : classifica
    SOLICITACAO ||--o{ ANEXO : possui
    SOLICITACAO ||--o{ HISTORICO : registra
    USUARIO ||--o{ HISTORICO : executa
    SOLICITACAO ||--o{ APROVACAO : exige
    USUARIO ||--o{ APROVACAO : aprova

    USUARIO {
        int id
        string nome
        string email
        string perfil
    }

    AREA {
        int id
        string nome
    }

    CATEGORIA {
        int id
        string nome
        int area_id
    }

    SOLICITACAO {
        int id
        string titulo
        string descricao
        string status
        datetime data_abertura
    }

    ANEXO {
        int id
        string nome_arquivo
        string caminho
    }

    HISTORICO {
        int id
        string acao
        datetime data_hora
    }

    APROVACAO {
        int id
        string status
        datetime data_decisao
    }
```---
## 32.5 Arquitetura sugerida
```mermaid
flowchart LR
    U[Usuário] --> W[Portal Web]
    W --> API[API REST]
    API --> AUTH[Autenticação]
    API --> DB[(Banco de Dados)]
    API --> FS[Armazenamento de Arquivos]
    API --> MQ[Fila de Mensagens]
    MQ --> NOTIF[Serviço de Notificação]
    MQ --> GLPI[Integração GLPI]
    MQ --> IA[Serviço de IA]
    API --> LOG[Logs e Auditoria]
    DB --> BI[Relatórios/BI]