TCC ENG SOFW Requisito - Pronto

Prévia do material em texto

1
INTRODUÇÃO AOS CONCEITOS E PRÁTICAS DA ENGENHARIA DE REQUISITOS
 
Nome: Evandro Caetano RGM: 20730764
Orientador: Afonso Luiz Pavão
Resumo:	
A engenharia de requisitos tem sido reconhecida como um dos maiores desafios do processo de desenvolvimento de software. Muitas empresas estão contratando o serviço de software para facilitar o controle da empresa, ajudando no financeiro, no estoque, e em relatórios. Com isso, os requisitos fornecem as condições necessárias que as empresas necessitam. Nesse estudo, foi preparado um projeto que estabeleça o controle da empresa e dos desenvolvedores no processo de desenvolvimento de requisitos. Com isso a empresa de software otimizará seus recursos, visando garantir a qualidade do processo. 
Palavras-chave: Engenharia de software, engenharia de requisitos, projeto.
Abstract:
Requirements engineering has been recognized as one of the greatest challenges in the software development process. Many companies are hiring the software service to facilitate the company's control, helping in financial, inventory, and reporting. With this, requirements provide the necessary conditions that companies need. In this study, a project was prepared to establish the control of the company and the developers in the process of requirements development. With this, the software company will optimize its resources to ensure the quality of the process. 
Keyword: Software engineering, requirements engineering, design.
Sumário
1.	INTRODUÇÃO À ENGENHARIA DE REQUISITOS	3
1.1.	Objetivo	4
1.2.	Metodologia	5
2.    ENGENHARIA DE REQUISITOS: CONCEITOS E PRÁTICAS	5
2.1.	O Manifesto Ágil (2001)	5
2.2.	Engenharia de Requisitos	6
2.2.1.	Tipos de Requisitos	7
2.2.2.	O Documento De Requisitos De Software	9
2.2.3.	Processos De Engenharia De Requisitos	10
3.	CONSIDERAÇÕES FINAIS	12
4.	REFERÊNCIAS	12
1.	INTRODUÇÃO À ENGENHARIA DE REQUISITOS
 
