O documento apresenta a modelagem de domínio para uma linha de produtos de software para gestão de crises em diferentes modalidades de transporte. Apresenta as premissas estabelecidas para a modelagem, incluindo a formação de uma equipe multidisciplinar e a realização da análise de contexto. Também descreve os modelos de domínio produzidos, identificando requisitos comuns e variantes para a linha de produtos, bem como os stakeholders e usuários comuns.

1. Identificando requisitos comuns
e variantes em linhas de produtos
de software
Engenharia de Requisitos de Softwares - Prof. Dr. Paulo Sérgio Muniz Silva – 2016
André Rocha Agostinho

2. Objetivos da apresentação
Análise de domínio e reuso de requisitos de software
Até o momento, a finalidade do sistema de gestão de crise era a de gerenciar o
atendimento de acidentes de veículos em estradas. Agora, seu escopo deve ser
ampliado para tratar diversas situações de crise, como as decorrentes de
desastres naturais, de várias modalidades de transporte, etc., constituindo uma
linha de produtos de software.
• Apresentar uma versão inicial de parte significativa do modelo de domínio,
numa linguagem apropriada, que identifique e especifique requisitos
comuns e variantes da linha de produtos. Para tanto:
– Empregar o método de modelagem proposto por (Kim, J. et al., 2006).
Explicitar as premissas assumidas.
– Apresentar uma avaliação a respeito da viabilidade de aplicação prática
deste método de modelagem.
2

3. Objetivos da apresentação
Rastreabilidade dos requisitos de software
Considerando a solução proposta na primeira parte:
• Definir a Estratégia de Rastreabilidade dos requisitos de software para a linha
de produtos definida.
• Considerando a estratégia definida:
– Elaborar alguns fragmentos de matrizes de rastreabilidade considerando
os requisitos de domínio identificados como requisitos comuns e
variantes.
– Definir os principais atributos dos requisitos de software a serem
utilizados na gerência dos requisitos. Justificar.
3

4. Organização da apresentação
1. Linha de produtos de software
– Definição
– Motivação
– Reuso do software
2. Análise de domínio utilizando a abordagem Feature Oriented Domain Analysis
– Conceitos
– Processo de análise de domínio
– Análise de produtos de domínio
3. Modelagem de domínio
– Premissas estabelecidas
– Modelos de domínio
– Identificação de requisitos comuns e variantes
– Especificação de requisitos comuns e variantes
4. Rastreabilidade dos requisitos do software
– Estratégia de rastreabilidade
– Matrizes de rastreabilidade
– Atributos dos requisitos de software a serem gerenciados
4

5. • Definição
• Motivação
• Reuso do software
Linha de produtos de software 5

6. Uma Linha de Produtos de Software é um conjunto de sistemas intensivos em
software, compartilhando um conjunto controlado de características comuns que
satisfazem a uma necessidade ou missão específica de um segmento particular do
mercado, desenvolvido a partir de um conjunto comum de ativos fundamentais
(core assets) segundo uma prescrição.
Linha de produtos de software
Definição
(Pohl, K. el al., 2005)
6

7. (Pohl, K. el al., 2005)
Break-Even Point
• (Weiss and Lai 1999) entre 3 e 4
• (Pohl, K. el al., 2005) 3
Principal:
Redução do custo no desenvolvimento
Outras motivações:
Melhorias na qualidade, redução no
time to market, menor esforço de
manutenção e etc.
Considerações:
A ponto preciso depende de várias
características da organização e do
mercado previsto, tais como base de
clientes, expertise e tipos de
produtos. A estratégia inicial pra
criar o primeiro produto também vai
influenciar neste número.
Linha de produtos de software
Motivação
7

8. As partes que serão reutilizadas podem ser partes existentes ou desenvolvidas para
reuso futuro.
Linha de produtos de software
Reuso do software
Podem incluir, entre outros:
• Conhecimento do domínio
• Modelo de domínio
• Técnicas de elicitação, análise e modelo de requisitos
• Arquitetura e componentes de software
• Planos de teste e casos de teste
• Processos, métodos e ferramentas
(Pohl, K. el al., 2005)
8

9. • Conceitos
• Processo de análise de domínio
• Análise de produtos de domínio
Análise de domínio – abordagem FODA 9

10. • Domínio (ou domínio da aplicação):
Um conjunto de aplicações atuais ou futuras que compartilham um conjunto
comum de capacidades e dados.
• Análise de domínio:
O processo de identificar, coletar, organizar e representar as informações relevantes
do domínio, baseado no estudo dos sistemas existentes e de suas histórias de
desenvolvimento.
• Modelo do domínio:
Definição das funções, dados e relações num domínio.
• Característica (feature)
Atributos do sistema que afetam os usuários finais e stakeholders: eles devem
entender as características para utilizarem o sistema.
(Kang et al., 1990)
Análise de domínio – abordagem FODA
Conceitos
10

