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

Slides:



Advertisements
Apresentações semelhantes
Engenharia de Software
Advertisements

Análise e Projeto de Sistemas I
Requisitos de Software
Gerenciamento do escopo
Engenharia de Software
Metodologia Científica
Faculdade de Ciências Sociais de Aplicadas de Petrolina – FACAPE
Faculdade de Ciências Sociais e Aplicadas de Petrolina – FACAPE
Técnicas eTipos de Requisitos
Adélia Barros Requisitos Adélia Barros
SISTEMA DE INFORMAÇÕES DESENVOLVIMENTO DE SISTEMAS
Professor: Rogério Lopes Disciplina: Engenharia de Software II Fortium Sistemas da Informação Engenharia de Software II.
O processo de coletar os requisitos (escopo do cliente)
Simulação de Sistemas Prof. MSc Sofia Mara de Souza AULA2.
Extração de Requisitos
1 - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – Noções de Engenharia de Software COINFO – CEFET-PB Noções de Engenharia de Software.
Prof. Everton Lopes Bonifácio
Engenharia de Requisitos Requisito – sistema Caso de uso - usuário
Projeto de Interface Equipe: Margarete Cardoso Sheila Aguiar
Plano de Projeto de Software
ANÁLISE DE REQUISITOS DE ENGENHARIA DE SOFTWARE
Prof.Alfredo Parteli Gomes
PMBOK 5ª Edição Capítulo 3
Especificação de Requisitos de Software - ERSw
Fase de Elaboração: Fluxo de Requisitos
2.1. O USO MERCADOLÓGICO DA DISCUSSÃO EM GRUPO c
IEEE Std IEEE Melhores Práticas para Especificações de Requisitos de Software (ERS)
Engenharia de Requisitos
Análise e Projeto de Sistemas
REQUIREMENTS DEVELOPMENT DESENVOLVIMENTO DE REQUISITOS
DIRETRIZES PARA ESPECIFICAÇÃO DOS REQUISITOS DO SOFTWARE
Introdução e Fundamentos Engenharia de Requisitos
Fase de Concepção (Início, Planejamento)
Processo de Aquisição Adilson de Almeida Cezar Meriguetti
O Processo de desenvolvimento de software
Levantamento de Requisitos
Documentação de Software
Aula 7 – Planejamento do Levantamento
Levantamento de Requisitos
ANÁLISE ESTRUTURADA DE SISTEMAS
Requisitos (Complemento) Marcio de Carvalho Victorino.
Gestão de defeitos.
Elaboração da pesquisa científica: 4 fases
GERENCIAMENTO DE PROJETOS DE T.I
Qualidade no Desenvolvimento de Software Wolley W. Silva Baseado nas notas de aula dos professores Tatuo e Daisy.
Requisitos de Software
Técnicas e Projeto de Sistemas
Agência Nacional de Vigilância Sanitária SISTEMA DA QUALIDADE SEGUNDO A NBR ISO/IEC ANÁLISE CRÍTICA DOS PEDIDOS, PROPOSTAS E CONTRATOS.
Especificação de Requisitos de Software
Capítulo 3: Analisando Processos de Decisão de Negócios
Expansão dos Casos de Uso
Técnicas de Coleta de Dados
Engenharia de Conhecimento
Formulários.
Aula 02 de Eng. de Requisitos
Análise e Projeto de Sistemas Análise e Projeto de Sistemas Aula 2 Professor: Italo Rodrigues Castro.
Engenharia de Software com o RUP - Workflow de Requisitos
Engenharia de Software
ISO9001:2000 para Software Professor: Alexandre Vasconcelos Equipe: Amanda Pimentel Börje Karlsson Danielly Karine Erika Pessoa Jorge Cavalcanti Jose Edson.
Projeto de Sistemas - PRJ Aula 4
TÉCNICAS DE ESTIMATIVAS

DIRETRIZES PARA O DESENVOLVIMENTO DE MANUAIS DA QUALIDADE
CENTRO UNVERSÁTARIO PADRE ANCHIETA AULA 6 CURSO ENGENHARIA DE PRODUÇÃO DISCIPLINA: SISTEMAS DE INFORMAÇÕES GERENCIAIS (SIG) PROF: CÉSAR ANTONIO SOLDERA.
Técnicas e Tipos de Requisitos
Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
Extração de REQUISITOS Parte II. Segundo Pressman (1995), na analise e especificação de requisitos, a ambigüidade não só é possível mas é provável. “-
MÉTODO A opção pelo método de pesquisa, quantitativo e/ou qualitativo, orienta-se pela formulação do problema de pesquisa, objetivos e hipóteses. O método.
Elicitação de Requisitos Análise Orientada a Objetos Prof. Wolley W. Silva.
ROTEIRO PARA ELABORAÇÃO DE SISTEMA ESTRUTURADO
Transcrição da apresentação:

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

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.

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á.

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?

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.

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

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.

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.

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.

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.

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.

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

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);

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;

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.

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.

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.

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.

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.

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.

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.

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.

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.

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;

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.

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.

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

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;