Engenharia

de
Requisitos
Aula 2
Prof.: Dr. Osmam Brás de Souto
 Sumário
• Técnicas de elicitação de requisitos;
• Etapas de preparação para elicitação de requisitos;
• Técnica: Entrevista;
• Técnica: Reunião;
• Momentos da Reunião;
• Recomendações da Reunião ;
• Técnica: Brainstorming;
• Tarefa; e
• Referências Bibliográficas.
Delimitar o Sistema e o Contexto do Sistema
Antes de iniciar o processo de elicitar
requisitos, faz necessário, a delimitação do sistema,
assim como o seu contexto.

Fonte: CPRE-FL Quick Guide

Delimitar o Sistema e o Contexto do Sistema

Fonte: CPRE-FL Quick Guide

Delimitar o Sistema e o Contexto do Sistema
O contexto do sistema é a parte da realidade
que influência o sistema a ser desenvolvido e dessa
forma também influência os requisitos do sistema.
Delimitar o Sistema e o Contexto do Sistema
Para que se possam elicitar os requisitos do
sistema a ser desenvolvido, é necessário em
primeiro lugar definir o limite entre o sistema e o
contexto do sistema, bem como o limite entre o
contexto do sistema e o ambiente irrelevante.
Delimitar o Sistema e o Contexto do Sistema
O escopo do sistema engloba aqueles aspectos
que podem ser modificados e projetados durante o
desenvolvimento do sistema.
Sistema, Contexto e Limites
A função do limite do sistema é determinar
quais aspectos serão cobertos pelo sistema
planejado e quais são partes do ambiente.
Sistema, Contexto e Limites
A função do contexto do sistema é identificar a
parte do ambiente que tem uma relação com o
sistema a ser desenvolvido.
Contexto do Sistema
Um requisito é definido para um contexto
específico e somente pode ser definido corretamente
em relação a esse contexto específico.
Os limites do sistema e do contexto definem o
contexto do sistema.
Determinar os Limites do Sistema e do Contexto
Uma vez definidos oslimites dosistema, o
escopo do sistema estará determinado.

Fonte: CPRE-FL Quick Guide

Determinar os Limites do Sistema e do Contexto

Fonte: CPRE-FL Quick Guide

Determinar os Limites do Sistema e do Contexto
O propósito de definir os limites do sistema e do
contexto é identificar a parte do ambiente que
influência os requisitos do sistema a ser
desenvolvido.
Limites do Sistema
As funções e qualidades desejadas do sistema
a ser planejado são conhecidas apenas de forma
incompleta ou mesmo desconhecidas.
Muitas vezes o limite do sistema somente é
definido mais precisamente ao final do processo.
Limites do Sistema
O limite do sistema separa o sistema a ser
desenvolvido do seu ambiente (isto é, separa a parte
da realidade que pode ser modificada ou alterada
pelo processo de desenvolvimento) daqueles
aspectos do ambiente que não podem ser mudados
ou modificados pelo processo de desenvolvimento.
Limites do Sistema
Aspectos dentro do contexto do sistema podem
ser processos de negócio, processos técnicos,
pessoas e papéis, estruturas organizacionais e
componentes da infraestrutura de TI.
Limites do Contexto
Pode mudar com o passar do tempo. Engloba
aqueles aspectos identificados do ambiente cuja
relação com o sistema planejado não está clara em
determinado momento.
Limites do Contexto
Diagramas de casos de uso e diagramas de
fluxo de dados são muitas vezes utilizados para
documentar o contexto do sistema (especialmente os
limites do sistema e do contexto).
Limites do Contexto
Uma definição completa e precisa do limite do
contexto para sistemas complexos é virtualmente
impossível.
Elicitar Requisitos
A elicitação se refere à etapa de investigação
dos requisitos. É o momento em que a equipe
técnica precisa compreender o que deve ser feito.

Fonte: CPRE-FL Quick Guide

Elicitar Requisitos

Fonte: CPRE-FL Quick Guide

 Elicitar Requisitos

Antigamente, o termo utilizado era “levantamento

de dados”, no entanto, essa expressão está em
desuso e, em seu lugar, usamos a expressão
“elicitação de requisitos” para denotar algo mais forte,
que remete a uma busca ativa pelos requisitos.
 Elicitar Requisitos

O analista de requisitos ou papel similar (analista

de negócios, analista de sistemas, product owner ou
equivalente) deve adotar uma postura proativa para a
descoberta e o entendimento dos requisitos.
Elicitar Requisitos

Isso implica em utilizar diversas formas de

elicitação, de acordo com o contexto em que o sistema
está sendo desenvolvido. Outros termos associados a
esta etapa podem ser: captura de requisitos,
descoberta de requisitos ou aquisição de requisitos
(BOURQUE; FAIRLEY, 2014).
Elicitar Requisitos

Quando falamos da Elicitação de requisitos não

estamos enfatizando que é necessário ter todos os
requisitos extensivamente detalhados no início do
projeto, ou que esta etapa ocorra uma única vez no
início do projeto.
Elicitar Requisitos

