***********Aula 1 PROCESSOS DE NEGÓCIO E

NOTAÇÃO BPMN********
Descrição: - Entender o que são processos de negócio
- Mapeando os processos "as is" e elaborando o "to be"
- Conhecendo e aplicando a notação BPMN em processos de negócios
- Aprofundando o conhecimento da notação BPMN
- Analisando um exemplo de modelagem de processo

**Mas, afinal, o que é um processo de negócio? Ele pode ser definido como um
conjunto de tarefas estruturadas e relacionadas, o qual tem como objetivo produzir
um serviço ou produto específico. Esse produto ou serviço é entregue a um cliente
específico ou um conjunto de clientes (Paim et al., 2009), ou seja, todo processo
de negócio tem como objetivo gerar um produto ou serviço. Dessa forma, um processo
de negócio que não gera um produto ou serviço não tem razão de existir.**

**Assim, é comum classificar os processos de negócios em três categorias,

dependendo do seu objetivo final, como processos primários, processos de suporte e
processos gerenciais **

**Processos primários:
Os processos primários, também conhecidos como processos finalísticos, são os
processos essenciais de uma empresa, que representam as atividades que uma empresa
desempenha para cumprir sua missão. Pode-se destacar como processo primário a
criação de um produto, a venda de um serviço, a realização de uma campanha de
marketing ou qualquer outro processo cujo objetivo da saída seja atender à
necessidade de um cliente do negócio.**

** Processos de suporte:
Os processos de suporte são aqueles processos que oferecem algum apoio e suportam
os processos primários. Ou seja, os processos de suporte facilitam ou viabilizam o
caminho para que os processos primários possam ser executados. Os processos de
suporte estão em todos os departamentos, sempre com o objetivo de apoiar o negócio
final. O processo de contratação de profissionais do departamento de RH é um
processo de suporte.**

**Processos de manutenção:
O processo de manutenção de software do departamento de TI é um processo de
suporte, pois garante que os softwares necessários para automatizar a construção
dos produtos da empresa estejam disponíveis e funcionando adequadamente. Os
processos da limpeza e segurança também são processos de suporte, pois garantem um
ambiente de trabalho agradável e seguro**

**Os processos gerenciais, por sua vez, são processos criados para coordenar e
controlar as atividades da empresa. O grande objetivo desses processos é gerir
melhor e garantir a execução adequada dos processos primários e secundários,
traçando planos e garantindo o atingimento das metas estratégicas definidas pela
empresa.**

**Documentando os processos de negócio:

Os processos de negócio servem para formalizar a visão da empresa sobre sua forma
de funcionamento, ou seja, organizam como as empresas funcionam. Uma montadora de
carros tem como objetivo final projetar, construir e fabricar carros, porém cada
montadora faz isso de uma forma diferente.**

**MAPEANDO OS PROCESSOS AS IS E ELABORANDO O TO BE:

O primeiro passo no mapeamento e na gestão de processos é justamente identificar
processos. Parece óbvio, mas nem sempre é simples identificar os processos, pois um
processo pode passar por vários departamentos e ser executado por diversos
profissionais, dificultando assim o entendimento de todos os passos envolvidos
desde seu início até sua finalização.**

**De acordo com Ogunnaike e Ray (1994), as principais características de um

processo são:

Processo é uma junção de atividades e recursos;

Processo é voltado à realização de um objetivo global;
Processo é orientado para o cliente final;
Processo é reforçado de maneira recorrente, para virar hábito;
Processo deve ter desempenho, organização e responsabilidades;
Processo é uma organização estruturada de tarefas;
Processo tem entrada e processamento, para gerar um resultado como saída.**

**Entendendo o que são os processos AS IS:

Após identificar um processo, é preciso mapear os passos que são executados do seu
início até sua finalização. Esse mapeamento é chamado de AS IS (traduzindo para
português, seria um sinônimo para como é), ou seja, é a identificação dos passos do
processo como ele é executado no momento do mapeamento.

A técnica de mapeamento de processos AS IS envolve o levantamento e a documentação

da situação atual do processo, a qual é representada em um fluxo. Durante o
mapeamento dos processos AS IS, é possível identificar também os problemas,
falhas ou fragilidades, assim como as oportunidades de melhoria do processo.**

**Para mapear o processo AS IS, é preciso entrevistar as pessoas que executam o

processo ou mesmo analisar a execução do processo presencialmente. Por isso é
preciso identificar todos os profissionais que de alguma forma interagem com o
processo, para ter a visão completa de todos os passos e de como esses passos são
executados. **

**é preciso tomar alguns cuidados no momento do mapeamento do processo, tais como:

Sempre fazer a documentação junto aos gestores, para garantir a aderência ao

que realmente é feito no dia a dia;
Conversar com os gestores sobre as melhorias e possíveis ganhos que são
esperados, além de entender se no futuro o processo continuará sendo executado.
Isso ajuda a identificar as falhas que devem ser corrigidas no processo TO BE;
Definir o padrão de notação para o mapeamento e a ferramenta que será
utilizada, para garantir o padrão do mapeamento de todos os processos. Atualmente o
padrão mais adotado é o BPMN (Business Process Model and Notation), por ser um
padrão de fácil compreensão e utilização.**

**Outro ponto importante e que é uma característica fundamental de um bom analista

de negócios é a visão crítica e questionadora, para identificar problemas que
precisam ser resolvidos.**

**Elaborando os processos TO BE:

Após mapear o processo AS IS, ou seja, identificar e entender como o processo é
executado no momento da modelagem, fica mais fácil propor correções de falhas e
melhorias para deixar o processo mais eficiente e ágil. Para propor um novo
processo de negócio ou melhorias no processo já existente, é utilizada a técnica TO
BE, quando são realizadas discussões, definições e documentação da proposta de
situação futura para o processo. Essa proposta também é representada por meio de um
fluxo, que pode ser chamado de redesenho ou modelagem. **
**Para que o processo TO BE seja útil e traga os benefícios esperado, é importante
reforçar alguns passos que devem ser realizados, tais como:

Trabalhar de forma priorizada com pequenos blocos do processo, para que