11. • Reuso de software:
O processo para implementer novos sistemas de software com base na informação
de um software existente.
• Reuso de componentes:
Um componente de software (incluindo requisitos, arquitetura, código, testes e etc)
concebido e implementado para uma finalidade específica de reutilização.
(Kang et al., 1990)
Análise de domínio – abordagem FODA
Conceitos
11

12. Análise de domínio reúne e representa as informações em sistemas de software que
compartilham um conjunto comum de recursos e dados.
Métodos [GILR89A, MCNI86A, PRIE87A] sugerem 3 fases no processo de análise de
domínio.
1. Análise de contexto:
Define a extensão (ou limites) de um domínio para análise.
2. Modelagem de domínio:
Deescreve os problemas dentro do domínio que são endereçados pelo software.
3. Modelagem de arquitetura:
Cria arquitectura (s) de software que implementa uma solução para os
problemas no domínio.
Análise de domínio – abordagem FODA
Processo de análise de domínio - Fases
(Kang et al., 1990)
12

13. Fontes Produtor Consumidores
Usuário final
Usuário final
Especialista
De domínio
Analista
de domínio
Analista
de Requisitos
Projetista de
Software
(Kang et al., 1990)
Análise de domínio – abordagem FODA
Processo de análise de domínio - Participantes
13

14. 1) Análise de contexto 2) Modelagem de domínio 3) Modelagem de arquitetura
Info.
Produt
os
Modelo
de
domínio
Modelo
de
domínio
Modelo
de
Arquit.
Escopo
E
Limites
Analista de domínio, usuários e
especialista do domínio
• Limites e escopo do
domínio.
• Reunir informações para
análise.
Analista de domínio, usuários,
especialista do domínio e analista de
requisitos
• Fontes de informação e outros
produtos de análise de contexto
• Apoiar a criação de um modelo de
domínio
• Revisão do modelo
Analista de domínio,
especialista do domínio, analista
de requisitos e projetista de
software
• Produzir o modelo de
arquitetura com o modelo de
domínio.
• Revisão do modelo
Análise de domínio – abordagem FODA
Processo de análise de domínio - Processo
(Kang et al., 1990)
14

15. Produtos
da análise
do domínio
Produtos do
novo sistema
a ser desenvolvido
Análise
de contexto
Modelagem
de Domínio
Modelagem
da Arquitetura
Contexto
e
escopo
Modelos
(Features,
ER, etc)
Arq.
Estrutura
de controle
Novo
contexto
Novas
espec.
Nova
arquit.
Requisitos
Requisitos
Requisitos Software
Domínio
Domínio
Domínio
Usuário
Usuário
Especialista
do domínio
Analista
do domínio
Adicionar, Modificar e remover “features”
Adicionar, Modificar e remover “features”
Adicionar, Modificar e remover “features”
Análise de domínio – abordagem FODA
Processo de análise de domínio – Adaptando novos produtos
(Kang et al., 1990)
15

16. • Premissas estabelecidas
• Modelos de domínio
• Identificação de requisitos comuns e variantes
• Especificação de requisitos comuns e variantes
Modelagem de domínio
Sistema de Gestão de Crises
16

17. 1. Formação de uma equipe seguindo a formação de participantes da abordagem
FODA:
Papéis Representados por
Analista de domínio
Pessoa com sólida experiência em análise e modelagem de
domínios de sistemas variados.
Especialistas de
domínio
Pessoas especializadas em gestão de crises de qualquer natureza
com foco em modalidades de transportes.
Usuários
Representantes: Atendente, Supervisor, Coordenador,
Observador, Grupo de Apoio à Crise (Bombeiros. Médicos,
Enfermeiros)
Modelagem de domínio
Premissas estabelecidas
• Analista de domínio
• Analistas de requisitos
• Especialistas de domínio
• Projetistas de softwares
• Usuários
17

18. 2. Etapa da análise de contexto foi realizada seguindo o processo de análise de
domínio da abordagem FODA
Insumos utilizados no processo:
Documento visão do SGAVE (Sistema de Gestão de Acidentes de Veículos em
Estradas)
- Definição e finalidade do produto
- Relação dos stakeholders e usuários
Modelagem de domínio
Premissas estabelecidas
18

19. 3. Aplicar o método FODA para abstrair elementos do SGC
“Desenvolvimento de produtos de domínio genéricos e amplamente aplicáveis
dentro de um domínio é o principal objetivo do método FODA. Este conhecimento
geral pode ser alcançado por abstrair "fatores" que fazem uma aplicação diferente
de outras aplicações. No entanto, para desenvolver aplicações dos produtos
genéricos, os fatores que foram abstraídos devem ser feito de forma específica e
introduzida durante o refinamento. Não só o conhecimento geral, mas também os
fatores que tornam cada aplicativo exclusivo são partes importantes do
conhecimento de domínio e devem ser capturados nos produtos de domínio.”
(Kang et al., 1990)
Conceitos de modelagem utilizados
- Agregação/Decomposição
- Generalização/Especialização
Modelagem de domínio
Premissas estabelecidas
19

