Your SlideShare is downloading. ×
0
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-requisitos
engenharia-de-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

engenharia-de-requisitos

3,560

Published on

Introdução à engenharia de requisitos.

Introdução à engenharia de requisitos.

Published in: Technology, Business
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,560
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
351
Comments
0
Likes
5
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
  • CUMPRIMENTAR, AGRADECER CONVIDADOS VÔO PANORÂMICO X DETALHES CÉLERE O QUE O SOFTWARE FARÁ?
  • CONFUSÃO GARANTIDA SOFTWARE NÃO EXISTE NO VÁCUO OBJETIVO É O MESMO
  • ÊNFASE NA COMPUTAÇÃO DESCONHEÇO AS DEMAIS ÁREAS
  • SE NÃO CONHECEMOS AS NECESSIDADES DO CLIENTE, ENTÃO NÃO PODEMOS PROPOR UMA SOLUÇÃO
  • TODOS CLIENTES PROJETISTAS
  • NÃO É DIFÍCIL DEFINIR ATRIBUTOS, MAS OBTÊ-LOS OBJETIVO DA ER: MELHORAR A PONTARIA DO NOSSO ARQUEIRO
  • NÃO ESTÁ ADEQUADAMENTE ARMADO
  • VOLUME EUA X EUROPA BRASIL?
  • TAREFA FÁCIL CONTUNDÊNCIA DE ALGUNS LIÇÃO: REUNIR COM O CLIENTE, PERGUNTAR O QUE ELE DESEJA, REGISTRAR, ENTREGAR PARA A EQUIPE DE DESENVOLVIMENTO, QUE USA TECNOLOGIA NÃO DISPONÍVEL 2 ANOS ATRÁS E IMPLANTAR, PARA MUITOS, NÃO FUNCIONA.
  • DUAS PALESTRAS QUE SUCEDEM ESCLARECEM ESTE DIAGRAMA. EU NÃO ESQUECI E TALVEZ VCS NÃO ESQUEÇÃM: NICOLAU MAQUIAVEL, EM “O PRÍNCIPE” ESCREVEU ACERCA DAS DOENÇAS TÍSICAS: NO INÍCIO É DIFÍCIL DIAGNOSTICAR, MAS FÁCIL DE CURAR, COM O TEMPO, FÁCIL DE DIAGNOSTICAR E DIFÍCIL DE CURAR.
  • CONTA A HISTÓRIA QUE O MAUSOLÉU MAIS BONITO DO PLANETA É FRUTO DO AMOR DE UM GRANDE GUERREIRO PELA SUA MULHER. FÁBULA É INVENÇÃO MINHA: ESTE GUERREIRO TEVE QUE CONTAR COM ALGUÉM QUE CONSTRUI O MAUSOLÉU, OU SEJA, SUAS IDÉIAS TIVERAM QUE SAIR DA MENTE DELE E, DE FORMA FORMAL OU NÃO, SER TRANSFERIDA PARA A DE OUTRAS PESSOAS. ENTRE ELES, UM MODELO. NESTA FÁBULA, ELE IMAGINOU ASSIM O MAUSOLÉU, QUE FOI ASSIM INTERPRETADO PELA CONSTRUTORA DA ÉPOCA E FOI ASSIM REALIZADO. ESTA É UMA FÁBULA QUE SERVE COMO METÁFORA DE SUCESSO PARA ER.
  • OBSERVEM ESTA CHARGE. NÃO HÁ O QUE EXPLICAR. FALA DE UMA DAS DIFICULDADES IDENTIFICADAS ANTERIORMENTE: COMUNICAÇÃO.
  • SEM FÁBULAS E METÁFORAS, O QUE É COMUM? Duas perguntas terríveis que eu já ouvi! Elas me ferem profundamente! É a perplexidade total, de ambas as partes. Já ouvi alguém me perguntar “O que é isso?”, depois de três meses de desenvolvimento. COMO MUDAR O CENÁRIO?
  • EXECUTADAS DE FORMA ITERATIVA, INTERCALADA COM OUTRAS ATIVIDADES E PODE SE ESTENDER POR PRATICAMENTE TODO O CICLO DE DESENVOLVIMENTO DO SOFTWRE.
  • Se não elicio não há o que modelar. Se não modelo, não tenho o que validar. Se não valido, o usuário não estará satisfeito. Se não gerencio, as mudanças, que necessariamente ocorrem, instauram o caos. Gerenciar requisitos é crucial. Neste aspecto, rastreabilidade é a palavra forte. OU VOCÊ CONTROLA AS MUDANÇAS OU ELAS CONTROLAM VOCÊ.
  • REQUISITOS NÃO SÃO OBTIDOS COM EXTRATIVISMO. ELES NÃO ESTÃO À DISPOSIÇÃO. QUANDO OBTIDOS DOS USUÁRIOS, IN NATURA, QUASE SEMPRE PRECISAM SER PROCESSADOS.
  • REQUISITOS NÃO SÃO OBTIDOS COM EXTRATIVISMO. ELES NÃO ESTÃO À DISPOSIÇÃO. QUANDO OBTIDOS DOS USUÁRIOS, IN NATURA, QUASE SEMPRE PRECISAM SER PROCESSADOS.
  • NÃO VOU FORNECER DETALHES, JULIANO FARÁ ISSO. AQUI É IMPORTANTE RESSALTAR O QUE ELE IRÁ FALAR LÁ: NÃO EXISTE “UMA TÉCNICA”, “UM MÉTODO”, “UM ...”, QUE RESOLVA OS PROBLEMAS. CADA CASO EXIGE SER CONSIDERADO ISOLADAMENTE.
  • FALA-SE MUITO EM VÁRIAS ABORDAGENS, CONTUDO, LINGUAGEM NATURAL É PREDOMINANTEMENTE O PRINCIPAL MECANISMO DE REGISTRO. ANÁLISE ORIENTADA A OBJETOS. PARTICULARMENTE, QUANDO ALGUÉM DIZ QUE ESTÁ FAZENDO USO DE AOO PARA REGISTRO DE REQUISITOS, EM TODOS OS CASOS QUE CONHEÇO, EMPREGA UMA OUTRA FORMA PARA COMUNICAÇÃO COM O USUÁRIO E GUARDA OS ARTEFATOS OO PARA USO INTERNO. ENTENDO QUE AOO É ÚTIL À ER ENQUANTO FACILITA A ANÁLISE DO PROBLEMA. PARA REGISTRO PROPRIAMENTE DITO DOS REQUISITOS, NÃO CONSIDERO ESTA FERRAMENTA TÃO ATRAENTE QUANTO O EMPREGO DE CASOS DE USO.
  • PROPOSTAS OTIMISTAS, PORQUE FALAM EM BENEFÍCIOS QUE NÃO SÃO USUFRUÍDOS PELA INDÚSTRIA. MOTIVO PARA O DESCOMPASSO SÃO VÁRIOS: NOSSA MESA-REDONDA DEVE TRATAR DISSO.
  • Quem gasta de 15% a 30% de todos os custos de desenvolvimento pensando em ER? Quem usa o paradigma de objetos para registrá-los? Quem usa português para registrar os requisitos? Em oposição a outros como DFD, MER, UC, ... Quem faz uso de uma mistura de itens?
  • Transcript

    • 1. O início é a parte mais importante do trabalho
    • 2. Sistema e software Engenheiro de Software Sistema Software (parte de um sistema)
    • 3. Características operacionais do software, interface com outros elementos e restrições Visão externa do software Define o papel do software Refina o papel do software Criar modelos de dados, funções e comportamento Visão geral do sistema Quando? Engenharia de sistema Projeto de software Análise de Requisitos de software
    • 4. Confusão garantida Engenharia de Software Engenharia de Requisitos Engenharia de Requisitos
    • 5. <ul><li>Produz a especificação do sistema
    • 6. Elemento software é tratado pela engenharia de software
    • 7. Engenharia de Software inicia-se com a engenharia de requisitos </li></ul>Engenharia de Sistemas
    • 8. Engenharia de Requisitos <ul><li>Entender o que o cliente deseja
    • 9. Analisar necessidades
    • 10. Avaliar exequibilidade
    • 11. Negociar uma solução razoável
    • 12. Especificar uma solução
    • 13. Validar uma especificação
    • 14. Gerenciar requisitos </li></ul>
    • 15. O que é um requisito? <ul><li>Condição necessária para que se resolva um problema ou se atinja um objetivo
    • 16. Condição que deve ser atendida ou apresentada por um sistema ou componente de sistema para satisfazer um contrato, um padrão, especificação ou outro documento formalmente imposto </li></ul>IEEE Std. 612.12-1990
    • 17. Quando é feita?
    • 18. Quando Outros nomes: Análise de requisitos, Requisitos, Análise, Análise de sistemas ,...
    • 19. Fundamentos <ul><li>Ciências Sociais </li><ul><li>Política, psicologia social
    • 20. Comportamento organizacional
    • 21. Antropologia </li></ul><li>Ciências Cognitivas </li><ul><li>Representação de conhecimento
    • 22. Lingüística </li></ul><li>Filosofia </li><ul><li>Epistemologia, ontologia,
    • 23. Fenomenologia, Semiótica </li></ul></ul><ul><li>Teoria de Sistemas </li><ul><li>O que é um sistema?
    • 24. Controle e evolução de sistemas </li></ul><li>Engenharia de Sistemas </li><ul><li>Ciclos de vida </li></ul><li>Matemática e Lógica </li><ul><li>Modelos relacionais
    • 25. Modelos algébricos
    • 26. Lógica temporal
    • 27. Lógica modal </li></ul></ul>
    • 28. Contexto e objetivo comportamento externo Domínio do Problema Domínio da Solução
    • 29. Resultado <ul><li>O que construir?
    • 30. O que esperar?
    • 31. Como validar? </li></ul>Se não for bem escrito:
    • 32. Quem se interessa pela ERS? <ul><li>Clientes Documenta o que deve ser entregue
    • 33. Gerentes Planejamento de projeto
    • 34. Projetistas de Software Define o que estes devem projetar
    • 35. Controle de Qualidade de Software Base da validação, planejamento de teste e verificação </li></ul>Interessados = stakeholders
    • 36. Conteúdo de uma ERS
    • 37. ERS de “boa” qualidade <ul><li>Completa
    • 38. Independente de implementação
    • 39. Consistente
    • 40. Não ambígua
    • 41. Precisa
    • 42. Verificável
    • 43. Modificável
    • 44. Legível
    • 45. Organizada </li></ul>
    • 46. Dificuldades para uma “boa” ERS <ul><li>Comunicação
    • 47. Especificação de Requisitos </li><ul><li>Ambígua
    • 48. Incompleta </li></ul><li>Volatilidade de requisitos
    • 49. Registro de requisitos </li><ul><li>Notação </li></ul><li>Detalhes desconhecidos
    • 50. Clientes numerosos
    • 51. Clientes conflitantes
    • 52. Clientes dispersos, ... </li></ul>
    • 53. Evidências de dificuldades <ul><li>Standish Group, 1995 350 empresas americanas 8000 projetos
    • 54. Fonte de falhas </li><ul><li>Pouco envolvimento do usuário (13%)
    • 55. Requisitos incompletos (12%)
    • 56. Mudança de requisitos (11%)
    • 57. Expectativas irreais (6%)
    • 58. Objetivos obscuros (5%) </li></ul></ul>cerca de 50% das causas de problemas <ul><li>European Software Institute, 1996 3800 organizações européias, 17 países
    • 59. Principais problemas em software são </li><ul><li>Especificação de requisitos (> 50%)
    • 60. Gerência de requisitos (50%) </li></ul></ul>
    • 61. Motivação Requisitos Versão 89.2-A2
    • 62. Motivação extra
    • 63. “Nada é mais difícil e incerto do que conduzir a introdução de uma nova ordem de coisas.” Machiavelli Motivação
    • 64. Fábula (sucesso)
    • 65. Mausoléu X Qual o problema?
    • 66. Charge (fracasso) Sobre as orelhas. Ok! King´s Kong Av. Anhangüera, 18...
    • 67. Após muito esforço e atrasos, ... IRONIA INSATISFAÇÃO
    • 68. Definição Requisitos
    • 69. Classificação dos requisitos
    • 70. Processo da ER: entradas/saídas
    • 71. Processo Validação Modelagem Eliciação
    • 72. Atividades da ER <ul><li>Eliciação </li><ul><li>Entrevista, análise de docs, ... </li></ul><li>Modelagem </li><ul><li>registrar requisitos </li></ul></ul><ul><li>Validação </li></ul><ul><li>Gerência </li><ul><li>rastreabilidade </li></ul></ul>
    • 73. Por que eliciar? Você se sente melhor?
    • 74. Descontração
    • 75. Técnicas de eliciação <ul><li>Entrevistas e questionários
    • 76. Workshops, Brainstorming
    • 77. Storyboard
    • 78. Casos de Uso
    • 79. Representação (role playing)
    • 80. Construção de protótipos
    • 81. Análise de textos </li></ul>
    • 82. Modelagem <ul><li>Linguagem natural (maioria dos casos) </li><ul><li>Seja sentença ou através de casos de uso </li></ul></ul><ul><li>Quais métodos podem ser empregados? </li><ul><li>Pseudocódigo
    • 83. Máquina de estados finitos
    • 84. Análise Orientada a Objetos
    • 85. Análise Estruturada
    • 86. Modelos entidade-relacionamento, ... </li></ul></ul>Ator Caso de uso C Caso de uso A Caso de uso B <<include>> Requerimento Boleto Bancário Comprovante Processo Parecer Autorização Sanciona Ajuda de Requerimento 0..1 1..n 0..1 1..n gera Avaliação de necessita Formulário de requerimento oficializado por
    • 87. Há custos?
    • 88. Teoria x Prática Supostos benefícios
    • 89. O que os “bons” fazem? <ul><li>Usam métodos avançados (OO)
    • 90. ER executada em várias rodadas
    • 91. Revisões constantes com usuários
    • 92. Protótipos + Modelos
    • 93. Alocação de 15% a 30% do esforço total para ER </li></ul>
    • 94. Onde procurar por informações? <ul><li>Livros http://easyweb.easynet.co.uk/~iany/reviews/reviews.htm
    • 95. Gerência de requisitos http://www.jiludwig.com/
    • 96. Ferramentas (>50) http://www. volere .co. uk/tools . htm </li></ul>
    • 97. Considerações finais <ul><li>ER é imprescindível e, ao mesmo tempo, difícil!
    • 98. Não menospreze os custos para execução adequada da engenharia de requisitos (cerca de 15% a 30% do custo total) </li></ul>

    ×