melhorias controladas sejam propostas;
Cuidar para que apenas pessoas que possam contribuir para melhorar o processo
estejam nas reuniões de elaboração do TO BE, evitando dessa forma pessoas apegadas
com o processo antigo e que possam atrapalhar a visão de melhorias para o processo
futuro;
Evitar pensar nas restrições ou limitações, mas sim em como o processo deveria
ser, simplificando ao máximo as tarefas que fazem parte do processo;
Validar com a alta gestão toda nova sugestão para o processo, garantindo que a
visão e estratégia da empresa estão sendo respeitados.**

**CONHECENDO E APLICANDO A NOTAÇÃO BPMN EM PROCESSOS DE NEGÓCIO:

Toda a gestão dos processos só é possível se os envolvidos no processo entenderem
os fluxos modelados, identificando as tarefas realizadas, assim como a ordem de
execução e os relacionamentos entre elas. Para que todos os envolvidos consigam
entender o processo modelado, é preciso usar uma linguagem única de fácil leitura e
compreensão de todos. **

**Essa linguagem única ou notação é baseada na disciplina BPM (sigla que em

português significa modelagem de processos de negócio), que é a mais utilizada
atualmente para modelar e fazer a gestão dos processos de negócios. O BPM é,
portanto, uma disciplina de gestão própria para entender o funcionamento dos
processos de negócios que considera os seguintes pontos:

As pessoas e as formas como elas trabalham juntas;

O mapeamento, análise, redesenho e implantação de processo de negócio;
O cumprimento de objetivos que os processos devem sustentar (ligação entre os
processos e a estratégia);
O gerenciamento dos processos de ponta a ponta, do seu início até sua
finalização, gerando o resultado esperado;
Mudanças na organização para suportar o gerenciamento de processos, podendo
sugerir até novos papéis e responsabilidades.

Resumindo, então, o BPM combina processos de negócio, pessoas, tecnologia e

organização para criar uma visão única e integrada de negócios.**

**O BPM propõe a notação BPMN (que, em português, significa notação para modelagem
de processos de negócio), que é amplamente utilizada pelos analistas de negócio e
de fácil entendimento por todos os envolvidos com processos de negócios. **

**Evento de início (verde) ou de fim (vermelho) – círculo: são eventos que mostram
qual ator inicia e finaliza um processo. Um processo pode ter mais de um início e
mais de um fim, caso seja necessário. Por exemplo, um processo pode ser iniciado
por contato telefônico ou por acesso a um site, e pode ser finalizado utilizando-se
de mais de um caminho diferente, mostrando as opções de finalizações possíveis,
dependendo da situação de decisão escolhida.**

**Atividades ou tarefas – retângulo: representam um trabalho realizado em uma etapa

do processo de negócio. É um passo do processo. As atividades são sequenciais e uma
atividade chama a próxima atividade, mostrando como elas estão relacionadas. **

**Fluxo de sequência – seta: o conector de fluxo de sequência é representado por

meio de uma linha sólida com uma seta preenchida apontando para o destino. Um fluxo
de sequência deve partir de um único elemento e apontar para um outro elemento
único, para que o fluxo seja claramente compreendido. Se um fluxo de sequência
deixa dúvida quanto ao seu caminho, apontando para mais de um elemento, esse fluxo
deve ser revisado, pois não consegue direcionar para onde vai, gerando dúvida
quanto à execução do processo.**

**Gateway (porta ou acesso) – losango: é o elemento que utiliza questionamento

lógico para decisões de fluxos diferentes no processo, ou seja, é o elemento
utilizado para separar ou juntar os diferentes caminhos de um processo.**

**APROFUNDANDO O CONHECIMENTO DA NOTAÇÃO BPMN:

Além dos elementos principais que vimos anteriormente, o BPMN ainda oferece
especializações dos elementos principais, de forma a facilitar a leitura do fluxo e
o entendimento de como um processo funcionará de forma automatizada. Os elementos
principais já vistos anteriormente permitem modelar um bom fluxo, porém com as
especializações é possível, inclusive, pensar em como o TO BE funcionará apoiado
por um software. Nesse momento, já estamos avançando na modelagem dos processos de
negócio, modelando sua futura automatização. **

**
Tarefa comum – é a tarefa sem nenhuma especialização, ou seja, a tarefa que
reflete apenas os passos a serem seguidos, sem especificar como estes passos serão
realizados;
Tarefa do tipo serviço – é uma tarefa executada de forma automatizada, ou seja,
identifica tarefas que serão executadas através de um software.
Tarefa de recebimento – é um tipo de tarefa que aguarda uma mensagem externa
para continuar o processamento do processo. Por exemplo, imagina uma proposta de
seguro que aguarda o OK do cliente para continuar com a contratação do seguro;
Tarefa de envio – é um tipo de tarefa programada para enviar uma mensagem
externa ao sistema. Por exemplo, um envio de e-mail, SMS ou até mesmo WhatsApp;
Tarefa de usuário – é um tipo de tarefa comandada por um usuário, ou seja, não
é completamente automática, mas que tem um software apoiando, ou seja, podemos
entender esse tipo de tarefa como sendo o preenchimento de um cadastro no sistema
de compra de produtos, por exemplo, em que o atendente preenche os dados do cliente
e o sistema processa a compra;
Tarefa script – uma tarefa do tipo script é uma tarefa automatizada, que pode
ser executada pelo sistema no momento de um processamento ou durante a noite, por
exemplo. Imagina que uma empresa tenha um sistema que processe todas as vendas
realizadas durante o dia, com um script programado para rodar e processar as vendas
do dia anterior sempre às 2:00 da manhã. Para representar este tipo de tarefa em um
processo de negócio, podemos utilizar a tarefa do tipo script;
Tarefa manual – é uma tarefa sem nenhum apoio de um software, ou seja, uma
tarefa executada em sua totalidade por um usuário. Um exemplo desse tipo de tarefa
poderia ser um processo de venda de seguro, em que o corretor liga para o cliente
para oferecer uma cotação. Essa tarefa de ligar para o cliente é totalmente manual,
pois é o atendente pegando um telefone e fazendo uma ligação para o cliente.**
**Eventos:
Assim como ocorre com as tarefas, os eventos também podem ser especializados, para
facilitar o entendimento do processo de negócio, ou seja, para facilitar o
entendimento de como será o TO BE. Vamos conhecer alguns eventos especializados: **

