Engenharia

Inserir TítulodeAqui
Requisitos
Inserir Título Aqui
Análise e Gestão de Requisitos

Responsável pelo Conteúdo:

Prof. Me. Afonso Maria Luiz Rodrigues Pavão

Revisão Textual:
Prof.ª Me. Sandra Regina F. Moreira
 Análise e Gestão de Requisitos

Nesta unidade, trabalharemos os seguintes tópicos:

• Análise de Requisito;
• Verificação de Requisitos;
• Validação de requisitos;

Fonte: iStock/Getty Images

• Gestão de Requisitos;
• Gerência de Escopo.

Objetivos
• Compreender as etapas necessárias para a determinação de requisitos de software
com qualidade.

Caro Aluno(a)!

Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o
último momento o acesso ao estudo, o que implicará o não aprofundamento no material
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.

Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns
dias e determinar como o seu “momento do estudo”.

No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões

de materiais complementares, elementos didáticos que ampliarão sua interpretação e
auxiliarão o pleno entendimento dos temas abordados.

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de
troca de ideias e aprendizagem.

Bons Estudos!
UNIDADE
Análise e Gestão de Requisitos

Contextualização
Para iniciarmos os estudos sobre a gestão de requisitos, quero propor-lhe uma
reflexão sobre as falhas e erros que você já viu (ou ouviu) acontecerem.

A partir desta reflexão, convido você a analisar quantas ações poderiam ter sido
executadas de modo a evitar que ocorressem as falhas e os prejuízos identificados.

E não apenas quanto à coleta de requisitos, como também relativas a seus controles
e gerenciamento.

Observe quanto desperdício ocorre no processo de desenvolvimento de um software,

mesmo com a utilização de técnicas consagradas ou identificadas como as melhores
práticas, e com a aplicação de ferramentas de controle e de gestão de requisitos.

Acesse os sites e assista aos vídeos que sugerimos no item “material complementar”
e tome conhecimento de alguns s disponíveis no mercado que colaboram com a gestão
de requisitos (indicados nesse mesmo item).

A área de tecnologia de informação vem tentando trazer valor agregado aos negócios,
mas ainda hoje, uma “simples” modificação em um requisito, ou um requisito mal
compreendido, ganha tamanha relevância e gera inúmeros prejuízos a uma empresa.

É tempo mais que suficiente para buscarmos reverter esta situação.

6
Análise de Requisitos
A análise de requisitos é fundamental para o processo de desenvolvimento de siste-
mas porque visa descobrir as necessidades do usuário e identificar as operações que o
sistema deverá realizar, além das restrições destas operações.

Após a obtenção (ou elicitação) dos requisitos, é necessário que seja feita sua análise
para averiguação da coleta de dados e atualizar-se sua documentação.

Alguns autores consideram a análise de requisitos como sendo o processo de des-

cobrir, analisar, documentar e verificar serviços requeridos para um sistema e suas
restrições operacionais.

Sommerville (2011) afirma que engenheiros de software, clientes, usuários finais

e demais envolvidos (stakeholders) devem entender com exatidão os requisitos sobre:
• O domínio da aplicação;
• Quais serviços e funcionalidades o sistema deve fornecer;
• O desempenho esperado; e
• As restrições de hardware, do ambiente e do negócio.

Como se sabe, muitas dificuldades surgem durante a coleta de dados, e as origens

são diversas:
• Stakeholders não sabem ou não expressam o que querem do sistema;
• Stakeholders expressam requisitos usando seus próprios termos (domínio);
• Diferentes stakeholders têm diferentes requisitos;
• Fatores políticos podem influenciar (ex.: mais poder a um gerente);
• Ambiente é dinâmico e muda frequentemente; e
• Novos requisitos podem surgir de novos stakeholders.

Entende-se que a engenharia de requisitos deva ser um processo interativo, cíclico

e que envolve as seguintes atividades:
• Obtenção de requisitos (coleta de dados);
• Classificação e organização de requisitos;
• Priorização e negociação de requisitos; e
• Documentação de requisitos.

