Processos x Requisitos

1. O processo como história da atividade

Todo processo representa uma atividade realizada por pessoas, setores ou sistemas. Ele mostra o começo, o meio e o fim de uma situação.

Por exemplo, em um sistema de chamados técnicos, a história pode começar assim:

Um usuário percebe um problema em um equipamento. Ele acessa o sistema, informa o problema, identifica o equipamento e registra a solicitação. O sistema cria um chamado com status inicial. Depois, a equipe técnica analisa o chamado, classifica o tipo de atendimento, define um responsável e registra os andamentos até a conclusão.

Esse texto conta a história do processo. Ele mostra quem participa, o que acontece primeiro, o que acontece depois e qual é o resultado esperado.

Dentro dessa história, aparecem naturalmente as funções que o sistema precisa ter.

2. Os requisitos funcionais dentro da história

Os requisitos funcionais não devem surgir soltos. Eles devem nascer das necessidades do processo.

Veja este trecho:

O usuário acessa o sistema e registra uma solicitação de atendimento.

Desse trecho, podemos extrair um requisito funcional:

RF001 — O sistema deve permitir cadastrar uma solicitação de atendimento.

Agora veja outro trecho:

A equipe técnica analisa o chamado e classifica o tipo de problema.

Daqui nasce outro requisito:

RF002 — O sistema deve permitir classificar o chamado por tipo de problema.

E mais um exemplo:

O técnico registra as ações realizadas durante o atendimento.

Esse trecho chama o requisito:

RF003 — O sistema deve permitir registrar andamentos no chamado.

Assim, o processo conta a história, e os requisitos são chamados conforme a história avança.

3. Ligação entre processo e requisito funcional

A relação pode ser entendida assim:

Parte da história do processo	Requisito funcional chamado
Usuário informa o problema	RF001 — Cadastrar chamado
Sistema registra data e solicitante	RF002 — Registrar dados iniciais do chamado
Técnico analisa a solicitação	RF003 — Consultar detalhes do chamado
Técnico classifica o problema	RF004 — Classificar chamado
Técnico registra atendimento	RF005 — Registrar andamento
Chamado é finalizado	RF006 — Encerrar chamado
Usuário consulta o resultado	RF007 — Consultar histórico do chamado

Essa ligação é importante porque mostra que cada requisito tem uma razão para existir. Ele não foi criado apenas porque alguém imaginou uma função, mas porque o processo precisa daquela ação.

4. Como escrever o processo em forma textual

A forma textual é uma das maneiras mais simples de documentar um processo. Ela deve ser clara, organizada e escrita como uma sequência de acontecimentos.

Um bom texto de processo pode seguir esta estrutura:

Nome do processo: Abertura e atendimento de chamado técnico.

Objetivo: Permitir que usuários registrem problemas e que a equipe técnica acompanhe o atendimento até a conclusão.

Participantes: Usuário solicitante, equipe técnica e administrador do sistema.

Descrição textual do processo:

O processo inicia quando o usuário identifica um problema em um equipamento ou serviço. Ele acessa o sistema e preenche uma solicitação informando a descrição do problema, o equipamento relacionado e a unidade onde ocorreu a situação.

Após o envio, o sistema registra o chamado com data, solicitante e status inicial. A equipe técnica consulta os chamados pendentes, analisa a solicitação e define uma classificação para o atendimento.

Em seguida, um técnico responsável é designado. Durante o atendimento, o técnico registra os andamentos realizados, podendo alterar o status do chamado conforme a evolução da atividade.

Quando o problema é resolvido, o técnico registra a conclusão e encerra o chamado. O sistema mantém o histórico disponível para consulta futura.

Agora, dentro desse texto, podemos apontar os requisitos chamados:

Trecho do processo	Requisito
“o usuário acessa o sistema”	RF001 — Autenticar usuário
“preenche uma solicitação”	RF002 — Cadastrar chamado
“informa a descrição do problema”	RF003 — Registrar descrição do chamado
“equipamento relacionado”	RF004 — Vincular equipamento ao chamado
“o sistema registra o chamado com data, solicitante e status inicial”	RF005 — Gerar chamado com dados automáticos
“equipe técnica consulta os chamados pendentes”	RF006 — Listar chamados pendentes
“define uma classificação”	RF007 — Classificar chamado
“um técnico responsável é designado”	RF008 — Atribuir responsável
“registra os andamentos realizados”	RF009 — Registrar andamento
“altera o status”	RF010 — Alterar status do chamado
“encerra o chamado”	RF011 — Encerrar chamado
“mantém o histórico disponível”	RF012 — Consultar histórico