**Além dos eventos de início e fim de processo, podemos encontrar eventos

intermediários, como:

-Evento de envio de mensagem – é um evento muito parecido com a tarefa de envio de

mensagem, em que o sistema está programado para enviar uma mensagem para que o
fluxo do processo continue. A diferença entre uma tarefa e um evento de envio de
mensagem é a forma de implementação do código. Ou seja, usando tarefas podemos
programar a ocorrência de repetição e multi-instância. Por outro lado, a utilização
de eventos para receber as mensagens permitem gerenciar fluxos através de controles
como o uso do gateway baseado em eventos, o que não seria possível com o uso de
atividades. Portanto, a escolha do uso de um evento ou de uma tarefa de envio de
mensagem depende da implementação que será feita no software. Para efeito de
entendimento de um fluxo de processo de negócio, não faz diferença utilizar um
evento ou uma tarefa de envio de mensagem;
-Evento de recebimento de mensagem – ocorre o mesmo já explicado anteriormente
para o envio de mensagem, só que nesse tipo de evento a ordem é invertida, pois o
sistema pausa o fluxo de processamento até que uma mensagem seja recebida;
-Evento de tempo – este evento mostra que o fluxo do processo fica parado,
aguardando a conclusão de alguma outra ação. Como no exemplo da Figura 10, o fluxo
do processo permite até dois dias de prazo para o recebimento de uma proposta, e só
depois disso o processo continua com as demais tarefas que serão executadas.

///////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////

**********************************Aula 2 HISTÓRICO E DIAGRAMA DE FLUXO DE

DADOS ***********************************************************

Descrição: - Análise de sistemas - a história

- Análise estruturada
- Diagrama de fluxo de dados (DFD)
- Níveis de um DFD
- Analisando um exemplo de DFD

**Análise de sistemas:
A análise de sistemas tem como finalidade a realização de estudos de processos a
fim de encontrar o melhor caminho lógico para que a informação possa ser
processada. Segundo Pressman (2016), a análise de sistemas é uma prática baseada em
modelos, com o objetivo de obter um melhor entendimento da entidade real a ser
construída.**

**Os modelos de projetos representam as características que ajudam tecnicamente a

entender o funcionamento do software, sendo elas: a arquitetura; a interface do
usuário ou camada visual do software; e os detalhes no nível de componentes, que é
a camada física relacionada com a construção efetiva do software.**

**A evolução da análise de sistemas propôs três grandes métodos de modelagem de

sistemas, sendo eles: modelagem estruturada, modelagem essencial e modelagem
orientada a objetos.***
**A análise estruturada está fundamentada na decomposição funcional do problema, ou
seja, foca de forma principal nas funcionalidades que o software deve entregar. A
modelagem estruturada utiliza um conjunto de ferramentas para organizar a visão de
análise do problema, sendo o DFD e o Dicionário de Dados (DD) as principais
ferramentas.**

**A análise essencial é considerada uma evolução da análise estruturada, mas com
diferenças essenciais da decomposição do problema. Ela se utiliza das mesmas
ferramentas de modelagem da análise estruturada, mas, em vez de uma decomposição do
mais geral para o mais específico (top-down), o método prevê que sejam
identificados, inicialmente, os eventos externos que acionam o software, sendo
derivadas, então, as ações (ou funções) em resposta a esses eventos e,
posteriormente, os eventos gerados internamente e também as respectivas ações.**

**A análise orientada a objetos procura compreender o problema a ser resolvido por
meio de simples objetos do mundo real. Objeto é uma entidade real ou abstrata que
modela um conceito presente na realidade humana, ocupando espaço físico ou lógico.
Por exemplo, um produto é um objeto com informações e características próprias. Um
produto pode ter um código que o identifique, um nome, um peso, dimensões e outras
características que façam sentido para o foco que o sistema quer dar ao objeto. Um
objeto pode também ser algo não físico, como uma venda ou mesmo uma data de
realização, produtos comprados, valor de venda, identificação do cliente, e outras
características que estejam relacionadas ao objetivo dos requisitos.**

**O analista de sistemas: Os analistas de sistemas estudam como o comportamento e

as funcionalidades do software serão desenvolvidos por meio dos requisitos,
transformando-se em soluções que serão padronizadas e transcritas da forma que o
computador possa executar.**

**Os analistas de sistemas projetam softwares, que são executados em hardwares e

são operados por usuários. Portanto, eles precisam traduzir a linguagem dos
negócios em linguagem técnica, que vai se transformar em linhas de código pelas
mãos dos programadores. Dessa forma, o analista de sistemas é o profissional que,
por meio do trabalho do analista de requisitos, projeta uma solução, baseada na
arquitetura definida pelo arquiteto de software, gerando modelos e documentos que
serão utilizados pelos programadores na construção do software.**

**ANÁLISE ESTRUTURADA:
A análise estruturada de sistemas é composta por um conjunto de técnicas e
ferramentas que continuam em constante evolução, apesar de ser um método mais
antigo de se fazer análise de sistemas.
O objetivo principal da análise estruturada é a construção de um modelo lógico e
não de um modelo físico de sistema. Ou seja, a análise estruturada busca
compreender a lógica por trás de cada funcionalidade que precisa ser desenvolvida
no software. Como toda modelagem, a análise estruturada também utiliza técnicas
gráficas.**

**A análise estruturada tem como objetivo fornecer uma abordagem sistemática, etapa
por etapa, para desenvolver a análise e produzir uma especificação de sistema
adequada para resolver o problema do cliente. Para conseguir esse objetivo, a
análise estruturada busca uma comunicação clara, direta e concisa.**

**O principal objetivo da análise é produzir uma especificação do sistema que

defina a estrutura do problema a ser resolvido de acordo com a visão do usuário e
em uma linguagem que possa ser entendida pela equipe técnica. **

**Vários benefícios podem ser identificados quando a análise estruturada é