20. 4. Escopo, limites e contexto
Produto:
Sistema de Gestão de Crises (SGC).
Definição:
Sistema de gestão de acidentes em rodovias no Estado de São Paulo.
Foco de atuação:
Acidentes de veículos em rodovias
Finalidade:
Facilitar o processo de gestão de crise, auxiliando a designação eficaz de recursos e
orquestrando a comunicação entre todas as partes envolvidas no tratamento da
crise.
Modelagem de domínio
Premissas estabelecidas
20

21. 4. Escopo, limites e contexto
Produto:
Sistema de Gestão de Crises (SGC).
Linha de Produtos:
Sistema de Gestão de Crises para Modalidades de Transportes (SGCMT).
Foco de atuação:
Meios de transportes (Carros, Motos, Caminhões, Aviões, Helicópteros, Trens e etc).
Finalidade:
Facilitar o processo de gestão de crise, auxiliando a designação eficaz de recursos e
orquestrando a comunicação entre todas as partes envolvidas no tratamento da
crise.
Modelagem de domínio
Premissas estabelecidas
PLANO DE MERCADO
PLANO DE PRODUTO
21

22. 5. Diagrama de estrutura (alto nível)
SGC
GCAR GCAF GCAA
Gestão da
crise
SGCMT
Gestão da
crise
Gestão da
crise
1) Família de produtos SGC
Sistema de Gestão de Crise
2) Linha de produtos SGCMT
Sistema de Gestão de Crise para
Modalidades de Transportes
3) Produtos SGCMT
• GCAR - Gestão de Crise para
Acidentes Rodoviários
• GCAF - Gestão de Crise para
Acidentes Ferroviários
• GCAA - Gestão de Crise
para Acidentes Aéreos
4) Finalidade
Facilitar o processo de gestão de
crise, deslocando recursos
e orquestrando a comunicação
entre todas as partes envolvidas.
Modelagem de domínio
Premissas estabelecidas
22

23. 6. Stakeholders comuns da linha de produtos SGCMT
Produto
Resumo dos principais
Stakeholders
Resumo dos stakeholders
em comum
GCAR
Polícia Rodoviária
Concessionárias de
Rodovias
1. Governo do Estado de São Paulo
2. Vítimas
3. Testemunhas
4. Comunidade local
5. Operadoras de Telefone
6. Atendente da Crise
7. Coordenador da Equipe de Gestão de Crise
8. Equipe de Gestão de Crise
9. Grupos de resgate
1. GRAU (Grupo de Resgate e
Atendimento a Urgências)
2. CBPMESP (Corpo de Bombeiros
Militar do Estado de São Paulo)
3. Grupamento de Radiopatrulha Aérea
da Polícia Militar.
GCAF
Polícia Ferroviária
Concessionárias de
Ferrovias
GCAA
Polícia Federal
Força Área Brasileira
Exército Brasileiro
Marinha do Brasil
Modelagem de domínio
Premissas estabelecidas
23

24. 7. Usuários comuns da linha de produtos SGCMT
Produto
Resumo dos stakeholders
em comum
Resumo dos usuários
em comum
GCAR
1. Governo do Estado de São Paulo
2. Vítimas
3. Testemunhas
4. Comunidade local
5. Operadoras de Telefone
6. Atendente da Crise
7. Coordenador da Equipe de Gestão
de Crise
8. Equipe de Gestão de Crise
9. Grupos de resgate
1. GRAU (Grupo de Resgate e
Atendimento a Urgências)
2. CBPMESP (Corpo de
Bombeiros Militar do Estado
de São Paulo)
3. Grupamento de
Radiopatrulha Aérea da
Polícia Militar.
• Atendente
6. Atendente da Crise
• Coordenador
7. Coordenador da Equipe de
Gestão de Crise
• Observador, Supervisor
6 Equipe de Gestão de Crise
• Recursos Humanos
9. Grupos de resgate
• Centro de Controle
8. Equipe de Gestão de Crise
• Operadora de Telefonia
5. Operadoras de Telefone
GCAF
GCAA
Modelagem de domínio
Premissas estabelecidas
24

25. Produto Atores Casos de Uso
GCAR
• Atendente
• Coordenador
• Observador
• Supervisor
• Recursos
Humanos
• Centro de
Controle
1. Abrir chamado de incidente
2. Cancelar chamado de incidente
3. Consultar chamado de incidente
4. Avaliar chamado de incidente
5. Registrar ocorrência da crise
6. Cancelar ocorrência da crise
7. Monitorar situação da crise
8. Modificar situação da crise
9. Encerrar ocorrência da crise
10. Definir estratégia de mitigação
11. Modificar estratégia de mitigação
12. Cancelar estratégia de mitigação
13. Avaliar estratégia de mitigação
14. Definir procedimentos de mitigação
15. Consultar procedimentos de mitigação
16. Alocar recursos para a crise
GCAF
GCAA
Use Cases: Best Practices - By Ellen Gottesdiener - 2003 - IBM
8. Atores candidatos e casos de uso
Modelagem de domínio
Premissas estabelecidas
25

