APS - APLICAÇÃO DA ENGENHARIA DE REQUISITOS VISANDO SUSTENTABILIDADE

Prévia do material em texto

UNIVERSIDADE PAULISTA 
 
 
Alunos: 
Juan Fagundes Vieira (F054DC-3) 
Matheus Pereira de Matos (F09647-5) 
Mateus Ferreira de Matos (F0985F-2) 
Turno: Noturno 
Período: 7º, 6º, 6º (respectivamente) 
Curso: Ciência da Computação 
 
 
 
 
 
 
 
APLICAÇÃO DA ENGENHARIA DE REQUISITOS VISANDO 
SUSTENTABILIDADE 
 
 
 
 
 
 
 
 
 
 
Goiânia – GO 
2022 
 
 
 
 
SUMÁRIO 
1. OBJETIVO 2 
2. INTRODUÇÃO 3 
3. CONCEITOS GERAIS 5 
3.1. Requisitos de software 5 
3.2. Requisitos Funcionais 5 
3.3. Requisitos não funcionais 5 
3.4. Engenharia de requisitos 6 
3.5. Elicitação 6 
3.6. Análise e negociação 7 
3.7. Especificação 7 
3.8. Modelagem 8 
3.9. Validação 8 
3.10. Gestão 9 
4. DESCRIÇÃO DE ATIVIDADES 10 
4.1. Projeto do software 11 
4.2. Requisitos de software 11 
4.3. Engenharia de requisitos 11 
4.4. Elicitação 11 
4.5. Análise e negociação 12 
4.6. Especificação 13 
4.7. Modelagem 13 
4.8. Validação 13 
4.9. Gestão 13 
5. CONCLUSÃO 15 
6. REFERÊNCIAS BIBLIOGRÁFICAS 17
2 
 
 
 
1. OBJETIVO 
 
O trabalho apresentado aqui tem como objetivo elaborar um sistema para uma 
entidade privada sem fins lucrativos chamada “Um novo amanhã”. Essa entidade 
deseja uma solução informatizada no qual será desenvolvido um sistema para efetuar 
um melhor controle sobre as informações da referida instituição. Esse trabalho está 
constituído de uma pesquisa sobre os conceitos de requisitos, engenharia de 
requisitos e seus processos, elicitação, análise e negociação, especificação, 
modelagem, validação e gestão, posteriormente foi desenvolvido uma solução no qual 
foram explorados todos os processos da engenharia de requisitos, as atividades foram 
detalhadas e as nossas conclusões foram colocadas nesse trabalho. Sistemas são 
importantes para controlar desde um simples celular até os processos mais 
importantes de um governo, por exemplo, então explorar essa área é fundamental 
para a formação de um aluno ciente das tecnologias e metodologias empregadas em 
um sistema, desenvolvimento de capacidades relacionadas à análise e solução de 
problemas, construção e prevenção dentro de um sistema, aprimorando assim suas 
qualidades e competências para o mercado de trabalho atual que exige mais 
qualidade e experiência dos candidatos. 
Então esse trabalho serve para demonstrar como o conhecimento aliado à 
prática pode ajudar a moldar um aluno capaz de produzir um sistema de acordo com 
as exigências de um cliente seguindo os processos necessários para tal finalidade. 
 
3 
 
 
 
2. INTRODUÇÃO 
 
Vivemos hoje em uma era onde tudo ao nosso redor está passando por um 
processo chamado sistematização. No nosso cotidiano, vivemos em instituições 
sistemáticas, temos equipamentos sistemáticos, até fazemos parte do sistema. O 
sistema é uma ferramenta muito poderosa para controlar informações, manipular 
dados, decidir quais ações tomar etc. 
O sistema é projetado para facilitar a organização de pessoas e instituições para 
melhorar seu desempenho e renda. Gerar sistemas de computação onde o sistema 
deve ajudar a melhorar requer conhecimento do desenvolvedor, especialmente a 
capacidade de moldar o sistema de acordo com as necessidades do cliente. Muitas 
vezes, apesar do que parece ser um processo simples, fazer um sistema não é uma 
tarefa fácil, pois se não atender fielmente as necessidades do cliente, o resultado pode 
ser desastroso. 
Desenvolver um sistema é um processo que demanda tempo e dinheiro e passa 
por diversas fases e dificuldades, dificuldades estas causadas pelos próprios clientes 
e usuários do sistema, surgem também mudanças que ocorrem dentro do ambiente 
em que o sistema será aplicado o que pode acarretar problemas durante o 
desenvolvimento do sistema e de problemas na compreensão dos objetivos e 
necessidades do cliente, acarretando erros no sistema desenvolvido. Construir um 
sistema demanda tempo, dinheiro e outros fatores como percepção, capacidades, e 
poder de adaptação às mudanças, construção de um sistema é processo em longo 
prazo em que todas as medidas e pesos devem ser alocados visando o menor impacto 
possível, isso exige responsabilidade de quem vai desenvolver o sistema. 
Os sistemas atuais são em sua grande maioria softwares que são desenvolvidos 
para atender finalidades específicas apresentadas por um cliente que necessitam 
deste serviço para auxiliar em tarefas importantes dentro de suas corporações, estes 
softwares precisam ser modelados de forma a alcançar estas finalidades para serem 
efetivos dentro da organização corporativa, e para serem efetivos são necessários 
processos que buscam compreender quais requisitos são atribuídos ao sistema, 
eliminando ao longo do caminho dúvidas sobre a utilização, necessidade e 
ambiguidade destes requisitos, também se faz necessários processos que tornam 
mais claro como o sistema irá funcionar estabelecendo as bases para o 
desenvolvimento correto, seguro e com o menor impacto sobre o produto final, é 
necessário avaliar as mudanças que podem ocorrer durante o desenvolvimento, tais 
mudanças podem alterar as funcionalidades ou até mesmo a necessidade sobre um 
requisito, esses processos fazem parte da engenharia de requisitos, um padrão 
existente dentro da engenharia de software que busca tornar o processo de 
desenvolvimento mais eficaz e menos dispendioso para alcançar os objetivos 
propostos pelo cliente. 
A engenharia de requisitos é um conjunto de seis processos: elicitação, análise e 
negociação, especificação, modelagem, validação e gestão. Cada fase compreende 
um conjunto de atividades que visa buscar a melhor compreensão possível sobre os 
requisitos do sistema solicitado pelo cliente, delas participam desenvolvedores, 
4 
 
 
 