utilizada, tais como:
Os usuários conseguem ter uma ideia mais clara do sistema proposto com o uso do
diagrama de fluxo de dados em comparação ao obtido por meio apenas de narrativa e
de fluxograma de sistemas físicos;
A apresentação dos requisitos em termos de fluxo lógico consegue mostrar mal-
entendidos e pontos controversos, minimizando problemas em estágios mais avançados
da construção do software;
As interfaces entre o novo sistema e outros sistemas já existentes são
mostrados de modo bem mais claro, facilitando a compreensão da comunicação entre
eles;
O uso de dicionário de dados para guardar os itens do glossário do projeto
economiza tempo ao resolver rapidamente os casos em que pessoas chamam as mesmas
coisas por diferentes nomes, além de criar um padrão de nomenclatura que ajuda na
qualidade de construção do software.**

**Alguns problemas também podem ser encontrados ao se utilizar análise de estrutura

para modelar um software, principalmente quando o software é complexo e precisa de
outras visões para ser mais bem compreendido e projetado. Vamos discutir alguns dos
problemas que podem ser identificados, tais como:
O esforço, a formalidade e o grau de detalhe necessários, especialmente na
construção do dicionário de dados, muitas vezes, geram resistência por parte dos
analistas de sistemas. Mas é importante reforçar que toda documentação de software
deve agregar valor ao entendimento do problema, por isso deve ser focada no que é
principal e essencial para o correto entendimento. E toda documentação deve ser
mantida, ou seja, deve evoluir junto com as modificações nos requisitos do
software. Uma documentação desatualizada pode ser fonte de confusão e desinformação
em um projeto;
Tem havido uma certa preocupação por parte dos programadores de que ao obterem
especificações detalhadas da lógica no português estruturado, acabarão “retirando
todo o prazer da programação, tornando-os meros codificadores”, mas é preciso
lembrar que existem programadores inexperientes que precisam de maior ajuda para
desenvolver seu trabalho com maior qualidade;
Orientação dos usuários e treinamento dos analistas são necessários, pois, com
a introdução da análise estruturada, foram mudadas as “regras do jogo”, e todos
devem ser bem esclarecidos quanto às novas regras e à maneira como elas melhoram o
jogo. Como a análise era feita anteriormente apenas com uma descrição dos
requisitos, agora é preciso “aprender” a ler o diagrama. Mas a linguagem usada no
DFD é tão simples que esse aprendizado não é um problema para a utilização do
método.**

**DIAGRAMA DE FLUXO DE DADOS (DFD)

O DFD é uma das ferramentas mais utilizadas na análise estruturada como forma de
compreender e analisar o fluxo de dados dentro do próprio sistema e o fluxo entre o
mundo exterior com o sistema. Quando falamos do fluxo exterior, precisamos detalhar
tanto os dados que entram no sistema quanto os que saem do sistema.**
**O DFD possui uma representação em rede que mostra as funcionalidades que o
sistema deve entregar e os dados que interligam essas funcionalidades. O objetivo
principal do diagrama de fluxo de dados é mostrar o que o sistema faz e não como
será feita a solução em desenvolvimento. Isso ocorre porque é o momento de análise,
e não de projeto, no ciclo de vida do desenvolvimento.

Outro ponto interessante a ressaltar é que o DFD mostra a lógica das

funcionalidades e não a parte física da sua implementação, exatamente porque foca
na análise, e não no projeto.**

**A criação de um DFD envolve os seguintes pontos:

-Escolha de nomes significativos para os seus componentes, de forma a facilitar

o entendimento sobre o DFD e o que ele faz;
-Numerar os processos, para facilitar a referência a eles em uma documentação
escrita;
-Criar o diagrama e ajustá-lo visando uma boa estética e comunicação adequada.
Evitar DFD muito complexo. Um diagrama é uma ferramenta gráfica,portanto, o
visual bem organizado é fundamental para a compreensão do todo;
-Caso necessário, utilizar o particionamento em níveis, ou seja, quebrar o
detalhamento em níveis de aprofundamento maiores. É mais fácil entender o todo por
meio de partes menores. Mas é importante se certificar de que os diferentes níveis
de entendimento gerados são consistentes internamente e também consistentes com os
demais níveis relacionados.**

**Processos

O primeiro componente a ser analisado é o processo, pois ele é o coração do DFD.

Ele mostra as funcionalidades ou processos que o software deve executar. Processos
também são conhecidos como bolha, função ou transformação, pois representam as
transformações de fluxos de dados de entrada em fluxos de dados de saída. Por
proporcionar uma transformação, geralmente, o processo provoca mudanças de
estrutura, conteúdo ou estado dos dados.**

**Para ficar intuitivo e mais fácil de ser compreendido, o nome do processo deve
descrever o que ele faz. Quando o nome de um processo é claro e direto, todos os
envolvidos no desenvolvimento do software conseguem compreender a que o DFD se
refere e o que o software deve fazer.**

**Fazendo uma analogia: andar, caminhar e comer são processos ou ações, assim como
“cadastrar cliente”, “registrar o pedido do cliente” ou “emitir nota fiscal para o
cliente”. Os processos ou ações são também entendidos como as funcionalidades que o
software deve entregar para o cliente. Portanto, entender como o fluxo de dados
ocorre nesses processos é fundamental para entender o que o software deve fazer.**

**Em um DFD, os processos modelados podem ser manuais, como “arquivar uma pasta do
cliente em um armário”, ou automatizados, como “arquivar os dados do cliente”.**

**Como boa prática de análise de sistemas, para representar processos, é

interessante utilizar verbos, como extrair, produzir, criar, armazenar, recuperar,
calcular, verificar, classificar, entre outros, a fim de demonstrar exatamente o
que o processo irá executar.**

**Especificando ainda mais um processo, podemos nomear a que o processo se refere

no contexto do software, por exemplo, a um cliente, a um aluno, a um produto, ou
qualquer outro objeto. Dessa forma, o nome de um processo pode ser “Armazenar dados
do cliente”, “Calcular média bimestral do aluno”, “Consultar dados do aluno” etc.
Um processo pode ter as seguintes representações gráficas:**

**Fluxos de dados

Os fluxos de dados são os componentes capazes de interligar os processos. Eles

representam caminhos pelos quais passam os dados, sendo representados por meio de
setas que indicam a origem e o destino do dado.**

**É preciso entender que, muitas vezes, um mesmo fragmento de dados pode ter
significados diferentes em pontos distintos de um DFD. É possível ter CPF-Válido e
CPF-Inválido, Aluno-Aprovado e Aluno-Reprovado, por exemplo. Perceba que o fluxo do
dado mostra também o estado em que o dado se encontra, baseado no processo
executado, mas ele não modifica o dado durante o transporte, apenas movimenta o
dado de um ponto para outro.**

