Parte 1 Especificação de Requisitos

Prévia do material em texto

Engenharia de Software II 
 
Parte 1 
 
Especificação de Requisitos 
 
1 
 
Prof. Dr. Celso Gallão 
Fevereiro/2017 
F
A
T
E
C
 
S
Ã
O
 
C
A
E
T
A
N
O
 
Requisitos 
“Os Requisitos de um sistema são 
descrições dos serviços fornecidos pelo 
sistema e as suas restrições 
operacionais.” 
[SOMMERVILLE, 2007] 
1 
Engenharia de Software II – Prof. Celso Gallão – Slide 2 
Requisitos 
“Uma boa Engenharia de Requisitos é um 
passo essencial para o desenvolvimento 
de um bom produto, em qualquer caso” 
[Pádua Filho, 2001] 
 
1 
Engenharia de Software II – Prof. Celso Gallão – Slide 3 
1.1 – Visão Geral 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 4 
Requisitos 1 
1.1 – Visão Geral 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 5 
Os Requisitos refletem as necessidades dos 
clientes de um sistema que ajuda a resolver 
algum problema. 
 
Os Requisitos devem ser redigidos de modo que 
os diversos fornecedores possam apresentar 
propostas, oferecendo diferentes maneiras de 
atender às necessidades do cliente. 
 
Requisitos 1 
1.1 – Visão Geral 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 6 
Os Requisitos devem ser levantados pela equipe 
do projeto, em conjunto com representantes do 
cliente, usuários-chave e outros especialistas da 
área de aplicação. 
 
O Fluxo de Requisitos reúne as atividades que 
visam a obter o enunciado completo, claro e 
preciso dos requisitos de um produto de software. 
 
Requisitos 1 
1.1 – Visão Geral 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 7 
Engenharia de Requisitos: é o conjunto de 
técnicas empregadas para levantar, detalhar, 
documentar e validar os requisitos de um produto. 
 
Especificação de Requisitos de Software 
(ERSw): é um documento que especifica o 
resultado principal do fluxo de requisitos. 
 
Requisitos 1 
1.1 – Visão Geral 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 8 
No desenvolvimento de uma nova versão de um 
produto já existente: 
• A experiência dos usuários com as versões 
anteriores permite identificar de forma rápida e 
clara as necessidades prioritárias. 
 
 
Requisitos 1 
1.1 – Visão Geral 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 9 
No desenvolvimento de um novo produto: 
• É mais difícil para os usuários identificar quais 
as características de maior valor. 
• É mais difícil para os desenvolvedores entender 
claramente o que os usuários desejam. 
 
 
Requisitos 1 
1.1 – Visão Geral 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 10 
No desenvolvimento de um novo produto: 
 
 
Requisitos 1 
O que é necessário fazer. 
1.1 – Visão Geral 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 11 
No desenvolvimento de um novo produto: 
 
 
Requisitos 1 
O que é necessário fazer. O que os usuário querem. 
1.1 – Visão Geral 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 12 
No desenvolvimento de um novo produto: 
 
 
Requisitos 1 
O que é necessário fazer. O que os usuário querem. 
O que os usuários pedem. 
1.1 – Visão Geral 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 13 
No desenvolvimento de um novo produto: 
 
 
Requisitos 1 
O que é necessário fazer. O que os usuário querem. 
O que os desenvolvedores 
entendem. 
O que os usuários pedem. 
1.1 – Visão Geral 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 14 
No desenvolvimento de um novo produto: 
 
 
Requisitos 1 
O que é necessário fazer. O que os usuário querem. 
O que acaba sendo feito... 
O que os desenvolvedores 
entendem. 
O que os usuários pedem. 
1.1 – Visão Geral 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 15 
Requisitos 1 
Figura extraída de http://www.rrochas.com.br/ 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 16 
Requisitos 1 
1.2 – Conceitos Fundamentais 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 17 
1.2.1 - Requisitos Funcionais: 
• Descrevem o que o sistema deve fazer, em alto 
nível de abstração. 
• Descrevem conjuntos de entradas, seus 
comportamentos e as saídas. 
• Declaram serviços que o sistema deve fornecer. 
• Especificam como o sistema deve reagir às 
entradas. 
• Especificam resultados particulares de um 
sistema. 
 
