Modelagem de Requisitos baseada em Objetivos com a utilização de Casos de Uso

Esta tarefa é possível na medida que objetivos e requisitos adquiri níveis.

Os objetivos vem atenuar dificuldades encontradas por analistas e usuários com uso de casos de uso.

Existem outras técnicas como histórias de usuários simples e formais, mas que podem trazer problemas.

A modelagerm de requisitos baseada em processos de negócios está tendo uma grande aceitação atualmente, na medida que dispomos atualmente de sistemas de gerência de processos de negócio, com arquiteturas orientadas para serviços.

Tipos de Objetivos:

De Alcance : requer que alguma propriedade eventualmente ocorra;

De Término : requer que alguma propriedade eventualmente cesse;

De Manutenção : requer que alguma propriedade sempre ocorra.

Objetivos (requisitos):

Funcionais – serviços a serem promovidos.

Não Funcionais – qualidade do serviço.

Nivéis:

Estratégico – alto nível (intenções).

Detalhe – baixo nível (Operacional).

Usuário – nível mais importante.

Componentes de um Sistema

Ativos – pessoas, dispositivos, outros sistemas => agente (ator é um agente externo).

Ex.: usuário – agente externo

módulo – agente interno

Objetivos – são + abrangentes -> envolvem muitos agentes num maior tempo.

Requisitos – são mais específicos -> envolve um agente em menos tempo. Possue múltiplas realizações.

Importância dos Objetivos na Engenharia de Requisitos

• Permite a obtenção completa dos requisitos: critério de completude;

• Evita a definição de requisitos irrelevantes: critério de pertinência;

• Permite a explicação dos requisitos aos stackholders do sistema;

• O seu detalhamento provê um mecanismo natural para a estruturação dos documentos de requisitos complexos, facilitando a sua leitura;

• O seu detalhamento favorece a escolha entre opções alternativas, a localização de conflitos, facilitando a negociação entre os envolvidos.

Opções de ser achar os requisitos:

Explícitas ( conhecimento explícito ) – Os stackholders do sistema definem

documentos da organização, lista de problemas e deficiências do sistema atual.

Implícitas ( conhecimento tácito ) – devem ser eliciados, levantados.

Técnicas

Envolvimento com stackholders do sistema.

Técnicas de eliciação de objetivos / requisitos ( entrevistas, workgroups, elaboração, de modelos )

Por refinamento e abstração

Uma vez identificado um objetivos, faz-se perguntas :

POR QUE ? – acha objetivos de nível superior.

Tendo um objetivo é possível agrupá-lo com outros de mesmo nível, chegando a um nível superior.

COMO ? – acha objetivos de nível inferior.

Ajuda detalhar o objetivo em sub-objetivos de nível mais baixo.

Os requisitos são derivados dos objetivos por refinamento.

Perguntas básicas que devem ser feitas ao usarmos as técnicas para eliciação de objetivos.

Modelagem de objetivos é necessária quando o sistema tem mais de 25 objetivos, daí se faz a estruturação de objetivos pelo gráfico hierárquico ( com metodologia KAOS (Knowledge Acquisition in automated specification)), através de ferramenta Objectiver ou senão por threads ferramenta RequisitePro.

A partir de um modelo hierárquico de objetivos, utiliza-se uma linguagem própria (símbolos gráficos), chegando de forma automática aos casos de uso. Usa técnicas mais avançadas para análise e consistência dos requisitos (uso de lógica matemática, o que é importante no caso de sistemas que não podem falhar).

Dispõe também de padrões (patterns) genéricos de requisitos, que podem ser usados como base para o início da modelagem, em função do tipo de sistema existente.

Para a ferramenta Objectiver temos:

Objetivos (retângulo azul inclinado)

Refinamento (bolinha com setas amarelas)

Requisito (diferente de objetivo, retângulo inclinado azul com moldura)

Agentes externos ou internos (losângulo)

Relação de Responsabilidade (bolinha e seta vermelhas)

Assinalamento (bolinha e seta rosas)

Ator do Sistema

Temos um ator quando o mesmo é percebido e controlado pelo sistema.

Atores – interno (parte do sistema)

– externo (parte do ambiente)

Ator: o ator ajuda o sistema a alcançar seus objetivos.

Agente de Sistema (Interno) – temos um requisito

Agente do ambiente (Externo) – uma expectativa é assinalada por vários agentes.

Técnica KAOS – Conceitos

Responsabilidade

Assinalamento

