003 Engenharia de Requisitos

Prévia do material em texto

03/09/2014 
1 
Engenharia de Requisitos 
Análise e Projeto de Sistemas Orientados a Objetos 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Slides referência: Prof. Diego Asfora 
O que são Requisitos? 
São descrições dos serviços fornecidos pelo 
sistema e suas restrições operacionais 
Descrevem comportamento, propriedade e atributo 
dos sistemas 
Esses requisitos refletem as necessidades dos 
clientes de um sistema que ajuda a resolver algum 
problema 
Exemplos de Requisitos 
O sistema deve manter registro de todas as 
transações do banco, incluindo: saques, 
transferências e depósito; 
O sistema deve permitir os usuários pesquisarem 
um item através do titulo, autor ou ano; 
O sistema deve permitir que alunos visualizem as 
notas obtidas por semestre letivo; 
Tipos de Requisitos 
Requisitos Funcionais 
• Definição das funções que um sistema ou componente do 
sistema deve fazer 
• Ex. O sistema deve permitir a busca de livros por título, 
autor ou ISBN 
Requisitos Não Funcionais 
• Relacionados com restrições e aspectos de qualidade 
• Ex. O sistema deve ser fácil de usar 
Requisitos Organizacionais 
• Metas da empresa, suas políticas estratégicas adotadas 
• Ex. O sistema deve agilizar o atendimento de estudantes 
Requisitos de Usuário 
Descrevem os requisitos funcionais e não 
funcionais, de modo que eles sejam compreensíveis 
pelos usuários 
Especificam apenas o comportamento externo do 
sistema e evita características de projeto do sistema. 
Descrita sempre em linguagem simples, com 
tabelas, formulários e diagramas intuitivos 
Não deve conter jargões de software 
Exemplo de Requisitos do Usuário 
“O software deve fornecer um meio de 
representar e acessar arquivos externos 
criados por outras ferramentas” 
 
 
“O aplicativo deve fornecer um sistema de 
contabilidade que mantenha registros de 
todos os pagamentos realizados pelos 
usuários do sistema” 
03/09/2014 
2 
Requisitos de Sistema 
Versões expandidas dos requisitos do usuário. 
 
Estabelecem detalhadamente as funções e 
restrições do sistema. 
 
O documento de requisitos, chamado de 
especificação funcional, pode servir como um 
contrato entre cliente e desenvolvedor. 
Exemplos de Requisitos do Sistema 
O usuário deve dispor de recursos para definir o tipo 
dos arquivos externos. 
Cada tipo de arquivo externo pode ter uma 
ferramenta associada que pode ser aplicada a ele. 
Cada tipo de arquivo externo pode ser representado 
por um ícone. 
Quando um usuário seleciona um ícone, o efeito 
desta seleção é aplicar a ferramenta associada com o 
tipo de arquivo. 
O que são Stakeholders do Sistema? 
Pessoas ou organizações que serão afetados 
pelo sistema e que tem influência direta e 
indireta nos requisitos do sistema 
Exemplos: 
• Engenheiros de software 
• Usuários finais do sistema 
• Os gerentes dos usuários finais do sistema 
• Fiscais externos 
• Especialistas de domínio 
• Etc. 
Importante!! 
É fundamental a 
identificação dos 
stakeholders para uma 
melhor definição dos 
requisitos do sistema! 
O que é Engenharia de Requisitos? 
Processo de descobrir, analisar, documentar e 
verificar os requisitos de um sistema de 
software 
Conjunto de atividades relacionadas que 
funciona como uma ponte entre o mundo real 
das necessidades dos usuários e as 
capacidades e oportunidades geradas pela 
tecnologia da informação 
O que é Gerenciamento de Requisitos? 
Requisitos de sistemas de software de grande porte 
estão sempre mudando 
Como o problema a ser resolvido via software não 
pode ser totalmente definido, os requisitos tendem a 
ser incompletos 
Gerenciamento de Requisitos é o processo 
responsável por gerenciar quaisquer mudanças nos 
requisitos do sistema 
Gerenciar mudanças é necessário para: 
• Refletir mudanças de objetivos, negócios, etc. 
• Fazer com que elas sejam benéficas 
• Controlar e avaliar o impacto que elas trazem ao sistema 
03/09/2014 
3 
O que são Documentos de Requisitos? 
Declaração oficial dos requisitos 
do sistema para clientes, usuários 
e desenvolvedores 
O que faz um Analista de Requisitos? 
O analista de requisitos deve: 
• Identificar o problema/solução 
• Se tornar um especialista no domínio da 
aplicação 
Requisitos Funcionais 
São as declarações de serviços que o sistema deve oferecer, 
como o sistema deve reagir a entradas específicas e como o 
sistema deve se comportar em determinadas situações 
Em alguns casos, o requisitos funcionais podem também 
estabelecer o que o sistema não deve fazer 
Os requisitos funcionais podem ser expressos de várias formas. 
Eles são coletados a partir dos requisitos de usuário levantados 
Requisitos do Usuário 
Requisito 
Funcional 
Requisito 
Funcional 
Requisito 
Funcional 
Requisito 
Funcional 
Requisito 
Funcional 
Exemplos de Requisitos Funcionais 
“O usuário deve ser capaz de fazer uma busca em 
todo o conjunto inicial do banco de dados ou 
selecionar um subconjunto com base nele” 
 
