Processos – Chegando aos

Requisitos de Sistema
Prof. André Campos
Mestre em Informática pela UFRJ
andrelncampos@gmail.com
2
Os sistemas de
informação, como
ferramenta do
negócio, podem
estar posicionados
em diferentes
quadrantes da
estratégia
organizacional.

3
 ALTO
IMPACTO FUTURO

FÁBRICA ESTRATÉGICO
BAIXO

SUPORTE TRANSIÇÃO

BAIXO ALTO
4 IMPACTO FUTURO
 O quadrante “suporte” abrigaria as
ALTO

organizações cuja Tecnologia da

IMPACTO FUTURO

FÁBRICA ESTRATÉGICO

Informação tem baixo impacto

estratégico e alto impacto operacional.
BAIXO

SUPORTE TRANSIÇÃO

Organizações típicas deste quadrante

BAIXO ALTO
IMPACTO FUTURO
seriam aquelas que utilizam a
Tecnologia da Informação para suportar
suas atividades de apoio, tais como
gestão dos recursos humanos, gestão
de materiais, e gestão de finanças. A
maioria das indústrias seriam exemplos
adequados.

5
 O quadrante “fábrica” abrigaria as
organizações cuja TI tem grande
ALTO
IMPACTO FUTURO

FÁBRICA ESTRATÉGICO

impacto estratégico no presente, mas

que possui relativamente baixo impacto
BAIXO

SUPORTE TRANSIÇÃO em aplicações futuras.

BAIXO ALTO Exemplos seriam empresas que

IMPACTO FUTURO
dependem fortemente de TI ou que
poderiam buscar novos objetivos
estratégicos a partir da TI. Seriam
exemplos aceitáveis as companhias
aéreas e supermercados, organizações
que já reformularam seus negócios com
base em tecnologia e sistemas de
informação.
6
 O quadrante “transição” abrigaria as
ALTO

organizações cuja TI está, aos

IMPACTO FUTURO

FÁBRICA ESTRATÉGICO

poucos, migrando de uma situação

de baixo impacto estratégico para
BAIXO

SUPORTE TRANSIÇÃO
alto impacto estratégico.
BAIXO ALTO
IMPACTO FUTURO Empresas deste tipo estão migrando
para uma estratégia de negócios
fortemente evolutiva em função dos
progressos da TI. Seriam exemplos
as editora e os provedores de
comércio eletrônico, também
conhecido como e-commerce B2C.
7
 O quadrante “estratégico” abrigaria as
organizações cuja TI representa alto
ALTO
IMPACTO FUTURO

FÁBRICA ESTRATÉGICO

impacto estratégico, tanto nas

aplicações atualmente implementadas,
BAIXO

SUPORTE TRANSIÇÃO quanto nas aplicações futuras.

BAIXO ALTO As empresas deste quadrante são

IMPACTO FUTURO
aquelas cuja TI determina as estratégias
de negócios tanto no presente quanto no
futuro, e ao passo que acontecem
avanços tecnológicos.

Seriam exemplos deste tipo de

organização as seguradoras,
administradoras de cartão de crédito e
8 os bancos.
Não é exatamente uma
novidade o fato de que
muitos projetos de sistemas
de informação
simplesmente fracassam.

Em média, menos de 20%

dos projetos deste tipo são
considerados como de
sucesso.

9
 Projetos de sistema

60,00%
52,70%

50,00%

40,00%
31,10%
30,00%

20,00% 16,20%

10,00%

0,00%
Cancelados Acima do custo Concluídos dentro do custo
10
Entregar os
requisitos que
atendam às
necessidades dos
processos de
negócio, não é tarefa
das mais simples.

11
 Requisitos de sistema originais

90,00%

80,00%
70,00%

60,00%
50,00%
40,00%
30,00%

20,00%
10,00%

0,00%
Pequenas e médias Grandes empresas Médias
>74% das funcionalidades 78,40% 42,00% 60,20%
< 75% das funcionalidades 21,60% 58,00% 39,80%

12
 Requisitos especificados e entregues

45,00%

40,00%

35,00%

30,00%

25,00%

20,00%

15,00%

10,00%

5,00%

0,00%
0 a 24% 25 a 49% 50 a 74% 75 a 99% 100%
Projetos 4,60% 27,20% 21,80% 39,10% 7,30%

13
Mas, por que tanta
dificuldade em
construir sistemas
que atendam, de
fato, às
necessidades dos
processos de
negócio?

O que torna os
projetos de sistema
em projetos de alto
risco?

14
 Motivos de problemas nos projetos

25,00%

20,00%

15,00%

10,00%

5,00%