Requisitos 1 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 18 
1.2.1 - Requisitos Funcionais: 
Dependem: 
• do tipo de software que está sendo desenvolvido; 
• dos usuários a que o software se destina; 
• da abordagem geral considerada pela organização. 
 
 
 
Requisitos 1 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 19 
1.2.1 - Requisitos Funcionais: 
Exemplo em um sistema para biblioteca online: 
1. O usuário deve ser capaz de fazer busca em todo o 
conjunto do banco de dados, ou selecionar um 
subconjunto com base nele. 
2. O sistema deve oferecer telas apropriadas 
(ajustáveis) para o usuário ler adequadamente os 
documentos. 
3. Para cada reserva de livro, deve ser alocado um 
único identificador, devendo ser registrado na área 
do usuário. 
 
Requisitos 1 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 20 
1.2.2 - Requisitos Não Funcionais: 
• Não são diretamente relacionados às funções 
específicas do sistema, mas sim demonstram 
qualidade acerca dos serviços. 
• São restrições sobre os serviços, ou funções, 
oferecidos pelo sistema. 
• Incluem restrições de tempo, de tipo de 
processo de desenvolvimento ou de padrões. 
• Surgem conforme a necessidade dos usuários. 
 
 
Requisitos 1 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 21 
1.2.2 - Requisitos Não Funcionais: 
Especificam: 
• desempenho (ex.: tempo de resposta); 
• proteção (ex.: armazenamento); 
• disponibilidade (ex.: dispositivos de I/O); 
• segurança (ex.: criptografias); 
• outras propriedades emergentes (ex.: confiabilidade, 
manutenibilidade, disponibilidade, usabilidade, etc.) 
 
 
 
Requisitos 1 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 22 
1.2.2 - Requisitos Não Funcionais: 
Exemplo em um sistema para biblioteca online: 
1. O sistema deve acessar um banco de dados Oracle 
e deve permitir gerenciamento via sistema, através 
de SQL. 
2. A interface do usuário deve ser implementada com 
HTML 5 e deveria conter applets de JAVA. 
3. Para cada pedido, deve haver limite de tempo de 
no máximo 3 segundos para a realização da 
operação, bem como limite de 90 dias para manter 
o pedido gravado na conta do usuário. 
 
Requisitos 1 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 23 
1.2.2 - Requisitos Não Funcionais (Taxonomia) 
 
 
 
Requisitos 1 
Figura adaptada de http://evertongomede.blogspot.com.br/2010/09/taxonomiados-requisitos-nao-funcionais.html 
 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 24 
1.2.2 - Requisitos Não Funcionais (Taxonomia) 
 
 
 
Requisitos 1 
Especificam o comportamento do produto 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 25 
1.2.2 - Requisitos Não Funcionais(Taxonomia) 
 
 
 
Requisitos 1 
Especificam o comportamento do produto 
Na tela de consulta, os 
textos devem ter fonte Arial 
tamanho 12, preta e o fundo 
da tela na cor branca. 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 26 
1.2.2 - Requisitos Não Funcionais (Taxonomia) 
 
 
 
Requisitos 1 
Especificam o comportamento do produto 
O tempo médio de resposta 
das consultas não devem 
ser superior a 3 segundos, 
em pelo menos 90% dos 
acessos. 
Os dados gravados pelo 
sistema devem ser 
armazenados em disco 
rígido local, de no mínimo 
1TB. 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 27 
1.2.2 - Requisitos Não Funcionais (Taxonomia) 
 
 
 
