SlideShare uma empresa Scribd logo
1 de 7
Baixar para ler offline
OS ASPECTOS MAIS RELEVANTES DA ENGENHARIA DE REQUISITOS
José Edilson Vieira Júnior - UAM-SP (edilsonv12@gmail.com)
Resumo
Este artigo busca explicar os aspectos mais relevantes da Engenharia de Requisitos, sua
importância para a Engenharia de ​Software​, suas tarefas e os princípios para uma boa
especificação. A Engenharia de Requisitos é conhecida há muito tempo, desde os anos 80 e,
atualmente, tem-se um cenário muito mais propício para sua atuação, utilizando-se da evolução
da tecnologia e do desenvolvimento de ​software​. A Engenharia de Requisitos é considerada por
muitas bibliografias como um método pelo qual se consegue decompor uma informação de
negócio em necessidades que precisam ser desenvolvidas e apresentadas dentro de sistemas
automatizados. O objetivo desta pesquisa foi conhecer os propósitos da Engenharia de Requisitos
no Desenvolvimento de ​Software ​e também na compreensão, organização e planejamento de um
novo projeto.
Palavras-chaves: ​Análise de Requisitos, Engenharia de ​Software​, Gestão.
Introdução
A Engenharia de Requisitos é de grande importância econômica para a indústria de
software​. O custo para corrigir erros nos requisitos tende a aumentar exponencialmente quanto
mais tempo eles permanecem não detectados. Os responsáveis pelos projetos desperdiçam
grande quantidade de recursos quando fazem suposições equivocadas sobre as necessidades dos
clientes. Como consequência, existe um risco considerável envolvido na Engenharia de
Requisitos, mas a maturidade de seus processos está muito além dos processos do ciclo de vida
de um ​software​. Isso é agravado pelo fato de que a Engenharia de Requisitos é rigorosamente
limitada ao tempo e aos recursos da etapa de análise de requisitos, geralmente percebido de
maneira errônea como tempo improdutivo.
A questão de quem deve executar a Engenharia de Requisitos é controversa. Sua
execução requer um conjunto de habilidades que se cruzam com a Engenharia de ​Software​, mas
que também inclui habilidades fora deste conjunto. Por este motivo, nomeia-se engenheiro de
requisitos quem faz a execução da Engenharia de Requisitos. Isso não que dizer que engenheiros
de ​software ​não possam “fazer” a Engenharia de Requisitos, mas sim enfatizar que o papel do
engenheiro de requisitos é distinto entre o domínio do desenvolvimento e o domínio do cliente
de ​software​.
1 Processo Geral da Engenharia
Os termos Engenharia de Requisitos e Engenharia de ​Software ​fazem uso adequado do
termo geral Engenharia, uma vez que estão extremamente ligados à aquisição e aplicação de
conhecimento para criação, aperfeiçoamento e implementação de sistemas de informação. O
Museu de Ciência de Boston possui um programa que busca apresentar aos jovens o que é
Engenharia e descreve um processo geral sobre ela, como sendo:
1. Pergunte: neste passo, a ideia é entender bem o que é o problema, o que os outros fizeram
e quais as restrições existentes, ou seja, deve-se ter uma visão clara do problema para que
uma solução possa ser proposta. Para isso, é fundamental saber perguntar;
2. Imagine: uma vez que se tem uma visão clara do problema, deve-se imaginar as possíveis
soluções para o mesmo. Em geral, todo problema tem várias soluções possíveis. É
importante que se consiga pensar em mais de uma possibilidade, avaliando o que é
melhor, dada as restrições conhecidas;
3. Planeje: tendo a solução definida, o próximo passo é planejar, que significa tanto detalhar
a solução encontrada quanto definir o trabalho necessário para entregar esta solução;
4. Crie: com base no planejamento, o próximo passo é construir a solução. Uma vez que a
solução foi construída e entregue, deve-se fazer um acompanhamento, pois dificilmente
entrega-se uma solução perfeita;
5. Melhore: baseado na percepção do funcionamento do sistema, deve-se retornar ao passo
inicial do ciclo, perguntando o que funcionou bem, o que não foi bem e o que há de novo
no cenário que exige adaptações no sistema.
Este processo é um ciclo que representa bem o que ocorre na Engenharia de Requisitos e,
não necessariamente, tem um único ponto de início.
2 A Engenharia de Requisitos
A Engenharia de Requisitos começa com alguns pontos importantes que são a
organização, a compreensão e o planejamento dos requisitos. Existem três tipos de requisitos, os
chamados funcionais, não-funcionais e os requisitos de domínio. Além disso, a atividade de
gerência dos requisitos é dividida em tarefas (sete, especificamente): concepção, levantamento,
elaboração, negociação, especificação, validação e gestão de requisitos.
Um requisito pode ser definido como uma declaração abstrata de alto nível de um
serviço, uma restrição de sistema ou até mesmo uma especificação funcional detalhada. Como
citado anteriormente, existem três tipos de requisitos:
● Funcionais: representam uma descrição da funcionalidade e serviços do sistema;
● Não-funcionais: representam uma descrição de propriedades, restrições do sistema,
qualidade e também podem especificar linguagens de programação, método de
desenvolvimento, etc. Devido à sua própria definição, estes requisitos são esperados
mensuráveis e deve-se associar formas de medida/referência a cada um deles elicitados.
Os requisitos não-funcionais podem ser:
○ De produto: especificações referentes ao produto;
○ De organização: referentes a políticas e procedimentos organizacionais;
○ Externo: referentes a fatores externos, como por exemplo legislação.
● Domínio: referentes ao domínio de aplicação. Descrevem características do sistema e
qualidades de acordo com o domínio.
A compreensão correta do problema se torna muito difícil às vezes, especialmente se o
sistema for novo. Por esta razão, utiliza-se a Engenharia de Requisitos, que pode ser definida
como o processo de descobrir, analisar, documentar e verificar os requisitos (Sommerville,
2008).
2.1 Características da Engenharia de Requisitos
Durante a Engenharia de Requisitos podem aparecer alguns problemas decorrentes da
falta de separação nítida entre os dois diferentes níveis de descrição. Estes níveis podem ser
distinguidos utilizando-se os termos requisitos de usuário para os requisitos abstratos de alto
nível e requisitos de sistema para indicar a descrição detalhada das funcionalidades do sistema.
Pode ser produzida ainda uma descrição mais detalhada associando a Engenharia de Requisitos
às atividades de projeto. Para Sommerville (2008), estes dois níveis de requisitos e a
especificação de projeto de ​software ​podem ser definidos do seguinte modo:
● Requisitos de usuário: são declarações em linguagem natural e diagramas contendo as
funcionalidades e as restrições sob as quais o sistema deve operar. Esse documento é
escrito para gerentes do cliente e dos fornecedores que não tenham conhecimento técnico
detalhado do sistema;
● Requisitos de sistema: detalham funcionalidades e restrições. Este documento pode
inclusive servir como um contrato entre as partes envolvidas no projeto. Ele é escrito para
os profissionais técnicos de nível sênior e para gerentes de projeto;
● Especificação de projeto de ​software​: é uma descrição abstrata do projeto de ​software ​na
qual se acrescenta mais detalhes aos requisitos do sistema. Este documento é escrito para
os engenheiros de ​software ​que desenvolverão o sistema.
2.2 O propósito dos requisitos em um sistema
No escopo geral, requisito é a condição que se deve satisfazer para alcançar certo fim, ou,
até mesmo, uma exigência de ordem legal para que determinado processo possa ter andamento.
No contexto da Engenharia de ​Software podemos definir requisito como “o que” este sistema
deve fazer, quais as restrições sobre as operações deste sistema ou, ainda, quais são as regras de
negócio deste sistema.
Normalmente, antes de um sistema existir, é necessário entender quais são os seus
requisitos para depois desenvolvê-lo. No entanto, se um sistema já existe e precisa ser
modificado, também é necessário entender os requisitos desse sistema e dessa modificação, para
que essa modificação seja desenvolvida.
Geralmente, existe um demandante do sistema, ou seja, um indivíduo ou uma empresa
responsável que fornece os requisitos. Os requisitos podem ser fornecidos pelo cliente, futuros
usuários e os demais envolvidos no projeto. Para coletar esses requisitos, o analista deve fazer
diversas reuniões com o demandante, aplicando técnicas para levantamento de requisitos,
filtrando todas as informações possíveis para que, posteriormente, o ​software ​possa ser
desenvolvido corretamente. Parece fácil, mas na prática não é. Isso depende muito da
comunicação entre o demandante e o analista.
3 Princípios de uma boa especificação e Tarefas da Engenharia de Requisitos
Segundo Balzer, Goldman e Wile (1978), existem princípios de uma boa especificação de
requisitos. Deve-se:
1. Separar funcionalidades da implementação, uma vez que a implementação é uma outra
etapa da Engenharia de ​Software​;
2. Haver uma linguagem de especificação orientada ao processo de desenvolvimento;
3. Abranger o sistema do qual o ​software ​é um componente;
4. Abranger o ambiente no qual o sistema opera;
5. Ser um modelo cognitivo;
6. Ser operacional;
7. Ser tolerante com a não completude, além de ser expansível;
8. Ser localizado e fracamente acoplado.
A especificação é uma parte muito importante na Engenharia de Requisitos. No entanto, é
necessário proceder com as tarefas para uma boa gerência e modelagem dos requisitos. Abaixo,
as atividades destas tarefas são descritas:
● Concepção: escopo, domínio de aplicação, entendimento básico do problema e percepção
geral de uma solução;
● Levantamento: objetivos/abrangência do sistema, necessidades de diferentes usuários e
uso do sistema;
● Elaboração: modelagem de análise (modelagem e refinamento), criação do modelo de
análise que define o domínio do problema informacional, funcional e comportamental
(refinamento das funções, características e restrições);
● Negociação: resolver conflitos, avaliar impactos (custo de projeto, prazos de entrega) e
alcançar satisfação;
● Especificação: criação do modelo escrito, fundamento das atividades seguintes da
Engenharia de ​Software ​e descrição de funções, desempenho e restrições;
● Validação: garantir que os requisitos estejam claros, abstrair inconsistências e erros,
revisar tecnicamente o projeto e aplicar um ​check list ​sobre as questões do projeto;
● Gestão de requisitos: identificar, controlar e rastrear modificações durante a vida do
projeto, atribuir um modo identificador e desenvolver tabelas de rastreamento.
4 A Importância da Engenharia de Requisitos
A Engenharia de Requisitos é implementada em projetos de ​software ​para que hajam
melhorias nos processos de desenvolvimento. O desenvolvimento e modificações de ​softwares
são atividades complexas e, por mais que as tecnologias tenham alcançado um nível superior,
ainda são grandes os números de projetos que falham ou que são considerados problemáticos em
relação às necessidades de um cliente.
A implementação da Engenharia de Requisitos é um dos fatores críticos para alcançar o
sucesso em projetos, aumentando as chances de satisfação dos clientes e de todos os envolvidos,
além de reduzir falhas, erros, prejuízos e aumentar a qualidade do ​software​. Em projetos de
software​, a Engenharia de Requisitos visa a entrega de produtos com qualidade e conformidade
nos requisitos.
5 Considerações Finais
A principal medida de sucesso de um sistema de ​software ​é o grau em que se atende à
finalidade para a qual ele se destinava. Em geral, a Engenharia de Requisitos é o processo de
descobrir este objetivo, identificando os ​stakeholders e suas necessidades, documentando estas
em uma forma que seja passível de análise, comunicação e, posteriormente, implementação.
Os stakeholders (incluindo clientes que pagam, usuários e desenvolvedores) podem ser
numerosos e distribuídos. Seus objetivos podem variar e conflitos podem aparecer, dependendo
das perspectivas do ambiente em que trabalham e das tarefas que desejam realizar. Seus
objetivos podem não ser explícitos ou podem ser difíceis de articular e, inevitavelmente, a
satisfação destes objetivos pode ser limitada por uma variedade de fatores fora de seu controle.
Neste artigo foi apresentada uma visão geral de pesquisa e conhecimento técnico atual em
Engenharia de Requisitos, descrita em termos das principais atividades que constituem esta área.
Embora estas tarefas sejam descritas de forma independente e em uma ordem específica, na
prática, elas são realmente intercaladas, interativas e podem abranger todo o ​software ​e o seu
ciclo de vida durante o desenvolvimento.
6 Referências
BALZER, R.; GOLDMAN, N.; WILE, D.. Informality in Program Specifications. IEEE
Transactions On Software Engineering, [s.l.], v. -4, n. 2, p.94-103, mar. 1978. Institute of
Electrical and Electronics Engineers (IEEE). http://dx.doi.org/10.1109/tse.1978.231480.
SOMMERVILLE, Ian. ​Engenharia de Software​. 8 ed. Rio de Janeiro: Prentice-Hall, 2008.
PRESSMAN, Roger S. ​Engenharia de Software​. 6 ed. São Paulo: McGraw Hill/Nacional,
2006.
MUSEUM OF SCIENCE, BOSTON. ​Engineering is Elementary​. Disponível em:
<https://eie.org>. Acesso em: 07 de julho de 2017.
COSTA, Leandro. ​Engenharia de Requisitos. ​2011. Disponível em:
<http://www.semeru.com.br/blog/engenharia-de-requisitos/>. Acesso em: 07 julho de 2017.
SAWYER, Pete. ​Software Requirements Engineering - An Introduction. ​Disponível em:
<http://sce.uhcl.edu/helm/REQ_ENG_WEB/My-Files/mod1/swreqinto/SREngineering.htm>.
Acesso em: 10 de julho de 2017.