**Os fluxos de dados transportam dados entre os componentes do DFD, ou seja, é

possível encontrar fluxos de dados movimentando dados: de processo ⇔ processo, de
entidade ⇔ processo e de depósito de dados ⇔ processo.**

**O DFD mostra todos os movimentos dos dados dentro e fora do software.

Os fluxos de dados podem ser classificados da seguinte forma:

Fluxo externo: entre entidade e processo. São chamados de externos, pois

envolvem não apenas processos, mas também outro componente do DFD;
Fluxo interno: entre dois processos;
Fluxo de acesso à memória: entre processo e depósito de dados;
Fluxo de erro ou rejeição: para fora de um Processo.**

**Um fluxo de dados pode ser representado por meio de setas, as quais podem estar
direcionadas para a direita e para a esquerda, ou, ainda, para cima e para baixo. A
ponta da seta indica o destino, portanto, no diagrama, deve-se observar a lógica da
origem para o destino de cada fluxo de dado.**

**Depósito de dados

Um depósito de dados representa uma coleção de pacotes de dados, mas não deve ser
confundido com banco de dados, pois possuem objetivos diferentes. Utilizar depósito
de dados em um DFD é um meio de se reter os dados que serão utilizados em outro
momento pela mesma funcionalidade ou por outras. Os depósitos de dados são simples
meios de armazenamento de dados estocados, sem maiores preocupações com suas
características físicas, por isso, não podem ser confundidos com o banco de
dados.**
**O depósito de dados representado em um DFD mostra a lógica e não a parte física
do dado em si. Um banco de dados seria exatamente a parte física, ou seja,
representa o dado fisicamente armazenado. O depósito de dados destina-se a informar
aquilo que precisamos movimentar, independentemente de ser um bando de dados em si.
É possível representar em um DFD a movimentação de dados partindo de um arquivo,
por exemplo.**

**O nome de um depósito de dados, como boa prática, deve sempre estar no plural,
representando que, no depósito, existem vários dados do mesmo contexto. Um depósito
de cliente, por exemplo, deve se chamar Clientes, pois o software vai processar
dados de vários clientes.**

**Entidades:

A entidades são categorias lógicas de “coisas” ou “pessoas”, as quais representam

uma origem ou destino de transações. Se compararmos com a orientação a objetos, as
entidades funcionam de modo similar ao dos objetos, pois representam parte do mundo
real.**

**Também podem ser chamadas de Terminadores, por serem o ponto de partida ou de

chegada de qualquer transação. As entidades são as fontes ou os destinatários das
informações que entram e saem do sistema. A entidades também podem, além de
representar “coisas” ou “pessoas”, representar um outro sistema, se este outro
sistema tiver interface com o sistema que está sendo modelado.**

**Seguindo as boas práticas de análise de sistemas, a nomenclatura utilizada nas

entidades deve estar no plural, devido ao mesmo motivo pelo qual é utilizado plural
nos depósitos de dados, ou seja, para representar um grupo de pessoas ou coisas.
Normalmente, as entidades têm, intencionalmente, seu nome escrito em maiúsculo,
para diferenciá-las de possíveis depósitos de dados com o mesmo nome.**

**NÍVEIS DE UM DFD

O DFD deve ser modelado em uma série de níveis, de modo que, a cada nível, ofereça
sucessivamente mais detalhes sobre uma parte do nível que lhe seja superior.**

**O principal objetivo de organizar o DFD em níveis é mostrar o diagrama de fluxo

de dados do nível mais macro até o nível mais detalhado. E qual é o limite de
criação de níveis em um DFD? O limite é o correto e o completo entendimento do
problema. Ou seja, enquanto for necessário detalhar algum processo para ajudar no
desenvolvimento do software, deve ser criado mais um nível de DFD. Vamos entender
cada um nos principais níveis conhecidos e definidos em um DFD.**

**DFD de contexto

Este é o DFD de nível mais alto, sendo o que dá a visão das principais funções do
sistema. Ele é macro, contendo um processo que representa o sistema como um todo,
os principais fluxos de dados e os agentes externos, ou seja, os sistemas com os
quais o sistema modelado faz interface, ou mesmo os diversos setores da empresa que
terão algum tipo de acesso ao sistema.
Ele é simples, porque não detalha nenhum dos processos do sistema, mas dá uma visão
do todo e dos principais relacionamentos.**

**O DFD do exemplo apresentado modela o sistema de vendas que é acionado pelo setor
de vendas quando um pedido é feito por um cliente. Quando o pedido é processado e
faturado, o setor de logística é acionado com a fatura, para que separe e entregue
os produtos comprados pelo cliente. O pagamento do pedido feito pelo cliente é
feito por outro sistema, o sistema financeiro, que recebe os dados de cobrança. E,
por último, o setor de pós-vendas recebe os dados do Pedido para fazer o
atendimento ao cliente e verificar a satisfação com a compra, após ele ter recebido
os produtos comprados.**

**DFD de nível zero

Após ter a visão macro do sistema, é preciso analisar os principais processos do

software e colocar uma lupa nos fluxos e nas entidades envolvidas nesses processos.
Nesse nível de DFD, é possível encontrar detalhes sobre as principais
funcionalidades do software.

O DFD imediatamente abaixo do diagrama de contexto é conhecido como DFD de nível

zero. Ele representa a visão de mais alto nível das principais funções do sistema,
bem como das principais interfaces entre essas funcionalidades.

Cada uma dessas bolhas, que representam os principais processos ou funcionalidades,

deve ser numerada para fácil identificação e referência. Explicando com outras
palavras, o DFD de nível zero contém as macrofunções do sistema.**

**DFD de níveis intermediários

Os DFDs de níveis intermediários são os diagramas que mostram a decomposição, ou

seja, o detalhamento ou explosão de cada processo de nível mais alto. Portanto,
cada nível detalha mais o nível imediatamente anterior.

A quantidade de níveis depende de fatores como complexidade e porte do sistema. Em

geral, a decomposição em níveis menores deve terminar quando for possível
especificar o processo em uma página, ou quando o detalhamento estiver suficiente
para compreender toda a análise do sistema.**

