SlideShare uma empresa Scribd logo
Princípios Fundamentais da Análise de Requisitos Marcelo Augusto Santos Turine
O ciclo de vida clássico Engenharia de Sistemas Análise Projeto Codificação Teste Manutenção
Uma compreensão completa dos  Requisitos do Software  é fundamental para obter um software e um processo de desenvolvimento com alta qualidade Não importa quão bem projetado ou codificado está um programa, se ele for mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor
Fase de Análise de Requisitos Escopo do Software Primeiro passo técnico Analista de Sistemas PONTE ANÁLISE DE REQUISITOS Engenharia de Sistemas de Computador Projeto de Software
Análise de Requisitos processo de descoberta e refinamento ATORES:  cliente e desenvolvedor Cliente: reformula um conceito de função e desempenho (às vezes nebuloso) Desenvolvedor: indagador e solucionador de problemas PROBLEMA:  grande propensão a mal entendidos " atividade aparentemente simples torna-se complexa "
Definição: Requisitos e Especificação Glossário de Engenharia de Software (IEEE) e do Aurélio Requisito (IEEE) Uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo Uma condição ou capacidade que deve ser satisfeita por um sistema para satisfazer um contrato ou um padrão
Requisito (Aurélio) Condição necessária para a obtenção de certo objetivo, ou para o preenchimento de certo fim Especificação : descrição rigorosa e minuciosa das características que um material, uma obra, ou um serviço deverá apresentar processo de representação dos requisitos de uma forma que leva à implementação bem-sucedida
Exemplos “ O sistema deve rodar em microcomputadores da linha IBM PC que possuam microprocessador 486 DX ou superior.” “ A interface do sistema deve ser gráfica, de acordo com um padrão de interface dirigida a menu.” “ Alternativamente, o sistema deve possibilitar o seu uso através de linhas de comando, para usuários avançados.”
Tipos de Requisitos  (divisão utilizada na literatura) Funcionais Não Funcionais (de Qualidade) ISO  -   The International Organization for Standardizatized IEC  - The International Electrotechnical Commition (formam o sistema especializado para padronização mais conhecido)
Requisitos de Software A Norma ISO/IEC 9126 define seis características de qualidade de software que devem ser avaliados: Funcionalidade  (finalidade do produto)  Usabilidade  (esforço para utilizar, aprender o produto) Confiabilidade  (freqüência de falhas, recuperabilidade) Eficiência  (desempenho) Manutenibilidade  (esforço necessário para modificar) Portabilidade  (capacidade de transferir o produto para outros ambientes)
fase de Análise de Requisitos elementos alocados ao software determinar domínio das informações e das funções, interfaces, restrições de projeto e critérios de validação construir protótipo para estabelecer os requisitos os requisitos são conhecidos? revisão administrativa Plano de Desenvolvimento do Software estabelecimento do alcance recursos, custo cronograma revisar  e  justificar recursos, custos  e  cronogramas Especificação dos Requisitos do Software início da fase de desenvolvimento revisão aceitável   revisão  não   sim   revisão  técnica revisão do plano de projeto do software aceitável   aceitável
Dilema do Engenheiro de Software Declaração de um cliente anônimo: “ Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer ... ”
ATIVIDADES de ANÁLISE:   1  -  reconhecimento do problema   2   -  avaliação do problema e síntese da solução ( Modelagem ) 3  -   especificação dos requisitos do  software 4  -   r evisão
Atividade 1    Reconhecimento do Problema A meta é o reconhecimento dos  elementos básicos do problema, conforme percebidos pelo cliente.  clientes Administrador do projeto analista desenvolvedores Plano de projeto  de software Espec. requisitos  de software protótipo
Atividade 2    Avaliação  do Problema e Síntese da Solução Avaliar os problemas na situação atual Principal Foco para o novo sistema:  O QUE e não COMO : - qual o fluxo e o conteúdo de informação - quais as funções do sistema - quais dados que o sistema produz e consome  - qual o comportamento do sistema - qual as características de interface - quais são as restrições do projeto
Avaliação  do Problema e Síntese da Solução Sintetizar uma ou mais soluções  (dentro do alcance delineado no  Plano de Projeto do Software ) O processo de avaliação e síntese continua até que o analista e o cliente concordem que o software pode ser adequadamente especificado. É a maior área de esforço
Modelagem Durante a atividade de avaliação e síntese devem ser criados  modelos do sistema   para se compreender melhor o fluxo de dados e de controle, o processamento funcional e a operação comportamental, além do conteúdo da informação. O modelo serve como fundamento para o projeto de software e como base para a criação de sua especificação
Atividade 3    Especificação  de Requisitos  Definição de  Especificação :  descrição rigorosa e minuciosa das características que um material, uma obra ou um serviço deverão apresentar descrição do fluxo e estrutura da informação refinamento detalhado de todas as funções do software estabelecimento das características de interface identificação das restrições de projeto especificação dos critérios de validação
Atividade 4    Revisões  Devem ser efetuadas revisões técnicas e revisões no Plano de Projeto de Software as revisões são conduzidas pelo Cliente e pelo Desenvolvedor a base para a revisão são os documentos produzidos na Especificação dos Requisitos O Plano de Projeto do Software deve ser revisto  devido ao conhecimento adquirido durante  a análise.
Analista de Sistemas Engenheiro de Sistemas Projetista de sistemas-chefe Programador/Analista
Características do Analista de Sistemas - Capacidade para compreender conceitos abstratos, reorganizar esses conceitos em divisões lógicas e sintetizar "soluções" baseado em cada divisão. 2- Capacidade de absorver fatos pertinentes a partir de fontes conflitantes ou confusas. 4- Capacidade de se comunicar bem de forma escrita e verbal. 5- Capacidade de " ver a floresta ao invés das árvores ”     (não se perder nos detalhes)
Papel do Analista de Sistemas 1- Coordenar cada uma das atividades da Análise de Requisitos de Software - comunicação com cliente - convoca pessoal de desenvolvimento durante avaliação e síntese 2- Responsável pelo desenvolvimento do documento de Especificação de Requisitos do Software e participa de todas as revisões
Áreas Problemas 1.  Aquisição da Informação 2.  Tamanho do Sistema  	 (complexidade dos problemas) 3.  Alterações (mudanças que ocorrem durante e após a análise)
Áreas Problemas 1. Aquisição da informação que informação deve ser coletada e como ela deve ser representada? quem fornece as informações? que técnicas e ferramentas estão disponíveis para facilitar a coleta de informações?
Áreas Problemas 2. Tamanho do sistema como eliminar inconsistências na especificação de grandes sistemas? é possível detectar omissões? pode um grande sistema ser efetivamente particionado para que se torne intelectualmente administrável?
Áreas Problemas 3. Alterações como as alterações efetuadas em outros elementos do software são coordenadas com os requisitos do software? como se determina o impacto de uma alteração em outras partes do software aparentemente não relacionadas? como se corrige erros na especificação para que não se gere efeitos colaterias?
Causas dos Problemas   comunicação ineficiente técnicas e ferramentas inadequadas  (especificação inadequada e imprecisa) tendências de se eliminar a tarefa de Especificação dos Requisitos falhas ao considerar alternativas antes que o software seja especificado
Abordagem de Engenharia de Software Aplicação de técnicas de comunicação sólidas Princípios de análise fundamentais Métodos de análise sistemáticos reduzirão o impacto dos problemas
Problema cuja solução é baseada em computador Responde ao pedido de ajuda  do cliente
Princípios Fundamentais de Análise domínio de informação   do problema      representado e compreendido  (para que a função possa ser entendida +  completamente ) modelos   que descrevam a informação, a função e o comportamento do sistema      desenvolvidos   (para que a informação possa ser comunicada  compactamente )
Princípios de Análise modelos (e o problema)     particionados ,  de maneira que revele os detalhes em forma de camadas (ou hierarquicamente)  (para reduzir a complexidade) processo de análise      mover-se da informação  essencial para os detalhes   de implementação  (para acomodar as restrições lógicas impostas por requisitos de processamento e as restrições físicas impostas por outros elementos do sistema) =  (Concepções lógicas e físicas)
1   princípio:   Domínio da Informação Todo software é construído para processar  dados  e  eventos .  Dados:  software embutido de tempo real para controlar o fluxo de combustível no motor de automóvel Eventos:  um sensor de pressão detecta que a pressão ultrapassa determinado valor de segurança e envia um sinal de alarme para o software de monitoração
1   princípio:   Domínio da Informação Os dados e itens de controle residem no  domínio   de informação  de um problema. Encerra 3 diferentes pontos de vista: Fluxo  Conteúdo  Estrutura da informação
Fluxo da Informação :   maneira pela qual os dados e o controle se modificam à medida que cada um se movimenta pelo sistema Conteúdo da Informação :   os dados e os itens de controle individuais que compreendem certo item de informação mais amplo. - o conteúdo do item de dados  cheque de pagamento  é definido pelos itens que são necessários para criá-lo: nome do recebedor, quantidade líquida a ser paga, pagamento bruto, etc. Estrutura da Informação :  a organização interna de vários itens de controle e de dados 1   princípio:  Domínio da Informação
2. princípio:   Modelagem  Modelos: melhor compreensão da entidade real a ser construída Entidade é física (prédio): modelo idêntico, mas em escala menor Entidade é software: o modelo deve ser capaz de modelar a informação que o software transforma as funções (ou subfunções) que possibilitam que as transformações ocorram o comportamento do sistema quando a transformação está se desenvolvendo.
2. princípio:   Modelagem  Os modelos concentram-se naquilo que o sistema deve fazer, não em como ele faz. Modelos fazem uso de notação gráfica e textual Os métodos de análise discutidos nos capítulos seguintes são métodos de modelagem Atividade de Modelagem é fundamental ao bom trabalho da análise
2. princípio:   Modelagem Papéis importantes do Modelo: 1) ajuda o analista a  entender a informação, a função e o comportamento  de um sistema, tornando a tarefa + fácil e sistemática. 2) torna-se o  ponto focal para a revisão  e, portanto, a chave para a determinação da completitude, consistência e precisão da especificação. 3) torna-se  a base para o projeto , fornecendo ao projetista uma representação essencial do software, a qual pode ser "mapeada" num contexto de implementação.
3. princípio:   Particionamento  (decomposição)   Os problemas freqüentemente são grandes demais e muito complexos para serem compreendidos como um todo. O particionamento divide o problema em partes mais facilmente entendidas Através das interfaces estabelecidas entre as partes a função global do software pode ser executada.
Particionamento Horizontal: decomposição funcional do problema Particionamento Vertical: expõe detalhes crescentes 3   princípio:  Particionamento  Particionamento horizontal
4   princípio:   Concepções essenciais e de implementação A  concepção essencial  dos requisitos do software apresenta as funções a serem realizadas sem tratar dos detalhes de implementação. Ao se concentrar atenção na essência do problema nas primeiras etapas da análise de requisitos, deixa-se as opções abertas para especificar detalhes de implementação durante as últimas etapas de especificação dos requisitos e projeto de software.
A  concepção de implementação  dos requisitos de software apresenta a manifestação das funções de processamento e estruturas de informação no mundo real. Não deve ser interpretada como uma representação do como. Um modelo de implementação representa o modo de operação corrente, ou seja a atribuição existente ou proposta para todos os elementos do sistema. 4   princípio:   Concepções essenciais e de implementação
Especificação de Requisitos de Software Desenvolvida como uma conseqüência da fase de análise de requisitos Serve como um padrão para testar se as fases de projeto e implementação do processo de desenvolvimento de software estão corretas
Princípios de uma boa especificação   (Balzer e Goldman) 1.   Separe  funcionalidade de implementação 2.   É necessária uma linguagem de especificação de sistemas orientada ao processo 3.  A especificação deve abranger o sistema do qual o software é um componente 4.  Uma especificação deve abranger o ambiente no qual o sistema opera 5.  Uma especificação de sistema deve ser um modelo cognitivo 6.  Uma especificação deve ser operacional 7.  A especificação do sistema deve ser tolerante com a não completitude e ser expansível 8.  Uma especificação deve ser localizada e fracamente acoplada.
A Especificação pode ser acompanhada de um  PROTÓTIPO  executável (ou em papel)  e/ou um  MANUAL PRELIMINAR DE USUÁRIO.
Revisão da Especificação ( nível macroscópico)   Os revisores tentam garantir que a especificação seja completa, consistente e precisa.  Questões : Metas e objetivos do software permanecem consistentes com metas e objetivos do sistema? Foram descritas as interfaces importantes para todos os elementos do sistema? O fluxo e a estrutura de informação são adequadamente definidas para o domínio da informação? Os diagramas são claros?
As funções importantes permanecem dentro do escopo e cada uma foi adequadamente descrita? O comportamento do software é consistente com a informação que ele deve processar e as funções que deve executar? As restrições de projeto são realísticas? Qual é o risco tecnológico desenvolvimento? Requisitos de software alternativos foram considerados? Critérios de Validação foram declarados detalhadamente? Eles são adequados para descrever um sistema bem sucedido? Existem inconsistências, omissões ou redundâncias? O usuário revisou o Manual Preliminar ou o protótipo? Como as estimativas do Plano de projeto de Software foram afetadas? Revisão da Especificação ( nível macroscópico)
Revisão da Especificação ( nível  detalhado ) A preocupação é com o enunciado da especificação. Tenta-se descobrir problemas que possam estar ocultos no conteúdo da especificação Diretrizes: Esteja alerta para perceber conectivos persuasivos (certamente, claramente, obviamente ) e perguntar por que eles estão presentes. Procure termos vagos e peça esclarecimento (algum, às vezes, usualmente, freqüentemente) Quando forem fornecidas listas que não sejam completas, certifique-se de que todos os itens sejam entendidos (evite colocar etc, tal como, assim por diante)
Revisão da Especificação ( nível  detalhado ) Esteja certo de que os limites declarados não contenham pressuposições não declaradas (“os códigos válidos variam de 0 a 100” - números inteiros, reais???) Cuidado com verbos vagos. Há muitas maneiras de interpretá-los. (manuseado, rejeitado, pulado, processado) Cuidado com pronomes "pendentes” (o módulo I/O comunica-se com o módulo de validação de dados e seu sinal de controle está ligado. Sinal de controle de qual?).  Procure declarações que impliquem certeza (sempre, cada, todos, nunca) e depois peça prova
Revisão da Especificação ( nível  detalhado ) Quando um termo for explicitamente definido num lugar, evite utilizar outras definições para o mesmo termo (normalização dos termos: documento - arquivo) Quando uma estrutura for descrita em palavras, verifique se há um gráfico ou uma figura para auxiliar a compreensão Quando um cálculo for especificado, desenvolva pelo menos dois exemplos.
Ferramentas de Especificação Automatizadas 1 a  categoria:  técnicas automatizadas que nada mais são do que um método manual que foi complementado com uma ferramenta CASE Possibilitam que o analista atualize informações e rastreie as conexões entre representações novas e existentes do sistema Ex:  DEC Design  ( Digital Equipment Corp .),  Design Aid  ( Transform Logic Corp .),  Excelerator  ( Intersolv ),  IEF  ( Texas Instruments ),  ADW  ( Knowledgeware ),  STP  ( Interative Development Environments ),  Teamwork  ( Cadre Technologies ).
2 a  categoria:  técnicas automatizadas que fazem uso de uma notação especial (na maioria dos casos, essa é uma linguagem de especificação de requisitos) que foi explicitamente projetada para processamento usando-se uma ferramenta automatizada. Ex:  SREM  (linguagem de especificação: RSL),  PSL/PSA  (linguagem  de especificação: PSL),  TAGS  (linguagem  de especificação: IORL) Ferramentas de Especificação Automatizadas
Análise de Requisitos   Conclusão Logo que a Revisão for concluída, a Especificação de Requisitos de Software é " assinada " pelo cliente e pelo desenvolvedor A especificação torna-se um " contrato " de desenvolvimento de software.  Mudanças solicitadas depois que a Espec.  for concluída serão consideradas,  porém cada mudança posterior pode aumentar o custo e/ou alongar o prazo de entrega Mesmo com os melhores procedimentos de revisão em andamento, uma série de problemas de especificação ainda persiste