Mais conteúdo relacionado

Mais procurados

Princípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de RequisitosPrincípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de Requisitos
elliando dias
 
Engenharia Requisitos
Engenharia RequisitosEngenharia Requisitos
Engenharia Requisitos
elliando dias
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
Roni Reis
 

Mais procurados (20)

Modelos e etapas do processo de software.pdf
Modelos e etapas do processo de software.pdfModelos e etapas do processo de software.pdf
Modelos e etapas do processo de software.pdf
 
Rastreabilidade de Requisitos
Rastreabilidade de RequisitosRastreabilidade de Requisitos
Rastreabilidade de Requisitos
 
Princípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de RequisitosPrincípios Fundamentais da Análise de Requisitos
Princípios Fundamentais da Análise de Requisitos
 
Gerência de Requisitos
Gerência de RequisitosGerência de Requisitos
Gerência de Requisitos
 
Definição e classificação dos requisitos
Definição e classificação dos requisitosDefinição e classificação dos requisitos
Definição e classificação dos requisitos
 
Requisitos de software
Requisitos de softwareRequisitos de software
Requisitos de software
 
engenharia-de-requisitos
engenharia-de-requisitosengenharia-de-requisitos
engenharia-de-requisitos
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de Software
 
Aula 02 - Engenharia de Requisitos
Aula 02 - Engenharia de RequisitosAula 02 - Engenharia de Requisitos
Aula 02 - Engenharia de Requisitos
 