“O sistema deve fornecer telas apropriadas para o 
usuário ler os documentos no repositório de 
documentos” 
 
“Para cada pedido, deve ser alocado um único 
identificador (ORDER_ID), o qual o usuário deve ser 
capaz de copiar para a área de armazenamento 
permanente da conta” 
Requisitos Não Funcionais 
São os requisitos não diretamente ligados às funcionalidades 
do sistema 
Descrevem qualidades do sistema (como o sistema é), por 
isso também são chamados de requisitos de qualidade 
Tipos de requisitos não funcionais: 
• Requisitos do produto: Especificam o comportamento do 
produto 
• Requisitos organizacionais: Especificam as políticas e 
procedimentos da organização do cliente 
• Requisitos externos: Especificam requisitos derivados de 
fatores externos 
Tipos de Requisitos Não Funcionais 
Requisitos 
não 
funcionais 
Requisitos 
organizaciona
is 
Requisitos 
de produto 
Requisitos 
externos 
Requisitos 
de eficiência 
Requisitos 
de 
confiabilidade 
Requisitos 
de 
portabilidade 
Requisitos de 
interoperabilida
de 
Requisitos 
éticos 
Requisitos de 
Facilidade de 
uso 
Requisitos 
de entrega 
Requisitos 
de 
implementação 
Requisitos 
de padrões 
Requisitos 
legais 
Requisitos 
de 
desempenho 
Requisitos 
de espaço 
Requisitos 
de 
privacidade 
Requisitos 
de 
segurança 
Fonte: Sommerville 
03/09/2014 
4 
Exemplos de Requisitos Não Funcionais 
Requisitos do Produto 
• “A interface de usuário para o sistema deve ser implementada como 
simples HTML, sem frames ou applets de java” 
 
Requisitos Organizacionais 
• “O processo de desenvolvimento do sistema e os documentos a serem 
entregues devem estar em conformidade com o processo e produtos a 
serem entregues definidos em X” 
 
Requisitos Externos 
• “O sistema não deve revelar quaisquer informações pessoais sobre os 
usuários do sistema ao pessoal da biblioteca que usa o sistema, com 
exceção do nome e número de referência da biblioteca” 
Problemas dos Requisitos Não Funcionais 
Não são fáceis de verificar 
Normalmente, estes requisitos são definidos 
pelos clientes como metas gerais 
Metas gerais causam problemas aos 
desenvolvedores por não serem verificáveis 
É importante que os requisitos não funcionais 
sejam verificáveis por teste 
Problemas dos Requisitos Não Funcionais 
Exemplo de requisito não funcional não verificável 
• “O sistema deve ser fácil de ser usadopelos controladores 
experientes e ser organizado de modo que os erros dos 
usuários sejam minimizados” 
 
Exemplo de requisito não funcional verificável 
• “Os controladores experientes devem ser capazes de usar 
todas as funções do sistema depois de um treinamento no 
total de duas horas. Após o treinamento, o número médio 
de erros cometidos pelos usuários experientes não de 
exceder dois por dia” 
Documento de Requisitos de Software 
Pode ser chamado também de documento de 
visão 
Declaração oficial do que os desenvolvedores 
devem implementar 
Inclui requisitos de usuário e uma especificação 
detalhada dos requisitos do sistema 
O documento serve de compromisso entre a 
comunicação dos requisitos para os clientes e os 
desenvolvedores 
PROCESSOS DE 
 
