GORE e as principais técnicas de especificação

Apresentação em tema: "GORE e as principais técnicas de especificação"— Transcrição da apresentação:

1

2 GORE e as principais técnicas de especificação

3 Agenda Motivação Goal-Oriented Requirements Engineering (GORE)
GORE - Especificação de requisitos GBRAM GRL KAOS

4 Motivação GORE Métodos tradicionais se preocupam apenas com o que deve ser feito. Métodos orientados a metas se preocupam com o “porquê” e “como”.

5 Métodos GORE Perguntam porque uma certa funcionalidade é necessária e como ela pode ser implementada. Mantém a razão para a funcionalidade do sistema através do conhecimento do porquê. Rastreiam diferentes alternativas de implementação e o critério de seleção entre estas alternativas.

6 GORE O que é uma meta? Existem várias definições na literatura.
Para contextualizar: É um objetivo do sistema sob consideração que deve ser alcançado. Formulações de metas se referem a propriedades que pretende-se garantir.

7 Métodos GORE Existem métodos GORE para atender as principais atividades da ER. A tabela presente em [Kavakli 2003] mostra as principais técnicas divididas por atividades da ER.

8 Métodos GORE

9 GBRAM

10 GBRAM GBRAM é a sigla para Goal-Based Requirements Analysis Method.
É utilizado para identificar, aprimorar, refinar e organizar metas para a especificação de requisitos.

11 GBRAM O método é focado em duas perspectivas: Análise de Metas
Evolução de Metas

12 GBRAM Antes de conhecermos o método em si, vamos conhecer:
Terminologia. Alguns conceitos chave.

13 GBRAM - Conceitos Metas Requisitos
São objetivos de alto nível do negócio, organização ou sistema. Capturam as razões que justificam a necessidade do sistema. Requisitos Especificam como uma meta deve ser cumprida por um sistema proposto.

14 GBRAM - Conceitos Operacionalização Metas de Realização
É o processo de definir uma meta suficientemente detalhada de forma que suas sub-metas tenham uma definição operacional. Metas de Realização São objetivos de alguma corporação ou sistema. Exemplo: Alistar estudantes nos cursos antes do início das aulas.

15 GBRAM - Conceitos Metas de Manutenção Agentes
São aquelas metas que são satisfeitas enquanto sua condição alvo permanecer verdadeira. Tendem a ser operacionalizadas como ações ou restrições que previnem certos estados de serem atingidos. Agentes São as entidades ou processos que realizam metas dentro de uma organização ou sistema.

16 GBRAM - Conceitos Restrições Decomposição de Metas
São requisitos que devem ser conhecidos para a realização da meta. Uma restrição coloca uma condição para a realização da meta. Decomposição de Metas É o processo de subdivisão de um conjunto de metas em um subconjunto lógico. Facilita o entendimento, definição e especificação dos requisitos do sistema.

17 GBRAM - Conceitos Cenários Obstáculos de Meta
São descrições comportamentais de um sistema e seu ambiente em situações restritas. Exemplificam comportamentos permitindo que necessidades escondidas sejam descobertas. São úteis para avaliar alternativas de projeto e validar projetos. Obstáculos de Meta São comportamentos ou outras metas que bloqueiam a realização de uma determinada meta. Abstrair e identificar obstáculos de meta permite considerar os possíveis caminhos para metas falharem e antecipar casos de exceção.

18 GBRAM - Conceitos Análise de Metas Evolução de Metas
Exploração de documentação Organização das metas Classificação das metas. Evolução de Metas Avalia a maneira que as metas mudam em todo o ciclo de vida do método.

19 GBRAM Agora vamos conhecer todas as atividades associadas a cada perspectiva. Conheceremos as atividades através de um estudo de caso.

20 GBRAM – Estudo de Caso Informações
CTTS (Sistema de Gerenciamento de Curso de Carreiras). Reengenharia de negócios para uma base de força aérea (AFB). Aproximadamente 155 funcionários da AFB são alistados no treinamento por ano.

