Análise de Requisitos

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

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

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.

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.

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!!!

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

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

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

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

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


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.


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

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

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.

•Engenheiro de Sistemas•Projetista de sistemas-chefe•Programador/Analista

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)

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

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)

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?

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?

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?

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

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

27Problema cuja solução é baseadaem computador

Responde ao pedido de ajuda do cliente

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.

29

A Especificação pode ser

acompanhada de um PROTÓTIPO

executável (ou em papel) e/ou um

MANUAL PRELIMINAR DE

USUÁRIO.

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

Technology

Análise de Requisitos