A análise de requisitos tem como pressuposto básico identificar:

• Problemas, inconsistência ou requisitos incompletos;
• Descobrir interações entre os requisitos; e
• Apresentar e informar conflitos e sobreposições.

7
7
UNIDADE
Análise e Gestão de Requisitos

Um aspecto importante é verificar se realmente aquele requisito é necessário, pois

em alguns casos, alguns requisitos podem não contribuir com os objetivos de negócio
da organização, ou para o problema específico que será tratado pelo sistema.

Também se deve verificar se, apesar de válido, é viável manter aquele requisito.
Isto visa garantir sua permanência (ou não) conforme tecnologia, orçamento e tempo
disponível para o desenvolvimento do sistema.

Os requisitos também devem ser verificados entre si para se identificar sua consis-
tência, e se contêm todos os elementos necessários e, portanto, se sua integralidade
está garantida.

A consistência significa que os requisitos não podem ser contraditórios entre si. Ou
seja, se uma informação não fica invalidada por qualquer motivo, ou ainda, por outra
informação, de outro stakeholder, por exemplo.

Quanto à completude, a análise de requisito visa identificar se nenhum serviço (ou

restrição) está incompleto ou foi esquecido ao longo do tempo.

Caso sejam identificadas, as divergências devem retornar aos stakeholders para

esclarecimentos e solução (chamada também de negociação).

A atividade de análise de requisitos deve ser normalmente praticada simultaneamente

com sua obtenção.

A figura abaixo ilustra esse processo.

Análise de Requisitos

Checagem da Checagem de Checagem de

Consistência e
Necessidade Completude Viabilidade

Requisitos Requisitos Incompletos Requisitos

Desnecessários e Conflitantes Inviáveis

Discussão Priorização Acordo de

de Requisitos de Requisitos Requisitos

Negociação de Requisitos

Figura 1 – Análise e Negociação de Requisitos

Note que, na prática, a “negociação” – termo utilizado para designar se o(s) requisitos(s)
deverá(ão) ou não permanecer no projeto de software – é com frequência aplicada, pois
questões técnicas ou comportamentais estarão sempre envolvidas.

8
 Independente disto, pode-se preparar uma lista de verificação para ser usada na análi-
se dos requisitos. A partir dessa lista, e não necessariamente com ela, é possível identifi-
car se todo conhecimento acumulado na pesquisa está correto, completo ou consistente,
conforme se vê na sequência.

Busca-se verificar se:

• O projeto é prematuro, ou seja, se os requisitos têm informação imatura para o
projeto ou para a implementação;
• Há requisitos combinados: se a descrição do requisito é única, ou o mesmo pode
ser desmembrado em mais requisitos;
• Os requisitos são realmente e, de fato, necessários;
• Será necessário o uso de hardware não padronizado – e os requisitos implicam em
algum hardware diferenciado. Essa decisão pode exigir outro tipo de conhecimento;
• Os requisitos estão em conformidade, ou estão consistentes com os objetivos de negócio;
• Há ambiguidade nos requisitos, ou se o mesmo o requisito pode ter interpretação
diferente por diferentes pessoas – stakeholders ou usuários.
• Os requisitos são realísticos com a tecnologia disponível, e se esta é adequada para
a implementação daquele requisito.
• Os requisitos foram escritos de forma a poderem ser testados para determinar se o
sistema irá satisfazê-los.

Em outras palavras, a nível macro os revisores devem garantir que a especificação

esteja completa, consistente e precisa. Então deve ser questionado se:
• As metas e objetivos do software são consistentes e coerentes com as metas e os
objetivos da empresa;
• O fluxo e a estrutura de informação estão adequadamente definidos para o domínio
da informação necessária;
• A modelagem, em casos de uso ou em outra representação, está clara;
• Todas as interfaces importantes foram adequadamente descritas para todos os
elementos do sistema;
• As funções consideradas essenciais e importantes ainda permanecem no escopo;
• Essas funções foram escritas adequada e corretamente;
• O comportamento esperado do software está consistente com os dados a serem
processados e as funções que o mesmo deve executar;
• As restrições encontradas e definidas para o projeto são realistas;
• Há – e, se houver, qual é o risco tecnológico para o desenvolvimento do software;
• Os requisitos de software alternativos foram considerados até serem esgotadas
todas as possibilidades;
• Os critérios de validação foram declarados detalhadamente;

