Engenharia de Requisitos

Prévia do material em texto

Aula 3 – Engenharia de Requisitos
Somerville – Pags 79-111
Prof. MSc. Priscila Facciolli
Prof. Dr. Renato Dutra
Profa. MSc. Roberta Aragon
Profa. Vanessa C. Lourenço
*
*
Introdução
	Muitos problemas de Engenharia de Software originam-se da imprecisão na especificação de requisitos ( Levantamento de Necessidades)
	Atraso na entrega do sistema;
	Aumento dos custos.
“O começo é a parte mais importante do trabalho.” (Platão)
*
E-Mail do Cliente
	Para: Lucas Bender	Enviado: Qui 23/11/2006 14:45
	De: Ancelmo Marques
	Assunto: Solicitação para desenvolvimento de sistema
	Prezados Senhores!
Conforme conversa telefônica, nós da Universidade Estudo Certo solicitamos uma proposta para o desenvolvimento de um sistema de matrículas, visto que nosso processo ainda é totalmente presencial e em grande parte manual e demorado.
 
Este novo sistema deverá permitir aos professores e alunos acessar o sistema através da Internet. Futuramente deverá permitir que os professores mantenham as notas dos alunos de suas disciplinas.
O objetivo deste novo sistema é, além de agilizar o processo de matrícula, melhorar a imagem da Instituição.
 
Desejamos ter o novo sistema disponível para o próximo período de matriculas, o que deverá ocorrer em Julho próximo.
 
Gostaríamos de agendar uma reunião para o discutirmos sobre a viabilidade do projeto.
Aguardo retorno.
 
Obrigado.
 
Ancelmo Marques
Diretor Acadêmico
*
E AGORA ????
*
Eu irei lá descobrir o que eles estão precisando e enquanto isso vocês todos comecem a programar !
*
Engenharia de Requisitos
	Objetivo
	Sistematizar o processo de definição dos requisitos, obtendo uma especificação correta e completa dos requisitos (IEEE, 1991).
	Desenvolver uma especificação completa, consistente e não ambígua, descrevendo o quê o produto de software irá fazer, mas não como ele será feito (Boehm, 1989).
*
*
Engenharia de Requisitos
	Processo para descobrir, analisar e documentar funções e as restrições de um sistema
	O produto desse processo é um Documento de Requisitos
	Documento de Requisitos de Software completo e consistente – preciso:
	Enteder o contexto em que o problema se situa:
	Objetivos do produto a ser desenvolvido.
	Funcionalidades do produto.
*
Importância da Engenharia de Requisitos
Erros são causados por diversas razões, mas a principal causa pode ser originada na especificação
(fonte: "Software Testing", Ron Patton)
Tipos de Requisitos
	Requisitos Funcionais - RF
	RF são requisitos diretamente ligados a funcionalidade do software
	Requisitos Não Funcionais – RNF
	Expressam restrições que o software deve atender ou qualidades específicas que o software deve ter
	Requisitos de Domínio ou Regras de Negócio - RN
	Requisitos provenientes do domínio da aplicação do sistema
*
*
Requisitos Funcionais - Funções do Sistema
	O que o sistema deve fazer?
	Declarações de funções que o sistema deve fornecer;
	Como o sistema deve reagir a entradas específicas;
*
Exemplos de Requisitos	
	Funcionais
	“O sistema deve permitir que o usuário cadastre os clientes...”
	“O sistema deve permitir que o gerente emitia relatório de vendas do dia...”
	“O Sistema deve permitir que a atendente cadastre as locações...”
	Não Funcionais
	“O sistema deve ser utilizado em plataforma Windows...”
	“O sistema deve ter restrições de segurança solicitando login e senha ...”
	“O sistema deve acessar o banco de dados Oracle...”
	Requisitos de Domínio ou Regras de Negócio
	“A média para passar na disciplina é 6,0”
	“Não se pode fazer uma matricula caso o pré-requisito não esteja cursado...”
*
*
Requisitos Não Funcionais
	Não dizem respeito diretamente às funções específicas fornecidas pelo sistema;
	Colocam restrições no sistema;
	Restrições sobre os serviços ou as funções oferecidos pelo sistema;
	Por exemplo:
	Restrições de tempo de resposta, desempenho, espaço em disco, portabilidade, entre outros.
*
Exemplos de requisitos não funcionais
	Velocidade
	Transações processadas / segundo
	Tempo de resposta ao usuário / evento
	Facilidade de uso
	Tempo de treinamento
	Nível de detalhe de ajuda on-line
	Confiabilidade
	Tempo médio para falhar
	Probabilidade de indisponibilidade
	Disponibilidade
	Robustez
	Tempo de reinício depois de uma falha
	Porcentagem de eventos que causam falhas
	Portabilidade
	Número de sistemas-alvo (especificar cada sistema-alvo) 
