IDENTIFICANDO
REQUISITOS
ENGENHARIA DE SOFTWARE
Prof.: José Eduardo Freire
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:
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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%
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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:
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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)
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Requisitos funcionais versus nãofuncionais


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
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger


Capítulo 4
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
Prentice Hall
Tipos de requisitos









Ambiente físico
Interfaces
Usuários e fatores humanos
Funcionalidade
Documentação
Dados
Recursos
Segurança
Garantia de qualidade
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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?
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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?
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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?
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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?
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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?
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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?
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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?
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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?
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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?
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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?
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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?
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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?
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Fontes de Requisitos
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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?
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Podem ser Verificados?

Planejar testes que demonstrem que os
requisitos foram satisfeitos.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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?
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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)
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Abstração de dados
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Figura 4.4
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Descrições dinâmicas: caso de
admissão de calouros - EUA

Tabelas de decisão
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Descrição Dinâmica
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Descrições dinâmicas

Descrição funcional e tabelas de transição
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Descrições dinâmicas: notação em UML
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Descrições dinâmicas: diagrama de transição para reservas de hotel
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Descrições dinâmicas

Tabelas de eventos: pode-se representar os
estados e as transições de um sistema em
uma forma tabular diferente.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Descrições dinâmicas

Tabelas de eventos
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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)
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Abordagem orientada a objetos
M undo
dos
Objetos
Modelagem
Problemas
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Sistemas
Capítulo 4
Soluções
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
(abstração)
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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...
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Abordagem orientada a objetos
classe Pessoa
objeto Maria
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
objeto Pedro
Capítulo 4
Prentice Hall
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
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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)
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Abordagem orientada a objetos Encapsulamento
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Abordagem orientada a objetos

Hierarquias de classe de objetos estimulam a
herança.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Abordagem orientada a objetos
Pessoa
Estudante
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Professor Funcionário
Capítulo 4
Diretor
Prentice Hall
Abordagem orientada a objetos
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Abordagem orientada a objetos

Polimorfismo: mesmo método para diferentes
objetos, cada qual com diferentes
comportamentos
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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:
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Notações de requisitos adicionais
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Notações de requisitos adicionais
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Participantes no processo de requisitos





Monitores do contrato
Clientes e usuários
Gerentes de negócios
Projetistas
Testadores
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
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
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
•
•
•
•
•
•
•
•
Capítulo 4
Verificabilidade
Segurança durante a execução
Maturidade da ferramenta
Imprecisão
Curva de aprendizado
Maturidade técnica
Modelagem de dados
Disciplina
Prentice Hall
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.
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall
Bibliografia


PFLEEGER, Shari Lawrence. Engenharia de
Software. Ed: Prentice Hall. São Paulo, 2004.
Cap. 4 Identificando Requisitos
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 4
Prentice Hall