Requisitos 1 
Especificam o comportamento do produto 
O produto que aparecer 
com o status “disponível” 
no banco de dados deve 
também estar disponível 
fisicamente. 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 28 
1.2.2 - Requisitos Não Funcionais (Taxonomia) 
 
 
 
Requisitos 1 
Especificam o comportamento do produto 
O sistema deve estar 
disponível para acesso 
através dos navegadores 
Internet Explorer 10, 
Chrome e Firefox. 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 29 
1.2.2 - Requisitos Não Funcionais (Taxonomia) 
 
 
 
Requisitos 1 
Derivados de políticas e procedimentos do cliente e do desenvolvedor 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 30 
1.2.2 - Requisitos Não Funcionais (Taxonomia) 
 
 
 
Requisitos 1 
Derivados de políticas e procedimentos do cliente e do desenvolvedor 
O sistema deve ser 
entregue em no máximo 6 
meses a partir da 
assinatura do aceite deste 
documento. 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 31 
1.2.2 - Requisitos Não Funcionais (Taxonomia) 
 
 
 
Requisitos 1 
Derivados de políticas e procedimentos do cliente e do desenvolvedor 
O website deve ser 
desenvolvido em HTML5, 
Javascript, CSS e PHP, com 
banco de dados MySQL. 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 32 
1.2.2 - Requisitos Não Funcionais (Taxonomia) 
 
 
 
Requisitos 1 
Derivados de políticas e procedimentos do cliente e do desenvolvedor 
O processo de 
desenvolvimento do 
sistema devem estar em 
conformidade com as 
normas CMM Nível 3. 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 33 
1.2.2 - Requisitos Não Funcionais (Taxonomia) 
 
 
 
Requisitos 1 
Derivados de fatores externos e de seu processo de desenvolvimento 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 34 
1.2.2 - Requisitos Não Funcionais (Taxonomia) 
 
 
 
Requisitos 1 
Derivados de fatores externos e de seu processo de desenvolvimento 
O sistema de consulta de 
livros deve se comunicar 
com o sistema de cadastro 
de usuários. 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 35 
1.2.2 - Requisitos Não Funcionais (Taxonomia) 
 
 
 
Requisitos 1 
Derivados de fatores externos e de seu processo de desenvolvimento 
O sistema de consulta de 
livros deve ser aberto a 
todo usuário, cadastrado ou 
não. 
1.2 – Conceitos Fundamentais 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 36 
1.2.2 - Requisitos Não Funcionais (Taxonomia) 
 
 
 
Requisitos 1 
Derivados de fatores externos e de seu processo de desenvolvimento 
Os dados cadastrais dos 
consumidores somente 
devem ser acessados pelo 
sistema após digitação de 
login e senha autorizados. 
O sistema não deve exibir 
quaisquer informações 
cadastrais dos alunos aos 
funcionários da biblioteca, 
com exceção do nome, 
matrícula e status. 
1.3 - Requisitos de Domínio: 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 37 
Requisitos 1 
1.3 - Requisitos de Domínio: 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 38 
• São derivados do domínio da aplicação do 
sistema, e não das atividades específicas dos 
usuários do sistema. 
• Incluem terminologia específica de domínio, 
portanto, os desenvolvedores têm dificuldade 
em compreender suas relações com outros 
requisitos do sistema. 
• Refletem os fundamentos do domínio da 
aplicação. 
 
 
Requisitos 1 
1.3 - Requisitos de Domínio: 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 39 
Exemplos: 
• A interface do sistema deve seguir as 
especificações de usabilidade baseada na 
norma ISO/IEC 9126. 
• Devido às restrições de direitos autorais, alguns 
documentos não devem ser disponibilizados 
para download. 
• O sistema deve calcular a desaceleração do 
trem. 
 
 
Requisitos 1 
1.4 – Requisitos de Usuário 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 40 
Requisitos 1 
1.4 – Requisitos de Usuário 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 41 
Devem descrever requisitos funcionais e não 
funcionais, de forma compreensível até pelos 
usuários sem conhecimento técnico. 
• Descreve o comportamento externo do sistema. 
• Evita características do projeto do sistema. 
• Não utiliza jargão técnico ou notações formais. 
• Utiliza tabelas, formulários e diagramas simples para 
fácil compreensão. 
 
 
 