Mais conteúdo relacionado

Mais procurados

Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
Estêvão Bissoli Saleme
 
Metodologias ágeis de desenvolvimento de software por Givanaldo Rocha
Metodologias ágeis de desenvolvimento de software por Givanaldo RochaMetodologias ágeis de desenvolvimento de software por Givanaldo Rocha
Metodologias ágeis de desenvolvimento de software por Givanaldo Rocha
Fernando Palma
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
Mailson Queiroz
 
Aula 1 requisitos
Aula 1   requisitosAula 1   requisitos
Aula 1 requisitos
licardino
 
Aula 1 - Introdução a POO
Aula 1 -  Introdução a POOAula 1 -  Introdução a POO
Aula 1 - Introdução a POO
Daniel Brandão
 
Conceitos de básicos de qualidade de software
Conceitos de básicos de qualidade de softwareConceitos de básicos de qualidade de software
Conceitos de básicos de qualidade de software
Ronney Moreira de Castro
 
Levantamento Ágil de Requisitos
Levantamento Ágil de RequisitosLevantamento Ágil de Requisitos
Levantamento Ágil de Requisitos
Paulo Furtado
 
Aula 01 - Introdução ao Sistema de Informação
Aula 01 - Introdução ao Sistema de InformaçãoAula 01 - Introdução ao Sistema de Informação
Aula 01 - Introdução ao Sistema de Informação
Daniel Brandão
 