analistas, clientes e usuários do sistema que será desenvolvido, os resultados são 
verificados e em cada processo é obtido ao término do mesmo um documento 
contendo as bases para o desenvolvimento do sistema. Esse documento é chamado 
documento de requisitos e contém todas as informações referentes aos requisitos, 
artefatos utilizados, valores de tempo e dinheiro. O documento de requisitos é sempre 
avaliado para a verificação de possíveis erros em requisitos e componentes uma vez 
que um erro que segue no projeto sua correção tem um custo alto e demandará um 
tempo maior do que o planejado. Por esta razão o documento passa por todas estas 
fases, para evitar erros, muitas vezes o processo se torna demorado devido a sua 
complexidade, por isso exige pessoas experiente e com conhecimento na área, por 
vezes é necessário que o desenvolvedor formule as questões utilizando palavras-
chave ou então para as pessoas certas que conseguirão responder de forma mais 
clara sobre as necessidades da empresa. 
Para a obtenção de um bom documento é necessário paciência, sabedoria, 
percepção e visão para conseguir entender os fatores que irão ser influenciados e irão 
influenciar o software e os motivos pelos quais tais requisitos serão utilizados. Este 
processo permite ao desenvolvedor construir de forma mais direta e específica o 
software diminuindo os riscos sobre um eventual erro e possibilitando em qualquer 
momento uma revisão das necessidades, custos e objetivos, de forma a melhorar o 
produto desenvolvido sempre buscando alcançar as metas solicitadas pelo cliente. 
 
5 
 
 
 
3. CONCEITOS GERAIS 
 
3.1. Requisitos de software 
 
Requisitos são as definições que o sistema deve atingir para a obtenção das 
metas determinadas pelos usuários aos desenvolvedores do software. Para a 
obtenção de requisitos é necessária uma abordagem que seja clara, coesa e eficiente 
para que as intenções do usuário com o software sejam compreendidas dentro de um 
contexto que pode variar no localonde este software irá funcionar e para que o 
desenvolvedor tenha uma noção de que artefatos utilizar e como utilizar estes 
recursos para chegar ao melhor produto final possível visando à aplicação no 
ambiente pretendido. Os requisitos se dividem em duas partes importantes, os 
requisitos funcionais e os requisitos não-funcionais, vamos abordar e explorar esses 
dois conceitos de requisitos. 
 
3.2. Requisitos Funcionais 
 
São geralmente expressas pelo cliente, através de notações, reuniões, 
entrevistas e outras formas de extração dos objetivos do sistema. Esses requisitos 
definem como o sistema deve se comportar em determinadas situações, com 
determinados dados e determinados tipos de entrada e saída de dados, os serviços 
que o sistema deve realizar e o que o sistema não deve realizar. 
 
3.3. Requisitos não funcionais 
 
São propriedades que o sistema naturalmente deve ter, não são especificadas 
pelo cliente, mas o desenvolvedor deve conhecê-las para garantir ao software, além 
da qualidade do serviço, especificações relacionadas ao funcionamento correto e 
adequado para melhor rodar a aplicação para que irá funcionar no ambiente. 
O processo de extração de requisitos é fundamental para o desenvolvimento 
de um produto, e um processo de extração que transmite informações sem um 
propósito claro para sua finalidade pode falhar completamente no resultado final do 
projeto, pois gasta tempo e dinheiro valiosos fazendo coisas que podem não funcionar 
corretamente conforme esperado. Isso significa que por melhor que seja um projeto, 
sem um bom entendimento dos requisitos e uma análise adequada, este não 
contribuirá para os resultados esperados. 
 
6 
 
 
 
3.4. Engenharia de requisitos 
 