There's no sense in being precise when you don't even know what you're talking about.
John von Neumann
Dados os constantes avanços tecnológicos, a engenharia de software tem extrema relevância, pois, além de estar atualizando e inovando no mercado, os softwares vêm sendo um fator de acelerador da tecnologia e informação. Com isso, os profissionais ligados à tecnologia vêm buscando inovações e estratégias, com os recursos da engenharia de requisitos, visando otimizar a criação e adequação de softwares às necessidades dos clientes, o que têm culminado no crescimento da importância delegada a este campo de estudo/atividade no processo de desenvolvimento de software. (PRIKLADNICKI et al., 2014)
Com esses sistemas avançando cada dia mais, as empresas estão buscando esses requisitos para melhorar o processo de desenvolvimento dos mesmos de acordo com as suas necessidades, personalizando os serviços oferecidos por elas e, consequentemente, melhorando a experiência dos usuários do(s) software(s) desenvolvido(s) por elas.
Muitas empresas estão se reformulando com o objetivo de definirem seus processos detalhadamente para que estes sejam um bom suporte em suas operações e atividades de desenvolvimento. Em matéria publicada na revista ‘Exame’ recentemente, relata-se o aumento no número de empresas que alcançaram níveis de maturidade observando moldes como MPS, BR e CMMI. (ÁVILA & SPÍNOLA, 2007)
Este dado é um bom indicativo de que nossas organizações nacionais estão cada vez mais atentas à qualidade dos serviços que prestam à sociedade, inserindo-se, com isso, no mercado internacional de desenvolvimento de software.
Segundo Vazquez & Simões (2016), criar um software é uma tarefa complexa por essência. Isto porque não há uma única resposta para cada cenário de desenvolvimento. Ademais, lidar o tempo todo com pessoas torna o sucesso do projeto vinculado à competência da equipe e à sua forma de trabalhar, e, para dificultar ainda mais, muitas vezes não utilizamos processos bem definidos a fim de apoiar as atividades do projeto.
Neste contexto, entende-se por processo um conjunto de tarefas bem definidas com os responsáveis pela sua execução, ferramentas de suporte e artefatos produzidos. Ou seja, primeiro define-se a forma com que a equipe deverá trabalhar a fim de alcançar o objetivo: desenvolver um software de qualidade com pontualidade, custos e requisitos previamente definidos (PAULA FILHO, 2000).
A engenharia de requisitos é uma ferramenta para um bom desenvolvimento, operação e manutenção de sistemas. Seu objetivo é auxiliar no processo de produção do software, de forma que o processo dê origem a produtos com qualidade, rapidez e a um custo cada vez menor. (ÁVILA & SPÍNOLA, 2007)
Podemos afirmar que, independente da natureza do projeto, a engenharia de requisitos é uma das fases mais importantes no desenvolvimento de software, pois nela são identificados, analisados e definidos os propósitos, funcionalidades e o escopo do software. (PRIKLADNICKI et al., 2014)
Além disso, a engenharia de requisitos é capaz de manipular o bem mais importante para uma empresa - a informação -, a fim de evitar que o desenvolvimento de software seja realizado resultando em sistema com baixa qualidade ou previsibilidade de custos e recursos. (ÁVILA & SPÍNOLA, 2007)
A engenharia de requisitos começa com o planejamento, depois aprovação do projeto e produção dos requisitos, desde os estágios iniciais de especificação do sistema até sua manutenção, de acordo com as necessidades de cada cliente. Consequentemente, a empresa que desenvolve um software considerando e aprimorando seus requisitos, tende a apresentar um diferencial das demais, tendo à sua disposição informações rápidas e um software personalizado e adequado aos interesses dos usuários (VAZQUEZ & SIMÕES, 2016).
1.1. Objetivo
O objetivo geral deste trabalho é propor um modelo de processo de engenharia de requisitos destinado a pequenas e médias empresas onde o uso do sistema é manual e o desenvolvimento de software visa apresentar um projeto com qualidade e segurança para empresa.
Neste estudo pretende-se definir as atividades que deverão ser desenvolvidas, as técnicas que serão utilizadas, os artefatos que serão produzidos e a ferramenta de gestão de requisitos que será empregada nas atividades da engenharia de requisitos.
Para atender a este objetivo da engenharia de requisitos serão analisados os seguintes critérios específicos:
- Analisar as diferentes técnicas e métodos existentes no processo de engenharia de requisitos.
- Identificação e apontamento das principais necessidades dos clientes/stakeholders.
- Elaboração de uma proposta preliminar do processo de engenharia de requisitos voltada para os negócios. 
1.2. Metodologia
Esta pesquisa será de natureza básica, por se tratar de uma pesquisa científica focada na melhoria de teorias já existentes que visam a aumentar a base do conhecimento científico a respeito da engenharia de requisitos.
A abordagem do problema se dará de forma qualitativa, pois seu objetivo será compreender e descrever mais a fundo o tema pesquisado – engenharia de requisitos de software – mais a fundo. 
Esta pesquisa tem como objetivo explorar, descrever e explicar os conceitos e práticas relacionados ao desenvolvimento de requisitos de software e a importância e desafios de atuação na área.
Os procedimentos de levantamento de dados que orientarão esse trabalho serão pesquisa bibliográfica, pesquisa documental e leitura com vistas descobrir e explorar o que a literatura científica trata sobre o assunto. 
Para a coleta de dados, os instrumentos usados serão coleta bibliográfica e documental em artigos científicos e livros e mídias digitais. Será feita busca de conteúdos a respeito do assunto em livros, artigos, revista e em sites especializados.
2.    ENGENHARIA DE REQUISITOS: CONCEITOS E PRÁTICAS
2.1. O Manifesto Ágil (2001)
“O termo foi cunhado por 17 especialistas que se reuniram para debater e propor um processo de desenvolvimento de software seja realizado da melhor maneira: mais leve, rápido e humanizado.” (PRIKLADNICKI et al., 2014, p. 89). De acordo com Vazquez & Simões(2016, p.4) “este documento - Manifesto Ágil, 2001 - é constituído por valores e princípios os quais os desenvolvedores de softwares têm de observar, os quais, a saber”:
·  “Indivíduos e interações mais que processos e ferramentas;
· Software em funcionamento mais que documentação abrangente;
· Colaboração com o cliente mais que negociação de contratos; e
·  Responder a mudanças mais que seguir um plano.”
“É com esse olhar humanizado visando à satisfação do cliente que a Engenharia de Requisitos faz-se necessária”. Neste contexto, o profissional de informática terá de lidar com uma série de requisitos, que serão os principais determinantes para o sucesso ou fracasso de um software. (PRIKLADNICKI et al., 2014, p. 28).
Figura 1. "Um processo geral de engenharia explicado de forma simples para jovens"
 Fonte: Engenharia De Requisitos: Software Orientado Ao Negócio, Vazquez & Simões, 2016, p.3.