Perceba que o processo vem primeiro. Os requisitos são extraídos dele.

5. Como representar o processo por fluxograma

Além do texto, o processo também pode ser contado por fluxograma. O fluxograma mostra visualmente o caminho da atividade.

Ele ajuda a entender:

onde o processo começa;
quais decisões precisam ser tomadas;
quais etapas são executadas;
quem participa;
onde o processo termina.

Um exemplo simples:

[Início]
   |
   v
[Usuário identifica problema]
   |
   v
[Usuário cadastra chamado]
   |
   v
[Sistema registra chamado com status "Aberto"]
   |
   v
[Equipe técnica analisa chamado]
   |
   v
{Chamado é válido?}
   | Sim
   v
[Classificar chamado]
   |
   v
[Atribuir técnico responsável]
   |
   v
[Técnico registra andamento]
   |
   v
{Problema resolvido?}
   | Sim
   v
[Encerrar chamado]
   |
   v
[Fim]

Se "Chamado é válido?" = Não:
   v
[Cancelar chamado]
   |
   v
[Fim]

Se "Problema resolvido?" = Não:
   v
[Manter chamado em atendimento]
   |
   v
[Técnico registra novo andamento]

Nesse fluxograma, cada caixa de ação pode chamar um requisito funcional.

6. Requisitos chamados dentro do fluxograma

O fluxograma pode ser anotado com os requisitos. Assim:

[Início]
   |
   v
[Usuário identifica problema]
   |
   v
[Usuário cadastra chamado]  -> RF002
   |
   v
[Sistema registra chamado com status "Aberto"]  -> RF005
   |
   v
[Equipe técnica analisa chamado]  -> RF006
   |
   v
{Chamado é válido?}
   | Sim
   v
[Classificar chamado]  -> RF007
   |
   v
[Atribuir técnico responsável]  -> RF008
   |
   v
[Técnico registra andamento]  -> RF009
   |
   v
{Problema resolvido?}
   | Sim
   v
[Encerrar chamado]  -> RF011
   |
   v
[Fim]

Essa forma deixa muito clara a ligação entre processo e requisitos.

O processo mostra a ordem da atividade.
O requisito mostra a função que o sistema precisa executar naquela etapa.

7. Exemplo completo de processo com requisitos funcionais

Processo: Atendimento de chamado técnico

O processo começa quando um usuário encontra um problema em um equipamento. Para iniciar o atendimento, ele acessa o sistema e informa os dados da solicitação.

Nesse momento, são chamados os seguintes requisitos:

RF001 — O sistema deve permitir autenticar o usuário.
RF002 — O sistema deve permitir cadastrar um novo chamado.
RF003 — O sistema deve permitir informar a descrição do problema.
RF004 — O sistema deve permitir vincular um equipamento ao chamado.

Depois que o chamado é enviado, o sistema registra automaticamente a data de abertura, o solicitante e o status inicial.

Aqui são chamados:

RF005 — O sistema deve registrar automaticamente a data de abertura do chamado.
RF006 — O sistema deve atribuir status inicial ao chamado.

Em seguida, a equipe técnica consulta os chamados pendentes e analisa a solicitação.

Nesse ponto, entram:

RF007 — O sistema deve permitir listar chamados pendentes.
RF008 — O sistema deve permitir visualizar os detalhes do chamado.

Após a análise, o chamado pode ser classificado e encaminhado para um técnico responsável.

Aqui são chamados:

RF009 — O sistema deve permitir classificar o chamado.
RF010 — O sistema deve permitir atribuir responsável ao chamado.

Durante o atendimento, o técnico registra as ações realizadas.

Nesse momento, o sistema precisa atender:

RF011 — O sistema deve permitir registrar andamentos no chamado.
RF012 — O sistema deve permitir alterar o status do chamado.