26. 9. A escolha da linguagem de modelagem
• Um artefato composto de um vocabulário de conceitos do domínio (suas
definições e propriedades), um modelo mostrando todas as relações
possíveis entre estes conceitos e um conjunto de regras formais que
restringem a interpretação dos conceitos e relações, representando de
maneira clara e não ambígua o conhecimento do domínio.
(Guarino, 1997)
Selecionadas
• ER
• SBVR
• Método de modelagem por metas e cenários (Kim, J. et al., 2006)
Modelagem de domínio
Premissas estabelecidas
26

27. Análise de domínio e reuso de requisitos de software
Até o momento, a finalidade do sistema de gestão de crise era a de gerenciar o
atendimento de acidentes de veículos em estradas. Agora, seu escopo deve ser
ampliado para tratar diversas situações de crise, como as decorrentes de
desastres naturais, de várias modalidades de transporte, etc., constituindo uma
linha de produtos de software.
• Apresentar uma versão inicial de parte significativa do modelo de domínio,
numa linguagem apropriada, que identifique e especifique requisitos
comuns e variantes da linha de produtos. Para tanto:
– Empregar o método de modelagem proposto por (Kim, J. et al., 2006).
Explicitar as premissas assumidas.
– Apresentar uma avaliação a respeito da viabilidade de aplicação prática
deste método de modelagem.
Objetivo 1 27

28. • Premissas estabelecidas
• Modelos de domínio
• Identificação de requisitos comuns e variantes
• Especificação de requisitos comuns e variantes
Modelagem de domínio
Sistema de Gestão de Crises
28

29. Chamado
Estratégia de
mitigação
Procedimentos de
mitigação
Recursos MITIGA CriseCONTÊM
REGISTRA
ANALISA
Atendente
Supervisor REGISTRA
Coordenador
ALOCA
Modelagem de domínio
Modelos de Domínio - ER
29
1 N
DEFINE
CONSOME
1
N
1
N
1N
1
1
1
N
N
N
1
N

30. Modelagem de domínio
Modelos de Domínio - SBVR
30
Regra R1:
O coordenador deve aguardar a ocorrência de uma crise para definir uma estratégia de
mitigação.
Regra R2:
O supervisor registra uma ocorrência de uma crise após um chamado ser classificado como
legítimo
Regra R3:
Os recursos consomem procedimentos de mitigação quando alocados pelo coordenador
Termo:
É usado para designar um conceito de palavra.
Verbo: O verbo é usado para designar conceitos de verbos, usualmente um verbo, preposição ou
combinação. Tal designação é definida no contexto na forma de expressão.
Palavra-chave: A palavra-chave é usada para símbolos linguísticos na construção de declarações – as
palavras podem ser combinadas com outras designações para formular declarações e definições

31. • Premissas estabelecidas
• Modelos de domínio
• Identificação de requisitos comuns e variantes
• Especificação de requisitos comuns e variantes
Modelagem de domínio
Sistema de Gestão de Crises
31

32. Motivação
As principais abordagens orientadas à características FODA/FeaturSEB NÃO
SUPORTAM um processo bem definido e a fonte de variabilidade.
• Processo bem definido
Sem um processo bem definido, a abordagem torna-se menos aplicável pela
ausência de um conjunto de passos de como se aplicar o método
• Fonte de variabilidade
Sem capturar o conhecimento da fonte de variabilidade, torna-se mais difícil
prever quando as variações vão ocorrer e de onde elas se originam.
Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
32

33. Metas e cenários na engenharia de requisitos
“São formas efetivas de indentificação de requisitos na engenharia de requisitos.”
(Kim et al, 2004, Potts, 1997; Rolland et al., 1998b. Sutcliffe, 1998)
“Metas fornecem uma análise racional para requisitos . Requisitos existem por
estarem fundamentados sobre metas. Metas fornecem uma base para requisitos.”
(Dardenee et al., 1991; Kim et al., 204; Sommerville and Sawyer, 1997)
“Cenários descrevem situação reais, capturando requisitos reais em um
determinado contexto.”
(Rolland et al, 1998b)
Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
33

34. • No contexto de linha de produto metas de negócios de alto nível guiam
planos de marketing e planos de produtos e forcam produtos em uma família
de produtos a terem requisitos comuns e variantes.
• Nas metas de negócios as características dos produtos são determinadas e
também fornecem uma análise sobre os requisitos do domínio.
• A modelagem de metas e cenários possibilita a gestão adequada das
variações entre produtos em uma família de produto.
Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
Metas e cenários em características de produtos
34

35. CenárioMeta
< Alcança
N
Autor >
1
Comum
Alternativo
Opcional
Tipo de variação
Meios de
se alcançar a meta
Tipos de cenários
Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
Metas e cenários na análise de requisitos do domínio
35

