Your SlideShare is downloading. ×
0
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
06 Requisitos
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

06 Requisitos

213

Published on

Notas de aula, baseadas no Sommerville e no Schach.

Notas de aula, baseadas no Sommerville e no Schach.

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
213
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Engenharia de Requisitos Elicitação, detalhamento e documentação.
  • 2. O que é um projeto de sucesso? “Satisfaz seus clientes e patrocinadores com resultados que atendem seus objetivos dentro das restrições de tempo e custo, com produtos de qualidade, mantendo e promovendo relações harmoniosas entre os envolvidos e contribuindo pro aprendizado da organização.” Daniel Garnier
  • 3. “A parte mais difícil de construir um sistema de software é decidir precisamente o que construir. Nenhuma outra parte do trabalho conceitual é tão difícil quanto estabelecer os requisitos técnicos detalhados… Nenhuma outra parte danifica tanto o sistema resultante se for feita de forma errada. Nenhuma outra parte é mais difícil de retificar posteriormente.” Frederick Brooks
  • 4. Custo para se reparar um defeito
  • 5. Requisitos “Eu sei que você acredita que compreendeu o que eu disse, mas não estou certo de que o que você ouviu era realmente o que eu queria dizer!”
  • 6. Identificando requisitos  Requisito é a condição para se alcançar determinado fim (Dicionário Houaiss)  É a descrição dos serviços e das restrições de um sistema (Somerville)  Uma capacidade do software necessária ao usuário para resolver um problema para atingir um objetivo (Dorfman)
  • 7. Processo de requisitos do software
  • 8. O processo de elicitação e análise de requisitos
  • 9. Técnicas para análise de requisitos  Entrevista (reunião, call, estruturada ou não)  Questionários (modelos padrão ou personalizados)  Análise de formulários (automatização)  Câmeras de vídeo (dia a dia do usuário)  Cenários  Cartões de estórias  Árvores de decisão  Prototipação
  • 10. Classificação dos requisitos  Funcionais • Descrever a funcionalidade ou os serviços do sistema. • Depende do tipo de software, possíveis usuários e o tipo de sistema em que o software é usado. • Requisitos funcionais dos usuários podem ser declarações de alto nível a respeito do que o sistema deve fazer. • Requisitos funcionais do sistema devem descrever detalhadamente os serviços do sistema.  Não Funcionais
  • 11. Classificação dos requisitos  Funcionais  Não Funcionais • Esses requisitos definem as propriedades e as restrições do sistema por exemplo, confiabilidade, tempo de resposta e ocupação de área. • As restrições são capacidades de dispositivos de E/S, as representações do sistema, etc. • Os requisitos de processo também podem ser especificados impondo um IDE particular, linguagem de programação ou método de desenvolvimento. • Os requisitos não-funcionais podem ser mais críticos do que os requisitos funcionais. Se esses não forem atendidos, o sistema pode ser inútil.
  • 12. Classificação dos requisitos  De usuário  Declarações em linguagem natural com diagramas dos serviços que o sistema deverá fornecer e suas restrições operacionais. Escrito para os clientes.  De Sistema  Um documento estruturado estabelecendo descrições detalhadas das funções do sistema, serviços e restrições operacionais. Define o que deve ser implementado assim, pode ser parte de um contrato entre o cliente e o empreiteiro.
  • 13. Classificação dos requisitos
  • 14. Classificação dos requisitos  De usuário  De Sistema
  • 15. Classificação dos requisitos
  • 16. Características de bons requisitos  Não ambíguo  Verificável  Determinístico  Rastreável  Correto
  • 17. Não ambíguo  Ambiguidade = incerteza por causa da obscuridade ou indistinção  Escrever para outra pessoa ler  Problemas:  Uso de pronomes  “O sistema de RH deverá permitir somente cinco registros de dependentes válidos e tipos de planos de saúde; ele deve incluir o mais velho”  Acrônimos e siglas  Indeterminação  “O sistema deverá fazer as correções no registro quando possível”  Assumir conhecimento prévio Características de bons requisitos
  • 18. Verificável  Pode ser testado completamente de modo razoável (conforme a sua criticidade)  Assegurar que  Sistema funciona corretamente  As exceções são tratadas de forma adequada  Suporta vários conjuntos diferentes de dados  Exemplo:  “O sistema deve ser amigável” Características de bons requisitos
  • 19. Determinístico  Precisa necessariamente ser determinável – todos os caminhos devem ser previstos  “O sistema deve enviar novos registros aos sistema Financeiro a cada cinco minutos”  E se não tiver novos registros neste período? Características de bons requisitos
  • 20. Rastreável  De onde veio este requisito?  No que ele vai se transformar (ou já se transformou) no sistema?  Caminho do requisitante à implementação em duas vias  É muito importante quando  Um requisito é alterado  Um componente de software é alterado  Se negocia prioridades (ou cortes) Características de bons requisitos
  • 21. Correto  Consistência (um requisito não pode contradizer o outro)  Deve ser assegurada a acuracidade e a correção no texto do requisito  Não enrolar  Sentenças com começo, meio e fim Características de bons requisitos
  • 22. Atores no processo de requisitos  Clientes e usuários  Gerentes de negócios (áreas afetadas)  Gerente e líderes do projeto  Projetistas de software  Testadores
  • 23. Documentação de requisitos  O documento de requisitos de software é a declaração oficial do que é demandado dos desenvolvedores do sistema.  Deve incluir ambas, uma definição de requisitos do usuário e uma especificação de requisitos do sistema.  NÃO é um documento de projeto. Na medida do possível, deve definir O QUE o sistema deve fazer ao invés de COMO deve fazê-lo.  Documento de especificação de requisitos: o que o desenvolvedor precisa saber  Lembrar: documento de visão, glossário e requisitos se complementam
  • 24. Documentação de requisitos
  • 25. Documentação de requisitos  Padronização da sintaxe  Modelo de user histories  Modelo em linguagem natural  Modelo de casos de uso
  • 26. Estrutura do documento de requisitos
  • 27. Estrutura do documento de requisitos
  • 28. Formas de escrever uma especificação de requisitos de sistema
  • 29. Usuários do documento de requisitos
  • 30. Usuários do documento de requisitos
  • 31. Validação dos requisitos
  • 32. Revisão dos requisitos  Rever metas e objetivos estabelecidos para o sistema  Comparar requisitos metas o objetivos  Descrever o ambiente operacional  Examinar  interfaces  fluxo de informações  funções  Verificar omissões, imperfeições e inconsistências  Documentar riscos  Discutir sobre como o sistema será testado
  • 33. Desafios da fase de requisitos  Funcionários do cliente podem sentir-se intimidados/substituídos pelos computadores  Habilidade em negociação  Pouco tempo para as discussões mais profundas (essenciais)  Flexibilidade e objetividade são essenciais
  • 34. Gerenciamento de requisitos  Gerenciamento de requisitos é o processo de gerenciar os requisitos em constante mudança durante o processo de engenharia de requisitos e desenvolvimento de sistemas.  Após o sistemas começar a ser usado, surgem novos requisitos.  É preciso manter o controle das necessidades individuais e manter ligações entre os requisitos dependentes para que você possa avaliar o impacto das mudanças nos requisitos.  É necessário estabelecer um processo formal para fazer propostas de mudança e ligar essas aos requisitos de sistema.
  • 35. Mudanças nos requisitos  O ambiente técnico e de negócios do sistema sempre muda após a instalação.  Um novo hardware pode ser introduzido, pode ser necessário para a interface do sistema com outros sistemas, as prioridades do negócio podem mudar (com as consequentes alterações no sistema de apoio necessário) e, podem ser que o sistema deve, necessariamente, respeitar.  As pessoas que pagam por um sistema e os usuários desse sistema raramente são as mesmas pessoas.  Clientes do sistema impõem requisitos devido a restrições orçamentais e organizacionais. Esses podem entrar em conflito com os requisitos do usuário final e, após a entrega, pode ser necessário adicionar novos recursos para suporte ao usuário, caso o sistema seja para atender a seus objetivos.  Sistemas de grande porte costumam ter uma comunidade de usuários diversos, com muitos usuários tendo necessidades diferentes e prioridades que podem ser conflitantes ou contraditórias.  Os requisitos do sistema final são, inevitavelmente, um compromisso entre eles e, a experiência mostra que, muitas vezes se descobre que o balanço de apoio dado aos diferentes usuários precisa ser mudado.
  • 36. Planejamento de gerenciamento de requisitos  Estabelece o nível de detalhamento necessário para o gerenciamento de requisitos. Decisões do gerenciamento de requisitos:  Identificação de requisitos. Cada requisito deve ser identificado exclusivamente para que ele possa ser comparado com outros requisitos.  Processo de gerenciamento de mudanças. Esse é o conjunto de atividades que avaliam o impacto e o custo das mudanças. Esse processo é discutido em mais detalhes na seção seguinte.  Políticas de rastreabilidade. Essas políticas definem as relações entre cada requisito e entre os requisitos e o projeto do sistema que deve ser registrado.  Ferramentas de suporte. As ferramentas de suporte que podem ser usadas ​​variam desde sistemas especialistas, sistemas de gerenciamento de requisitos até planilhas e sistemas de banco de dados simples.
  • 37. Gerenciamento de mundança de requisitos  Decidir se uma mudança de requisitos deve ser aceita.  Análise de problema e especificação de mudanças  Durante essa fase, o problema ou a proposta de mudança é analisada para verificar se é válida. O feedback dessa análise é devolvido para o solicitante, que pode responder com uma proposta mais específica de mudança dos requisitos, ou decidir retirar o pedido.  Análise de mudanças e custos  O efeito da mudança proposta é avaliado por meio de informações de rastreabilidade e conhecimento geral dos requisitos do sistema. Uma vez que essa análise é concluída, toma-se a decisão de prosseguir ou não com a mudança de requisitos.  Implementação de mudanças  O documento de requisitos e, se necessário, o projeto e implementação do sistema, são modificados. Idealmente, o documento deve ser organizado de modo que as mudanças possam ser facilmente implementadas.
  • 38. Gerenciamento de mudança de requisitos
  • 39. AVISOS PAROQUIAIS São avisos fixados nas portas de uma igreja, todos eles reais, escritos com muito boa vontade e muito má redação.
  • 40. AVISOS AOS PAROQUIANOS Para todos os que tenham filhos e não o saibam, temos na paróquia uma área especial para crianças.
  • 41. AVISOS AOS PAROQUIANOS Prezadas senhoras, não esqueçam a próxima venda para beneficencia. É uma boa ocasião para se livrar das coisas inúteis que há na sua casa. Tragam os seus maridos!
  • 42. AVISOS AOS PAROQUIANOS O mês de novembro finalizará com uma missa cantada por todos os defuntos da paróquia.
  • 43. Checklist  Os requisitos:  Estão corretos?  São consistentes?  Estão completos?  São realistas?  Descrevem algo necessário para o cliente?  Podem ser verificados?  Podem ser rastreados?
  • 44. Relembrando
  • 45. Pontos importantes  Você pode usar uma variedade de técnicas para a elicitação de requisitos, incluindo entrevistas, cenários, casos de uso e etnografia.  A validação dos requisitos é o processo de verificação da validade, consistência, completude, realismo e verificabilidade dos requisitos.  Mudanças organizacionais e técnicas, e de negócios, inevitavelmente levam a mudanças nos requisitos de um sistema de software.  O gerenciamento dos requisitos é o processo de gerenciamento e controle dessas mudanças.
  • 46. Engenharia de Requisitos Elicitação, detalhamento e documentação.

×