21 GBRAM – Análise de Metas
Identificar metas Analisando as informações disponíveis foram encontradas 36 metas. Algumas destas metas são:

22 GBRAM – Análise de Metas
Classificar metas de realização e manutenção Existem várias perguntas que ajudam a classificar as metas. Por exemplo: “Esta meta denota um estado que foi alcançado ou um estado desejado?” (Realização) “A realização desta meta é requerida continuamente?” (Manutenção)

23 GBRAM – Análise de Metas
Classificar metas de realização e manutenção Exemplo: a meta “Dinheiro dos pagadores de taxas gasto eficientemente” deve ser executada de forma contínua. Esta meta caracteriza uma condição que deve ser mantida verdadeira.

24 GBRAM – Análise de Metas
Identificar agentes e stakeholders Agentes são identificados para determinar os responsáveis por realizar uma meta em um dado momento. Stakeholders são identificados para desenvolver um entendimento dos diferentes pontos de vista envolvidos no sistema para a resolução de conflitos.

25 GBRAM – Análise de Metas
Identificar agentes e stakeholders Uma meta pode ter um ou mais stakeholders associados. Exemplo: A meta “Conhecimentos profissionais melhorados” é de interesse do empregado e da AFB.

26 GBRAM – Evolução de Metas
Reduzir o tamanho do conjunto de metas e clareá-las. Existem três abordagens: Eliminar metas duplicadas Refinar metas baseado nas entidades do sistema Consolidar metas sinônimas

27 GBRAM – Evolução de Metas
Reduzir o tamanho do conjunto de metas e clareá-las. Refinar metas baseado nas entidades do sistema: Exemplo: a meta “Processo HRD concluído” deve ser refinada para entendermos tal processo. Especificamente neste caso esta meta se transformou em duas: “Vagas disponíveis no curso anunciadas” e “Pessoal qualificado identificado”.

28 GBRAM – Evolução de Metas
Reduzir o tamanho do conjunto de metas e clareá-las. Consolidar metas sinônimas: Exemplo de metas similares: “Conhecimentos melhorados” e “Qualificações melhoradas”. A meta “Conhecimentos melhorados” representa bem as duas metas.

29 GBRAM – Evolução de Metas
Reduzir o tamanho do conjunto de metas e clareá-las. As metas de realização do CTTS foram afetadas utilizando as técnicas de refinamento mostradas. O número de metas de realização diminuiu de 27 para 19.

30 GBRAM – Evolução de Metas
Usar restrições Exemplo: “O curso deve qualificar o empregado para avançar para outro nível”. Antes do empregado poder avançar seu nível de certificação ele deve participar de um curso que o qualifique para o avanço.

31 GBRAM – Evolução de Metas
Usar restrições Por causa da restrição, a meta “Cursos que o empregado se qualifica identificados” foi identificada.

32 GBRAM – Evolução de Metas
Aprimorar e refinar metas Relações de dependência Maneira de considerar outros possíveis aprimoramentos e refinamentos. São definidas através das perguntas: “Quais metas são pré-requisito para esta meta?” “Quais metas devem seguir esta meta?”.

33 GBRAM – Evolução de Metas
Identificar obstáculos de metas É útil considerar casos específicos que devem ser tratados devido a atividades que impedem a realização da meta. Exemplo: “De quais outras metas ou condições esta meta depende?”

34 GBRAM – Evolução de Metas
Identificar obstáculos de metas A realização da meta “Portfolio de carreira disponibilizado” depende da cooperação do surpevisor. Caso não exista tal cooperação surge um obstáculo.

35 GBRAM – Evolução de Metas
Identificar cenários A identificação de obstáculos inicia na identificação de caminhos nos quais as metas podem falhar. Cenários aprimoram esta informação. Cenários são instâncias dos obstáculos.

36 GBRAM – Evolução de Metas
Identificar cenários Exemplo: dado o obstáculo “Sem vagas disponíveis”. Através da pergunta “Quais são as circunstâncias sob as quais este obstáculo pode ocorrer? “Todos os cursos fechados (vagas preenchidas)”. “Curso cancelado”.

