Engenharia de Requisitos Documento
•Descargar como ODP, PDF•
6 recomendaciones•2,319 vistas
Introdução à engenharia de requisitos.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Engenharia de Requisitos Documento
Similar a Engenharia de Requisitos Documento (20)
Más de Fábio Nogueira de Lucena
Más de Fábio Nogueira de Lucena (20)
Engenharia de Requisitos Documento
- 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
- 6. Elemento software é tratado pela engenharia de software
- 7. Engenharia de Software inicia-se com a engenharia de requisitos Engenharia de Sistemas
- 11. Negociar uma solução razoável
- 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 IEEE Std. 612.12-1990
- 17. Quando é feita?
- 18. Quando Outros nomes: Análise de requisitos, Requisitos, Análise, Análise de sistemas ,...
- 26. Lógica temporal
- 27. Lógica modal
- 28. Contexto e objetivo comportamento externo Domínio do Problema Domínio da Solução
- 30. O que esperar?
- 31. Como validar? Se não for bem escrito:
- 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 Interessados = stakeholders
- 36. Conteúdo de uma ERS
- 39. Consistente
- 40. Não ambígua
- 41. Precisa
- 42. Verificável
- 43. Modificável
- 44. Legível
- 45. Organizada
- 56. Mudança de requisitos (11%)
- 60. Gerência de requisitos (50%)
- 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
- 70. Processo da ER: entradas/saídas
- 71. Processo Validação Modelagem Eliciação
- 73. Por que eliciar? Você se sente melhor?
- 74. Descontração
- 77. Storyboard
- 78. Casos de Uso
- 83. Máquina de estados finitos
- 84. Análise Orientada a Objetos
- 86. Modelos entidade-relacionamento, ... 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?
- 89. ER executada em várias rodadas
- 90. Revisões constantes com usuários
- 92. Alocação de 15% a 30% do esforço total para ER
- 94. Gerência de requisitos http://www.jiludwig.com/
- 95. Ferramentas (>50) http://www. volere .co. uk/tools . htm
- 97. Não menospreze os custos para execução adequada da engenharia de requisitos (cerca de 15% a 30% do custo total)
Notas del editor
- 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?