ENGENHARIA DE REQUISITOS 
Processos de Engenharia de Requisitos 
Tem como objetivo criar e manter um documento de 
requisitos de sistema 
Processo que especifica todas as atividades que auxiliam na 
produção de um documento de requisitos e sua manutenção 
ao longo do tempo 
Envolve todas as atividades dedicadas a identificação, 
análise, documentação e validação de requisitos de acordo 
com as necessidades dos usuários; bem como os processos 
que deem suporte a essas atividades 
Fornece métodos, técnicas e ferramentas que auxiliam o 
processo de compreensão e registro dos requisitos do 
software 
03/09/2014 
5 
Processos de Engenharia de Requisitos 
Estudo de 
Viabilidade Elicitação e 
análise de 
requisitos 
Especificação 
de requisitos 
Validação de 
requisitos 
Relatório de 
viabilidade 
Modelos de 
sistema 
Requisitos de 
usuário 
e de sistema 
Documento 
de requisitos 
Processos de Engenharia de Requisitos 
Estudo de 
Viabilidade Elicitação e 
análise de 
requisitos 
Especificação 
de requisitos 
Validação de 
requisitos 
Relatório de 
viabilidade 
Modelos de 
sistema 
Requisitos de 
usuário 
e de sistema 
Documento 
de requisitos 
Estudos de Viabilidade 
Em todos os sistemas novos, o processo de 
engenharia de requisitos deve começar com um 
estudo de viabilidade 
Entrada para os estudos de viabilidade 
Requisitos de negócio 
Esboço da descrição do sistema 
Como o sistema pretende apoiar os processos de negócio 
Resultado dos estudos 
Relatório contendo a recomendação se vale a pena ou não 
prosseguir 
Processos de Engenharia de Requisitos 
Estudo de 
Viabilidade Elicitação e 
análise de 
requisitos 
Especificação 
de requisitos 
Validação de 
requisitos 
Relatório de 
viabilidade 
Modelos de 
sistema 
Requisitos de 
usuário 
e de sistema 
Documento 
de requisitos 
Elicitação e Análise de Requisitos 
ELICITAR: descobrir, tornar explícito, obter o máximo de 
informações para o conhecimento do objeto em questão 
Processo para a identificação dos fatos que compõem os 
requisitos do sistema, de modo a prover o mais correto e mais 
completo entendimento do que é demandado daquele 
software 
Engenheiros de requisitos trabalham com os clientes e 
usuários finais (stakeholders) para aprender sobre o domínio 
da aplicação, quais serviços o sistema deve fornecer, etc. 
Dificuldades do Processo de Elicitação 
Os stakeholders frequentemente não sabem o que querem 
do sistema de computador 
Os stakeholders expressam os requisitos naturalmente em 
seus próprios termos o que dificulta o entendimento dos 
engenheiros de requisitos que não possuem experiência no 
domínio do cliente 
Diferentes stakeholders possuem diferentes requisitos, 
expressos de diferentes formas 
Fatores políticos podem influenciar os requisitos de sistema 
Resistência dos usuários ao novo sistema 
03/09/2014 
6 
Atividades da Elicitação 
Entendimento do domínio da aplicação 
• O conhecimento do domínio da aplicação é o conhecimento 
geral onde o sistema será aplicado 
Entendimento do problema 
• Os detalhes dos problemas específicos do problema do 
cliente onde o sistema será aplicado deve ser entendido 
Entendimento do negócio 
• Deve-se entender como os sistemas interagem e 
contribuem de forma geral com os objetivos de negócio 
Entendimento das necessidades e limitações dos 
stakeholders do sistema 
Estágios da Elicitação 
Aquisição de 
conhecimento e 
background 
Organização do 
conhecimento 
Coletar os 
requisitos do 
stakeholders 
Definir objetivos 
Estágios da Elicitação 
Definir objetivos 
• Os objetivos organizacionais devem ser estabelecidos 
incluindo objetivos gerais do negócio, um descrição geral 
do problema a ser resolvidos porque o sistema é 
necessário e as limitações do sistema. 
 
Aquisição de conhecimento do background 
• Informação de background do sistema inclui informação 
acerca da organização onde o sistema será instalado, o 
domínio de aplicação do sistema e informação acerca de 
outros sistemas existente 
Estágios da Elicitação 
Organização do conhecimento 
• A grande quantidade de conhecimento que foi coletada nos 
estágios anteriores devem ser organizadas e colocadas em 
ordem 
 
