Analise sistemas 04

ENGENHARIA DE REQUISITOS

Profª. M.Sc. Caroline Raquel Rodrigues

Análise de Sistemas Computacionais

FANAP

Engenharia de Requisitos

Introdução:

É o 1º passo no modelo do processo. O que devo fazer e não a forma como será implementado. Serve como contrato entre desenvolvedor e comprador.

É o processo de aquisição, refinamento e verificação das necessidades do sistema.

O objetivo é sistematizar o processo de definição dos requisitos, obtendo uma especificação correta e completa do mesmo para elaboração do Documento de Requisitos .


Introdução:

A análise de requisitos tem como objetivo estabelecer os serviços que devem ser fornecidos pelo sistema e as restrições sobre as quais ele deve operar.


Introdução:


Introdução:


Definição de Requisitos do Sistema:

Obter os requisitos do sistema como um todo estabelecendo um conjunto de objetivos gerais que o sistema deve cumprir;

Características do que o sistema deve fazer e não o que deve ser implementado;

Utilizados pelos: usuários finais de sistemas, desenvolvedores de software e arquitetos de sistemas.


Tipos de requisitos:

Funcional: descreve um serviço ou uma função do sistema;

Não funcional: descreve uma restrição imposta ao sistema (por exemplo, tempo de resposta) ou ao processo de desenvolvimento (por exemplo, uso de uma linguagem de programação específica;)


Requisitos Funcionais:

São declarações de funções de como o sistema deve reagir a entradas específicas e como deve comportar em determinadas situações. É uma interação entre o sistema e o seu ambiente. Algumas vezes, os requisitos funcionais podem também explicitamente declarar o que o sistema não deve fazer. A especificação deve ser completa e consistente.


Requisitos Funcionais – exemplo:

O sistema deve permitir a inclusão, alteração e remoção de funcionários com os seguintes atributos: nome, endereço, cidade,etc).

O usuário deve ser capaz de buscar todo o conjunto inicial do BD ou selecionar um subconjunto a partir dele.

O sistema fornecerá telas apropriadas para o usuário ler documentos

Cada pedido tem um único identificador.


Requisitos Não Funcionais:

Organizacionais: refere-se a políticas e procedimentos nas organizações do cliente e do desenvolvedor. de entrega, de implementação, padrões de processo

Externos: refere-se a fatores externos ao sistema e ao seu processo de desenvolvimento. interoperabilidade (interação do sistema com outros), éticos,

legais (privacidade e de segurança)

De produto: especificam o comportamento do produto. eficiência (desempenho, espaço, rapidez, memória),

confiabilidade, portabilidade.


Requisitos Não Funcionais - exemplo:

Organizacional: o processo de desenvolvimento de sistema e os documentos a serem entregues deverão estar de acordo com o processo e os produtos a serem entregues definidos em XYZKL.

Externo: o sistema não deverá revelar aos operadores nenhuma informação pessoal sobre os clientes.

De produto: toda comunicação necessária entre o ambiente X e o usuário deve ser expressa no conjunto padrão de caracteres ANSI.



Ambiente físico: Onde o equipamento funcionará?

Interfaces: A saída vai para outro ou outros sistemas?

Funcionalidade: Existem limitações quanto à velocidade de execução, ao tempo de resposta, ou a saída?

Os usuários e os fatores humanos: Haverá diversos tipos de usuários?



Documentação: Essa documentação deve ser online, no formato de livro, ou ambos?

Dados: Qual será o fluxo de dados do sistema?

Segurança: O acesso ao sistema ou às informações deve ser controlado?

Recursos: Quanto espaço físico será ocupado pelo sistema.


Como obter os requisitos?

Entrevista

Questionário

Observação direta

Sessões brainstorming


Como obter os requisitos? – Entrevista:

Usado quanto poucas pessoas conhecem as informações necessárias para o desenvolvimento do sistema.

Precisa ser preparada antecipadamente. Ter perguntas objetivas.

Evitar constrangimento dos participantes.


Como obter os requisitos? – Entrevista:

Antes: planejar, identificar a posição e responsabilidade do entrevistado, marcar horário, escolher local sossegado.

Durante: apresente-se informando a finalidade da entrevista, explique as anotações que fizer, não demore mais do que 2 horas, agradeça a contribuição.

Depois: documente os pontos relevantes; envie a documentação ao entrevistado (aprovação final), envie os resultados para os usuários e seus gerentes


Como obter os requisitos? – Questionário:

Usado quanto muitas pessoas conhecem as informações necessárias para o desenvolvimento do sistema.

Preparar antecipadamente com questões objetivas

Desvantagem: comunicação restrita com o usuário e não há troca de informação face a face. A preparação exige tempo.


Como obter os requisitos? – Questionário:

