IDENTIFICANDO REQUISITOS ENGENHARIA DE SOFTWARE Prof.: José Eduardo Freire.

Apresentação em tema: "IDENTIFICANDO REQUISITOS ENGENHARIA DE SOFTWARE Prof.: José Eduardo Freire."— Transcrição da apresentação:

1 IDENTIFICANDO REQUISITOS ENGENHARIA DE SOFTWARE Prof.: José Eduardo Freire

2 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Identificando requisitos Requisito: é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir seus objetivos Não importa se a funcionalidade do sistema é nova ou antiga, cada sistema tem um propósito, geralmente expresso em termos do que o sistema pode fazer. Vejamos a figura a seguir:

3 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4

4 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Identificando requisitos Pesquisa da Standish Group relata as causas dos projetos terem falhados: (350 empresas)  requisitos incompletos: 13,1%  falta de envolvimento dos usuários: 12,4%  falta de recursos: 10,6%  expectativas não realistas: 9,9%  falta de apoio aos executivos: 9,3%  modificações nos requisitos e especificações: 8,7%  falta de planejamento: 8,1%  o sistema não era mais necessário: 7,5%

5 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Identificando requisitos Três categorias de requisitos:  1-) requisitos que devem ser totalmente satisfeitos  2-) requisitos que são altamente desejáveis, mas não necessários  3-) requisitos que são possíveis, mas poderiam ser eliminados

6 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Identificando requisitos Exemplo: Um sistema de cobrança de cartões de crédito deve ser capaz de relacionar as despesas atuais, somá-las e solicitar o pagamento para uma certa data, esses são requisitos da categoria 1. Mas ele pode também separar as despesas por tipo de compra, para auxiliar o comprador a entender os padrões de compra, esses são da categoria 2. O sistema de cobrança pode imprimir os créditos em preto e os débitos em vermelho, categoria 3.

7 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Identificando requisitos OS REQUISITOS IDENTIFICAM “O QUE”O SISTEMA DEVE FAZER, E O PROJETO IDENTIFICA O “COMO FAZER”. Vamos analisar a figura a seguir, que apresenta as atividades do processo de desenvolvimento de software:

8 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4

9 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Documentos de requisitos Definição dos requisitos: listagem completa de tudo que o cliente espera que o sistema proposto faça (feita de modo que o cliente entenda) Especificação dos requisitos: redefine os requisitos em termos técnicos apropriados para o desenvolvimento do projeto do sistema (analista de requisitos)

10 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Documentos de requisitos Gerência de configuração: correspondência direta entre os dois requisitos, que controlam:  os requisitos que definem o que o sistema deverá fazer  os módulos de projeto que são gerados a partir dos requisitos  o código do programa que implementa o projeto  os testes que verificam a funcionalidade do sistema  os documentos que descrevem o sistema

11 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Requisitos funcionais versus não- funcionais Funcional: descreve uma interação entre o sistema e seu ambiente Exemplos:  o sistema dever ter comunicação com um sistema ‘x’ externo  Quais estados devem ser encontrados para uma mensagem ser enviada Não-funcional: descreve uma restrição do sistema que limita nossas opções para criar uma solução para o problema Exemplos:  Contracheques distribuídos em não mais que quatro horas depois de os dados iniciais terem sido lidos  Sistema limita o acesso a gerentes seniores

12 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Tipos de requisitos Ambiente físico Interfaces Usuários e fatores humanos Funcionalidade Documentação Dados Recursos Segurança Garantia de qualidade

13 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Ambiente físico Onde o equipamento funcionará? Esse funcionamento se dará em um ou vários locais? Existe alguma restrição ambiental, tal como temperatura, umidade ou interferência magnética?

14 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Interfaces A entrada tem origem em outro ou outros sistemas? A saída vai para outro ou outros sistemas? Existe uma maneira preestabelecida pela qual os dados devem ser formatados? Existe alguma mídia definida?

15 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Os usuários e os fatores humanos Quem utilizará o sistema? Haverá diversos tipos de usuário? Qual o nível de habilidade de cada tipo de usuário? Que tipo de treinamento será necessário para cada tipo de usuário? Que facilidade o usuário terá para entender e utilizar o sistema? Qual será a dificuldade para que os usuários utilize inadequadamente o sistema?