Modelos de Engenharia de Software
Modelos de Engenharia de SoftwareModelos de Engenharia de Software
Modelos de Engenharia de Software
Nathalia Sautchuk Patricio
 
Modelo de Prototipação
Modelo de PrototipaçãoModelo de Prototipação
Modelo de Prototipação
Juliano Pires
 
Aula1 e aula2 - Analise e Projeto de Sistemas
Aula1 e aula2 - Analise e Projeto de SistemasAula1 e aula2 - Analise e Projeto de Sistemas
Aula1 e aula2 - Analise e Projeto de Sistemas
Gustavo Gonzalez
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
Marcelo Yamaguti
 
Eng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. RequisitosEng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. Requisitos
Manuel Menezes de Sequeira
 
Aula3 engenharia requisitos
Aula3 engenharia requisitosAula3 engenharia requisitos
Aula3 engenharia requisitos
Computação Depressão
 
Modelo Incremental - Engenharia de Software
Modelo Incremental - Engenharia de SoftwareModelo Incremental - Engenharia de Software
Modelo Incremental - Engenharia de Software
Daniela Franciosi
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
Tiago Antônio da Silva
 
Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
Joeldson Costa Damasceno
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
Mauricio Cesar Santos da Purificação
 
Introdução à Análise de Sistemas
Introdução à Análise de SistemasIntrodução à Análise de Sistemas
Introdução à Análise de Sistemas
Nécio de Lima Veras
 
UML
UMLUML

Mais procurados (20)

Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Metodologias ágeis de desenvolvimento de software por Givanaldo Rocha
Metodologias ágeis de desenvolvimento de software por Givanaldo RochaMetodologias ágeis de desenvolvimento de software por Givanaldo Rocha
Metodologias ágeis de desenvolvimento de software por Givanaldo Rocha
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
 
Aula 1 requisitos
Aula 1   requisitosAula 1   requisitos
Aula 1 requisitos
 
Aula 1 - Introdução a POO
Aula 1 -  Introdução a POOAula 1 -  Introdução a POO
Aula 1 - Introdução a POO
 
Conceitos de básicos de qualidade de software
Conceitos de básicos de qualidade de softwareConceitos de básicos de qualidade de software
Conceitos de básicos de qualidade de software
 
Levantamento Ágil de Requisitos
Levantamento Ágil de RequisitosLevantamento Ágil de Requisitos
Levantamento Ágil de Requisitos
 
Aula 01 - Introdução ao Sistema de Informação
Aula 01 - Introdução ao Sistema de InformaçãoAula 01 - Introdução ao Sistema de Informação
Aula 01 - Introdução ao Sistema de Informação
 
Modelos de Engenharia de Software
Modelos de Engenharia de SoftwareModelos de Engenharia de Software
Modelos de Engenharia de Software
 
Modelo de Prototipação
Modelo de PrototipaçãoModelo de Prototipação
Modelo de Prototipação
 
