Importância da Engenharia de Requisitos

Prévia do material em texto

A IMPORTÂNCIA DA ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO 
DOS PROJETOS DE SOFTWARE 
 
 
Kaio da Fonseca Gonçalves da Silva – kaiofonseca.gsilva@gmail.com 
Universidade Paulista – UNIP 
Rua Antonio de Macedo, 505, Tatuapé 
03087-040 – São Paulo – SP – Brasil 
 
Resumo: A Engenharia de Requisitos é uma etapa da Engenharia de Software onde 
são aplicadas técnicas com o intuito de criar e refinar os requisitos do projeto. Nesse 
sentido, esse artigo tem como objetivo abordar importância da Engenharia de 
Requisitos no processo de desenvolvimento dos projetos de software e definir os 
processos e atividades oferecidas na Engenharia de Requisitos. 
 
Palavras-chave: Engenharia de Requisitos, Desenvolvimento de Software. 
 
 
 
 
Abstract: Requirements Engineering is a stage of Software Engineering where 
techniques are applied in order to create and refine the requirements of the project. In 
this sense, this article aims to address the importance of Requirements Engineering in 
the process of developing software projects and define the processes and activities 
offered in Requirements Engineering. 
 
Keyword: Requirements Engineering, Software Development. 
 
 
 
 
 
 
 
 
 
1 INTRODUÇÃO 
 
Para compreender o que é engenharia de requisitos é necessário entender o que 
vem a ser um requisito. 
Para Sommerville (2011) requisitos são as descrições do que o sistema deve fazer, 
os serviços que oferece e as restrições a seu funcionamento. Esses requisitos 
refletem as necessidades dos clientes para um sistema que serve a uma finalidade 
determinada. 
De acordo com Pfleeger (2004) os requisitos são como uma descrição do 
funcionamento de um sistema, tais como uma reação à inserção de dados, e o 
estado de cada entidade antes e depois da atividade ocorrer. A mesma altera que os 
requisitos não descrevem, somente, o fluxo de informações que entra e sai de um 
sistema, e a transformação dos dados, mas também as restrições ao seu 
desempenho. 
 
2 ENGENHARIA DE REQUISITOS 
 
 Sommerville (2011) defini a engenharia de requisitos como um processo de 
compreensão e definição dos serviços requisitados do sistema e identificação de 
restrições relativas à operação e ao desenvolvimento do sistema. A engenharia de 
requisitos é um estágio particularmente crítico do processo de software, pois erros 
nessa fase inevitavelmente geram problemas no projeto e na implementação do 
sistema. 
 Segundo Pressman (2011), entender os requisitos de um problema está entre as 
tarefas mais difíceis enfrentadas por um engenheiro de software. O autor explica que 
o amplo espectro de tarefas e técnicas que levam a um entendimento dos requisitos 
é denominado engenharia de requisitos. Na perspectiva do processo de software, a 
engenharia de requisitos é 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. 
 De acordo com Cysneiros (2001) para a engenharia de requisitos é fundamental 
que o engenheiro de software delimite os contornos do macrosistema em que a 
 
definição de software ocorrerá, ou seja, delimitar o Universo de Informações do 
sistema (Udl). 
O mesmo autor informa que o UdI sempre existe. O UdI independe do modelo que 
estamos utilizando. Mesmo que o macrosistema não esteja bem definido, sempre 
podemos, e devemos, estabelecer os limites de nossa atuação. Quanto mais bem 
delineado um UdI, maiores são as chances de um software bem definido. 
 
 
3 CLASSIFICAÇÃO DE REQUISITOS 
 
 Segundo Sommerville (2011) os requisitos de software são frequentemente 
divididos em duas categorias: 
1. Requisitos funcionais. São declarações de serviços que o sistema deve 
fornecer, de como o sistema deve reagir a entradas específicas e de como 
o sistema deve se comportar em determinadas situações. Em alguns 
casos, os requisitos funcionais também podem explicitar o que o sistema 
não deve fazer. 
2. Requisitos não funcionais. São restrições aos serviços ou funções 
oferecidos pelo sistema. Incluem restrições de timing, restrições no 
processo de desenvolvimento e restrições impostas pelas normas. Ao 
contrário das características individuais ou serviços do sistema, os 
requisitos não funcionais, muitas vezes, aplicam-se ao sistema como um 
todo. 
 O mesmo autor explica que a distinção entre diferentes tipos de requisitos não é 