**ANALISANDO UM EXEMPLO DE DFD:

Estamos chegando ao último tema desta aula e, como foi feito em outro momento de
nossos estudos, vamos analisar o que aprendemos por meio de um estudo de caso.
Vamos analisar a construção de um DFD na prática. O objetivo é apresentar como um
DFD pode ser criado por meio da descrição de um problema de um cliente.

Atente-se aos detalhes e lembre-se de que vamos utilizar este estudo de caso em
todas as aulas da disciplina. Conforme explicado anteriormente, vamos evoluir com
esse estudo de caso por todas as etapas da análise de sistemas de um ciclo de
desenvolvimento, construindo vários modelos que ajudem a projetar a construção
completa do software.

Relembrando o nosso estudo de caso:

Fomos contratados pelo nosso cliente para modelar o processo de vendas on-line de
livros. O nosso cliente tem uma livraria virtual, que vende produtos diretamente em
um site próprio. O diferencial desta livraria é ter um estoque próprio, o que
garante uma entrega mais rápida a seus clientes, e aceitar vários tipos de
pagamento, como cartão de crédito, cartão de débito e boleto bancário. A livraria
possui um programa de fidelidade, que permite desconto de 10% aos clientes que
comprarem R$ 500,00 ou mais em 1 ano.
//Este DFD é o de mais alto nível, refletindo o sistema com uma visão macro e
geral, mostrando as principais entidades envolvidas e os dados que alimentam o
sistema também de forma macro. Dessa forma, trata-se de uma visão lógica e de alto
nível do que foi representado na modelagem de processos de negócio, estudada
anteriormente.**

///////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////

**********************************Aula 3 ENGENHARIA DE REQUISITOS E CASOS

DE USO ***********************************************************
Descrição: - Engenharia de requisitos
- Requisitos funcionais e requisitos não funcionais
- Documentando requisitos funcionais por meio de casos de uso
- Estórias de usuários
- Analisando um exemplo de descrição de caso de uso

**ENGENHARIA DE REQUISITOS

Os requisitos guiam as atividades do projeto e normalmente são expressos em

linguagem natural para que todos possam obter o entendimento de como o software
deve funcionar. Os requisitos devem ser obtidos com os usuários que conhecem o
negócio e vão utilizar o software, além de ser necessário que tais requisitos sejam
entendidos pela equipe técnica, que vai construir o software.**

**A coleta de requisitos é um processo normalmente organizado em quatro passos, que

inclui o estudo de viabilidade da construção do software, a coleta dos requisitos,
a especificação de requisitos e a validação de requisitos de software. Vamos
entender cada um desses passos:

*Estudo de viabilidade da construção do software: é o primeiro passo do

processo de levantamento de requisitos, que envolve entender a necessidade do
cliente e fazer um estudo detalhado sobre o sistema desejado a fim de verificar se
sua funcionalidade é viável para se codificar (Mall, 2014). O estudo de viabilidade
está focado em analisar se o produto de software pode ser, na prática,
materializado em termos de implementação, pensando em aspectos técnicos, de prazo e
financeiros;
*Coleta de requisitos: após a análise de viabilidade, a próxima fase é a coleta
de requisitos junto aos usuários. Os analistas de requisitos entrevistam clientes e
usuários finais para conhecer as suas ideias e necessidades sobre quais
funcionalidades o software deve executar;
*Especificação de requisitos: esta etapa ocorre após a coleta dos requisitos e
envolve a documentação e o detalhamento de cada um dos requisitos necessários para
o software;
*Validação dos requisitos: a validação é a etapa final do processo de
levantamento de requisitos e tem como objetivo garantir o entendimento sobre cada
um dos requisitos coletados e especificados. Um requisito mal entendido ou
documentado de forma errada gera um software inadequado.**
**Ciclo de vida da engenharia de requisitos
O ciclo de vida da engenharia de requisitos é composto por sete passos, conforme já
comentado anteriormente.
Os passos são evolutivos e complementares entre si, cada um possuindo uma meta a
ser atingida. São eles: concepção, levantamento, elaboração, negociação,
especificação, validação e gestão de requisitos. Perceba que alguns desses sete
passos também existiam na proposta anterior de ciclo de vida, a versão com quatro
etapas, apresentada anteriormente.**

**Concepção: o objetivo deste passo é compreender o problema a ser resolvido,

entendendo o cenário de atuação do cliente. A intenção é estabelecer um
entendimento do que o cliente espera com base na necessidade de negócio
apresentada.

Levantamento: este passo é o momento em que os analistas de requisitos começam a

entrevistar os usuários e a compreender, em detalhes, como os requisitos deverão
funcionar. Esse passo pode usar a modelagem de processo de negócio desenvolvida
anteriormente como base para identificar os requisitos do software. É uma
continuação do passo anterior, o passo da concepção, evoluindo no entendimento e
mergulhando nos detalhes dos requisitos que deverão fazer parte do software;

Elaboração: neste passo, as informações obtidas durante a concepção e levantamento

são expandidas e refinadas. O objetivo principal desse passo é desenvolver um
modelo técnico refinado das funcionalidades, características principais a serem
atendidas e restrições do software. Nesse passo, são definidos cenários de uso,
demonstrando como cada usuário vai interagir com o software;

Negociação: este passo é o momento em que os requisitos levantados e detalhados nos

passos anteriores são validados pelos usuários. É bastante comum que os usuários
peçam novos requisitos e alterações nos requisitos já existentes. É o momento no
qual a negociação de custo, prazo e escopo ocorrem, pois é preciso atender aos
usuários, mas também manter o prazo e o custo previstos para o projeto.

Especificação: uma vez finalizado o passo da negociação e definidas as

funcionalidades que serão construídas, agora é possível trabalhar nos modelos de
implementação dos requisitos, ou seja, o projeto de construção de software já pode
ser desenvolvido, baseado nos requisitos priorizados e detalhados. Neste passo, são
definidas, de forma definitiva, as tecnologias que serão usadas e a arquitetura que
será empregada na construção do software.