9
9
UNIDADE
Análise e Gestão de Requisitos

• Esses critérios são adequados para descrever um sistema bem sucedido;

• Existem inconsistências, omissões ou redundâncias;
• As estimativas do plano de projeto de software foram afetadas, e como foram.

Já no nível detalhado, os revisores devem se preocupar com o enunciado da especi-

ficação. Esta etapa deve descobrir problemas que podem estar ocultos na especificação.
Suas diretrizes devem ser para:
• Estar alerta para perceber conectivos persuasivos (certamente, claramente, obvia-
mente) e perguntar por que eles estão presentes;
• Procurar termos vagos e pedir esclarecimento (algum, às vezes, usualmente,
frequentemente);
• Evitar o uso de “etc.”, “tal como” ou “assim por diante”, quando houver listas que
não estejam completas;
• Ter certeza de que limites declarados não contenham pressuposições não declaradas
do tipo “os códigos válidos variam de 0 a 100” - números inteiros ou reais;
• Evitar verbos vagos, pois há muitas formas de interpretá-los: manuseado,
rejeitado, pulado;
• Evitar pronomes “pendentes” ou dúbios, como por exemplo: o módulo I/O se comunica
com o de validação de dados e seu sinal de controle está ligado (qual módulo?);
• Procurar declarações que impliquem certeza (sempre, cada, todos, nunca) e depois
queira-se prova disto;
• Evitar usar outros conceitos para um mesmo termo, ou seja, se um termo for de-
finido num lugar, deve-se evitar usar outro que possa ter o mesmo sentido, como
documento ou arquivo;
• Verificar se há gráficos ou figuras que possam auxiliar a compreensão caso uma
estrutura descrita em palavras não seja suficiente para seu entendimento;
• Elaborar ao menos dois exemplos com algoritmos, caso seja especificado um cálculo.

A análise de requisitos deverá evitar os tão conhecidos erros de projeto. Sua impor-
tância alcança até o gerenciamento de projetos, pois na engenharia de requisitos ela (a
análise) é a responsável por obter os dados indispensáveis para solucionar os problemas
dos usuários e ajudá-los a alcançar seus objetivos.

Para o IEEE (1990), a análise de requisitos é o processo que estuda as necessidades

do usuário para validar o produto final, estabelecendo o elo final de ligação entre o
cliente e o fornecedor do software. É ela que vai determinar o sucesso ou o fracasso do
projeto, já que a comunicação e o envolvimento constante com os usuários irão influen-
ciar no resultado final do produto.

10
Verificação de Requisitos
A equipe de interessados e envolvidos no projeto de software lê, analisa os requisitos
e procura problemas, erros, omissões, incongruências, falhas ou situações descritas que
não estejam de acordo com o escopo do projeto, se reúne, discute estas situações,
negocia e concorda com as ações para tratá-las.

As atividades de obtenção, análise, verificação e validação de requisitos estão intima-

mente ligadas. Por isso alguns autores tratam desses conceitos de forma simultânea, e
consideram que a revisão contem as atividades de análise, de verificação e de validação.

Para Pfleeger (2004), a revisão de requisitos deve:

• Rever metas e objetivos estabelecidos para o sistema;
• Descrever o ambiente operacional;
• Examinar:
»» interfaces
»» fluxo de informações
»» funções
• Comparar requisitos, metas e objetivos;
• Verificar omissões, imperfeições e inconsistências;
• Documentar riscos; e
• Discutir sobre como o sistema será testado.

Para a verificação, as seguintes atividades devem ser executadas:

• Planejar a revisão, selecionando a equipe, a hora e o local para sua ocorrência;
• Distribuir os documentos de requisitos para todos os membros participantes;
• Os revisores devem preparar-se para a revisão, lendo os requisitos e assinalando
suas dúvidas e suas observações sobre conflitos, omissões, inconsistências, desvios,
e todo questionamento que se queira esclarecer;
• Realizar a reunião de forma que todas as dúvidas individuais sejam discutidas e que
seja gerada concordância para o conjunto de ações que irá tratá-las;
• Ações para acompanhamento das revisões sugeridas, de forma que seu respon-
sável possa verificar se estas foram executadas conforme todas as ações que
foram acordadas;
• Revisar o documento de requisitos para refletir as ações acordadas, podendo ou
não ocorrer nova revisão.

11
11
UNIDADE
Análise e Gestão de Requisitos

A coordenação do projeto deve convocar para a(s) reunião(ões) os colaboradores e

envolvidos de forma que:
• Dentre os revisores se incluam stakeholders com backgrounds diferentes, porque
seus conhecimentos e habilidades contribuem para a revisão;
• A participação dos stakeholders que se envolvem no processo possa ajudar no
entendimento das necessidades de outros stakeholders;
• Existam no time de revisores ao menos um especialista no domínio e um usuário
final independente.

Os critérios mais adequados para a atividade de revisão devem exigir que nos requisitos
sejam verificadas a existência de:

• Ambiguidade • Completude
• Conformidade a padrões • Consistência
• Entendimento • Organização
• Rastreamento • Redundância

Isto é importante porque, por mais cuidado que os desenvolvedores tenham com
as especificações dos requisitos, não há garantias de que estas estejam completas e
corretas. Além disso, elas pode ser por eles revistas diversas vezes e não se identificar
falha alguma.

Principalmente por esse motivo, é que as especificações devem ser revisadas por
outras pessoas – inclusive por aquelas não envolvidas no projeto, para maior isenção em
sua opinião.

Validação de Requisitos
Quanto à validação de requisitos, seus objetivos devem ser para certificar-se de que o
documento de requisitos é uma descrição correta e aceitável do sistema a ser desenvol-
vido, verificando-se suas propriedades.

Estudo Elicitação e análise

da viabilidade de requisitos
Especificação
de requisitos
Relatório Validação
de viabilidade de requisitos
Modelos
de sistema
Requisitos de usuários
e de sistema

Documentação
de requisitos

Figura 2 – Validação de Requisitos

12
 Observe a figura 2 e note que a análise de viabilidade também está incluída no ciclo
de validação. Note que também na figura 1 a análise de viabilidade é citada.

A verificação de requisitos, assim como sua validação, envolvem antes uma profunda
análise de seu teor, e apesar de alguns autores colocarem a verificação e a validação num
mesmo patamar, resolvemos separá-las, pois entendemos que validar é mais importante
que verificar, conforme explicamos na sequência com o que identificamos em alguns
dicionários eletrônicos disponíveis.

A verificação é, de acordo com “Aurélio”, o ato ou efeito de verificar, averiguação,

enquanto que para “Michaelis”, é a realização de algo previsto.

O dicionário de “Sinônimos” caracteriza verificação como sendo uma averiguação,

investigação, ou uma apuração, e o outro dicionário – o “Dicio”, define que verificação,
trata de averiguação ou comprovação.

A validação, por sua vez, para “Aurélio”, é tornar ou declarar algo válido, e para
“Michaelis” é uma declaração de validade.

O “Sinônimos” conceitua validação como sendo aceitação, aprovação ou confirmação,

e o “Dicio” a caracteriza como aceitação, aprovação, confirmação, ou tornar algo válido.

A verificação usa dados obtidos dos stakeholders do sistema e sua questão básica é
saber se a equipe tem os requisitos certos.

A validação usa uma versão menos informal e mais final do documento de requisitos
que foram negociados e acordados e, nesta fase, a questão chave é saber se os requisitos
disponíveis estão certos.

Para a validação dos requisitos são utilizados:

• O documento oficial de requisitos, que deve estar na sua versão completa, formatada
e organizada conforme os padrões da instalação;
• O conhecimento organizacional, que é o conhecimento frequentemente implícito,
da organização, e que poderá ser usado para julgar o realismo dos requisitos; e
• Os padrões organizacionais, usados para organizar oficialmente o documento
de requisitos.

Igualmente, na verificação, são gerados alguns artefatos:

• A lista de problemas, com a relação dos problemas descobertos no documento de
requisitos; e
• As ações acordadas, que é uma lista de ações que ficaram acertadas em resposta
aos problemas detectados. Alguns destes problemas podem gerar várias ações
corretivas, e outros podem não ter qualquer ação associada.

As atividades devem ainda ser para a:

• Verificação de validade;
• Verificação de consistência;

13
13
UNIDADE
Análise e Gestão de Requisitos

• Verificação de clareza;
• Verificação de realismo; e
• Facilidade de verificação.

Por outro lado, as validações podem ser feitas por meio de técnicas, tais como:
• Geração de casos de teste, com testes específicos, análise de consistência automática
ou avaliar apenas uma especificação;
• Prototipação, incluindo um modelo “executável” (ou interfaces) do sistema;
• Revisão de requisitos, com a análise manual sendo sistemática;
• Reusando domínios já conhecidos e efetivos;
• Usando o princípio de “pontos de vista” de stakeholders; ou
• Validação mediante o uso de outros modelos.

Para Vazquez (2016), as validações podem ser feitas mediante a utilização de:
• Casos dos usuários;
• Modelagem de processos;
• Decomposição funcional;
• Modelagem de domínio;
• Modelagem dos Casos de Uso;
• Listas de verificação; ou
• Prototipação.

Outra técnica usada durante as revisões técnicas formais – RTF – é o checklist e visa
garantir a qualidade do software mediante:
• A descoberta de erros de função, lógica ou codificação;
• A verificação de que o software atende aos requisitos especificados;
• A garantia de que o software foi representado conforme padrões previamente definidos;
• A garantia de que o software foi desenvolvido uniformemente; e
• O desenvolvimento de projetos mais facilmente gerenciáveis.

A etapa de validação pode ocorrer em momentos específicos durante o desenvolvi-

mento e apoia-se no conhecimento dos avaliadores naquele momento.

Durante a engenharia de requisitos, os stakeholders adquirem novos conhecimentos

sobre o sistema em projeto, sendo exímios colaboradores nessa etapa.

Mas não significa, de fato, que uma validação positiva de requisitos garanta que os
mesmos continuarão sendo válidos posteriormente.

14
 Entendemos que a validação de requisitos poderia ser feita diversas vezes se:
• No projeto houver muitas ideias e tecnologias inovadoras;
• Durante a fase de engenharia de requisitos houver acréscimo significativo no conhe-
cimento dos envolvidos;
• O projeto tiver longa duração;
• A validação de requisitos anterior foi realizada muito cedo;
• O domínio do problema seja desconhecido; e
• Houver a reutilização de requisitos.

Portanto, a validação de requisitos visa demonstrar que eles definem o sistema que
realmente o cliente deseja, e que estão conforme foi definido.

Vale lembrar novamente que, os custos resultantes de erros em requisitos são muito
altos, o que torna sua validação muito importante. Estimam-se que o custo da reparação
de um erro após a entrega de um software pode chegar a cem vezes mais que o custo
de reparação de um erro na fase de implementação.

Gestão de Requisitos
A gestão de requisitos refere-se a um processo de gerenciamento de suas mudanças
durante o processo de engenharia de requisitos e o desenvolvimento de sistema.

Os requisitos de um software inevitavelmente são incompletos e inconsistentes pois

novos requisitos surgem:
• Durante o processo de sua elicitação;
• À medida que as necessidades de negócio mudam;
• Conforme é desenvolvida uma melhor compreensão do projeto;
• Quando os diferentes pontos de vista têm requisitos diferentes e estes são contraditórios.