37 GBRAM – Evolução de Metas
Operacionalizar metas Informações das metas devem ser traduzidas para uma especificação de requisitos. Isto é feito através da consolidação das informações das metas em um conjunto de esquemas de metas.

38 GBRAM – Evolução de Metas
Operacionalizar metas Esquemas de metas especificam os relacionamentos entre metas e agentes em termos de eventos que causam a mudança de estado.

39 GBRAM – Evolução de Metas
Operacionalizar metas

40 GRL

41 GRL GRL é a sigla para Goal-oriented Requirement Language.
Dá suporte à modelagem e a justificativa de requisitos orientados a metas. Própria para requisitos não-funcionais.

42 GRL Fornece diversas construções para expressar vários tipos de conceitos que surgem durante o processo de requisitos. Existem três principais categorias destes conceitos. Elementos intencionais. Ligações. Atores.

43 GRL Suporta avaliação sobre cenários.
A modelagem de cenários é complementar à de metas. Ajuda na identificação de mais metas e cenários importantes. Contribui para a completude e precisão dos requisitos.

44 GRL Elementos intencionais
São chamados intencionais por causa da capacidade de responder questões: O porquê de comportamentos particulares. Aspectos informacionais e estruturais que foram escolhidos para serem incluídos nos requisitos do sistema Alternativas existentes. O porquê da escolha de uma alternativa em detrimento da outra.

45 GRL Elementos intencionais Goal Task Resource Softgoal Belief

46 GRL Elementos intencionais Definição de um elemento intencional:

47 GRL – Elementos intencionais
Meta (Goal) É uma condição que os stakeholders gostariam de alcançar. Não se especifica como alcançá-la. Permite que alternativas possam ser consideradas.

48 GRL – Elementos intencionais
Meta (Goal) Pode-se classificar uma meta como: Meta de negócio Expressa metas relativas ao negócio ou a algo que a organização quer alcançar. Meta de sistema Expressa metas que o sistema alvo deve alcançar (geralmente descrevem os requisitos funcionais).

49 GRL – Elementos intencionais
Meta (Goal) É representada graficamente por um retângulo arredondado Exemplo: VoiceConnectionBeSetup Meta básica para qualquer sistema de telecomunicação. Existem várias formas de configurar a conexão de voz.

50 GRL – Elementos intencionais
Tarefa (Task) Especifica uma forma particular de se fazer algo. Podem ser vistas como soluções em um sistema alvo.

51 GRL – Elementos intencionais
Tarefa (Task) É representada graficamente por um hexágono. Exemplo: MakeVoice-Over-LAN É uma forma particular de configurar uma conexão de voz.

52 GRL – Elementos intencionais
Recurso (Resource) É uma entidade física ou informacional. Disponibilidade é a principal preocupação.

53 GRL – Elementos intencionais
Recurso (Resource) É representado graficamente por um retângulo. Exemplo: LAN Bandwidth Largura de banda deve estar disponível na arquitetura voz sobre LAN.

54 GRL – Elementos intencionais
Meta Flexível (Softgoal) É uma condição que o ator gostaria de alcançar. Diferente da meta normal. Não há um critério bem definido para determinar se a condição foi alcançada.

55 GRL – Elementos intencionais
Meta Flexível (Softgoal) É representada graficamente por uma forma curvilínea irregular. Exemplo: Reliability of Router A confiança no roteador é uma softgoal que deve ser alcançada durante o projeto de um sistema de telecomunicação.

56 GRL – Elementos intencionais
Crença (Belief) São usadas para representar argumentos de projeto. Permitem que características do domínio sejam consideradas e corretamente refletidas dentro de um processo de tomada de decisão. Facilita uma posterior revisão, justificativa e mudança do sistema.

57 GRL – Elementos intencionais
Crença (Belief) É representada graficamente por uma elipse. Exemplo: Este argumento apóia a task VoiceLAN como um redutor de custos.

58 GRL Relacionamentos intencionais Existem cinco tipos:
Ligam os elementos intencionais. Existem cinco tipos: Decomposition Means-Ends Contribution Correlation Dependency

