IREB CPRE-FL QUICK GUIDEibqts.com.br/downloads/CPRE-FL_Quick_Guide_PT_Brasil_v11.pdf · 2012-06-15 · CPRE-FL Quick Guide Certified Professional for Requirements Engineering –

CPRE-FL Quick Guide Certified Professional for Requirements

Engineering – Foundation Level

para auxiliar no Exame para Profissional de Engenharia de Requisitos Certificado – Nível Fundamental

em conformidade com o IREB – International Requirements Engineering Board

www.certified-re.de/international IREB Recognized Training Provider

www.tmtestes.com.br

Versão original em português v1.0 - 23 de dezembro de 2011

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.

© T&M 2011 (Brasil) Este Quick Guide foi originalmente desenvolvido e escrito pelos seguintes

colaboradores da T&M: Martin Tornquist, Paulo Henrique Nannini e Jorge Luiz Diaz Pinaya.

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

Fonte: Jama Software, The State of Requirements Management Report, 2011

Quais as

causas típicas

para um

projeto não

obter sucesso?

Porque é importante o trabalho do Engenheiro de Requisitos?

Qual a

distribuição

da origem dos

defeitos?

Qual a

distribuição

do esforço de

retrabalho?

requisitos 82%

requisitos 41% projeto

28%

outros 31%

Fonte: Dean Leffingwell, James Martin

Fonte: U.S. Air Force Project, F. Sheldon, 1992 “Reliability Measurement from Theory to Practice”

requisitos projeto construção testes aceite operação

R$150,77

R$376,92

R$753,85

R$1130,77

R$2261,54

R$4900,00

Qual o custo

para correção

de um

problema em

requisitos?

Fonte: Média do custo de correção de um erro em requisitos por etapa (300 projetos T&M)

72.8% requisitos mal definidos ou faltantes

O sucesso de

projetos

depende

sobremaneira

de bons

requisitos 3

As 9 Unidades de Ensino

do Syllabus CPRE-FL e o

tempo minimo de ensino necessário

18:00

Introdução e Fundamentos

01:15 Delimitar o Sistema e o Contexto do

Sistema

01:15

Elicitar Requisitos

01:30

Documentação de Requisitos

02:00

Documentação de Requisitos

usando Linguagem

Natural

01:00

Documentar Requisitos

usando Modelos

05:00

Validar e Acordar

Requisitos

02:30

Gerenciar Requisitos

02:30

Apoio por Ferramentas

01:00

2

3

4

5 6

7

8

9

1

4

UE 1 Introdução e Fundamentos

1 2

3

4

5 6

7

8

9

Sintomas e Causas de uma Engenharia de Requisitos (ER) inadequada

Requisitos

ambíguos,

incorretos,

incompletos

e omissão

Pressão do cliente para construção

de um sistema rapidamente

problemas de comunicação

suposição incorreta, por parte dos stakeholders,

de que muito do assunto é evidente

As 4 atividades principais da ER

elicitação

gerenciamento documentação

validação & negociação

Requisitos devem ser comunicados

! ! três

3

2 + 1

A linguagem natural (oral ou

escrita) é o meio mais utilizado

para comunicar requisitos.

Portanto, é importante buscar

uma terminologia comum e

manter uma comunicação

focada e simplificada

5

UE 1 Introdução e Fundamentos

1 2

3

4

5 6

7

8

9

requis

itos

não funcio

nais

Tipicamente diferenciamos 3 tipos de requisitos

requisitos funcionais

requisitos de qualidade

restrições

1

2

3

Especial ênfase sobre os requisitos de qualidade

relações com outras declarações devem ser rastreáveis

deve ser assegurada por assertivas quantitativas

As restrições não são

implementadas, elas são

cumpridas, porque elas

simplesmente limitam o

espaço de solução!

Características a serem consideradas

confiabilidade

usabilidade

eficiência

manutenibilidade

portabilidade

detalhamento da funcionalidade

As 7 capacidades exigidas de um Engenheiro de Requisitos

competência comunicativa

raciocínio analítico

empatia

resolução de conflitos

moderação

auto-confiança

persuasão

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

geralmente documentados em linguagem natural

ou operacionalizada por meio de funcionalidades adicionais