2.2. Engenharia de Requisitos
“Engenharia de requisitos refere-se à ampla gama de procedimentos e métodos que visam o entendimento dos requisitos de um software.” Na perspectiva do processo de desenvolvimento de software, a engenharia de requisitos é uma importante área da engenharia de software cujas atividades se iniciam durante a comunicação e continua na modelagem. Ela deve ser adequada às demandas do processo, do produto, do projeto e das pessoas interessadas no trabalho. (PRESSMAN, 2011, p. 127). 
Paula Filho (2000) destaca que a área de atuação da engenharia de requisitos consiste no “processo sistemático de desenvolvimento de requisitos através de um processo cooperativo de análise onde os resultados das observações são codificados em uma variedade de formatos e a acurácia das observações é constante”.
Os requisitos são as definições das expectativas, das tarefas que o software deve executar, dos serviços oferecidos e das restrições quanto ao seu funcionamento. Tais requisitos refletem as demandas dos clientes para um software que tem uma finalidade pré-determinada, como controlar um aparelho, adicionar um pedido ou buscar informações. Ao processo de descoberta, análise, documentação e verificação desses serviços e restrições, denomina-se engenharia de requisitos. (SOMMERVILLE, 2011).
Sommerville (2011) também tem o cuidado de diferenciar os requisitos quanto à origem das suas necessidades.  Para ele, parte dos problemas surgidos durante o processo de engenharia de requisitos advém da não distinção entre diferentes níveis de descrição. 
O requisito pode ser somente uma declaração abstrata de um serviço que deve ser oferecido ou uma restrição a um software, denominado “requisito de usuário”. Por outro lado, também pode se tratar de uma definição formal e detalhada de uma função, serviços ou restrições operacionais específicos, denominados por ele como “requisitos do sistema”. O documento de requisitos do sistema deve definir precisamente o que deve ser implementado no sistema.
2.2.1. Tipos de Requisitos
Os requisitos são classificados frequentemente na literatura científica como requisitos funcionais e não funcionais. 
Requisitos funcionais são descrições de serviços que o software deve oferecer, de como deve reagir a comandos específicos e de como seu comportamento em situações determinadas. “Em alguns casos, também podem evidenciar como o sistema não deve se comportar” (Sommerville, 2011, p. 60). 
A princípio, a determinação dos requisitos funcionais de um software deve ser integral e coerente. Entretanto, em sistemas grandes e complexos são quase impossível de se alcançar integralidade e coerência dos requisitos. (Sommerville, 2011)
As razões mais comuns para isso são erros e omissões cometidos ao se formular as disposições para sistemas complexos, além das diferentes - e até inconsistentes - necessidades dos stakeholders “(indivíduos interessado-afetados pelo sistema) que podem conter inconsistências que passam despercebidas e as quais podem ser descobertas após a inclusão das especificações dos requisitos, durante uma análise mais cuidadosa” e/ou depois da entrega do sistema. (Sommerville, 2011, p. 61). 
Requisitos não funcionais são restrições às funções ou serviços que o sistema deve oferecer. Incluem limitações de timing, do processo de desenvolvimento ou restrições impostas pelos regimentos. Contrariamente às características ou serviços particulares do software, os requisitos não funcionais comumente se aplicam ao sistema como um todo e podem ser subdivididos, de acordo com Sommerville (2011)  em:
· Requisitos de produto: especificam ou restringem como o software deve se comportar. Como exemplo temos os requisitos de desempenho, os requisitos de confiabilidade que determinam a margem de falhas aceitável, os requisitos de segurança e os de usabilidade. 
· Requisitos organizacionais: são os requisitos gerais de softwares advindos da cultura organizacional do cliente ou do desenvolvedor. Podem incluir os requisitos operacionais, que definem o modo com que o sistema será utilizado, os requisitos do processo de elaboração que determinam a linguagem de programação, o ambiente de criação ou regras de processo usadas, dentre outros. 
· Requisitos externos: constituem todos os requisitos derivados de condições exteriores ao sistema e ao seu processo de elaboração. Exemplos incluem requisitos restritores de aprovação, requisitos legais e requisitos éticos que assegurem que o sistema será aceito por seus usuários e o público em geral. 
Na figura abaixo, temos o esquema da estruturação geral dos requisitos, exposto no livro “Engenharia de Requisitos: software orientado ao negócio” em que os autores Vazquez & Simões (2016) descreve os conceitos e práticas da Engenharia de Requisito sob uma perspectiva mercadológica.
Figura 2. “Os diferentes tipos de requisitos abordados pela Engenharia de Requisitos.”
 Fonte: Engenharia De Requisitos: Software Orientado Ao Negócio, Vazquez & Simões, 2016, p. 157.