Requisitos não funcionais - Classificação
	Produto: Referem-se a características do comportamento do produto que esta sendo desenvolvido
	Organizacional: São procedentes de políticas e procedimentos definido nas organizações do cliente e do desenvolvedor.
	Externo: Impostos tanto ao produto quanto ao processo 	de desenvolvimento em função do ambiente no qual o sistema é desenvolvido
Requisitos Não Funcionais
*
Exemplos Requisito Não Funcional de Produto
	RNF de usabilidade: usuarios devem ser
	capazes de usar as funções do sistema após
	duas horas de treinamento
	RNF de confiabilidade: o sistema deve
	estar disponível 99% das vezes
	RNF de segurança: o acesso aos dados
	deve ser protegido, conforme RN01
	RNF de desempenho: o sistema deve
	processar 1000 transações por segundo
Exemplos Requisito Não Funcional de Produto
	RNF de capacidade: o sistema deve
	suportar 270 usuários concorrentemente
	RNF de portabilidade: o sistema deve
 rodar nas plataformas X e Y
Exemplos Requisito Não Funcional Organizacional
	RNF de entrega: um relatório de progresso
 deve ser entregue toda semana
	RNF de implementação: o sistema deve ser
 implementado em .Net
Exemplos Requisito Não Funcional Externo
	RNF de interoperabilidade: o sistema deve
 interagir com os sistemas Compras e Vendas
	RNF de restricoes éticas: o sistema não
 deverá revelar aos operadores nenhuma
 informação pessoal dos clientes
	RNF de restricoes legais: o sistema deverá
 armazenar as informações de acordo com a Lei
 número XXYY do ano de XXXX.
Atividade 1 - Identificar Requisitos Funcionais, Requisitos não funcionais e Requisitos de domínio
Uma biblioteca deve automatizar seus registros de livros, leitores e empréstimos. Esse sistema deve ser utilizado através do navegador Firefox.
Suponha que seus procedimentos sejam básicos, onde não há reserva de livros, o prazo de devolução é de uma semana, não há multa e o leitor não tem limite máximo para retirada de livros. 
O sistema deve permitir a consulta da bibliotecária ou leitor ao acervo, indicando se o livro está retirado ou disponível, imprimir relatórios de leitores, leitores em atraso e livros disponíveis e retirados.
O sistema de rodar 24 horas x 7 dias, com tempo máximo de resposta de 10 segundos.
*
	Quando um paciente deseja marcar uma consulta, a atendente deve verificar a agenda do dentista e oferecer o primeiro horário disponível (data e hora), de acordo com o que o paciente deseja. 	Caso o paciente concordar com o horário, é registrado na agenda o nome do paciente e horário combinado. 
	Os pacientes já cadastrados têm a ficha de consulta preenchida automaticamente. Os pacientes novos devem fornecer seus dados de cadastro: RG, endereço, telefone, data nascimento, profissão. 
	A consulta consiste de 2 tipos de serviços: de limpeza e restauração, ou exames para diagnóstico. Na realização da consulta, o dentista faz o registro do serviço efetuado em detalhes e, se necessário, o paciente marca uma nova consulta. 	O dentista pode pesquisar as fichas de seus pacientes por nome ou data de consultas.
 O Sistema deve ficar pronto até outubro de 2014.
Atividade 2 – Clínica odontológica
Atividade 3 – Locadora de filmes
	Ao realizar uma locação, o sócio deve primeiro informar seu código para que o atendente possa verificar se este esta cadastrado no sistema. Caso o sócio não esteja cadastrado, a locação deverá ser recusada e o sócio poderá ser cadastrado. Caso esteja cadastrado, o atendente deve verificar se o sócio em questão já devolveu todas as locações feitas anteriormente,se não o tiver feito a locação deverá ser recusada.
	Caso o sócio esteja em conformidade com os requisitos acima, deverá informar as cópias dos filmes que deseja locar.Em seguida o atendente registrará a locação e fornecerá as cópias em questão para o sócio.
	É responsabilidade do atendente realizar a manutenção dos filmes e de suas respectivas cópias. Registrando novos filmes adquiridos pela locadora, por exemplo.
Processos de Engenharia de Requisitos
	Objetivo
	 Criar e manter um documento de requisitos
*
Engenharia de Requisitos
	Visão tradicional
*
Estudos de Viabilidade
	Conjunto preliminar de requisitos de negócios, um esboço da descrição do sistema e como o sistema pretende apoiar os processos de negócios
	Estudo breve e focalizado que procura responder a uma séria de questões:
	O Sistema contribui para os objetivos gerais da organização?
	O sistema pode ser implementado com tecnologia atual de dentro das restrições definidas de custo e prazo?
	O sistema pode ser integrado a outros sistemas já implantados?
