Termo de Uso:

Qualquer indivíduo ou grupo de indivíduos poderá utilizar este Quick Guide

como base para seminários, artigos, livros, material de suporte para o CPRE-
FL Syllabus, tradução para qualquer outra língua ou outras publicações e ou
materiais derivados, desde que citem os autores do presente documento e a
T&M como fonte e detentores dos direitos autorais do mesmo. A T&M e os
autores se reservam o direito e a propriedade exclusivos das versões em
linguagem portuguesa e inglesa.

CPRE-FL Quick Guide

Certified Professional for Requirements
Engineering – Foundation Level
Versão original em português v1.0 - 23 de dezembro de 2011

para auxiliar no Exame para

Profissional de Engenharia de Requisitos Certificado – Nível Fundamental
em conformidade com o IREB – International Requirements Engineering Board

© T&M 2011 (Brasil)

Este Quick Guide foi originalmente desenvolvido e escrito pelos seguintes
colaboradores da T&M: Martin Tornquist, Paulo Henrique Nannini e IREB Recognized Training Provider
www.certified-re.de/international Jorge Luiz Diaz Pinaya. www.tmtestes.com.br 1
 A parte mais árdua na construção de um software
consiste exatamente em identificar o que construir.

Nenhuma outra fase compromete tanto o resultado

do trabalho se elaborada de forma incorreta.

Nenhuma outra parte dificulta tanto

as correções posteriores.

Frederick P. Brooks
The Mythical Man-Month: Essays on Software Engineering
2
 Porque é importante o trabalho do Engenheiro de Requisitos?

Quais as Qual a
causas típicas distribuição
para um da origem dos
projeto não defeitos?
obter sucesso? Qual a
distribuição
requisitos
do esforço de

72.8%
41% projeto
28% retrabalho?

requisitos mal definidos ou faltantes outros requisitos

31% 82%

Fonte: U.S. Air Force Project, F. Sheldon, 1992

Fonte: Jama Software, The State of Requirements Management Report, 2011 “Reliability Measurement from Theory to Practice” Fonte: Dean Leffingwell, James Martin

R$4900,00

Qual o custo
para correção
de um
problema em
requisitos?
R$2261,54

R$1130,77
O sucesso de
R$753,85 projetos
depende
R$376,92
sobremaneira
R$150,77 de bons
requisitos projeto construção testes aceite operação
requisitos 3
Fonte: Média do custo de correção de um erro em requisitos por etapa (300 projetos T&M)
 1 Introdução e

9 Apoio por
Fundamentos
01:15 2Delimitar o
Sistema e o
Ferramentas Contexto do
01:00 Sistema
01:15

8
Gerenciar
3 Elicitar
Requisitos As 9 Unidades de Requisitos
Ensino
02:30 01:30
do Syllabus
CPRE-FL e o
tempo minimo de
ensino necessário
18:00

7Validar e
Acordar
4Documentação
de Requisitos
Requisitos
02:00
02:30

6 Documentar
Requisitos
5
Documentação
de Requisitos
usando
usando Linguagem
Modelos Natural
05:00 01:00

4
 1
9 2

UE 1 Introdução e Fundamentos 8 3

7 4
6 5

Sintomas e Causas de uma Engenharia de

As 4 atividades principais da ER
Requisitos (ER) inadequada

Pressão do cliente para construção problemas de elicitação

de um sistema rapidamente comunicação
Requisitos
ambíguos,
incorretos, documentação gerenciamento
incompletos
e omissão
suposição incorreta, por parte dos stakeholders,
validação & negociação
de que muito do assunto é evidente

Requisitos devem ser comunicados

três
A linguagem natural (oral ou
escrita) é o meio mais utilizado
para comunicar requisitos.
! 3
!
Portanto, é importante buscar
uma terminologia comum e
manter uma comunicação
focada e simplificada 2+1
5
 1
9 2

UE 1 Introdução e Fundamentos 8 3

7 4
O engenheiro de requisitos tem contato direto com os stakeholders e possui a competência e responsabilidade 6 5
de familiarizar-se ao máximo com o domínio, buscando compreende-lo da melhor maneira possível.

As 7 capacidades exigidas de um Engenheiro de Requisitos

competência comunicativa moderação

raciocínio analítico auto-confiança

empatia persuasão

resolução de conflitos

Especial ênfase sobre os Características a

Tipicamente diferenciamos 3 tipos de requisitos
requisitos de qualidade serem consideradas
1 detalhamento da
requisitos funcionais geralmente documentados em funcionalidade
linguagem natural
2 confiabilidade
não funcionais