Engenharia de requisitos é uma subárea da engenharia de software que surgiu na 
década de 1980 por necessidade de melhor compreensão dos requisitos de software 
e é destinada aos processos de extração, validação e manutenção de um documento 
de requisitos que é resultado de uma extensa fase de extração e análise de requisitos, 
estas fases que são necessárias para a elaboração de um documento de requisitos 
permitem identificar, detectar, visualizar erros, especifica em números os valores de 
tempo e dinheiro que serão gastos no desenvolvimento do projeto e condiciona o 
projeto em torno de um crescimento programado através de metas que tem de serem 
alcançadas de acordo com determinado tempo. 
A Engenharia de requisitos está subdividida em seis áreas: elicitação, análise e 
negociação, especificação, modelagem, validação e gestão. 
 
3.5. Elicitação 
 
A elicitação de requisitos é a pesquisa sobre os requisitos necessários ao sistema, 
o momento no qual se tornam evidentes (ou não) as necessidades que o cliente tem, 
quais os seus interesses ao obter o sistema, o ambiente em que será aplicado o 
produto, quem utilizará o sistema, qual a finalidade do sistema proposto, esses 
cenários devem ser analisados de forma a permitir a perfeita compreensão do que o 
cliente solicita auxiliar o desenvolvedor na formulação de questões mais claras e 
objetivas de acordo com o perfil do cliente e da empresa, ajudar o desenvolvedor a 
dimensionar o que realmente o cliente necessita, possibilita novas abordagens e 
novas ideias para encontrar o desejo do cliente e contribui para o início do 
desenvolvimento das atividades uma vez que desta fase se definem os objetivos do 
sistema, propriedades e qualidades. 
A elicitação para ser eficiente depende de questões bem formuladas para pessoas 
que podem definir de maneira prática as finalidades e a importância do sistema para 
aquela instituição, é uma situação que exige do desenvolvedor a capacidade de 
argumentação, capacidade de encontrar palavras-chave de acordo com o local e suas 
condições e capacidade de análise sobre a situação em que será desenvolvido o 
trabalho, uma compreensão dúbia, ambígua, malfeita sobre os requisitos irá provocar 
no futuro um sistema que não será útil às intenções da empresa, pois os requisitos 
não foram explorados de forma esperada, causando prejuízos financeiros e materiais 
e não conseguirá dar o retorno esperado pelo cliente, tornando o prejuízo maior. 
 
7 
 
 
 
3.6. Análise e negociação 
 
Essa parte da engenharia de requisitos tem como definição a solução de 
problemas que são identificados pelo desenvolvedor no documento de requisitos, 
gerado a partir da extração e identificação dos requisitos, processos que são de 
responsabilidade da elicitação de requisitos. 
O processo de análise tem como objetivo a verificação do documento de requisitos 
criado e detecção de problemas nos requisitos, estes problemas são relacionados à 
sobreposição dos requisitos, conflitos entre os requisitos, real necessidade dos 
requisitos e até mesmo a falta de algum requisito no desenvolvimento do software. 
Este processo devido a sua ampla abordagem exige que os seus participantes sejam 
experientes na área de atuação do software, não é um processo simples, trata-se de 
um longo processo para identificar todos os possíveis problemas, pode ser usado 
nesta fase o checklist, que é um formulário criado pelo desenvolvedor com o intuito 
de avaliar o que realmente é necessário verificar em certo item do requisito, é uma 
forma de se priorizar o que deve ser observado. Outra forma de análise é o protótipo 
que possibilita aos interessados no sistema ter uma ideia de como o sistema irá 
funcionar, é voltada para as funcionalidades que o sistema irá exercer e possibilita 
uma boa visão sobre quais requisitos são realmente importantes ou não. A negociação 
tem como função a solução dos problemas verificados na análise, ajustando as 
necessidades do cliente aos requisitos que podem contribuir no desenvolvimento do 
sistema descartando os menos relevantes, definição de prioridade e solução de 
problemas relacionados aos conflitos entre requisitos, desta etapa é criado um novo 
documento de requisitos, mais efetivo e direto em relação aos objetivos do cliente, 
permitindo ao desenvolvedor uma melhor perspectiva sobre como deve ser conduzido 
o seu trabalho. 
 
3.7. Especificação 
 
O processo de especificação de requisitos tem como objetivo principal tornar claro 
qual o papel exercido de cada requisito dentro do contexto de um sistema. Oriundos 
de fases anteriores, a especificação visa definir quais requisitos serão utilizados 
dentro do sistema, como eles serão testados, como eles serão implementados e como 
os usuários poderão verificar seu desempenho. Essas decisões são tomadas pelos 
desenvolvedores com base nas fases anteriores da engenharia na qual eles buscam 
extrair os requisitos e solucionar problemas oriundos da fase de extração, tais 
decisões precisam ser apresentadas para os clientes de forma que eles possam 
validar o documento de especificação de requisitos, que contém o objetivo principal 
desta fase que é esclarecer de forma objetiva o que todos os requisitos devem fazer 
suas funcionalidades e qualidades. Além do documento de especificação outra forma 
utilizada atualmente para a especificação de requisitos é o diagrama de caso de uso 
que da mesma maneira que o documento especifica qual o comportamento esperado 
de cada requisito no software. 
8 
 
 
 