2.2.2. O Documento De Requisitos De Software
Os requisitos devem ser devidamente documentados a fim de servirem de base para as demais fases do processo de desenvolvimento. Para Sommerville (2011) se trata de uma declaração oficial de o que os desenvolvedores do sistema devem implementar. “Deve incluir tanto os requisitos de usuário para um sistema quanto uma especificação detalhada dos requisitos de sistema”.
Presmann (2011) corrobora que “o registro dos requisitos num documento próprio facilita o controle de alterações de todos os envolvidos na manutenção dos requisitos, bem como a geração de versões do documento e a facilidade de acesso por todos os envolvidos”. 
A documentação de requisitos ainda é motivo de controvérsias e ambivalências na literatura. Lopes (2002), parafraseando Sommerville (2011) afirma que “a linguagem natural é a única capaz de ser compreendida por todos os participantes do processo de requisitos e, dessa forma, deve ser utilizada para representá-los”. Eles reconhecem, contudo, que “o foco principal é o entendimento e a acuidade dos requisitos especificados, de forma que sempre que necessário, pode-se incluir à documentação itens que facilitem o entendimento e a elucidação das informações registradas no documento de requisitos”. 
Um contraponto a esta perspectiva é de Davis (1993 apud. LOPES, 2002). Ele argumenta que “apesar da vantagem da linguagem natural, que pode ser entendida por todos os participantes do processo de requisitos, ela apresenta um alto grau de ambiguidade, o que favorece o aparecimento de inconsistências”.
2.2.3. Processos De Engenharia De Requisitos
O processo de engenharia de requisito é descrito de maneiras diferentes na literatura. Alguns, como Presmann (2011) e Vazquez & Simões (2016), dividem em processos com mais fases distintas.
Figura 3. "Etapas da identificação de requisitos de negócios."
 Fonte: Engenharia De Requisitos: Software Orientado Ao Negócio, Vazquez & Simões, 2016, p.134.