6

Ambiente irrelevante

Contexto do sistema

Limite do sistema

Sistema

Limite do contexto do sistema

Partes da

realidade que

são irrelevantes

para o sistema aspectos do contexto no contexto do sistema

pessoas (stakeholders ou grupos de stakeholders)

sistemas em operação

eventos (técnicos ou físicos)

documentos (por exemplo: normas, regulamentos, documentação do sistema)

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

UE 2 Delimitar o Sistema e o Contexto do Sistema

1 2

3

4

5 6

7

8

9

Aspectos da

realidade que

influenciam o

contexto do sistema

UE 2.1 Sistema, Contexto e Limites

7

UE 2 Delimitar o Sistema e o Contexto do Sistema

1 2

3

4

5 6

7

8

9

UE 2.2 Determinar os Limites do Sistema e do Contexto

Contexto do Sistema

Limite do Sistema

Limite do contexto do sistema

zona cinzenta (t1)

zona cinzenta (t2)

Sistema

Deslocamento do limite do

sistema Extensão do limite

do contexto do sistema (t4)

Redução do limite do contexto do sistema (t3)

Zona cinzenta entre o contexto do sistema e o ambiente irrelevante

Ambiente Irrelevante

A zona cinzenta

entre o sistema e o

contexto do sistema

deve ser resolvida

8

UE 3 Elicitar Requisitos

1 2

3

4

5 6

7

8

9

UE 3.2 Categorização de Requisitos conforme Modelo de Kano

Requisitos Subconscientes fatores básicos de satisfação

Requisitos Inconscientes

fatores de entusiasmo

Requisitos Conscientes

fatores esperados de satisfação

UE 3.1 Fontes de Requisitos

Contexto do Sistema

sistema

Os 3 tipos de fontes de requisitos

Coletar e compilar as

metas e requisitos das diversas fontes

Stakeholders Documentos Sistemas em operação

para evitar mal-entendidos e disputas sobre competências

Acordo

informação para documentar os stakeholders

nome

relevância

função (papel)

área e nível de expertise

dados pessoais

disponibilidade

objetivos e interesses em relação ao projeto

atribuições direitos

deveres

responsabilidades

autoridades

O uso de técnicas de elicitação apropriadas é uma competência decisiva para o sucesso do projeto. Os melhores resultados são alcançados com uma combinação de várias técnicas diferentes de elicitação

UE 3.3 Técnicas de Elicitação

• técnicas de pesquisa • técnicas de criatividade • técnicas baseadas em documentos • técnicas de observação • técnicas de apoio

fatores de risco

influências humanas

influências organizacionais

influências técnicas (função-

conteúdo)

nível de detalhamento esperado dos

requisitos

Fatores básicos de satisfação devem ser atendidos pelo sistema de qualquer maneira. Caso contrário, os stakeholders ficarão decepcionados .

Fatores esperados de satisfação são propriedades conscientemente conhecidas e explicitamente exigidas pelos stakeholders.

Fatores inesperados de satisfação são propriedades cujo valor somente é reconhecido quando o stakeholder pode utilizar o sistema na pratica. 9

UE 4 Documentação de Requisitos

1 2

3

4

5 6

7

8

9

UE 4.1 Design do Documento

repre

senta

ção r

equis

itos

razões

Muitas p

essoas

são e

nvolv

idas

duradouros juridicamente relevantes devem ser acessíveis a

todos

1 2 3

técnic

as d

e

docum

enta

ção

desde um texto descritivo

até diagramas

documentos de requisitos são

complexos

4

1 2

...na comunicação ...no estabelecimento de metas

UE 4.2 Tipos de Documentação

perspectivas

Perspectiva Estrutural Perspectiva Funcional Perspectiva Comportamental

formas eficazes de documentação

linguagem natural modelos conceituais linguagem natural + modelos

conceituais (forma combinada) 10

Os documentos de requisitos servem de base para

diferentes atividades ao longo do ciclo de vida Plan-

Do-Check-Act de desenvolvimento

UE 4 Documentação de Requisitos

1 2

3

4

5 6

7

8

9

UE 4.3 Estrutura dos Documentos UE 4.5

Critérios de Qualidade para Documento de Requisitos UE 4.4