Para tal finalidade é utilizado o UML, uma linguagem destinada à modelagem de 
requisitos que possibilita uma definição sobre o que o sistema tem de realizar para 
alcançar o resultado esperado, o caso de uso especifica a sequência de ações que o 
sistema deve realizar para chegar ao objetivo, porém não mostra como o sistema 
realiza cada passo para conseguir tal resultado, para cada caso de uso são 
necessários três componentes importantes, o ator que representa os clientes dentro 
do sistema e que faz a interação por sua vez com os casos de uso que identificam as 
funcionalidades exigidas no sistema e o próprio sistema que é o conjunto de casos de 
usos. Aespecificação é uma atividade que procura determinar como cada requisito 
deve agir para obter o resultado esperado no software, é, portanto, de fundamental 
importância para o produto final uma vez que a definição procura estabelecer de forma 
clara e objetiva o papel de cada requisito e sua contribuição dentro do sistema. 
 
3.8. Modelagem 
 
A modelagem de requisitos é uma prática fundamental na engenharia de 
requisitos, cujo objetivo principal é mostrar como os requisitos se comportam em um 
sistema, ou seja, a modelagem é uma forma de representar a sequência de operações 
que um requisito deve realizar para atingir um objetivo desejado. Um diagrama de 
caso de uso na modelagem aplicada é um modelo gráfico detalhado no qual todas as 
ações são especificadas dentro da perspectiva do cliente e do desenvolvedor. 
Representando o papel do cliente no sistema e interagindo com o sistema, essa 
interação é representada por linhas, enquanto as esferas representam as ações 
específicas esperadas pelos requisitos. Na modelagem, além dos gráficos, usamos 
linguagem escrita para especificar o que é cada ação, suas propriedades e 
características. 
A modelagem possibilita uma especificação mais detalhada dos requisitos através 
de uma perspectiva mais bem definida e caracterizada de cada item, a modelagem 
foca caracterizar as funcionalidades do sistema permitindo uma extração mais clara e 
eficaz dos requisitos, a modelagem dá condições de visualização do sistema do ponto 
de vista do usuário e serve como referência para uma melhor definição dos requisitos, 
é também uma base para comunicação entre desenvolvedores, analistas e usuários 
do sistema porque fornece uma visualização mais delineada do sistema tornando mais 
fácil a compreensão de cada ação dentro de um requisito. 
 
3.9. Validação 
 
A validação de requisitos é responsável por executar uma verificação no 
documento de requisito que foi elaborado em fases anteriores na engenharia de 
requisitos e tem como objetivo encontrar problemas dentro do documento uma vez 
que o documento de requisitos é a base para a elaboração do sistema e um problema 
que seja identificado tardiamente dentro do processo de desenvolvimento do software 
9 
 
 
 
pode gerar custos muito altos para o seu reparo, ou seja, o processo de validação 
permite encontrar os problemas antes que estes sejam detectados em fase avançadas 
ou até mesmo com o sistema pronto para uso. Os problemas podem ser de 
inconsistência, incompletude e ambiguidade. A inconsistência pode causar problemas 
relacionados a descrições diferentes para os mesmos requisitos dentro de um 
sistema, a ambiguidade pode gerar problemas de incerteza e dúvidas sobre quais 
ações o sistema está programado para atuar e a incompletude está relacionado com 
a existência de todas as funcionalidades e restrições esperadas pelo cliente. 
No entanto, isso acontece em paralelo com outros processos de engenharia, pois 
alguns processos são projetados para validar requisitos e analisar seus requisitos 
reais, uma forma interessante de fazer isso também nesta fase é um checklist, que 
faz uma série de perguntas importantes para identificar problemas no projeto. Erros 
em relação às suas necessidades e requisitos do formulário de inscrição. 
Esta etapa não é simples e requer a participação de alguém experiente na área de 
trabalho do sistema para melhor capturar os erros de requisitos antes da validação, o 
resultado desta etapa é a criação de um documento de validação de requisitos no qual 
clientes, desenvolvedores e analistas validam como um guia de projeto escrito para 
criar o sistema e confirmar que esses são os requisitos reais conforme necessário e 
quais artefatos serão usados para construir o produto. 
 
3.10. Gestão 
 
A gestão é a última das seis atividades do processo de engenharia de requisitos e 
a finalidade dessa fase do processo é gerenciar os requisitos ao longo do processo 
de desenvolvimento do software. No desenvolvimento de um determinado produto 
pode haver mudanças nos requisitos pelas mais diversas situações como erros ou 
requisitos mal identificados, podem ocorrer devido a mudanças no ambiente de 
aplicação ou até mesmo o desenvolvedor pode implementar uma funcionalidade extra 
no sistema, tais mudanças nos requisitos devem ser verificadas para que se possa 
fazer alterações certas de forma a não prejudicar aquele requisito e não comprometer 
a funcionalidade do sistema. 
Para a gestão de requisitos ocorrerem é definido uma política, ou seja, uma série 
de objetivos que devem ser alcançados no processo de gestão de requisitos. A gestão 
é responsável por verificar o controle de versões de um sistema, uma vez que o 
mesmo está baseado em requisitos que funcionam juntamente com artefatos 
adequados para tais requisitos, uma vez modificados algumas características destes 
requisitos, tais artefatos podem não aceitar as novas configurações dos requisitos 
necessitando assim de uma nova versão do artefato capaz de aceitar e funcionar com 
essas alterações, essas mudanças de versões de artefatos também deve ser 
gerenciado para que todos os envolvidos no projeto possam ter a mesma versão do 
sistema. Temos sob o controle da gestão a gerência de controle de configuração de 
software que visa manter o controle de quais artefatos e componentes são atrelados 
a cada uma das configurações do software. Outra atividade da gestão é a 
10 
 
 
 