Engenharia Requisitos
Engenharia RequisitosEngenharia Requisitos
Engenharia Requisitos
 
JAD e levantamento de requisitos
JAD e levantamento de requisitosJAD e levantamento de requisitos
JAD e levantamento de requisitos
 
ASPECTOS DA ENGENHARIA DE REQUISITOS
ASPECTOS DA ENGENHARIA DE REQUISITOSASPECTOS DA ENGENHARIA DE REQUISITOS
ASPECTOS DA ENGENHARIA DE REQUISITOS
 
Principais Técnicas de Elicitação de Requisitos
Principais Técnicas de Elicitação de RequisitosPrincipais Técnicas de Elicitação de Requisitos
Principais Técnicas de Elicitação de Requisitos
 
Aula 1 Analise e Projeto
Aula 1   Analise e ProjetoAula 1   Analise e Projeto
Aula 1 Analise e Projeto
 
Es capítulo 4 - engenharia de requisitos
Es   capítulo 4  - engenharia de requisitosEs   capítulo 4  - engenharia de requisitos
Es capítulo 4 - engenharia de requisitos
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?
 
Engenharia de Requisitos - Aula 2
Engenharia de Requisitos - Aula 2Engenharia de Requisitos - Aula 2
Engenharia de Requisitos - Aula 2
 