Uso dos Documentos

Docum

ento

de r

equis

itos

part

e c

entr

al requisitos para o sistema

contexto do sistema

condições de aceite

consistente e sem ambiguidade

estrutura clara

modificável e extensível

1

2

3

completo

rastreável

4

5 estrutura de referência muito utilizada

IEEE 830-1998 Recommended Practice for Software Requirements Specifications

UE 4.6 Critérios de Qualidade para Requisitos

regra

s

de

estilo

usar sentenças curtas e

parágrafos curtos

formular um único

requisito por frase c

rité

rios

• acordado • priorizado • não ambíguo

• verificável • realizável • rastreável

• completo • compreensível

• válido e atualizado • correto • consistente

1 2

UE 4.7 Glossário

Termos técnicos específicos para um determinado contexto

abreviações e acrônimos

conceitos do dia-a-dia

sinônimos

homônimos Regra

s

• gerenciado de forma centralizado

• responsabilidades definidas • mantido ao longo do curso do projeto • habitualmente acessíveis

• uso obrigatório

• conter as fontes dos termos • aprovado pelos stakeholders • as entradas têm uma estrutura consistente

características técnicas de implementação

11

P D C A

UE 5 Documentação de Requisitos usando Linguagem Natural

1 2

3

4

5 6

7

8

9

UE 5.1 Efeitos da Linguagem ?

pro

cessos

transfo

rmacio

nais

2

3

4

5

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

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

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

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

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

tem

pla

te d

e

sente

nças

[<Quando? Sob que

condições?>]

O SISTEMA <nome do sistema>

DEVERÁ “Shall”

PODERÁ “Should”

SERÁ “Will”

<processo>

FORNECER PARA <quem?> A CAPACIDADE

DE <processo>

SER CAPAZ DE <processo>

<objeto> <detalhes

adicionais sobre o objeto>

passos

Determinar a obrigação legal

Inserir objetos Determinar o núcleo

do requisito

Caracterizar a atividade do

sistema

Determinar as condições lógicas e temporal

1 5 4 3 2

12

UE 6 Documentar Requisitos usando Modelos

1 2

3

4

5 6

7

8

9

UE 6.1 Conceito de Modelo

modelo

s

Os m

odelo

s a

pre

senta

m 3

pro

priedades e

ssencia

is q

ue

tam

bém

são s

uas v

anta

gens

pre

vale

nte

s

representação

os modelos são construídos para um uso específico

os modelos retratam certos aspectos de uma realidade observada

redução

pragmatismo

os modelos reduzem a realidade representada

1

2

3

modelo é a

representação

abstrata de uma

realidade

existente, ou

uma realidade a

ser criada

modelo

s c

onceituais

Linguagens de Modelagem

Sintaxe (os elementos de modelagem e suas

combinações válidas)

Semântica (o significado dos elementos de

modelagem)

... na construção de modelos conceituais

são utilizadas linguagens de

modelagem especificas. Uma

linguagem de modelagem é

definida por

Os modelos de requisitos descrevem aspectos específicos

do problema em questão

vanta

gens

modelos de requisitos permitem a modelagem de uma perspectiva específica dos requisitos

informação representada por uma imagem é mais rapidamente compreendida e memorizada

Ao definir uma linguagem de modelagem para uma finalidade específica podemos estabelecer abstrações relevantes da realidade 13

UE 6 Documentar Requisitos usando Modelos

1 2

3

4

5 6

7

8

9

UE 6.2 Modelo de Metas UE 6.3 Casos de Uso

Os casos de uso ajudam a examinar e documentar um sistema

planejado ou existente a partir da perspectiva do usuário

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

UE 6.4 3 Perspectivas sobre Requisitos

UE 6.5

documenta a estrutura de dados, bem como

relacionamentos de uso e de dependência no

contexto do sistema

UE 6.6 UE 6.7

documenta a transformação de dados de entrada recebidos do ambiente do sistema, em dados de

saída liberados para o ambiente

documenta os diversos estados em que um sistema pode se encontrar, bem como nos eventos

responsáveis por uma transição entre os estados

diagrama de fluxo de dados

diagrama de atividade

diagrama de entidade -relacionamento