rastreabilidade de requisitos, que tem como função verificar a evolução do requisito 
desde sua descoberta até o desenvolvimento dele, verificando suas ligações com 
outros requisitos visando a identificações de relacionamentos hierárquicos entre os 
requisitos e a relação de dependência entre requisitos e os artefatos. A gestão é 
fundamental no processo para identificar as mudanças de requisitos, controlar as 
versões e controlar suas configurações permitindo uma interação e possibilitando uma 
estratégia de mudança adequada para que nenhum requisito seja prejudicado 
perdendo seu valor dentro do sistema. 
 
11 
 
 
 
4. DESCRIÇÃO DE ATIVIDADES 
 
4.1. Projeto do software 
 
Foi desenvolvido um projeto com a seguinte metodologia: utilização do padrão 
RUP elaborados em etapas as quais serão mostradas no trabalho. 
Para termos uma visão mais ampla foi aplicada o uso de UML, para 
desenvolvimento da documentação de modelagem de software. 
 
4.2. Requisitos de software 
 
Por meio de reuniões devidamente documentadas através de questionários foi 
definido como iriamos desenvolver o software para aplicação e controle de acordo 
com a necessidade do cliente. 
Posteriormente fizemos uma reunião com cliente e os usuários para demostrar a 
aplicabilidade do sistema (protótipo) e ficamos aberto a opiniões e questionamento. 
Após essa reunião, tivemos o conceito de como o sistema iria funcionar na prática e 
posteriormente fizemos as adequações para um bom funcionamento para que este 
tivesse rapidez, facilidade. Sendo assim, reduzimos ao máximo os erros na operação 
das tarefas e com isso obtemos a satisfação do cliente. 
 
4.3. Engenharia de requisitos 
 
Com o padrão de engenharia de requisitos, possibilitou ao cliente um melhor 
entendimento e facilidade nos quesitos funcionalidade e qualidade e assim atendeu a 
sua necessidade. 
 
4.4. Elicitação 
 
Nesta etapa foram levantados, identificados e definidos o desenvolvimento do 
projeto de software, com base e levantamento como citado acima (formato de 
documentação). 
Foram feitas questões mais claras e objetivas de acordo com o perfil do cliente e 
da empresa como forma de obter informações de forma a permitir a perfeita 
compreensão do que o cliente solicita auxiliar o desenvolvedor dimensionar o que 
realmente o cliente necessita sendo assim conseguimos observar os problemas 
existentes como controle manuais o que afeta a agilidade e a integridade das 
12 
 
 
 
informações financeiras,cadastrais, estoque e vendas e tudo isso acarreta um 
descontrole total. 
A elicitação foi eficiente devido as questões bem formuladas. Com isso definiu-se 
de maneira pratica as finalidades e a importância do sistema para a entidade “Um 
novo amanhã”. Com isso foi encontrado palavras-chave e argumentos dentro das 
condições e a capacidade de análise para o desenvolvimento do trabalho. Isso evitou 
uma compreensão dúbia, ambígua e malfeita sobre os requisitos, que possivelmente 
provocaria no futuro um sistema que não seria útil às intenções da instituição, tendo 
então evitado prejuízos financeiros e materiais futuros. 
 
4.5. Análise e negociação 
 
Constatado o problema, podemos então identificar os requisitos e a solução dos 
problemas, processos que são de responsabilidade da elicitação de requisitos, por 
meio de documentação de requisitos, gerado a partir da extração e identificação dos 
requisitos. 
Com o processo de análise chegamos ao objetivo de verificação do documento de 
requisitos. Criado e detectado os problemas nos requisitos, esses problemas são 
relacionados à sobreposição dos requisitos, conflitos entre os requisitos, real 
necessidade dos requisitos e até mesmo a falta de algum requisito. 
Com a vasta experiência que o quadro de funcionários que a empresa MWG 
SOFTWARE possui foi possível chegar em uma conclusão mais rapidamente pois não 
é um processo simples, trata-se de um longo processo para a identificação de todos 
os possíveis problemas. Usamos nesta fase o checklist, que é um formulário que foi 
criado pelo desenvolvedor com o intuito de avaliar o que realmente é necessário 
verificar pois em um certo item do requisito, foi uma forma de priorizar o que foi 
observado. 
Com o protótipo possibilitou uma outra forma de análise e uma ideia de como o 
sistema funcionou, focou as funcionalidades que o sistema exerceu e possibilitou uma 
boa visão sobre quais requisitos são realmente importantes ou não. 
A negociação teve como função a solução dos problemas verificados na análise, 
ajustando as necessidades do cliente aos requisitos que contribuíram no 
desenvolvimento do sistema descartando os menos relevantes, definição de 
prioridade e solução de problemas relacionados aos conflitos entre requisitos, desta 
etapa foi criado um documento de requisitos, mais efetivo e direto em relação aos 
objetivos do cliente, nos permitiu uma melhor perspectiva sobre a conduta o seu 
trabalho. 
 