Aula1 e aula2 - Analise e Projeto de Sistemas
Aula1 e aula2 - Analise e Projeto de SistemasAula1 e aula2 - Analise e Projeto de Sistemas
Aula1 e aula2 - Analise e Projeto de Sistemas
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Eng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. RequisitosEng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. Requisitos
 
Aula3 engenharia requisitos
Aula3 engenharia requisitosAula3 engenharia requisitos
Aula3 engenharia requisitos
 
Modelo Incremental - Engenharia de Software
Modelo Incremental - Engenharia de SoftwareModelo Incremental - Engenharia de Software
Modelo Incremental - Engenharia de Software
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
 
Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
 
Introdução à Análise de Sistemas
Introdução à Análise de SistemasIntrodução à Análise de Sistemas
Introdução à Análise de Sistemas
 
UML
UMLUML
UML
 

Destaque

Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
Rildo (@rildosan) Santos
 
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Rosanete Grassiani dos Santos
 
Princípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de RequisitosPrincípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de Requisitos
elliando dias
 
Especificação de requisitos
Especificação de requisitosEspecificação de requisitos
Especificação de requisitos
Fernando Palma
 
Análise e Projeto de Sistemas
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Análise e Projeto de Sistemas
Guilherme
 
Engenharia de software apostila analise de requisitos i
Engenharia de software   apostila analise de requisitos iEngenharia de software   apostila analise de requisitos i
Engenharia de software apostila analise de requisitos i
robinhoct
 
Requisitos Nao Funcionais
Requisitos Nao FuncionaisRequisitos Nao Funcionais
Requisitos Nao Funcionais
guesta36ce2
 
Fundamentos de Engenharia de Requisitos
Fundamentos de Engenharia de RequisitosFundamentos de Engenharia de Requisitos
Fundamentos de Engenharia de Requisitos
Barbara Lima
 
Gerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoes
Gerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoesGerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoes
Gerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoes
Jucioliver
 
Engenharia de software 7° edição roger s.pressman referência
Engenharia de software 7° edição roger s.pressman referênciaEngenharia de software 7° edição roger s.pressman referência
Engenharia de software 7° edição roger s.pressman referência
Lindomar ...
 
A importância da análise de requisitos e casos de uso
A importância da análise de requisitos e casos de usoA importância da análise de requisitos e casos de uso
A importância da análise de requisitos e casos de uso
Hussani Oliveira
 
Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de Software
Robson Silva Espig
 
Métricas de Software
Métricas de SoftwareMétricas de Software
Métricas de Software
elliando dias
 
Métricas de software: modelos de contratação e planejamento de projetos
Métricas de software: modelos de contratação e planejamento de projetosMétricas de software: modelos de contratação e planejamento de projetos
Métricas de software: modelos de contratação e planejamento de projetos
José Claudemir Pacheco Júnior
 
Software de qualidade e qualidade de código
Software de qualidade e qualidade de códigoSoftware de qualidade e qualidade de código
Software de qualidade e qualidade de código
Guilherme Silveira
 
Java pra web mais fácil com MVC
Java pra web mais fácil com MVCJava pra web mais fácil com MVC
Java pra web mais fácil com MVC
Cecilia Fernandes
 
Apostila Java Web (Servlets e JSPs)
Apostila Java Web (Servlets e JSPs)Apostila Java Web (Servlets e JSPs)
Apostila Java Web (Servlets e JSPs)
Ricardo Terra
 
T@rget Trust - Formação Análise de Sistemas
T@rget Trust - Formação Análise de SistemasT@rget Trust - Formação Análise de Sistemas
T@rget Trust - Formação Análise de Sistemas
Targettrust
 
Eng.Software-Métricas
Eng.Software-MétricasEng.Software-Métricas
Eng.Software-Métricas
elliando dias
 
Java Web, o Tutorial
Java Web, o TutorialJava Web, o Tutorial
Java Web, o Tutorial
Rildo (@rildosan) Santos
 

Destaque (20)

Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
 
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
 
Princípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de RequisitosPrincípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de Requisitos
 
Especificação de requisitos
Especificação de requisitosEspecificação de requisitos
Especificação de requisitos
 
Análise e Projeto de Sistemas
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Análise e Projeto de Sistemas
 
Engenharia de software apostila analise de requisitos i
Engenharia de software   apostila analise de requisitos iEngenharia de software   apostila analise de requisitos i
Engenharia de software apostila analise de requisitos i
 
Requisitos Nao Funcionais
Requisitos Nao FuncionaisRequisitos Nao Funcionais
Requisitos Nao Funcionais
 
Fundamentos de Engenharia de Requisitos
Fundamentos de Engenharia de RequisitosFundamentos de Engenharia de Requisitos
Fundamentos de Engenharia de Requisitos
 
Gerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoes
Gerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoesGerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoes
Gerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoes
 
Engenharia de software 7° edição roger s.pressman referência
Engenharia de software 7° edição roger s.pressman referênciaEngenharia de software 7° edição roger s.pressman referência
Engenharia de software 7° edição roger s.pressman referência
 
A importância da análise de requisitos e casos de uso
A importância da análise de requisitos e casos de usoA importância da análise de requisitos e casos de uso
A importância da análise de requisitos e casos de uso
 
Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de Software
 
Métricas de Software
Métricas de SoftwareMétricas de Software
Métricas de Software
 
Métricas de software: modelos de contratação e planejamento de projetos
Métricas de software: modelos de contratação e planejamento de projetosMétricas de software: modelos de contratação e planejamento de projetos
Métricas de software: modelos de contratação e planejamento de projetos
 
Software de qualidade e qualidade de código
Software de qualidade e qualidade de códigoSoftware de qualidade e qualidade de código
Software de qualidade e qualidade de código
 
Java pra web mais fácil com MVC
Java pra web mais fácil com MVCJava pra web mais fácil com MVC
Java pra web mais fácil com MVC
 
Apostila Java Web (Servlets e JSPs)
Apostila Java Web (Servlets e JSPs)Apostila Java Web (Servlets e JSPs)
Apostila Java Web (Servlets e JSPs)
 
T@rget Trust - Formação Análise de Sistemas
T@rget Trust - Formação Análise de SistemasT@rget Trust - Formação Análise de Sistemas
T@rget Trust - Formação Análise de Sistemas
 
Eng.Software-Métricas
Eng.Software-MétricasEng.Software-Métricas
Eng.Software-Métricas
 
Java Web, o Tutorial
Java Web, o TutorialJava Web, o Tutorial
Java Web, o Tutorial
 

Semelhante a Analise de Requisitos

Analise sistemas 04
Analise sistemas 04Analise sistemas 04
Analise sistemas 04
Caroline Raquel Rodrigues
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
Roni Reis
 
Aula3 TEES UFS: Engenharia de Requisitos
Aula3 TEES UFS: Engenharia de RequisitosAula3 TEES UFS: Engenharia de Requisitos
Aula3 TEES UFS: Engenharia de Requisitos
Rogerio P C do Nascimento
 