tão clara como sugerem essas definições simples. Um requisito de usuário 
relacionado com a proteção, tal como uma declaração de limitação de acesso a 
usuários autorizados, pode parecer um requisito não funcional. No entanto, quando 
desenvolvido em mais detalhes, esse requisito pode gerar outros requisitos, 
claramente funcionais, como a necessidade de incluir recursos de autenticação de 
usuário no sistema. 
 Isso mostra que os requisitos não são independentes e que muitas vezes 
geram ou restringem outros requisitos. Portanto, os requisitos de sistema não apenas 
especificam os serviços ou as características necessárias ao sistema, mas também a 
 
funcionalidade necessária para garantir que esses serviços/características sejam 
entregues corretamente. 
 
 
3.1 REQUISITOS FUNCIONAIS 
 
 Sommerville (2011) informa que os requisitos funcionais de um sistema 
descrevem o que ele deve fazer. Eles dependem do tipo de software a ser 
desenvolvido, de quem são seus possíveis usuários e da abordagem geral adotada 
pela organização ao escrever os requisitos. Quando expressos como requisitos de 
usuário, os requisitos funcionais são normalmente descritos de forma abstrata, para 
serem compreendidos pelos usuários do sistema. No entanto, requisitos de sistema 
funcionais mais específicos descrevem em detalhes as funções do sistema, suas 
entradas e saídas, exceções etc. 
 O autor explica que requisitos funcionais do sistema variam de requisitos gerais, 
que abrangem o que o sistema deve fazer, até requisitos muito específicos, que 
refletem os sistemas e as formas de trabalho em uma organização. 
 
3.2 REQUISITOS NÃO FUNCIONAIS 
 
Segundo Sommerville (2011) os requisitos não funcionais, como o nome sugere, 
são requisitos que não estão diretamente relacionados com os serviços 
específicos oferecidos pelo sistema a seus usuários. Eles podem estar 
relacionados às propriedades emergentes do sistema, como confiabilidade, 
tempo de resposta e ocupação de área. Uma alternativa a esse cenário seria os 
requisitos definirem restrições sobre a implementação do sistema, como as 
capacidades dos dispositivos de E/S ou as representações de dados usadas nas 
interfaces com outros sistemas. 
O mesmo autor informa que os requisitos não funcionais, como desempenho, 
proteção ou disponibilidade, normalmente especificam ou restringem as 
características do sistema como um todo. Requisitos não funcionais são 
frequentemente mais críticos que requisitos funcionais individuais. Os usuários 
do sistema podem, geralmente, encontrar maneiras de contornar uma função do 
sistema que realmente não atenda a suas necessidades. No entanto, deixar de 
 
atender a um requisito não funcional pode significar a inutilização de todo o 
sistema. 
 
 
 
4 PROCESSO DE ENGENHARIA DE REQUISITOS 
 
 Sommerville (2011) declara que o processo de engenharia de requisitos tem 
como objetivo produzir um documento de requisitos acordados que especifica um 
sistema que satisfaz os requisitos dos stokeholders (são todas as partes interessadas 
no projeto). Requisitos são geralmente apresentados em dois níveis de detalhe. 
 Os usuários finais e os clientes precisam de uma declaração de requisitos em 
alto nível; desenvolvedores de sistemas precisam de uma especificação mais 
detalhada do sistema. 
 
 
Fonte: Sommerville, 2011. 
 
Sommerville (2011) explica que naturalmente,as atividades no processo de 
requisitos não são feitas em apenas uma sequência. A análise de requisitos continua 
durante a definição e especificação, e novos requisitos emergem durante o processo. 
Portanto, as atividades de análise, definição e especificação são intercaladas. Nos 
métodos ágeis, como extreme programming, os requisitos são desenvolvidos de forma 
incremental, de acordo com as prioridades do usuário, e a elicitaçâo de requisitos é 
feita pelos usuários que integram equipe de desenvolvimento. 
 
 
 
4.1 ELICITAÇÃO DE REQUISITOS 
 
Pressman (2011) explica que a elicitação de requisitos, encoraja uma 
abordagem colaborativa e orientada às equipes em relação ao levantamento de 
requisitos, os interessados trabalham juntos para identificar o problema e desenvolver 
elementos de solução. 
Sommerville (2011) demonstra que há quatro processos de elicitação: 
 Descoberta de Requisitos: Essa é a atividade de interação com os 
stakeholders do sistema para descobrir seus requisitos. 
 Classificação e Organização de Requisitos: Essa atividade toma a 
coleção de requisitos não estruturados, agrupa requisitos relacionados 
e os organiza em grupos coerentes. 
 Priorização e Negociação de Requisitos: Essa atividade está 
relacionada com a priorização de requisitos e em encontrar e resolver os 
conflitos por meio da negociação de requisitos. 
 Especificação de Requisitos: Os requisitos são documentados e 