13 
 
 
 
4.6. Especificação 
 
Com processo de especificação de requisitos teve como objetivo principal tornar 
claro qual é o papel exercido de cada requisito dentro do contexto do sistema. 
Originários de fases anteriores, a especificação visou definição quais requisitos foram 
utilizados dentro do sistema, como eles foram testados, como eles foram 
implementados e como os usuários verificam seu desempenho. Essas decisões foram 
tomadas pela MWG SOFTWARE com base nas fases anteriores da engenharia na 
qual eles extraíram os requisitos e solucionaram os problemas oriundos da fase de 
extração. Tais decisões foram apresentadas para a ONG usada nesse trabalho de 
forma que eles validaram o documento de especificação de requisitos. Aqui continha 
o objetivo principal desta fase: esclarecer de forma objetiva o que todos os requisitos 
exerceram, tais como suas funcionalidades e qualidades. Além do documento de 
especificação outra forma que foi utilizada para a especificação de requisitos foi o 
diagrama de caso de uso que da mesma maneira que o documento especificou qual 
foi comportamento esperado de cada requisito no software. 
Para tal finalidade foi utilizado o UML, uma linguagem destinada a modelagem de 
requisitos que possibilitou uma definição sobre o que o sistema realizou para alcançar 
o resultado esperado. O caso de uso especificou a sequência de ações que o sistema 
realizou para chegar ao objetivo, porém não é mostrado como o sistema realiza cada 
passo para conseguir tal resultado. Para cada caso de uso foram necessários dois 
componentes importantes: o ator que representou os clientes dentro do sistema e que 
faz a interação por sua vez com os casos de uso que identificou as funcionalidades 
exigidas no sistema e o próprio sistema que foi o conjunto de casos de usos. 
 
4.7. Validação 
 
 A verificação de requisitos é responsável pela verificação dos documentos de 
requisitos elaborados em etapas anteriores da engenharia de requisitos com o objetivo 
de desvendar possíveis problemas nos documentos, pois os documentos de requisitos 
são a base para a descrição detalhada do sistema, e possíveis problemas podem ser 
encontrados posteriormente em O processo de desenvolvimento de software terá 
custos de manutenção muito altos, ou seja, o processo de verificação permite que os 
problemas sejam descobertos antes mesmo de serem detectados, antes mesmo que 
o sistema esteja pronto para uso. O principal método de verificação de requisitos é a 
revisão técnica, que consiste em engenheiros de software, clientes e usuários. 
4.8. Gestão 
 
O gerenciamento é a última das seis atividades do processo de engenharia de 
requisitos, o objetivo desta fase do processo é gerenciar os requisitos ao longo do 
processo de desenvolvimento de software. Neste desenvolvimento de produto, os 
14 
 
 
 
mais diversos casos de alterações de demanda, como a demanda por erros ou erros 
de identificação, ocorrem devido a alterações no ambiente da aplicação ou até mesmo 
a MWG SOFTWARE implementa funções adicionais no sistema, esta demanda 
Alterações são verificadas para poder ser alterado para não quebrar o requisito e não 
comprometer a funcionalidade do sistema. 
Para o gerenciamento de requisitos, é definida uma estratégia, que é um conjunto 
de metas a serem alcançadas durante o processo de gerenciamento de requisitos. A 
gerência é responsável por validar o controle de versão do sistema, pois é baseado 
na necessidade de trabalhar com artefatos adequados a tais necessidades. Temos 
sob o controle da gestão a gerência de controle de configuração de software que 
visamos manter o controle de quais artefatos e componentes são atrelados a cada 
uma das configurações do software. 
 
15 
 
 
 
5. CONCLUSÃO 
 
