Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
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