diagrama de classe

diagrama de máquina de estado

Perspectiva Estrutural Perspectiva Funcional Perspectiva

Comportamental

um template predefinido é geralmente preenchido para cada caso de uso relevante

Os requisitos para o sistema a ser desenvolvido são modelados por três perspectivas sobrepostas

statechart

14

Meta

s p

odem

ser

docum

enta

das a

través d

e

linguagem

natu

ral ou

usando m

odelo

s

modelagem de decomposição de Metas usando Árvores E/OU

UE 7 Validar e Acordar Requisitos

1 2

3

4

5 6

7

8

9

UE 7.1 Fundamentos da Validação

requisitos devem satisfazer os critérios de

qualidade

requisitos são base para as atividades seguintes

do ciclo de desenvolvimento

erros devem ser corrigidos em todos os artefatos baseados em

requisitos

1 2 3

UE 7.2 Fundamentos da Negociação de Requisitos

o sistema não é

aceito ou será

parcialmente aceito

ou parcialmente

utilizado.

requisitos

apresentados por

determinado grupo de

stakeholders não sejam

implementados

Conflitos não solucionados nos requisitos

do sistema

UE 7.3 Aspectos de Qualidade dos Requisitos

validação d

o c

onte

údo

validação d

a

docum

enta

ção

validação d

o a

cord

o conformidade com o formato

da documentação

conformidade com a estrutura da documentação

inteligibilidade

1

2

3

não ambigüidade

conformidade com as regras da documentação

4

5

acordado

acordado após alteração

conflitos resolvidos

1

2

3

completude do documento de requisitos

completude de cada requisito

rastreabilidade

1

2 3

exatidão e adequação

consistência

4 5

nenhuma decisão de design prematura

verificabilidade

necessidade

7

8

6

O objetivo do acordo de requisitos é chegar a uma compreensão única e comum entre os stakeholders relevantes, dos requisitos

do sistema a ser desenvolvido

15

UE 7 Validar e Acordar Requisitos

1 2

3

4

5 6

7

8

9

UE 7.5 Técnicas de Validação

de Requisitos UE 7.4

Princípios da Validação de Requisitos

parecer do especialista

inspeção

walkthrough

1

2

3 técnic

as

adic

ionais

leitura em perspectiva

validação por protótipos

utilização de checklists

melhora a qualidade dos resultados da

validação

envolvimento dos stakeholders corretos

separação da busca de falhas da correção de defeitos

...de pontos de vista diversos

...a partir da mudança do tipo de

documentação

...a partir da construção de artefatos baseados

nos requisitos

...em momentos e pontos distintos ao longo do processo

UE 7.6 Acordo de Requisitos

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

análise de conflitos 2

identificação de conflitos

1

resolução de conflitos

documentação da resolução de conflitos

4

3

• conflito de conteúdo • conflito de interesses • conflito de valores • conflito de relacionamentos • conflito de poder em estruturas organizacionais

• acordo • compromisso • votação • análise de alternativas

• “manda quem pode” • “obter mais informações”

• pontos fortes e pontos fracos

• matriz de decisão

• motivo • stakeholders envolvidos

• opiniões de cada um • meios utilizados de solução

• alternativas possíveis • razões apresentadas para decisão

Conflitos podem

surgir durante

todas as

atividades de ER

16

esquem

a d

e

atr

ibuto

s

estrutura

UE 8 Gerenciar Requisitos

1 2

3

4

5 6

7

8

9

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

condiç

ões

do p

roje

to

• contexto da gerência do projeto • diretrizes da empresa • regras do domínio da aplicação • restrições do processo de desenvolvimento

exibe um sub-conjunto de

valores/atributos relacionados aos

requisitos selecionados

Visualização seletiva

1

exibe

informações consolidadas

relacionadas aos requisitos

selecionados

Visualização consolidada

2

a partir de critérios definidos

UE 8.3 Priorização de Requisitos

pro

cesso

técnic

as

ranking e top 10

classificação por critério único

classificação de Kano

matriz de priorização de Wiegers

identificador nome

descrição

estabilidade criticalidade fonte prioridade

<req10> <Evitar o congestionamento de tráfego>