36. Meta
V + Target + Direction
V: Verbo ativo
Target: Objeto concentual ou físico
Direction: Fonte ou destino
Cenário
S + V + Target + Direction + Manner
S: Agente para o sistema projetado ou o próprio sistema projetado
V: Verbo ativo
Target: Objeto conceitual ou físico
Direction: Fonte ou destino
Manner: Forma o qual o cenário está implementado
Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
Escrevendo metas e cenários em características de produtos
36

37. Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
Características da abordagem
37

38. Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
Análise de requisitos do domínio – Processo de modelagem
38

39. Análise de requisitos do domínio – Utilizando o método
Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
39
BG: Meta de negócio
Sg: Meta de serviço
Ss: Cenário de serviço
IAg: Meta de interação
IAs: Cenário de interação
INg: Meta interna
INs: Cenário interno

40. Meta de negócio do SGCMT
BG: "Ser o principal e o melhor sistema de gestão de crise de meios de transportes
para o estado de São Paulo"
Metas de serviços
Sg1: "Fornecer gestão de crise para acidentes rodoviários“
Sg2: “Fornecer gestão de crise para acidentes ferroviários“[alternativo]
Sg3: "Fornecer gestão de crise para acidentes aéreos“[alternativo]
Análise de requisitos do domínio – Utilizando o método
Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
40
Nível de negócio

41. • Sg1: "Fornecer gestão de crise para acidentes rodoviários“
• Ss1: Coordenador pode alocar unidades GRAU (Grupo de Resgate e Atendimento a
Urgências) para uma ocorrência de crise via centro de controle. [comum]
• Sg2: “Fornecer gestão de crise para acidentes ferroviários“
• Ss1: Coordenador pode alocar unidades GRAU (Grupo de Resgate e Atendimento a
Urgências) para uma ocorrência de crise via centro de controle. [comum]
• Ss2: Coordenador pode alocar unidades da polícia ferroviária para acidentes de trens
via centro de controle [opcional]
• Sg3: "Fornecer gestão de crise para acidentes aéreos“
• Ss1: Coordenador pode alocar unidades GRAU (Grupo de Resgate e Atendimento a
Urgências) para uma ocorrência de crise via centro de controle [comum]
• Ss2: Coordenador pode alocar unidades da FAB (Força Aérea Brasileira) para
acidentes de aviões via centro de controle [opcional]
Nível de serviçoAnálise de requisitos do domínio – Utilizando o método
Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
41

42. • Sg1: "Fornecer gestão de crise para acidentes rodoviários“
Ss1: Coordenador pode alocar unidades GRAU (Grupo de Resgate e Atendimento a Urgências) para
uma ocorrência de crise via centro de controle [comum]
IAg1: “Alocar unidades GRAU para o local da crise “
• IAs1: Coordenador deve definir a estratégia de mitigação da crise [comum]
• IAs2: Coordenador deve acionar unidades GRAU para o local da crise por meio dos
procedimentos da estratégia de mitigação escolhida [comum]
• IAs3: Coordenador pode acionar unidades do GATE (Grupo de Ações Táticas Especiais da
PM) para o local da crise por meio das unidades GRAU [opcional]
Análise de requisitos do domínio – Utilizando o método
Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
42
Nível de interação

43. • Sg1: "Fornecer gestão de crise para acidentes rodoviários“
Ss1: Coordenador pode alocar unidades GRAU (Grupo de Resgate e Atendimento a Urgências) para
uma ocorrência de crise via centro de controle [comum]
IAg1: “Alocar unidades GRAU para o local da crise “
• IAs1: Coordenador deve definir a estratégia de mitigação da crise [comum]
• IAs2: Coordenador deve acionar unidades GRAU para o local da crise por meio dos
procedimentos da estratégia de mitigação escolhida [comum]
• IAs3: Coordenador pode acionar unidades do GATE (Grupo de Ações Táticas Especiais da
PM) para o local da crise por meio das unidades GRAU [opcional]
Análise de requisitos do domínio – Utilizando o método
Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
43
Nível interno
INg2: “Encaminhar informações da ocorrência e procedimentos para a central
da GRAU“
• INs1: Módulo de comunicação SGC deve transmitir um pacote com informações
sobre a ocorrência para a central da GRAU [comum]
• INs2: Módulo de comunicação SGC deve aguardar confirmação da central da GRAU
[comum]
• INs3: Módulo de comunicação SGC pode retransmitir um pacote com informações
sobre ocorrência para a central da GRAU [opcional]

44. • Sg3: "Fornecer gestão de crise para acidentes aéreos“
• Ss1: Coordenador pode alocar unidades GRAU (Grupo de Resgate e Atendimento a Urgências)
para uma ocorrência de crise via centro de controle [comum]
• Ss2: Coordenador pode alocar unidades da FAB (Força Aérea Brasileira) para acidentes de
aviões pelo centro de controle [opcional]
IAg2: “Alocar unidades da FAB para o local da crise “
• IAs1: Coordenador deve definir a estratégia de mitigação da crise [comum]
• IAs2: Coordenador deve acionar unidades da FAB para o local da crise por meio dos
procedimentos da estratégia de mitigação escolhida [comum]
Análise de requisitos do domínio – Utilizando o método
Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
44
Nível de interação