Requisitos 1 
1.4 – Requisitos de Usuário 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 42 
Podem surgir problemas de interpretação por 
escrever requisitos com linguagem natural. 
• Falta de clareza (omissões); 
• Confusão de requisitos (ambiguidades); 
• Fusão de requisitos (mais de uma função). 
Exemplo: Deve conter um sistema de contabilidade 
financeira que mantenha registros de todos os 
pagamentos realizados pelos usuários do sistema, para 
que os gerentes possam fazer com que clientes 
frequentes recebam descontos. 
 
 
Requisitos 1 
1.4 – Requisitos de Usuário 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 43 
Diretrizes para escrever requisitos de usuário: 
• Criar formato padrão para todos os requisitos. 
• Usar a linguagem de uma forma consistente. 
Escreva ‘deve’ para requisitos necessários 
(obrigatórios), e ‘deveria’ para requisitos desejáveis 
ou opcionais (não obrigatórios). 
• Destacar o texto (com negrito, itálico, etc.) para 
identificar as partes principais do requisito. 
• Evitar o uso de termos técnicos da informática. 
 
 
 
Requisitos 1 
1.5 – Requisitos de Sistema 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 44 
Requisitos 1 
1.5 – Requisitos de Sistema 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 45 
• São versões expandidas dos requisitos de 
usuários, com especificações mais detalhadas 
das funções do sistema, dos serviços e das 
restrições. 
• Usados pelos desenvolvedores como ponto de 
partida para o projeto do sistema. 
• Explicam como os requisitos de usuário devem ser 
fornecidos pelo sistema. 
• Deve ser uma especificação completa e consistente 
de todo o sistema, pois podem ser utilizados como 
parte do contrato de implementação. 
 
Requisitos 1 
1.5 – Requisitos de Sistema 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 46 
• As especificações de requisitos escritas emlinguagem natural são propensas a mal-
entendidos, pois podem possuir ambiguidades, 
omissões e fusões. 
• A solução desses problemas pode ser onerosa, 
se descobertos nas fases finais do processo. 
 
 
Requisitos 1 
1.5 – Requisitos de Sistema 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 47 
1.5.1 – Uso de Linguagem Estruturada: 
Forma padronizada de redigir requisitos, baseada em 
templates. 
• Incorpora construções derivadas de linguagens de 
programação. 
• Destaques gráficos e formulários. 
• A maior parte da expressividade da linguagem 
natural é mantida. O grau de uniformidade é imposto 
na especificação dos templates. 
 
 
 
Requisitos 1 
1.5 – Requisitos de Sistema 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 48 
1.5.1 – Uso de Linguagem Estruturada: 
Informações contidos em formulário-padrão: 
1. Descrição da função ou da entidade especificada. 
2. Descrição das entradas e suas origens. 
3. Descrição das saídas e seus destinos. 
4. Indicações de outras entidades (requer). 
5. Descrição da ação a ser tomada. 
6. Estabelecer pré e pós-condição de abordagem 
funcional, se apropriado. 
7. Descrição dos efeitos colaterais (se houver). 
 
Requisitos 1 
1.5 – Requisitos de Sistema 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 49 
1.5.1 – Uso de Linguagem Estruturada: 
Exemplo: Bomba de insulina [SOMMERVILLE, 2007] 
 
 
 
 
Requisitos 1 
1.5 – Requisitos de Sistema 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 50 
1.5.2 – Uso de Linguagem de Descrição: 
• Semelhante à linguagem de programação, com 
mais características abstratas. 
• Útil para especificar interfaces. 
• Pouco utilizada. 
 
 
 
 
Requisitos 1 
1.5 – Requisitos de Sistema 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 51 
1.5.3 – Uso de Notação Gráfica: 
• Linguagem gráfica, complementada com 
anotações de texto. 
• Descrições de Caso de Uso. 
• Diagramas de Sequência. 
 
 
 
 
Requisitos 1 
1.5 – Requisitos de Sistema 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 52 
1.5.3 – Uso de Notação Gráfica: 
 
 
 