A partir daí, é necessário de seja feita uma boa gestão de mudanças de requisitos, pois:
• A priorização dos requisitos muda em decorrência das mudanças de pontos de vista
durante o processo de desenvolvimento;
• O ambiente técnico e o de negócio do sistema mudam durante o desenvolvimento;
• Os clientes do sistema podem especificar requisitos a partir de perspectiva de
negócio que conflite com os requisitos do usuário final.

15
15
UNIDADE
Análise e Gestão de Requisitos

Devido a esses principais motivos, a utilização de um processo formal para a gestão de

mudanças deve garantir que todas as propostas de alterações de requisitos sejam tratadas
consistentemente, e que as alterações no documento de requisitos sejam controladas.
Analogamente, deve permitir também a análise do impacto dessas mudanças.

São três os estágios do processo de gerenciamento de requisitos:

• Fazer-se a análise do problema e a especificação da mudança;
• Efetuar a análise da mudança e a estimativa do custo para realizá-la;
• Executar a implementação da mudança.

A figura 3 apresenta a amplitude da engenharia de requisitos e a figura 4, da gestão

de requisitos.

Engenharia de Requisitos

Produção de Requisitos Gerência de Requisitos

• Levantamento • Controle de Mudanças
• Registro • Gerência de Configuração
• Validação • Rastreabilidade
• Gerência da Qualidade
• Verificação de Requisitos

Figura 3 – Engenharia de Requisitos

Elicitação dos Requisitos

Gerenciamento dos Requisitos

Análise e Negociação
dos Requisitos

Documentação
dos Requisitos

Verificação dos Requisitos

Validação dos Requisitos

Figura 4 – Gestão de Requisitos

16
 A figura 4 apresenta claramente que, na prática, a gestão de requisitos é um processo
cíclico e ininterrupto, que se inicia já na fase de obtenção de dados.

Uma mudança em requisitos pode implicar em alterações em um ou mais modelos

subsequentes do software. Por isso, apenas aquelas autorizadas podem ser efetua-
das, ainda que a gestão de mudanças nos requisitos deva ocorrer em todas as que
forem propostas.

O gerenciamento das mudanças para se controlar as etapas acima envolve fazer a:

• Identificação da baseline de requisitos;
• Restrição de mudanças;
• Auditoria das mudanças.

Uma baseline, ou linha base, é uma “imagem” de uma versão de cada artefato no re-
positório do projeto e funciona como um padrão oficial básico para os demais trabalhos
subsequentes. Uma baseline de requisitos é uma versão de sua especificação e contém
um conjunto definido de itens de configuração, que poderão servir, inclusive, como mar-
cos no processo de desenvolvimento do software.

Esses itens também irão colaborar com outra gestão – a de configuração de software,
para que esta possa definir critérios que permitam realizar as modificações solicitadas,
mantendo-se a consistência e a integridade do software com as novas especificações.

Gerência de Escopo
O gerenciamento de escopo do projeto deve considerar a:
• Própria mudança, pois deverá ser feito um planejamento para sua acomodação, e
isto tem um custo, e precisa ter um prazo;
• Revisão de requisitos para se evitar conflitos. Os stakeholders devem ser questionados,
para se obter sua concordância se eles especificaram qualquer alteração em um requisito.

O escopo de um projeto é definido pelo conjunto de requisitos a ele alocados, e,

portanto, para que esse projeto se adeque aos recursos disponíveis (tempo, pessoas e
dinheiro) é primordial o gerenciamento eficaz do escopo.

Isso significa garantir que o projeto não excederá os requisitos necessários, o orça-
mento planejado e o prazo estabelecido.

A gerência de escopo é feita com os detalhes do fluxo de trabalho que visam:

• Priorizar e refinar informações fornecidas para a seleção das características e dos
requisitos a incluir;
• Listar os casos de uso (ou cenários) representativos de alguma funcionalidade;
• Definir quais atributos, requisitos e rastreabilidades serão mantidos.

17
17
UNIDADE
Análise e Gestão de Requisitos

A rastreabilidade é definida como sendo a habilidade para se acompanhar a vida de

um requisito, seja partindo do requisito e chegando ao projeto, ou vice-versa, e durante
todo seu ciclo de vida.