As ferramentas para modelagem de requisitos tem sua linguagem própria, sendo que a UML não tem padrões para se trabalhar de forma completa com objetivos ou requisitos, dispõe somente do diagrama de casos de uso, que ajuda mais na organizações dos requisitos já existentes e não na sua obtenção e melhor definição dos mesmos.

Engenharia de Requisitos – gerência de requisitos

Uma vez desenvolvido um objetivo e seus requisitos, em colaboração estreita com os seus envolvidos, é necessária acompanhar a sua vida, no decorrer do desenvolvimento do sistema e mesmo após, durante a operação do mesmo.

As especificações de objetivos permitem:

Elaborar

Verificação/Validar

Gerênciar Conflitos de requisitos

Negociar

Explanar

Evoluir

Métodos utilizados no desenvolvimento de objetivos e seus requisitos.

Métodos informais: Definição simples através somente do nome do objetivo

Métodos semi-formais: Definição de seus tipos, atributos e relacionamentos.

Utiliza: palavras chave com semântica pré-definida e modelos visuais

Métodos formais: Utilização de lógica matemática.

Casos de Uso – UML (Visão comportamental e abstrata do sistema)

Os casos de uso são utilizados sobre diferentes enfoques e propósitos, dependendo das técnicas e ferramentas em uso. Muitas vezes são utilizados sem a base conceitual necessária, o que confunde os seus leitores, justificando muitas vezes a sua utilização.

Um método semi-formal que permite captar, definir e organizar requisitos. De uma forma consistente e estruturada definindo os seus diversos cenários a partir de uma hierarquia de objetivos.

Modelo de Comunicação e Interação

Agentes comunicam-se entre si através de interação

Um agente pode ser uma pessoa, um software, um computador, o próprio sistema pode ser visto como um agente.

Agente Externo (parte do ambiente)

Agente Interno (para do sistema)

Agente primário é aquele que para alcançar seus objetivos necessita da assistência do sistema.

Agente secundário é aquele do qual o sistema necessita de assistência para satisfazer seu objetivo.

Um exemplo: Site da Amazon

Agente Primário (externo) – comprador

Sistema em Desenvolvimento (Interno) – Site da Amazon

Agente Secundário (Externo) – Sistema de Cartão de Crédito X

A dinâmica da interação entre os agentes de um sistema.

Ator é sempre um agente externo.

Agente – possui um conjunto de responsabilidades. Para assumir estas, ele necessita de alguns objetivos, para alcançar tais objetivos realiza uma ação (evento). Esta dispara uma ação com outro agente.

Neste momento o agente começa a agir através de hierarquia de objetivos e ações.

Fluxo de Interações

Interação Simples – remessa de uma única mensagem.

Interação Composta – constitui de uma seqüência de interações, podendo ter ou não ramificações (fluxo principal e alternativo), tal seqüência constitui-se num cenário

Uma interação pode ocorrer através de mais de um cenário (interação composta de um conjunto de cenários, cada um desses cenários descreve os caminhos (fluxos) que você deve cursar para alcançar um dos sub-objetivos existentes) ).

Cenário

Seqüência de interações que acontecem sob certas condições, para que seja alcançado um objetivo do agente primário, e com a qual se obtém um resultado específico ( total ou parcial ) em relação a esse objetivo

Existem duas opções para descrever um caso de uso:

Descrição Geral: através de seu titulo, que normalmente representa o objetivo do caso de uso

Descrição detalhada: o fluxo dos passos ou interações entre um agente externo e o sistema (que será o cenário do caso de uso).

Definição de casos de uso

Cenário são as instâncias (as realizações) de um caso de uso, usado para mostrar um caso de uso em detalhes.

Coleção de Cenários.

A UML tem um símbolo para representar cada caso de uso (a elipse).

O resultado de um cenário é um objetivo (sub-objetivo) alcançado ou abandonado.

Uma das visões importantes para se descrever um sistema corresponde ao levantamento de todos os cenários que podem ocorrer em todas as interações (visão de caso de uso do sistema).

Em síntese: Uma coleção de possíveis cenários que ocorrem envolvendo o sistema e o agente externo ( ator ), caracterizada pelo objetivo do agente primário.

A descrição de um caso de uso mostrar como um objetivo do agente externo ( ator) pode ser alcançado ou falhar. Sua descrição é composta de:

Atores: Primário ou Secundário

Objetivo Geral

Pré – condição

Cenários Usados

Pós – condição

Um cenário pode ser:

Separado de acordo com condições encontradas.