Em projetos ágeis, os requisitos podem emergir

em diversos momentos, compondo o product backlog.
No entanto, é importante ter em mente que alguns
requisitos, quando descobertos muito tardiamente no
ciclo de vida de um projeto, podem implicar em grande
quantidade de retrabalho e custos adicionais.
Elicitar Requisitos

O processo de elicitação exige uma intensa

comunicação com os stakeholders do projeto. É no
processo de comunicação que o analista de requisitos
identifica o que realmente é imprescindível para o
desenvolvimento do produto e não perde tempo
detalhando o que não é importante ou que não precisa
de detalhamento naquele momento.
Elicitar Requisitos

Há casos em que a comunicação com os

stakeholders é direta e é possível aplicar técnicas
como entrevistas e reuniões, pois existem fontes de
informação humanas que compreendem o contexto de
negócio e podem prover as informações necessárias
para a definição dos requisitos.
Elicitar Requisitos

Delinear histórias do usuário ou mapear a jornada

do usuário pode ajudar. Ambos se baseiam na
narrativa de uma história de uso do sistema por um
usuário.
 Elicitar Requisitos

No caso dos produtos inovadores, que estão

sendo criados sem uma experiência anterior, ou que
tenham um propósito disruptivo, é necessário que
sejam utilizadas técnicas com o propósito de despertar
a criatividade. Isto pode ser feito utilizando sessões de
cocriação, como o brainstorming ou o design thinking.
Elicitar Requisitos

Há ainda os momentos em que os requisitos são

obtidos a partir de documentações como editais de
licitação (no caso de contratação advinda do setor
público), de normas e leis (no caso de sistemas que
precisam atender a legislações específicas e órgãos
regulamentadores), de documentação de outros
sistemas anteriores e, até mesmo, no pior caso, do
próprio código-fonte anterior.
Elicitar Requisitos

O importante nas atividades de elicitação de

requisitos é que o analista de requisitos seja capaz de
compreender o contexto em que o projeto está inserido
e que possa planejar de que forma irá realizar sua
atividade de elicitar os requisitos. Pode ser
empregando uma única técnica, pode ser empregando
uma combinação de técnicas.
Fontes de Requisitos

No processo de definição do tipo de fonte de

requisitos, faz necessário o estudo detalhado do
contexto do projeto(Sistema).

Fonte: CPRE-FL Quick Guide

Fontes de Requisitos

Quais são asfontes de informação dos

requisitos?

Fonte: br.pinterest.com
Fontes de Requisitos

Existem diversas classificações para os

tipos de fonte de informação, como veremos a
seguir. Pohl e Rupp (2015) definem basicamente
os três tipos listados a seguir.
Fontes de Requisitos

Stakeholders: são pessoas ou organizações

que influenciam direta ou indiretamente nos requisitos
do sistema, como usuários, operadores do sistema,
desenvolvedores, arquitetos, clientes e testadores.
Fontes de Requisitos

Documentos: contêm informações importantes

que podem se tornar requisitos, como documentos de
ordem legal ou regulatória, normas e padrões,
documentos específicos do domínio de negócio ou da
própria empresa, como documentos de requisitos de
mais alto nível ou documentos de erros em sistemas
legados, por exemplo.
Fontes de Requisitos

Sistemas em operação: sistemas legados,

predecessores ou mesmo concorrentes. Os sistemas
podem ser a fonte de informações sobre novas
funcionalidades desejadas pelos clientes.
Stakeholders
Stakeholders

Classes de usuários favorecidos: são aqueles

usuários que estão mais diretamente relacionados
com a satisfação dos objetivos de negócio do sistema
e, portanto, seus requisitos terão maior prioridade do
que outros requisitos.
Stakeholders

Classes de usuários não favorecidos: são

usuários que não devem utilizar o produto, por razões
legais, de segurança ou proteção, e que, portanto,
devem ser impedidos de fazê-lo por meio de
funcionalidades implementadas com essa finalidade
(como hackers, por exemplo).
Stakeholders

Classes de usuários ignorados: são usuários

que podem utilizar o produto, porém não são a razão
de existir do produto e os seus requisitos terão menor
prioridade.
Stakeholders

Outras classes de usuários: outros usuários

que não sejam os anteriormente mencionados e que
terão igual prioridade na definição de requisitos.
Fontes de Requisitos

Como identificar as fontes de informação?

Fonte: br.pinterest.com
Fontes de Requisitos
Taref
a
Disponível no Ava.
https://ava1.uniceplac.edu.br/
Referências Bibliográficas
SHEILA, Reinehr. Engenharia de requisitos. 1ª Edição. Porto Alegre:
Sagah, 2020. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9786556900674/cfi/0!
/4/4@0.00:0.00

CPRE-FL Quick Guide Certified Professional for

Requirements
Engineering – Foundation Level.
 Obrigado (a)!
osmam.souto@uniceplac.edu.br