A engenharia de requisitos é uma série de atividades com um total de seis etapas 
diferentes: inspiração, análise e negociação, especificação, modelagem, validação e 
gerenciamento. A engenharia de requisitos é aplicada ao processo de produção de 
software com o objetivo de construir softwares com segurança, evitando bugs e erros. 
A ideia é projetar o produto com a maior qualidade possível. Desde as primeiras 
atividades, a engenharia de requisitos busca tirar dúvidas sobre o produto e deixar o 
mais claro possível a intenção do cliente e as reais necessidades relacionadas ao 
produto. A engenharia de requisitos permite a participação de todos os envolvidos. 
Entre os projetos que efetivamente buscam os melhores resultados em relação ao 
produto, possui algumas etapas mais demoradas devido à complexidade do processo, 
mas é a melhor forma de auxiliar e projetar o desenvolvimento de software. 
O resultado da engenharia de requisitos é o documento de requisitos que é 
formulado na elicitação e vai sendo aprimorado, revisado e analisado, se necessário 
o documento retorna para as fases anteriores para correção de erros detectados pois 
uma vez um erro descoberto em uma fase tardia pode prejudicar o software tornando 
o produto ineficiente do ponto de vista do cliente, perdendo assim quantias valiosas 
de tempo e dinheiro. 
Foi abordado neste trabalho o processo de planejamento e desenvolvimento de 
software para uma organização sem fins lucrativos que recolhe crianças de rua, e são 
ministrados cursos com o objetivo de educá-las e treiná-las para serem 
ecologicamente corretas e produzidas adequadamente com materiais recicláveis de 
brinquedo pela agência orientada por professoresde ex-alunos que ensinam e 
confeccionam brinquedos no Brasil e no exterior. 
A instituição é fundamental em seu trabalho, pois exige um melhor controle do 
sistema financeiro, dos dados de alunos e funcionários e da instituição. Desde então 
pesquisamos bastante para tentar entender as etapas de fabricação do produto e a 
aplicação em nossas instalações. Desenvolvemos então um sistema para controlar 
essas informações de forma sucinta para atender da melhor forma possível as 
necessidades e objetivos reais da empresa. Consideramos as etapas de modelagem 
e extração dos requisitos, e ao final do processo foi criado o resultado obtido. Um 
sistema muito simples e prático que pode atender de forma eficiente e rápida as 
necessidades da entidade, melhorando assim o controle geral sobre toda a instituição, 
tornando-a mais equilibrada para o desenvolvimento e alinhando as finanças com a 
capacidade institucional. 
O uso da modelagem proporciona ao desenvolvedor a capacidade de se adaptar 
e desenhar a situação da aplicação, além de proporcionar uma visão ampla do projeto 
a ser criado, dando condições para que o desenvolvedor faça correções, evitando 
perdas futuras no cronograma do projeto. Além disso, pode-se constatar a importância 
da engenharia de requisitos para o produto final, no que tange o desenvolvimento do 
software, pois suas etapas nos forneceram uma visão clara e objetiva sobre o que 
16 
 
 
 
fazer para alcançar o objetivo final contribuindo para o crescimento e desenvolvimento 
da instituição trabalhada neste projeto. 
17 
 
 
 
REFERÊNCIAS BIBLIOGRÁFICAS 
 
http://www.subrotina.com.br/a-importancia-dos-requisitos-nao-funcionais/ acessada 
em 02/04/2022 22:12 
 
https://www.ibm.com/developerworks/community/blogs/tlcbr/entry/boas_praticas_par
a_a_elicitacao_de_requisitos?lang=en acessada em 02/04/2022 00:12 
 
http://twiki.fe.up.pt/twiki/pub/ERSS0506/ErssDocumentos0506/er-analise.pdf 
acessada em 02/04/2022 00:50 
 
http://www.macoratti.net/07/12/net_fer.htm acessada em 09/04/2022 23:14 
 
http://www.dimap.ufrn.br/~jair/ES/c4.html acessada em 09/04/2022 23:15 
 
http://www.apinfo.com/artigo68.htm acessada em 15/04/2022 23:15 
 
http://mastersoft.com.br/Tutoriais/Mastermodel/ModelagemRequisitos/LevModelReq.
PDF acessada em 17/04/2022 00:02 
 
http://www.dimap.ufrn.br/~flavia.delicato/ModeloRequisitosCasosdeUSos.pdf 
acessada em 17/04/2022 00:05 
 
http://www.cin.ufpe.br/~in1020/arquivos/monografias/2007-
2/Monografia_ValidacaoRequisitos_AlbertoLima.pdf acessada em 17/04/2022 18:43 
 
https://www.infoescola.com/engenharia-de-software/rup/ acessada em 17/04/2022 
16:30 
 
https://leonwgn.wordpress.com/2010/11/05/rup-rational-unified-process/ acessada 
em 17/04/2022 16:42 
 
http://pt.slideshare.net/mauricioastiazara/gerencia-de-requisitos acessada em 
29/04/2022 19:33 
http://www.subrotina.com.br/a-importancia-dos-requisitos-nao-funcionais/
https://www.ibm.com/developerworks/community/blogs/tlcbr/entry/boas_praticas_para_a_elicitacao_de_requisitos?lang=en
https://www.ibm.com/developerworks/community/blogs/tlcbr/entry/boas_praticas_para_a_elicitacao_de_requisitos?lang=en
http://twiki.fe.up.pt/twiki/pub/ERSS0506/ErssDocumentos0506/er-analise.pdf
http://www.macoratti.net/07/12/net_fer.htm
http://www.dimap.ufrn.br/~jair/ES/c4.html
http://www.apinfo.com/artigo68.htm
http://mastersoft.com.br/Tutoriais/Mastermodel/ModelagemRequisitos/LevModelReq.PDF
http://mastersoft.com.br/Tutoriais/Mastermodel/ModelagemRequisitos/LevModelReq.PDF
https://www.infoescola.com/engenharia-de-software/rup/
https://leonwgn.wordpress.com/2010/11/05/rup-rational-unified-process/
18 
 
 
 
 
http://www-di.inf.puc-rio.br/~karin/prominp/index_files/gerencia_req.pdf acessada em 
29/04/2022 19:37 
 
