Modelagem de Processos

&
Business Process Modeling Notation
(BPMN)

DESCREVENDO REQUISITOS
2
Os requisitos de
sistema podem ser
descritos em diversos
níveis de profundidade.

Podem ir de uma
simples descrição até
um conjunto complexo
de diagramas.

3
Mas, no entanto, neste
nível, muito próximo ao
negócio, queremos
uma lista suscinta,
clara, e precisa do que
pretendemos ver
resolvido com a
implantação de um
sistema de informação.

4
A partir desta lista é
possível construir o
conjunto de informações
para suportar a decisão
entre:
1) Desenvolver
internamente;
2) Encomendar o
desenvolvimento;
3) Comprar um produto
de mercado.
5
Pensando nisso, e
considerando mais
uma vez a descrição
da atividade
“Recomendar filme”,
já é possível pensar
em uma
funcionalidade que
de fato apóie esta
atividade.

6
Uma funcionalidade que suporte a atividade
humana de recomendar filme seria, por exemplo,
a de “Consulta perfil de cliente”.

7
É importante ressaltar que esta funcionalidade só
aparece depois de uma análise da descrição da
atividade humana.
Quer dizer, ela literalmente “nasce” desta atividade.

8
Isto aumenta as
chances de que as
funcionalidades do
sistema suportem,
de fato, as
atividades dos
processos de
negócio.

9
Contribui também
para reduzir o
volume de
mudanças nestas
funcionalidades, ou
requisitos.

10
Ou pelo menos
aumentar a relação
entre a mudança nos
requisitos e a
mudança nos
processos de
negócio.
Assim, o modelo dos
processos passam a
ser a ferramenta de
negociação de
requisitos.
11
 A partir do código, do CPF ou do nome
completo do cliente, gera lista para consulta
em tela das locações realizadas pelo cliente
nos últimos 12 meses, gerando pontuação
para os seguintes itens de cada filme
alugado: estilo (comédia, drama, terror, etc),
protagonista, e produtora. Para os filmes
locados mais de uma vez (repetidos) os
pesos das pontuações serão dobrados.
A partir destas pontuações será gerada uma
nova lista com todos os filmes disponíveis
para locação, ordenados pela pontuação
que os mesmos obtivem com base em um
modelo de pontuação gerado a partir da
lista anteirior, por ordem da maior
pontuação somada para a menor pontuação
somada.
12
A descrição busca ser completa
e proporcionar uma
compreensão da
funcionalidade que permita
estimar o grau de esforço para
seu desenvolvimento. É
possível ainda, identificar a
existência desta funcionalidade
em produtos existentes, e
inclusive, determinar o grau de
aderência entre a
funcionalidade esperada e a
funcionalidade existente.
13
É interessante,
escrever a
funcionalidade em
um formato mais
estruturado, a fim
de contribuir com a
clareza.

14
15
 Ação Requisito de sistema

Registrar as atividades de cada UO TQS - Cadastrar atividades

 Cadastrar as atividades de cada UO.
 Mesmo que para uma dada atividade não
exista um documento formalizado, como POP
ou IT, a mesma deve ser cadastrada.
 Deverá ser informado se a atividade exige ou
não treinamento.
 Durante revisão das atividades (na fase de
avaliação do plano de treinamento), se for
observado a existência de uma nova
atividade, então será cadastrada. Se for
verificada a descontinuidade de uma
atividade, a mesma será desativada. 16
17
Cada vez mais as
organizações operam em
ambientes
tecnologicamente
heterogêneos.
Hardware, software, e
soluções se diversificam
para atender a
complexidade do negócio.

18
Nem mesmo os
sistemas de base
para as operações
das organizações
são unificados.
Não se pensa em
uma única solução
para todos os
problemas, mas em
se obter o melhor
de cada solução.

19
Há organizações, inclusive, que optaram pela criação de
áreas de TI que competem dentro da própria estrutura.

20
E casos onde estas áreas
de TI competem com
empresas externas ao
grupo.
As áreas de TI internas são
tratadas como provedores
de solução, ou prestadores
de serviço, que precisam
apresentar baixo custo e
alta qualidade para superar
os “concorrentes”.

21
Com o tempo, isto pode
gerar uma profusão de
soluções de TI, e
também uma confusão
de igual tamanho.

Administrar este
complexo exige a
adoção de técnicas
específicas.

22
A estruturação
das aplicações
em partes
menores, ou
serviços,
permite uma
gestão melhor,
além do maior
aproveitamento
das soluções.

23
 Pensando dentro deste modelo, as
funcionalidades podem ser estruturadas em
forma de serviços. Estes serviços poderão
fazer parte de uma estrutura muito maior de
organização, tal como o SOA (Service-
Oriented Architecture).

24
Neste caso, as
descrições das IT
Systems devem
definir claramente as
interfaces, além de
manter a
independência entre
elas.
Isto contribuirá para a
construção destas
funcionalidades
através de web
services. 25
* SOA foi abordado aqui de maneira muito superficial,
objetivando apenas proporcionar uma visão geral a
respeito do tema.

26
 Continue atualizado
www.sistemamoderno.com.br

Que tal saber mais?

Modelagem de Processos Com Bpmn
Autor: André L. N. Campos
Editora: Brasport