inseridos no próximo ciclo da espiral. 
 
4.2 ANÁLISE E NEGOCIAÇÃO DE REQUISITOS 
 
Pressman (2011) explica que em um contexto de engenharia de requisitos 
ideal, as tarefas do início, levantamento e elaboração determinam os requisitos do 
cliente com detalhes suficientes para prosseguir para atividades de engenharia de 
software subsequentes. Infelizmente, isso raramente acontece. Na realidade, talvez 
você tenha de iniciar uma negociação com um ou mais interessados. Na maioria dos 
casos, solicita-se aos interessados contrabalançar funcionalidade, desempenho e 
outas características do produto ou sistema, em função do custo e do tempo para 
chegar ao mercado. 
O intuito da negociação é desenvolver um plano de projeto que atenda às 
necessidades dos interessados e, ao mesmo tempo, reflita as restrições do mundo 
real (por exemplo, tempo, pessoal, orçamento) impostas à equipe de software. 
 
 
 
4.3 ESPECIFICAÇÃO DE REQUISITOS 
 
De acordo com Sommerville (2011) a especificação de requisitos é o processo 
de escrever os requisitos de usuário e de sistema em um documento de requisitos. 
Idealmente, os requisitos de usuário e de sistema devem ser claros, inequívocos, de 
fácil compreensão, completos e consistentes. 
O mesmo auto informa que na prática, isso é difícil de conseguir, pois os 
stakeholders interpretam os requisitos de maneiras diferentes, e muitas vezes notam-
se conflitos e inconsistências inerentes aos requisitos. 
 
 
4.4 MODELAGEM DO SISTEMA 
 
Segundo Sommerville (2011) a modelagem de sistema como o processo de 
desenvolvimento de modelos abstratos de um sistema, em que cada modelo 
apresenta uma visão ou perspectiva, diferente do sistema. A modelagem de sistema 
geralmente representa o sistema com algum tipo de notação gráfica, que, atualmente, 
quase sempre é baseada em notações de UML. No entanto, também é possível 
desenvolver modelos (matemáticos) formais de um sistema, normalmente como uma 
especificação detalhada do sistema. 
Os modelos são usados durante o processo de engenharia de requisitos para 
ajudar a extrair os requisitos do sistema; durante o processo de projeto, são usados 
para descrever o sistema para os engenheiros que o implementam; e, após isso, são 
usados para documentar a estrutura e a operação do sistema. 
O mesmo autor destaca que é possível desenvolver modelos do sistema 
existente e do sistema a ser desenvolvido. Os modelos de sistema existente ajudam 
na manutenção e esclarecem o motivo da existência do sistema. Os modelos do 
sistema a ser desenvolvido servem para ajudar a explicar os requisitos propostos para 
outros stakeholders do sistema. 
 
 
4.5 VALIDAÇÃO DE REQUISITOS 
De acordo com Sommerville (2011) a validação de requisitos é 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. A validação de requisitos é importante porque erros em um documento 
de requisitos podem gerar altos custos de retrabalho quando descobertos durante o 
desenvolvimento ou após o sistema já estar em serviço. 
Pressman (2011) destaca que à medida que cada elemento do modelo de 
requisitos é criado, é examinado em termos de inconsistência, omissões e 
ambiguidade. Os requisitos representados pelo modelo são priorizados pelos 
interessados e agrupados em pacotes de requisitos que serão implementados como 
incrementos de software. O mesmo autor demonstra que uma revisão do modelo de 
requisitos trata as seguintes questões: 
 Cada um dos requisitos é consistente com os objetivos globais para o 
sistema/produto? 
 Todos os requisitos foram especificados no nível de abstração 
apropriado? Ou seja, algum dos requisitos fornece um nível de detalhe 
técnico inapropriado no atual estágio? 
 O requisito é realmente necessário ou representa um recurso adicional 
que talvez não seja essencial para o objetivo do sistema? 
 Cada um dos requisitos é limitado e sem ambiguidade? 
 Cada um dos requisitos possui atribuição? Ou seja, uma fonte (em geral, 
um indivíduo específico) é indicada para cada requisito? 
 Algum dos requisitos conflita com outros requisitos? 
 Cada um dos requisitos é atingível no ambiente técnico que irá abrigar o 
sistema ou produto? 
 Cada um dos requisitos pode ser testado, uma vez implementado? 
 O modelo de requisitos reflete, de forma apropriada a informação, função 
e comportamento do sistema a ser construído? 
 O modelo de requisitos foi "dividido" para expor progressivamente 