relações com outras declarações

devem ser rastreáveis usabilidade
requisitos

requisitos de qualidade
deve ser assegurada por
eficiência
assertivas quantitativas

3 As restrições não são ou operacionalizada por meio de manutenibilidade

restrições implementadas, elas são
cumpridas, porque elas
funcionalidades adicionais
simplesmente limitam o portabilidade 6
espaço de solução!
 1
9 2

UE 2 Delimitar o Sistema e o 8 3

Contexto do Sistema
7 4
6 5

UE 2.1 Sistema, Contexto e Limites

Limite do sistema

Ambiente irrelevante

Contexto do sistema Partes da

realidade que
são irrelevantes
Sistema aspectos do contexto no contexto do sistema para o sistema

pessoas (stakeholders ou grupos de stakeholders)

sistemas em operação

processos (de negócio, técnicos ou físicos)

eventos (técnicos ou físicos)

documentos (por exemplo: normas, regulamentos,

Aspectos da
documentação do sistema)
realidade que
influenciam o
contexto do sistema

Limite do contexto do sistema 7

 1
9 2

UE 2 Delimitar o Sistema e o 8 3

Contexto do Sistema
7 4
6 5

UE 2.2 Determinar os Limites do Sistema e do Contexto

Limite do
Ambiente
Sistema
Contexto do Sistema Irrelevante

Sistema
Redução do limite
zona cinzenta (t1) do contexto do
sistema (t3)

Deslocamento zona cinzenta (t2)

do limite do Extensão do limite
sistema do contexto do
sistema (t4)

A zona cinzenta
entre o sistema e o
Zona cinzenta entre o
contexto do sistema
deve ser resolvida contexto do sistema e
o ambiente irrelevante

Limite do contexto do sistema 8

 1
9 2

UE 3 Elicitar Requisitos 8 3

7 4
6 5

UE 3.1 Fontes de Requisitos

Contexto do Sistema informação para documentar os stakeholders

nome função (papel) dados pessoais

sistema
Coletar e relevância área e nível de expertise disponibilidade

compilar as objetivos e interesses em relação ao projeto

metas e
para evitar mal-entendidos e disputas sobre competências
Os 3 tipos de fontes de requisitos das
requisitos
diversas fontes atribuições direitos
Acordo responsabilidades
Stakeholders Documentos Sistemas em autoridades deveres
operação

Categorização de Requisitos
UE 3.2 conforme Modelo de Kano
UE 3.3 Técnicas de Elicitação

influências nível de

Requisitos Requisitos fatores influências influências técnicas detalhamento

de risco humanas organizacionais (função- esperado dos
Subconscientes Conscientes conteúdo) requisitos
fatores esperados
fatores básicos
de satisfação
de satisfação • técnicas de pesquisa
Requisitos
• técnicas de criatividade
Inconscientes
fatores de entusiasmo
• técnicas baseadas em documentos
• técnicas de observação
Fatores básicos de satisfação devem ser atendidos pelo sistema de
qualquer maneira. Caso contrário, os stakeholders ficarão decepcionados . • técnicas de apoio
Fatores esperados de satisfação são propriedades conscientemente
conhecidas e explicitamente exigidas pelos stakeholders. O uso de técnicas de elicitação apropriadas é uma competência decisiva
Fatores inesperados de satisfação são propriedades cujo valor somente é para o sucesso do projeto. Os melhores resultados são alcançados com
reconhecido quando o stakeholder pode utilizar o sistema na pratica.
uma combinação de várias técnicas diferentes de elicitação 9
 1
9 2

UE 4 Documentação de Requisitos 8 3

7 4
6 5

UE 4.1 Design do Documento

representação requisitos

documentação

Muitas pessoas
são envolvidas
1 2
técnicas de

desde um texto até diagramas

descritivo ...na comunicação ...no estabelecimento de metas
razões

1 2 3 devem ser acessíveis a 4documentos de requisitos são

duradouros juridicamente relevantes
todos complexos

UE 4.2 Tipos de Documentação

perspectivas
Perspectiva Estrutural Perspectiva Funcional Perspectiva Comportamental

formas eficazes de documentação

linguagem natural + modelos
linguagem natural modelos conceituais
conceituais (forma combinada) 10
 1
9 2

UE 4 Documentação de Requisitos 8 3

7 4
6 5

Estrutura dos Uso dos Critérios de Qualidade para

UE 4.3 Documentos UE 4.4 Documentos
UE 4.5 Documento de Requisitos
1
consistente e sem
requisitos para o sistema
Documento de requisitos

Os documentos de requisitos ambiguidade

parte central

