Engenharia de Requisitos

173 visualizações

Publicada em

Seminário sobre Engenharia de Requisitos apresentado por Estêvão Bissoli Saleme em 17/05/2016.

Publicada em: Software
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
173
No SlideShare
0
A partir de incorporações
0
Número de incorporações
14
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Engenharia de Requisitos

  1. 1. Engenharia de Requisitos Apresentado por ESTÊVÃO B. SALEME Seminário da disciplina Engenharia de Software - Professora Dra. Monalessa Perini Barcellos Vitória, ES, 17/05/2016 Universidade Federal do Espírito Santo – UFES Programa de Pós Graduação em Informática - PPGI
  2. 2. Objetivos Descrever conceitos gerais sobre Engenharia de Requisitos (ER) Explicar processos de ER Apresentar técnicas de levantamento, análise, documentação, verificação, validação e gerência de requisitos Demonstrar práticas de ER em projetos reais de desenvolvimento de software Apresentar ER em Metodologias Ágeis e MDD (Desenvolvimento Dirigido por Modelos) e usando GORE
  3. 3. Agenda Contextualização Introdução a ER Processos de ER Levantamento, análise, documentação, verificação, validação e gerência de requisitos ER - Metodologias Ágeis, MDD e GORE Ferramentas CASE ER Considerações Finais
  4. 4. Contextualização
  5. 5. “Era uma vez...” Elton Gerente do banco Simon Gerente de manutenção John Dono da ATMTec Um banco Onde trabalhavam Elton recebia reclamações frequentes sobre a falta de ATM em 2 bairros próximos ...mas estava sempre ocupado e se esquecia de solicitar ao Simon Um dia, ele recebeu uma ligação de um cliente importante com a mesma reclamação Ele precisava resolver rápido Então, logo chamou Simon e solicitou a instalação de mais ATMs nos bairros Antes mesmo que Simon perguntasse a localização exata ele desligou o telefone Simon, também muito ocupado e nervoso, ligou para John e, esbravejando, pediu mais 2 ATMs sem dar maiores explicação John queria explicar que faltava espaço adequado, mas sem sucesso. Baseado nas informações que detinha, John e sua equipe construíram e instalaram os ATMs...
  6. 6. Está complicado alcançar o ATM? Bom, acho que eu consigo... Fonte: https://www.youtube.com/watch?v=qPhVZExcGXg
  7. 7. Banheiros do banco de Elton e Simon! Fonte: https://www.youtube.com/watch?v=qPhVZExcGXg
  8. 8. Elton e Simon foram trabalhar numa construtora... O que eu faço agora??? Isso pode custar caro... Fonte: https://www.youtube.com/watch?v=qPhVZExcGXg
  9. 9. O que geralmente ocorre no entendimento Autor: Alex Gorbatchev (postou em um blog em 2005) Fonte: http://blog.codinghorror.com/on-software-engineering/
  10. 10. Na execução... Autor: Alex Gorbatchev (postou em um blog em 2005) Fonte: http://blog.codinghorror.com/on-software-engineering/
  11. 11. Problemas nos requisitos Não refletem as reais necessidades do cliente ◦ Inconsistentes ou incompletos Alto custo para fazer mudanças depois que os requisitos foram acordados e executados Cliente insatisfeito
  12. 12. Principais causas dos problemas Falha no entendimento dos requisitos Registro de requisitos de maneira desorganizada Pouco esforço para verificar o que coletamos e registramos Falta de mecanismo para priorização e controle de mudanças nos requisitos
  13. 13. Dados sobre requisitos (HOOKS; FARRY, 2001) Tipos de erros de requisitos Custo de erro nos requisitos por fase (quantidade de vezes)
  14. 14. Impacto dos requisitos nos projetos (STANDISH GROUP, 1995)
  15. 15. Esforço pré-design x custo (NASA) (HOOKS; FARRY, 2001)
  16. 16. Introdução a ER
  17. 17. O que é a Engenharia de Requisitos? “O amplo espectro de tarefas e técnicas que conduzem ao entendimento dos requisitos” (PRESSMAN; MAXIM, 2014) “O processo de levantamento, análise, documentação e checagem dos requisitos dos clientes e suas restrições” SOMMERVILLE (2011) “O processo de levantar, analisar, documentar, gerenciar e controlar a qualidade dos requisitos” FALBO (2016)
  18. 18. O que é a Engenharia de Requisitos? “Função interdisciplinar que faz a mediação entre os domínios do adquirente e o fornecedor para estabelecer e manter os requisitos para ser satisfeito por um sistema, software ou serviço” (ISO/IEC/IEEE 29148:2011) “Elicitação, análise, especificação e validação de requisitos de software bem como gerenciamento de requisitos durante todo o ciclo de vida do software” (SWEBOK, 2014) – Por Kotonya e Sawyer SWEBOK não usa o termo “Engenharia” por razão de consistência
  19. 19. O que são Requisitos? “Definem o que o sistema deve fazer e as circunstâncias sob as quais deve operar” (BARCELLOS, 2016) “Expressam as necessidades e restrições do produto de software que contribui para uma solução de um problema no mundo real” (SWEBOK, 2014) “Descrevem o que o sistema deve fazer e suas restrições de operação. Reflete a necessidade dos clientes para um sistema com um certo propósito” (SOMMERVILLE, 2011)
  20. 20. O que são Requisitos? Caracterização e restrições Exemplos Manter o registro de todos os documentos administrativos da UFES (o que) Permitir ao usuário pesquisar os documentos por: título, palavra-chave ou qualquer parte do texto (o que) Ter o tempo máximo de retorno da pesquisa menor ou igual a 5 segundos (restrição) Suportar no mínimo 200 usuários simultâneos sem comprometer a performance do sistema (restrição)
  21. 21. Requisitos - Perspectivas Negócio • Tarefas que os usuários serão capazes de executar com a utilização do sistema Produto • Relacionadas a implementação da solução (sistema) (SOMMERVILLE, 2011)
  22. 22. Tipos de Requisitos Funcionais • Descreve a funcionalidade e os serviços do sistema (sob a perspectiva do negócio ou produto) • Interação entre o sistema e atores • Ex.: Manter o registro de todos os documentos administrativos da UFES Não funcionais • Não estão diretamente preocupados com serviços específicos estregues pelo sistema ao usuário. • Pode ser descrito como um atributo de qualidade, performance, segurança ou uma restrição geral do sistema (PRESSMAN; MAXIM, 2014) • Ex. 1: Ter o tempo máximo de retorno da pesquisa menor ou igual a 5 segundos • Ex. 2: Estar em conformidade com o DECRETO Nº 8.539, DE 8 DE OUTUBRO DE 2015
  23. 23. Processos de ER
  24. 24. Processos de ER (FALBO, 2016)
  25. 25. Processos de ER Adaptado de Sommerville (2011) 1 2 3 4 5 6 7 8 9 Requisitos Gerenciados Macro atividades em diferentes níveis
  26. 26. Exemplo: RUP • Documento de visão e glossário • Plano de gerenciamento de requisitos desenvolvido Análise do Problema • Refinamento do documento de visão • Resumo da especificação suplementar (ES) Compreensão das Atividades dos Envolvidos • Atores e casos de uso identificados na íntegra • Requisitos não-funcionais expandidas na ES Definir o Sistema • Gerenciamento de atributos de requisitos • Priorização Gerenciamento de Escopo • Casos de uso e EF detalhados • Descoberta ou refinamento de requisitos Refinamento da Definição do Sistema • Avaliação de solicitações de mudanças • Verificação formal dos requisitos junto ao cliente Gerência de Requisitos Mutáveis (RUP, 2003)
  27. 27. Exemplo: RUP (Papéis e artefatos) (RUP, 2003)
  28. 28. Levantamento, análise, documentação, verificação, validação e gerência de requisitos
  29. 29. Levantamento de Requisitos Pontapé inicial da ER Entendimento básico do problema, quem quer a solução e a natureza da solução Entendimento • Obter informações dos interessados (stakeholders) • Consultar documentos • Obter conhecimentos do domínio • Estudar o negócio da organização
  30. 30. Levantamento de Requisitos - Técnicas Entrevistas • Conversas com propósito específico • Descobrir problemas, levantar procedimentos, opiniões e expectativas Questionários • Obter informações como postura, comportamento e características das pessoas que serão afetadas pelo sistema Observação • Ajuda a confirmar ou refutar informações de outras técnicas • Ajuda na identificação de tarefas que podem ser automatizadas no ambiente do usuário e não detectadas por outras técnicas Análise de documentos • Capturar informações e detalhes que são difíceis de se obter por entrevista ou observação Cenários • Interação entre o usuário e o sistema • Expor possibilidades dessas interações Prototipagem • Materializar um requisito (pode ser não-operacional e descartável) • Obter reações iniciais e sugestões Dinâmicas de Grupo • Brainstorm estruturado com grupos de interessados • Discussão de problemas e soluções
  31. 31. Levantamento de Requisitos - Dificuldades Pode ser difícil compreender e coletar informações quando existem muitos termos desconhecidos, manuais técnicos, etc. Usuário de negócio (ou interessado) pode estar muito ocupado e não ter agenda suficiente para apoiar o analista no entendimento Políticas organizacionais podem influenciar nos requisitos de um sistema Muitas vezes os interessados não sabem muito bem o que querem do sistema
  32. 32. Levantamento de Requisitos - Prática
  33. 33. Levantamento de Requisitos - Prática
  34. 34. Levantamento de Requisitos - Prática (FOODDELIVERYWEB,2016)
  35. 35. Levantamento de Requisitos - Prática (FOODDELIVERYWEB,2016)
  36. 36. Análise de Requisitos Requisitos levantados são usados como base para a modelagem do sistema Detalhados do sistema de maneira mais técnica Os modelos: ◦ Ajudam o analista a entender a informação, a função e o comportamento do sistema de maneira sistemática ◦ Chave para a determinação da consistência da especificação Análise é uma atividade extremamente vinculada ao levantamento de requisitos Perspectiva Estrutural • Modelar conceitos, propriedades e relações do domínio • Estático. Ex. diagrama de classes Perspectiva Comportamental • Comportamento do sistema ou funcionalidade • Dinâmico. Ex. diagramas de atividades, estado e interação
  37. 37. Análise de Requisitos - Dificuldades Análise de requisitos: ◦ Base para o entendimento e concordância entre as partes sobre o que o sistema deve fazer ◦ Especificação que guie os desenvolvedores na demais etapas do ciclo de desenvolvimento Problemas e conflitos encontrados nos requisitos devem ser listados, negociados e acordados. Reuniões de negociação: ◦ Discussão: requisitos problemáticos são discutidos e os interessados opinam sobre eles ◦ Priorização: requisitos são priorizados para identificar requisitos críticos e ajudar nas decisões e planejamento ◦ Concordância: soluções para os problemas são identificadas, mudanças são feitas e é realizado um acordo
  38. 38. Análise de Requisitos - Prática Diagrama de atividades Diagrama de classe de domínio da aplicação (FOOD DELIVERY WEB, 2016)
  39. 39. Análise de Requisitos - Prática Diagrama de casos de uso (FOOD DELIVERY WEB, 2016)
  40. 40. Documentação de Requisitos Atividade de registro e oficialização dos resultados da engenharia de requisitos Benefícios: ◦ Facilita a comunicação dos requisitos ◦ Reduz o esforço de desenvolvimento, pois sua preparação força usuários e clientes a considerar os requisitos atentamente, evitando retrabalho nas fases posteriores ◦ Base realística para estimativas ◦ Base para verificação e validação ◦ Facilita a transferência do software para novos usuários e/ou máquinas ◦ Base para futuras manutenções ou incremento de novas funcionalidades Dois tipos de documentos de requisitos elaborados (não limitados a 2 documentos): ◦ Documento de Definição de Requisitos ◦ Documento de Especificação de Requisitos
  41. 41. Documentação de Requisitos Definição de Requisitos • Descrição do propósito do sistema • Descrição do domínio do problema tratado pelo sistema • Lista de requisitos funcionais • Lista de requisitos não funcionais • Regras de negócio • Usa-se identificadores nos requisitos • Público alvo clientes, usuários, gerentes e desenvolvedores • Ex.: Documento de visão Especificação de Requisitos • Requisitos escritos a partir da perspectiva mais técnica • Pode conter modelos, casos de uso, atributos de requisitos, etc. • Correspondência entre requisitos de negócio com requisitos de negócio x requisitos de produto • Ex.: ERS (Especificação de Requisitos de Software)
  42. 42. Documentação de Requisitos - Prática Especificaçãodecasodeuso Especificaçãosuplementar (FOODDELIVERYWEB,2016)
  43. 43. Documentação de Requisitos - Prática Atributos dos Casos de Uso (FOOD DELIVERY WEB, 2016) Atributos da Especificação Suplementar
  44. 44. Documentação de Requisitos - Prática Disponível em: https://github.com/estevaosaleme/fooddeliveryweb/blob/master/Documentacao/Requisitos/Visao/FDW_ERS_FoodDeliveryWeb.odt (FOODDELIVERYWEB,2016) ERS (SRS)
  45. 45. Documentação de Requisitos - Prática Disponível em: https://github.com/estevaosaleme/fooddeliveryweb/blob/master/Documentacao/Requisitos/Visao/FDW_ERS_FoodDeliveryWeb.odt (FOODDELIVERYWEB,2016)
  46. 46. Verificação e Validação de Requisitos Requisitos = base para o desenvolvimento Documentação de requisitos devem ser submetidos à verificação e à validação. Verificação • Assegurar o que software está sendo construído de forma correta • Verificação de consistência entre requisitos e modelos e à conformidade com padrões organizacionais dos documentos de requisitos Validação • Validar que o software que está sendo desenvolvido é o software correto (se atende ao propósito) • Participação de usuários e clientes
  47. 47. Para Verificar se os requisitos do sistema tenham sido declarados de modo não- ambíguo, se as inconsistências, conflitos, omissões e erros tenham sido detectados e corrigidos, se os documentos estão em conformidade com os padrões estabelecidos e validar se os requisitos realmente satisfazem às necessidades dos clientes e usuários, É útil ◦ Realizar revisões dos documentos de requisitos ◦ Definir casos de teste para os requisitos especificados ◦ Definir critérios de aceitação de requisitos por parte do usuário/cliente ◦ Obter aceitação do usuário/cliente Verificação e Validação de Requisitos
  48. 48. Verificação e Validação de Requisitos - Prática Inspeção de artefatos produzidos
  49. 49. Verificação e Validação de Requisitos - Prática Termo de aceite (Validação do usuário) Especificação de Casos de Teste (Outra forma de verificação)
  50. 50. Gerência de Requisitos A gerência ocorre ao longo de todo processo da ER devido às frequentes mudanças decorrentes de diversos fatores: Sem a gerência: ◦ Alterações com baixa prioridade podem ser implementadas antes de outras mais importantes ◦ Modificações com custo alto que não são realmente necessárias podem ser aprovadas
  51. 51. Ao se detectar a necessidade de alteração em um ou mais requisitos: ◦ Deve-se registrar uma solicitação de mudança ◦ Avaliar impacto da alteração considerando valores de custo, esforço, tempo e viabilidade ◦ Avaliar impacto da mudança no restante do software É necessário estabelecer ligações de modo que um requisito e os elementos ligados a ele possam ser rastreados. Rastreabilidade = acompanhamento da vida de um requisito no processo de software durante todo o ciclo de vida Gerência de Requisitos - Mudanças
  52. 52. Gerência de Requisitos - Prática (FOODDELIVERYWEB,2016)
  53. 53. Gerência de Requisitos - Prática (FOOD DELIVERY WEB, 2016) Matriz de rastreabilidade Requisito de Negócio x Casos de Uso Matriz de rastreabilidade Regra de Negócio x Casos de Uso
  54. 54. ER e Modelos de Referência CMMI SG 1 Manage Requirements SP 1.1 Understand Requirements SP 1.2 Obtain Commitmentto Requirements SP 1.3 Manage Requirements Changes SP 1.4 Maintain BidirectionalTraceability of Requirements SP 1.5 Ensure Alignment Between Project Work and Requirements SG 1 Develop Customer Requirements SP 1.1 Elicit Needs SP 1.2 Transform Stakeholder Needs into Customer Requirements SG 2 Develop Product Requirements SP 2.1 Establish Product and Product Component Requirements SP 2.2 Allocate Product Component Requirements SP 2.3 Identify Interface Requirements SG 3 Analyze and Validate Requirements SP 3.1 Establish Operational Concepts and Scenarios SP 3.2 Establish a Definition of Required Functionality and Quality Attributes SP 3.3 Analyze Requirements SP 3.4 Analyze Requirements to Achieve Balance SP 3.5 Validate Requirements MPS.BR GRE - Gerência de Requisitos GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos; GRE 2. Os requisitos são avaliados com base em critérios objetivos e um comprometimentoda equipe técnica com estes requisitos é obtido; GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida; GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificare corrigir inconsistências em relação aos requisitos; GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto. DRE - Desenvolvimento de Requisitos DRE 1. As necessidades, expectativas e restrições do cliente, tanto do produto quanto de suas interfaces, são identificadas; DRE 2. Um conjunto definido de requisitos do cliente é especificado e priorizado a partir das necessidades, expectativas e restrições identificadas; DRE 3. Um conjunto de requisitos funcionais e não-funcionais, do produto e dos componentes do produto que descrevem a solução do problema a ser resolvido, é definido e mantido a partir dos requisitos do cliente; DRE 4. Os requisitos funcionais e não-funcionais de cada componente do produto são refinados, elaborados e alocados. Interfaces internas e externas do produto e de cada componente do produto são definidas; DRE 5. Conceitos operacionais e cenários são desenvolvidos; DRE 6. Os requisitos são analisados, usando critérios definidos, para balancear as necessidades dos interessados com as restrições existentes; DRE 7. Os requisitos são validados.
  55. 55. ER - Metodologias Ágeis, MDD e GORE Agile
  56. 56. ER em Métodos Ágeis Defende que os requisitos mudam constantemente e o documento de requisitos está “desatualizado” assim que ele acaba de ser escrito Priorizam requisitos para implementação Técnica mais comum de se obter os requisitos são entrevistas Modelos são rapidamente traduzidos em código e a maioria não é persistente Criar documentos consistentes e completos é visto como infactível. Assumem que são menores (documentos) do que processo tradicionais Fazem reuniões frequentes para validação por meio de teste de aceitação Gerenciamento - requisitos são escritos em cartões ou mantido em backlog/lista de feature. Omitem detalhes
  57. 57. ER em Métodos Ágeis Envolvimento do cliente é o ponto fundamental para o sucesso dos métodos ágeis Gerenciam requisitos efetivamente em projetos pequenos, mas apresentam problemas em projetos grandes Fases da ER estão presentes em todos os processos ágeis Dependência maior das pessoas
  58. 58. ER em MDD MDD (Model Driven Development) ou Desenvolvimento orientado a modelo – principais artefatos são os modelos a partir dos quais são gerados códigos CIM (Computation Independent Model) - modela abstrações de domínio importantes usadas no sistema PIM (Platform Independent Model) – modela operações do sistema sem se preocupar com sua implementação PSM (Platform Specific Models) – modela operações do sistema levando em conta a plataforma e detalhes de implementações
  59. 59. ER em MDD As etapas de ER em MDD são semelhantes as de um ciclo de desenvolvimento tradicional, porém com grande ênfase na modelagem CIM e o PIM são os principais modelos trabalhados na ER. O processo de ER é fundamental, pois o código será resultado do modelo Fonte: http://www.rdbprime.com/researchPapers/UML/UML_TermPaper.html
  60. 60. ER com GORE Goal Oriented Requirement Engineering ou Engenharia de Requisitos Orientada a Objetivos. Não é recente: ~1993 Foco em expressar os “porquês” associados ao desenvolvimento de sistemas Objetivos são metas que clientes e usuários possuem em relação a sistemas de software Foco no início do processo de ER -> analistas comunicam-se com os stakeholders utilizando uma linguagem baseada nos conceitos ◦ Pode-se derivar e descrever cenários de uso destes sistemas a partir dos objetivos ◦ Na análise dos cenários, pode-se descobrir novos objetivos Processo iterativo na busca de novos requisitos de sistemas
  61. 61. ER com GORE Benefícios da ER com GORE ◦ Derivação sistemática de requisitos a partir de objetivos ◦ Objetivos explicam o motivo dos requisitos ◦ Estrutura de refinamento fornece uma estrutura compreensível para o documento de requisitos ◦ Alternativas de refinamentos dos objetivos permitem explorar diferentes propostas de soluções ◦ A formalização dos objetivos ajuda na avaliação da corretude e completude do refinamento Técnica mais comuns: i* (iStar) e KAOS
  62. 62. ER com GORE Estrutura Refinada (derivada) para extração de casos de uso (SOUZA, 2014)
  63. 63. Ferramentas CASE ER
  64. 64. Ferramentas CASE ER • Nuvem de tags gerada a partir da página List of Requirements Management Tools em 30/04/2016 • Em Fev/16 Andreas Birk e Gerald Heller encontraram 111 ferramentas CASE relacionadas RE
  65. 65. Principais Ferramentas para ER Agile Manager (2.50) by Hewlett-Packard Enterprise Scope: RM, Agile Blueprint (v6.4) by Blueprint Software Systems, Inc. Scope: RD, RM, UI Mockup, Visual Modeling CA Agile Central (previously: Rally) (2015.2) by CA Technologies (previously: Rally Software Development Corp.) Scope: RM, Agile Caliber (11.4.11) by Borland (Micro Focus) Scope: RM, Visual Modeling codeBeamer Requirements Management (7.8.0) by Intland Software GmbH Scope: RM Cognition Cockpit (7.4) by Cognition Corporation Scope: RM, Product Management, Testing, Project Management Enterprise Architect (12.1) by Sparx Systems Scope: Visual Modeling, RM HPE ALM/Quality Center (12.50) by Hewlett-Packard Enterprise Scope: RM, Testing, Project Management, Issue Management IBM Rational DOORS (9.6.1.4) by IBM Scope: RM IBM Rational DOORS Next Generation (6.0.1) by IBM Scope: RM in-STEP BLUE (5.1.3) by microTool GmbH Scope: Project Management, RM, Testing in-STEP RED (2.2) by microTool GmbH Scope: Project Management, RM Innovator for Business Analysts (12.3) by MID GmbH Scope: Visual Modeling, RM inteGREAT (v8.7.13) by eDev Technologies Scope: RM, RD, Visual Modeling Jama (2015.5) by Jama Software Scope: RM, Testing JIRA Software (7.1.0) by Atlassian Scope: Issue Management, Agile, Project Management, RM Kovair ALM Studio (8.0) by Kovair Software, Inc. Scope: RM, Testing Mingle (15.2) by Thoughtworks Scope: RM, Agile, Project Management Polarion Requirements (2015 SR3) by Polarion Software Scope: RM PTC Integrity (10.8) by PTC Integrity Scope: RM, Testing Serena Dimensions RM (12.3) by Serena Software Scope: RM TestTrack RM (2015.1.2) by Seapine Software, Inc. Scope: RM TopTeam Analyst (version info not available) by TechnoSolutions Scope: Visual Modeling, RM VersionOne (16.0.2.180) by VersionOne Scope: RM, Agile Visure Requirements (4.7) by Visure Scope: RD, RM Fonte: List of Requirements Management Tools acesso em 30/04/2016
  66. 66. Demo IBM/Rational ReqPro Ps.: A IBM continua o suporte, manutenção e melhoria ao ReqPro, mas os seus esforços futuros estão direcionados para a IBM Rational DOORS Next (Fonte: https://www.ibm.com/developerworks/community/blogs/requirementsmanagement/entry/3_reasons_to_throw_away_your_requireme nts_documents_webcast_follow_up?lang=en acesso em 30/04/2016)
  67. 67. Considerações Finais ER pode ser vista como “roadmap” para estabelecer requisitos para se alcançar o produto e gerenciar suas mudanças A ER, apesar de sistemática, não é impositiva. O engenheiro de software pode instanciar o que lhe for mais apropriado levando em conta fatores como criticidade ou tamanho do projeto Não é necessariamente sequencial. São aproximações do mundo real. RE nunca será perfeita Java has many tools to select as well as RE!
  68. 68. Referências BARCELLOS, M. P., Material da disciplina Engenharia de Software, UFES, 2016 FALBO, R. A., Engenharia de Requisitos – Notas de aula, UFES, 2016 FOOD DELIVERY WEB, Disponível em https://github.com/estevaosaleme/fooddeliveryweb forked from tiubak/fooddeliveryweb. Acesso em 07 de maio de 2016 HOOKS, F., FARRY, A., Customer-centered Products: Creating Successful Products Through Smart Requirements Management, Ed. Amacon, USA, 2001 ISO/IEC/IEEE 29148:2011, Systems and software engineering - Life cycle processes - Requirements engineering, 2011 NUSEIBEH, B., EASTERBROOK, S., Requirements engineering: a roadmap. In Proceedings of the Conference on The Future of Software Engineering (ICSE '00). ACM, 2000
  69. 69. Referências PAETSCH, F., EBERLEIN, A., Maurer, F., Requirements engineering and Agile software Development. In Proceedings of 8th Int. Workshop on Enterprise Security, Linz, Austria, 2003 PRESSMAN, R.; MAXIM, B., Software Engineering: A Practitioner’s Approach. 8 ed., McGraw-Hill Science/Engineering/Math, 2014 RUP, Rational Unified Process. Version 2003.06.12.01. Rational Software Corporation, 2003 SALEME, E. B., Análise da Utilização do RUP na Engenharia de Requisitos do Software Livre Food Delivery Web, UFLA, 2010 STANDISH GROUP, The Chaos Report, 1995 SOMMERVILLE, I., Software engineering. 9. ed. [S.l.]: Pearson, 2011
  70. 70. Referências SOUZA, V. E. S., Material da disciplina Análise e Projeto Orientado a Objetos, UFES, 2006 SOUZA, V. E. S., Material da disciplina Banco de Dados - Análise de Requisitos, UFES, 2014 SWEBOK, Guide to the Software Engineering Body of Knowledge – SWEBOK V3, IEEE Computer Society, 2014 VASCONCELOS, A. M. L., MEDEIROS, T. M. M., ROUILLER, A. C., MACHADO, C. A. F., Introdução à Engenharia de Software e Qualidade de Software. Lavras: UFLA, 2006
  71. 71. Pensamento Fonte: Einstein, Albert and Infeld, Léopold, The Evolution of Physics, 1938
  72. 72. Dúvidas? Obrigado! Estêvão Bissoli Saleme br.linkedin.com/in/estevaosaleme http://lattes.cnpq.br/8757661847246456

×