A importância da análise de requisitos e casos de uso
A importância da análise de requisitos e casos de usoA importância da análise de requisitos e casos de uso
A importância da análise de requisitos e casos de uso
 

Semelhante a Os aspectos mais relevantes da Engenharia de Requisitos

Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de Software
Robson Silva Espig
 
Aula 1 requisitos
Aula 1   requisitosAula 1   requisitos
Aula 1 requisitos
licardino
 
Aula 03 de engenharia de software uespi 2011-1
Aula 03 de engenharia de software uespi 2011-1Aula 03 de engenharia de software uespi 2011-1
Aula 03 de engenharia de software uespi 2011-1
Erivelton Silva Rocha
 

Semelhante a Os aspectos mais relevantes da Engenharia de Requisitos (20)

Introdução à Engenharia de Requisitos
Introdução à Engenharia de RequisitosIntrodução à Engenharia de Requisitos
Introdução à Engenharia de Requisitos
 
Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01
 
A proposal to combine elicitation techniques to write vision document and use...
A proposal to combine elicitation techniques to write vision document and use...A proposal to combine elicitation techniques to write vision document and use...
A proposal to combine elicitation techniques to write vision document and use...
 
aula7 software ciclo de vida analise req
aula7 software ciclo de vida analise reqaula7 software ciclo de vida analise req
aula7 software ciclo de vida analise req
 