Preparação: identificar o tipo de informação que deseja obter. Enviar carta acompanhando o questionário enfatizando a sua importância.

Identificar quem responderá: nome, função e localização.

Distribuir com instruções detalhadas de como preencher e o prazo de devolução.

Analisar e consolidar as informações recebidas, documentar as principais descobertas e enviá-las juntamente com cópia do relatório para todos os respondentes.


Como obter os requisitos? – Observação:

Utilizada como processamento e confirmação de outros resultados (entrevista e questionário).

Identificar documentos que devem ser coletados para posterior análise.

Observar diretamente quem desenvolve o trabalho.

Deve ter aprovação antecipada das gerências.


Como obter os requisitos? – Brainstorming:

Útil para obter rapidamente informações sobre a atual situação.

Reunião de pessoas com diferentes níveis de informação e conhecimento sobre o sistema desejado.

A discussão em grupo é conduzida por um mediador.

Conceito: diversas cabeças pensam melhor do que uma.


O processo de engenharia de requisitos:

Tipos de requisitos:



Estudo de viabilidade: Analisa se as necessidades do cliente podem ser

satisfeitas usando as tecnologias de software e hardware atuais;

Analisa de o projeto do cliente pode ir adiante, dadas as restrições orçamentárias existentes;



Análise de requisitos: Descobre os requisitos do sistema através da

observação de sistemas existentes, da discussão com usuários e da análise da tarefa;

Gera um conjunto de modelos que ajudam o analista a compreender o sistema que será especificado.

Protótipos podem ser desenvolvidos para ajudar a compreender os requisitos;



Definição dos requisitos: Transforma a informação obtida durante a etapa de

análise em um documento que define um conjunto de requisitos realmente desejados pelo cliente;

O documento deve ser compreendido pelo usuário final e pelo cliente do sistema;



Especificação dos requisitos: Os requisitos são detalhados e descritos de forma

precisa ; Serve como base de contrato entre o cliente e o

desenvolvedor;


O documento de requisitos:

Também chamado de especificação de requisitos É a declaração oficial do que é requerido dos

desenvolvedores de software; Especifica o que o software deve fazer sem dizer

como; Cada requisito deverá gerar uma parte do software

que implementa uma solução para o problema;


Estrutura do documento de requisitos:

Introdução: descreve brevemente as funções que o sistema deverá desempenhar;

Glossário: define termos técnicos utilizados no documento;

Modelos do sistema: inclui os modelos que mostram o relacionamento entre os componentes do sistema e entre o sistema e seu ambiente (modelos de objetos, modelos de fluxos de dados etc.).


Estrutura do documento de requisitos:

Definição de requisitos funcionais: descreve através de linguagem natural ou de diagramas, os serviços que serão fornecidos pelo sistema;

Definição de requisitos não-funcionais: descreve as restrições impostas sobre o software e relaciona estas restrições aos requisitos funcionais;

Especificação de requisitos: descreve os requisitos funcionais em mais detalhes;


Validação dos requisitos:

Objetivo: mostrar que os requisitos realmente definem o sistema que o cliente deseja;

Revisões são a técnica mais comum de validação de requisitos;

Nas revisões usuários e desenvolvedores se reúnem para discutir o documento de requisitos em busca de conflitos, contradições, erros e omissões;


Validação dos requisitos:

O que deve ser checado? Consistência: não existe conflito entre os

requisitos. Completude: todas as funções e restrições

pretendidas pelo cliente são consideradas;


Evolução dos requisitos:

Os requisitos sempre mudam durante o processo de desenvolvimento de software.

É preciso ter a preocupação de manter o documento de requisitos atualizado tendo em vista essas mudanças;


Análise de requisitos - dificuldades:

O cliente nem sempre sabe o que quer que o sistema faça;

A comunicação entre os clientes e os engenheiros normalmente é difícil;


Análise de requisitos - dificuldades:

Diferentes usuários podem ter diferentes requisitos: Cabe aos engenheiros captar os requisitos comuns

e os conflitos entre os requisitos;

Requisitos podem mudar e novos requisitos podem surgir durante o processo;


Análise de requisitos – etapas do processo:

Compreensão do domínio: os analistas buscam o máximo de informações possíveis a respeito do problema;

Coleta de requisitos: os analistas interagem com os usuários a fim de descobrir seus requisitos;

Classificação: os requisitos coletados são classificados em grupos coerentes;


Análise de requisitos – etapas do processo:

Resolução de conflitos: os analistas procuram e resolvem conflitos existentes entre os requisitos dos diferentes usuários;

Priorização: os analistas interagem com os usuários a fim de descobrir quais são os requisitos mais importantes;

Validação de requisitos: os analistas checam os requisitos a fim de garantir sua consistência e completude;

Documents

Analise sistemas 04