Buscar

Aula 5 - (2012)

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 57 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 6, do total de 57 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 9, do total de 57 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Prévia do material em texto

09/03/2012
1
2
� Stakeholders (Partes interessadas)
◦ Um stakeholder pode ser definido como alguém 
que ganha ou perde algo com o resultado do 
projeto
[Conte 2007]
09/03/2012
2
3
� Exemplos típicos de stakeholders:
◦ Usuários – grupo que irá usar o software
◦ Clientes – grupo que encomendou o software ou que 
representa o público alvo do mesmo
◦ Analistas de mercado – para casos de produtos que precisam 
da análise de mercado
◦ Autoridades de regulamentação – para aplicações com 
regulamentações próprias, como transporte público
◦ Desenvolvedor/Engenheiro de Software
◦ Outros engenheiros de software
[Conte 2007]
4
� O contato inicial normalmente indica pessoas 
com quem se deve falar, seus papéis e seus 
interesses
� Stakeholders incluem usuários diretos do sistema 
e interessados indiretos também
� Stakeholders podem sugerir outras pessoas que 
devem ser consultadas …
[Conte 2007]
09/03/2012
3
5
interessados
fregueses
desenvolvedores
usuários
clientes
dono
especialista
contratado
parceiro
cliente terceirizados
investidor
Controle Qualidade
programadores
engenheiros de software
não clientes
[Breitman 2007]
� Atores do Universo de Informações
◦ Clientes
◦ Usuários
◦ Desenvolvedores
� Documentos
� Livros
� Sistemas de Software
6
09/03/2012
4
7
� É aquele conhecimento que é trivial para o 
entrevistado e não o é para o entrevistador
� Por ser trivial nunca é lembrado como 
importante e, portanto, não é transmitido ao 
entrevistador, que, não sabendo, não pode 
perguntar
[Breitman 2007]
8
Perguntar por que?
“A cafeteira deve ser feita de aço”
� qual a razão disto?
� pode me explicar porquê?
� qual o pensamento por detrás disto?
Ian Alexander, Writing better requirements
09/03/2012
5
9
“Porque se for de vidro pode quebrar”
Requisito real:
� A cafeteira deve ser feita de material 
inquebrável 
� Plástico
� Poliuretano
� Até mesmo aço 
Ian Alexander, Writing better requirements
10
� “a cafeteira tem uma luz vermelha que pisca 
quando está ligada, quando a água chega 
na temperatura certa ela fica ligada (sem 
piscar)”
◦ Quais seriam as perguntas do tipo “por que” que 
poderiam ser utilizadas nesta situação?
◦ Quais seriam os “reais” requisitos?
Dica: Separar requisito de solução/implementação
09/03/2012
6
11
� Os usuários misturam a solução com os 
requisitos 
Separar NECESSIDADE da solução proposta!
[Breitman 2007]
12
� Os clientes dificilmente têm uma idéia clara 
do que realmente querem
� Diferentes pessoas dentro da organização 
normalmente possuem requisitos 
conflitantes
� Podem existir na maioria dos casos 
limitações tecnológicas influenciando os 
requisitos.
� …
09/03/2012
7
13
14
� Entrevistas estruturadas
◦ requer um prévio conhecimento sobre o contexto onde se 
aplica a entrevista. 
◦ é feita com base em perguntas previamente pensadas ou
delineadas.
◦ Claro, que o entrevistador tem liberdade de inserir perguntas
de clarificação ou eventualmente outras que se façam
necessárias, mas o núcleo de perguntas já é definido a priori. 
◦ O papel do entrevistador na entrevista estruturada é um papel
de questionador. 
Fonte:[Leite 2007]
09/03/2012
8
15
� Entrevista não-estruturada
◦ é aplicada quando se inicia o contato com o Universo
de Informações e serve para garimpar informações
iniciais. 
◦ Fundamentalmente o entrevistador deixa o 
entrevistado falar, mas procura orientá-lo para que a 
entrevista mantenha o foco no tópico de interesse.
◦ O papel do entrevistador é um papel de aprendizado. 
Fonte:[Leite 2007]
16
� Extensão da entrevista 
� Brainstorm
� Workshop de Requisitos
[Breitman 2007]
09/03/2012
9
17
� Toda reunião/entrevista deve ser 
planejada
◦ Os objetivos da reunião devem estar claros;
◦ Os participantes devem ser bem escolhidos
◦ Deve haver uma convocação (com pauta) 
◦ Deve ser entregue aos participantes uma ata de 
reunião anterior (para relembrar as decisões 
tomadas) e uma lista com os requisitos já 
elicitados até o momento
18
� Manter o foco e os objetivos da reunião
� Registrar o conteúdo
◦ Anotar
◦ gravar
� Gerenciar conflitos
� Definir próximos passos.
� Após reunião:
◦ Elaborar uma ata e atualizar documentação relevante
09/03/2012
10
19
� +
� facilidade de acesso às fontes de informação
� volume de informação
� -
� dispersão das informações
20
◦ baixo custo
◦ pouca complexidade da tarefa
◦ dependência do ator (observador)
◦ superficialidade decorrente da pouca
exposição ao universo de informações
[Breitman 2007]
09/03/2012
11
© Carla A. Lima Reis, 2007 21
[Leite, 
2007]
22
� Qualitativo
� Quantitativo
� O que perguntar
◦ exige conhecimento mínimo
◦ similar a entrevista estruturada
[Breitman 2007]
09/03/2012
12
23
� Quantitativo
0
5
10
15
20
25
30
35
40
45
50
55
60
N
u
m
. 
d
e
 R