Aula 7 - Ciclo de vida do software.pptx
Aula 7 - Ciclo de vida do software.pptxAula 7 - Ciclo de vida do software.pptx
Aula 7 - Ciclo de vida do software.pptx
 
Resumo capítulo 1 livro Engenharia de Software Moderna
Resumo capítulo 1 livro Engenharia de Software ModernaResumo capítulo 1 livro Engenharia de Software Moderna
Resumo capítulo 1 livro Engenharia de Software Moderna
 
Analise sistemas 04
Analise sistemas 04Analise sistemas 04
Analise sistemas 04
 
Aula 1 introducao
Aula 1   introducaoAula 1   introducao
Aula 1 introducao
 
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane FidelixAula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
 
Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de Software
 
Documento de requisitos
Documento de requisitosDocumento de requisitos
Documento de requisitos
 
Documento de requisitos
Documento de requisitosDocumento de requisitos
Documento de requisitos
 
Utilização da Engenharia de Requisitos: Onde, quando e como utilizar
Utilização da Engenharia de Requisitos: Onde, quando e como utilizarUtilização da Engenharia de Requisitos: Onde, quando e como utilizar
Utilização da Engenharia de Requisitos: Onde, quando e como utilizar
 
Modelagem de Sistemas de Informação 04
Modelagem de Sistemas de Informação 04Modelagem de Sistemas de Informação 04
Modelagem de Sistemas de Informação 04
 
Analise aula2
Analise aula2Analise aula2
Analise aula2
 
Aula 1 requisitos
Aula 1   requisitosAula 1   requisitos
Aula 1 requisitos
 
Análise de Sistemas Orientado a Objetos - 03
Análise de Sistemas Orientado a Objetos - 03Análise de Sistemas Orientado a Objetos - 03
Análise de Sistemas Orientado a Objetos - 03
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
 
Aula Gestão de Projetos
Aula Gestão de ProjetosAula Gestão de Projetos
Aula Gestão de Projetos
 
Aula 03 de engenharia de software uespi 2011-1
Aula 03 de engenharia de software uespi 2011-1Aula 03 de engenharia de software uespi 2011-1
Aula 03 de engenharia de software uespi 2011-1
 

