Escolar Documentos
Profissional Documentos
Cultura Documentos
Qualquer indivduo ou grupo de indivduos poder utilizar este Quick Guide como base para seminrios, artigos, livros, material de suporte para o CPREFL Syllabus, traduo para qualquer outra lngua ou outras publicaes 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 verses em linguagem portuguesa e inglesa.
para auxiliar no Exame para Profissional de Engenharia de Requisitos Certificado Nvel 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 Jorge Luiz Diaz Pinaya. www.certified-re.de/international www.tmtestes.com.br
A parte mais rdua na construo 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 correes posteriores.
Frederick P. Brooks
72.8%
projeto 28%
outros 31%
requisitos 82%
Fonte: U.S. Air Force Project, F. Sheldon, 1992 Reliability Measurement from Theory to Practice
R$4900,00
R$2261,54
aceite
operao
Fonte: Mdia do custo de correo de um erro em requisitos por etapa (300 projetos T&M)
9
8
3
As 9 Unidades de Ensino do Syllabus CPRE-FL e o tempo minimo de ensino necessrio 18:00
2 3 4
UE 1 Introduo e Fundamentos
Sintomas e Causas de uma Engenharia de Requisitos (ER) inadequada
Presso do cliente para construo de um sistema rapidamente problemas de comunicao
8 7 6 5
As 4 atividades principais da ER
elicitao
Requisitos ambguos, incorretos, incompletos e omisso
documentao
gerenciamento
suposio incorreta, por parte dos stakeholders, de que muito do assunto evidente
trs
A linguagem natural (oral ou escrita) o meio mais utilizado para comunicar requisitos. Portanto, importante buscar uma terminologia comum e manter uma comunicao focada e simplificada
3
2+1
!
5
2 3 4
UE 1 Introduo e Fundamentos
8 7
O engenheiro de requisitos tem contato direto com os stakeholders e possui a competncia e responsabilidade de familiarizar-se ao mximo com o domnio, buscando compreende-lo da melhor maneira possvel.
raciocnio analtico
empatia resoluo de conflitos
auto-confiana
persuaso
1
requisitos no funcionais
requisitos funcionais
2
requisitos de qualidade
restries
As restries no so implementadas, elas so cumpridas, porque elas simplesmente limitam o espao de soluo!
2 3 4
8 7 6 5
Sistema
2 3 4
8 7 6 5
Limite do Sistema
Contexto do Sistema
Ambiente Irrelevante
Sistema
zona cinzenta (t1) Deslocamento do limite do sistema zona cinzenta (t2) Extenso do limite do contexto do sistema (t4) Reduo do limite do contexto do sistema (t3)
Zona cinzenta entre o contexto do sistema e o ambiente irrelevante Limite do contexto do sistema
2 3 4
UE 3 Elicitar Requisitos
UE 3.1
Contexto do Sistema
8 7 6 5
Fontes de Requisitos
informao para documentar os stakeholders
nome sistema
dados pessoais
disponibilidade
relevncia
objetivos e interesses em relao ao projeto para evitar mal-entendidos e disputas sobre competncias
direitos deveres
UE 3.2
Requisitos Subconscientes
fatores bsicos de satisfao
UE 3.3
fatores de risco influncias humanas
Tcnicas de Elicitao
influncias organizacionais influncias tcnicas (funocontedo) nvel de detalhamento esperado dos requisitos
fatores de entusiasmo
Requisitos Inconscientes
Fatores bsicos de satisfao devem ser atendidos pelo sistema de qualquer maneira. Caso contrrio, os stakeholders ficaro decepcionados .
Fatores esperados de satisfao so propriedades conscientemente conhecidas e explicitamente exigidas pelos stakeholders. Fatores inesperados de satisfao so propriedades cujo valor somente reconhecido quando o stakeholder pode utilizar o sistema na pratica.
O uso de tcnicas de elicitao apropriadas uma competncia decisiva para o sucesso do projeto. Os melhores resultados so alcanados com uma combinao de vrias tcnicas diferentes de elicitao
2 3 4
UE 4 Documentao de Requisitos
UE 4.1
representao requisitos tcnicas de documentao
8 7 6 5
Design do Documento
Muitas pessoas so envolvidas
at diagramas
...na comunicao
razes
duradouros
juridicamente relevantes
4 documentos de requisitos so
complexos
UE 4.2
Tipos de Documentao
perspectivas
Perspectiva Funcional Perspectiva Comportamental
Perspectiva Estrutural
10
2 3 4
UE 4 Documentao de Requisitos
UE 4.3
Documento de requisitos
8 7 6 5
UE 4.4
UE 4.5
Os documentos de requisitos servem de base para diferentes atividades ao longo do ciclo de vida PlanDo-Check-Act de desenvolvimento
parte central
estrutura de referncia muito utilizada IEEE 830-1998 Recommended Practice for Software Requirements Specifications
UE 4.6
critrios
acordado priorizado no ambguo
completo compreensvel
UE 4.7
Termos tcnicos especficos para um determinado contexto abreviaes e acrnimos conceitos do dia-a-dia sinnimos homnimos
Glossrio
uso obrigatrio conter as fontes dos termos responsabilidades definidas mantido ao longo do curso do projeto aprovado pelos stakeholders as entradas tm uma estrutura habitualmente acessveis consistente gerenciado de forma centralizado
Regras
11
2 3 4
8 7 6 5
Efeitos da Linguagem
nominalizao [...reiniciar o sistema...] substantivos sem ponto de referncia [ ...os dados devem ser exibidos...] quantificadores universais [...mostrar todos os dados em cada sub-menu...] condies formuladas de forma incompleta [a um hspede registrado com idade acima de 20 anos...] formulaes verbais de forma incompleta [os dados de login so fornecidos]
UE 5.2
template de sentenas
<objeto>
passos
Inserir objetos
12
2 3 4
8 7 6 5
modelo a representao abstrata de uma realidade existente, ou uma realidade a ser criada
os modelos retratam certos aspectos de uma realidade observada os modelos reduzem a realidade representada os modelos so construdos para um uso especfico
modelos
pragmatismo
modelos conceituais
Linguagens de Modelagem
... na construo de modelos conceituais so utilizadas linguagens de modelagem especificas. Uma linguagem de modelagem definida por
Sintaxe
Semntica
vantagens
Ao definir uma linguagem de modelagem para uma finalidade especfica podemos estabelecer abstraes relevantes da realidade
13
2 3 4
8 7 6 5
Modelo de Metas
UE 6.3
Casos de Uso
Especificaes de Caso de Uso
Os casos de uso ajudam a examinar e documentar um sistema planejado ou existente a partir da perspectiva do usurio Diagramas de Caso de Uso
um template predefinido geralmente preenchido para cada caso de uso relevante Os requisitos para o sistema a ser desenvolvido so modelados por trs perspectivas sobrepostas
UE 6.4
UE 6.5
Perspectiva Funcional
UE 6.7
Perspectiva Comportamental
documenta a estrutura de dados, bem como relacionamentos de uso e de dependncia no contexto do sistema
diagrama de entidade relacionamento
documenta a transformao de dados de entrada recebidos do ambiente do sistema, em dados de sada liberados para o ambiente diagrama de fluxo de dados
documenta os diversos estados em que um sistema pode se encontrar, bem como nos eventos responsveis por uma transio entre os estados statechart
diagrama de classe
diagrama de atividade
14
2 3 4
8 7 6 5
Fundamentos da Validao
2 requisitos so base para
as atividades seguintes do ciclo de desenvolvimento
UE 7.2
O objetivo do acordo de requisitos chegar a uma compreenso nica e comum entre os stakeholders relevantes, dos requisitos do sistema a ser desenvolvido
UE 7.3
1 completude do documento de requisitos 2 completude de cada requisito 3 rastreabilidade 4 exatido e adequao 5 consistncia 6 nenhuma deciso de design prematura 7 verificabilidade 8 necessidade
validao do contedo
1
validao da documentao
conformidade com o formato da documentao da documentao inteligibilidade no ambigidade conformidade com as regras da documentao
1 2 3
15
2 3 4
8 7 6 5
UE 7.5
1
melhora a qualidade dos resultados da validao
leitura em perspectiva
validao por prottipos
utilizao de checklists
UE 7.6
atividades
Acordo de Requisitos
tipos de conflito
tcnicas de resoluo acordo compromisso votao anlise de alternativas manda quem pode obter mais informaes pontos fortes e pontos fracos matriz de deciso
resoluo do conflito
1identificao de
conflitos
anlise de conflitos
resoluo de conflitos
4documentao da resoluo
de conflitos
conflito de contedo conflito de interesses conflito de valores conflito de relacionamentos conflito de poder em estruturas organizacionais
motivo stakeholders envolvidos opinies de cada um meios utilizados de soluo alternativas possveis razes apresentadas para deciso
16
2 3 4
UE 8 Gerenciar Requisitos
UE 8.1
condies do projeto
8 7 6 5
Designando Atributos
UE 8.2
Visualizaes de Requisitos
a partir de critrios definidos
contexto da gerncia do projeto diretrizes da empresa regras do domnio da aplicao restries do processo de desenvolvimento
nome <Evitar o congestionamento de trfego> descrio <O sistema deve calcular uma rota alternativa se o congestionamento exceder o limite configurado>
identificador <req10>
Visualizao seletiva
exibe um subconjunto de valores/atributos relacionados aos requisitos selecionados
Visualizao consolidada
exibe informaes consolidadas relacionadas aos requisitos selecionados
esquema de atributos
estabilidade
criticalidade
fonte
<Sr. R. especialista no domnio>
prioridade
<importncia para o mercado: alta>
<estvel>
<alta>
estrutura
nome do atributo
UE 8.3
processo
Definir as metas e as restries da priorizao
Priorizao de Requisitos
1
tcnicas
17
2 3 4
UE 8 Gerenciar Requisitos
UE 8.4
classes de relacionamentos de rastreabilidade
8 7 6 5
Rastreabilidade de Requisitos
rastreabilidade com artefatos especificados ANTES da especificao-de-requisitos rastreabilidade com artefatos especificados APS a especificao-de-requisitos rastreabilidade entre requisitos referncias textual e hyperlink matriz de rastreabilidade grafo de rastreabilidade
UE 8.5
componentes
Versionamento de Requisitos
Configurao de requisitos
dimenso
Vantagens
simplificao da verificabilidade identificao das propriedades desnecessrias do sistema identificao dos requisitos desnecessrios respaldo para anlise de impacto respaldo para reusabilidade respaldo para determinao de responsabilidades respaldo para manuteno e administrao
nmero da verso
produto verso
conexo lgica
verso incremento
caractersticas
consistncia
maneiras de representao
baseline
ID nico
inalterabilidade base para roll-back
UE 8.6
tipos de solicitao
analisar o impacto e avaliar a mudana priorizar a solicitao de mudana alocar a mudana para um projeto de modificao comunicar a deciso
informaes
aprovar
rejeitar
18
2 3 4
8 7 6 5
Avaliao de Ferramentas
Muitas ferramentas de desenvolvimento de sistemas tambm atuam como apoio para a ER, como por exemplo: ferramentas de gerenciamento de testes ou de configurao, ferramentas Wiki, pacotes de aplicativos de escritrio ou ferramentas de visualizao. As ferramentas de modelagem so igualmente importantes para a ER, na funo de elaborar e analisar as informaes sob forma de modelos.
Uma ferramenta apropriada somente poder ser escolhida aps a introduo de procedimentos e tcnicas de ER requer responsabilidades e procedimentos claros de ER
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]
As 8 funcionalidades das ferramentas de gerenciamento exclusivas da ER: 1. Gerenciar diversos tipos de informaes 2. Estabelecer e manter relacionamentos lgicos entre as informaes 3. Identificar os artefatos 4. Permitir um acesso flexvel e seguro s informaes atravs do controle de acesso 5. Possibilitar diferentes visualizaes das informaes 6. Organizar as informaes
5 aspectos a observar:
2. Usurio
1. Planejar recursos
2. Reduzir riscos por meio da implementao de um projeto piloto 3. Realizar a avaliao conforme critrios prdefinidos 4. Considerar o custo global, alm do custo das licenas 5. Treinar usurios
[especialmente a usabilidade]
3. Produto
[as funcionalidades]
4. Processo
[apoio metodolgico]
5. Fornecedor 6. Tcnica
[servios oferecidos]
[a interoperabilidade, a escalabilidade,...]
7. Gerar relatrios
8. Gerar documentos
7. Econmica
[custos]
19
O Instituto Brasileiro de Qualidade e Testes de Software (IBQTS) foi licenciado pelo IREB para realizar o exame CPRE no Brasil. Inscries, bem como os detalhes de organizao 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 so marcas registradas, e pertencem aos seus respectivos detentores.
20