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 para um sistema de biblioteca de soluções técnicas by Mind Map: Modelagem de requisitos para
um sistema de biblioteca de
soluções técnicas
0.0 stars - 0 reviews range from 0 to 5

Modelagem de requisitos para um sistema de biblioteca de soluções técnicas

OBERG, Roger; PROBASCO, Leslee ; ERICSSON, Maria. Applying requirements management with use cases. Rational Software White Paper, TP505, 2000. Disponível em: . Acesso em: 22 ago. 2009. ROBERTSON, Suzzane ; ROBERTSON, James. Mastering the Requirements Process. 2. ed. Harlow : Addison Wesley, 1999. 404p. ROBINSON, William N.; ELOFSON, Greg. Goal Directed Analysis with Use Cases, in Journal of Object Technology. Zurich, vol. 3, n. 5, may- june 2004, p. 125-142. SAMPAIO, Ana Lúcia de Sousa; PRIMO, Francisco Formoso; MARTINO, Wagner Roberto de. Visão geral do método. In: SIMPÓSIO INTERNACIONAL DE MELHORIA DE PROCESSOS DE SOFTWARE, 7 ., 2005, São Paulo. Método para definição de requisitos de software de um sistema a partir das necessidades dos seus stakeholders . Campinas: CenPRA , 2005, p. 3-10. SOMMERVILLE, Ian. Requisitos de software. In: Engenharia de software. 6. Ed. São Paulo: Addison Wesley, 2004. p. 81-99. ______. Processos de engenharia de requisitos. In: Engenharia de software. 6. Ed. São Paulo: Addison Wesley, 2004. p. 102-122. SPENCE, Ian; PROBASCO, Leslee . Traceability strategies for managing requirements with use cases. Rational Software White Paper, TP166, 2000. Disponível em: . Acesso em: 22 ago. 2009.

Requisitos

Conceitos e particularidades

Sentido geral: informações a descobrir antes de construir o software.

Sentido específico: algo que o produto fará ou qualidade desse produto., Tipo funcional: capacidade que o produto tem para realizar algo., Tipo não-funcional : qualidades ou propriedades que o produto detém.

Deve satisfazer as seguintes condições., Condicionar (restringir) comportamento de software., Ser descrito em valores monitorados pelo software., Restringir apenas valores controlados pelo software., Não enquadrar valores monitorados no futuro.

Pode ser derivado em Especificação., Relativo apenas às propriedades do sistema.

Descreve simultaneamente o ambiente e o sistema.

Método orientado a objetivos

ROBINSON e ELOFSON, 2004

Conceito de Objetivos

Deriva-se em Requisito.

Hierarquia por refinamento., Padrão disjunção (OU):, Alternativas para satisfação do objetivo., Padrão conjunção (E):, Detalha a descrição do objetivo., Marco., Casos.

Finalidade

Obter especificações UML usando objetivos., Benefícios, Abstração., Direção., Rastreabilidade., Análise.

Lista de atividades

Elicitar um contexto para o sistema.

Definir objetivos do sistema.

Derivar requisitos.

Derivar casos de uso.

Derivar modelos UML.

Modelagem com objetivos

ROBINSON e ELOFSON, 2004.

Relevância.

Usar objetivos para fornecer um alvo para a especificação mais detalhada de software.

Usar objetivos para:

- conciliar desejos do usuário à funcionalidade (operacional).

- refinar requisitos não-funcionais (propriedades).

- acompanhar o andamento de projetos.

- obter novos requisitos quando os objetivos não forem atingidos.

- associação às especificações de projeto

Com padrões:

- de Obtenção: que algumas propriedades nem sempre prevalecem.

- de Término: que algumas propriedades eventualmente não prevaleçam.

- de Manutenção: que alguma propriedade sempre prevaleça.

- de Não-Ocorrência: que algumas propriedades nunca ocorram.

Propriedade de domínio.

Existe naturalmente no ambiente. Independe de sistema de software.

Propriedade desejada do ambiente.

Fronteiras dos comportamentos

ROBINSON e ELOFSON, 2004.

.

Comportamentos ambientais: representados pelas propriedades do domínio.

Comportamentos implementáveis: são executados pelo sistema.

Comportamentos requeridos: estão na intersecção entre comportamentos ambientais e comportamentos implementáveis

Derivando Casos de Uso

Casos de Uso

Descrevem uma sequência de ações que  um sistema executa e que gera um resultado de valor para um determinado ator. (ROBINSON e ELOFSON, 2004)

Baseados em objetivos, Abstratos, Concretos

Tipos, De negócios, De tarefa, De baixo nível

Modelagem, Reduz complexidade dos métodos O.O., Deve ser conjugado com técnicas tradicionais de captura dos requisitos, Fornece um processo de gerenciamento aceitável para todas as partes interessadas no projeto., Estratégia, Particionar o sistema em pequenas unidades baseadas na visão dos usuários., Reduz complexidade

Ferramentas disponíveis

Aplicação:

Uso de instrumentos de captura e análise.

Modalidades:

ROBINSON e ELOFSON, 2004; ROBERTSON, 1999.

Entrevistas.

Questionários.

Sessões de brainstorming.

Prototipação.

Instrumentos de análise com tabelas e listas de verificação.

Mapas mentais.

Contextualização

Problema: a especificação de requisitos realizada nos ambientes de desenvolvimento é feita de maneira informal e artesanalmente.

SAMPAIO; PRIMO; MARTINO, 2003.

Hipótese: situação pode estar relacionada à má gestão ou à complexidade dos problemas.

SOMMERVILLE, 2004; SAMPAIO; PRIMO; MARTINO, 2003

Os problemas a serem enfrentados pela engenharia de software são imensamente complexos.

Compreender a natureza de cada problema é tarefa difícil, principalmente em sistemas novos.

Solução:

Oberg, Probasco e Ericsson (2000).

Desenvolver habilidades-chave:, Analisar o problema., Entender as necessidades dos envolvidos., Definir o sistema., Gerenciar o escopo do sistema., Refinar a definição do sistema