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. 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. 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. Contextualização

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. Está complicado alcançar o ATM? Bom, acho que eu consigo...
Fonte: https://www.youtube.com/watch?v=qPhVZExcGXg

7. Banheiros do banco de Elton e Simon!
Fonte: https://www.youtube.com/watch?v=qPhVZExcGXg

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. O que geralmente ocorre no
entendimento
Autor: Alex Gorbatchev (postou em um blog em 2005)
Fonte: http://blog.codinghorror.com/on-software-engineering/

10. Na execução...
Autor: Alex Gorbatchev (postou em um blog em 2005)
Fonte: http://blog.codinghorror.com/on-software-engineering/

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. 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. Dados sobre requisitos
(HOOKS; FARRY, 2001)
Tipos de erros de requisitos Custo de erro nos requisitos por fase
(quantidade de vezes)

14. Impacto dos requisitos nos projetos
(STANDISH GROUP, 1995)

15. Esforço pré-design x custo (NASA)
(HOOKS; FARRY, 2001)

16. Introdução a ER

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. 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. 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. 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. 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. 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. Processos de ER

24. Processos de ER
(FALBO, 2016)

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. 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. Exemplo: RUP (Papéis e artefatos)
(RUP, 2003)

28. Levantamento, análise, documentação,
verificação, validação e gerência de requisitos

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. 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. 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. Levantamento de Requisitos - Prática

33. Levantamento de Requisitos - Prática

34. Levantamento de Requisitos - Prática
(FOODDELIVERYWEB,2016)

35. Levantamento de Requisitos - Prática
(FOODDELIVERYWEB,2016)

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. 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. Análise de Requisitos - Prática
Diagrama de atividades
Diagrama de classe de domínio da aplicação
(FOOD DELIVERY WEB, 2016)

39. Análise de Requisitos - Prática
Diagrama de casos de uso
(FOOD DELIVERY WEB, 2016)

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. 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. Documentação de Requisitos - Prática
Especificaçãodecasodeuso
Especificaçãosuplementar
(FOODDELIVERYWEB,2016)

43. Documentação de Requisitos - Prática
Atributos dos Casos de Uso
(FOOD DELIVERY WEB, 2016) Atributos da Especificação Suplementar

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. 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. 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. 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. Verificação e Validação de Requisitos -
Prática
Inspeção de artefatos produzidos

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. 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. 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. Gerência de Requisitos - Prática
(FOODDELIVERYWEB,2016)

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. 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. ER - Metodologias Ágeis, MDD e GORE
Agile

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. 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. 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. 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. 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. 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. ER com GORE
Estrutura Refinada (derivada) para
extração de casos de uso (SOUZA, 2014)

63. Ferramentas CASE ER

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. 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. 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. 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. 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. 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. 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. Pensamento
Fonte: Einstein, Albert and Infeld, Léopold, The Evolution of Physics, 1938

72. Dúvidas?
Obrigado!
Estêvão Bissoli Saleme
br.linkedin.com/in/estevaosaleme
http://lattes.cnpq.br/8757661847246456