servem de base para 2

contexto do sistema diferentes atividades ao estrutura clara
longo do ciclo de vida Plan- 3
condições de aceite modificável e
Do-Check-Act de
características técnicas de desenvolvimento extensível
4
implementação

estrutura de referência muito utilizada

P D C A 5
completo

IEEE 830-1998 Recommended Practice for

Software Requirements Specifications
rastreável

UE 4.6 Critérios de Qualidade para Requisitos

1 usar 2
formular um
critérios

• acordado • válido e atualizado • verificável • completo sentenças

regras

estilo
• priorizado • correto • realizável • compreensível único
curtas e

de
• não ambíguo • consistente • rastreável requisito por
parágrafos
frase
curtos

UE 4.7 Glossário
Termos técnicos específicos para um determinado contexto • gerenciado de forma centralizado • uso obrigatório
Regras

• responsabilidades definidas • conter as fontes dos termos

abreviações e acrônimos sinônimos • mantido ao longo do curso do projeto • aprovado pelos stakeholders
• habitualmente acessíveis • as entradas têm uma estrutura
conceitos do dia-a-dia homônimos consistente 11
 1
9 2

UE 5 Documentação de Requisitos 8 3

usando Linguagem Natural

7 4
6 5

UE 5.1 Efeitos da Linguagem

?
1 nominalização [...reiniciar o sistema...]
transformacionais

2 substantivos sem ponto de referência [ ...os dados devem ser exibidos...]

processos

3 quantificadores universais [...mostrar todos os dados em cada sub-menu...]

4 condições formuladas de forma incompleta […a um hóspede registrado com idade acima de 20 anos...]

5 formulações verbais de forma incompleta […os dados de login são fornecidos…]

UE 5.2 Construção de Requisitos usando Template de Sentenças

DEVERÁ
<processo>
“Shall”
template de
sentenças

[<Quando? O SISTEMA FORNECER PARA <detalhes

PODERÁ
Sob que <nome do <quem?> A CAPACIDADE <objeto> adicionais sobre
condições?>] “Should” DE <processo> o objeto>
sistema>

SERÁ SER CAPAZ DE

“Will” <processo>
passos

Caracterizar a
Determinar a Determinar o núcleo Determinar as condições
1 obrigação legal
2 do requisito
3 atividade do 4 Inserir objetos 5 lógicas e temporal
sistema
12
 1
9 2

UE 6 Documentar Requisitos 8 3

usando Modelos
7 4
6 5

UE 6.1 Conceito de Modelo

1 representação os modelos retratam certos aspectos

também são suas vantagens

propriedades essenciais que
Os modelos apresentam 3
modelo é a de uma realidade observada
representação
modelos

prevalentes
abstrata de uma 2
redução os modelos reduzem a realidade
realidade
representada
existente, ou
uma realidade a
ser criada
3 os modelos são construídos para um
pragmatismo
uso específico
modelos conceituais

... na construção de
modelos conceituais Sintaxe
são utilizadas
(os elementos de modelagem e suas Os modelos de
combinações válidas)
linguagens de requisitos descrevem
Linguagens de modelagem aspectos específicos
Modelagem especificas. Uma
linguagem de Semântica do problema em
modelagem é (o significado dos elementos de questão
definida por modelagem)
vantagens

Ao definir uma linguagem de

informação representada por uma
imagem é mais rapidamente
compreendida e memorizada
modelos de requisitos permitem a
modelagem para uma finalidade
modelagem de uma perspectiva
específica podemos estabelecer
específica dos requisitos
abstrações relevantes da realidade
13
 1
9 2

UE 6 Documentar Requisitos 8 3

usando Modelos
7 4
6 5

UE 6.2 Modelo de Metas UE 6.3 Casos de Uso

Os casos de uso ajudam a examinar e documentar um sistema
documentadas através de

planejado ou existente a partir da perspectiva do usuário

linguagem natural ou
Metas podem ser

usando modelos

Diagramas de Caso de Uso Especificações de Caso de Uso

modelagem de decomposição de Metas

um template predefinido é
usando Árvores E/OU
geralmente preenchido para
cada caso de uso relevante

Os requisitos para o sistema a ser desenvolvido são modelados

UE 6.4 3 Perspectivas sobre Requisitos por três perspectivas sobrepostas

Perspectiva
UE 6.5 Perspectiva Estrutural UE 6.6 Perspectiva Funcional UE 6.7 Comportamental
documenta a estrutura de dados, bem como documenta a transformação de dados de entrada documenta os diversos estados em que um sistema
relacionamentos de uso e de dependência no recebidos do ambiente do sistema, em dados de pode se encontrar, bem como nos eventos
contexto do sistema saída liberados para o ambiente responsáveis por uma transição entre os estados