59 GRL Relacionamentos intencionais
A definição dos relacionamentos intencionais:

60 GRL – Relacionamentos intencionais
Means-Ends A sentença MEANS-END descreve como as metas são de fato alcançadas. Cada tarefa fornecida é um meio alternativo para alcançar a meta.

61 GRL – Relacionamentos intencionais
Means-Ends Exemplo gráfico:

62 GRL – Relacionamentos intencionais
Decomposition É a sentença que permite definir quais outros elementos precisam estar disponíveis para realizar uma tarefa. Estes elementos podem ser: tasks, goals, resources ou softgoals.

63 GRL – Relacionamentos intencionais
Decomposition Exemplo gráfico:

64 GRL – Relacionamentos intencionais
Contribution É a sentença que descreve como elementos intencionais contribuem entre si. Existem vários tipos: AND, OR, MAKE, BREAK, HELP, HURT, SOME-, SOME+, EQUAL, UNKNOWN.

65 GRL – Relacionamentos intencionais
Contribution Exemplo gráfico:

66 GRL – Atores É uma entidade ativa que realiza ações para alcançar metas. É representado graficamente por um círculo. Exemplo:

67 GRL – Atores Opcionalmente pode haver uma fronteira que define o escopo de atuação do ator. É representada por um círculo tracejado cinza. Exemplo:

68 GRL – Relacionamentos intencionais
Dependency É a sentença que descreve um relacionamento intencional entre dois atores.

69 GRL – Relacionamentos intencionais
Dependency Exemplo gráfico: Vários atores e dependências

70 GRL – Relacionamentos intencionais
Correlations Funciona da mesma forma que Contributions. A diferença é que a correlação é um desejo explícito e a contribuição é um efeito colateral.

71 KAOS

72 KAOS É uma metodologia. Tem o propósito de suportar todo o processo de elaboração de requisitos, a partir das metas de alto nível a serem alcançadas. Fornece: Linguagem de especificação. Método de elaboração.

73 KAOS Antes de conhecermos a linguagem e método vamos conhecer:
Terminologia Alguns conceitos

74 KAOS Objeto É algo de interesse no sistema cujas instâncias podem evoluir de estado. São caracterizados por declarações de atributos e constantes. Podem ser organizados em hierarquia de herança.

75 KAOS Objeto Entidade: é um objeto independente.
Relacionamento: é um objeto dependente de objetos que os ligam. Evento: é um objeto instantâneo.

76 KAOS Operação É uma relação de entrada e saída sobre os objetos.
Operações quando aplicadas definem transições de estado. São caracterizadas por pré-condições, pós-condições e condições de gatilho.

77 KAOS Agente É um objeto ativo que age como processador para algumas operações. Realiza uma operação, quando alocada a ele. Monitora e controla um objeto se os estados do objeto são observáveis e controláveis por ele. Podem ser humanos, dispositivos, programas, entre outros.

78 KAOS Meta É um objetivo que o sistema deve satisfazer.
Captura um conjunto de comportamentos desejados.

79 KAOS Meta Existem dois tipos de refinamento que relacionam as metas com as sub-metas: AND-refinement A única condição suficiente para satisfazer a meta é satisfazer todas as sub-metas. OR-refinement Satisfazer uma das sub-metas é condição suficiente para satisfazer a meta.

80 KAOS Meta Pode (opcionalmente) ser caracterizada por um atributo de prioridade: Especifica se a meta é obrigatória ou opcional. São classificadas de acordo com a categoria dos requisitos que irão lidar.

81 KAOS Meta Metas funcionais resultam em requisitos funcionais.
Por exemplo: SatisfactionGoals São relacionadas com a satisfação das requisições dos agentes.

82 KAOS Meta Metas não-funcionais resultam em requisitos não-funcionais.
Por exemplo: AccuracyGoals São relacionadas com a manutenção da consistência entre o estado dos objetos no ambiente e o estado de suas representações no software.