45. • Sg3: "Fornecer gestão de crise para acidentes aéreos“
• Ss1: Coordenador pode alocar unidades GRAU (Grupo de Resgate e Atendimento a Urgências)
para uma ocorrência de crise via centro de controle [comum]
• Ss2: Coordenador pode alocar unidades da FAB (Força Aérea Brasileira) para acidentes de
aviões pelo centro de controle [opcional]
IAg2: “Alocar unidades da FAB para o local da crise “
• IAs1: Coordenador deve definir a estratégia de mitigação da crise [comum]
• IAs2: Coordenador deve acionar unidades da FAB para o local da crise por meio dos
procedimentos da estratégia de mitigação escolhida [comum]
Análise de requisitos do domínio – Utilizando o método
Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
45
Nível interno
INg2: “Encaminhar informações da ocorrência e procedimentos ao centro de
controle da FAB “
• INs1: Módulo de comunicação SGC deve transmitir um pacote com informações
sobre ocorrência para o centro de controle de desastres aéreos da FAB [comum]
• INs2: Módulo de comunicação SGC deve aguardar a confirmação para o centro de
controle de desastres aéreos da FAB [comum]
• INs3: Módulo de comunicação SGC pode retransmitir um pacote com informações
sobre ocorrência para o centro de controle de desastres aéreos da FAB [opcional]

46. Fornecer gestão de
crise para acidentes
rodoviários
Fornecer gestão de
crise para acidentes
ferroviários
Fornecer gestão de crise
para acidentes aéreos
Ser o principal e o melhor sistema de gestão de crise
de meios de transportes para o estado de São Paulo
Alocar unidades GRAU
para o local da crise
Encaminhar informações
da ocorrência e
procedimentos a central
da GRAU.
Alocar unidades GRAU
para o local da crise
Encaminhar informações
da ocorrência e
procedimentos a central
da GRAU.
Alocar unidades GRAU
para o local da crise
Encaminhar informações
da ocorrência e
procedimentos a central
da GRAU.
SGCMT
Alocar unidades da FAB
para o local da crise
Encaminhar informações
da ocorrência e
procedimentos ao centro
de controle de desastres
aéreos da FAB.
Árvore de metas
Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
46

47. Modelagem de domínio
Identificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
47

48. • Premissas estabelecidas
• Modelos de domínio
• Identificação de requisitos comuns e variantes
• Especificação de requisitos comuns e variantes
Modelagem de domínio
Sistema de Gestão de Crises
48

49. Representação dos requisitos do domínio – Visão geral
- Metas e cenários no nível de interação dos requisitos de domínio são usados
para ajudar a construir casos de usos.
- Uma meta no nível de interação é alcançada através de cenários e um caso de
uso contém o conjunto de cenários possíveis para alcançar a meta
Modelagem de domínio
Especificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
49

50. Representação dos requisitos do domínio – Regras-guia de transferência
Regras Definição
R1 Metas no nível de interação tornam-se casos de uso
R2 Um agente que necessita interagir com a meta torna-se o ator primário
R3
Cenários tornam-se especificações textuais de casos de uso e um agente ou
sujeito do cenário pode se tornar um ator. Caso um agente não se torne um
ator primário o mesmo deve ser considerado como secundário
R4
Metas com requisitos variantes no nível de interação tornam-se casos de uso
com tipo variante. Se uma meta tem um relacionamento como “alternativo”,
um caso de uso com o estereótipo “<<alternative>>” é representado no
diagrama. Se uma meta tem um relacionamento como “opcional”, um caso de
uso com o estereótipo “<<opcional>>” é representado no diagrama.
R5
Metas e cenários no nível interno são descritos em cada especificação textual
de caso de uso
Modelagem de domínio
Especificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
50

51. Representação dos requisitos do domínio – Diagrama de casos de uso
Coordenador
<<comum>>
Alocar unidades GRAU
para o local da crise
<<opcional>>
Alocar unidades da FAB
para o local da crise
SGCMT
Modelagem de domínio
Especificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
51

52. Representação dos requisitos do domínio – Diagrama de casos de uso
Coordenador
<<comum>>
Alocar unidades GRAU
para o local da crise
<<opcional>>
Alocar unidades da FAB
para o local da crise
SGCMT
R1
META DE INTERAÇÃO >
CASO DE USO
R2
AGENTE > ATOR
R4
ESTEREÓTIPOS DE
VARIAÇÃO
Modelagem de domínio
Especificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
52

