1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.
-
Upload
beatriz-merenda -
Category
Documents
-
view
234 -
download
1
Transcript of 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.
![Page 1: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/1.jpg)
1
Princípios Fundamentais da Análise de Requisitos
Fauzi de Moraes Shubeita
![Page 2: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/2.jpg)
2
Fase de Análise de RequisitosFase de Análise de Requisitos
ANÁLISE DEREQUISITOS
Engenharia de Sistemas de Computador
Projeto de Software
![Page 3: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/3.jpg)
3
Análise de Requisitos
processo de descoberta e refinamento ATORES: cliente e desenvolvedor PROBLEMA: grande propensão a mal
entendidos
"atividade aparentemente simples torna-se complexa"
![Page 4: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/4.jpg)
4
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 - revisão
![Page 5: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/5.jpg)
5Fase
de
Aná
lise
d e R
equ i
s ito
s
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 alcancerecursos, 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
![Page 6: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/6.jpg)
6
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
![Page 7: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/7.jpg)
7
Atividade 2 Avaliação do Problema e Síntese da SoluçãoAvaliação do Problema e Síntese da Solução Avaliar os problemas na situação atual Para o novo sistema:
-definir e elaborar todas as funções do sistema-identificar dados que o sistema produz e consome -entender o comportamento do sistema-estabelecer características de interface-descobrir restrições do projeto
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
![Page 8: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/8.jpg)
8
ModelagemModelagem
Durante a atividade de avaliação e síntese devem ser criados modelos do sistemamodelos 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
![Page 9: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/9.jpg)
9
Atividade 3 Especificação de RequisitosEspecificação de Requisitos
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
![Page 10: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/10.jpg)
10
Atividade 4 RevisõesRevisõ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.
![Page 11: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/11.jpg)
11
Características do Analista de SistemasCaracterísticas do Analista de Sistemas
1-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.
3-Capacidade de se comunicar bem de forma escrita e verbal.
4-Capacidade de "ver a floresta ao invés das árvores”
![Page 12: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/12.jpg)
12
Áreas ProblemasÁreas Problemas
1. Aquisição da Informação
2. Tamanho do Sistema
3. Alterações
![Page 13: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/13.jpg)
13
Á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?
![Page 14: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/14.jpg)
14
Á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?
![Page 15: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/15.jpg)
15
Á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 colaterais?
![Page 16: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/16.jpg)
16
Causas dos ProblemasCausas dos Problemas
comunicação ineficiente
técnicas e ferramentas inadequadas
tendências de eliminar a tarefa de Especificação dos Requisitos
falha de considerar alternativas antes que o software seja especificado
![Page 17: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/17.jpg)
17
Princípios de AnálisePrincípios 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)
![Page 18: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/18.jpg)
18
Princípios de AnálisePrincí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)
![Page 19: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/19.jpg)
19
1. princípio: Domínio da Informação
Todo software é construído para processar dados e eventos.
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çãoFluxo / Conteúdo / Estrutura da informação
![Page 20: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/20.jpg)
20
1. princípio: Domínio da Informação Fluxo da InformaçãoFluxo 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çãoConteúdo da Informação: os dados e os itens de controle individuais que compreendem certo item de informação mais amplo.
Estrutura da InformaçãoEstrutura da Informação: a organização interna de vários itens de controle e de dados
![Page 21: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/21.jpg)
21
2. princípio: Modelagem 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 e o comportamento do sistema quando a transformação está se desenvolvendo.
Os modelos concentram-se naquilo que o sistema deve fazer, não em como ele faz.
![Page 22: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/22.jpg)
22
2. princípio: Modelagem
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 projetoa base para o projeto, fornecendo ao projetista uma representação essencial do software, a qual pode ser "mapeada" num contexto de implementação.
![Page 23: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/23.jpg)
23
3. princípio: Particionamento 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.
![Page 24: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/24.jpg)
24
3. princípio: Particionamento
Particionamento Horizontal: decomposição funcional do problema
Particionamento Vertical: expõe detalhes crescentes
Particionamento horizontalParticionamento horizontal
![Page 25: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/25.jpg)
25
4. princípio: Concepções essenciais e de implementaçãoConcepções essenciais e de implementação A concepção essencialconcepçã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.
![Page 26: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/26.jpg)
26
4. princípio: Concepções essenciais e de implementaçãoConcepções essenciais e de implementação A concepção de implementaçãoconcepçã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.
![Page 27: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/27.jpg)
27
Princípios de uma boa especificaçãoPrincípios de uma boa especificação1. Separe funcionalidade de implementação2. É necessária uma linguagem de especificação de sistemas
orientada ao processo3. A especificação deve abranger o sistema do qual o software
é um componente4. Uma especificação deve abranger o ambiente no qual o
sistema opera5. Uma especificação de sistema deve ser um modelo cognitivo6. Uma especificação deve ser operacional7. A especificação do sistema deve ser tolerante com a não
completitude e ser expansível8. Uma especificação deve ser localizada e fracamente
acoplada.
![Page 28: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/28.jpg)
28
Formato da descrição de requisito Requisito de performance: A busca no banco de dados
deve ser mais otimizada o possivel possibilitando um bom uso do sistema via internet; Usado na rede, acesso de mais de um usuário concorrentemente; Dados relevantes devem estar disponiveis para Impressão.
Requisito de confiabilidade:O ponto principal é a confiabilidade nas consultas, inserções e remoções de dados no banco de dados, não podendo ocorrer inconsistência; Apenas o administrado tem autorização para cadastrar dados; Ao Usuario será dado um acesso parcial, ou seja, apenas dados relevantes para consulta; O objetivo é evitar acesso de pessoas não autorizadas, o que poderia causar algum tipo de dano ao sistema
![Page 29: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/29.jpg)
29
Limitações técnicas - exemplo Limitações da implementação :
O sistema será desenvolvido em Delphi, onde será utilizado o Oracle para armazenar a base de dados. Limitações de ambiente :
O sistema pode ficar fora do ar caso não haja energia, pois o banco de dados pode ficar fora do ar.
Limitações econômicas : O custo do sistema será de R$ 10.000,00 não podendo ultrapassar de R$
15.000,00 . Limitações de tempo : O sistema deverá ser desenvolvido em 5 meses , podendo ser extendido por
mais 2 meses. Limitações políticas : Qualquer alteração no banco de dados será limitada a usuários cadastrados,
com login e senha.
![Page 30: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/30.jpg)
30
Formato da Especificação de RequisitosFormato da Especificação de Requisitos
I. Introdução - declara as metas e os objetivos do software, descrevendo-os no contexto do sistema baseado em computador
II. Descrição da Informação - descrição detalhada do problema que o software deve resolver
III. Descrição Funcional IV. Descrição Comportamental V. Critérios de ValidaçãoVI. BibliografiaVII. Apêndice
![Page 31: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/31.jpg)
31
A Especificação pode ser acompanhada de um PROTÓTIPO executável (ou em papel) e/ou um
MANUAL PRELIMINAR DE USUÁRIO.
![Page 32: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/32.jpg)
32
Revisão da EspecificaçãoRevisã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?
![Page 33: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/33.jpg)
33
Revisão da EspecificaçãoRevisão da Especificação 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?
![Page 34: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/34.jpg)
34
Revisão da EspecificaçãoRevisã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 e
perguntar por que eles estão presentes. Procure termos vagos e peça esclarecimento Quando forem fornecidas listas que não sejam completas,
certifique-se de que todos os itens sejam entendidos Esteja certo de que os limites declarados não contenham
pressuposições não declaradas
![Page 35: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/35.jpg)
35
Diretrizes: Cuidado com verbos vagos. Há muitas maneiras de
interpretá-los. Cuidado com pronomes "pendentes". Procure declarações que impliquem certeza e depois peça
prova Quando um termo for explicitamente definido num lugar,
evite utilizar outras definições para o mesmo termo 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.
![Page 36: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/36.jpg)
36
Ferramentas de Especificação Ferramentas de Especificação AutomatizadasAutomatizadas
1a 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
).
![Page 37: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/37.jpg)
37
Ferramentas de Especificação Ferramentas de Especificação AutomatizadasAutomatizadas
2a 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.
![Page 38: 1 Princípios Fundamentais da Análise de Requisitos Fauzi de Moraes Shubeita.](https://reader030.fdocuments.net/reader030/viewer/2022013113/570638441a28abb8238f22a9/html5/thumbnails/38.jpg)
38
ConclusãoConclusão Logo que a Revisão for concluída, a Espec. 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