Ao final, o técnico encerra o chamado e registra a conclusão.

Aqui entram:

RF013 — O sistema deve permitir registrar a conclusão do chamado.
RF014 — O sistema deve permitir encerrar o chamado.
RF015 — O sistema deve manter histórico do atendimento.

Dessa forma, a documentação mostra claramente que os requisitos funcionais não estão isolados. Eles aparecem dentro da história do processo.

8. Diferença entre processo e requisito

É importante separar bem as duas coisas.

Processo é a história da atividade.

Exemplo:

O técnico recebe o chamado, analisa o problema, registra o atendimento e encerra a solicitação.

Requisito funcional é o que o sistema precisa permitir.

Exemplo:

O sistema deve permitir registrar o atendimento realizado pelo técnico.

O processo pertence à regra do trabalho.
O requisito pertence à solução do sistema.

9. Como analisar um processo

Para analisar um processo, é preciso observar a atividade real e perguntar:

Quem inicia o processo?
Qual informação entra no sistema?
Quem consulta essa informação?
Quais decisões são tomadas?
Quais ações o sistema precisa permitir?
Quais registros precisam ser guardados?
Qual é o resultado final?
O que acontece se houver erro, cancelamento ou exceção?

Depois disso, o analista deve transformar cada necessidade do processo em requisito funcional.

Exemplo:

Necessidade do processo: o técnico precisa informar o que foi feito.
Requisito funcional: o sistema deve permitir registrar andamento técnico.

Necessidade do processo: o administrador precisa saber quais chamados estão atrasados.
Requisito funcional: o sistema deve permitir consultar chamados por status, data e responsável.

Necessidade do processo: o usuário precisa acompanhar sua solicitação.
Requisito funcional: o sistema deve permitir consultar o andamento do chamado.

10. Como validar se os requisitos estão bem ligados ao processo

Uma boa pergunta para testar a documentação é:

Em qual parte do processo este requisito é usado?

Se não for possível responder, talvez o requisito esteja mal definido, duplicado ou fora do escopo.

Outra pergunta importante é:

Existe alguma etapa do processo que não possui requisito correspondente?

Se existir, o sistema pode ficar incompleto.

Por isso, a ligação entre processo e requisito ajuda a evitar falhas no desenvolvimento.

11. Modelo simples para documentar

Um modelo simples pode ser assim:

Nome do processo

Atendimento de chamado técnico.

Objetivo

Registrar, acompanhar e finalizar solicitações de suporte técnico.

Participantes

Usuário solicitante, técnico responsável e administrador.

Descrição do processo

Texto contando a história da atividade do começo ao fim.

Fluxo resumido

Usuário solicita atendimento
        ↓
Sistema registra chamado
        ↓
Técnico analisa
        ↓
Chamado é classificado
        ↓
Técnico atende
        ↓
Chamado é encerrado

Requisitos funcionais relacionados

Código	Requisito	Etapa do processo
RF001	Autenticar usuário	Acesso ao sistema
RF002	Cadastrar chamado	Solicitação inicial
RF003	Vincular equipamento	Cadastro do chamado
RF004	Listar chamados	Análise técnica
RF005	Classificar chamado	Triagem
RF006	Atribuir responsável	Encaminhamento
RF007	Registrar andamento	Atendimento
RF008	Alterar status	Acompanhamento
RF009	Encerrar chamado	Finalização
RF010	Consultar histórico	Pós-atendimento

12. Conclusão

O processo é a narrativa da atividade. Ele conta como o trabalho acontece, quem participa, quais informações circulam e qual resultado deve ser alcançado.

Os requisitos funcionais são chamados dentro dessa narrativa. Cada vez que o processo exige uma ação do sistema, nasce um requisito.

Por isso, uma boa documentação deve primeiro contar a história do processo e depois mostrar quais requisitos aparecem em cada etapa. Essa ligação torna o sistema mais fácil de entender, desenvolver, testar e manter.

O processo pode ser contado de forma textual, explicando a sequência das ações, ou por fluxogramas, mostrando visualmente o caminho da atividade. O ideal é usar os dois: o texto explica a história, e o fluxograma mostra o caminho.