Coletar os requisitos dos stakeholders 
• Os stakeholders do sistema são consultados para 
descoberta de seus requisitos 
Análise dos Requisitos 
Tem como objetivo descobrir problemas, 
incompletudes e inconsistências nos requisitos 
elicitados 
A análise é intercalada com elicitação 
• Pois problemas são descobertos quando os 
requisitos são elicitados 
Uma lista de verificação (checklist) de problemas 
poderá ser usada para ajudar a análise 
Ao final desta atividade, os requisitos desnecessários 
são descartados, os requisitos críticos são identificados 
e alguns requisitos são atualizados 
 
Análise e Negociação dos Requisitos 
Requisitos 
desnecessário
s 
Requisitos 
incompletos e 
inconsistentes 
Requisitos 
inviáveis 
Checagem 
da 
necessidade 
Checagem 
da consistência 
e completude 
Checagem 
da 
viabilidade 
Análise 
Discutir 
os 
requisitos 
Priorizar 
os 
requisitos 
Acordar 
os 
requisitos 
Negociação 
03/09/2014 
7 
Análise dos Requisitos 
Checagem da necessidade 
• A necessidade dos requisitos é analisada. Em alguns 
casos, alguns requisitos propostos podem não contribuir 
para os objetivos de negócio da organização ou para o 
problema específico tratado pelo sistema 
Checagem de consistência e completude 
• Os requisitos são checados entre si para determinar 
consistência e completude. Consistência significa que 
nenhum requisito deve ser contraditório. Completude 
significa que nenhum serviço (ou limitação) que seja 
necessário foi esquecido 
Análise dos Requisitos 
Checagem de viabilidade 
• Os requisitos são checados para garantir que são viáveis 
dentro do orçamento e tempo disponível para o 
desenvolvimento do sistema 
Discutir os requisitos 
• Os requisitos que foram identificados como problemáticos 
são discutidos e os stakeholders envolvidos apresentam 
seus pontos de vista acerca dos requisitos 
Análise dos Requisitos 
Priorizar os requisitos 
• Os requisitos disputados são priorizados para identificar 
requisitos críticos e ajudar o processo de tomada de 
decisão 
 
Concordância dos requisitos 
• Soluções para os problemas dos requisitos são 
identificadas e um conjunto de requisitos são acordados. 
Geralmente isto envolve mudanças em alguns dos 
requisitos. 
Exemplo de Lista de Verificação da Análise 
Projeto prematuro 
• Os requisitos incluem informação prematura de projetoou 
implementação? 
Requisitos combinados 
• A descrição dos requisitos descreve um requisito único ou 
pode ser descrito em vários requisitos diferentes? 
Requisitos desnecessários 
• O requisito é realmente necessário ou será que é uma 
mera adição cosmética ao sistema? 
Exemplo de Lista de Verificação da Análise 
Está de acordo com os objetivos do negócio 
• O requisito é consistente com os objetivos de negócio 
definidos na introdução do documento de requisitos? 
Ambiguidade de requisitos 
• O requisito é ambíguo? 
• Quais são as possibilidades de interpretação dos 
requisitos? 
Técnicas de Elicitação 
O profissional de engenharia de requisitos deve selecionar as 
técnicas a serem utilizadas e estabelecer de que maneira elas 
serão integradas 
Existem técnicas especiais que podem ser usadas para 
coletar conhecimento sobre os requisitos dos usuários 
A escolha das técnicas e seu esquema de integração 
dependerá do problema e da equipe participante 
Um ponto importante é ter conhecimento sobre 
as técnicas e identificar onde uma técnica se 
encaixa melhor que outra 
03/09/2014 
8 
Técnicas de Elicitação - Dicas 
Sempre pergunte: 
• O que? 
• Por que(m)? 
• Como? 
Pergunte o óbvio 
Organize as respostas 
• Durante e depois 
Viva a situação durante um tempo 
Observe tudo 
Seja humilde, procure aprender! 
Algumas Técnicas de Elicitação 
Entrevista 
Leitura de documentos 
Questionários 
Análise de protocolos 
Etnografia 
Cenários 
Observações e análise sociais 
Reuso de requisitos 
Reuniões 
Brainstorming 
Prototipagem 
Workshops 
Entrevistas 
O engenheiro de requisitos ou analista 
discute sobre o sistema com diferentes 
stakeholders para obter um entendimento dos 
requisitos 
Ponto forte 
• Contato direto com o usuário e validação 
imediata 
Ponto fraco 
• Algumas vezes o conhecimento está 
dentro da cabeça das pessoas e é difícil de 
ser formalizado 
• Diferenças de culturas 
Tipos de Entrevistas 
Entrevistas Fechadas 
• O engenheiro de requisitos já inicia a entrevista com um 
conjunto de questões pré-definidas 
 
