Técnicas e Projeto de Sistemas Aula 01: Análise de Requisitos

Apresentação em tema: "Técnicas e Projeto de Sistemas Aula 01: Análise de Requisitos"— Transcrição da apresentação:

1 Técnicas e Projeto de Sistemas Aula 01: Análise de Requisitos
Prof. MSc. Antonio da Luz Jr. Curso Téc. Informática – Mód. III ETF/Palmas – UNED/Paraíso

2 Introdução É a fase inicial no processo de desenvolvimento de software. A Análise de Requisitos especifica o que deve ser feito e não como deve ser feito. É durante esta etapa que se realiza a aquisição, refinamento e verificação das necessidades do usuário. Ao final desta etapa é gerado um documento que descreve o processo realizado, denominado Documento de Requisitos ou Documento de Especificação do Sistema.

3 Introdução O Documento de Requisitos permite ao cliente descrever suas necessidades e ao desenvolvedor compreendê-las. Define todos os requisitos (restrições, necessidades e funcionalidades) que devem compor o sistema. Estabelece uma base para o acordo entre clientes e desenvolvedores sobre o que o sistema fará.

4 Análise de Requisitos A Análise de Requisitos deve responder a alguma questões básicas: Funcionalidade: O que o software pretende fazer? Interfaces Externas: Como o software interage com as pessoas, hardware do sistemas, outros hardwares e outros sistemas? Performance: Qual é a velocidade, disponibilidade, o tempo de resposta, o tempo de recuperação das várias funções do sistema? Atributos: Quais são as considerações sobre portabilidade, manutenibilidade, segurança, corretude, entre outras? Restrições: Existem algum padrão requerido, linguagem de programação, políticas de integridade de BD, limitações de recursos, ambientes operacionais, entre outras?

5 Análise de Requisitos A Análise de Requisitos deve ser:
Correta: quando cada requisito expresso nela for encontrado no software; Não Ambígua: quando cada requisito declarado tiver uma só interpretação; Completa: quando incluir todos os requisitos significativos relacionados à funcionalidade, desempenho e restrições. Incluir ainda o comportamento do sistema para todas as entradas e saídas de dados; Consistente: quando não há conflito entre os requisitos; Verificável: quando for possível checar cada requisito; Modificável: quando os requisitos podem ser facilmente, completamente e consistentemente alterados.

6 Análise de Requisitos Existem dois tipos principais de requisitos:
Funcionais; Não-Funcionais.

7 Análise de Requisitos Requisitos Funcionais
São declarações de funções de como o sistema deve reagir a entradas específicas e como de comportar em determinadas situações. É uma interação entre o sistema e o seu ambiente. Os requisitos funcionais também podem explicitar o que o sistema não deve fazer.

8 Análise de Requisitos Exemplos:
O sistema deve permitir a inclusão, alteração e remoção de funcionário com os seguintes atributos: nome, endereço e cidade). 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.

9 Análise de Requisitos Requisitos Não-Funcionais
Organizacionais: refere-se a políticas e procedimentos nas organizações do cliente e do desenvolvedor. Externos: refere-se a fatores externos ao sistema e ao seu processo de desenvolvimento; Interoperabilidade com outros sistemas; Requisitos éticos ou legais; De produto: especificam o comportamento do produto Eficiência: desempenho, espaço, rapidez, memória; Confiabilidade; Portabilidade.

10 Análise de Requisitos Exemplos:
O processo de desenvolvimento do sistema deve estar de acordo com o padrão definido pela ISO. O sistema não deverá ocupar mais do que 130 MB em memória RAM; Toda a documentação gerada para o sistema deverá estar disponível online; O sistema não deverá revelar aos operadores nenhuma informação pessoal sobre os clientes.

11 Obtenção de Requisitos
Existem diferentes abordagens para a obtenção de requisitos de software: Entrevista; Questionário; Observação Direta; Rastreamento de Processo; Brainstorming.

12 Entrevista É a técnica mais comum de levantamento de requisitos
Utilizada quando poucas pessoas detêm o conhecimento sobre o problema; A habilidade do entrevistador é um fator significante na determinação do sucesso da entrevista e obtenção de conhecimento útil Uma entrevista pode ser: Desestrutura: Deseja-se explorar um problema (estágios inicias de um tópico considerado) Entrevista mais informal Estruturada: Deseja-se obter informações específicas do conteúdo e do problema

13 Entrevista O planejamento da entrevista é importante:
Identifique a responsabilidade do entrevistado; Marque um horário adequado; Escolha um local sossegado; Defina o processo de anotação a ser utilizado (manual, gravação em fita ou em vídeo);

14 Entrevista Durante a entrevista:
Apresente-se informando a finalidade da entrevista; Explique o modo de anotação escolhido: Aguarde a aceitação do entrevistado. Motive os participantes; Forneça um resumo verbal do problema; Não se alongue muito;

15 Entrevista Após a entrevista:
Documente todos os pontos relevantes observados; Envie a documentação ao entrevistado para a sua aprovação; Se for necessário mais esclarecimentos, marque outra reunião com o entrevistado.

