Análise de Requisitos
-
Upload
suki-kitsune-fujihara -
Category
Technology
-
view
990 -
download
0
Transcript of Análise de Requisitos
![Page 1: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/1.jpg)
1
Análise de Requisitos
Profa. Renata de Freitas Góis
Parte deste material retirado de notas de aula da Profa. Renata Fortin – ICMC –USP
![Page 2: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/2.jpg)
2
Entendimento Modificação
Revalidação
Projeto Codificação
Teste
Análise de Sistema
Planejamento
Análise de Requisitos
Fases dosFases dos Modelos de Modelos de Processo de Processo de SoftwareSoftware
DEFINIÇÃODEFINIÇÃO
CONSTRUÇÃOCONSTRUÇÃO
MANUTENÇÃOMANUTENÇÃO
ATIVIDADES DE APOIO
• Controle e Acompanhamento do Projeto de Software
• Revisões Técnicas Formais
• Garantia de Qualidade de Software
• Gerenciamento de Configuração de Software
• Preparação e Produção de Documentos
• Gerenciamento de Reusabilidade
• Medidas • Gerenciamento de
Riscos
![Page 3: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/3.jpg)
3
Requisitos: Definição:
– (1) Uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo.
– (2) Uma condição ou uma capacidade que deve ser alcançada ou estar presente em um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto.
O documento que descreve todos os requisitos de um software, usualmente num formato ou linguagem inteligível pelo cliente, é a Descrição de Requisitos.
O documento que especifica estes requisitos, utilizando um formato mais apropriado para a implementação, é a Especificação de Requisitos.
Geralmente, ambos os documentos (descrição e especificação de requisitos) descrevem o que o software proposto deve fazer sem se preocupar em como deve ser feito.
![Page 4: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/4.jpg)
4
Requisitos: Funcionais x Não-Funcionais Requisitos Funcionais:
– Descrevem uma interação entre o sistema e seu meio ambiente. – Funcionalidades do sistema conforme percebidas pelos atores externos
(usuários).
Requisitos Não-Funcionais:– Ou restrições, descrevem uma restrição para o sistema que limita as
possíveis escolhas de solução para o problema. – Normalmente conhecidos como Requisitos de Qualidade de uma aplicação. – Devem ser detalhados em uma seção da documentação do Software.
![Page 5: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/5.jpg)
5
Requisitos: Importância e Qualidade Uma Especificação de Requisitos é importante porque:
– Estabelece uma base de concordância entre o cliente e o fornecedor sobre o que o software fará. – Mapeia o problema. – Uma especificação de requisitos de alta qualidade é um pré-requisito para um software de alta
qualidade. Qualidade:
–Critérios de qualidade para uma especificação de requisitos:
»Corretude – reflete fielmente a realidade e necessidades dos usuários e cliente;»Consistência – informações em diferentes locais não são contraditórias;»Clareza – sem ambigüidades, possibilita sua verificação;»Completude – não há nenhuma informação necessária ou importante para os usuários e cliente que esteja omitida;»Coesão – descreve exatamente o que é necessário para o cliente, sem acrescentar informações desnecessárias.
Evite focar na corretude como o único critério de
qualidade!!!
![Page 6: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/6.jpg)
6
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
![Page 7: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/7.jpg)
7
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
![Page 8: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/8.jpg)
8
ANÁLISE DE REQUISITOS
Representação de Especificação
1- O formato de representação e o conteúdo devem ser pertinentes ao problema
2- As informações contidas na especificação devem ser apresentadas em nível
3- Diagramas e outras formas notacionais devem ser restritos quanto ao número e consistentes em relação ao uso
4- As representações devem ser revisáveisDIRETRIZES
DIRETRIZES
![Page 9: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/9.jpg)
9
ANÁLISE DE REQUISITOS : Formato da Especificação de Requisitos de Software
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
– Apresenta uma descrição detalhada do problema que o software deve resolver
![Page 10: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/10.jpg)
10
III. DESCRIÇÃO FUNCIONAL
– Engloga uma descrição de cada função exigida para resolver o problema
IV. DESCRIÇÃO COMPORTAMENTAL
– Examina a operação do software como uma sequência de eventos
ANÁLISE DE REQUISITOS : Formato da Especificação de Requisitos de Software
![Page 11: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/11.jpg)
11
V. CRITÉRIOS DE VALIDAÇÃO
– Designam classes de testes que devem ser efetuadas para validar a função, o desempenho e as restrições. Seção muito importante, porém negligenciada.
VI. BIBLIOGRAFIA
– Contém referências a todos os documentos que se relacionam com o software.
ANÁLISE DE REQUISITOS : Formato da Especificação de Requisitos de Software
![Page 12: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/12.jpg)
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 ... ”
![Page 13: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/13.jpg)
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 - revisão
![Page 14: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/14.jpg)
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
![Page 15: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/15.jpg)
15
Atividade 2 Avaliação do Problema e Síntese Avaliação do Problema e Síntese da Soluçãoda 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
![Page 16: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/16.jpg)
16
Atividade 3 Especificação de Requisitos Especificação de Requisitos Definição de Especificação: descrição rigorosa e descrição rigorosa e
minuciosa das características que um material, uma minuciosa das características que um material, uma obra ou um serviço deverão apresentarobra 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
![Page 17: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/17.jpg)
17
Atividade 4 Revisões 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.
![Page 18: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/18.jpg)
•Engenheiro de Sistemas•Projetista de sistemas-chefe•Programador/Analista
![Page 19: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/19.jpg)
19
Características do Analista de Características do Analista de SistemasSistemas
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.
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)
![Page 20: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/20.jpg)
20
Papel do Analista de SistemasPapel 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
![Page 21: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/21.jpg)
21
Áreas ProblemasÁ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)
![Page 22: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/22.jpg)
22
Á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 23: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/23.jpg)
23
Á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 24: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/24.jpg)
24
Á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?
![Page 25: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/25.jpg)
25
Causas dos ProblemasCausas 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
![Page 26: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/26.jpg)
26
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
![Page 27: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/27.jpg)
27Problema cuja solução é baseadaem computador
Responde ao pedido de ajuda do cliente
![Page 28: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/28.jpg)
28
Princípios de uma boa especificaçãoPrincí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.
![Page 29: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/29.jpg)
29
A Especificação pode ser
acompanhada de um PROTÓTIPO
executável (ou em papel) e/ou um
MANUAL PRELIMINAR DE
USUÁRIO.
![Page 30: Análise de Requisitos](https://reader035.fdocuments.net/reader035/viewer/2022081603/55866035d8b42aa9308b4747/html5/thumbnails/30.jpg)
30
Análise de RequisitosAnálise de Requisitos ConclusãoConclusã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