Negociação, Gerenciamento e Validação de Requisitos

Prévia do material em texto

7ºAula
Negociação, gerenciamento e 
validação de requisitos
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
•	 saber da importância da negociação de requisitos;
•	 entender como funciona o gerenciamento de requisitos;
•	 conhecer uma noção básica de como é a validação de requisitos.
Olá, pessoal, tudo bem? 
Estamos chegando ao final da nossa disciplina. Nesta aula, 
vamos nos aprofundar em três tarefas muito importantes para 
a Engenharia de Requisitos: a negociação de requisitos, que 
permite que os stakeholders selecionem o que será desenvolvido, 
o gerenciamento de requisitos, que é o processo de construir 
um processo de gerenciamento de requisitos, e a validação de 
requisitos, que como seu nome diz, é a etapa encarregada de 
validar os requisitos.
Sempre lembrando que estaremos a sua disposição na sua 
área do aluno, para eventuais dúvidas.
Bons estudos!
Engenharia de Requisitos 50
Seções de estudo
1 - Negociação de Requisitos
2 - Gerenciamento de Requisitos
3	-	Verificação	e	Validação	de	Requisitos
1 - Negociação de Requisitos
Você viu, na aula 01, que a negociação de requisitos é a 
etapa onde é feita a priorização de requisitos. Isso é necessário 
para o andamento e o sucesso do projeto, pois um escopo mal 
delineado pode causar fracasso no processo de 
desenvolvimento de software. Isso é explicitado por 
Zanlorenci e Burnett:
No contexto do negócio, os assuntos 
organizacionais e fatores políticos podem 
influenciar	 nos	 requisitos.	 Nas	 organizações,	
a	 luta	 pelo	 poder	 e	 relações	 de	 influência	
entre	 diferentes	 pessoas	 dificultam	 um	
denominador comum quanto à propriedade 
da	informação	e	a	definição	da	melhor	forma	
de administrá-la. Cabe aí uma negociação 
cuidadosa e a delimitação de fronteiras, com o 
estabelecimento de objetivos, o entendimento 
do histórico e estrutura organizacional e 
a própria organização do conhecimento. 
(ZANLORENCI; BURNETT, s.d.)
Então, como podemos fazer a negociação de requisitos? 
Podemos	 usar	 métodos	 simples,	 como	 a	 definição	 por	
consenso, quando todas as partes precisam aceitar uma 
questão	ou	pela	definição	por	maioria,	quando	é	necessário	a	
maioria aceitar os requisitos. 
Tabela 1 - Alguns pontos comparativos entre consenso e voto maioritário 
Consenso Voto Maioritário
Promove cooperação Promove competição
Todos os stakeholders têm o 
mesmo poder de decisão
O poder de decisão 
corresponde a hierarquia, 
popularidade etc.
Os stakeholders concordam 
ou não concordam
Os stakeholder votam contra, 
a favor ou abstém-se
Todas as ideias são ouvidas e 
exploradas
A maioria decide quais as 
ideias a serem consideradas.
Fonte: raMirES, 2004.
Há outros métodos para isso, como o QFD, onde os 
stakeholders comparam ao requisito e seu potencial de 
resolver a solução.
Mas cabe ao analista de requisitos escolher a melhor 
forma de fazer essa negociação. Pressman e Maxim (2016) 
afirmam	 que	 não	 existem	 ganhadores	 e	 nem	 perdedores	
em uma negociação efetiva. Todos ganham, pois é feito um 
acordo entre ambas as partes.
2 - Gerenciamento de Requisitos
Quando um sistema já está pronto para uso, não é sinal 
que o trabalho terminou. Um sistema é algo vivo, que sofre 
muitas mudanças ao longo da sua existência. Sommerville 
(2011) cita alguns exemplos de situações que podem acarretar 
em mudanças de sistema:
•	 Após a instalação, o ambiente técnico e de negócios 
do sistema sempre muda. Um novo hardware pode 
ser introduzido. Pode ser necessário fazer a interface 
do sistema com outros sistemas, as prioridades 
do negócio podem mudar (com consequentes 
alterações necessárias no apoio do sistema), podem 
ser introduzidas novas legislações e regulamentos 
aos quais o sistema deve, necessariamente, respeitar 
etc.
•	 As pessoas que pagam por um sistema e os usuários 
desse sistema raramente são os mesmos. Clientes 
do sistema impõem requisitos devido a restrições 
orçamentárias e organizacionais, os quais podem 
entrar	 em	 conflito	 com	 os	 requisitos	 do	 usuário	
final,	e,	após	a	entrega,	novos	recursos	podem	ser	
adicionados,	para	dar	suporte	ao	usuário,	a	fim	de	
que o sistema cumpra suas metas.
•	 Geralmente, sistemas de grande porte têm uma 
comunidade de diversos usuários, com diferentes 
requisitos	e	prioridades,	que	podem	ser	conflitantes	
ou	contraditórios.	Os	requisitos	do	sistema	final	são,	
certamente, um compromisso entre esses usuários, 
e, com a experiência, frequentemente se descobre 
que o balanço de apoio prestado aos diferentes 
usuários precisa ser mudado.
É por estas situações que um projeto de software deve 
aceitar	novos	requisitos	ou	modificar	requisitos	já	existentes.	
Assim, devemos ter em mente alguma estratégia de gestão de 
requisitos. 
Sommerville	 (2011,	 p.	 78)	 define	 gerenciamento	 de	
requisitos como: “o processo de compreensão e controle das 
mudanças	nos	requisitos	do	sistema”.	Já	Coelho	(2014)	afirma	
que “o conjunto de atividades que auxilia a equipe do projeto 
a	identificar,	controlar	e	rastrear	os	requisitos,	bem	como	as	
alterações nos requisitos em muitos momentos do projeto. 
Em outras palavras, é o processo que gerencia mudanças nos 
requisitos de um sistema. Essas mudanças ocorrem conforme 
os clientes desenvolvem um melhor entendimento de suas 
reais necessidades”.
Podemos dividir o gerenciamento de requisitos em duas 
atividades, sendo o gerenciamento de requisitos propriamente 
dito, que ocorre durante o processo de modelagem do sistema 
e o gerenciamento de mudança de requisitos.
2.1 - Planejamento de 
Gerenciamento de Requisitos
Essa etapa determina o nível de detalhamento requerido 
no gerenciamento de requisitos. É a primeira etapa do 
gerenciamento de requisitos.
51
Nessa etapa, você deve decidir vários aspectos. Vários 
deles são elencados por Sommerville (2011):
•	 Identificação	de	requisitos.	Cada	requisito	deve	ser	
identificado	unicamente	para	poder	ser	comparado	
com outros requisitos e usado em avaliações de 
rastreabilidade.
•	 Processo de gerenciamento de mudanças. Esse é o 
conjunto de atividades que avaliam o impacto e o 
custo das mudanças. Na próxima seção, vou discutir 
detalhadamente esse processo.
•	 Políticas	 de	 rastreabilidade.	 Definem	 os	
relacionamentos entre cada requisito e entre os 
requisitos e o projeto de sistema que deve ser 
registrado. A política de rastreabilidade também 
deve	 definir	 como	 esses	 registros	 devem	 ser	
mantidos.
•	 Ferramenta de apoio. Gerenciamento de requisitos 
envolve o processamento de grandes quantidades 
de informações sobre os requisitos. Ferramentas 
que podem ser usadas variam desde sistemas 
especializados em gerenciamento de requisitos até 
planilhas e sistemas de banco de dados simples.
Coelho	 (2004)	 afirma	 que	 para	 definir	 esses	 aspectos,	
deve-se	 definir	 um	 conjunto	 de	 objetivos,	 para	 que	 esses	
objetivos	corroborem	nessas	regras	que	serão	definidas,	pois	
afinal	de	 contas,	os	 artefatos	que	 serão	elaborados	 servirão	
para dar transparência a gerência do sistema.
Para facilitar o processo de gerenciamento de requisitos, 
podem	 ser	 usados	 programas	 eletrônicos	 para	 esse	 fim,	
para facilitar o armazenamento, a gestão de mudanças de 
requisitos - veja a seção a seguir - e a rastreabilidade entre 
requisitos.
Agora veremos o gerenciamento de mudança de 
requisitos.
2.2 - Gerenciamento de Mudança 
de Requisitos
Depois, quando o documento de requisitos está pronto, 
pode ser que mudanças possam ocorrer no sistema, com o 
decorrer da descoberta de novas necessidades. Com isso, 
novos requisitos podem surgir.
Mas esses requisitos podem degradar o sistema se 
mal planejados. Para isso a necessidade do planejamento 
da	 mudança	 de	 requisitos,	 pois	 é	 definido	 um	 processo	
controlado, visando a atualizaçãoconstante nos artefatos do 
sistema e a inclusão de requisitos que apenas proporcionem 
vantagens ao sistema.
Sommerville (2011) cita três estágios principais nessa 
atividade:
•	 Análise	de	problema	e	especificação	de	mudanças.	
O processo começa com um problema de requisitos 
identificado	 ou,	 às	 vezes,	 com	 uma	 proposta	
específica	de	mudança.	Durante	esse	estágio,	analisa-
se	o	problema	ou	a	proposta	de	mudança	a	fim	de	
se	verificar	sua	validade.	Essa	análise	é	transmitida	
a quem solicitou a mudança, que pode responder 
com	uma	proposta	mais	específica	de	mudança	de	
requisitos ou retirar a solicitação.
•	 Análise de mudanças e custos. O efeito da 
mudança proposta é avaliado por meio de 
informações de rastreabilidade e conhecimentos 
gerais dos requisitos do sistema. O custo de fazer 
a	mudança	é	estimado	em	termos	de	modificações	
no documento de requisitos e, se apropriado, no 
projeto e implementação do sistema. Uma vez que 
essa análise é concluída, decide-se prosseguir ou não 
com a mudança de requisitos.
•	 Implementação de mudanças. O documento 
de requisitos e, quando necessário, o projeto e 
implementação	do	sistema,	são	modificados.	Você	
deve organizar o documento de requisitos para 
poder fazer alterações sem ampla reformulação 
ou reorganização. Tal como acontece com os 
programas, a mutabilidade nos documentos é 
obtida minimizando-se as referências externas e 
tornando as seções do documento o mais modular 
possível. Assim, as seções individuais podem ser 
alteradas e substituídas sem afetar outras partes do 
documento.
Figura 1 - gerenciamento de Mudança de requisitos. Fonte: SOMMErViLLE, 2011, 
p. 79
Em metodologias ágeis, há uma lista de requisitos que 
devem ser implementados durante a construção do sistema. 
Quando ocorre uma mudança de requisitos, é discutida 
uma alteração na lista de prioridades, contemplando o novo 
requisito.
3	 -	 Verificação	 e	 Validação	 de	
Requisitos
Sommerville	 (2011)	 define	 a	 verificação	 e	 validação	
de	requisitos	como	“o	processo	pelo	qual	se	verifica	se	os	
requisitos	definem	o	sistema	que	o	cliente	realmente	quer.	
Ela se sobrepõe à análise, uma vez que está preocupada 
em encontrar problemas com os requisitos.” Vale lembrar 
que um erro descoberto na fase de construção ou após o 
sistema estar pronto, pode ser muito mais caro de 
consertar.
Várias validações podem ser feitas nessa etapa, como:
•	 Verificações	 de	 validade:	 Um	 usuário	 pode	
pensar que é necessário um sistema para executar 
determinadas	funções.	No	entanto,	maior	reflexão	
e	 análise	 mais	 aprofundada	 podem	 identificar	
funções necessárias, adicionais ou diferentes. Os 
sistemas têm diversos stakeholders com diferentes 
necessidades, e qualquer conjunto de requisitos é 
inevitavelmente um compromisso da comunidade 
de stakeholders.
Engenharia de Requisitos 52
•	 Verificações	 de	 consistência:	 Requisitos	 no	
documento	 não	 devem	 entrar	 em	 conflito.	Ou	
seja, não deve haver restrições contraditórias 
ou descrições diferentes da mesma função do 
sistema.
•	 Verificações	 de	 completude:	 O	 documento	 de	
requisitos	deve	incluir	requisitos	que	definam	todas	
as funções e as restrições pretendidas pelo usuário 
do sistema.
•	 Verificações	de	realismo:	Usando	o	conhecimento	
das tecnologias existentes, os requisitos devem ser 
verificados	 para	 assegurar	 que	 realmente	 podem	
ser	 implementados.	 Essas	 verificações	 devem	
considerar o orçamento e o cronograma para o 
desenvolvimento do sistema.
•	 Verificabilidade:	Para	reduzir	o	potencial	de	conflito	
entre o cliente e o contratante, os requisitos do 
sistema	 devem	 ser	 passíveis	 de	 verificação.	 Isso	
significa	 que	 você	 deve	 ser	 capaz	 de	 escrever	 um	
conjunto de testes que demonstrem que o sistema 
entregue	 atende	 a	 cada	 requisito	 especificado	
(SOMMERVILLE, 2011).
E,	 com	 isso,	 finalizamos	 a	 nossa	 penúltima	 aula.	 Na	
próxima aula, vamos mostrar para você o modelo do 
seu Documento de Requisitos.
Retomando a aula
 
