O documento discute a gerência de requisitos no processo de engenharia de software, abordando tópicos como a evolução dos requisitos, conceito de gerência de requisitos, gerenciamento de mudanças, rastreabilidade, ferramentas, entre outros.
1. Gerência de Requisitos
Disciplina Engenharia de Software
Mauricio Volkweis Astiazara
Mirela Ferreira César
Porto Alegre, maio de 2010
2. Sumário
Evolução dos Requisitos
Conceito de Gerência de Requisitos
Gerenciamento de Mudanças de Requisitos
Rastreabilidade de Requisitos
Planejamento da Gerência de Requisitos
Ferramentas para Gerência de Requisitos
Conclusão
3. Evolução dos Requisitos
Requisitos costumam sofrer modificações porque o problema
para o qual se refere o requisito não foi inteiramente definido,
os requisitos do sistema são necessariamente incompletos.
4. Evolução dos Requisitos
Por que os requisitos mudam?
● Porque durante o processo de software o entendimento dos
desenvolvedores vai se modificando.
● No aperfeiçoamento de um sistema antigo ou automatização de um
processo manual podem surgir novos requisitos.
● Quando os usuários se familiarizam com o sistema, novos
requisitos surgem pelas seguintes razões:
○ A comunidade de usuários é diversificada;
○ O pessoal que paga por um sistema e os usuários desse
sistema raramente são as mesmas pessoas e;
○ A empresa e o ambiente técnico do sistema se modificam, e isso
tem de ser refletido no próprio sistema.
5. Evolução dos Requisitos
Evolução dos Requisitos. Adaptado de SOMMERVILLE, 2003.
Compreensão
inicial do problema
Compreensão
modificada do
problema
Requisitos
Iniciais
Requisitos
Modificados
6. Evolução dos Requisitos
Na perspectiva de evolução, os requisitos podem ser
classificados como:
●Voláteis
●Permanentes
8. Gerenciamento de Mudanças de
Requisitos
Alteração no sistema e depois nos requisitos faz com que
especificação e implementação se desajustem.
Se este tipo de situação acontecer, os requisitos cairão em
descrédito e serão relegados a segundo plano.
Deve ser adotado um processo de gerenciamento de
mudanças.
9. Gerenciamento de Mudanças de
Requisitos
A vantagem de utilizar um processo formal para o
gerenciamento de mudanças é que todas as propostas de
mudança são tratadas de modo consistente e que as
mudanças no documento de requisitos são feitas de maneira
controlada (SOMMERVILLE, 2003).
10. Gerenciamento de Mudanças de
Requisitos
Há três estágios:
1. Análise do problema e especificação da mudança.
2. Análise e custo da mudança.
3. Implementação de mudanças.
11. Gerenciamento de Mudanças de
Requisitos
Problema
identificado Análise do problema e
especificação da mudança
Análise e custo da mudança
Implementação de
mudanças
Requisitos e
outros artefatos
revisados
12. Gerenciamento de Mudanças de
Requisitos
Um dos principais problemas de um projeto é gerenciar o
escopo. Facilmente a correta gerência de escopo é perdida.
O escopo deve ser modificado com a anuência de todos os
envolvidos.
Os requisitos macro representam diretamente um eventual
aumento de escopo. Os requisitos macro que implicam novos
casos de uso devem ser inseridos somente se aprovados pelo
financiador do projeto (MAGELA, 2006).
13. Gerenciamento de Mudanças de
Requisitos
Requisitos podem ser alterados, incluídos ou excluídos.
Mas deve ser realizado um gerenciamento de versões,
mantendo o histórico de cada atualização, com dados como
data, projeto, usuário solicitante e motivo.
Realizar esta tarefa sem uso de ferramentas é bastante
trabalhoso (MAGELA, 2006).
14. Rastreabilidade de Requisitos
A facilidade de rastreamento é uma propriedade geral de uma
especificação de requisitos que reflete a facilidade de se
encontrar requisitos relacionados.
Os requisitos devem obrigatoriamente possuir rastreabilidade
para trás (origem) e para frente (projeto) para garantir a
qualidade e consistência da especificação.
15. Rastreabilidade de Requisitos
●A rastreabilidade apoia a gerência de mudanças.
●Quando são propostas modificações, é preciso verificar o
impacto dessas mudanças sobre outros requisitos e o
projeto do sistema.
●As informações sobre facilidade de rastreamento são,
frequentemente representadas com o uso de matrizes de
facilidade de rastreamento
16. Matriz de Rastreabilidade
Rastreabilidade de Requisitos
ID do
Requisito
1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2
1.1 U R
1.2 U R U
1.3 R R
2.1 R U U
2.2 U
2.3 R U
3.1 R
3.2 R
A dependência entre os
requisitos é registrada na
interseção da linha com
a coluna.
Neste exemplo, "U"
indica que o requisito da
linha utiliza recursos
especificados no
requisito da coluna, e "R"
para indicar um
relacionamento fraco
entre os requisitos.
17. Rastreabilidade de Requisitos
Requisito
Funcional
Caso
de Uso
UC-1 UC-2 UC-3 UC-4
RF-1 <--
RF-2 <--
RF-3 <--
RF-4 <--
RF-5 <-- <--
RF-6 <--
A intersecção entre dois
componentes indica uma conexão.
É possível utilizar um símbolo na
célula para indicar o
sentido "rastreado-para" e
"rastreado-de", ou alguma outra
relação.
Matriz de Rastreabilidade
Algumas ferramentas indicam de forma automática uma relação
"suspeita" sempre que um objeto da conexão é modificado. O
"suspeito" facilita a análise de impacto numa mudança de requisitos.
18. Rastreabilidade de Requisitos
Requisito
do
Usuário
Requisito Funcional Elemento do
Sistema
Código Caso de
Teste
UC-28 catalog.query.sort Classe catalog catalog.sort() search.7
search.8
UC-29 catalog.query.import Classe catalog catalog.import()
catalog.validate()
search.12
search.13
search.14
A rastreabilidade pode ter relações do tipo: um-para-um,
um-para-muitos, ou muitos-para-muitos
Matriz de Rastreabilidade
19. Rastreabilidade de Requisitos
Tipo de Objeto Fonte da
Ligação
Tipo de Objeto Alvo da
Ligação
Fonte da Informação
Requisito de Sistema Requisito de Software Engenheiro de Sistema
Caso de Uso Requisito Funcional Analista de Requisitos
Requisito Funcional Requisito Funcional Analista de Requisitos
Requisito Funcional Caso de Teste Engenheiro de Teste
Requisito Funcional Elemento de Arquitetura de
Software
Arquiteto de Software
Requisito Funcional Outros Elementos de Projeto Projetista ou
Desenvolvedor
Elemento de Projeto Código-fonte Desenvolvedor
Regra de Negócio Requisito Funcional Analista de Requisitos
Matriz de Rastreabilidade - Prováveis fontes de conhecimento
21. Planejamento da Gerência de
Requisitos
Primeiro estágio da gerência de requisitos.
Deve ser decido sobre:
●Identificação dos Requisitos
●Estados dos Requisitos
●Processo de Gerenciamento de Mudanças
●Políticas de Rastreamento
●Ferramentas CASE
22. Planejamento da Gerência de
Requisitos
Uma vez avaliado o impacto e custo da mudança, decisões
gerencias devem ser tomadas e podem estar apoiadas em
políticas definidas no planejamento:
●Requisitos devem ser adiados?
●Será necessário alocar mais pessoas para o projeto?
●Será necessário realizar horas extras por um período?
●Será adiado o prazo de modo a acomodar os novos
requisitos?
●Será deixada, de forma consciente, menor qualidade
daquela esperada para manter o prazo?
23. Planejamento da Gerência de
Requisitos
●As mudanças propostas foram cuidadosamente avaliadas
por todos os envolvidos?
●As decisões sobre a incorporação dessas mudanças foram
tomadas pelas pessoas apropriadas?
●As mudanças foram comunicadas a todos os interessados?
24. Ferramentas para Gerência de
Requisitos
Benefícios no uso de ferramentas:
●Gerenciar versões e alterações
●Armazenar atributos dos requisitos
●Facilidade na análise de impacto
●Rastrear o status do requisito
●Controle de acesso
●Comunicação com stakeholders
●Reutilização de requisitos
25. Ferramentas para Gerência de
Requisitos
Esses produtos são classificados como ferramentas de
gerenciamento de requisitos e não como ferramentas de
desenvolvimento de requisitos.
26. Ferramentas para Gerência de
Requisitos
Estas ferramentas não substituem um processo definido que
os membros da equipe seguem para elicitar e gerenciar
requisitos.
É sugerido usar uma ferramenta quando já se tem uma
abordagem que funciona mas que requer maior eficiência pois
uma ferramenta não compensa a falta de processo, disciplina,
experiência e entendimento.
27. Ferramentas para Gerência de
Requisitos
Exemplos de ferramentas:
IBM Rational RequisitePro
Borland CaliberRM
HP Quality Center
41. Referências (3 de 3)
MAGELA, Rogério. Engenharia de Software Aplicada:
fundamentos. Rio de Janeiro: Alta Books, 2006.
SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São
Paulo: Pearson Addison Wesley, 2003.
TIGRIS. Software requirements management tools. Disponível
em: <http://requirements.tigris.org/>. Acesso em: 01/05/2010.
WIEGERS, Karl E. Software Requirements. 2ª ed.
Washington, USA: Microsoft Press, 2003.