16 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Funcionalidade O que o sistema realizará? Quando o sistema o fará? Existem diversos modos de operaçãp? Como e quando o sistema pode ser modificado ou aprimorado? Existem limitações quanto à velocidade de execução, ao tempo de resposta, ou à saída?

17 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Documentação Que documentação é necessária? Essa documentação deve ser on-line, no formato de livro, ou ambos? A que público se destina cada tipo de documentação?

18 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Dados Qual deverá ser o formato dos dados de entrada e saída? Com que freqüência eles serão enviados ou recebidos? Que precisão devem ter? Com que grau de precisão os cáculos devem ser feitos? Qual será o fluxo de dados do sistema/ Existem dados que devem ser mantidos por algum tempo?

19 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Recursos Que materiais, pessoal ou outros recursos são necessários para construir, utilizar e manter o sistema? Que habilidades os desenvolvedores devem ter? quanto espaço físico será ocupado pelo sistema? Quais são os requisitos quanto à energia, ao aquecimento ou condicionamento de ar?

20 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Recursos Existe um cronograma definido para o desenvolvimento? Existe um limite de custo para o desenvolvimento ou para a aquisição de hardware ou software?

21 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Segurança O acesso ao sistema ou às informações deve ser controlado? Como os dados de um usuário serão isolados dos de outros usuários? Como os programas dos usuários serão isolados de outros programas e do sistema operacional? Com que freqüência será feito o backup dos sistema?

22 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Segurança As cópias de segurança devem ser armazenadas em um local diferente? Devem ser tomadas precauções contra fogo, danos provocados pela água, ou ocorrência de roubo?

23 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Garantia da qualidade Quais são os requisitos quanto a confiabilidade, disponibilidade, manutenibilidade, segurança e outros atributos de qualidade? Como as características do sistema devem ser demonstrada para os outros? O sistema deve detectar e isolar defeitos? Qual é o tempo médio entre falhas, que foi determinado? Existe um tempo máximo permitido para reiniciar o sistema, depois de uma falha?

24 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Garantia da qualidade Como o sistema pode incorporar modificações no projeto? A manutenção meramente corrigirá os erros ou também incluirá o aprimoramento do sistema? Que medidas de eficiência serão aplicadas à utilização dos recursos e ao tempo de resposta? Com que facilidade o sistema se deslocará de um local para outro, ou de um tipo de computador para outro?

25 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Fontes de Requisitos

26 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Características dos Requisitos Estão corretos? São consistentes? Estão completos? São realistas? Cada requisito descreve algo necessário ao cliente? Podem ser verificados? Podem ser rastreados?

27 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Estão Corretos? Engenheiros de software, analistas de sistemas, clientes e outros envolvidos devem analisar os requisitos para garantir que eles foram definidos sem erros.

28 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 São Consistentes? Por exemplo, se um requisito informa que, no máximo, 10 usuários podem utilizar o sistema ao mesmo tempo, e outro requisito diz que, em certa situação, pode haver 20 usuários simultaneamente, esses requisitos são inconsistentes. Dois requisitos são inconsistente, se for impossível satisfazer aos dois simultaneamente.

29 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Estão Completos? O conjunto de requisitos é completo, se todos os possíveis estados, mudança de estado, entradas, produtos e restrições estiverem descritos por algum requisito. Diz que a descrição de um sistema é externamente completa, se a descrição contém todas as propriedades do ambiente desejado pelo cliente. É internamente completa, se não houver referências indefinidas entre os requisitos.

30 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 São Realistas? O que o cliente está pedindo pode realmente ser feito pelo sistema. Todos os requisitos deverão ser analisados, a fim de assegurar que eles sejam possíveis.

31 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Descreve algo necessário para o cliente? Algumas vezes, um requisito limita os desenvolvedores desnecessariamente ou inclui funções que não estão diretamente relacionadas com o problema em questão. Deve-se rever os requisitos, de forma a manter somente requisitos que atuam diretamente na resolução do problema do cliente.

32 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Podem ser Verificados? Planejar testes que demonstrem que os requisitos foram satisfeitos.

