View
93
Download
0
Category
Preview:
Citation preview
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
Recommended