Aula Gestão de Projetos
Aula Gestão de ProjetosAula Gestão de Projetos
Aula Gestão de Projetos
Rudson Kiyoshi Souza Carvalho
 
Introdução à Engenharia de Requisitos
Introdução à Engenharia de RequisitosIntrodução à Engenharia de Requisitos
Introdução à Engenharia de Requisitos
Orlando Junior
 
Ap i unidade 3 - levantamento de requisitos
Ap i   unidade 3 - levantamento de requisitosAp i   unidade 3 - levantamento de requisitos
Ap i unidade 3 - levantamento de requisitos
Glauber Aquino
 
Dfd
DfdDfd
04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt
04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt
04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt
IedaRosanaKollingWie
 
Técnicas de Análise Contextual - Livro de Walter Cybis
Técnicas de Análise Contextual - Livro de Walter CybisTécnicas de Análise Contextual - Livro de Walter Cybis
Técnicas de Análise Contextual - Livro de Walter Cybis
Luiz Agner
 
Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01
Danielle Ballester, PMP,PSM,SFC,SDC,SMC,SPOC,SCT
 
Os aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de RequisitosOs aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de Requisitos
José Vieira
 
Prodemge WTQS - Minicurso técnicas de verificação de requisitos
Prodemge WTQS - Minicurso técnicas de verificação de requisitosProdemge WTQS - Minicurso técnicas de verificação de requisitos
Prodemge WTQS - Minicurso técnicas de verificação de requisitos
Gustavo Lopes
 
Engenharia de software
Engenharia de software Engenharia de software
Engenharia de software
MarcosSilva941136
 
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane FidelixAula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Cris Fidelix
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
Tiago Barros
 
Ciclo de vida processo
Ciclo de vida processoCiclo de vida processo
Ciclo de vida processo
Patrícia Melo
 
Análise de sistemas análise de requisitos
Análise de sistemas   análise de requisitosAnálise de sistemas   análise de requisitos
Análise de sistemas análise de requisitos
Má Puia
 
ASPECTOS DA ENGENHARIA DE REQUISITOS
ASPECTOS DA ENGENHARIA DE REQUISITOSASPECTOS DA ENGENHARIA DE REQUISITOS
ASPECTOS DA ENGENHARIA DE REQUISITOS
Jaffer Veronezi
 
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Danielle Ballester, PMP,PSM,SFC,SDC,SMC,SPOC,SCT
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Cris Fidelix
 

Semelhante a Analise de Requisitos (20)

Analise sistemas 04
Analise sistemas 04Analise sistemas 04
Analise sistemas 04
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Aula3 TEES UFS: Engenharia de Requisitos
Aula3 TEES UFS: Engenharia de RequisitosAula3 TEES UFS: Engenharia de Requisitos
Aula3 TEES UFS: Engenharia de Requisitos
 
Aula Gestão de Projetos
Aula Gestão de ProjetosAula Gestão de Projetos
Aula Gestão de Projetos
 
Introdução à Engenharia de Requisitos
Introdução à Engenharia de RequisitosIntrodução à Engenharia de Requisitos
Introdução à Engenharia de Requisitos
 
Ap i unidade 3 - levantamento de requisitos
Ap i   unidade 3 - levantamento de requisitosAp i   unidade 3 - levantamento de requisitos
Ap i unidade 3 - levantamento de requisitos
 
Dfd
DfdDfd
Dfd
 
04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt
04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt
04 - Reqxxxxxxxxxxxxxxxxxxxxxxxuisitos.ppt
 
Técnicas de Análise Contextual - Livro de Walter Cybis
Técnicas de Análise Contextual - Livro de Walter CybisTécnicas de Análise Contextual - Livro de Walter Cybis
Técnicas de Análise Contextual - Livro de Walter Cybis
 
Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01
 
Os aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de RequisitosOs aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de Requisitos
 
Prodemge WTQS - Minicurso técnicas de verificação de requisitos
Prodemge WTQS - Minicurso técnicas de verificação de requisitosProdemge WTQS - Minicurso técnicas de verificação de requisitos
Prodemge WTQS - Minicurso técnicas de verificação de requisitos
 
Engenharia de software
Engenharia de software Engenharia de software
Engenharia de software
 
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane FidelixAula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Ciclo de vida processo
Ciclo de vida processoCiclo de vida processo
Ciclo de vida processo
 
Análise de sistemas análise de requisitos
Análise de sistemas   análise de requisitosAnálise de sistemas   análise de requisitos
Análise de sistemas análise de requisitos
 
ASPECTOS DA ENGENHARIA DE REQUISITOS
ASPECTOS DA ENGENHARIA DE REQUISITOSASPECTOS DA ENGENHARIA DE REQUISITOS
ASPECTOS DA ENGENHARIA DE REQUISITOS
 
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
 

Mais de elliando dias

Clojurescript slides
Clojurescript slidesClojurescript slides
Clojurescript slides
elliando dias
 
Why you should be excited about ClojureScript
Why you should be excited about ClojureScriptWhy you should be excited about ClojureScript
Why you should be excited about ClojureScript
elliando dias
 
Functional Programming with Immutable Data Structures
Functional Programming with Immutable Data StructuresFunctional Programming with Immutable Data Structures
Functional Programming with Immutable Data Structures
elliando dias
 
Nomenclatura e peças de container
Nomenclatura  e peças de containerNomenclatura  e peças de container
Nomenclatura e peças de container
elliando dias
 
Geometria Projetiva
Geometria ProjetivaGeometria Projetiva
Geometria Projetiva
elliando dias
 
Polyglot and Poly-paradigm Programming for Better Agility
Polyglot and Poly-paradigm Programming for Better AgilityPolyglot and Poly-paradigm Programming for Better Agility
Polyglot and Poly-paradigm Programming for Better Agility
elliando dias
 
Javascript Libraries
Javascript LibrariesJavascript Libraries
Javascript Libraries
elliando dias
 
How to Make an Eight Bit Computer and Save the World!
How to Make an Eight Bit Computer and Save the World!How to Make an Eight Bit Computer and Save the World!
How to Make an Eight Bit Computer and Save the World!
elliando dias
 
Ragel talk
Ragel talkRagel talk
Ragel talk
elliando dias
 
A Practical Guide to Connecting Hardware to the Web
A Practical Guide to Connecting Hardware to the WebA Practical Guide to Connecting Hardware to the Web
A Practical Guide to Connecting Hardware to the Web
elliando dias
 
Introdução ao Arduino
Introdução ao ArduinoIntrodução ao Arduino
Introdução ao Arduino
elliando dias
 
Minicurso arduino
Minicurso arduinoMinicurso arduino
Minicurso arduino
elliando dias
 
Incanter Data Sorcery
Incanter Data SorceryIncanter Data Sorcery
Incanter Data Sorcery
elliando dias
 