<O sistema deve calcular uma rota alternativa se o congestionamento exceder o limite configurado>

<estável> <Sr. R.

especialista no domínio>

<importância para o mercado:

alta> <alta>

nome do atributo valor do atributo <exemplo>

Definir os critérios de priorização

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

Selecionar os artefatos a serem priorizados

Determinar os stakeholders relevantes

1

2

3

4

17

UE 8 Gerenciar Requisitos

1 2

3

4

5 6

7

8

9

UE 8.5 Versionamento de Requisitos UE 8.4 Rastreabilidade de Requisitos

UE 8.6 Gerenciamento de Mudanças de Requisitos

tipos d

e s

olicitação

corretivas

adaptativas

excepcionais info

rmações

Comitê de Controle de Mudanças

•Classificar as solicitações de mudança recebidas •Determinar o esforço exigido para executar as mudanças •Avaliar a solicitação de mudança em termos de custo-benefício •Definir novos requisitos com base na solicitação de mudança •Aceitar ou recusar a solicitação de mudança •Priorizar as solicitações de mudança aceitas •Relacionar as mudanças aceitas a projetos de modificação

identificador

título

descrição

justificativa

pro

cesso d

e

gere

ncia

mento

de

mudanças

analisar o impacto e avaliar a mudança

priorizar a solicitação de mudança

alocar a mudança para um projeto de modificação

comunicar a decisão

data da solicitação

solicitante

prioridade aprovar rejeitar

Configura

ção d

e r

equis

itos

dim

ensão

produto

versão

núm

ero

da

vers

ão

com

ponente

s

versão

incremento

cara

cte

rísticas

conexão lógica

consistência

ID único

inalterabilidade

base para roll-back

baseline são configurações

específicas de requisitos que muitas

vezes definem releases do sistema

cla

sses d

e

rela

cio

nam

ento

s

de r

astr

eabilid

ade rastreabilidade com artefatos

especificados ANTES da especificação-de-requisitos

rastreabilidade com artefatos especificados APÓS a especificação-de-requisitos

rastreabilidade entre requisitos

maneir

as d

e

repre

senta

ção

Vantagens

• simplificação da verificabilidade

• identificação das propriedades desnecessárias do sistema

• identificação dos requisitos desnecessários

• respaldo para análise de impacto

• respaldo para reusabilidade • respaldo para

determinação de responsabilidades

• respaldo para manutenção e administração

referências textual e hyperlink

matriz de rastreabilidade

grafo de rastreabilidade

18

UE 9 Apoio por Ferramentas

1 2

3

4

5 6

7

8

9

A variedade de aspectos que devem ser considerados ao avaliar

ferramentas de ER podem ser estruturados a partir de

7 perspectivas:

1. Projeto [Apoio para o planejamento]

2. Usuário [especialmente a usabilidade]

3. Produto [as funcionalidades]

4. Processo [apoio metodológico]

5. Fornecedor [serviços oferecidos]

6. Técnica [a interoperabilidade, a

escalabilidade,...]

7. Econômica [custos]

UE 9.1 Tipos de

Ferramentas

As 8 funcionalidades das ferramentas de gerenciamento exclusivas da ER:

1. Gerenciar diversos tipos de informações

2. Estabelecer e manter relacionamentos lógicos entre as informações

3. Identificar os artefatos

4. Permitir um acesso flexível e seguro às informações através do controle de acesso

5. Possibilitar diferentes visualizações das informações

6. Organizar as informações

7. Gerar relatórios

8. Gerar documentos

5 aspectos a observar:

1. Planejar recursos

2. Reduzir riscos por meio da implementação de um projeto piloto

3. Realizar a avaliação conforme critérios pré-definidos

4. Considerar o custo global, além do custo das licenças

5. Treinar usuários

UE 9.2 Introduzindo Ferramentas

UE 9.3 Avaliação de 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.

Uma ferramenta apropriada somente poderá ser escolhida após a

introdução de procedimentos e técnicas de ER

1

requer responsabilidades e procedimentos claros de ER

2

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.

19

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.

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.

IREB Licensed Certification Body www.ibqts.com.br

IREB Recognized Training Provider www.tmtestes.com.br

Versão original em português v1.0 23 de dezembro de 2011

20