diagrama de entidade - diagrama de fluxo de dados statechart

relacionamento

diagrama de
máquina de estado
diagrama de classe diagrama de atividade
14
 1
9 2

UE 7 Validar e Acordar Requisitos 8 3

7 4
6 5

UE 7.1 Fundamentos da Validação

1 2requisitos são base para 3 erros devem ser
requisitos devem
as atividades seguintes corrigidos em todos os
satisfazer os critérios de
do ciclo de artefatos baseados em
qualidade
desenvolvimento requisitos

UE 7.2 Fundamentos da Negociação de Requisitos

requisitos o sistema não é
O objetivo do acordo de requisitos é chegar Conflitos não
apresentados por aceito ou será
a uma compreensão única e comum entre solucionados
determinado grupo de parcialmente aceito
os stakeholders relevantes, dos requisitos nos requisitos
stakeholders não sejam ou parcialmente
do sistema a ser desenvolvido do sistema
implementados utilizado.

UE 7.3 Aspectos de Qualidade dos Requisitos

1 completude do documento de requisitos
2 1 conformidade com o formato
validação do conteúdo

validação do acordo
completude de cada requisito da documentação
3 2 conformidade com a estrutura 1
documentação

rastreabilidade acordado
validação da

da documentação
4 exatidão e adequação 3 2
5 inteligibilidade acordado após alteração
consistência
6 nenhuma decisão de design prematura 4 3
não ambigüidade conflitos resolvidos
7 verificabilidade 5 conformidade com as regras
8 necessidade
da documentação
15
 1
9 2

UE 7 Validar e Acordar Requisitos 8 3

7 4
6 5

Princípios da Validação Técnicas de Validação

UE 7.4 UE 7.5
de Requisitos de Requisitos
envolvimento dos separação da busca de falhas ...de pontos 1 parecer do
stakeholders corretos da correção de defeitos de vista diversos
especialista leitura em perspectiva

adicionais
técnicas
melhora a 2
qualidade dos inspeção validação por protótipos
resultados da
validação 3
...a partir da mudança ...a partir da construção ...em momentos e walkthrough utilização de checklists
do tipo de de artefatos baseados pontos distintos ao
documentação nos requisitos longo do processo

UE 7.6 Acordo de Requisitos

atividades tipos de conflito técnicas de resolução resolução do conflito

1identificação de Conflitos podem
surgir durante • acordo
conflitos todas as
atividades de ER
• compromisso • motivo
2 • conflito de conteúdo • votação • stakeholders
análise de conflitos • conflito de interesses • análise de envolvidos
• conflito de valores alternativas • opiniões de cada um
3 • conflito de • “manda quem pode” • meios utilizados de
resolução de conflitos relacionamentos • “obter mais solução
• conflito de poder informações” • alternativas possíveis
4documentação da resolução em estruturas • pontos fortes e • razões apresentadas
organizacionais pontos fracos para decisão
de conflitos • matriz de decisão

16
 1
9 2

UE 8 Gerenciar Requisitos 8 3

7 4
6 5

UE 8.1 Designando Atributos UE 8.2 Visualizações de Requisitos

do projeto

contexto da gerência do projeto

condições

• a partir de critérios definidos

• diretrizes da empresa
• regras do domínio da aplicação
• restrições do processo de desenvolvimento

1 2
identificador nome Visualização Visualização
<req10> <Evitar o congestionamento de tráfego> seletiva consolidada
descrição
esquema de

exibe um sub- exibe

atributos

<O sistema deve calcular uma rota alternativa se o

congestionamento exceder o limite configurado> conjunto de informações
estabilidade criticalidade fonte prioridade
valores/atributos consolidadas
<Sr. R. <importância relacionados aos relacionadas aos
<estável> <alta> especialista para o mercado: requisitos requisitos
no domínio> alta>
selecionados selecionados
estrutura nome do atributo valor do atributo <exemplo>

UE 8.3 Priorização de Requisitos

1
Definir as metas e as
restrições da priorização
processo

técnicas

4 2 ranking e top 10 classificação de Kano

Selecionar os artefatos a Definir os critérios de
serem priorizados priorização classificação por matriz de priorização
3 critério único de Wiegers
Determinar os
stakeholders relevantes 17
 1
9 2

UE 8 Gerenciar Requisitos 8 3

7 4
6 5

UE 8.4 Rastreabilidade de Requisitos UE 8.5 Versionamento de Requisitos