Rango
RangoRango
Fab.in.a.box - Fab Academy: Machine Design
Fab.in.a.box - Fab Academy: Machine DesignFab.in.a.box - Fab Academy: Machine Design
Fab.in.a.box - Fab Academy: Machine Design
elliando dias
 
The Digital Revolution: Machines that makes
The Digital Revolution: Machines that makesThe Digital Revolution: Machines that makes
The Digital Revolution: Machines that makes
elliando dias
 
Hadoop + Clojure
Hadoop + ClojureHadoop + Clojure
Hadoop + Clojure
elliando dias
 
Hadoop - Simple. Scalable.
Hadoop - Simple. Scalable.Hadoop - Simple. Scalable.
Hadoop - Simple. Scalable.
elliando dias
 
Hadoop and Hive Development at Facebook
Hadoop and Hive Development at FacebookHadoop and Hive Development at Facebook
Hadoop and Hive Development at Facebook
elliando dias
 
Multi-core Parallelization in Clojure - a Case Study
Multi-core Parallelization in Clojure - a Case StudyMulti-core Parallelization in Clojure - a Case Study
Multi-core Parallelization in Clojure - a Case Study
elliando dias
 

Mais de elliando dias (20)

Clojurescript slides
Clojurescript slidesClojurescript slides
Clojurescript slides
 
Why you should be excited about ClojureScript
Why you should be excited about ClojureScriptWhy you should be excited about ClojureScript
Why you should be excited about ClojureScript
 
Functional Programming with Immutable Data Structures
Functional Programming with Immutable Data StructuresFunctional Programming with Immutable Data Structures
Functional Programming with Immutable Data Structures
 
Nomenclatura e peças de container
Nomenclatura  e peças de containerNomenclatura  e peças de container
Nomenclatura e peças de container
 
Geometria Projetiva
Geometria ProjetivaGeometria Projetiva
Geometria Projetiva
 
Polyglot and Poly-paradigm Programming for Better Agility
Polyglot and Poly-paradigm Programming for Better AgilityPolyglot and Poly-paradigm Programming for Better Agility
Polyglot and Poly-paradigm Programming for Better Agility
 
Javascript Libraries
Javascript LibrariesJavascript Libraries
Javascript Libraries
 
How to Make an Eight Bit Computer and Save the World!
How to Make an Eight Bit Computer and Save the World!How to Make an Eight Bit Computer and Save the World!
How to Make an Eight Bit Computer and Save the World!
 
Ragel talk
Ragel talkRagel talk
Ragel talk
 
A Practical Guide to Connecting Hardware to the Web
A Practical Guide to Connecting Hardware to the WebA Practical Guide to Connecting Hardware to the Web
A Practical Guide to Connecting Hardware to the Web
 
Introdução ao Arduino
Introdução ao ArduinoIntrodução ao Arduino
Introdução ao Arduino
 
Minicurso arduino
Minicurso arduinoMinicurso arduino
Minicurso arduino
 
Incanter Data Sorcery
Incanter Data SorceryIncanter Data Sorcery
Incanter Data Sorcery
 
Rango
RangoRango
Rango
 
Fab.in.a.box - Fab Academy: Machine Design
Fab.in.a.box - Fab Academy: Machine DesignFab.in.a.box - Fab Academy: Machine Design
Fab.in.a.box - Fab Academy: Machine Design
 
The Digital Revolution: Machines that makes
The Digital Revolution: Machines that makesThe Digital Revolution: Machines that makes
The Digital Revolution: Machines that makes
 
Hadoop + Clojure
Hadoop + ClojureHadoop + Clojure
Hadoop + Clojure
 
Hadoop - Simple. Scalable.
Hadoop - Simple. Scalable.Hadoop - Simple. Scalable.
Hadoop - Simple. Scalable.
 
Hadoop and Hive Development at Facebook
Hadoop and Hive Development at FacebookHadoop and Hive Development at Facebook
Hadoop and Hive Development at Facebook
 
Multi-core Parallelization in Clojure - a Case Study
Multi-core Parallelization in Clojure - a Case StudyMulti-core Parallelization in Clojure - a Case Study
Multi-core Parallelization in Clojure - a Case Study
 