16 Entrevista Tipos de perguntas: Abertas: Tendem a não ser específicas;
Não são seguidas por alternativas; Encorajam resposta livre; Indicadas quando deseja-se conhecer o escopo do entendimento do entrevistado; Podem consumir muito tempo e resultar em pouca informação útil; É necessário estar atendo ao andamento das respostas.

17 Entrevista Tipos de perguntas: Fechadas:
Impõem limites no tipo, nível e quantidade de informação fornecida pelo entrevistado; Fornecem escolha de alternativas ou níveis de resposta. Indicadas para avaliar características específicas do problema.

18 Questionário Usado quando muitas pessoas conhecem as informações necessárias para o desenvolvimento do sistema. Deve ser preparado antecipadamente com questões objetivas (múltipla escolha); A desvantagem deste modelo em relação a Entrevista é a comunicação restrita com o usuário. A preparação do questionário exige tempo e atenção. Perguntas mal feitas podem levar a resultados não desejados.

19 Questionário Durante a preparação do questionário deve ser:
Identificado o tipo de informação que se deseja obter; Escolhido um formato adequado para o questionário; Enviada carta acompanhando o questionário, enfatizando a importância de seu preenchimento; As questões devem ser montadas de forma simples e concisa. Cuidado com as ambiguidades. Caso adote questões descritivas, deixar espaço suficiente para as respostas; Elaborar instruções detalhadas de como realizar o preenchimento correto e estabelecer prazo para devolução dos formulários.

20 Questionário Analisar e consolidar as informações fornecidas pelos respondentes através dos questionários devolvidos; Documentar as principais descobertas; Enviar uma cópia do relatório com as principais descobertas para todos os respondentes.

21 Observação Direta Utilizada como processamento e confirmação de outros resultados (entrevista e questionário); Observar diretamente quem desenvolve o trabalho; Observar como se dá na prática o fluxo do trabalho: Familiarizar-se com o local de trabalho observado; Observar as facilidades manuais e automatizadas em uso; Coletar amostras de documentos e procedimentos escritos que serão usados para cada processo específico que está sendo observado; Acumular informações estatísticas relativas às tarefas: Freqüência que ocorrem, estimativas de volumes, entre outras. Deve ter aprovação antecipada do cliente.

22 Observação Direta Depois da visita de observação, documente as descobertas resultantes; Consolide os resultados; Reveja os resultados com as pessoas observadas e com seus superiores.

23 Rastreamento de Processo
É um conjunto de técnicas que permite a determinação do processo de pensar do indivíduo enquanto ele realiza uma tarefa ou chega a um conclusão. Pode ser realizado de duas maneiras: Verbalização Corrente: O especialista “pensa alto” enquanto resolve o problema. Enquanto realiza uma tarefa vai relatando ao analista todos os passos realizados e o que o levou a cada etapa. Verbalização Restropectiva: O especialista verbaliza o seu processo de raciocínio logo após realizar uma determinada tarefa. O analista de requisitos registra ou grava todo o procedimento adotado para resolver o problema. Posteriormente revisa os resultados junto com o especialista.

24 Brainstorming Técnica utilizada para encorajar a criatividade em grupo; Útil para obter rapidamente informações sobre a atual situação do problema; Ajuda a um grupo a gerar tantas idéias quanto forem possível em um curto espaço de tempo; Bastante útil principalmente para a sessões iniciais de levantamento de requisitos; Reuni pessoas com diferentes níveis de informação e conhecimento sobre o sistema; A discussão é conduzida por um moderador;

25 Brainstorming Regras de uma sessão de brainstorming:
Qualquer um pode apresentar espontaneamente uma idéia; As idéias devem ser relacionadas ao tópico correntemente em discussão; Um participante não deve expressar discordância com a idéia do outro, nem criticar a idéia ou comentar sobre a importância da mesma; É aceitável, claro, que um participante expanda a idéia sugerida por outro com detalhes adicionais ou idéias relacionadas.

26 Sugestão Temporal Etapas Iniciais Entrevista desestruturada
Questionário tipo Sim/Não Brainstorming Etapas Intermediárias Entrevista estruturada Etapas Finais Rastreamento de Processo Não existe uma melhor técnica. Cada situação exige uma abordagem específica.

27 Documento de Requisitos
Introdução Objetivo Especificar o objetivo do Documento de Requisitos Escopo Identificar pelo nome o produto do software a ser produzido Explicar o que o produto fará (alto nível) Descrever a aplicação do produto, incluindo benefícios relevantes Visão Geral Descrever como o restante do documento está organizado

28 Documento de Requisitos
Descrição Geral do Produto Requisitos Funcionais: Fornecer uma relação das funções do sistema por meio de textos, detalhando cada campo A lista de funções deve ser compreensível para o cliente ou para qualquer um. Requisitos Não-Funcionais: Deve incluir uma relação das exigências do produto, tais como: Estilos de interface e relatórios; Plataformas a serem adotadas: S.O., BD, linguagens; Limites de Memória;