Entrevistas Abertas 
• É uma conversa mais informal, o engenheiro de requisitos 
discute, de forma aberta, o que o stakeholder quer do 
sistema 
Leitura de Documentos 
Fontes importantes de informação 
podem ser documentos, livros 
sobre os temas, etc. 
Ponto forte 
• Facilidade de acesso e volume 
de informações 
Ponto fraco 
• Dispersão de informações 
• Volume de trabalho 
Questionários 
Utilizado quando existe conhecimento sobre o 
problema e grande número de clientes 
Funciona como uma pesquisa qualitativa 
Possibilitam análises estatísticas 
Ponto forte 
• Padronização das perguntas 
• Tratamento estatístico das respostas 
Ponto fraco 
• Limitação do universo de respostas 
• Pouca iteração 
03/09/2014 
9 
Prototipagem 
Um protótipo é uma versão inicial de um sistema que poderá 
ser usado para experimentação. 
 
Protótipos são úteis para elicitação de requisitos porque os 
usuários poderão experimentar o “sistema” e mostrar os 
pontes fortes e fracos. Eles terão algo concreto para criticar. 
 
O desenvolvimento rápido dos protótipos é essencial para 
que eles fiquem disponíveis logo para o processo de elicitação 
Benefícios da Prototipagem 
O protótipo permite que os usuários experimentem e 
descubram o que eles realmente necessitam para suportar o 
trabalho deles 
Estabelece a viabilidade e utilidade antes que altos custos 
de desenvolvimento tenham sido realizados 
Essencial para desenvolvimento do aspecto ‘look and feel’ 
da interface do usuário 
Pode ser usado para teste do sistema e desenvolvimento da 
documentação 
Força um estudo detalhado dos requisitos, revelando 
inconsistências e omissões 
Etnografia 
Técnica de observação utilizada para 
compreender os requisitos sociais e 
organizacionais 
O analista se insere no ambiente de 
trabalho onde o sistema será utilizado, 
observando o dia-a-dia e anota tudo 
O motivo de uso desta técnica é que 
muitas vezes as pessoas consideram muito 
difícil articular detalhes do seu trabalho por 
considerar secundário para elas 
Etnografia 
O etnógrafo procura ter a mesma 
perspectiva do cliente 
Ponto forte 
• Visão mais completa e perfeitamente 
ajustada ao contexto 
Ponto fraco 
• Tempo gasto e pouca sistematização do 
processo 
 
Reuso de Requisitos 
Reuso envolve considerar requisitos que foram 
desenvolvidos para um sistema e usá-los em sistemas 
diferentes 
O reuso de requisitos economiza tempo e esforço, pois 
requisitos reutilizados já foram analisados e validados em 
outros sistemas 
Atualmente o reuso de requisitos é um processo informal. 
Contudo, um reuso mais sistemático economizaria muito 
esforço 
Reuso de Requisitos 
É justamente a capacidade de se aproveitar análises 
anteriores que diferencia um analista experiente de um 
inexperiente 
Ponto forte 
• Produtividade e qualidade (componentes já validados) 
Ponto fraco 
• Dificuldade de se promover reutilização sem modificação 
03/09/2014 
10 
Brainstorming 
Brainstorming (tempestade cerebral) é 
uma técnica para geração de novas 
ideias, conceitos e soluções para 
qualquer assunto num ambiente livre de 
críticas e de restrições à imaginação 
 
