Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Modelagem de Requisitos by Mind Map: Modelagem de Requisitos
0.0 stars - reviews range from 0 to 5

Modelagem de Requisitos

Modelagem

Cockburn preve cinco possibilidades para o uso de objetivos.

Requisitos não funcionais

atribuição de requisitos não funcionais a objetivos.

Acompanhar projetos

Acompanhamento de projetos pelos objetivos.

Requisitos diferentes

Obtenção de requisitos difrentes apartir do não alcance dos objetivos.

Acossiados a Design

Utilização de objetivos acossiados a design de suas realizações.

Casar objetivos do usuário

Casar objetivos do usuário com conceitos operacionais.

Método

Definimos  um método para obter especificações com UML a partir de objetivos. O método é uma síntese dos  métodos comuns com UML, tais como o Rational Unified Process [Kruchten 2000], e os métodos de análise de requisitos orientados a objetivos, tais como KAOS [Dardenne 1993]. O método consiste em cinco atividades:

Eliciar

O contexto do sistema. Informações sobre o sistema proposto, e de seu contexto, são adquiridos por meio de entrevistas, coleta de documentos, observação, etc

Definir Objetivos

Baseado no contexto do sistema,  um analista define os objetivos do sistema

Derivar Casos de uso

Casos de uso organizacionais, de sistema e de baixo nível  são derivados a partir dos requisitos.

Derivar modelos UML

Outros modelos UML, tais diagramas de classe e seqüência, são derivados dos requisitos  ou casos de uso.

Descrição de Sistemas de software

A partir de simples observações podemos caracterizar quatro definições fundamentais, de sistemas de software.

Propriedade

Objetivo pode ser uma propriedade desejada no sistema. Ex: Após o elevador chegar no andar solicidade o mesmo deve abrir a porta.

Propriedade de domínio

É uma propriedade que existe naturalmente no sistema, independente de qualquer software.  

Requisito

É um tipo especial de objetivo que condicona ou restringe o comportamento do software.

Especificação

Tipo especial de requisito que somente tem haver com as propriedades do sistema.

Objetivos

Uma visão mais detalhada de obejtivos pode ser apresentada em quatro patterns; Objetivos estimulam a elaboração de requisitos sendo a sua base.

Obtenção

Requerem que algumas propriedades nem sempre prevalençam. Ex: Após a entrega do pedido deve ser enviada a fatura ao cliente.

Término

Requerem que algumas propriedade não prevaleçam. Ex: Após o encerramento do débito em conta encerrar a cobrança.

Manutenção

Requerem que alguma propriedade prevaleça. Ex: sempre registrar o nível atual de estoque para todos os produtos existentes.

Não ocorrência

Requer que alguma propriedade nunca ocorra.Ex: Um usuário não autorizado nunca pode acessar qualquer conta.

Objetivos com modelos UML

Adicionar objetivos aos modelos uml pode trazer objetivos como:

Abstração

De acordo com van Lamsweerde(2001) objetivos proporcionam descrição de alto nível, funcionais e não funcionais, descrição, compreensíveis do "o que" o sistema deve fazer, sem a complexidade de descrever o funcionamento do sistema.

Direção

Objetivos criam um checklist de atividades a completar.

Rastreabilidade

Objetivos fornecem uma ponte ligando os pedidos dos stackholders às especificações do sistema.

Análise

Objetivos fornecem um meio para análisar o sistema antes da sua construção. Essa análise é importante pois inclui análise de conflitos.

Definir objetivos e Requisitos

Os objetivos podem ser obtidos de duas maneiras:

Explícitas

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

Implícitas

Devem ser eliciados.

Porque?

Como?

Patterns de Refinamento

Marco

Baseado em casos

Casos de Uso

"Descreve uma seqüência de ações que  um sistema executa que gera um resultado de valor para um determinado ator" -p.491 [LEFFINGWELL 2000]. Casos de uso  podem descrever um sistema em diferentes níveis de abstração [Regnell 1996]. Reconhecemos três tipos comuns de casos de uso, com base em seus atores e no uso de declarações de especificação [Cockburn 1997, Larman 2001]: Consideramos que casos de uso  baseados em declarações de objetivos são abstratos, e  casos de uso baseados em requisitos e especificações  são concretos.

Sub-objetivos

Então um caso de uso abstrato pode ser definido com os sub-objetivos como passos.

Sub-requisitos

Tipo de Caso de Uso

Casos de uso de tarefa

Casos de uso de baixo nível

Casos de uso de negócios

Requisito folha

Então um caso de uso de baixo nível pode ser definido usando declarações de especificação.