33 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Podem ser Rastreados? Cada função do sistema pode ser rastreada para um conjunto de requisitos que a exige? É fácil identificar o conjunto de requisitos que trata de um aspecto específico do sistema?

34 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Como expressar os requisitos Descrições estáticas Não descreve como os relacionamentos se modificam ao longo do tempo. Uma descrição do sistema lista as entidades ou os objetos do sistema, seus atributos e seus relacionamentos com cada um dos outros.

35 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Maneiras de descrever um sistema estaticamente Referência indireta: um sistema pode ser descrito com uma referência indireta ao problema e sua solução estar implícita e não declarada. Relações de recorrência :uma condição inicial é definida, e a transformação de uma certa condição na condição seguinte é descrita em termos das condições previamente definidas. (sistema que acompanha a disseminação de uma doença)

36 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Maneiras de descrever um sistema estaticamente Definição axiomática: adequado para o desenvolvimento de sistemas especialistas, uma vez que o comportamento de tal sistema envolve a geração de novas informações a partir de declarações de conhecimento básico sobre um assunto específico. Expressão como uma linguagem: linguagem de programação, por exemplo.

37 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Maneiras de descrever um sistema estaticamente Abstração de Dados: é uma técnica para descrever para que servem os dados, em vez de como eles se parecem ou de que modo são chamados.

38 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abstração de dados

39 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Figura 4.4

40 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Descrição Dinâmica Quando se descreve um sistema em termos das relações entre suas entidades, não há um modo fácil de explicar como o sistema reage às coisas que modificam o seu comportamento em determinado período. Por isso os engenheiros de software tem desenvolvido técnicas para visualizar o sistema em termos de mudanças que ocorrem com o decorrer do tempo.

41 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Descrição Dinâmica Tabelas de Decisão: algumas vezes, é conveniente descrever um sistema como um conjunto de condições possíveis, satisfeitas pelo sistema em determinado momento, de regras para reagir aos estímulos quando certos conjuntos de condições são satisfeitas, e de ações a serem tomadas, como resultado.

42 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Descrições dinâmicas: caso de admissão de calouros - EUA Tabelas de decisão

43 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Descrição Dinâmica Descrição Funcional e diagramas de transição: pode-se visualizar um sistema de maneira semelhante a um conjunto de estados, em que o sistema reage a certos eventos possíveis.

44 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Descrição Dinâmica

45 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Descrições dinâmicas Descrição funcional e tabelas de transição

46 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Descrições dinâmicas: notação em UML

47 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Descrições dinâmicas: diagrama de transição para reservas de hotel

48 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Descrições dinâmicas Tabelas de eventos: pode-se representar os estados e as transições de um sistema em uma forma tabular diferente.

49 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Descrições dinâmicas Tabelas de eventos

50 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Descrições dinâmicas Redes de Petri: quando diversos eventos ocorrem de uma vez, algumas vezes um sistema deve realizar processamento paralelo. (emergência de um hospital)

51 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos Muito se tem pesquisado segundo este enfoque, que representa o mundo real com objetos e suas interações. Busca-se a solução dos problemas através de uma modelagem orientada a objetos, conforme mostra a Figura a seguir.

52 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos

53 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos Na AOO a interação entre o usuário e o sistema é baseada em mensagens, que correspondem, na análise estruturada moderna, à associação dos fluxo de dados com os eventos que documentam as solicitações do usuário.

54 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos Os grandes problemas da análise de sistemas em quase todos os sistemas estão relacionados com: a compreensão do domínio do problema, comunicação dos fatos, evolução contínua e reutilização. O desenvolvedor precisa compreender e modelar o domínio do problema, especialmente no caso de sistemas grandes e complexos. A partir do domínio do problema, concentrar-se-á nos aspectos específicos do seu problema, ou seja, na descrição das responsabilidades do sistema que está sendo considerado, estabelecendo dessa forma as fronteiras do sistema.

55 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos Foco está nos dados e nas operações sobre os dados, e não sobre procedimentos. É baseada na modelagem de objetos do mundo real. Concentra-se, basicamente, na visão externa do objeto separando seu comportamento de sua implementação (abstração) Consiste em capturar as informações essenciais das entidades ou objetos envolvidos no contexto do sistema sendo desenvolvido. (abstração)