Exemplo de Diagrama de Sequência: 
Retirada de dinheiro em 
caixa eletrônico. 
[SOMMERVILLE, 2007] 
 
 
 
 
Requisitos 1 
1.5 – Requisitos de Sistema 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 53 
1.5.3 – Uso de Notação Gráfica: 
• Um Caso de Uso é uma seqüência de 
interações entre o ator e o sistema, que 
acontece na perspectiva do ator. 
• Quando criamos um Caso de Uso nos 
preocupamos com “o que” o sistema deve 
fazer, e não com o “como” deve fazer. 
 
 
 
 
Requisitos 1 
1.5 – Requisitos de Sistema 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 54 
1.5.3 – Uso de Notação Gráfica: 
Exemplo de Caso de Uso: 
 
 
 
 
Requisitos 1 
1.5 – Requisitos de Sistema 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 55 
1.5.3 – Uso de Notação Gráfica: 
Exemplo de Caso de Uso com Descrição: 
Quadro 1. Especificação de caso de uso com descrição contínua 
Caso de Uso: Abrir Conta 
Ator: Gerente e Cliente 
Descrição: O Gerente ao receber a solicitação de abertura de conta 
pelo cliente, inicia o cadastramento do mesmo informando para o 
sistema os dados pessoais, o tipo da conta (corrente ou poupança) e 
se a conta é em conjunto. Em seguida o Gerente solicita que o cliente 
informe a senha da conta no sistema para que o processo possa 
continuar. Caso o cliente já esteja cadastrado no sistema, não é 
necessário o cadastramento do cliente. Ao final do procedimento, o 
sistema informa o número da nova conta e o Gerente repassa a 
informação ao cliente. 
 
 
Requisitos 1 
1.5 – Requisitos de Sistema 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 56 
1.5.4 – Uso de Especificações Matemáticas: 
• Baseada em conceitos matemáticos, como 
máquinas de estados finitos ou a teoria dos 
conjuntos. 
• Difícil compreensão por parte dos clientes. 
 
 
 
 
Requisitos 1 
1.6 – Características de Qualidade 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 57 
Requisitos 1 
1.6 – Características de Qualidade 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 58 
Deve elaborar a Especificação de Requisitos 
de Software (ERSw): 
• Documento oficial da descrição dos requisitos de um 
projeto de software. 
• Descreve as funcionalidades, interfaces, 
desempenho, portabilidade, manutenibilidade e 
confiabilidade. 
• Descreve padrões e outros limites a serem 
obedecidos, como linguagem de implementação, 
ambientes de operação, limites de recursos, etc. 
 
 
Requisitos 1 
1.6 – Características de Qualidade 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 59 
1.6.1 - Correção: 
ERSw é correta se todo requisito presente é um 
requisito do produto realmente a ser construído. 
• Não existe ferramenta que garanta a correção. 
• Deve-se verificar a coerência da ERSw com outros 
documentos. 
• Deve-se solicitar aprovação formal da ERSw por 
parte do cliente. 
 
 
 
Requisitos 1 
Engenharia de Software II – Prof. Celso Gallão – Slide 60 
1.6.2 - Precisão: 
ERSw é precisa se todo requisito presente possui 
apenas uma única interpretação, sem 
ambiguidades, tanto para desenvolvedores 
como para usuários. 
• Deve ser compreensível para o público alvo. 
• Deve ser suficiente para o desenho dos testes de 
aceitação. 
• Recomenda-se Glossário para evitar ambiguidades 
na interpretação. 
 
1.6 – Características de Qualidade 
 