Deve ser utilizada quando se deseja 
gerar uma grande quantidade de ideias 
sobre um assunto a ser resolvido em um 
curto espaço de tempo 
Negociação de Requisitos 
Problemas nos requisitos são inevitáveis 
quando um sistema possui muitos stakeholders. 
Conflitos não são falhas mas refletem 
necessidades e prioridades diferentes entre as 
partes interessadas 
A negociação de requisitos é o processo de 
discussão dos conflitos de requisitos e busca de 
um compromisso no qual todas as partes 
interessadas concordem 
No planejamento do processo de engenharia 
de requisitos, é importante deixar bastante 
tempo para negociação. Alcançar um 
compromisso aceitável pode tomar um tempo 
considerável 
Processos de Engenharia de Requisitos 
Estudo de 
Viabilidade Elicitação e 
análise de 
requisitos 
Especificação 
de requisitos 
Validação de 
requisitos 
Relatório de 
viabilidade 
Modelos de 
sistema 
Requisitos de 
usuário 
e de sistema 
Documento 
de requisitos 
Especificação dos Requisitos 
Tem como objetivo criar o Documento de 
Requisitos – principal produto de trabalho do 
processo de engenharia de requisitos 
 
O Documento de Requisitos descreve: 
• Serviços que o sistema deve prover 
• Limitações sobre as quais o sistema deve 
operar 
• Identificação de outros sistemas com o 
qual o sistema deve interagir 
Processos de Engenharia de Requisitos 
Estudo de 
Viabilidade Elicitação e 
análise de 
requisitos 
Especificação 
de requisitos 
Validação de 
requisitos 
Relatório de 
viabilidade 
Modelos de 
sistema 
Requisitos de 
usuário 
e de sistema 
Documento 
de requisitos 
Validação de Requisitos 
Tem como objetivo obter concordância dos stakeholders e 
garantir qualidade no processo de engenharia de requisitos 
Esta atividade se sobrepõe à análise 
Caso seja necessário, as atividades anteriores podem ser 
revisitadas 
Durante este processo, são realizadas as seguintes 
verificações: 
• Validade – o requisito é válido? 
• Consistência – existe conflito entre os requisitos? 
• Completeza – o requisito está completo? 
• Realismo – existe tecnologiapara atender o requisito? 
• Verificação – o requisito é verificável? 
03/09/2014 
11 
Técnicas de Validação de Requisitos 
Revisões de requisitos 
• Os requisitos são analisados sistematicamente por uma equipe de 
revisores 
 
Prototipação 
• Um modelo executável do sistema é apresentado para o cliente 
 
Geração de casos de teste 
• Requisitos devem ser testáveis 
• A partir da criação de testes dos requisitos durante o processo de 
validação, é possível que problemas nos requisitos sejam revelados 
Resumo 
Requisitos definem o que sistema deve fazer e as restrições 
sobre suas operações e implementação 
Requisitos funcionais definem os serviços que os sistema 
deve fornecer 
Requisitos não funcionais restringem o sistema que está 
sendo desenvolvido ou o processo de desenvolvimento 
O documento de requisitos é a especificação para os 
clientes, engenheiros e gerentes 
A elicitação de requisitos envolve a compreensão do domínio 
da aplicação, o problema específico a ser resolvido, as 
necessidades e limitações organizacionais e as facilidades 
especificas necessárias para as partes interessadas 
Resumo 
Os processos de elicitação de requisitos, análise e 
negociação são interativos e intercalados, precisando ser 
repetidos várias vezes 
Existem várias técnicas de elicitação de requisitos que podem 
ser usadas, incluindo entrevistas, cenários, prototipagem e 
observação dos participantes 
Listas de verificação são formas particularmente úteis para 
organizar o processo de validação dos requisitos. Elas 
lembram ao analista o que deve ser verificado quando da 
leitura dos requisitos propostos. 
Negociação dos requisitos é sempre necessária para resolver 
conflitos e remover a sobreposição de requisitos. 
Negociação envolve a troca de informação, discussão e 
resolução de conflitos. 
GERENCIAMENTO DOS 
REQUISITOS 
Gerenciamento de Requisitos 
É o processo sistemático de levantamento, 
organização e documentação dos requisitos 
do sistema, também, estabelecer e manter 
acordos entre o cliente e a equipe sobre as 
mudanças dos requisitos 
 
É preciso manter o acompanhamento dos 
requisitos individuais e manter a ligação 
entre os requisitos dependentes 
Requisitos Permanentes e Voláteis 
Requisitos permanentes 
• São requisitos relativamente estáveis derivados da 
atividade central da organização e que se relacionam 
diretamente ao domínio do sistema 
 