Validação: este passo examina a especificação que foi feita com objetivo de
garantir que todos os requisitos necessários para o software foram identificados e
especificados, que estão claros, coerentes entre si e descritos de modo a evitar
ambiguidade. É um momento de validação em que a revisão técnica e negocial formal
devem ser aplicadas, garantindo que os requisitos estão corretos segundo os
processos da empresa e, tecnicamente, garantindo que foram especificados e
projetados de uma forma viável para implementação.

Gestão de requisitos: a gestão de requisitos é necessária, pois os requisitos são

voláteis e facilmente alteráveis por conta de necessidades do negócio, exigências
do mercado ou outros fatores. Dessa forma, a gestão de requisitos é composta por um
conjunto de atividades que ajudam na identificação, controle, rastreamento e
modificação dos requisitos ao longo do tempo. A gestão de requisitos também se
ocupa com a rastreabilidade entre os requisitos de um software.**

**O analista de requisitos:

Na TI, os profissionais se especializam em diferentes áreas, podendo atuar em
vários momentos do ciclo de vida do desenvolvimento de software. Existem analistas,
programadores, testadores, arquitetos de software e muitos outros perfis que
contribuem para a construção de um bom software.**

**O documento de especificação de requisitos:

Por serem complexos e críticos para o sucesso de um projeto de software, os
requisitos precisam ser documentados ao longo do ciclo de vida da engenharia de
requisitos.
Uma especificação de requisitos de software (SRS – Software Requirements
Specification) é uma descrição de um sistema de software a ser desenvolvido. Ele
estabelece requisitos funcionais e não funcionais e pode incluir um conjunto de
casos de uso que descrevem as interações do usuário que o software deve fornecer.**

**REQUISITOS FUNCIONAIS E REQUISITOS NÃO FUNCIONAIS:

-Os requisitos que estão relacionados aos aspectos funcionais do software se
enquadram nesta categoria chamada de requisitos funcionais. Eles definem funções e
funcionalidades que o sistema de software deve executar.
A correta compreensão dos requisitos funcionais é muito importante durante a
modelagem de um produto de software, pois é com base nos requisitos funcionais que
todo o projeto é desenvolvido. Se um requisito funcional não estiver correto, todo
o funcionamento do software estará comprometido.
Um requisito funcional define uma função particular de um sistema ou algum dos seus
componentes; eles representam “o que o software faz”, em termos de tarefas e
serviços (funcionalidades).
A seguir, apresentamos alguns exemplos de requisitos funcionais:

[RF001] O Sistema deve cadastrar médicos profissionais (entrada);

[RF002] O Sistema deve emitir um relatório de clientes (saída);
[RF003] O Sistema deve passar um cliente da situação "em consulta" para
"consultado" quando o cliente terminar de ser atendido (mudança de estado);
[RF004] O cliente pode consultar seus dados no sistema.
//////////////////////////////////////////////////////////////////////////////
-Os requisitos não funcionais referem-se aos critérios que qualificam os requisitos
funcionais. Esses critérios podem ser de qualidade para o software, ou seja, os
requisitos de performance, usabilidade, confiabilidade, robustez etc.

Ou então, os critérios podem ser quanto à qualidade para o processo de software, ou

seja, requisitos de entrega, implementação, entre outros.

Os requisitos funcionais são suportados por requisitos não funcionais, que impõem
restrições ao projeto ou implementação (como requisitos de desempenho, segurança ou
confiabilidade).
A seguir, apresentamos alguns exemplos de requisitos não funcionais:

[RNF001] O sistema deve imprimir o relatório em até cinco segundos;

[RNF002] Todos os relatórios devem seguir o padrão de relatórios especificado
pelo setor XYZ;
[RNF003] O sistema deve ser implementado em Java.**

**DOCUMENTANDO REQUISITOS FUNCIONAIS POR MEIO DE CASOS DE USO:

Os requisitos precisam ser entendidos e documentados, para que todos os envolvidos
no software conheçam e possam opinar sobre o processo refletido no conjunto de
requisitos, afinal de contas, os requisitos devem ser o detalhamento fiel do
processo de negócio.
Quando são utilizadas metodologias tradicionais de desenvolvimento de software, os
requisitos são descritos e detalhados em documentos chamados de casos de uso.

Dessa forma, um caso de uso procura documentar as ações necessárias, comportamentos

e sequências para que o resultado esperado pelo usuário ocorra. Então, é possível
dizer que o documento de casos de uso modela os requisitos funcionais do sistema.**

**Casos de uso:
É importante entender que documentar casos de uso significa descrever como o
software deve se comportar, pois o caso de uso descreve os requisitos funcionais de
um software. Logo, em última instância, documentar um caso de uso significa
descrever fluxos de eventos, listando todos os passos seguidos para se chegar a um
resultado.
Os fluxos de eventos em um caso de uso mostram o que deve ser executado em cada
funcionalidade do software, sendo que existem três tipos de fluxos, conforme

Fluxo Principal (FP): também é conhecido como caminho feliz. É o fluxo no

qual todas as informações estão corretas e o caso de uso faz o que deveria ser
feito, conforme o requisito. É o caminho que documenta o passo a passo do que o
caso de uso tem que fazer, de acordo com seu objetivo principal. Por exemplo, se o
objetivo do caso de uso é “Cadastrar Cliente”, os passos devem ser seguidos até que
todos os dados do cliente estejam salvos no banco de dados

Fluxo alternativo (FA): é o tratamento de tudo o que não é o caminho normal

ou esperado, ou seja, qualquer informação errada, qualquer ação que não foi
executada conforme o previsto. O fluxo alternativo descreve qual o passo a passo
para o tratamento de problemas ou situações fora do normal. Seguindo o mesmo caso
de uso que usamos no caminho principal – “Cadastrar Cliente” –, podemos acrescentar
alguns passos para verificar os dados informados

Fluxo de exceção (FE): são funções que não fazem parte do fluxo principal,
mas estão disponíveis para o usuário executar, ou seja, sua execução não é
obrigatória, por não ser o objetivo principal do caso de uso, mas fazem do processo
e podem ser acionadas pelo usuário. Alguns fluxos de exceção muito comuns:
Alterar senha: opção que permite ao cliente alterar sua senha quando ele
está se logando no site, por exemplo;
Help on-line: opção que permite ao cliente obter mais informações sobre um
produto, por exemplo;
Veja seu histórico de compras: permite ao cliente ver o seu histórico de
compras, quando ele loga no site para realizar uma nova compra, por exemplo.**