Agrupados se eles tiverem o mesmo objetivo.

Obs.: Um caso de uso mais complexos pode ser divididos em casos de uso mais simples (através de seus cenários) usando os relacionamentos descritos entre o caso de uso pai (geral) e seus filhos (detalhes).

Técnicas disponíveis para organização de Casos de Uso

Generalização / Especialização

Extensão

Inclusão

Descrição de Casos de Uso através de abstração

Nível é definido em função da etapa do processo de desenvolvimento do sistema.

Chega-se a um caso de uso de certo nível a partir do levantamento do conjunto de objetivos definidos a esse nível.

ABSTRATO } Objetivos

CONCRETO } Requisitos e Especificações

Tipos de Casos de Uso

Estratégico – de negócio

• Define o ambiente do sistema;

• Inclui atores de múltiplas organizações (pessoas, sistemas);

• Voltado para a organização;

• Inclui objetivos estratégicos.

De Usuário – tarefa

• Especifica, explicita as tarefas do usuário na interação com o sistema;

• Envolve atores de uma única organização;

• Voltado para as tarefas do usuário;

• Incluem objetivos / requisitos de usuário.

De Detalhe – operacional

• Decompõe ou detalha o diálogo do usuário com o sistema;

• Voltado para as interfaces do sistema;

• Incluem requisitos/especificações de detalhe.

Um objetivo (estratégico no caso) pode ser definido por um conjunto de sub-objetivos.

À medida que se aprofunda nesse detalhamento (perguntando: como?) vamos chegando mais próximo de requisitos e especificações (envolvendo-nos com os detalhes relativos às tecnologias).

Obs.:

Os casos de uso devem ser derivados a partir dos Objetivos / Requisitos do Ator.

Os objetivos do Sistema devem ser derivados de forma a serem compatíveis com os objetivos / requisitos do ator.

Nos diversos momentos do desenvolvimento de um sistema precisaremos de casos de uso com visões ou níveis diferentes.

Os OBJETIVOS tendem a ser mais ABSTRATOS. A visão abstrata parte do usário.

As ESPECIFICAÇÕES são mais CONCRETAS.

REQUISITOS compatibilizam essas DUAS VISÕES.

Descrição de um caso de uso abstrato e de nível de usuário.

Usam-se objetivos e não requisitos, que representam as ações do usuário e as respostas (interação) do sistema.

Não existe nenhuma descrição dos tipos de tecnologia a serem usados, temos somente intenções.

Descrição de um caso de uso concreto e de nível de usuário.

Para a visão ser concreta deve incluir requisitos ou especificações.

Deve mostrar as ações dos usuários interagindo com os diversos tipos de interfaces do sistema.

A cada ação do usuário (requisito do ator) existe uma ação correspondente do sistema (requisito do sistema).

Escopo do Sistema

Define o que será projetado ou não. Define o espaço que será envolvido pelo sistema. Este pode ser:

Escopo Funcional : serviços que o sistema oferecerá.

Modelo de objetivos

Lista de Atores – Objetivos

Descrição de casos de uso

Escopo de Projeto (Design).

Corporação

Sistema

Subsistema

O caso de uso pode ser usado para definir o escopo de um sistema.

Escopo de corporação

Escopo mais amplo. No desenvolvimento serão incluídos os processos manuais (não automatizados).

Significa que serão envolvidos aspectos da organização (atividades manuais), além do hardware/software a desenvolver, para se alcançar os objetivos do ator principal.

Escopo de Sistema

Escopo incluirá somente os processos automatizados ou que terão apoio de informações digitais. O hardware ou o software que será desenvolvido.

Escopo de Sub-sistemas

Escopo mais específico, o desenvolvimento abrangerá somente uma parte de um sistema maior já existente.

Levando em consideração somente um componente do sistema.

Objetivos estratégicos e seus casos de uso, normalmente abrangem a organização como um todo e o escopo tenderá ser mais amplo, o sistema tende a incluir partes manuais e automatizadas.

Quando se trabalha com casos de uso de detalhe a tendência é o sistema ser mais específico, ser um sub-sistema de um sistema maior já existente.

Dificuldades na modelagem de Requisitos

Envolvimento com stackholders;

Escopo do trabalho (organização, sistema, componente);

Abstração x Concretude;

Nível do requisito (caso de uso);

Responsabilidades do ator e do sistema;

Possíveis exceções existentes;

Nível do processo de gestão dos requisitos existente (RMM).

ance : requer que alguma propriedade eventualmente ocorra