Requisitos voláteis 
• Mudanças nos requisitos são inevitáveis 
• Mudanças nos requisitos não necessariamente representa 
uma falha na engenharia de requisitos 
• Mudanças nos requisitos deve ser prevista no processo de 
desenvolvimento de um sistema 
03/09/2014 
12 
Fatores de Mudanças de Requisitos 
Erros, conflitos e inconsistências dos requisitos 
Evolução do conhecimento do cliente/usuário do 
sistema 
Problemas de custo, cronograma ou técnicos 
Mudanças nas prioridades do cliente 
Mudanças no ambiente 
Mudanças organizacionais 
Mudanças nas leis 
Planejamento de Gerenciamento de Requisitos 
Identificação 
de requisitos 
Processo de 
gerenciamento 
de mudanças 
Políticas de 
rastreabilidade 
Apoio de 
ferramentas 
CASE 
Planejamento de Gerenciamento de Requisitos 
Primeiro estágio essencial no processo de gerenciamento de 
requisitos 
 
Identificação de requisitos 
• Cada requisito deve ser identificado unicamente de modo que possa ser 
feita a referência cruzada entre este e outro requisito para que ele possa 
ser usado nas avaliações de rastreabilidade 
 
Processo de gerenciamento de mudanças 
• Conjunto de atividades que avaliam o impacto e custo das mudanças 
Planejamento de Gerenciamento de Requisitos 
Políticas de rastreabilidade 
• Essas políticas definem os relacionamentos entre os requisitos e o 
projeto do sistema, que devem ser registrados e como devem ser 
mantidos 
 
Apoio de ferramentas CASE 
• Estas ferramentas podem ser usadas para apoiar a gerência 
Planejamento de Gerenciamento de Requisitos 
Identificação 
de requisitos 
Processo de 
gerenciamento 
de mudanças 
Políticas de 
rastreabilidade 
Apoio de 
ferramentas 
CASE 
Por que deve se identificar os requisitos? 
É um requisito essencial para a gerencia de 
requisitos que os mesmos sejam identificados 
• Durante a gestão dos requisitos se faz necessário 
criar referências entre requisitos 
• As referências devem identificar unicamente e 
exatamente o requisito em questão para não gerar 
ambiguidade 
03/09/2014 
13 
Formas de Identificação e Armazenamento 
Usando número do capítulo ou seção do 
Documento de Requisitos 
• O mecanismo mais utilizado 
• Identificador baseado no número do capítulo e pelo 
número da seção onde o requisito foi detalhado no 
documento de requisitos 
Usando banco de dados 
• A chave primária da tabela de requisitos é o identificador 
Status de Requisitos (Possíveis Valores) 
Proposto 
• O requisito foi proposto por uma fonte e está pendente de aprovação 
para ser implementado 
Aprovado 
• O requisito foi analisado e seu custo de impacto no sistema foi 
detalhado. Pode ser implementado 
Implementado 
• Foi realizada a implementação do requisito 
Verificado 
• O requisito foi verificado 
Excluído 
• Foi removido do sistema 
Planejamento de Gerenciamento de Requisitos 
Identificação 
de requisitos 
Processo de 
gerenciamento 
de mudanças 
Políticas de 
rastreabilidade 
Apoio de 
ferramentas 
CASE 
Processo de Gerenciamento de Mudanças 
Envolve procedimentos, processos e padrões 
usados para gerenciar mudanças aos requisitos do 
sistema 
 
Políticas de gerência de mudanças 
• Processo de solicitação de mudanças e os documentos 
necessários para a mesma 
• Processo de análise do impacto e custo 
• Membros dos comitês que processam as solicitações de 
mudanças e realizam a análise de impacto 
• Ferramentas de suporte ao processo 
Processo de Solicitação de Mudança nos Requisitos 
Análise do 
problema e a 
especificação 
da mudança 
Análise de 
mudanças e 
estimativa de 
custo 
Implementação 
das mudanças 
Problema 
identificado 
Requisitos 
revisados 
Processo de Solicitação de Mudança nos Requisitos 
Análise do 
problema e a 
especificação 
da mudança 
Análise de 
mudanças e 
estimativa de 
custo 
Implementação 
das mudanças 
Problema 
identificado 
Requisitos 
revisados 
03/09/2014 
14 
Análise do problema e a especificação da mudança 
O processo se inicia com um problema de 
requisitos identificado ou uma proposta de mudança 
específica 
 
