Introdução à Engenharia de Requisitos

Prévia do material em texto

1ºAula
Introdução a Engenharia de 
Requisitos
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
•	 entender o que é um requisito;
•	 saber o que é engenharia de requisitos;
•	 compreender como funcionam as etapas de Concepção e Levantamento dos Requisitos.
Olá,
Estamos iniciando a matéria de Engenharia de Requisitos, 
uma das matérias-chave de estudo da Engenharia de Software. 
Durante as próximas oito aulas, você vai ver, de uma forma 
aprofundada, cada uma das etapas que existem na Engenharia 
de Software. 
Para começarmos, vamos refletir sobre o que é um 
requisito e o que é a Engenharia de Requisitos. Após isso, vamos 
ver como funciona as duas primeiras etapas da Engenharia de 
Requisitos, que são a concepção e o levantamento de requisitos.
Lembre-se que a área do aluno está a sua disposição para 
eventuais dúvidas.
Bons estudos!
Engenharia de Requisitos 6
Seções de estudo
1 - O que é Requisito?
2 - Fase de Concepção
3 - Levantando Requisitos
1 - o que é Requisito?
Para compreendermos com o que estamos lidando nessa 
matéria, vamos estudar hoje o que é um requisito. Engholm 
Júnior explica: 
Podemos	 definir	 requisito	 como	 uma	
condição ou uma capacidade de um software 
que deve ser implementada por um sistema 
ou componente de sistema para se alcançar 
determinado	 fim.	 Todo	 projeto	 de	 software	
tem	um	conjunto	de	requisitos,	definidos	pelas	
necessidades e expectativas dos usuários que 
efetivamente utilizarão o mesmo, relacionado 
ao atendimento dos objetivos de negócio da 
empresa onde trabalham. ENGHOLM JR. 
(2010, p. 151) 
Assim, podemos entender requisito como um item 
que deve ser implementado, e cuja origem vem de uma 
necessidade do usuário, e que depende do ramo de negócio 
onde o sistema atuará. 
Vejam os exemplos a seguir:
•	 para um sistema de farmácias, podemos citar como 
prováveis requisitos a exigência de controle de 
estoque de remédios e o registro de venda desses 
remédios;
•	 para um sistema de bibliotecas, podemos citar a 
necessidade de cadastrar usuários, livros e os seus 
empréstimos;
•	 para um sistema que sirva de apoio para a plataforma 
EAD (como a sua área do aluno), podemos citar 
como prováveis requisitos a necessidade de registrar 
aulas, de registrar as vídeoaulas, a possibilidade do 
aluno de ver as vídeoaulas, entre outras funções.
1.1 - o que é Engenharia de 
Requisitos?
Agora que você já aprendeu o que é um requisito, 
devemos entender como os requisitos são detectados e 
elaborados. Na Engenharia de Software, os processos de 
coleta, análise, documentação e gerenciamento de 
requisitos são denominados de Engenharia de Requisitos. 
Segundo Pressman (2016, p. 132), é “uma ação de engenharia 
de software importante que se inicia durante a atividade de 
comunicação e continua na de modelagem. Ela deve ser 
adaptada às necessidades do processo, do projeto, do produto 
e das pessoas que estão realizando o trabalho.”
Graças aos processos da Engenharia de Requisitos, 
podemos descobrir quem são os usuários do projeto, quais 
são as suas necessidades e as suas prioridades para tornar a 
rotina de uso do sistema prazerosa para todos os usuários, 
sem complicações ou problemas.
Pressman (2016) cita sete tarefas que a Engenharia de 
Requisitos trabalha. Sobre essas tarefas, veremos de maneira 
mais detalhada nos próximos conteúdos, mas agora citaremos 
todas de uma vez, para que você tenha uma visão geral das 
atividades que são desempenhadas no processo de elaboração 
de requisitos.
As tarefas da Engenharia de Requisitos são:
•	 Concepção: É a etapa onde são estabelecidos: o 
entendimento básico do problema que o sistema 
deve resolver; as pessoas que querem a solução 
e a natureza da solução desejada. Nessa etapa, a 
equipe tem os primeiros contatos com os clientes e 
usuários do sistema, estabelecendo uma colaboração 
preliminar entre os envolvidos;
•	 Levantamento: Essa é uma das etapas mais 
cruciais da Engenharia de Requisitos, pois envolve 
a coleta das informações que gerarão os requisitos 
preliminares do sistema. Muitos podem entender 
que é uma tarefa simples, pois consistiria em 
apenas perguntar ao cliente o que ele quer que o 
sistema tenha. Mas como isso envolve comunicação 
entre duas pessoas, podem ocorrer ambiguidades, 
inconsistências e problemas de entendimento. 
Abordaremos mais detalhadamente mais tarde;
•	 Elaboração: Nessa etapa, as informações obtidas do 
cliente	são	refinadas	e	expandidas	durante	essa	fase.	
Através das informações, são detectados os cenários 
que descrevem como os usuários vão interagir com 
o sistema e quais são as classes do sistema (além 
de seus atributos, métodos e relacionamentos com 
outras classes);
•	 Negociação: Após a elaboração dos requisitos 
atributos de requisitos
Carlos Alberto Debastiani (2015) elenca alguns atributos onde todo 
requisito deve ter:
•	 Ser mensuráveis: o requisito deve ser passível de medição 
quanto	 a	 sua	 abrangência	 e	 medição,	 para	 verificar	 a	 sua	
capacidade de atender à necessidade de negócio a qual se 
propõe;
•	 Ser	 testável:	 o	 requisito	 deve	 ser	 testável	 para	 verificar	 se	
foi corretamente implementado no sistema. Para isso, são 
identificadas	 as	 possíveis	 saídas	 do	 requisito	 para	 realizar	 a	
verificação;
•	 Ser	 completo:	 a	 definição	 do	 requisito	 deve	 ser	 abrangente	
o	 suficiente	 para	 orientar	 adequadamente	 a	 solução.	 Sua	
definição	não	deve	gerar	dúvidas	quanto	o	escopo	ou	a	sua	
forma de implementação;
•	 Ser consistente: o requisito deve ser coerente com os demais 
requisitos que se relaciona. Portanto, devemos evitar requisitos 
que	invalidam	ou	dificultam	outro	requisito;
•	 Ser aceitável: o requisito deve ser possível documentar e 
registrar formalmente a sua aceitação, para que seja possível a 
sua homologação e;
Ser	não	ambíguo:	a	sua	definição	não	pode	ser	obscura	ou	de	
duplo sentido, evitando problemas de interpretação. 
7
detalhados, o cliente ordene os requisitos e discuta 
a sua prioridade. Nesse trabalho, são revisados 
os	 requisitos	 que	 causam	 conflitos	 internos	 com	
outros	requisitos,	onde	os	clientes	justificam	a	sua	
existência;
•	 Especificação: Depois dos requisitos serem 
descobertos	e	revisados,	é	feito	uma	especificação	
que serve para formalizar os requisitos. Essa 
formalização pode ser feita em um documento 
por	escrito,	um	conjunto	de	modelos	gráficos,	um	
conjunto de cenários de uso, um protótipo, um 
modelo matemático etc.;
•	 Validação: Nessa etapa, os artefatos produzidos 
pela engenharia de requisitos são revisados, em 
busca de ambiguidades na declaração, erros, 
inconsistências, omissões, requisitos irreais (ou seja, 
sua	execução	é	 impossível),	 requisitos	 conflitantes	
etc.;
•	 Gestão de Requisitos: É um conjunto de atividades 
que	ajuda	a	equipe	do	projeto	a	identificar,	controlar	
e acompanhar as necessidades e suas mudanças à 
medida que o projeto prossegue.
Nessa seção, você teve uma visão mais abrangente sobre 
a Engenharia de Requisitos. A partir da próxima seção, vamos 
ver todas as etapas de uma forma mais detalhada, a iniciar pela 
etapa de concepção.
2 - Fase de Concepção
Como já vimos, os projetos de desenvolvimento de 
software iniciam-se com a coleta das primeiras informações 
sobre o software e a descoberta das pessoas envolvidas. Essa 
etapa propicia aos interessados um primeiro contato com os 
possíveis requisitos do sistema e pode declarar se o sistema é 
viável ou não.
Pressman (2016) elenca as principais tarefas que devem 
ser feitas nesta fase:
•	 Identificação dos envolvidos: é feita uma lista de 
pessoas que podem ajudar os analistas na etapa de 
coleta de requisitos. Essas pessoas devem ser aquelas 
que	 se	 beneficiam	 diretamente	 ou	 indiretamente	
com o sistema a ser desenvolvido(na maioria das 
vezes, usuários da aplicação). Esses envolvidos são 
chamados também de stakeholders.
•	 Reconhecimento dos diversos pontos de vista: 
depois	da	criação	da	lista	dos	prováveis	beneficiários	
do sistema, deve-se catalogar os usuários pela área a 
qual	pertence,	para	facilitar	a	 identificação	de	seus	
pontos de vista diferentes e de suas necessidades. 
Como vários envolvidos podem trabalhar em 
posições diferentes, podem ter necessidades 
diferentes, que podem gerar requisitos diferentes, 
que	 podem	 conflitar	 com	 outros	 requisitos.	 A	
identificação	das	áreas	serve	para	enxergar	melhor	
essas necessidades;
•	 Levantamento das informações iniciais: 
a partir daí, os analistas levantam junto aos 
stakeholders, as informações necessárias do sistema. 
Elencamos aqui uma lista de possíveis perguntas 
a serem feitas:
 – quem está por trás da solicitação deste 