83 KAOS Meta O refinamento da meta termina quando as metas terminais são atingidas. Uma meta terminal pode ser formulada em termos de estados controláveis por algum agente individual. Um requisito é uma meta terminal designada a um agente no ambiente. As metas terminais são operacionalizadas por operações e objetos.

84 KAOS Propriedade de domínio
É uma propriedade sobre os objetos ou operações no ambiente que existe independentemente do sistema a ser construído. Incluem leis da física, regulamentos, restrições impostas por agentes ambientais, entre outros.

85 KAOS Cenário É uma seqüência consistente de domínio das transições de estado controladas por instâncias dos agentes correspondentes. Consistência de domínio significa que a operação é aplicada em um estado que satisfaz sua pré-condição de domínio, resultando em um estado que satisfaz sua pós-condição de domínio.

86 KAOS Cada construção na linguagem tem uma estrutura genérica de dois níveis: Uma camada de rede semântica exterior. Declara um conceito, seus atributos e suas várias ligações a outros conceitos. Uma camada de declaração interna para definir formalmente o conceito.

87 KAOS Exemplo de especificação para um sistema de despacho de ambulância:

88 KAOS A primeira parte da declaração:
Introduz um conceito do tipo Goal: AmbulanceMobilization. Declara uma propriedade alvo que deve eventualmente manter, referindo-se a objetos, tais como, Call ou Ambulance. Refina a meta de origem AmbulanceIntervention. Refinado em sub-metas IncidentFiled, AmbulanceAllocated e AllocatedAmbulanceMobilized. E uma definição informal.

89 KAOS A segunda parte da declaração (opcional):
Define a meta em termos formais usando uma lógica temporal de tempo real. Os operadores de lógica temporal utilizados são:

90 KAOS – Método de elaboração

91 KAOS – Método de elaboração
Elaboração de meta Elabora a estrutura AND/OR da meta. Define metas e suas ligações de refinamento até alcançar as metas designáveis. A identificação de metas é realizada geralmente através de uma combinação de processos top-down e bottom-up. Metas descendentes são identificadas através de questões “Como?” Metas de origem são identificadas através de questões “Porque?”

92 KAOS – Método de elaboração
Captura dos objetos Identifica os objetos envolvidos nas formulações das metas. Define suas ligações conceituais. Descreve suas propriedades de domínio por constantes.

93 KAOS – Método de elaboração
Captura das operações Identifica transições do estado do objeto que são significantes para as metas. As formulações de metas referem aos estados desejados ou proibidos. São alcançáveis apenas através de transições de estado.

94 KAOS – Método de elaboração
Operacionalização Deriva: As (pré-, pós- e gatilho) condições em operações. Constantes em objetos.

95 KAOS – Método de elaboração
Designação de responsabilidade Identificar responsabilidades alternativas para metas terminais. Designar as operações para os agentes que podem realizá-las. As várias metas terminais se tornam requisitos.

96 Conclusões Avanço a engenharia de requisitos orientada a metas.
Supõe-se que esta abordagem é bastante proveitosa. Captura dos requisitos de forma mais eficaz. Evita que alguns projetos fracassem.

97 Referências [Kavakli 2003] Kavakli, E. and P. Loucopoulos (2003). Goal driven requirements engineering: Evaluation of current methods. 8th CAiSE/IFIP8.1 International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design (EMMSAD'03), Velden, Austria. [Annie 1996] Annie, I. A. (1996). Goal-Based Requirements Analysis. Proceedings of the 2nd International Conference on Requirements Engineering (ICRE '96), IEEE Computer Society. [Annie 1997] Annie, I. A. (1997). Goal identification and refinement in the specification of software-based information systems, Georgia Institute of Technology. [Annie 1998] Annie, I. A. and P. Colin (1998). The use of goals to surface requirements for evolving systems. Proceedings of the 20th international conference on Software engineering. Kyoto, Japan, IEEE Computer Society.

98 Referências [GRL 2008] GRL – Goal-Oriented Requirement Language Disponível em: [Anne 1993] D. Anne, L. Axel van, and F. Stephen, Goal-directed requirements acquisition. Sci. Comput. Program. 20 (1993) 3-50.