Durante esse estágio o problema ou proposta é 
analisada para verificar se é válida 
Processo de Solicitação de Mudança nos Requisitos 
Análise do 
problema e a 
especificação 
da mudança 
Análise de 
mudanças e 
estimativa de 
custo 
Implementação 
das mudanças 
Problema 
identificado 
Requisitos 
revisados 
Análise de mudanças e estimativa de custo O efeito da mudança proposta é avaliado usando as 
informações de rastreabilidade e o conhecimento 
geral sobre os requisitos do sistema 
 
O custo da mudança é estimado em termos de 
modificação no Documento de Requisitos, do projeto 
e da implementação 
 
Após feita esta análise, toma-se a decisão de sobre 
prosseguir ou não com a mudança 
Processo de Solicitação de Mudança nos Requisitos 
Análise do 
problema e a 
especificação 
da mudança 
Análise de 
mudanças e 
estimativa de 
custoImplementação 
das mudanças 
Problema 
identificado 
Requisitos 
revisados 
Implementação das Mudanças 
Documento de Requisitos e, quando necessário, 
o projeto e o código do sistema são modificados 
Solicitações Rejeitadas 
Uma solicitação pode ser rejeitada por um dos 
seguintes motivos 
• Solicitação inválida: O cliente mal interpretou os requisitos 
ou a alteração solicitada não se faz necessária 
 
• Se a alteração solicitada vai contra ou invalida outro 
requisito importante para o cliente 
 
• Se o custo ou tempo para realizar a alteração é muito alto 
03/09/2014 
15 
Comitê de Controle de Mudança 
É o comitê que determina que solicitações de mudança 
devem ser aprovadas 
Em grandes projetos pode ter vários níveis de aprovação 
Para a formação do comitê, é importante ter um 
representante de todos os grupos que são afetados pelas 
mudanças 
• Gerente de produto 
• Gerente de projeto 
• Desenvolvedor 
• Dept. comercial e vendas 
• Responsável pelos documentos do usuário 
• Suporte ao usuário 
• Gerente de configuração 
Planejamento de Gerenciamento de Requisitos 
Identificação 
de requisitos 
Processo de 
gerenciamento 
de mudanças 
Políticas de 
rastreabilidade 
Apoio de 
ferramentas 
CASE 
Políticas de Rastreabilidade 
Análise do impacto das alterações em um requisito nos 
outros requisitos e no próprio sistema 
• Se a mudança no requisito é feita durante a fase de elaboração dos 
requisitos, a análise deve envolver o impacto da alteração nos outros 
requisitos 
• Se a mudança for feita durante a fase de implementação do sistema, 
deve envolver na análise do impacto não só os outros requisitos mas 
também o projeto do sistema e a implementação atual 
• Se a mudança for colocada depois que o sistema já está em produção 
então, além dos outros requisitos, projeto e o código, deve levar em 
consideração o impacto para os stakeholders do sistemas 
Matriz de Rastreabilidade 
Mostra a relação entre os requisitos ou entre os 
requisitos e os componentes do projeto 
Tabela de Rastreamento 
A tabela de rastreamento substitui a matriz de 
rastreamento quando a quantidade de requisitos 
do projeto for muito grande 
Políticas de Rastreamento 
Deve detalhar que tipo de relacionamento vai ser rastreado 
 
Determina que tipo de matriz de rastreamento e quantas 
devem ser utilizadas 
 
Identifica os módulos do produto que devem ser rastreados 
Define claramente os padrões de nomenclatura ou fazer 
referência aos documentos do projeto 
03/09/2014 
16 
Resumo 
Mudanças nos requisitos são inevitáveis e devem 
ser encarados e planejados 
Identificar os requisitos voláteis e classificar seu tipo 
É essencial para o gerenciamento dos requisitos a 
identificação clara e inequívoca dos requisitos 
A política de gerenciamento de mudanças deve 
definir o processo e as informações que devem ser 
gerenciadas de cada requisito 
Resumo 
Suporte de ferramentas deve ser providenciado 
O rastreamento dos requisitos deve registrar a 
dependência existente entre os requisitos e/ou 
dependência com os módulos do sistema 
Coletar e manter informações de rastreamento tem 
um custo alto e a organização deve definir um nível 
de rastreamento necessário