Analise de Requisitos

  • 1. Princípios Fundamentais da Análise de Requisitos Marcelo Augusto Santos Turine
  • 2. O ciclo de vida clássico Engenharia de Sistemas Análise Projeto Codificação Teste Manutenção
  • 3. Uma compreensão completa dos Requisitos do Software é fundamental para obter um software e um processo de desenvolvimento com alta qualidade Não importa quão bem projetado ou codificado está um programa, se ele for mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor
  • 4. Fase de Análise de Requisitos Escopo do Software Primeiro passo técnico Analista de Sistemas PONTE ANÁLISE DE REQUISITOS Engenharia de Sistemas de Computador Projeto de Software
  • 5. Análise de Requisitos processo de descoberta e refinamento ATORES: cliente e desenvolvedor Cliente: reformula um conceito de função e desempenho (às vezes nebuloso) Desenvolvedor: indagador e solucionador de problemas PROBLEMA: grande propensão a mal entendidos " atividade aparentemente simples torna-se complexa "
  • 6. Definição: Requisitos e Especificação Glossário de Engenharia de Software (IEEE) e do Aurélio Requisito (IEEE) Uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo Uma condição ou capacidade que deve ser satisfeita por um sistema para satisfazer um contrato ou um padrão
  • 7. Requisito (Aurélio) Condição necessária para a obtenção de certo objetivo, ou para o preenchimento de certo fim Especificação : descrição rigorosa e minuciosa das características que um material, uma obra, ou um serviço deverá apresentar processo de representação dos requisitos de uma forma que leva à implementação bem-sucedida
  • 8. Exemplos “ O sistema deve rodar em microcomputadores da linha IBM PC que possuam microprocessador 486 DX ou superior.” “ A interface do sistema deve ser gráfica, de acordo com um padrão de interface dirigida a menu.” “ Alternativamente, o sistema deve possibilitar o seu uso através de linhas de comando, para usuários avançados.”
  • 9. Tipos de Requisitos (divisão utilizada na literatura) Funcionais Não Funcionais (de Qualidade) ISO - The International Organization for Standardizatized IEC - The International Electrotechnical Commition (formam o sistema especializado para padronização mais conhecido)
  • 10. Requisitos de Software A Norma ISO/IEC 9126 define seis características de qualidade de software que devem ser avaliados: Funcionalidade (finalidade do produto) Usabilidade (esforço para utilizar, aprender o produto) Confiabilidade (freqüência de falhas, recuperabilidade) Eficiência (desempenho) Manutenibilidade (esforço necessário para modificar) Portabilidade (capacidade de transferir o produto para outros ambientes)
  • 11. fase de Análise de Requisitos elementos alocados ao software determinar domínio das informações e das funções, interfaces, restrições de projeto e critérios de validação construir protótipo para estabelecer os requisitos os requisitos são conhecidos? revisão administrativa Plano de Desenvolvimento do Software estabelecimento do alcance recursos, custo cronograma revisar e justificar recursos, custos e cronogramas Especificação dos Requisitos do Software início da fase de desenvolvimento revisão aceitável revisão não sim revisão técnica revisão do plano de projeto do software aceitável aceitável
  • 12. Dilema do Engenheiro de Software Declaração de um cliente anônimo: “ Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer ... ”
  • 13. ATIVIDADES de ANÁLISE: 1 - reconhecimento do problema 2 - avaliação do problema e síntese da solução ( Modelagem ) 3 - especificação dos requisitos do software 4 - r evisão
  • 14. Atividade 1 Reconhecimento do Problema A meta é o reconhecimento dos elementos básicos do problema, conforme percebidos pelo cliente. clientes Administrador do projeto analista desenvolvedores Plano de projeto de software Espec. requisitos de software protótipo
  • 15. Atividade 2 Avaliação do Problema e Síntese da Solução Avaliar os problemas na situação atual Principal Foco para o novo sistema: O QUE e não COMO : - qual o fluxo e o conteúdo de informação - quais as funções do sistema - quais dados que o sistema produz e consome - qual o comportamento do sistema - qual as características de interface - quais são as restrições do projeto
  • 16. Avaliação do Problema e Síntese da Solução Sintetizar uma ou mais soluções (dentro do alcance delineado no Plano de Projeto do Software ) O processo de avaliação e síntese continua até que o analista e o cliente concordem que o software pode ser adequadamente especificado. É a maior área de esforço
  • 17. Modelagem Durante a atividade de avaliação e síntese devem ser criados modelos do sistema para se compreender melhor o fluxo de dados e de controle, o processamento funcional e a operação comportamental, além do conteúdo da informação. O modelo serve como fundamento para o projeto de software e como base para a criação de sua especificação
  • 18. Atividade 3 Especificação de Requisitos Definição de Especificação : descrição rigorosa e minuciosa das características que um material, uma obra ou um serviço deverão apresentar descrição do fluxo e estrutura da informação refinamento detalhado de todas as funções do software estabelecimento das características de interface identificação das restrições de projeto especificação dos critérios de validação
  • 19. Atividade 4 Revisões Devem ser efetuadas revisões técnicas e revisões no Plano de Projeto de Software as revisões são conduzidas pelo Cliente e pelo Desenvolvedor a base para a revisão são os documentos produzidos na Especificação dos Requisitos O Plano de Projeto do Software deve ser revisto devido ao conhecimento adquirido durante a análise.
  • 20. Analista de Sistemas Engenheiro de Sistemas Projetista de sistemas-chefe Programador/Analista
  • 21. Características do Analista de Sistemas - Capacidade para compreender conceitos abstratos, reorganizar esses conceitos em divisões lógicas e sintetizar "soluções" baseado em cada divisão. 2- Capacidade de absorver fatos pertinentes a partir de fontes conflitantes ou confusas. 4- Capacidade de se comunicar bem de forma escrita e verbal. 5- Capacidade de " ver a floresta ao invés das árvores ”  (não se perder nos detalhes)
  • 22. Papel do Analista de Sistemas 1- Coordenar cada uma das atividades da Análise de Requisitos de Software - comunicação com cliente - convoca pessoal de desenvolvimento durante avaliação e síntese 2- Responsável pelo desenvolvimento do documento de Especificação de Requisitos do Software e participa de todas as revisões
  • 23. Áreas Problemas 1. Aquisição da Informação 2. Tamanho do Sistema (complexidade dos problemas) 3. Alterações (mudanças que ocorrem durante e após a análise)
  • 24. Áreas Problemas 1. Aquisição da informação que informação deve ser coletada e como ela deve ser representada? quem fornece as informações? que técnicas e ferramentas estão disponíveis para facilitar a coleta de informações?
  • 25. Áreas Problemas 2. Tamanho do sistema como eliminar inconsistências na especificação de grandes sistemas? é possível detectar omissões? pode um grande sistema ser efetivamente particionado para que se torne intelectualmente administrável?
  • 26. Áreas Problemas 3. Alterações como as alterações efetuadas em outros elementos do software são coordenadas com os requisitos do software? como se determina o impacto de uma alteração em outras partes do software aparentemente não relacionadas? como se corrige erros na especificação para que não se gere efeitos colaterias?
  • 27. Causas dos Problemas comunicação ineficiente técnicas e ferramentas inadequadas (especificação inadequada e imprecisa) tendências de se eliminar a tarefa de Especificação dos Requisitos falhas ao considerar alternativas antes que o software seja especificado
  • 28. Abordagem de Engenharia de Software Aplicação de técnicas de comunicação sólidas Princípios de análise fundamentais Métodos de análise sistemáticos reduzirão o impacto dos problemas
  • 29. Problema cuja solução é baseada em computador Responde ao pedido de ajuda do cliente
  • 30. Princípios Fundamentais de Análise domínio de informação do problema  representado e compreendido (para que a função possa ser entendida + completamente ) modelos que descrevam a informação, a função e o comportamento do sistema  desenvolvidos (para que a informação possa ser comunicada compactamente )
  • 31. Princípios de Análise modelos (e o problema)  particionados , de maneira que revele os detalhes em forma de camadas (ou hierarquicamente) (para reduzir a complexidade) processo de análise  mover-se da informação essencial para os detalhes de implementação (para acomodar as restrições lógicas impostas por requisitos de processamento e as restrições físicas impostas por outros elementos do sistema) = (Concepções lógicas e físicas)
  • 32. 1  princípio: Domínio da Informação Todo software é construído para processar dados e eventos . Dados: software embutido de tempo real para controlar o fluxo de combustível no motor de automóvel Eventos: um sensor de pressão detecta que a pressão ultrapassa determinado valor de segurança e envia um sinal de alarme para o software de monitoração
  • 33. 1  princípio: Domínio da Informação Os dados e itens de controle residem no domínio de informação de um problema. Encerra 3 diferentes pontos de vista: Fluxo Conteúdo Estrutura da informação
  • 34. Fluxo da Informação : maneira pela qual os dados e o controle se modificam à medida que cada um se movimenta pelo sistema Conteúdo da Informação : os dados e os itens de controle individuais que compreendem certo item de informação mais amplo. - o conteúdo do item de dados cheque de pagamento é definido pelos itens que são necessários para criá-lo: nome do recebedor, quantidade líquida a ser paga, pagamento bruto, etc. Estrutura da Informação : a organização interna de vários itens de controle e de dados 1  princípio: Domínio da Informação
  • 35. 2. princípio: Modelagem Modelos: melhor compreensão da entidade real a ser construída Entidade é física (prédio): modelo idêntico, mas em escala menor Entidade é software: o modelo deve ser capaz de modelar a informação que o software transforma as funções (ou subfunções) que possibilitam que as transformações ocorram o comportamento do sistema quando a transformação está se desenvolvendo.
  • 36. 2. princípio: Modelagem Os modelos concentram-se naquilo que o sistema deve fazer, não em como ele faz. Modelos fazem uso de notação gráfica e textual Os métodos de análise discutidos nos capítulos seguintes são métodos de modelagem Atividade de Modelagem é fundamental ao bom trabalho da análise
  • 37. 2. princípio: Modelagem Papéis importantes do Modelo: 1) ajuda o analista a entender a informação, a função e o comportamento de um sistema, tornando a tarefa + fácil e sistemática. 2) torna-se o ponto focal para a revisão e, portanto, a chave para a determinação da completitude, consistência e precisão da especificação. 3) torna-se a base para o projeto , fornecendo ao projetista uma representação essencial do software, a qual pode ser "mapeada" num contexto de implementação.
  • 38. 3. princípio: Particionamento (decomposição) Os problemas freqüentemente são grandes demais e muito complexos para serem compreendidos como um todo. O particionamento divide o problema em partes mais facilmente entendidas Através das interfaces estabelecidas entre as partes a função global do software pode ser executada.
  • 39. Particionamento Horizontal: decomposição funcional do problema Particionamento Vertical: expõe detalhes crescentes 3  princípio: Particionamento Particionamento horizontal
  • 40. 4  princípio: Concepções essenciais e de implementação A concepção essencial dos requisitos do software apresenta as funções a serem realizadas sem tratar dos detalhes de implementação. Ao se concentrar atenção na essência do problema nas primeiras etapas da análise de requisitos, deixa-se as opções abertas para especificar detalhes de implementação durante as últimas etapas de especificação dos requisitos e projeto de software.
  • 41. A concepção de implementação dos requisitos de software apresenta a manifestação das funções de processamento e estruturas de informação no mundo real. Não deve ser interpretada como uma representação do como. Um modelo de implementação representa o modo de operação corrente, ou seja a atribuição existente ou proposta para todos os elementos do sistema. 4  princípio: Concepções essenciais e de implementação
  • 42. Especificação de Requisitos de Software Desenvolvida como uma conseqüência da fase de análise de requisitos Serve como um padrão para testar se as fases de projeto e implementação do processo de desenvolvimento de software estão corretas
  • 43. Princípios de uma boa especificação (Balzer e Goldman) 1. Separe funcionalidade de implementação 2. É necessária uma linguagem de especificação de sistemas orientada ao processo 3. A especificação deve abranger o sistema do qual o software é um componente 4. Uma especificação deve abranger o ambiente no qual o sistema opera 5. Uma especificação de sistema deve ser um modelo cognitivo 6. Uma especificação deve ser operacional 7. A especificação do sistema deve ser tolerante com a não completitude e ser expansível 8. Uma especificação deve ser localizada e fracamente acoplada.
  • 44. A Especificação pode ser acompanhada de um PROTÓTIPO executável (ou em papel) e/ou um MANUAL PRELIMINAR DE USUÁRIO.
  • 45. Revisão da Especificação ( nível macroscópico) Os revisores tentam garantir que a especificação seja completa, consistente e precisa. Questões : Metas e objetivos do software permanecem consistentes com metas e objetivos do sistema? Foram descritas as interfaces importantes para todos os elementos do sistema? O fluxo e a estrutura de informação são adequadamente definidas para o domínio da informação? Os diagramas são claros?
  • 46. As funções importantes permanecem dentro do escopo e cada uma foi adequadamente descrita? O comportamento do software é consistente com a informação que ele deve processar e as funções que deve executar? As restrições de projeto são realísticas? Qual é o risco tecnológico desenvolvimento? Requisitos de software alternativos foram considerados? Critérios de Validação foram declarados detalhadamente? Eles são adequados para descrever um sistema bem sucedido? Existem inconsistências, omissões ou redundâncias? O usuário revisou o Manual Preliminar ou o protótipo? Como as estimativas do Plano de projeto de Software foram afetadas? Revisão da Especificação ( nível macroscópico)
  • 47. Revisão da Especificação ( nível detalhado ) A preocupação é com o enunciado da especificação. Tenta-se descobrir problemas que possam estar ocultos no conteúdo da especificação Diretrizes: Esteja alerta para perceber conectivos persuasivos (certamente, claramente, obviamente ) e perguntar por que eles estão presentes. Procure termos vagos e peça esclarecimento (algum, às vezes, usualmente, freqüentemente) Quando forem fornecidas listas que não sejam completas, certifique-se de que todos os itens sejam entendidos (evite colocar etc, tal como, assim por diante)
  • 48. Revisão da Especificação ( nível detalhado ) Esteja certo de que os limites declarados não contenham pressuposições não declaradas (“os códigos válidos variam de 0 a 100” - números inteiros, reais???) Cuidado com verbos vagos. Há muitas maneiras de interpretá-los. (manuseado, rejeitado, pulado, processado) Cuidado com pronomes "pendentes” (o módulo I/O comunica-se com o módulo de validação de dados e seu sinal de controle está ligado. Sinal de controle de qual?). Procure declarações que impliquem certeza (sempre, cada, todos, nunca) e depois peça prova
  • 49. Revisão da Especificação ( nível detalhado ) Quando um termo for explicitamente definido num lugar, evite utilizar outras definições para o mesmo termo (normalização dos termos: documento - arquivo) Quando uma estrutura for descrita em palavras, verifique se há um gráfico ou uma figura para auxiliar a compreensão Quando um cálculo for especificado, desenvolva pelo menos dois exemplos.
  • 50. Ferramentas de Especificação Automatizadas 1 a categoria: técnicas automatizadas que nada mais são do que um método manual que foi complementado com uma ferramenta CASE Possibilitam que o analista atualize informações e rastreie as conexões entre representações novas e existentes do sistema Ex: DEC Design ( Digital Equipment Corp .), Design Aid ( Transform Logic Corp .), Excelerator ( Intersolv ), IEF ( Texas Instruments ), ADW ( Knowledgeware ), STP ( Interative Development Environments ), Teamwork ( Cadre Technologies ).
  • 51. 2 a categoria: técnicas automatizadas que fazem uso de uma notação especial (na maioria dos casos, essa é uma linguagem de especificação de requisitos) que foi explicitamente projetada para processamento usando-se uma ferramenta automatizada. Ex: SREM (linguagem de especificação: RSL), PSL/PSA (linguagem de especificação: PSL), TAGS (linguagem de especificação: IORL) Ferramentas de Especificação Automatizadas
  • 52. Análise de Requisitos Conclusão Logo que a Revisão for concluída, a Especificação de Requisitos de Software é " assinada " pelo cliente e pelo desenvolvedor A especificação torna-se um " contrato " de desenvolvimento de software. Mudanças solicitadas depois que a Espec. for concluída serão consideradas, porém cada mudança posterior pode aumentar o custo e/ou alongar o prazo de entrega Mesmo com os melhores procedimentos de revisão em andamento, uma série de problemas de especificação ainda persiste