*
Estudos de Viabilidade
	Envolve a avaliação de informações, sua coleta e a elaboração de um relatório.
	Após a identificação das informações podem surgir outras questões:
	Como a organização se comportaria se o sistema não fosse implementado?
	Quais são os problemas com os processos atuais e como o novo sistema ajudaria a reduzir esses problemas?
	Qual será a contribuição direta do sistema para os objetivos e requisitos da empresa?
	As informações podem ser transferidas e recebidas de outros sistemas da organização?
	O sistema requer tecnologia que ainda não foi usada na organização?
	O que deve ser apoiado pelo sistema e o que não precisa ser apoiado?
*
Elicitação e Análise de Requisitos
	Nessa atividade os engenheiros de software trabalham com os clientes e os usuários finais para aprender sobre o domínio da aplicação
	Quais serviços o sistema deve fornecer, o desempenho esperado, restrições de hardware, etc.
	Pode envolver várias pessoas na organização, os stakeholders (envolvidos, afetados, interessados)
*
Elicitação e Análise de Requisitos
Dificuldades
*
Elicitação e Análise de Requisitos
Atividades do Processo
*
Elicitação e Análise de Requisitos
Atividades do Processo
	 Obtenção de requisitos
	Interação com stakeholders para coletar requisitos
	Entrevistas, Reuniões, Questionários, Prototipagem, Role Playing, Observação Direta, etc.
	Classificação e organização de requisitos
	Agrupa requisitos relacionados
	Priorização e negociação de requisitos
	Vários stakeholders => requisitos conflitantes
	Documentação de requisitos
	Documentação de requisitos levantados.
*
Elicitação e Análise de Requisitos
Obtenção de Requisitos
*
Especificação de Requisitos
	Detalhamento e descrição dos requisitos obtidos de acordo com um template padrão
*
	 Requisitos realmente definem o sistema?
	 O que deve ser feito?
	Verificações de validade
	Verificações de consistência
	Sem conflitos
	Verificações de completude
	Requisitos definem o sistema como um todo?
	Verificações de realismo
	É possível fazer em termos de prazo e custo?
	Facilidade de verificação
	Linguagem padronizada de escrita de requisitos
Validação de Requisitos
*
	Realizada através de:
	 Revisões
	Problema: Quem vigia o vigia?
	 Prototipação
	 Casos de teste
	Antes de implementar: Implementar o caso de teste
	Se o teste é difícil de se implementar...
	Então o código também é!
	Re-analisar os requisitos...
Validação de Requisitos
*
	Fato: Requisitos mudam...
	 Utilizar ferramentas que permitam a rastreabilidade de requisitos.
	Armazenamento de requisitos
	Gerenciamento de mudanças
	Ligação entre requisitos e artefatos gerados por ele.
	Diagramas de análise
	Casos de uso
	Código
Gerenciamento de Requisitos
*
*
Documento de Requisitos
	O Documento de Requisitos do sistema deve ser composto por sentenças em linguagem natural, seguindo determinados padrões:
Iniciar com “O sistema deve…”
Usar frases curtas.
“ O sistema deve rodar em microcomputadores da linha IBM PC que possuam microprocessador 486 DX ou superior.”
*
Documento de Requisitos
Os requisitos devem estar organizados logicamente
Cada requisito deve ter um identificador único.
	Um identificador numérico, para posterior referência.
Os requisitos do software devem estar divididos em requisitos funcionais e não funcionais.
Os requisitos não devem conter detalhes de implementação
	É importante não utilizar termos relacionados à implementação, tais como “arquivo” e “menu”.
*
*
Padrão IEEE para o Documento de Requisitos
Introdução
1.1 Propósito do documento de requisitos
Motivações, público alvo, …
1.2 Escopo do produto
Explicitar o que o produto faz (e o que não faz).
Descrever a aplicação.
1.3. Definições, abreviações
1.4. Referências
Listar todos os documentos referenciados.
Especificar a origem dos documentos.
1.5. Visão Geral do restante do documento
Estrutura / Organização.
*
*
Padrão IEEE para o Documento de Requisitos
Descrição Geral
2.1 Perspectiva do Produto
Relacionamento: sistema, usuário, hardware, software, comunicação.
2.2 Funcionalidades do produto
2.3. Características do Usuário
2.4. Restriçoes Gerais
Limitações de hardware, consideraçoes sobre segurança.
2.5. Suposições e Dependências
Máquina específica, SO, ...
Apêndices
Índice
*
Questões para discussão
	Qual a importância da Engenharia de Requisitos para a qualidade do software?
	O que podemos fazer para minimizar os problemas dos fatores críticos referentes à Engenharia de Requisitos?
	Quais os principais cuidados a serem tomados na Engenharia de Requisitos?
*
Referências
	Sommerville, I. Engenharia de Software
	www.ieee.org