A dificuldade da rastreabilidade é o grande volume de informações que é gerado.

Estas informações relativas ao processo de requisitos devem ser catalogadas e associadas
a outros elementos, de forma a serem referenciadas através dos diversos itens de
informação registrados.

Para facilitar, pode-se elaborar um artefato, a matriz de rastreabilidade, junto com a es-
pecificação de requisitos, cujo objetivo é mapear os requisitos descritos na sua especificação.

A rastreabilidade dos requisitos, e de suas mudanças, referem-se aos relacionamentos

entre os requisitos, suas fontes e o projeto de sistema, podendo ser rastreabilidades:
• Da fonte, ou seja, onde se associam os requisitos aos stakeholders que os propuseram;
• Dos requisitos, que trata da ligação dos requisitos dependentes; e
• De projeto, pois associam os requisitos aos módulos de projeto.

A gestão do escopo – e a gestão de requisitos – devem atuar durante todo o processo

da engenharia de requisitos porque deve(m) ser planejados(as):
• A identificação dos requisitos, e como deverão ser identificados individualmente;
• O gerenciamento das mudanças e qual deverá ser o processo a seguir a partir da
análise de uma mudança em requisitos;
• As políticas de rastreabilidade, a qualidade e a quantidade de informações a serem
mantidas sobre os relacionamentos de requisitos; e
• Avaliar e, preferencialmente, fazer o uso do apoio de ferramentas CASE.

Assim, esse conjunto de técnicas denominadas gestão possibilita minimizar os efeitos

negativos das alterações tão comuns nos requisitos de um software durante o processo
de seu desenvolvimento.

18
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Sites
Engenharia de Software - introdução à engenharia de requisitos
DEVMEDIA. Engenharia de Software - introdução à engenharia de requisitos.
https://goo.gl/8msNxk
Requirements management
GODA, Software. Requirements management
https://goo.gl/6GDPmD
What is requirements management?
https://goo.gl/t7FUd7
The most affordable, flexible & powerful requirements management tools
https://goo.gl/89YJer
Modern Requirements4TFS – easy, eficiente, essential
https://goo.gl/RKQe8C
Open source Requirements management.
https://goo.gl/SNjHsd

Vídeos
Requirements management - meaning, definition, explanation.
https://youtu.be/QVVuCj4GTWE
Agile Requirements Management Best Practices
https://youtu.be/HQizMS04A7s
Requirements Management
https://youtu.be/RyafVhLHNxs
Controle de Versão de Requisitos de Software
https://youtu.be/uZdXQe-NYFQ
Requirements Management
https://youtu.be/t4PRpQ5xAC4

19
19
UNIDADE
Análise e Gestão de Requisitos

Referências
AUDIOPEDIA. Requirements management - meaning, definition, explanation.
Disponível em: https://www.youtube.com/watch?v=QVVuCj4GTWE, último acesso
em 09/04/2018.

DEVMEDIA. Engenharia de Software - introdução à engenharia de requisitos.

Disponível em: https://www.devmedia.com.br/artigo-engenharia-de-software-
introducao-a-engenharia-de-requisitos/8034, último acesso em 10/04/2018.

GODA, Software. Requirements management. Disponível em: http://analysttool.

com/requirementsmanagement, último acesso em 09/04/2018.

HÖRÖMPÖLY, Bem. Agile requirements management best practices. Disponível

em: https://www.youtube.com/watch?v=HQizMS04A7s, último acesso em
09/04/2018.

IT METRICS & PRODUCTIVITY INSTITUTE. Requirements management best

practices. Disponível em: https://www.youtube.com/watch?v=RyafVhLHNxs, último
acesso em 09/04/2018.

VENTURA, Plinio. Engenharia de requisitos na real. Disponível em: https://www.

youtube.com/watch?v=uZdXQe-NYFQ, último acesso em 09/04/2018.

Requirements management. Disponível em: https://www.youtube.com/

watch?v=t4PRpQ5xAC4. último acesso em 09/04/2018.

20