53. Representação dos requisitos do domínio – Especificação de caso de uso
Nome do caso de uso: Alocar unidades GRAU para o local da crise
Atores: Coordenador
Descrição do caso de uso:
1. Coordenador deve definir a estratégia de mitigação da crise <<comum>>
2. Coordenador deve acionar unidades GRAU para o local da crise por meio dos
procedimentos da estratégia de mitigação escolhida <<comum>>
1. Encaminhar informações da ocorrência e procedimentos para a central da
GRAU
1. Módulo de comunicação SGC deve transmitir um pacote com informações
sobre a ocorrência para a central da GRAU <<comum>>
2. Módulo de comunicação SGC deve aguardar confirmação da central
da GRAU <<comum>>
3. Módulo de comunicação SGC pode retransmitir um pacote com informações
sobre ocorrência para a central da GRAU << opcional >>
3. Coordenador pode acionar unidades do GATE para o local da crise por meio das
unidades GRAU <<opcional>>
Tipo de variação: Comum
Modelagem de domínio
Especificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
53

54. Nome do caso de uso: Alocar unidades GRAU para o local da crise
Atores: Coordenador
Descrição do caso de uso:
1. Coordenador deve definir a estratégia de mitigação da crise <<comum>>
2. Coordenador deve acionar unidades GRAU para o local da crise por meio dos
procedimentos da estratégia de mitigação escolhida <<comum>>
1. Encaminhar informações da ocorrência e procedimentos para a central da
GRAU
1. Módulo de comunicação SGC deve transmitir um pacote com informações
sobre a ocorrência para a central da GRAU <<comum>>
2. Módulo de comunicação SGC deve aguardar confirmação da central
da GRAU <<comum>>
3. Módulo de comunicação SGC pode retransmitir um pacote com informações
sobre ocorrência para a central da GRAU << opcional >>
3. Coordenador pode acionar unidades do GATE para o local da crise por meio das
unidades GRAU <<opcional>>
Tipo de variação: Comum
Representação dos requisitos do domínio – Especificação de caso de uso
R1
META DE INTERAÇÃO >
CASO DE USO
R2
AGENTE > ATOR
R3
CENÁRIOS DE INTERAÇÃO
> ESPECIFICAÇÃO
AGENTES > ATOR
R4
ESTEREÓTIPOS DE
VARIAÇÃO
R5
METAS E CENÁRIOS DO NÍVEL
INTERNO SÃO DESCRITOS NA
ESPECIFICAÇÃO DE CASO DE USO
Modelagem de domínio
Especificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
54

55. Modelagem de domínio
Especificação de requisitos comuns e variantes
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
55

56. Pontos fortes
1. Uma boa abordagem para a derivação do escopo das metas de negócios
2. Os níveis de metas propostos auxiliam nas definições dos requisitos de
acordo com cada perspectiva
3. Existe uma rastreabilidade total entre metas, cenários, requisitos e
especificação
4. Existe uma rastreabilidade parcial entre planos de marketing e de produto
com as metas de negócio
5. Bom entendimento sobre a variabilidade das características do produto em
uma linha de produto
6. Facilidade em escalar a produção de novos produtos utilizando-se do reuso
do software
Modelagem de domínio
Apresentar uma avaliação a respeito da viabilidade de aplicação prática do método
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
56

57. Pontos fracos
1. Dificuldade em se aplicar o método sem um documento visão bem
definido
2. Dificuldade em se criar metas de serviços sem um plano de marketing bem
definido
3. Dificuldade na derivação de cenários para as metas dos níveis
subsequentes
4. Dificuldade no uso do método sem um conhecimento prévio de uma
abordagem dirigida à características como o FODA e o FeaturSEB
5. Necessidade dos papéis de analista do domínio e especialista do domínio.
E segundo o FODA de uma equipe contendo um analista de requisitos ,
usuários e projetista de software.
6. Não encontrado nenhum papel relacionado à gerente de produto ou
gerente grupo-produto (linha de produto).
Modelagem de domínio
Apresentar uma avaliação a respeito da viabilidade de aplicação prática do método
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
57

58. Oportunidades
1. Adaptar os papéis do FODA com uma metodologia ágil
Ex: Em equipes usando metodologia Scrum, tentar adequar os papeis da
equipe que possam de fato suprir um analista de domínio e um
especialista do domínio.
2. Considerar na abordagem FODA os conceitos de Lean Startup
Ex: Para criar produtos MVP (Mínimo produto viável) tentar utilizar um
processo de análise de domínio mais enxuto e tentar adaptar os métodos
de modelagem para a criação de linhas de produtos que possam
responder bem a mudanças.
Modelagem de domínio
Apresentar uma avaliação a respeito da viabilidade de aplicação prática do método
Artigo Kim, J. et al., 2006 - Goal and scenario based domain requirements analysis environment
58

59. Rastreabilidade dos requisitos de software
Considerando a solução proposta na primeira parte:
• Definir a Estratégia de Rastreabilidade dos requisitos de software para a
linha de produtos definida.
• Considerando a estratégia definida:
– Elaborar alguns fragmentos de matrizes de rastreabilidade
considerando os requisitos de domínio identificados como requisitos
comuns e variantes.
– Definir os principais atributos dos requisitos de software a serem
utilizados na gerência dos requisitos. Justificar.
Objetivo 2 59