Os aspectos mais relevantes da Engenharia de Requisitos

  • 1. OS ASPECTOS MAIS RELEVANTES DA ENGENHARIA DE REQUISITOS José Edilson Vieira Júnior - UAM-SP (edilsonv12@gmail.com) Resumo Este artigo busca explicar os aspectos mais relevantes da Engenharia de Requisitos, sua importância para a Engenharia de ​Software​, suas tarefas e os princípios para uma boa especificação. A Engenharia de Requisitos é conhecida há muito tempo, desde os anos 80 e, atualmente, tem-se um cenário muito mais propício para sua atuação, utilizando-se da evolução da tecnologia e do desenvolvimento de ​software​. A Engenharia de Requisitos é considerada por muitas bibliografias como um método pelo qual se consegue decompor uma informação de negócio em necessidades que precisam ser desenvolvidas e apresentadas dentro de sistemas automatizados. O objetivo desta pesquisa foi conhecer os propósitos da Engenharia de Requisitos no Desenvolvimento de ​Software ​e também na compreensão, organização e planejamento de um novo projeto. Palavras-chaves: ​Análise de Requisitos, Engenharia de ​Software​, Gestão. Introdução A Engenharia de Requisitos é de grande importância econômica para a indústria de software​. O custo para corrigir erros nos requisitos tende a aumentar exponencialmente quanto mais tempo eles permanecem não detectados. Os responsáveis pelos projetos desperdiçam grande quantidade de recursos quando fazem suposições equivocadas sobre as necessidades dos clientes. Como consequência, existe um risco considerável envolvido na Engenharia de Requisitos, mas a maturidade de seus processos está muito além dos processos do ciclo de vida de um ​software​. Isso é agravado pelo fato de que a Engenharia de Requisitos é rigorosamente limitada ao tempo e aos recursos da etapa de análise de requisitos, geralmente percebido de maneira errônea como tempo improdutivo.
  • 2. A questão de quem deve executar a Engenharia de Requisitos é controversa. Sua execução requer um conjunto de habilidades que se cruzam com a Engenharia de ​Software​, mas que também inclui habilidades fora deste conjunto. Por este motivo, nomeia-se engenheiro de requisitos quem faz a execução da Engenharia de Requisitos. Isso não que dizer que engenheiros de ​software ​não possam “fazer” a Engenharia de Requisitos, mas sim enfatizar que o papel do engenheiro de requisitos é distinto entre o domínio do desenvolvimento e o domínio do cliente de ​software​. 1 Processo Geral da Engenharia Os termos Engenharia de Requisitos e Engenharia de ​Software ​fazem uso adequado do termo geral Engenharia, uma vez que estão extremamente ligados à aquisição e aplicação de conhecimento para criação, aperfeiçoamento e implementação de sistemas de informação. O Museu de Ciência de Boston possui um programa que busca apresentar aos jovens o que é Engenharia e descreve um processo geral sobre ela, como sendo: 1. Pergunte: neste passo, a ideia é entender bem o que é o problema, o que os outros fizeram e quais as restrições existentes, ou seja, deve-se ter uma visão clara do problema para que uma solução possa ser proposta. Para isso, é fundamental saber perguntar; 2. Imagine: uma vez que se tem uma visão clara do problema, deve-se imaginar as possíveis soluções para o mesmo. Em geral, todo problema tem várias soluções possíveis. É importante que se consiga pensar em mais de uma possibilidade, avaliando o que é melhor, dada as restrições conhecidas; 3. Planeje: tendo a solução definida, o próximo passo é planejar, que significa tanto detalhar a solução encontrada quanto definir o trabalho necessário para entregar esta solução; 4. Crie: com base no planejamento, o próximo passo é construir a solução. Uma vez que a solução foi construída e entregue, deve-se fazer um acompanhamento, pois dificilmente entrega-se uma solução perfeita; 5. Melhore: baseado na percepção do funcionamento do sistema, deve-se retornar ao passo inicial do ciclo, perguntando o que funcionou bem, o que não foi bem e o que há de novo no cenário que exige adaptações no sistema.
  • 3. Este processo é um ciclo que representa bem o que ocorre na Engenharia de Requisitos e, não necessariamente, tem um único ponto de início. 2 A Engenharia de Requisitos A Engenharia de Requisitos começa com alguns pontos importantes que são a organização, a compreensão e o planejamento dos requisitos. Existem três tipos de requisitos, os chamados funcionais, não-funcionais e os requisitos de domínio. Além disso, a atividade de gerência dos requisitos é dividida em tarefas (sete, especificamente): concepção, levantamento, elaboração, negociação, especificação, validação e gestão de requisitos. Um requisito pode ser definido como uma declaração abstrata de alto nível de um serviço, uma restrição de sistema ou até mesmo uma especificação funcional detalhada. Como citado anteriormente, existem três tipos de requisitos: ● Funcionais: representam uma descrição da funcionalidade e serviços do sistema; ● Não-funcionais: representam uma descrição de propriedades, restrições do sistema, qualidade e também podem especificar linguagens de programação, método de desenvolvimento, etc. Devido à sua própria definição, estes requisitos são esperados mensuráveis e deve-se associar formas de medida/referência a cada um deles elicitados. Os requisitos não-funcionais podem ser: ○ De produto: especificações referentes ao produto; ○ De organização: referentes a políticas e procedimentos organizacionais; ○ Externo: referentes a fatores externos, como por exemplo legislação. ● Domínio: referentes ao domínio de aplicação. Descrevem características do sistema e qualidades de acordo com o domínio. A compreensão correta do problema se torna muito difícil às vezes, especialmente se o sistema for novo. Por esta razão, utiliza-se a Engenharia de Requisitos, que pode ser definida como o processo de descobrir, analisar, documentar e verificar os requisitos (Sommerville, 2008).
  • 4. 2.1 Características da Engenharia de Requisitos Durante a Engenharia de Requisitos podem aparecer alguns problemas decorrentes da falta de separação nítida entre os dois diferentes níveis de descrição. Estes níveis podem ser distinguidos utilizando-se os termos requisitos de usuário para os requisitos abstratos de alto nível e requisitos de sistema para indicar a descrição detalhada das funcionalidades do sistema. Pode ser produzida ainda uma descrição mais detalhada associando a Engenharia de Requisitos às atividades de projeto. Para Sommerville (2008), estes dois níveis de requisitos e a especificação de projeto de ​software ​podem ser definidos do seguinte modo: ● Requisitos de usuário: são declarações em linguagem natural e diagramas contendo as funcionalidades e as restrições sob as quais o sistema deve operar. Esse documento é escrito para gerentes do cliente e dos fornecedores que não tenham conhecimento técnico detalhado do sistema; ● Requisitos de sistema: detalham funcionalidades e restrições. Este documento pode inclusive servir como um contrato entre as partes envolvidas no projeto. Ele é escrito para os profissionais técnicos de nível sênior e para gerentes de projeto; ● Especificação de projeto de ​software​: é uma descrição abstrata do projeto de ​software ​na qual se acrescenta mais detalhes aos requisitos do sistema. Este documento é escrito para os engenheiros de ​software ​que desenvolverão o sistema. 2.2 O propósito dos requisitos em um sistema No escopo geral, requisito é a condição que se deve satisfazer para alcançar certo fim, ou, até mesmo, uma exigência de ordem legal para que determinado processo possa ter andamento. No contexto da Engenharia de ​Software podemos definir requisito como “o que” este sistema deve fazer, quais as restrições sobre as operações deste sistema ou, ainda, quais são as regras de negócio deste sistema. Normalmente, antes de um sistema existir, é necessário entender quais são os seus requisitos para depois desenvolvê-lo. No entanto, se um sistema já existe e precisa ser
  • 5. modificado, também é necessário entender os requisitos desse sistema e dessa modificação, para que essa modificação seja desenvolvida. Geralmente, existe um demandante do sistema, ou seja, um indivíduo ou uma empresa responsável que fornece os requisitos. Os requisitos podem ser fornecidos pelo cliente, futuros usuários e os demais envolvidos no projeto. Para coletar esses requisitos, o analista deve fazer diversas reuniões com o demandante, aplicando técnicas para levantamento de requisitos, filtrando todas as informações possíveis para que, posteriormente, o ​software ​possa ser desenvolvido corretamente. Parece fácil, mas na prática não é. Isso depende muito da comunicação entre o demandante e o analista. 3 Princípios de uma boa especificação e Tarefas da Engenharia de Requisitos Segundo Balzer, Goldman e Wile (1978), existem princípios de uma boa especificação de requisitos. Deve-se: 1. Separar funcionalidades da implementação, uma vez que a implementação é uma outra etapa da Engenharia de ​Software​; 2. Haver uma linguagem de especificação orientada ao processo de desenvolvimento; 3. Abranger o sistema do qual o ​software ​é um componente; 4. Abranger o ambiente no qual o sistema opera; 5. Ser um modelo cognitivo; 6. Ser operacional; 7. Ser tolerante com a não completude, além de ser expansível; 8. Ser localizado e fracamente acoplado. A especificação é uma parte muito importante na Engenharia de Requisitos. No entanto, é necessário proceder com as tarefas para uma boa gerência e modelagem dos requisitos. Abaixo, as atividades destas tarefas são descritas: ● Concepção: escopo, domínio de aplicação, entendimento básico do problema e percepção geral de uma solução; ● Levantamento: objetivos/abrangência do sistema, necessidades de diferentes usuários e uso do sistema;
  • 6. ● Elaboração: modelagem de análise (modelagem e refinamento), criação do modelo de análise que define o domínio do problema informacional, funcional e comportamental (refinamento das funções, características e restrições); ● Negociação: resolver conflitos, avaliar impactos (custo de projeto, prazos de entrega) e alcançar satisfação; ● Especificação: criação do modelo escrito, fundamento das atividades seguintes da Engenharia de ​Software ​e descrição de funções, desempenho e restrições; ● Validação: garantir que os requisitos estejam claros, abstrair inconsistências e erros, revisar tecnicamente o projeto e aplicar um ​check list ​sobre as questões do projeto; ● Gestão de requisitos: identificar, controlar e rastrear modificações durante a vida do projeto, atribuir um modo identificador e desenvolver tabelas de rastreamento. 4 A Importância da Engenharia de Requisitos A Engenharia de Requisitos é implementada em projetos de ​software ​para que hajam melhorias nos processos de desenvolvimento. O desenvolvimento e modificações de ​softwares são atividades complexas e, por mais que as tecnologias tenham alcançado um nível superior, ainda são grandes os números de projetos que falham ou que são considerados problemáticos em relação às necessidades de um cliente. A implementação da Engenharia de Requisitos é um dos fatores críticos para alcançar o sucesso em projetos, aumentando as chances de satisfação dos clientes e de todos os envolvidos, além de reduzir falhas, erros, prejuízos e aumentar a qualidade do ​software​. Em projetos de software​, a Engenharia de Requisitos visa a entrega de produtos com qualidade e conformidade nos requisitos. 5 Considerações Finais A principal medida de sucesso de um sistema de ​software ​é o grau em que se atende à finalidade para a qual ele se destinava. Em geral, a Engenharia de Requisitos é o processo de descobrir este objetivo, identificando os ​stakeholders e suas necessidades, documentando estas em uma forma que seja passível de análise, comunicação e, posteriormente, implementação.
  • 7. Os stakeholders (incluindo clientes que pagam, usuários e desenvolvedores) podem ser numerosos e distribuídos. Seus objetivos podem variar e conflitos podem aparecer, dependendo das perspectivas do ambiente em que trabalham e das tarefas que desejam realizar. Seus objetivos podem não ser explícitos ou podem ser difíceis de articular e, inevitavelmente, a satisfação destes objetivos pode ser limitada por uma variedade de fatores fora de seu controle. Neste artigo foi apresentada uma visão geral de pesquisa e conhecimento técnico atual em Engenharia de Requisitos, descrita em termos das principais atividades que constituem esta área. Embora estas tarefas sejam descritas de forma independente e em uma ordem específica, na prática, elas são realmente intercaladas, interativas e podem abranger todo o ​software ​e o seu ciclo de vida durante o desenvolvimento. 6 Referências BALZER, R.; GOLDMAN, N.; WILE, D.. Informality in Program Specifications. IEEE Transactions On Software Engineering, [s.l.], v. -4, n. 2, p.94-103, mar. 1978. Institute of Electrical and Electronics Engineers (IEEE). http://dx.doi.org/10.1109/tse.1978.231480. SOMMERVILLE, Ian. ​Engenharia de Software​. 8 ed. Rio de Janeiro: Prentice-Hall, 2008. PRESSMAN, Roger S. ​Engenharia de Software​. 6 ed. São Paulo: McGraw Hill/Nacional, 2006. MUSEUM OF SCIENCE, BOSTON. ​Engineering is Elementary​. Disponível em: <https://eie.org>. Acesso em: 07 de julho de 2017. COSTA, Leandro. ​Engenharia de Requisitos. ​2011. Disponível em: <http://www.semeru.com.br/blog/engenharia-de-requisitos/>. Acesso em: 07 julho de 2017. SAWYER, Pete. ​Software Requirements Engineering - An Introduction. ​Disponível em: <http://sce.uhcl.edu/helm/REQ_ENG_WEB/My-Files/mod1/swreqinto/SREngineering.htm>. Acesso em: 10 de julho de 2017.