informações mais detalhadas sobre o sistema? 
 Os padrões de requisitos foram utilizados para simplificar o modelo de 
requisitos? Todos os padrões foram validados adequadamente? Todos 
os padrões são consistentes com os requisitos do cliente? 
 
 
 
 
4.6 GESTÃO DE REQUISITOS 
 
 O gerenciamento de requisitos é o processo, segundo Sommerville (2011), de 
compreensão e controle das mudanças nos requisitos do sistema. Você precisa se 
manter a par das necessidades individuais e manter as ligações entre as 
necessidades dependentes para conseguir avaliar o impacto das mudanças nos 
requisitos. 
 Segundo Pressman (2011), gestão de requisitos é um conjunto de atividades 
que ajuda a equipe de projeto a identificar, controlar e acompanhar as necessidades 
e suas mudanças enquanto o projeto prossegue. 
 Sommerville (2011) informa que os requisitos para sistemas de software de 
grande porte estão sempre mudando. 
 
 
 
5 BENEFICIADOS DA ENGENHARIA DE REQUISITOS 
De acordo com Cysneiros (2001) os beneficiados com a Engenharia de Requisitos 
são: 
 Os Contratantes: são as pessoas que solicitam os serviços de análise do 
problema, por conta de terem um documento que assegure a resolução 
dos problemas referentes aos requisitos funcionais propostos e terem 
também a garantia da qualidade através de requisitos não funcionais 
expressados no mesmo documento. 
 Os Contratados: são as pessoas que fornecem os serviços de análise 
de problemas com o documento produzido através da engenharia de 
software, onde este terá uma visão mais precisa e clara dos verdadeiros 
requisitos funcionais necessários, não perdendo tempo e sendo mais 
objetivo, e também podem focalizar a qualidade do produto de acordo com 
os requisitos não funcionais escolhidos. 
 Os futuros Contratados e Contratantes: são as pessoas que vão 
reutilizar osdocumentos bem elaborados feitos anteriormente para 
resolução de problemas parecidos, diminuindo o tempo de 
desenvolvimento e por conseqüência o custo para o contratante. 
 
 
 
 
6 CONSIDERAÇÕES FINAIS 
A engenharia de requisitos é sem duvida uma das etapas mais importante para 
o desenvolvimento de um software. Ainda que não garanta a qualidade do produto 
fabricado, a engenharia de requisitos e uma condição básica para que se tenha 
sucesso em um projeto de software. 
De acordo com Pressman (2011) a engenharia de requisitos constrói uma ponte 
para o projeto e para a construção. O mesmo autor informa que o processo da 
engenharia de requisitos fornece o mecanismo apropriado para compreender tudo que 
o cliente deseja no seu produto, analisando as necessidades, avaliando a viabilidade, 
negociando uma solução razoável, especificando a solução de ambiguidades, 
validando a especificação e gerenciando as necessidades. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
REFERÊNCIAS BIBLIOGRÁFICAS 
 
 PRESSMAN, R. S. Engenharia de Software – Uma Abordagem Profissional. 
07. ed. Porto Alegre: AMGH, 2011. 780 p. 
 SOMMERVILLE, I. Engenharia de Software. 09. ed. São Paulo: Pearson 
Prentice Hall, 2011. 529 p. 
 PFLEEGER, S. L. Engenharia de Software – Teoria e Prática. 02. ed. São 
Paulo: Prentice Hall, 2004. 537 p. 
 CYSNEIROS, Luiz M. Requisitos Não Funcionais: Da Elicitação ao Modelo 
Conceitual. 2001. 224f. Tese (Doutorado e Ciências da Computação) –
Departamento de Informática, Pontifício Universidade Católica do Rio de 
Janeiro, 2001. 
 
	1 INTRODUÇÃO
	2 ENGENHARIA DE REQUISITOS
	3 CLASSIFICAÇÃO DE REQUISITOS
	1. Requisitos funcionais. São declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais também p...
	3.1 REQUISITOS FUNCIONAIS
	3.2 REQUISITOS NÃO FUNCIONAIS
	4 PROCESSO DE ENGENHARIA DE REQUISITOS
	4.1 ELICITAÇÃO DE REQUISITOS
	4.2 ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
	4.3 ESPECIFICAÇÃO DE REQUISITOS
	4.4 MODELAGEM DO SISTEMA
	4.5 VALIDAÇÃO DE REQUISITOS
	4.6 GESTÃO DE REQUISITOS
	5 BENEFICIADOS DA ENGENHARIA DE REQUISITOS
	6 CONSIDERAÇÕES FINAIS
	REFERÊNCIAS BIBLIOGRÁFICAS