60. Rastreabilidade dos requisitos de software 60
Estratégia de rastreabilidade
- As características dirigem o MCU (Spence, I.; Probasco, L. , 2000)
- Pré-rastreabilidade: das origens à especificação dos requisitos
- Método proposto no artigo Kim, J. et al
- Rastreabilidade das características do software à especificação de
casos uso através de metas e cenários.
- Rastreabilidade da ERS alinhadas à prática IEEE 830-1998.
- Rastreamento para trás (estágios anteriores do desenvolvimento).

61. Rastreabilidade dos requisitos de software 61
Estratégia de rastreabilidade
Quais as relações que têm interesse para a gerência de requisitos?
- Identificar o conjunto de objetos (Ramesh,B.; Jarke, M., 2001) exigidos
para definir os itens de rastreabilidade.
• Necessidade e característica
• RF e RNF
• Itens do glossário
• Caso de uso e Seção de caso de uso
• Ator
Spence e Probasco (2000)

62. Rastreabilidade dos requisitos de software 62
Estratégia de rastreabilidade
As características dirigem o MCU
(Spence, I.; Probasco, L. , 2000)

63. Rastreabilidade dos requisitos de software 63
Matrizes de rastreabilidade
As características dirigem o MCU
Necessidade
Características
Alocação de
recursos GRAU
Alocação de
recursos da Polícia
Rodoviária
Alocação de
recursos da
Polícia Ferroviária
Alocação de
recursos da FAB
Fornecer gestão de crise
para acidentes
rodoviários
X X
Fornecer gestão de crise
para acidentes
ferroviários
X X
Fornecer gestão de crise
para acidentes aéreos
X X

64. Rastreabilidade dos requisitos de software 64
Matrizes de rastreabilidade
As características dirigem o MCU
Características
Casos de uso
Encaminhar
procedimentos de
mitigação para as
unidades da GRAU
Encaminhar
procedimentos de
mitigação para as
unidades da FAB
Alocar unidades
GRAU para o
local da crise
Alocar unidades
da FAB para o
local da crise
Alocação de recursos
GRAU
X X
Alocação de recursos da
FAB
X X
Alocação de recursos da
Polícia Rodoviária
Alocação de recursos da
Polícia Ferroviária

65. Rastreabilidade dos requisitos de software 65
Atributos dos requisitos de software a serem gerenciados
Fatores críticos de sucesso
• Prioridade
o Alta, Média e Baixa
• Dificuldade
o Alta, Média e Baixa
• Status
o Apontado, Aprovado, Em desenvolvimento, Implementado e
Validado
• Valor de negócio (Baseado em ROI )
o Alto, Médio e Baixo
Cohn, Mike, Agile Estimating and Planning, 2006

66. Rastreabilidade dos requisitos de software 66
Atributos dos requisitos de software a serem gerenciados
Matriz de atributos
Características
Atributos
Prioridade Dificuldade Status Valor de negócio
Alocação de recursos
GRAU
Alta Média Implementado Alto
Alocação de recursos da
FAB
Baixa Alta Apontado Baixo
Alocação de recursos da
Polícia Rodoviária
Alta Média
Em
desenvolvimento
Alto
Alocação de recursos da
Polícia Ferroviária
Média Alta Apontado Médio

67. Referências
1) Kim, J.; Kim, M.; Park, S. Goal and scenario based domain requirements analysis environment. In:
The Journal of Systems and Software, 79 (2006) p. 926-938
2) Kang, K.C. et al, Feature-oriented domain analysis feasibility study. CMU/SEI-TR- 21, 1990.
3) Pohl, K. et al. Software Product Line Engineering – Foundations, Principles, and Techniques.
Springer-Verlag, 2005
4) Arango, G. A brief introduction to domain analysis. In Proc. of the 1994 ACM Symposium on Applied
Computing, Phoenix, AZ USA, 1994, pp. 42-46.
5) Evermann, J.; Wand, Y. Toward formalizing domain modeling semantics in language syntax. IEEE
Transactions on Software Engineering, vol. 31 (1), 2005.
6) Guizzardi, G., Herre, H., Wagner G. On the general ontological foundations of conceptual modeling.
In Proc. of 21st Intl. Conf. on Conceptual Modeling (ER 2002), Springer-Verlag, Berlin, LNCS n. 2503,
2002, pp. 65-78.
7) Spence, I.; Probasco, L. Traceability strategies for managing requirements with use cases.
IBM/Rational, 2000.
8) Gottesdiener , E; Use Cases: Best Practices . IBM, 2003
9) Cohn, Mike, Agile Estimating and Planning Prentice Hall, 2006
67

68. Obrigado :)
André Rocha Agostinho
andre@magnadev.com.br
www.scrumalliance.org/aagostinho
68