e
s
p
o
s
ta
s
5. A XXX mantém dados estatísticos sobre o processo de 
desenvolvimento de software?
SIMNÃO
[Breitman 2007]
24
� Qualitativo
� O quê você acha da sua formação no que se refere a 
produção de software de qualidade?
� O que você acredita ser necessário para aprimorar seu 
desempenho? 
� Quais conhecimentos você desejaria adquirir? Por quê?
� Objetivo: verificar a opinião em relação a política de 
treinamento
� Justificativa: uma organização madura tem políticas bem 
definidas de treinamento.
[Breitman 2007]
09/03/2012
13
25
26
� Taxonomias propostas na literatura 
servem de guia para a elicitação
09/03/2012
14
© Carla A. Lima Reis, 2007 27
Requisitos não Requisitos não 
funcionaisfuncionais
Processo
Requisitos de
Processo
Requisitos de
Produto Externos
Requisitos 
Externos
requisitos de
entrega
requisitos de
usabilidade
requisitos de
eficiência
requisitos de 
confiabilidade
requisitos de
portabilidade
requisitos de
implementação
requisitos para
padrões
requisitos de
espaço
requisitos
de custo interoperabilidade
requisitos de
interoperabilidade
requisitos
legais
requisitos de 
performance
Taxonomia – Proposta 1
Sommerville 92
09/03/2012
15
30
Requisito Inverificável Requisito Verificável
“ O banco de dados ZZ deve ser flexível” �O banco de dados ZZ deve possuir oito campos 
por registro.
“MNOP deve ser seguro” �MNOP deve parar sua operação se uma pessoa
se aproximar a menos de 2 metros de uma de 
suas partes móveis
�MNOP deve desligar os aquecedores se a 
temperatura da água exceder 37°C
�MNOP deve estar dentro dos padrões
estabelecidos pela norma N567 seção 3.6 para
temperaturas de superfícies externas.
“O sistema CE deve processar depósitos 
rapidamente”
�O sistema CE deve escanear os dados do 
usuário e conta de cada folheto de depósito em 2 
segundos ou menos”
• Requisitos não funcionais devem ser elaborados até que se tornem verificáveis
Ralph Young – effective requirements practices
09/03/2012
16
31
Palavras não Verificáveis Possíveis substitutos
Amigável Número máximo de passos
Lista de funcionalidades presentes em outras 
aplicações
Menus ou prompts para auxiliar usuários
Portável Dimensões 
Requisitos mínimos de hardware
Sistemas operacionais em que deve funcionar 
Pequeno Dimensões aceitáveis (em número de Bytes)
Flexível Possui variáveis que podem acomodar mudanças
de valores
Ralph Young – effective requirements practices
• Algumas palavras levam a requisitos impossíveis de serem 
verificados
32
� Reescreva os seguintes requisitos:
◦ o sistema bibliotecário deve serfácil de usar;
◦ o sistema deve fornecer um serviço confiável a 
todas as classes de usuários;
◦ o sistema deve permitir uma resposta rápida a 
todos os pedidos de informação.
09/03/2012
17
33
34
� O sistema deve + [frase verbal ] + [complemento de 
agente | nulo] + [condições | nulo]
� Frase verbal é uma frase que expressa a funcionalidade do 
requisito
� Complemento de agente é a identificação de um agente 
relacionado com o requisito; Agente pode ser uma 
pessoa, uma instituição, um grupo ou um dispositivo 
físico externo ao software
� Condições são as possíveis condições externas ou 
internas ao sistema que influenciam o requisito
[Breitman 2007]
09/03/2012
18
35
� O sistema deve emitir um recibo para o cliente.
� O sistema deve emitir o recibo para o cliente em no 
máximo 2 segundos.
� O sistema deve cadastrar o cliente, desde que o cliente 
possua identificação. 
� O sistema deve transformar uma fita disponível em fita 
emprestada, quando a fita for alugada pelo cliente.
� O sistema deve cadastrar bibliotecários.
� O sistema deve verificar a identidade do bibliotecário.
� O sistema não pode deixar que um livro fique na reserva 
mais de um mês.
[Breitman 2007]
36
� Claro
� Não Ambíguo
� Completo
� Simples
� Bem escrito
[Breitman 2007]
09/03/2012
19
37
Um requisito claro
Tipo de usuário O engenheiro de testeC
Resultado desejado Csimula
Objeto Cerros de componente C.
Condições Cutilizando as funções de teste QQ e TT. 
Um requisito vago
Em geral o sistemaC
Precisa ou não? C deve ser capazC
Quais? Cde diagnosticar possíveis errosC
Como verificar isto? C em um prazo razoável.
[Breitman 2007]
38
� No evento de falha da rede elétrica, o 
sistema deve enviar mensagem de erro ao 
usuário, salvar a configuração atual do 
sistema e os dados entrados, até então.
� O sistema deve manter dados estatísticos 
sobre compra, venda e movimentação do 
estoque de materiais de limpeza. 
Informação relativa a comissão de 
vendedores também deve ser mantida.
[Breitman 2007]
09/03/2012
20
39
Mas, com exceção, apesar, quando…
� O sistema deve mostrar o total do pedido a 
medida em que os códigos dos produtos vão 
sendo entrados no pedido, a não ser que se 
trate de um produto promocional.
[Breitman 2007]
40
� O sistema poderá ser acessado 
remotamente por qualquer unidade 
internacional da Petrobras, com isso, ele 
deverá ter um desempenho compatível ao 
acesso. 
[Breitman 2007]
09/03/2012
21
41
� Descreva cinco requisitos sobre um sistema de 
venda de passagens aéreas.
� Descreva um requisito incompleto.
[Breitman 2007]
42
Identificação
, descoberta 
de requisitos
análise e 
negociação 
de 
requisitos
documentaçã
o de 
requisitos
validação de 
requisitos
documento 
de requisitos
necessidades dos utilizadores, 
sistemas legados,
informação do domínio, 
normas organizacionais, 
etc.
09/03/2012
22
� No conjunto de requisitos identificados pode
◦ haver requisitos que se sobrepõem
◦ haver requisitos que estão em conflito ou que são
contraditórios
◦ faltar requisitos
� Análise de completude é uma das mais difíceis de 
serem realizadas.
43
� matriz de dependências
44
requisito r1 r2 r3 r4
r1 x x x x
r2 conflito x x x
r3 x x
r4 sobreposição sobreposição x
09/03/2012
23
� Risco nos requisitos tem relação com 
◦ Dificuldades no desenvolvimento de Requisitos
◦ Dificuldades na análise de Requisitos
45
46
� Normalmente requisitos que têm alto risco 
devem estar associados com alta prioridade.
tempo
risco
Risco tem de decair
com a evolução do
projeto.
09/03/2012
24
47
� Negociação para quê?
◦ Chegar a acordo em relação a opções mais 
adequadas aos interesses dos stakeholders
◦ Definir as prioridades para os requisitos
48
� stakeholders primáriosprimáriosprimáriosprimários
◦ os que operam o sistema
◦ preocupam-se com os requisitos funcionais e 
questões de usabilidade
◦ pretendem sistemas fáceis de usar e aprender
09/03/2012
25
49
� stakeholders secundáriossecundáriossecundáriossecundários
◦ não operam o sistema mas consomem o que este
produz
◦ o sucesso das suas atividades depende da
qualidade do sistema
◦ são tipicamente gestores que usam a informação
do sistema para controlar, monitorar e ajustar
processos organizacionais
50
� Stakeholders terciáriosterciáriosterciáriosterciários
◦ Gestores de topo da hierarquia que raramente 
consomem as saídas do sistema (diretamente) 
◦ Usam as saídas indiretamente para planejar e 
controlar estrategicamente o negócio
◦ Interessam-se pelo papel que o sistema 
desempenha para obtenção dos objetivos 
estratégicos do negócio
09/03/2012
26
51
� Problemas num processo de negociação
◦ separar os aspectos a debater das questões 
pessoais
◦ falta de entendimento compartilhado e de pontos 
de vista pessoais
52
� Lidar com os ataques pessoais
◦ Evitá-los...
◦ Se acontecerem: mudar de assunto, fazer um 
intervalo...
◦ Resolver o problema fora da reunião
09/03/2012
27
53
� Impedir as seguintes reações:
◦ "isso não funciona", “é impossível", "dá muito
trabalho", “quem foi o imbecil que propôs…" 
� Deve solicitar que os participantes
justifiquem a posição negativa
54
� Conflitos entre grupos
◦ choque de pontos de vista entre grupos
◦ exemplos:
� Qualidade vs. Prazos
� Segurança vs. Acesso
� Complexidade funcional vs. Usabilidade
� etc.
� É necessário tentar: 
◦ encontrar potenciais benefícios para todos
◦ evitar tomar partido
09/03/2012
28
55
Gerência de Requisitos
56
� Maiores riscos:
◦ “passar por cima” de um requisito crucial
◦ definir requisitos incorretamente
◦ representar inadequadamente os clientes
◦ modelar apenas aspectos funcionais
◦ falta de inspeções nos requisitos
[Breitman 1007]
09/03/2012
29
57
Parte 3
VerificaçãoVerificaçãoVerificaçãoVerificação
58
ValidaçãoValidaçãoValidaçãoValidação
estamos estamos estamos estamos 
construindo o construindo o construindo o construindo o 
produto de produto de produto de produto de 
maneira certa?maneira certa?maneira certa?maneira certa?
estamos estamos estamos estamos 
construindo o construindo o construindo o construindo o 
produto certo?produto certo?produto certo?produto certo?
09/03/2012
30
59
� Estamos construindo o produto certo?
◦ Teste
◦ Execução de cenários (leitura em reunião)
◦ Leituras por atores interessados
◦ Protótipos
60
09/03/2012
31
© Carla A. Lima Rei/ Rodrigo Reis, 2007
61
� Prototipagem em papel
◦ Processo simples: muitas iterações
◦ Identificação precoce de problemas
◦ Baixo custo para reparar erros
◦ Notas de Post-it ou rascunhos no papel
� Menus
� Janelas
� Botões
� Caixas de diálogos
� Etc.
[Lemos, Kuroki, 2007]
62Fonte: http://www.sapdesignguild.org/resources/glossary_web/index2.html
09/03/2012
32
© Carla A. Lima Rei/ Rodrigo Reis, 2007
63Fonte: http://www.snyderconsulting.net/article_paperprototyping.htm
64
� Ajudam a clarear requisitos
◦ Requisitos que embora conhecidos estão
pobremente definidos e pouco compreendidos
◦ Reações do tipo “agora que estou vendo
funcionar também preciso de …..”
� Disponibilidade de ferramentas que
permitem a construção rápida e barata de 
protótipos
Breitman, 2007]
09/03/2012
33
65
� Vertical X Horizontal
◦ Horizontal
� implementa grande parte da funcionalidade
◦ Vertical
� implementa poucas funções
� maior qualidade
© Carla A. Lima Rei/ Rodrigo Reis, 2007
66
09/03/2012
34
67
� Desafio Atual:
◦ O que se deve gerenciar?
◦ É possível gerenciar efetivamente requisitos?
◦ Qual o ganhocom o gerenciamento?
68
� Antes do Processo de Gerência de Requisitos
◦ “Quem definiu isso? Vou tentar me lembrar...”
� Depois do Processo de Gerência de Requisitos
◦ “Quem definiu isso? Foi a área de negócio XYZ no 
dia 10 de janeiro segundo consta aqui nessa ata...”
09/03/2012
35
69
� Gerenciamento
◦ Antes do Processo de Gerência de Requisitos
� “Como o usuário pode estar insatisfeito com a mudança 
de prazo se estamos fazendo tudo que ele quer?”
◦ Depois do Processo de Gerência de Requisitos
� “Informe ao usuário que os novos requisitos acarretarão 
um desvio de 20% no prazo e 5% no custo”
70
� Um requisito é rastreável se for possível 
identificar:
◦ Quem solicitou o requisito
◦ Porque o requisito existe
◦ Quais os requisitos relacionados
◦ Como os requisitos se relacionam a outras 
informações
09/03/2012
36
71
� Seu objetivo é criar vínculos (links) entre os requisitos e 
outros itens do sistema
� A rastreabilidade é importante para auxiliar a avaliação do 
impacto de mudanças nos requisitos
� E também para demonstrar a completa satisfação dos 
requisitos
72
Requisitos do 
Usuário
Projeto do 
Sistema
Especificações 
do Sistema
forward – p/ avaliar o impacto de mudança
backward – p/a rastrear a origem de um componente
09/03/2012
37
73
� Ferramentas de Gerência de Requisitos 
devem oferecer facilidades para:
◦ Identificação e Armazenamento dos Requisitos;
◦ Gerenciamento de mudanças, que ajudem a 
garantir que as mudanças solicitadas foram 
avaliadas e tratadas corretamente;
◦ Rastreabilidade, que auxiliem a encontrar 
dependências entre os requisitos.
� ReqManager (TABA)
� Analyst Pro (Goda Software, 
Inc.)
� CaliberRM (Borland)
� Catalyze (SteelTrace)
� Cradle (3SL - Structured
Software Systems Ltd)
� Enterprise Architect
74
� Doors (Telelogic AB)
� Objectiver (Cediti)
� RDT (Igatech)
� Reconcile
(Compuware
Corporation)
� Requisite Pro (IBM 
Rational Software)
09/03/2012
38
75
� Tabela utilizada para documentar os 
relacionamentos entre os requisitos
� Rastreabilidade Horizontal e Vertical:
◦ Requisitos do Cliente,
◦ Módulos de Código,
◦ Casos de Teste...
76
09/03/2012
39
77
78
09/03/2012
40
79
� Ao adotar um processo de Gerenciamento de 
Requisitos, a organização precisa definir sua 
Política de Rastreabilidade de Requisitos que deve 
incluir:
◦ A informação de rastreabilidade que será mantida; 
◦ As técnicas e ferramentas que serão utilizadas;
◦ Processo de coleta das informações de rastreabilidade: 
quem e quando
◦ Processo de atualização das informações de 
rastreabilidade, após alterações
80
09/03/2012
41
© Carla A. Lima Rei/ Rodrigo Reis, 2007
81
82
09/03/2012
42
83
© Carla A. Lima Rei/ Rodrigo Reis, 2007
84
09/03/2012
43
© Carla A. Lima Rei/ Rodrigo Reis, 2007
85
© Carla A. Lima Rei/ Rodrigo Reis, 2007
86
09/03/2012
44
87
� Ferramenta de gerência de 
requisitos
� Integração com o Microsoft Word
�Noção dos impactos de alterações 
dos requisitos
© Carla A. Lima Rei/ Rodrigo Reis, 2007
88
projetoprojetoprojetoprojeto
explorerexplorerexplorerexplorer
visõesvisõesvisõesvisões
pastapastapastapasta
documentodocumentodocumentodocumento
visãovisãovisãovisão
requisitorequisitorequisitorequisito
09/03/2012
45
89
---- Prioridade, status, dificuldade, risco...Prioridade, status, dificuldade, risco...Prioridade, status, dificuldade, risco...Prioridade, status, dificuldade, risco...
90
09/03/2012
46
91
Entendimento, comprometimento e mudança 
dos requisitos
92
� Fornecedores de Requisitos
◦ Para o MPS.BR é desejável que os fornecedores de 
requisitos estejam identificados e aprovados pelo 
patrocinador do projeto.
◦ Uma possível opção é registrar no plano do projeto 
quem serão os fornecedores de requisitos e como 
será a comunicação com os mesmos 
� Incluindo como mudanças nos requisitos poderão ser 
solicitadas
09/03/2012
47
93
� Meios e formas de comunicação com 
fornecedores de requisitos
◦ As comunicações devem ser registradas 
formalmente através de:
� Atas de reunião
� Documentos (devem ser aprovados/assinados)
� Emails (devem ser armazenados)
� Ou outras ferramentas de comunicação
94
� Meios e formas de comunicação com 
fornecedores de requisitos
◦ É importante a comprovação de que os 
interessados estão de acordo com o conteúdo 
registrado
◦ Devem ser definidos e evidenciados os meios e 
formas de comunicação, momentos e/ou 
freqüências para as comunicações
09/03/2012
48
95
� Procedimentos para obtenção do entendimento 
sobre os Requisitos
◦ Para o conjunto de requisitos especificados, é necessário 
rever com o cliente se as necessidades e expectativas estão 
sendo atendidas com os requisitos propostos. 
◦ Como comprovação deste entendimento deve-se ter um 
documento de requisitos
96
� Comprometimento com os Requisitos
◦ Após o entendimento dos requisitos e da 
aceitação dos mesmos, é necessário o 
comprometimento dos responsáveis pela 
implementação dos requisitos
� Partes envolvidas no Comprometimento
◦ Equipe técnica da empresa (equipe do projeto)
◦ Cliente
09/03/2012
49
97
� Efetivação do Comprometimento
◦ Pode ser feito de diversas formas, porém devem ser sempre 
documentados
◦ Exemplo de prática para efetivação do comprometimento:
� Reunião de kick off onde se apresenta o projeto como um todo 
(incluindo seus requisitos)
� Esta reunião possibilita que as diversas partes possam opinar e 
se comprometerem em relação aos requisitos do projeto
◦ Sempre que forem aprovadas mudanças nos requisitos, 
deve-se obter novos comprometimentos para os requisitos 
do projeto
98
� Estabelecimento da Rastreabilidade Bidirecional
◦ Um mecanismo que permita rastrear a dependência entre 
os requisitos, os planos do projeto e os produtos de 
trabalho deve ser estabelecido
◦ A rastreabilidade bidirecional deve ser tanto horizontal 
quanto vertical
09/03/2012
50
99
� Itens que devem ser rastreáveis 
◦ A rastreabilidade só é efetiva para a avaliação do 
impacto das mudanças se existe rastreabilidade 
bidirecional entre os itens com impacto no 
produto:
� Requisitos
� Produtos de trabalho
� Componentes do projeto 
� Códigos de unidade ou módulos do software
� Casos de Teste (caso existam)
100
� Identificação de Inconsistências entre requisitos e 
outros produtos de trabalho 
◦ Quando há mudanças nos requisitos:
� Devem ser identificados os impactos da mudança com a 
utilização do instrumento de rastreabilidade dos requisitos
� Deve-se examinar se os demais artefatos estão consistentes 
com as alterações realizadas
09/03/2012
51
101
102
� Processo: Gerência de Requisitos
� Nível MPS.Br: G – Parcialmente Gerenciado
� Propósito:
O propósito do processo Gerência de Requisitos é
◦ Gerenciar os requisitos dos produtos e componentes do 
projeto 
◦ Identificar inconsistências entre os requisitos, os planos 
do projeto e os produtos de trabalho do projeto.
09/03/2012
52
10
3
Resultados esperados
GRE 1. O entendimento dos requisitos é obtido 
junto aos fornecedores de requisitos;
GRE 2. Os requisitos de software são aprovados 
utilizando critérios objetivos;
GRE 3. A rastreabilidade bidirecional entre os 
requisitos e os produtos de trabalho é 
estabelecida e mantida;
10
4
Resultados esperados
GRE 4. Revisões em planos e produtos de 
trabalho do projeto são realizadas visando 
identificar e corrigir inconsistências em relação 
aos requisitos;
GRE 5. Mudanças nos requisitos são 
gerenciadas ao longo do projeto.
09/03/2012
53
105� Resultados Atributos do Processo 
Esperados:
RAP 1. O processo de Gerência de Requisitos
atinge seus resultados definidos
RAP 2. Existe uma política organizacional 
estabelecida e mantida para a Gerência de 
Requisitos
RAP 3. A execução do processo de Gerência de 
Requisitos é planejada
RAP 4. A execução da Gerência de Requisitos é 
monitorada e ajustes são realizados para 
atender aos planos
106
� Resultados Atributos do Processo Esperados:
RAP 5. Os recursos necessários para a execução da Gerência de 
Requisitos são identificados e disponibilizados 
RAP 6. As pessoas que executam a Gerência de Requisitos são 
competentes em termos de formação, treinamento e 
experiência
RAP 7. A comunicação entre as partes interessadas na Gerência de 
Requisitos é gerenciada de forma a garantir seu envolvimento 
no projeto
RAP 8. O estado, atividades e resultados da Gerência de Requisitos
são revistos com os níveis adequados de gerência (incluindo a 
gerência de alto nível) e problemas pertinentes são tratados
09/03/2012
54
107
� Informações adicionais para Gerência de 
Requisitos:
◦ Consulte NBR ISO/IEC 12207, emendas 1 e 2 da 
12207: Subprocessos Elicitação de Requisitos e 
Análise de Requisitos de Software
◦ Consulte ISO/IEC 15504-5: Processos Elicitação 
de Requisitos e Análise de Requisitos de Software
◦ Consulte CMMI-SE/SW: Área de Processo 
Gerência de Requisitos 
108
Gerência de Requisitos no CMMI
Processos de Engenharia de Requisitos na 
ISO 12207
09/03/2012
55
109
� Relaciona-se com duas Áreas de Processo:
◦ Gerência de Requisitos (Nível de Maturidade 2)
◦ Desenvolvimento de Requisitos (Nível de 
Maturidade 3)
110
� Aplica-se
◦ a todos os requisitos de produtos e componentes 
do produto que são entregues com o projeto
09/03/2012
56
111
� Objetivo Específico:
◦ Gerenciar requisitos
� Os requisitos são gerenciados e inconsistências com 
os planos de projeto e produtos de trabalho são 
identificadas
11
2
Matriz de 
Rastreabilidade
Requisitos
Obter 
Entendimento 
dos Requisitos
Obter Aceite/ 
Comprometi-
mento com os 
Requisitos
Gerenciar 
Mudanças nos 
Requisitos
Identificar 
Inconsistências 
entre o Trabalho 
do Projeto e os 
Requisitos
Manter 
Rastreabilidade
bidirecional dos 
Requisitos
Gerenciar Requisitos
09/03/2012
57
113
� Gerenciar requisitosGerenciar requisitosGerenciar requisitosGerenciar requisitos
� Deve ser mantido um conjunto atualizado de
requisitos aprovados durante o projeto, sendo
necessário:
� Gerenciar todas as mudanças nos requisitos
� Manter os relacionamentos entre os requisitos, os planos 
do projeto e os produtos
� Identificar inconsistências entre o trabalho do projeto e 
os requisitos
� Iniciar ações corretivas
� 1) Escreva os requisitos funcionais do sistema 
escolhido
� 2) Escreva os requisitos não-funcionais do 
sistema escolhido
� 3) Faça a matriz de rastreabilidade dos 
requisitos funcionais x requisitos funcionais

Outros materiais