56 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos O que é um objeto?  Uma entidade que você pode reconhecer  Uma abstração de um objeto do mundo real  Uma estrutura composta de dados (“estado local”) e operações (executa processamentos)  Recebe e envia mensagens.

57 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos Exemplo de objeto: empregado de uma firma Estado:Todo empregado tem um nome, carteira de identidade, CIC, endereco, seção na qual trabalha, salário, etc. Comportamento: Pode-se alterar o salário de um empregado, imprimir seu endereço, etc.

58 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos Exemplo de objeto abstrato: Lista Estado Número de elementos. Elementos componentes Comportamento Elementos podem ser inseridos e removidos. Consultar informação exemplos de uso: agenda telefônica; cadastro de produtos; lista de espera de um vôo...

59 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos

60 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos Cada entidade no sistema é um objeto. Um método ou uma operação é uma ação que pode ser realizada pelo objeto ou pode acontecer com o objeto. Usuário CLASSE: USUÁRIO DADOS OPERAÇÕES

61 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos Encapsulamento: maneira pela qual os métodos formam um limite de proteção em torno do objeto (os objetos podem ser manipulados somente por meio de seus métodos)

62 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos - Encapsulamento

63 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos Hierarquias de classe de objetos estimulam a herança.

64 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos Herança é o mecanismo para expressar a similaridade entre Classes, simplificando a definição de Classes iguais a outras que já foram definidas. Este princípio permite representar membros comuns, serviços e atributos uma só vez, assim como especializar estes membros em casos específicos.

65 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos

66 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos

67 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Abordagem orientada a objetos Polimorfismo: mesmo método para diferentes objetos, cada qual com diferentes comportamentos

68 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 MODELAGEM DE SISTEMAS MODELAR UM SISTEMA significa identificar seus componentes, suas características e comportamentos e o relacionamento entre estes componentes. Em sistemas OO: Componentes = Entidades Características = Atributos Comportamento = Métodos Relacionamento = Mensagens

69 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Notações de requisitos adicionais Diagramas de fluxo de dados: o diagrama mostra os dados que fluem para dentro do sistema, como eles são transformados e como eles saem do sistema. A ênfase é sempre no fluxo dos dados, não no fluxo de controle. Veja alguns símbolos usados para construir um diagrama:

70 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Notações de requisitos adicionais

71 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Notações de requisitos adicionais

72 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Prototipação de requisitos Protótipo descartável: exploratório Protótipo evolutivo: base de uma parte ou todo o software (protótipo para interface) Protótipo rápido: entender os requisitos o decidir sobre o projeto final.

73 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Documentação de requisitos Documento de definição de requisitos: o que o cliente gostaria de ver:  propósito geral  fundamentos e objetivos de desenvolvimento do sistema  descrição da abordagem  características detalhadas  ambiente operacional Documento de especificação de requisitos: o que o desenvolvedor precisa saber

74 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Participantes no processo de requisitos Monitores do contrato Clientes e usuários Gerentes de negócios Projetistas Testadores

75 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4

76 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4

77 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 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

78 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Escolhendo uma técnica de especificação de requisitos Aplicabilidade Possibilidade de implementação Testabilidade/simulação Avaliabilidade Manutenibilidade Modularidade Nível de abstração/expressividade Solidez Verificabilidade Segurança durante a execução Maturidade da ferramenta Imprecisão Curva de aprendizado Maturidade técnica Modelagem de dados Disciplina

79 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Fechando o Semestre!!! A engenharia de software depende muito mais das pessoas do que das fórmulas complicadas, como ocorre nas demais engenharias. O conhecimento dos princípios da orientação a objetos é de fundamental importância, principalmente porque nos ajuda a pensar em objetos e não apenas em dados ou funções, como era no paradigma tradicional de desenvolvimento de software.

80 Prentice Hall Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 4 Bibliografia PFLEEGER, Shari Lawrence. Engenharia de Software. Ed: Prentice Hall. São Paulo, 2004. Cap. 4 Identificando Requisitos