Chegamos	ao	final	da	nossa	penúltima	aula.	Vamos	
recordar os pontos principais?
1 - Negociação de Requisitos
A negociação de requisitos é a etapa em que os 
stakeholders	definem	o	que	será	feito	no	sistema	e	o	que	será	
priorizado na construção do sistema. Essa negociação pode 
ser	 feita	usando	consenso,	maioria,	ou	métodos	específicos	
como o QFD.
2 - Gerenciamento de Requisitos
É	a	etapa	onde	é	definida	uma	estratégia	para	gestão	
e para a manutenção dos requisitos. Essa etapa é crucial, 
pois permite uma segurança no desenvolvimento do 
sistema.
3 - Verificação e Validação de Requisitos
É o processo pelo qual se verifica se os requisitos 
definem o sistema que o cliente realmente quer. 
Várias validações são feitas durante essa fase, como 
verificações de validade, verificações de consistência, 
verificações de realismo, verificações de completude e 
verificabilidade.
Vale a pena
CDEBASTIANI, Carlos Alberto. Definindo Escopo em 
Projetos de Software. São Paulo: Novatec, 2015.
ENGHOLM JR, Hélio. Engenharia de Software na Prática. 
São Paulo: Novatec, 2010.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia 
de Software:	Uma	abordagem	profissional.	8	ed.	Porto	Alegre:	
Bookman, 2016. 
RAMIRES, João Jorge da Costa Vieira. 
NEGOCIAÇÃO DE REQUISITOS NO PROCESSO DE 
DESENVOLVIMENTO DE SOFTWARE. 2004. 197 f. 
Dissertação (Mestrado) - Curso de Informática, Faculdade 
de Ciências, Universidade de Lisboa, Lisboa, 2004. 
Disponível em: <http://www.di.fc.ul.pt/~paa/reports/
T13.pdf>. Acesso em: 15 mar. 2018.
SOMMERVILLE, Ian. Engenharia de Software. 9 ed. São 
Paulo: Pearson, 2011.
Vale a pena ler
COELHO, Jailton. Gerenciamento de Requisitos. [S.l.]: 
LeanTI, 2014. Disponível em: <http://www.leanti.com.br/
artigos/16/gerenciamento-de-requisitos.aspx>. Acesso em: 
15 mar. 2018.
MEDEIROS, Higor. As Etapas da Engenharia de 
Software. [S.l.]: DevMedia, s.d. Disponível em: <https://
www.devmedia.com.br/as-etapas-da-engenharia-de-
requisitos/30220>. Acesso em: 14 mar. 2018.
DESDOBRAMENTO da Função Qualidade (QFD). 
Blog da Qualidade, 2012. Disponível em: <http://www.
blogdaqualidade.com.br/desdobramento-da-funcao-
qualidade-qfd/>. Acesso em: 14 mar. 2018.
ZANLORENCI, Edna Pacheco; BURNETT, Robert 
Carlise. Engenharia de requisitos: processos e técnicas no 
contexto organizacional. [S.l.]: Bate Byte, s.d.. Disponível 
em: <http://www.batebyte.pr.gov.br/modules/conteudo/
conteudo.php?conteudo=601>. Acesso em: 15 mar. 2018.
Vale a pena acessar