apresentação sobre volere

Volere Requirements Specification

Maio/2012

UNIVERSIDADE SANTA CECILIA

VOLERE Especificações de Requisitos

Volere é um verbo italiano que significa querer, desejar.

É um termo apropriado para explicar o que vem a ser um requisito: é a condição necessária para se obter o que se quer e alcançar um objetivo.

Introdução

Volere é uma metodologia desenvolvida por James e Suzanne Robertson ao longo de 30 anos de experiência, pesquisas e prática em Engenharia de Requisitos.

O Modelo é um guia que descreve um processo genérico e estruturado que auxilia o Analista a descobrir e escrever os requisitos para sistemas aplicativos de computadores em uma gama variada de domínios.

Sua primeira edição foi lançada em 1995.

Atla

ntic S

yste

ms

Guild

Fundadores da Associação Atlântica de Sistemas Fonte: TASG, 2010

O objetivo do Volere é proporcionar estrutura e orientação para atingir o equíbrio adequado de cada projeto.

Estrutura de Conhecimento de Requisitos    Requisitos dos Processo de Stakeholders Requisitos

Fonte: VOLERE, 2008

Modelo VolereImpulsionadores do projeto

1. A Finalidade do Produto2. Cliente e outras partes interessadas3. Usuários do ProdutoRestrições do projeto4. Restrições Obrigatórios5. Convenções de nomenclatura e definições6. Fatos Relevantes e PressupostosRequisitos Funcionais7. O escopo do trabalho8. O escopo do produto9. Requisitos funcionais e de dadosRequisitos Não Funcionais10. Requisitos Look and Feel 11. Requisitos de Usabilidade12. Requisitos de desempenho13. Requisitos Operacionais14. Requisitos Manutenibilidade e

Portabilidade15. Requisitos de segurança16. Requisitos Culturais e Políticos17. Requisitos LegaisProblemas do projeto18. Questões em aberto19. Off-the-shelf Solutions (“fora prateleira”)20. Novos Problemas21. Tarefas22. Cutover – migração p/ novos produtos23. Riscos24. Custos25. Documentação do Usuário e Treinamento26. Sala de Espera27. Ideias para Soluções

Conexões entre os Casos de Uso do Produto, Casos de Uso do Negócio e

Eventos do Negócio

Evento de negócio acontece

Limite do Produto

Limite do Trabalho

Caso de Uso do do Produto

Caso de Uso do Negócio

Fonte: VOLERE, 2010

Cartão de neve

Fonte: VOLERE, 2010

Formulário de Requisitos para descrever cada mínima exigência de

um Requisito Funcional ou Não Funcional

Caso de Uso do Produto

Fonte: ROBERTSON, 2010

Requisito #: No. sequencial Tipo de Requisito: Tipo de Padrão Evento /BUC/PUC #:  Descrição: Declaração única do significado do Requisito

  Razão: Justificativa do Requisito

  Origem: Quem abordou este Requisito?

Critério de ajuste: Uma medida do Requisito de maneira que seja possível

testar se a solução se enquadra nele

  Satisfação do Cliente: Insatisfação do Cliente: Dependências: Uma lista de outros Requisitos que Conflitos: Outros Requisitos que

tenham alguma dependência deste não podem ser implementados Materiais de Apoio: Índice de documentos que

Ilustrem e expliquem o requisito Histórico: Criação, mudanças

exclusão, etc.

Lista de Eventos/Casos de Uso que necessitam desse Requisito

Grau de satisfação do interessado se esse requisito for implementadoEscala de 1 = desinteressado a 5 = extremamente satisfeito

Medida de insatisfação do interessado se esse requisito não Fizer parte do produto final. Escala 1 = muito importante a 5 = extremamente insatisfeito

Requisito #: 1 Tipo de Requisito: 9 Evento /BUC/PUC #: 2  Descrição: O sistema define e propõe um ou mais horários para estudante  Razão: Para ajudar os alunos a selecionar seus cursos  Origem: TI, nós e os alunos Critério de ajuste: O sistema fornece o reconhecimento dos cursos já efetuados pelo usuário e

cursos futuros que serão necessários para completar a sua exigência. Também propõem para o semestre

que se inicia os cursos que satisfaçam os pré-requisitos .  Satisfação do Cliente: 4 Insatisfação do Cliente: 3 Dependências: O aluno receber indicação do orientador Conflitos: Nenhum

Materiais de Apoio: Relatório de reunião de Ryan com TI Histórico: 25/04/2012

Tipos de Requisitos

Sistema de Câmara Fotográfica

Requisito

Consciente

Eu quero a câmara

caiba na minha bolsa

Eu quero que a

bateria da câmara

dure mais

Eu quero que a câmara

tire fotos digitais

Requisito

Inconsciente

Acontece quando o indivíduo sabe muito sobre o assunto e faz suposições

que todos têm o mesmo conhecimento então não articula uma

determinada exigência. (exemplo: rebobinamento automático do filme)

Requisito

Inimaginável

Uma idéia que se acredita ser possível mas que é improvável que ele

mencione: Gostaria que a câmara fosse à prova d’água mas não é possível

dentro do orçamento.

Fonte: SYSTEMGUILD, 2010

Exemplo dos diferentes tipos de Requisitos

Sistema Objetivos do Projeto

Requisito Funcional

Requisito Não Funcional

Restrições

Jardinagem Aumentar a colheita de legumes em 50%

Adubar as Plantas

Conveniência do jardineiro Adubar as Plantas