Outros, a exemplo de Sommerville (2011), descrevemo processo em quatro tópicos: 
I. Estudo de viabilidade: estudam-se as necessidades do usuário analisando a possibilidade de se satisfazê-las. 
II. Elicitação e análise de requisitos: os requisitos do software são originários desse processo, através do estudo dos softwares atuais, além de entrevistas com os usuários e stakeholders, observação das atividades, dentre outras atividades.
III. Especificação de requisitos: nessa fase ocorre a tradução das informações advindas da análise do documento que descreve o conjunto de requisitos. 
IV. Validação de requisitos: o desenvolvedor verifica a consistência, o realismo e completude dos requisitos, logo, os erros na documentação de requisitos são irremediavelmente descobertos. “Logo após, deve-se corrigir o documento para solução desses problemas” (SOMMERVILLE, 2011, p.76). 
“Em linhas gerais, as tarefas da gestão de compreende as atividades de concepção do projeto, nas quais os interessados formulam os requisitos básicos do sistema, definem as premissas e restrições primordiais do software a ser projetado” e discutem as características e funções principais a serem inseridas no sistema que atendam aos objetivos. (PRESMANN, 2011, p.129).
Durante o levantamento, segunda fase do processo e quando começa o trabalho do desenvolvedor, as informações são refinadas e expandidas — através de reuniões com os interessados, entrevistas aos usuários, pesquisa em documentos, questionários, dentre outras fontes, para o desenvolvimento de cenários de uso (PAULA FILHO, 2000).
A elaboração expande as informações sobre os requisitos e elabora um modelo de projeto — um apanhado de itens comportamentais, norteados a um fluxo determinado com base em cenários e classes. O modelo serve como referência para parâmetros de análise, soluções para falhas ou outros problemas recorrentes nas aplicações. (PRESMANN, 2011).
Após os processos anteriores, a equipe de desenvolvimento de software e os interessados no projeto seguem para a fase de negociação. Nessa fase, são negociadas as prioridades, disponibilidade e custo dos requisitos. Essa negociação objetiva desenvolver um projeto realista. Além disso, essa fase é importantíssima para entender as necessidades e expectativas dos clientes em relação ao modelo (PRESMANN, 2011).
Os itens produzidos após as fases anteriores são analisados quanto à qualidade e o grau de satisfação dos usuários durante a fase de validação. A validação de requisitos visa garantir que os requisitos do sistema tenham sido elaborados de forma coerente; detectar e corrigir inconsistências e falhas, e que os requisitos estejam alinhados com os objetivos determinados para o processo, projeto e software. 
3. CONSIDERAÇÕES FINAIS
Os conceitos e práticas da engenharia de requisitos conduzem os desenvolvedores de softwares para desenvolver uma base sólida para o sistema, a fim de produzir um sistema de qualidade, satisfatório na perspectiva dos clientes e que facilite a manutenção depois que o sistema é entregue.
As atividades da engenharia de requisitos começam no momento da comunicação ou detecção da necessidade – requisito – e segue durante todo o ciclo de vida do software. Durante o processo, o desenvolvedor realiza as tarefas de concepção da necessidade, levantamento dos requisitos, elaboração do projeto, negociação das condições, premissas e requisitos relacionados à criação do software, especificação ou desenvolvimento dos requisitos, validação do modelo e gestão.
Os objetivos dessa revisão bibliográfica foi entender sobre o processo de desenvolvimento de software atentando para as principais expectativas dos clientes e elaborar o processo de desenvolvimento de sistemas a fim de tornar público o conhecimento sobre o contexto onde está inserido o profissional de criação de software e quais as práticas relacionadas à engenharia de requisitos.
Novos e profundos estudos se fazem necessários, já que o desenvolvimento de softwares é uma atividade típica das novas corporações. Por ser uma área tão promissora e necessária e pelo fato de a engenharia de requisitos ainda ser pouco discutida na literatura brasileira, os estudiosos e profissionais da área têm um amplo tema para desbravar.
4. REFERÊNCIAS
ÁVILA, Ana Luiza; SPÍNOLA, Rodrigo Oliveira. Introdução à Engenharia de Requisitos. Engenharia de Software Magazine. 2007.
FILHO, Wilson de Pádua Paula. Engenharia de Software: fundamentos, métodos e padrões. Editora LTC. 2000
LOPES, Leandro Teixeira. Um Modelo de Processo de Engenharia de Requisitos para Ambientes de Desenvolvimento Distribuído de Software. Faculdade de Informática, PUCRS, 2004.
PRESSMAN, Roger S. Software Engineering: a practitioner’s approach. EUA: McGraw Hill, 2011.
PRIKLADNICKI, Rafael, Willi Renato, Milani Fabiano. Métodos Ágeis para Desenvolvimento de Software. Porto Alegre, Bookman, 2014.
SOMMERVILLE, Ian. Engenharia de Software — 9. ed. — São Paulo : Pearson Prentice Hall, 2011.
Vazquez Carlos Eduardo; Simões, Guilherme Siqueira. Engenharia de Requisitos: software orientado ao negócio. Rio de Janeiro, Brassport, 2016.