**Regras de escrita de um caso de uso:

O caso de uso é um documento criado com o objetivo de descrever como os requisitos
ou funcionalidades do software devem se comportar. Dessa forma, ele deve ser
compreendido tanto pelo pessoal da área de negócio quanto pelo pessoal da área
técnica.
É importante entender que os requisitos:
*Nem sempre são óbvios, pois eles podem ter um funcionamento diferente do
normal encontrado em outros softwares. Por exemplo, vários sites de vendas podem
ter como requisito “Calcular Comissão de Vendas”, porém, a fórmula de cálculo pode
ser diferente de empresa para empresa.

Podem vir de muitas fontes, pois, algumas vezes, um requisito é executado por
mais de um usuário. Para garantir o correto entendimento do funcionamento do
requisito, é fundamental ouvir todos os usuários envolvidos. Nesse caso, o papel do
analista de requisitos é entender o funcionamento do requisito

Não são claramente expressáveis, pois, algumas vezes, os usuários não

conseguem expressar o funcionamento do requisito por meio de palavras. Quando
isso ocorre, o melhor é ver o funcionamento do requisito no processo
executado pelo usuário, mesmo que seja uma execução manual.

Podem ser constantemente modificados, pois as necessidades do cliente podem

mudar ou evoluir. Logo, eles precisam ser mantidos atualizados constantemente,
para garantir um bom gerenciamento dos requisitos e também para garantir que o
código construído esteja de acordo com a nova necessidade do cliente.**

**Algumas regras são bastante conhecidas pelos analistas de requisitos:

*Todo caso de uso deve indicar uma ação, por ser uma funcionalidade. Dessa
forma, é uma boa prática utilizar um verbo para indicar a funcionalidade e
acrescentar o objeto a que se refere. Por exemplo, “Validar CPF”, “Cadastrar
Cliente” e “Calcular Comissão de Vendas”. Dessa forma, o nome do caso de uso fica
autoexplicativo;
*Outra boa prática é utilizar uma numeração sequencial para se referenciar ao caso
de uso, sem precisar ficar repetindo o nome completo do caso de uso, que pode ser
bastante grande em algumas situações. A identificação de caso de uso seria então –
UC, acrescentado por um sequencial. Por exemplo, UC001 – Validar CPF, UC002 –
Cadastrar Cliente, UC003 – Calcular Comissão de Vendas.
*Dentro de um caso de uso, para descrever o passo a passo, podemos utilizar
também uma identificação e um sequencial numérico para organizar os passos que
devem ser seguidos para executar a funcionalidade. Por exemplo, podemos utilizar
FP001 para identificar o passo 1 do Fluxo Principal.
*No caso de uso, para facilitar o entendimento do mesmo, é importante inserir as
seguintes informações: Nome do caso de uso, Descrição breve do caso de uso, Pré-
condições, Fluxo Principal, Fluxos Alternativos, Fluxos de Exceção, Regras de
Negócios, Mensagens.**

**ESTÓRIAS DE USUÁRIO:
Nas metodologias tradicionais, o foco da construção de um software está no
entendimento das funcionalidades. Nas metodologias ágeis, o foco da construção de
um software está na experiência do usuário, no comportamento do software e em como
e para que os usuários vão utilizá-lo.

Portanto, como o foco das metodologias ágeis está nos indivíduos, a escrita de uma
estória de usuário utiliza a linguagem do negócio, pois o software é feito para um
usuário. Mas a estória de usuário também é uma explicação informal escrita por meio
da perspectiva do usuário final.
E o programador, que vai construir o software, terá como base não apenas a estória
de usuário, mas um Product Owner (PO) o ajudando a entender os requisitos e tirando
suas dúvidas sempre que surgirem, ou seja, a estória de usuário é uma parte da
comunicação entre a área de negócio e a equipe técnica, comunicação essa evoluída e
complementada com conversas e reuniões de planejamento realizadas em cada ciclo de
desenvolvimento de parte do software.

O PO para a metodologia ágil tem um papel muito parecido com o papel desempenhado
pelo analista de requisitos na metodologia tradicional, pois ele é o responsável
por conhecer os requisitos do negócio e documentar esses requisitos de forma que a
equipe técnica consiga construir os requisitos utilizando uma linguagem de
programação.

As metodologias ágeis descrevem seus requisitos em formato de épicos e de estórias

de usuários. Vamos entender o que são esses conceitos.**

**Épicos e estórias de usuário:

Um épico é uma grande estória ou um conjunto de estórias. Quando uma funcionalidade

é muito extensa, ela necessita ser quebrada em partes menores (estórias) para que
seja mais bem compreendida. Isso ajuda a manter princípios ágeis, como entregar um
software funcionando com frequência e minimizar as constantes mudanças, uma vez que
se constrói o software focando em pequenas partes por vez.

Uma estória de usuário pode ser caracterizada como uma curta e simples descrição de
uma funcionalidade ou parte de uma funcionalidade. Ela pode ser contada por meio da
perspectiva da pessoa que deseja a funcionalidade, usualmente de um usuário ou
cliente do sistema. Para criar uma estória de usuário, pode-se seguir o seguinte
formato: Como/Sendo <quem>, eu quero/gostaria/devo/posso <o que>, para que/de/para
<porque/resultado>.**

**
Negociável: ela é negociável porque toda estória de usuário é apenas um desejo
do usuário, logo, ela pode ser considerada como sendo apenas um ponto de partida.
Portanto, deve ser totalmente negociável em termos de características e restrições;
Valiosa: o foco está em atender ao cliente, logo, deve representar valor de
negócio, sempre. Sem valor de negócio, não faz sentindo existir e não deve ser
priorizada e muito menos desenvolvida;
Estimável: o time deve ser capaz de estimá-la, para isso, ela deve ser bem
entendida por todos;
Pequena (Small): deve ser pequena, reduzindo as incertezas e as dificuldades no
momento de estimar;
Testável: todas as estórias de usuário devem ser testáveis, ou seja, deve ser
possível validar se elas atingem os critérios de aceitação. Para isso, os critérios
precisam estar claramente definidos, para que possam ser verificados.
**

****