trabalho?
 – quem vai usar a solução?
 – qual será o benefício econômico de uma 
solução bem-sucedida?
 – há outra fonte para a solução de que você 
precisa?
 – como você caracterizaria uma “boa” saída, 
que seria gerada por uma solução bem-
sucedida?
 – qual(is) problema(s) esta solução vai 
resolver?
 – você poderia me indicar (ou descrever o 
ambiente de negócios em que a solução será 
utilizada?
 – aspectos ou restrições de desempenho 
afetam a maneira com que a solução será 
abordada?
 – você é a pessoa correta para responder a 
estas	perguntas?	suas	respostas	são	oficiais?	
 – minhas perguntas são relevantes para o 
problema que você tem?
 – estaria eu fazendo perguntas demais?
 – alguma outra pessoa poderia me prestar 
informações adicionais?
 – deveria eu perguntar-lhe algo mais?
Esse conjunto de perguntas que nós vimos serve para 
detectar	possíveis	clientes	e	seus	perfis	de	uso;	as	metas	que	
o sistema deve alcançar; as primeiras informações sobre o 
problema que o sistema propõe a resolver e para detectar 
informações a respeito da conversa. Pressman recomenda 
essa solução de perguntas e respostas apenas no primeiro 
encontro, para coletar essas informações. 
Vamos agora ver o nosso estudo de caso, que 
acompanhará nossos estudos durante essa matéria. Na matéria 
de Metodologia para Desenvolvimento de Software, vimos o 
estudo de caso da empresa de locação de veículos LocaPlus, 
sobre um hipotético sistema de locações. Esse estudo de caso 
era	simplificado,	para	apenas	situar	o	estudo	dos	diagramas	
da UML.
Nessa matéria, vamos contextualizar as etapas da 
Engenharia de Requisitos usando o estudo de caso a seguir. A 
analista contratada pela empresa seguiu as etapas necessárias 
para realizar a concepção do projeto de software, e reuniu 
as informações nas anotações que reproduziremos a seguir, 
advindas de uma reunião com o dono da empresa:
Envolvidos:
•	 Luciano Silva, dono da empresa LocaPlus;
•	 Marcela Silva, gerente da empresa;
•	 Carlos Couto e Roberto Abóbora, funcionários da empresa.
Quem está por trás da solicitação deste trabalho?
•	 Luciano Silva, dono da empresa LocaPlus;
Engenharia de Requisitos 8
Quem vai usar a solução?
Gerentes e funcionários da empresa LocaPlus
Qual será o benefício econômico de uma solução bem-
sucedida?
Mais agilidade no atendimento e na tomada de decisões da 
empresa.
há outra fonte para a solução de que você precisa?
Não
Como você caracterizaria uma “boa” saída, que seria gerada 
por uma solução bem-sucedida?
uma boa saída seria aquela que fosse amigável ao usuário e 
atendesse as necessidades da empresa.
Qual(is) problema(s) esta solução vai resolver?
•	 Cadastro de clientes;
•	 Cadastro de locações;
•	 Cadastro de veículos;
•	 Cadastro de funcionários.
Você poderia me indicar (ou descrever o ambiente de 
negócios em que a solução será utilizada?
Seria utilizado dentro da sede da LocaPlus, em um contexto de uma 
loja de locação de veículos.
aspectos ou restrições de desempenho afetam a maneira 
com que a solução será abordada?
Como todo o sistema, deve ser rápido para atender as transações 
comerciais e o sistema deve permitir o acesso a apenas pessoas 
autorizadas.
Agora que vocês viram como funciona esta etapa 
preliminar da Engenharia de Requisitos, vamos ver na 
próxima seção como funciona a principal atividade desse 
ramo: o levantamento de requisitos.
3 - Levantando Requisitos
A fase de levantamento de requisitos, que também pode 
ser chamada de elaboração, é a principal fase da Engenharia 
de Requisitos, pois é a fase onde os analistas ouvem os 
stakeholders sobre as suas necessidades a serem resolvidas.
Um erro, nessa fase, pode causar problemas nas fases 
seguintes do sistema, e causar insatisfações entre a equipe de 
desenvolvimento e os envolvidos pelo sistema. Esta etapa 
consiste “em que se pergunta ao cliente, usuários e os demais 
interessados quais são os objetivos de cada um para o sistema, 
qual será o objetivo do sistema, como o sistema atenderá às 
necessidades da empresa e como o sistema deverá ser utilizado 
no dia a dia.” (MEDEIROS, s.d.)
Para isso, são utilizadas várias técnicas. Vamos elencar 
elas a seguir:
3.1 - Entrevistas
É o método mais comum utilizado para levantamento de 
requisitos. Não há segredos em relação ao seu uso. Em uma 
entrevista, os analistas coletam respostas junto aos stakeholders 
sobre o que o sistema deve fazer. As entrevistas se dividem 
em dois tipos:
•	 entrevistas fechadas, quando as questões já são 
predefinidas;
•	 entrevistas abertas, onde não é feito um conjunto de 
questões	predefinidas.
Segundo Sommerville, as entrevistas são uma boa para 
obter uma compreensão global sobre o que os envolvidos no 
sistema fazem; como esses envolvidos fazem a interação e as 
dificuldades	que	eles	enfrentam	atualmente,	mas	pode	não	ser	
eficaz	para	extrair	o	domínio	da	aplicação	por	dois	motivos:
•	 os	entrevistados	podem	utilizar	os	jargões	específicos	
da sua área de atuação (ex.: um economista que 
pleiteia a criação de um sistema que atua na bolsa 
de valores pode citar os termos buy, sell, after market) 
sem explicar ao entrevistador o que se trata;
•	 o conhecimento de domínio é tão familiar aos 
envolvidos que podem subentender que não devem 
explicar as complexidades ao entrevistador, achando 
que isso é uma coisa óbvia (por exemplo, um dono 
de supermercado pode não explicar que toda vez 
que uma compra é feita, é realizada uma baixa nos 
produtos no estoque, pois crê que todos tenham 
que saber isso).
Ainda	 sobre	 isso,	 Sommerville	 (2011)	 afirma	 que	
o	 entrevistador,	 para	 ser	 eficaz,	 deve	 ser	 aberto	 a	 novos	
requisitos e estimular o entrevistado a participar da discussão 
por meio de questões que instiguem essa discussão.
Debastiani (2015) recomenda que o conteúdo das 
entrevistas seja registrado numa ata, com a documentação de 
todo o sistema.
3.2 - Cenários
Pode ser interessante os stakeholders explicarem suas 
necessidades por meio de cenários de uso da vida real. A 
metodologia eXtreme Programing (XP) estimula a elicitação de 
requisitos por meio de cenários, ou, no jargão da metodologia, 
por estórias de usuário (User Stories).
 Em cada cenário, normalmente são descritos:
•	 uma descrição do que o sistema e os usuários 
esperam quando o cenário se iniciar;
•	 uma	 descrição	 do	 fluxo	 normal	 de	 eventos	 no	
cenário;
•	 uma descrição do que pode dar errado e como isso 
é tratado; 
•	 informações sobre outras atividades que podem 
ocorrer ao mesmo tempo;
•	 uma descrição do estado do sistema quando o 
cenário acaba.
Os métodos ágeis, como já vimos, propõe um método 
mais simples para a escrita de cenários. Segue o modelo:
Como um <papel do usuário> eu quero <ação> para 
<funcionalidade>
Como um funcionário da locadora, eu quero cadastrar carros para 
poder locar esses carros.
9
3.3	-	Etnografia
É chamada também de técnicade observação, onde o 
“analista faz uma imersão no ambiente de trabalho em que o 
sistema será utilizado. O trabalho do dia a dia é observado e são 
feitas anotações sobre as tarefas reais em que os participantes 
estão envolvidos.” (SOMMERVILLE, 2011, p. 75)
Esse método pode ser usado para compreender os 
processos operacionais e ajudar a extrair os requisitos de apoio 
para esses processos. Ele ajuda a descobrir requisitos implícitos 
que indicam as formas reais que as pessoas trabalham, que 
podem ser diferentes do que a organização prevê em seus 
manuais e formalidades, e quais são as colaborações que 
ocorrem durante as execuções das atividades.
3.4 - Técnicas de Levantamento de 
Requisitos em Grupo
Adicionalmente, podemos usar estratégias de 
levantamento de requisitos que envolvem reuniões em grupo. 
A vantagem é a possibilidade do confronto e discussão de 
ideias	 conflitantes	 entre	 stakeholders que atuam em áreas 
diferentes na empresa. 
Para possibilitar o direcionamento, nessas reuniões, há 
a	 figura	 do	moderador,	 cuja	 responsabilidade	 é	manter	 ou	
redirecionar o foco da reunião. Várias técnicas se encaixam 
nessa classe, como:
•	 Dinâmicas de grupo: são reuniões que reúnem 
partes interessadas com especialistas em áreas de 
interesse que estejam alinhadas com os objetivos 
do	 projeto,	 a	 fim	 de	 aprender	 mais	 sobre	 um	
determinado processo, produto ou serviço, que será 
objeto de estudo e discussão;
•	 Oficinas: são sessões focadas e dirigidas a objetivos 
específicos	 que	 reúnem	 partes	 interessadas	
multifuncionais relacionadas a um projeto, para 
definir	os	requisitos	de	um	determinado	produto;
•	 Brainstorming: chamado também pela sua 
tradução [da palavra oriunda do inglês] em 
português para “tempestade de ideias” consiste 
em explorar a capacidade criativa de um grupo de 
indivíduos selecionados previamente, buscando 
atingir	 objetivos	 específicos	 ou	 a	 solução	 de	
problemas (Debastiani, 2015). Nessas reuniões, 
a diversidade de pensamentos dos envolvidos é 
utilizada para gerar soluções inovadoras. Para isso, 
cada participante propõe qualquer pensamento 
ou ideia que venha na mente do participante que 
solucione o problema. As sessões dessa técnica são 
divididas em três etapas:
 – encontre	os	fatos	do	problema,	definindo	o	
que é e quais são os elementos do problema;
 – depois de terem uma noção do problema, os 
participantes discutem suas visões e ideias a 
respeito do problema;
 – finalmente,	 é	 feito	uma	compilação	e	uma	
melhora de tudo o que foi discutido, fazendo 
uma avaliação de viabilidade das soluções 
apresentadas, até se chegar a um consenso 
da solução.
Agora, vamos mostrar os requisitos do sistema do nosso 
estudo de caso, de acordo com a analista do sistema:
•	 um cliente pode locar veículos, para isso, deve informar a sua 
CNH,	seu	RG,	seu	nome,	seu	endereço,	seu	CPF	e	seu	número	
de dependentes;
•	 A locadora possui vários carros. Você observou que a locadora 
mantém	uma	ficha	de	cadastro	dos	carros,	que	inclui	a	placa	
do veículo, o nome, a marca, o modelo, o valor do seguro, o 
valor da locação e a sua cor. Sendo que o valor da locação do 
carro pode ser atualizado a qualquer momento.
•	 Além disso, a locadora registra seus funcionários com os 
seguintes dados: CPF, RG, seu nome, seu endereço e seu 
cargo. um funcionário pode ainda ser admitido ou demitido, 
para isso são registradas suas datas de admissão - contratação 
- e demissão.
•	 A locadora, além de realizar os cadastros, ela cadastra as 
locações de veículos. No momento da locação, a locadora 
registra	 o	 número	 do	 cliente	 e	 a	 placa	 do	 carro,	 além	 de	
atribuir a data da locação para o dia atual. No ato da devolução, 
o funcionário registra a data de devolução e a quilometragem 
percorrida, para que seja informado o preço a pagar pela 
locação.
•	 qualquer funcionário pode registrar clientes, carros e locações. 
Mas,	o	 funcionário	na	condição	de	supervisor	é	o	único	que	
tem a permissão de registrar e demitir funcionários - além de 
pode fazer o que um funcionário comum pode fazer.
•	 o funcionário deve estar cadastrado e logado para acessar os 
recursos do sistema.
Com	isso,	finalizamos	nossa	primeira	aula	da	disciplina	de	
Engenharia de Requisitos. Na nossa próxima aula, entraremos 
em detalhes na fase de modelagem de requisitos. Até lá, releia 
essa aula se achar necessário, e se tiver alguma dúvida, use as 
ferramentas que estão a sua disposição.
Retomando a aula
Chegamos	 ao	 final	 da	 nossa	 primeira	 aula.	 Vamos	
relembrar?
1 - O que é Requisito?
Vimos que requisito é uma condição ou uma capacidade 
de um software que deve ser implementada por um sistema 
ou	componente	de	sistema	para	se	alcançar	determinado	fim.	
Ainda vimos que a Engenharia de Requisitos é o conjunto de 
processos de coleta, análise, documentação e gerenciamento 
de requisitos.
2 - Fase de Concepção
A fase de concepção, que abre o processo da Engenharia 
de Requsitos, consiste na coleta das primeiras informações 
sobre o software e a descoberta das pessoas envolvidas, como 
Engenharia de Requisitos 10
o levantamento dos envolvidos no sistema e das informações 
iniciais do sistema (como o ambiente de negócio, quem serão 
os usuários do sistema, quais são as metas etc.)
3 - Levantando Requisitos
A fase de levantamento ou elicitação de requisitos é a 
fase onde os analistas ouvem os stakeholders sobre as suas 
necessidades a serem resolvidas. São utilizadas várias técnicas 
como:	entrevistas,	reuniões,	etnografia,	oficinas	etc.
Vale a pena
 
DEBASTIANI, 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. 
SOMMERVILLE, Ian. Engenharia de Software. 9 ed. São 
Paulo: Pearson, 2011.
Vale a pena ler
MEDEIROS, Higor. As Etapas da Engenharia de 
Requisitos. [S.l.]: DevMedia, s.d. Disponível em: <https://
www.devmedia.com.br/as-etapas-da-engenharia-de-
requisitos/30220>. Acesso em: 25 fev. 2018.
PEREIRA, Thiago. Elicitação de requisitos e suas técnicas. 
[S.l.]: iMasters, 2010. Disponível em: <https://imasters.
com.br/artigo/18032/gerencia-de-projetos/elicitacao-de-
requisitos-e-suas-tecnicas/?trace=1519021197&source=sin
gle>. Acesso em: 25 fev. 2018.
PRIMO, Glauco. User Stories – O que são? Como Usar?. 
[S.l.]: Blog Scrum Half, 2011. Disponível em: <http://blog.
myscrumhalf.com/2011/10/user-stories-o-que-sao-como-
usar/>. Acesso em: 25 fev. 2018.
Vale a pena acessar
Minhas anotações