Requisitos 1 
Engenharia de Software II – Prof. Celso Gallão – Slide 61 
1.6.3 - Completeza: 
ERSw é completa se reflete todas as decisões de 
especificação que foram tomadas, sem 
pendências, sem omissões. 
• Conter todos os requisitos relativos a funcionalidade, 
desempenho, restrições de desenho, atributos e 
interfaces externas. 
• Definir as respostas do software p/ todas as 
entradas, válidas/inválidas, em todas situações. 
• Conter Glossários (termos técnicos, medidas, 
figuras e tabelas). 
 
1.6 – Características de Qualidade 
 
Requisitos 1 
Engenharia de Software II – Prof. Celso Gallão – Slide 62 
1.6.4 - Consistência: 
ERSw é consistente se não há conflitos entre 
nenhum dos subconjuntos de requisitos 
presentes, a saber: 
• Conflito entre características de objetos do mundo 
real. Ex.: formato de relatórios, cores de sinalização. 
• Conflito lógico ou temporal entre ações. Ex: um 
requisito diz A  B, mas outro diz B  A. 
 
 
 
1.6 – Características de Qualidade 
 
Requisitos 1 
Engenharia de Software II – Prof. Celso Gallão – Slide 63 
1.6.5 - Priorização: 
ERSw é priorizada se cada requisito é 
classificado de acordo com a sua importância, 
estabilidade e complexidade. 
• A estabilidade estima a probabilidade de um 
requisito ser alterado ao longo do projeto. 
• Requisito essencial: sem este o produto é 
inaceitável. 
• Requisito desejável: aumenta o valor do produto. 
• Requisito opcional: se houver disponibilidade. 
 
1.6 – Características de Qualidade 
 
Requisitos 1 
Engenharia de Software II – Prof. Celso Gallão – Slide 64 
1.6.6 - Verificabilidade: 
ERSw é verificável se todos os seus requisitos 
são verificáveis. 
• Se existir um processo finito. 
• Com custo compensador. 
• Que possa ser executado. 
• Que mostre conformidade do produto final com os 
requisitos. 
 
 
 
1.6 – Características de QualidadeRequisitos 1 
Engenharia de Software II – Prof. Celso Gallão – Slide 65 
1.6.7 - Modificabilidade: 
ERSw é modificável se sua estrutura e estilo 
permitem a mudança de qualquer requisito, de 
forma fácil e consistente. 
• Requer organização coerente, com índices e 
referências. 
• Sem redundância entre requisitos. 
• Definição separada de cada requisito. 
 
 
 
1.6 – Características de Qualidade 
 
Requisitos 1 
Engenharia de Software II – Prof. Celso Gallão – Slide 66 
1.6.8 - Rastreabilidade: 
ERSw é rastreável se permite a fácil 
determinação dos antecedentes e consequências 
de todos os requisitos. 
• Rastreabilidade para trás: localizar a origem de 
cada requisito, o porquê de existirem e quem o 
determinou. 
• Rastreabilidade para frente: localizar os resultados 
que serão afetados por cada requisito. 
 
 
1.6 – Características de Qualidade 
 
Requisitos 1 
Referências Bibliográficas 
 I. PAULA FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, 
Metodos e Padrões. LTC, 2009, Capítulo 3. 
II. PRESSMAN, R. S. Engenharia de Software. 6.ed. McGraw-Hill, 2006. 
III. SOMMERVILLE, Ian. Engenharia de Software. 8.ed. Pearson, 2007, 
Capítulo 6. 
 
 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 67 
Outras Referências 
 I. http://www.rrochas.com.br/ 
II. http://ivansowa.blogspot.com.br/2011/04/requisitos-de-software.html 
III. http://www.devmedia.com.br/space.asp?id=176186 
IV. http://pt.wikipedia.org/wiki/Requisito_funcional 
V. http://pt.wikipedia.org/wiki/Requisito_n%C3%A3o-funcional 
 
 
 
Engenharia de Software II – Prof. Celso Gallão – Slide 68