Analise de Requisitos
-
Upload
elliando-dias -
Category
Technology
-
view
9.424 -
download
14
description
Transcript of Analise de Requisitos
1
Princípios Fundamentais da Análise de Requisitos
Marcelo Augusto Santos Turine
O ciclo de vida clássicoEngenhariade Sistemas
AnáliseProjeto
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 RequisitosFase de Análise de Requisitos
ANÁLISE DEREQUISITOS
Engenharia de Sistemas de Computador
Projeto de Software
Escopo do Software
•Primeiro passo técnico•Analista de Sistemas
PONTE
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)
FuncionaisNã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
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
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
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
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 - revisã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 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
16
Avaliação do Problema e Síntese Avaliação do Problema e Síntese da Soluçãoda 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
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
18
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
19
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.
•Engenheiro de Sistemas•Projetista de sistemas-chefe•Programador/Analista
21
Características do Analista de Características do Analista de SistemasSistemas
- 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 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
23
Á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)
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 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
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
29Problema cuja solução é baseadaem computador
Responde ao pedido de ajuda do cliente
30
Princípios Fundamentais de Princípios Fundamentais de AnáliseAná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á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) = (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:
34
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.
- 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çãoEstrutura 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 projetoa 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
Particionamento horizontalParticionamento horizontal
3 princípio: Particionamento
40
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.
41
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.
4 princípio: Concepções essenciais e de implementaçãoConcepçõ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çã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.
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çã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?
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çãoRevisão da Especificação((nível macroscópico)
47
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 (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çãoRevisã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çãoRevisã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 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
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
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.
Ex: SREM (linguagem de especificação: RSL), PSL/PSA (linguagem de especificação: PSL), TAGS (linguagem de especificação: IORL)
Ferramentas de Especificação Ferramentas de Especificação AutomatizadasAutomatizadas
52
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