0,00%
Informações Requisitos e Alterações nos Objetivos não
Apoio executivo Incompetência Recursos Expectativas Prazos Novas
deficientes do especificação requisitos e definidos Outros
insuficiente tecnológica insuficientes irrealísticas irrealísticos tecnologias
usuário incompletos especificações claramente

% de respostas15 12,80% 12,30% 11,80% 7,50% 7,00% 6,40% 5,90% 5,30% 4,30% 3,70% 23,00%
 Item Motivos de problemas com requisitos % de respostas

1 Informações deficientes do usuário 12,80%

2 Requisitos e especificação incompletos 12,30%

3 Alterações nos requisitos e especificações 11,80%

4 Apoio executivo insuficiente 7,50%

5 Incompetência tecnológica 7,00%

6 Recursos insuficientes 6,40%

7 Expectativas irrealísticas 5,90%

8 Objetivos não definidos claramente 5,30%

9 Prazos irrealísticos 4,30%

10 Novas tecnologias 3,70%

11 Outros 23,00%

16
Mais de 50% dos
motivos podem ser
relacionados a
problemas com os
requisitos.

17
 Informações
deficientes do
usuário

Requisitos e
Prazos
especificação
irrealísticos
incompletos

Alterações nos Objetivos não

requisitos e definidos
especificações claramente
Expectativas
irrealísticas

18
 Fatores de sucesso

25

20

15

10

0
Objetivos de Experiência Requisitos
Envolvimento Apoio Metas Equipe Plajenamento
negócio em gestão de básicos Propriedade Outros
do usuário executivo menores competente adequado
claros projetos definidos

Pontos 20 15 15 15 10 5 5 5 5 5

19
20
 Artefato

Sujeito Objeto Resultado

Divisão do
Regras Comunidade
21 trabalho
 Nível 1 Nível 2 Nível 3

Motivo Meta / Propósito Condição

ATIVIDADE AÇÃO OPERAÇÃO

Indivíduo / Indivíduo /
Comunidade
Grupo Máquina

22
 Existem diversas ARIS;
ferramentas IDEF;
conceituais que são BPM;
utilizadas para a UML;
modelagem de Petri Nets;
processos. CIM/CIMOSA;
I*;
ORDIT;
F3 de Bubenko;
EKD.

23
24
 Dificuldades
Ação Requisitos
específicas

Identificar Propor Documentar

Selecionar
dificuldades soluções solução em forma Validar requisitos
dificuldades
do usuário funcionais de requisito

Dificuldades em
Soluções Requisitos validados
geral

As “dificuldades” são problemas que devem ser

resolvidos ou oportunidades que podem ser
exploradas.

25
 O processo será o mesmo utilizado no último encontro de métodos e ferramentas, um processo
específico do ONS. Deverá ser modelado em ARIS Express, e para cada atividade deverá haver
uma descrição que informe o que faz a atividade, e qual seriam suas dificuldades.

26
27
 As necessidades
(problemas ou
oportunidades) estão
relacionadas ao
processo de negócio,
e não ao sistema de
informação.

O sistema deve
resolver problemas
do negócio, e não do
próprio sistema.

28
 Isto significa que as
descrições de
necessidades não
devem fazer
referências
tecnológicas claras,
embora possam
haver referências.

29
 Por exemplo, neste
trecho de modelagem
é possível perceber
que o atendente tem
a oportunidade de
recomendar um filme
para o cliente.

Talvez haja aqui uma

oportunidade a ser
explorada.

30
“O atendente recomenda títulos ao cliente, procurando
previamente identificar seu perfil no que se refere filmes
anteriormente alugados. O objetivo primário é atender a
expectativa do cliente, e se possível, fazer circular os
filmes menos alugados, deixando aqueles de maior apelo
popular para os clientes que não solicitam apoio para
seleção”

31
 Esta descrição da
“O atendente recomenda títulos ao
atividade está focada cliente, procurando previamente
no negócio e em identificar seu perfil no que se
suas necessidades, e refere filmes anteriormente
alugados. O objetivo primário é
não distorcidas por atender a expectativa do cliente, e
alguma influência se possível, fazer circular os
tecnológica. filmes menos alugados, deixando
aqueles de maior apelo popular para
os clientes que não solicitam apoio
para seleção”

32
 Fazer menção do
“O atendente recomenda títulos ao
que se espera em cliente, utilizando a tela de lista de
termos de tecnologia títulos. Nesta tela haverá
pode desviar a possibilidade de busca por nome do
filme, pelo ator(a) principal, pelo tipo
atenção de quem de filme (drama, comédia, terror,
modela o processo, e etc), e ainda informará
produzir resultados automaticamente se o filme está
alugado no momento e quando
mais distantes das retornará, possibilitando inclusive já
reais necessidades fazer a reserva antes mesmo do
do processo de retorno”