PRESSMAN, Roger S. Engenharia de software/; uma abordagem profissional. 7 ed. 
Porto Alegre: AMGH, 2011. 
 
19 
 
 
 
RUP (Rational Unified Process – Processo Unificado Relacional) 
 
O Rational Unified Process - RUP que traduzido para o português significa 
Processo Unificado Rational, é um processo de engenharia de software. Com o 
objetivo de garantir um software de alta qualidade que, dentro de um cronograma e 
um orçamento previsíveis, atendam às necessidades dos seus usuários finais, o RUP 
fornece uma abordagem disciplinada para a atribuição de tarefas e responsabilidades 
na organização do desenvolvimento. Utiliza a linguagem UML no desenvolvimento dos 
casos de uso e a orientação a objetos. 
 
Arquitetura do RUP 
 
Nesta seção será apresentada a arquitetura do RUP composta por dimensões e 
fases. 
 
Dimensões 
 
O RUP apresenta duas dimensões, a dinâmica e a estática, como mostra a figura 
a seguir: 
 
Figura 1 – Dimensões do RUP. 
 
Fonte: Leonwag's Blog (2011) 
 
20 
 
 
 
A dimensão horizontal representa o aspecto dinâmico do processo, o ciclo de vida. 
Essa dimensão faz com que o projeto do software seja elaborado com uma sequência 
de iterações incrementais. A dimensão vertical representa o aspecto estático, descrito 
em termos de componentes do processo: atividades, disciplinas, artefatos e papéis do 
processo. 
 
Dimensão Dinâmica 
 
A arquitetura do RUP apresenta quatro fases no aspecto dinâmico: concepção, 
elaboração, construção e transição, como apresenta a figura 2. Essas fases podem 
conter várias iterações. 
 
Figura 2 – Arquiteturas das fases do RUP. 
 
Fonte: Infoescola (2021) 
 
As quatro fases do RUP 
 
A Concepção é a fase da criação do escopo do projeto; nela é realizada a avaliação 
de risco, uma estimativa dos recursos necessários e o cronograma dos marcos 
temporal mais importante. Todos os atores envolvidos na iteração do sistema também 
são identificados nesta fase. Nesta fase são desenvolvidos, também, os seguintes 
artefatos: 
 
Caso de negócio inicial; 
Formulação do documento de visão geral dos requisitos do projeto; 
Relatório inicial de avaliação de risco; 
21 
 
 
 
Estimativa de recursos; 
Cronograma inicial; 
Protótipos iniciais. 
 
A elaboração é a especificação e eliminação dos pontos de maior risco. Nesta fase 
são desenvolvidos os seguintes requerimentos: 
Modelo de casos de uso; 
Análise e projeto do sistema; 
Relatórios de riscos; 
Plano de gerenciamento; 
Alocação da equipe; 
Planejamento das fases, mostrando suas iterações e conteúdos. 
 
Realiza-se a análise do domínio do problema e projeta uma arquitetura para o 
sistema. 
A construção é o início do desenvolvimento do sistema, ao final de cada ciclo, pode 
surgir uma versão utilizável do processo. Nesta fase são desenvolvidos os seguintes 
requerimentos: 
Sistema de software funcionando e documentação associada pronta para ser liberada 
aos usuários; 
Casos de teste baseados em cenários, e resultados de testes; 
Por último a transição: implantação do software e transferência do software para o 
usuário do sistema. 
 
A Linguagem UML 
 
A Unified Modeling Language - UML é uma especificação da Object Management 
Group – OMG. É uma linguagem gráfica de modelagem para visualizar, especificar, 
construir e documentar os artefatos de sistemas de objetos distribuídos. 
A UML possui treze modelos gráficos que estão divididos em duas categorias, os 
diagramas de aplicações estáticas que representam a estrutura e os diagramas de 
comportamentos, no entanto dentro desta última categoria, existe uma subcategoria 
que compõe os diagramas de interação. 
22 
 
 
 
A categoria de diagramas de Estrutura inclui diagrama de classe, diagrama de 
objeto, diagrama de componentes, diagrama de estrutura composta, diagrama de 
pacote e diagrama de utilização. 
Os diagramas de Comportamento são: diagrama de caso de uso, diagrama de 
máquina de estados e diagrama de atividades. Em sua subcategoria Interação estão 
inclusos os diagramas de sequência, comunicação, visão geral de interação e por 
último, porém não menos importante o de temporização. 
 
Principais DiagramasUML 
 
Os diagramas UML abordados neste projeto são os de: Caso de Uso, Sequência, 
Atividade, Classe, Estado e Utilização. 
 
23 
 
 
 
FICHAS 
 
 
Aluno: Juan Fagundes Vieira 
 
 
Aluno: Mateus Pereira de Matos 
24 
 
 
 
 
Aluno: Mateus Ferreira de Matos