O Sistema de jardinagem deve usar apenas produtos orgânicos

Aeroporto Acomodar 20% a mais de passageiros

Registrar a hora de pouso de um voo

Quem tem permissão para olhar as informações sobre os voos

O novo aeroporto deve estar operacional dentro de 1 ano

Engarrafamento Reduzir o número de produtos defeituosos

Encher as garrafas

Velocidade que o sistema tem que encher as garrafas

Sistema tem orçamento de 1 milhão de Euros

Fonte: SYSTEMGUILD , 2010

Técnicas de Arrasto

Técnicas descrição

abstração Generalizações úteis

aprendiz Aprendiz observa o mestre

brainstorming Grupo gerando idéias

Mind mapping Notas amplas e significativas

entrevistas Técnica comum e eficaz

Soft systems Abordagem CATWOE – client/actors/ transformation/world/owner/environment

Workshops Oficinas de Casos de Uso

Os d

ifere

nte

s T

ipos d

e

Req

uis

itos e

su

as

ligações

Fonte: TASG, 2010

Requisitos FuncionaisO escopo do trabalho

A Situação AtualEsta é uma análise dos processos existentes no negócio.

MotivaçãoSe o projeto pretende realizar modificações em um sistema manual ouautomatizado, você precisa entender o efeito das mudanças propostas.

Requisitos FuncionaisO contexto do trabalho

O Contexto do TrabalhoO diagrama de contexto do trabalho identifica suas fronteiras, as quaisvocê precisa investigar, para ser capaz de construir o produto

MotivaçãoDefinir com clareza a fronteira para o estudo do trabalho e aumentar oempenho dos requisitos.

Exemplo IceBreaker

Requisitos Funcionais Divisão do Trabalho

Divisão do TrabalhoUma lista exibindo todos os eventos do negócio ao quais o trabalhoCorresponde

MotivaçãoIdentificar aglomerados lógicos do sistema que possam ser utilizadoscomo base para descobrir requisitos detalhados

Exemplo IceBreaker

Requisitos FuncionaisModelo dos Dados

Divisão do TrabalhoUma especificação de temas importantes, objetos do negócio,entidades, e membros que sejam relevantes ao produto.

MotivaçãoEsclarecer a importância do elemento principal do sistema,consequentemente, incitando o reconhecimento dos requisitos aindanão considerados

Exemplo IceBreaker

Requisitos FuncionaisDicionário dos Dados

Dicionário dos DadosO dicionário dos dados especifica o conteúdo de:• Classes no modelo dos dados• Atributos das classes• Relações entre as classes• Entradas e Saídas em todos os modelos• Elementos dos dados dentro das Entradas e Saídas

MotivaçãoO diagrama de contexto fornece uma definição precisa do escopo dotrabalho em estudo ou do produto a ser construído

Exemplo IceBreaker

Requisitos FuncionaisFronteiras do Produto

Fronteiras do ProdutoUm diagrama de caso de uso identifica as fronteiras entre os usuários(atuadores) e o produto.

Requisitos FuncionaisRequisitos Funcionais e dos Dados

Requisitos Funcionais e dos DadosUma especificação para cada requisito funcional. Como feito com todosos seus tipos, utilize a ficha de requisitos.

MotivaçãoApresentar os requisitos funcionais, detalhados, oferecidos peloproduto.

Requisitos Não Funcionais

Requisitos de Aparência e SensaçõesRequisitos de Usabilidade e HumanidadeRequisitos de DesempenhoRequisitos Operacionais e AmbientaisRequisitos de Mantenabilidade e SuporteRequisitos de SegurançaRequisitos Culturais e PolíticosRequisitos Legais

Bib

liog

rafi

aJAMA BLOG . Aproveite o seu gênio coletivo. Entrevista com James e Suzanne Robertson. 2009. Disponível em< http://blog.jamasoftware.com/2009/03/23/requirements-management-qa-an-interview-with-james-and-suzanne-robertson/ > Acesso em 10.abr.2012

REQUIREMENTS TRAWLING - Techniques for discovering Requirements. TASG. London, 2010. Disponível em < http://www.systemsguild.com/requirementstrawling.htm> Acesso em 13.04.2012

ROBERTSON S., J. Robertson. Dominar o Processo de Requisitos. ACM Press / Addison-Wesley Publ. Co., New York, NY, 1999. Disponível em < http://www.amazon.co.uk/Mastering-Requirements-Process-Suzanne-Robertson/dp/0321419499 > Acesso em 17.mar.2012  

Bib

liog

rafi

aROBERTSON S., J.Robertson. Volere Requirements Technics –An Overview. The Atlantic System Guild. UK, 2008. Disponível em <http://www.volere.co.uk/pdf%20files/01%20Volere%20Overview.pdf> Acesso em 17.mar.2012

ROBERTSON S., J. Robertson.. Volere Requirements - How to Get Started. The Atlantic System Guild. UK, 2010.disponível em < http://www.volere.co.uk/pdf%20files/VolereGettingStarted.pdf> Acesso em 18.mar.2012

THE ATLANTIC SYSTENS GUILD . Cursos . 2010. Disponível em < http://www.systemsguild.com/about.htm> Acesso em 18.mar.2012 

Bib

liog

rafi

aVOLERE REQUIREMENTS RESOURCES. Volere Requirements Specification. 2010 . Disponível em < http://www.volere.co.uk/template.htm. Acesso em 17.mar.2012  

Muito Obrigado!

Bruno Santos SilveiraDomênica B. Martinez