rastreabilidade com artefatos
de rastreabilidade

especificados ANTES da Vantagens

relacionamentos

dimensão
componentes

Configuração de requisitos
especificação-de-requisitos produto

número da
• simplificação da
classes de

versão
rastreabilidade com artefatos verificabilidade versão
especificados APÓS a • identificação das versão
especificação-de-requisitos propriedades
desnecessárias do sistema incremento
rastreabilidade entre • identificação dos requisitos conexão lógica
requisitos desnecessários

características
• respaldo para análise de consistência
impacto
representação

referências textual e hyperlink

maneiras de

• respaldo para reusabilidade são configurações ID único

baseline
• respaldo para específicas de
matriz de rastreabilidade determinação de requisitos que muitas inalterabilidade
responsabilidades vezes definem releases
• respaldo para manutenção do sistema base para
grafo de rastreabilidade
e administração roll-back

UE 8.6 Gerenciamento de Mudanças de Requisitos

identificador analisar o impacto e

Comitê de Controle de Mudanças
tipos de solicitação

avaliar a mudança

gerenciamento de
título •Classificar as solicitações de mudança recebidas
informações

priorizar a solicitação de
corretivas •Determinar o esforço exigido para executar as mudanças

processo de

mudanças
descrição mudança
•Avaliar a solicitação de mudança em termos de custo-
benefício alocar a mudança para um
adaptativas justificativa
•Definir novos requisitos com base na solicitação de projeto de modificação
data da mudança
excepcionais solicitação •Aceitar ou recusar a solicitação de mudança comunicar a decisão
solicitante •Priorizar as solicitações de mudança aceitas
•Relacionar as mudanças aceitas a projetos de aprovar rejeitar
prioridade modificação
18
 1
9 2

UE 9 Apoio por Ferramentas 8 3

7 4
6 5

Tipos de Introduzindo Avaliação de

UE 9.1
Ferramentas
Muitas ferramentas de desenvolvimento de
sistemas também atuam como apoio para a ER,
como por exemplo: ferramentas de
gerenciamento de testes ou de configuração,
ferramentas Wiki, pacotes de aplicativos de
escritório ou ferramentas de visualização.
As ferramentas de modelagem são igualmente
importantes para a ER, na função de elaborar e
analisar as informações sob forma de modelos.
UE 9.2
Ferramentas
1
Uma ferramenta apropriada somente
poderá ser escolhida após a
introdução de procedimentos e
técnicas de ER
2 7 perspectivas:
requer responsabilidades e
procedimentos claros de ER
UE 9.3
Ferramentas
A variedade de aspectos que
devem ser considerados ao avaliar
ferramentas de ER podem ser
estruturados a partir de
1. Projeto
[Apoio para o planejamento]

5 aspectos a observar:
As 8 funcionalidades das ferramentas de 2. Usuário
[especialmente a usabilidade]
gerenciamento exclusivas da ER: 1. Planejar recursos
1. Gerenciar diversos tipos de
informações 2. Reduzir riscos por meio 3. Produto
2. Estabelecer e manter
da implementação de [as funcionalidades]
relacionamentos lógicos entre as um projeto piloto
informações 4. Processo
3. Realizar a avaliação [apoio metodológico]
3. Identificar os artefatos
conforme critérios pré-
4. Permitir um acesso flexível e seguro
definidos 5. Fornecedor
às informações através do controle [serviços oferecidos]
de acesso
4. Considerar o custo
5. Possibilitar diferentes visualizações global, além do custo 6. Técnica
das informações [a interoperabilidade, a
das licenças escalabilidade,...]
6. Organizar as informações
7. Gerar relatórios 5. Treinar usuários 7. Econômica
8. Gerar documentos [custos]
19
Versão original em português v1.0 IREB Recognized Training Provider IREB Licensed Certification Body
23 de dezembro de 2011 www.tmtestes.com.br www.ibqts.com.br

O Instituto Brasileiro de Qualidade e Testes de Software (IBQTS) foi licenciado

pelo IREB para realizar o exame CPRE no Brasil. Inscrições, bem como os
detalhes de organização para o seu exame CPRE FL pode ser tratado pela T & M,
para todos os treinamentos abertos e in-house.

Copyright © 2011 T&M Testes de Software (BRASIL). Todos os direitos reservados.

Este Quick Guide foi originalmente desenvolvido e escrito pelos seguintes colaboradores da T&M:
Martin Tornquist, Paulo Henrique Nannini e Jorge Luiz Diaz Pinaya.
Todas as marcas aqui citadas são marcas registradas, e pertencem aos seus respectivos detentores. 20