negócio. Veja um
exemplo ruim, ao
lado.
33
Considerando que o objetivo da locadora é obter lucro,
qual descrição contribui mais com o objetivo do negócio?
Então, qual descrição está mais próxima do negócio?

“O atendente recomenda títulos “O atendente recomenda títulos

ao cliente, procurando
previamente identificar seu perfil
no que se refere filmes
anteriormente alugados. O
objetivo primário é atender a
expectativa do cliente, e se
possível, fazer circular os filmes
menos alugados, deixando
aqueles de maior apelo popular
para os clientes que não solicitam
apoio para seleção”
ao cliente, utilizando a tela de lista
de títulos. Nesta tela haverá
possibilidade de busca por nome
do filme, pelo ator(a) principal,
pelo tipo de filme (drama,
comédia, terror, etc), e ainda
informará automaticamente se o
filme está alugado no momento e
quando retornará, possibilitando
inclusive já fazer a reserva antes
mesmo do retorno”

34
 Muitas das
necessidades
identificadas não
estarão
relacionadas com os
requisitos do
sistema de
informação.

Veja o caso desta

atividade em
particular.

35
“Verificar com o cliente se ele
pretende pagar o filme no
momento da locação ou apenas
no retorno. Deve-se estimular,
sem promover qualquer tipo de
constrangimento, o pagamento
imediato, no ato da locação”

A descrição da
atividade é como
apresentada acima.

36
 Deve gerar uma
funcionalidade de
sistema.
“Verificar com o cliente se ele
pretende pagar o filme no
momento da locação ou
apenas no retorno.

Deve-se estimular, sem

promover qualquer tipo de
constrangimento, o
pagamento imediato, no ato
da locação” Não deve gerar uma
funcionalidade de
sistema.

37
 Dificuldades
Ação Requisitos
específicas

Identificar Propor Documentar

Selecionar
dificuldades soluções solução em forma Validar requisitos
dificuldades
do usuário funcionais de requisito

Dificuldades em
Soluções Requisitos validados
geral

Por isso, há uma fase para seleção das necessidades

que poderão gerar funcionalidades de sistema, ou, neste
contexto, soluções.
38
Por conta da diferença
de contexto entre
negócio e tecnologia,
que ainda acontece
algumas vezes, pode
ser que a modelagem
de processos seja feita
por uma parte da
equipe, e a
identificação de
requisitos por outra.

39
É perfeitamente
possível que
profissionais de TI
façam as duas partes
do trabalho.

No entanto, é
necessário ter boa
visão de negócio e
saber separar os
papéis.

40
 As descrições das atividades deve ser revista e devem ser identificadas as necessidades que
serão consideradas para a elaboração de requisitos.

41
42
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.

43
 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.

44
 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.
45
 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.

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

47
 É 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.

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

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

50
 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.
51
 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.
52
 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.
53
 É interessante,
escrever a
funcionalidade em
um formato mais
estruturado, a fim
de contribuir com a
clareza.

54
55
 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
56 atividade, a mesma será desativada.
 No ARIS Express há um
objeto específico para a
identificação e descrição
do requisito, ou
funcionalidade do sistema.
Chama-se “IT System”.

57
 A atividade, realizada em grupo, envolve a adição das funcionalidades e a troca de modelos com
outros grupos para a adição de eventuais novas contribuições. O ideal é que a turma esteja
dividida em um número par de grupos, ou seja, 4 ou 6 grupos.

58
59
 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.

60
 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.

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

62
 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”.

63
 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.

64
 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.

65
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).

66
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.
67
Futuros encontros
abordarão a
questão “SOA”
mas de perto.

68
J. Souza, L. Azevedo, F. Baião, F. Santoro, C. Cappelli, A. Magdaleno, V. Nunes;
Modelagem de serviços web: uma proposta para modelagem de serviços
candidatos e físicos; Universidade Federal do Estado do Rio de Janeiro, 2009.

J. Souza, L. Azevedo, F. Baião, F. Santoro; Arquitetura Orientada a Serviço –

Metodologia de Criação de Serviços Orquestrados; Universidade Federal do
Estado do Rio de Janeiro, 2009.

C. Furtado, V. Pereira, L. Azevedo, F. Baião,F. Santoro; Arquitetura Orientada

a Serviço - Conceituação; Universidade Federal do Estado do Rio de Janeiro,
2009.

T. Specht, J. Drawehn, M. Tharänert, s. Kühne; Modeling Cooperative

Business Processes and Transformation to a Service Oriented
Architecture; Proceedings of IEEE Conference on E-Comerce Technology,
2005.

69
Processos – Chegando aos
Requisitos de Sistema
Prof. André Campos
Mestre em Informática pela UFRJ
andrelncampos@gmail.com