UNIDADE 1 - Definicoes de Requisitos de Software Ampli

Prévia do material em texto

Introdução
Começaremos os estudos apresentando a você a definição de Engenharia de Requisitos. Este é um processo que se concentra, basicamente, em avaliar se o sistema é útil para o negócio (estudo de viabilidade), descobrir requisitos (elicitação e análise), converter esses requisitos em algum formato padrão (especificação) e verificar se os requisitos definem o sistema que o cliente deseja (validação). Em seguida, você verá que a Engenharia de Requisitos é o ramo da Engenharia de Software preocupado com o objetivo do mundo real para as funções e restrições dos sistemas. Para finalizar, você conhecerá a delimitação do escopo, que tende a ser uma atividade iterativa à medida que os limites se tornam mais claros com o aumento da compreensão do domínio compartilhado por todas as partes interessadas. Estes estudos iniciais serão muito importantes para você, pois te darão toda a base para os próximos assuntos, então bons estudos! 
Compreensão de requisitos de software
A Engenharia de Requisitos é um processo de coleta e definição de quais serviços devem ser fornecidos pelo sistema. Concentra-se, basicamente, em avaliar se o sistema é útil para o negócio (estudo de viabilidade), descobrir requisitos (elicitação e análise), converter esses requisitos em algum formato padrão (especificação) e verificar se os requisitos definem o sistema que o cliente deseja (validação). 
Na prática, a Engenharia de Requisitos não é um processo sequencial, e sim iterativo, no qual as atividades são intercaladas. Por exemplo, você itera, primeiro, nos requisitos do usuário; elicitação, especificação e validação, e repete as mesmas etapas para os requisitos do sistema, como podemos ver na Figura 1. 
Fonte: adaptada de Sommerville (2011).
No início do processo, a maior parte do esforço será consumido na compreensão dos requisitos de negócios e do usuário de alto nível. Mais tarde, mais esforços serão gastos na elicitação e compreensão dos requisitos detalhados do sistema (ELGABRY, 2016).  
Requisitos do usuário e do sistema 
Normalmente, os requisitos são apresentados em dois níveis de detalhes:  
· Requisitos do usuário: descreve os serviços que o sistema deve fornecer e as restrições sob as quais deve operar. Não esperamos ver nenhum nível de detalhe, ou o que exatamente o sistema fará, são mais requisitos genéricos. Geralmente, é escrito em linguagem natural e fornecido por diagramas. 
· Requisitos do sistema: significam uma descrição mais detalhada dos serviços do sistema e das restrições operacionais, como o sistema será usado e as restrições de desenvolvimento, como as linguagens de programação. Este nível de detalhe é necessário para aqueles que estão envolvidos no desenvolvimento do sistema, como engenheiros, arquitetos de sistemas, testadores etc. 
Assim, os requisitos do usuário e do sistema referem-se apenas a diferentes níveis de detalhes. Ter diferentes níveis de detalhes é útil porque comunica informações sobre o sistema que está sendo desenvolvido para diferentes tipos de leitores, conforme apresentado na Figura 2.
Fonte: adaptada de Sommerville (2011).
Assim, os usuários finais não se preocuparão com os detalhes, eles precisam de um requisito escrito genérico e abstrato, enquanto as pessoas envolvidas no desenvolvimento precisam saber exatamente o que o sistema deve fazer. Você, provavelmente, acabará com muitos problemas e mal-entendidos se não tiver uma separação clara entre os diferentes níveis de detalhes (ELGABRY, 2016).  
Requisitos funcionais e não funcionais 
Os requisitos de software são classificados em requisitos funcionais e requisitos não funcionais: 
· Requisitos funcionais: abrangem as principais funções que devem ser fornecidas pelo sistema. Quando expressos como requisitos do usuário, geralmente, são descritos de forma abstrata. Entretanto, requisitos de sistema funcionais mais específicos descrevem as funções do sistema, suas entradas, seu processamento, como ele reagirá a uma entrada específica e qual é a saída esperada (ELGABRY, 2016). 
· Requisitos não funcionais: são as restrições sobre as funções fornecidas pelo sistema, como quantos processos o sistema pode manipular (desempenho), quais são os problemas (de segurança) que o sistema precisa cuidar, a taxa de insucesso (confiabilidade), quais são as linguagens e ferramentas que serão utilizadas (desenvolvimento), quais são as regras que precisa seguir para garantir que o sistema funcione dentro da lei da organização (legislativa), como na Figura 3 (ELGABRY, 2016).
Fonte: adaptada de Sommerville (2011).
Os requisitos não funcionais são mais críticos, e os usuários, geralmente, podem encontrar maneiras de contornar uma função do sistema que realmente não atende às suas necessidades, porém não atender a um requisito não funcional pode significar que todo o sistema fica inutilizável. 
Engenharia de requisitos na engenharia de software
Você já parou para observar que o mundo da tecnologia não pode funcionar sem software? As indústrias são controladas por sistemas de software, como sistemas financeiros, laboratórios científicos, infraestruturas e utilitários, jogos, cinema, televisão... E a lista continua. Mas, antes de tudo, o que é um software? 
Um software é um programa de computador junto aos documentos associados e aos dados de configuração que fazem com que esses programas funcionem corretamente. E um programa é um conjunto de instruções (escritas em forma de código legível por humanos) que executa uma tarefa específica (ELGABRY, 2016).  
Tipos de sistemas de software 
Existem muitos tipos diferentes de sistemas de software, de simples a complexos. Esses sistemas podem ser desenvolvidos para um cliente específico, como para dar suporte a um processo de negócios específico, ou desenvolvidos para fins gerais, como qualquer software para nossos computadores, como processadores de texto (ELGABRY, 2016).  
Engenharia de Software 
A Engenharia de Software é uma disciplina de engenharia aplicada ao desenvolvimento de software em uma abordagem sistemática (chamada de processo de software). Basicamente, é a aplicação de teorias, métodos e ferramentas para projetar e construir um software que atenda às especificações de forma eficiente, econômica e garanta qualidade.  
Não se preocupa apenas com o processo técnico de construção de um software mas também inclui atividades para gerenciar o projeto e desenvolver ferramentas, métodos e teorias que dão suporte à produção de software. 
A não aplicação de métodos de Engenharia de Software resulta em um software mais caro e menos confiável e pode ser vital a longo prazo, pois, à medida que as mudanças chegam, os custos aumentam drasticamente (ELGABRY, 2016).  
Engenharia de Requisitos (ER) 
Conforme definido por Zave (1997), a Engenharia de Requisitos é o ramo da Engenharia de Software preocupado com o objetivo do mundo real para as funções e restrições dos sistemas. Preocupa-se também com a relação desses fatores com a especificação do comportamento do software e com sua evolução ao longo do tempo em famílias de software. 
O processo de Engenharia de Requisitos inclui elicitação, modelagem, análise, verificação e validação e gerenciamento de requisitos. Dentre esses subprocessos, a elicitação de requisitos desempenha um papel importante na extração das necessidades dos stakeholders, pois é o primeiro subprocesso da engenharia de requisitos e tem efeito cascata. Isso significa que erros que ocorrem durante a elicitação afetarão os processos de ER restantes. A compreensão inadequada dos processos pode levar ao fracasso de projetos de software. O processo ocorre em quatro etapas, que incluem:  
1. Estudo de viabilidade. 
2. Levantamento e análise de requisitos. 
3. Especificação de requisitos de software. 
4. Validação de requisitos de software. 
5. Gerenciamento de requisitos de software. 
Brooks e Bullet (1987, p. 12) já afirmavam que “a parte mais difícil de um sistema de software é decidir precisamente o que construir. Portanto, a função máxima que o construtor de software executa para o clienteé o refinamento de extração iterativo dos requisitos do produto”.
A maioria dos softwares falha devido aos requisitos inconsistentes e ambíguos, logo a compreensão clara da Engenharia de Requisitos ajuda a desenvolver um sistema de software bem-sucedido.
Delimitação de escopo
O escopo do projeto é a parte do planejamento do projeto que envolve determinar e documentar uma lista de objetivos, entregas, tarefas, custos e prazos específicos do projeto. E refere-se ao trabalho necessário para entregar um produto. Requisitos e entregas definem o escopo do projeto, e é fundamental que a parte interessada esteja de acordo com as informações discutidas no plano proposto. 
O aumento do escopo (também chamado de aumento de requisitos, aumento de função, aumento de recursos) no gerenciamento de projetos refere-se a mudanças, crescimento contínuo ou descontrolado no escopo de um projeto em qualquer ponto após o início do projeto. Isso pode ocorrer quando o escopo de um projeto não é definido, documentado ou controlado adequadamente.  
Os requisitos, geralmente, começam com uma vaga declaração de intenção. O primeiro problema é estabelecer o limite da investigação e, entre outros, o escopo do sistema pretendido. Infelizmente, isso raramente é um processo fácil, pois os clientes, normalmente, não sabem exatamente o que querem, e o conhecimento sobre o sistema pretendido é vago. O escopo tende a ser uma atividade iterativa à medida que os limites se tornam mais claros com o aumento da compreensão do domínio compartilhado por todas as partes interessadas. No entanto, o processo é pouco compreendido e poucas pesquisas abordaram diretamente esse difícil problema (SUTCLIFFE, 2017). 
Tomemos, por exemplo, um sistema para ajudar epidemiologistas em suas pesquisas. As partes interessadas podem incluir analistas de saúde pública com interesses em epidemiologia, bem como pesquisadores médicos. A gama de possíveis ferramentas de apoio à decisão pode incluir coleta de dados, preparação de dados, análise estatística, visualizações, gráficos, mapas, bem como um suporte de trabalho em grupo para discussão colaborativa de resultados. O proprietário e o escopo do sistema não estavam claros, pois o projeto foi iniciado como parte do programa de pesquisa em ciência, com usuários que eram pesquisadores acadêmicos em epidemiologia e que colaboravam com analistas de saúde pública que trabalhavam em hospitais locais. 
A definição do escopo é mais bem alcançada a partir da discussão com todas as partes interessadas e pela documentação dos objetivos de alto nível do sistema como termos de referência. Anotar o escopo tende a focar a atenção dos usuários em onde os limites da investigação do sistema devem estar e ajuda a identificar pelo menos um escopo inicial para o sistema. 
A norma internacional que trata das ferramentas e dos métodos de Engenharia de Requisitos para linha de produtos de software e sistemas é a ISO/IEC 26551:2016. O escopo dela é: 
· Fornecer os termos e as definições específicos para Engenharia de Requisitos para linhas de produtos de software e sistemas e produtos membros associados. 
· Definir grupos de processos e seus processos executados durante a engenharia de requisitos de linha de produto (esses processos são descritos em termos de propósito, entradas, tarefas e resultados). 
· Definir as capacidades do método para suportar as tarefas definidas de cada processo. 
· Definir os recursos da ferramenta para automatizar/semiautomatizar tarefas ou recursos de métodos definidos. 
· Saiba mais
· 
· Para entender melhor Engenharia de Requisitos, disponibilizamos alguns links a seguir, que abordam com mais detalhes esse assunto. Vale a pena conferir! 
· Engenharia de requisitos: quais as etapas e como funciona?
· O Processo de Engenharia de Requisitos
· Análise de Requisitos
· Engenharia de Requisitos: software orientado ao negócio 
· Engenharia de requisitos
Referências
BROOKS, F. P.; BULLET, N. S. Essence and accidents of software engineering. IEEE computer, v. 20, n. 4, p. 10-19, 1987.  
ELGABRY, O. Requirements Engineering – Introduction (Part 1). Medium, 2016. Disponível em: https://medium.com/omarelgabrys-blog/requirements-engineering-introduction-part-1-6d49001526d3. Acesso em: 19 jul. 2022.  
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 26551:2016. Engenharia de software e sistemas – Ferramentas e métodos para engenharia de requisitos de linha de produto. [S. l.]: ISO, 2016. Disponível em: https://www.iso.org/standard/69530.html. Acesso em: 19 jul. 2022.  
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo, SP: Pearson, 2011.  
SUTCLIFFE, A. G. Requirements Engineering. Interaction Design Foundation, 2017. Disponível em: https://www.interaction-design.org/literature/book/the-encyclopedia-of-human-computer-interaction-2nd-ed/requirements-engineering. Acesso em: 19 jul. 2022.  
ZAVE, P. Classification of research efforts in requirements engineering. ACM Computing Surveys (CSUR), v. 29, n. 4, p. 315-321, 1997. 
Introdução
Olá, estudante! 
Nesta aula, você aprenderá a realizar o refinamento dos requisitos de software, de modo a aumentar a compreensão das necessidades do cliente quanto à aplicação que será construída. Além disso, serão apresentadas técnicas que podem ser utilizadas no processo do levantamento de requisitos, auxiliando tanto o cliente quanto o membro da equipe de desenvolvimento responsável pela escrita das funcionalidades que devem ser providas pelo programa. 
Você também aprenderá sobre a importância do analista de requisitos e do engenheiro de software no processo da construção de uma aplicação. 
Lembre-se de que você é responsável pelo seu aprendizado. Bons estudos!
Análise e refinamento do escopo
No início do processo de desenvolvimento de uma nova aplicação, as primeiras entrevistas com o cliente darão apenas uma vaga ideia dos requisitos necessários para o software, de modo que, com o passar do tempo e as constantes validações e esclarecimentos de dúvidas acerca do negócio com o cliente, a maior compreensão do domínio da aplicação facilitará para que o requisito se adeque cada vez mais às reais necessidades do cliente. 
A este processo de “descoberta” das regras de negócio e, por consequência, dos requisitos em si, denominamos de refinamento dos requisitos. Esta fase é de extrema importância para o sucesso do projeto, já que o refinamento transformará um requisito que estava em um nível de detalhamento macro, sem detalhes técnicos e apenas focado no funcionamento geral, em um requisito com o detalhamento técnico necessário para que a equipe de desenvolvimento possa implementá-lo na aplicação. 
Os requisitos, após serem refinados com o auxílio do cliente, precisam ser validados, para que se tenha a garantia de que o que está escrito confere com o que é esperado pelo cliente (e partes interessadas) como resposta esperada da funcionalidade. 
Após o processo de refinamento das funcionalidades ter sido concluído e acordado com o cliente, deverá haver o planejamento dos recursos necessários (quantidade e perfil de profissionais, configuração das máquinas necessárias e outros recursos, como impressoras etc.) e a estimativa de conclusão do projeto, com entrega do produto ao cliente. Este planejamento está se referindo ao escopo do projeto, delimitando-o conforme os requisitos necessários para a aplicação. 
O escopo do projeto representa tudo o que precisa ser feito para atender às necessidades do cliente ao final do projeto (ENAP, 2014). Com isso, contempla todo o trabalho necessário para a conclusão do projeto com sucesso. A delimitação do escopo, por sua vez, criará uma fronteira entre o que está incluso no projeto e o que não estará englobado na aplicação.  
Após o processo de refinamento do escopo ter sido finalizado, é importante garantir que nenhuma variável acordada será modificada, tendo em vista o impacto negativo no planejamento do projeto, tendo por consequência o aumento do custo, já que os recursos alocados precisarão permanecer assim por mais tempo, além do aumentono prazo da entrega final. 
Qualquer imprevisto no projeto, como inclusão de novas funcionalidades não mapeadas inicialmente ou alteração das já existentes no projeto, precisará de uma nova rodada de negociação com o cliente, garantindo que este ficará ciente dos efeitos colaterais de tal alteração. 
Outra variável importante para o refinamento do escopo são os riscos envolvidos no projeto. Com a análise dos riscos feita de forma adequada, é possível prever e se precaver de eventualidades que possam impactar negativamente o projeto, através de planos de contorno para cada risco mapeado. A estimativa de prazo final para a entrega e conclusão do projeto, por sua vez, deverá considerar uma folga para tais eventualidades, evitando que prejuízos de tempo e custos aconteçam. 
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos! 
Técnicas de levantamento de requisitos
Para realizar o processo de levantamento de requisitos, você terá que entender o negócio que está sendo mapeado, suas regras e seus detalhes técnicos. Muitas vezes, o passo inicial para esta fase é a realização de entrevistas com o cliente (ou as partes interessadas), de modo a compreender sua expectativa com relação ao produto que será construído. 
Um problema, no entanto, é a dificuldade encontrada por muitos clientes para conseguir expressar seus anseios da melhor forma possível, de modo a deixar claras todas as regras de negócio inerentes ao domínio que englobará a aplicação. Para conseguir obter o nível de detalhamento dos requisitos necessário para que a equipe de desenvolvimento possa atuar (programando o software), técnicas podem ser aplicadas em conjunto com as entrevistas. 
Sommerville (2011) apresenta as técnicas mais utilizadas para este processo, tais quais: 
· Levantamento orientado a ponto de vista. 
· Etnografia. 
· Workshops. 
· Prototipagem. 
· Entrevistas. 
· Questionários. 
· Brainstorming. 
· JAD.  
Levantamento orientado a ponto de vista 
Também conhecida como VORD, sigla em inglês para definição de requisitos baseados em pontos de vista, será possível analisar as funcionalidades que deverão ser providas pelo sistema a partir da visão dos mais diferentes interessados no produto. Desta forma, procura-se definir as necessidades de cada interessado e mapear as regras de negócio de acordo com o perfil de cada interessado. 
Uma característica importante da utilização desta técnica é a detecção dos conflitos existentes nos diferentes pontos de vista dos diversos interessados, mapeando estes conflitos para que possam ser resolvidos em um consenso entre os diferentes stakeholders (interessados).  
Etnografia 
Esta técnica consiste em mapear as funcionalidades de uma aplicação de acordo com a observação da estrutura organizacional e sua hierarquia, assim como a cultura empresarial, de modo que o analista responsável pelo levantamento das funcionalidades deverá se inserir no dia a dia do ambiente de trabalho no qual o sistema será utilizado.   
Workshops 
Para a aplicação desta técnica, você deverá montar uma equipe de desenvolvedores e uma equipe com os principais interessados no projeto (os que mais sabem do negócio e melhor representam o ambiente no qual o sistema será utilizado), com a finalidade de fomentar o trabalho em grupo e a interação entre os participantes.  
Prototipagem 
A criação de protótipos é importante para que os stakeholders possam validar, de forma visual, os requisitos que estão sendo mapeados e ajustar (ou não) às suas reais necessidades. É possível adicionar validações de campos e fluxo entre as diferentes páginas da aplicação, assim como a disposição dos campos nas telas do sistema.  
Entrevistas 
A realização de entrevistas acontece, principalmente, nas etapas iniciais do projeto, através das quais se procura entender as necessidades do cliente e o domínio da aplicação.  
Questionários 
A elaboração de questionários a respeito de como deve ser o comportamento do sistema com os requisitos desejados é uma boa forma de se entender o fluxo da aplicação e as regras de negócio específicas do domínio.  
Brainstorming 
Tempestade de ideias é uma técnica indicada para que todos os interessados possam expor seus anseios em relação ao projeto, sendo possível armazenar as ideias que não forem contempladas em um primeiro momento do projeto para evoluções futuras.  
JAD 
Joint Application Design, ou Projeto de Aplicação Conjunta, tem o objetivo de criar uma visão única da aplicação, para que todos os interessados possam avaliar e apresentar suas contribuições.
Papel do analista de sistemas e engenheiro de software na engenharia de requisitos
A Engenharia de Software, conforme explica Sommerville (2011), objetiva fornecer ferramentas e técnicas para o processo de construção profissional de uma aplicação, indo além da mera codificação amadora. 
O papel do engenheiro de software é, então, seguir um processo de construção de softwares baseado em metodologias bem validadas, que gerarão produtos, os quais, por sua vez, poderão ser vendidos para clientes. Estes produtos podem estar em diferentes categorias, tais como: 
· Produtos genéricos: aplicações construídas de forma a englobar as principais funcionalidades de um domínio, sem se preocupar com regras de negócio específicas de cada cliente. 
· Produtos sob encomenda: aplicações que são específicas para atender às necessidades do cliente que fez a encomenda, de modo a atender às suas regras de negócio particulares. 
Quando uma aplicação é construída de forma genérica, também conhecida como software de prateleira, ela não atenderá às necessidades específicas de uma organização, da mesma forma que os ajustes e as eventuais modificações na aplicação são feitos pela equipe que construiu o produto. Por outro lado, quando uma aplicação é encomendada, seus ajustes e sua manutenção serão solicitados pelo cliente que realizou a encomenda, de modo que a aplicação se mantenha sempre ajustada à sua dinâmica organizacional.  
O papel do engenheiro de software é realizar todo o processo de construção e manutenção da aplicação, estando mais focado na parte da codificação e nas questões que estão envoltas a ela. É responsável pelas fases do levantamento de requisitos (elicitação, validação e refinamento das funcionalidades), definindo quais as técnicas que serão utilizadas pela equipe de desenvolvimento para a execução desta fase, além da definição da metodologia de desenvolvimento que será utilizada pela equipe e da orquestração das cerimônias e fases que precisam ser seguidas, conforme a metodologia escolhida. 
Ao final do processo de construção da aplicação, o fato de se ter seguido uma metodologia bem fundamentada, gerida pelo engenheiro de software, garantirá um produto com boa qualidade e de fácil manutenção, que deverá estar bem documentado, de modo a facilitar o entendimento dos membros da equipe de desenvolvimento e servir de manual de utilização para o usuário final. 
Também cabe ao engenheiro de software aplicar técnicas que garantam a qualidade do produto desenvolvido, que podem ser utilizadas para a validação dos requisitos, por parte do cliente, ou nos testes funcionais da aplicação, a fim de garantir que as respostas obtidas com as funcionalidades do software estão de acordo com as esperadas, conforme o mapeamento das necessidades do cliente. 
O analista de sistemas, por sua vez, trabalhará em conjunto com o engenheiro de software para garantir o sucesso do projeto e, consequentemente, do produto gerado por ele. O analista desempenhará o papel de se aprofundar nas atividades processuais do projeto de desenvolvimento, como a modelagem da estrutura que será implementada no banco de dados, a modelagem do negócio a ser trabalhado no projeto, a arquitetura das camadas da aplicação, os padrões de projeto que deverão ser utilizados, entre outras questões técnicas voltadas a processos.
Saiba mais
A ferramenta Creately, gratuita, auxilia na criação de ferramentas visuais para colaboração nas reuniões de levantamento de requisitos,como mapas mentais, diagramas de casos de uso, diagramas de sequência, entre outras. Basta clicar no botão “Ir para App” que uma sessão gratuita e sem necessidade de cadastro será iniciada. 
A ferramenta gratuita Miro poderá te auxiliar na escrita dos requisitos e no processo de detalhamento. As funcionalidades poderão ser compartilhadas com os membros da equipe de desenvolvimento. 
Referências
ESCOLA NACIONAL DE ADMINISTRAÇÃO PÚBLICA. Gerência de Projetos – Teoria e Prática. Módulo 2: Gerenciamento de Escopo, Tempo e Custos do Projeto. Brasília, DF: ENAP, 2014. Disponível em: https://repositorio.enap.gov.br/bitstream/1/1109/1/GerenciaDeProjeos_modulo_2_final_.pdf. Acesso em: 8 ago. 2022.   
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011. 
Introdução
Olá, estudante! 
Nesta aula, você aprenderá a importância do correto entendimento acerca do domínio do problema de uma nova aplicação e como isso influencia a especificação de requisitos. Aprenderá também quais são os processos necessários para a especificação de requisitos e como identificar e mapear as restrições e premissas iniciais do projeto. 
As funcionalidades de uma aplicação, para que satisfaçam às reais necessidades do cliente, precisam ser bem compreendidas e descritas, conforme as premissas e restrições de cada projeto. 
Lembre-se de que o seu conhecimento só dependerá de você, então não se limite apenas ao visto na aula, mas esteja sempre buscando novas formas de se atualizar. 
Bons estudos!
Domínio do problema e os tipos de requisitos
Para que uma nova aplicação tenha seu processo de construção iniciado, é preciso, em primeiro lugar, entender em qual domínio de aplicação este novo software se encaixa. Essa característica poderá ser percebida pela descrição inicial do cliente a respeito do propósito para qual aplicação será desenvolvida. 
O domínio da aplicação se caracteriza por ser o ambiente macro no qual a aplicação está inserida, ou seja, se um software que se destine ao cadastramento de consultas médicas for construído, seu domínio será o ambiente médico (clínico, hospitalar ou ambos). A partir da identificação deste domínio, termos e regras específicas, pertencentes ao domínio, serão considerados no momento da elicitação de requisitos de uma nova aplicação. 
Conforme explica Sommerville (2011), o domínio é utilizado para auxiliar na identificação de objetos, atributos e serviços que serão utilizados pela nova aplicação a ser desenvolvida. Sendo assim, antes que o processo de desenvolvimento de fato aconteça, é importante conhecer quais são estes objetos, atributos e serviços intrínsecos ao domínio, o relacionamento entre eles e como interagirão com as funcionalidades mapeadas para a sua aplicação. 
Muitas vezes, identificar requisitos que são próprios do domínio da nova aplicação requer atenção e experiência do analista responsável. Quando uma pessoa que está muito ambientada ao domínio é entrevistada, por exemplo, ela pode estar tão familiarizada com os termos, jargões e conceitos que ache desnecessário explicar para quem está fazendo o levantamento de requisitos da aplicação, ou até mesmo acredite que é tão “óbvio” que a pessoa já conheça tal assunto.  
Então, para que se consiga obter o máximo de informações possíveis acerca de um domínio e dos requisitos implícitos que uma nova aplicação precisará atender, é necessário, muitas vezes, utilizar mais de uma técnica de levantamento de requisitos para conseguir entender e mapear tais funcionalidades. As técnicas de tempestade de ideias (brainstorming) e entrevistas com o cliente poderão ser utilizadas em conjunto para esta finalidade. 
A depender do domínio do problema, os requisitos funcionais e não funcionais de sua aplicação poderão ser influenciados por ele. Um exemplo é a questão de marcação de consultas: imagine que a sua nova aplicação pertença ao domínio médico e que terá, como uma de suas funcionalidades, o agendamento de consultas médicas. Caso uma consulta já tenha sido agendada para um determinado horário e paciente, outro paciente não poderá ser agendado para este mesmo horário e médico. Isso representa uma característica do domínio, uma vez que não é possível que duas pessoas sejam atendidas pelo mesmo profissional simultaneamente. 
Os requisitos não funcionais, como questões de segurança, performance, auditoria, entre outros, também poderão ser definidos conforme a necessidade do domínio, tendo em vista que serão as características deste domínio que ditarão qual o comportamento implícito da sua aplicação. Como exemplo, podemos mencionar a anonimização de dados sensíveis dos pacientes atendidos pela nossa aplicação exemplo que mencionamos no parágrafo anterior. Dados, como nome, data de nascimento, histórico médico e documentos pessoais, precisam ser mantidos sob sigilo, conforme a Lei Geral de Proteção de Dados (LGPD), em vigor desde 2020. 
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos!  
Processos de especificação de requisitos
Após o entendimento inicial do domínio da aplicação, será necessário realizar um levantamento de quais funcionalidades que esta nova aplicação deverá prover, suas regras de negócio e os requisitos não funcionais envolvidos, considerando o domínio no qual a aplicação está inserido. 
Segundo Turine e Masiero (1996), o processo de especificação de requisitos deverá englobar as fases de aquisição, refinamento (detalhamento técnico dos requisitos) e validação destes com as necessidades reais do usuário. Os requisitos precisam estar livres de ambiguidades, com uma linguagem clara e objetiva, destrinchando como deverá ser o comportamento do sistema após a sua implementação. 
Para a fase de elicitação de requisitos, o domínio da aplicação poderá fornecer um conjunto grande de funcionalidades disponíveis para serem implementadas na aplicação que será construída, sendo necessário conhecer o escopo acordado para os requisitos do novo programa. Esta limitação se faz necessária para que os balizadores do projeto, como a limitação de tempo e orçamento, não sejam infringidos pela adição de funcionalidades extras durante o andamento do projeto.
Fonte: elaborada pela autora.
Em metodologias tradicionais de desenvolvimento de softwares, como a cascata, apresentada pela Figura 1, cada fase do processo de especificação de requisitos precisa estar totalmente pronta para que a fase seguinte se inicie. Desta forma, caso o cliente necessite realizar algum ajuste em uma das funcionalidades já levantadas para a aplicação, não será possível após a fase de especificação de requisitos ter sido concluída. Este fato ocasiona, muitas vezes, o descontentamento do cliente ao final do projeto, já que o produto entregue poderá não mais atender às suas reais expectativas. 
Para ajustar o processo de levantamento de requisitos de modo a atender com mais eficiência e eficácia os anseios das partes interessadas, novas metodologias para o desenvolvimento de aplicações foram desenvolvidas, como a espiral (ou incremental) e as metodologias ágeis. 
Fonte: elaborada pela autora.
A Figura 2 apresenta as etapas da metodologia incremental, em que cada entrega incrementará um pacote de funcionalidades ao produto, que estará pronto ao final do último incremento. 
A metodologia espiral busca desenvolver uma implementação inicial da aplicação, apresentar ao cliente para obtenção de feedbacks, realizar os ajustes necessários e retomar o processo de desenvolvimento, de modo que as fases do processo de especificação de requisitos acontecem todas de forma simultânea (especificação de requisitos, implementação da aplicação e validação desta junto ao cliente). Cada versão que é apresentada ao cliente para validação é denominada versão intermediária, enquanto a aplicação validada se denomina versão final. 
Em comparação com a metodologia tradicional cascata, a metodologia incremental apresenta algumas vantagens, tais quais apresentadas no Quadro 1. 
Fonte: elaborado pela autora.
As metodologias ágeis, por sua vez,se inspiraram na metodologia incremental para otimizar ainda mais as fases do processo de desenvolvimento de aplicações, buscando aproximar o cliente das fases de levantamento de requisitos, validação e implementação. Desta forma, o cliente poderá efetuar ajustes nos requisitos levantados inicialmente, inserir novos requisitos durante o andamento do projeto (desde que acordados e os impactos de custo e prazo analisados) e obter versões parciais já prontas para serem utilizadas em produção. 
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos!
Restrições e premissas de requisitos
Todo projeto terá restrições e premissas que precisam ser levadas em consideração durante o processo de construção da nova aplicação. Essas premissas e restrições podem ser originadas tanto do domínio da aplicação (como nos casos com relação ao negócio da aplicação) como das necessidades das partes interessadas (como a restrição de orçamento disponível, por exemplo). 
Quando nos referimos às restrições, estamos falando em limitações que o negócio poderá impor, como restrições de acesso a determinadas partes da aplicação para perfis de acesso específicos e restrições de usabilidade (limitação de usuários simultâneos ou apenas um usuário poderá estar logado na aplicação com um determinado usuário ao mesmo tempo). Estas restrições são traduzidas para a aplicação como requisitos não funcionais, ligados a um ou mais requisitos funcionais da aplicação. 
Por outro lado, quando mencionamos o termo “premissas”, estamos nos referindo às pré-condições do projeto que precisarão ser consideradas verdadeiras. Um exemplo é a definição de parâmetros de inicialização com valores fixos, já que se assume que os valores esperados pela aplicação serão informados pelos parâmetros (e que estes parâmetros estarão preenchidos). 
A compreensão do negócio da aplicação pelo analista de requisitos responsável pelas fases de levantamento das funcionalidades do novo sistema é importante para que as restrições de negócio e as premissas iniciais da aplicação sejam identificadas corretamente, o que nem sempre é uma tarefa fácil, tendo em vista que a grande familiaridade do cliente com o negócio e os termos envolvidos poderão dificultar este processo de descoberta, por parecer óbvio. 
Quando uma restrição do sistema é infringida, a depender da gravidade e do tipo de restrição (se está relacionada com um requisito funcional ou não funcional), poderá trazer sérios prejuízos para o sistema, como inconsistências (em caso de englobarem requisitos funcionais), e, caso a restrição seja relacionada a um requisito não funcional, a inutilização do sistema não está descartada. Por isso, é de extrema importância observar se todas as restrições estão sendo consideradas na implementação da aplicação, através dos testes funcionais e não funcionais da aplicação. 
O prejuízo causado por uma quebra de premissa, por sua vez, poderá ser uma falha no funcionamento da aplicação, sendo percebida pelo usuário final, sendo menos grave do que o não atendimento a uma restrição. 
As restrições também podem ser mapeadas diretamente no banco de dados, quando estão relacionadas com os dados e o relacionamento entre eles, conforme apresentada na Figura 3. Neste caso, o próprio Sistema Gerenciador de Banco de Dados (SGBD) ficará responsável por garantir que todas as regras definidas pelos desenvolvedores sejam cumpridas, evitando que inconsistências aconteçam. 
Fonte: elaborada pela autora.
A Figura 3 apresenta algumas formas de implementação de restrições do negócio em banco de dados, como a checagem de valores únicos em determinados campos, o preenchimento de campos obrigatórios ou a validação dos relacionamentos entre campos de diferentes tabelas. 
Quando as restrições existem apenas a nível de aplicação, cabe à equipe de desenvolvimento garantir, através das regras de negócio implementadas e da documentação elaborada sobre estas regras, que as informações geridas pela aplicação se manterão consistentes. Quando uma equipe é formada por diversos membros, com alta rotatividade e sem uma boa documentação atualizada, pode ser mais difícil manter as restrições em consonância com o que é especificado na documentação. 
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos!
Saiba mais
Para saber mais sobre as premissas e restrições de um projeto e seu relacionamento com o escopo da aplicação, você poderá acessar o documento Módulo 2: Gerenciamento de Escopo, Tempo e Custos do Projeto
O manual prático do plano de projetos define os conceitos sobre premissas, restrições e riscos do projeto e é de leitura essencial para quem deseja conhecer melhor o processo de gerenciamento de projetos.
Referências
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011.  
TURINE, M. A. S.; MASIERO, P. C. Especificação de Requisitos: uma introdução. São Carlos, SP: Universidade de São Carlos, 1996. Disponível em: http://www2.unemat.br/rhycardo/download/engenharia_de_requisitos.pdf. Acesso em: 15 ago. 2022.  
Introdução
Olá, estudante! 
Nesta aula, você aprenderá como acontece o processo de negociação de requisitos, como técnicas para negociação podem ser aplicadas, quais as consequências de ter requisitos mal especificados em um projeto e como evitá-las.   
O sucesso de um projeto dependerá da qualidade da fase de especificação de requisitos, então é de fundamental importância que o analista responsável consiga extrair do cliente todas as informações relevantes para o projeto. 
Lembre-se de que o seu conhecimento só dependerá de você, então não se limite apenas ao visto na aula, mas esteja sempre buscando novas formas de se atualizar. Bons estudos!
Processos de negociação de requisitos
Quando um projeto possui diversos stakeholders, cada um terá suas próprias expectativas quanto ao produto e às suas funcionalidades. Desta forma, é comum que conflitos de interesses aconteçam, sendo necessária uma intermediação para que se chegue a um consenso.  
O processo de resolução de conflitos, em um projeto de software, tem por objetivo se chegar a um consenso no que diz respeito a quais funcionalidades são importantes para todos, ou grande parte dos interessados (patrocinadores), priorizando-as para a fase de implementação. 
Para iniciar o processo de negociação, o analista de requisitos responsável deverá reunir todos os interessados no projeto, que deverão expor quais as suas principais expectativas com o produto. A partir deste ponto, pode-se, por exemplo, atribuir um número a cada requisito, simbolizando um peso em termos de importância para cada stakeholder para aquela funcionalidade específica. Ao final do processo, as funcionalidades que tiverem um maior peso deverão ser as mais importantes para todos (ou a maioria), compondo o conjunto prioritário de implementação. 
Nem sempre o processo de negociação e priorização é fácil e de rápida resolução. Sendo assim, tornam-se necessárias algumas etapas de reunião entre os interessados, de modo que cada um possa apresentar seu ponto de vista e o motivo pelo qual um determinado conjunto de funcionalidades é mais importante que as demais funcionalidades.  
A Figura 1 apresenta um resumo do ciclo de negociação e priorização dos requisitos de um projeto, quando há conflitos de interesses entre os patrocinadores do projeto
Fonte: elaborada pela autora.
As rodadas de negociação, quando não se consegue chegar a um consenso, precisam de técnicas que você, como analista de requisitos ou um papel equivalente, deverá aplicar para que se consiga obter um direcionamento acerca de quais funcionalidades deverão ser priorizadas. Muitas vezes, os conflitos começam ainda no processo de levantamento dos requisitos, sendo necessário um consenso sobre quais requisitos farão (ou não) parte do projeto. 
As reuniões para negociação de requisitos precisam ter o objetivo de apresentar quais conflitos de interesse existem no projeto, a fim de obter possíveis soluções das partes interessadase quais ações poderão ser tomadas para a resolução dos conflitos. É possível, por exemplo, que a alteração em uma funcionalidade consiga solucionar um conflito de interesse existente, ajustando este requisito ao melhor para todas as partes. 
É importante que, durante a fase de elicitação de requisitos de um projeto, seja dedicado um tempo relativamente longo para este processo de negociação de requisitos, tendo em vista que é um processo interativo e que podem ser necessárias diversas rodadas de negociação até que se chegue a um denominador comum. 
O resultado do processo de negociação é um compromisso firmado entre as partes interessadas no projeto, quanto ao conjunto de requisitos que deverão ser codificados de forma prioritária. Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos! 
Técnicas de negociação de requisitos
Para que o processo de negociação de requisitos aconteça de forma satisfatória, é necessário que o analista de requisitos ou líder técnico responsável faça uso de algumas técnicas. A concordância entre as partes dirá quantas e quais técnicas devem ser utilizadas ao longo das reuniões de negociação. 
Conforme explica Ramires (2004), o processo de negociação de requisitos pode seguir por duas vertentes: a integrativa, na qual o acordo entre as partes é feito de forma colaborativa e inventiva, e a distributiva, que se mostra mais inflexível, buscando convencer as partes sobre os interesses de outros interessados, sem se preocupar com as necessidades globais.  
Estratégia integrativa 
Com a estratégia integrativa, o objetivo será agregar valor ao produto através da solução de impasses entre os interessados de forma colaborativa, na qual todos os interesses são ouvidos e busca-se alcançar um ponto de equilíbrio, no qual todos podem ter suas necessidades atendidas. 
Nesta estratégia, um interessado pode, por exemplo, renunciar aos seus interesses de forma voluntária, cedendo aos demais interessados, criando um relacionamento positivo no futuro, ou pode-se utilizar técnicas de ganha-ganha (win-win), a partir das quais todos serão beneficiados e nenhum prejudicado. 
Uma técnica que pode ser utilizada é a win-win, como apresentado por Ramires (2004), na qual se busca a concordância na negociação, beneficiando a todos as partes ou, pelo menos, mantendo um bom relacionamento entre os interessados e não causando perdas para nenhum deles. 
Nesta técnica, a utilização de ferramentas de comunicação claras e que não ocultem interesses são incentivadas, assim como a busca por acordos amigáveis e relações duradouras entre os stakeholders.  
A justiça em atender da melhor forma possível todos os anseios é sempre buscada com a estratégia integrativa.  
Estratégia distributiva 
Nesta estratégia, segundo Ramires (2004), não existe processo de negociação diplomático, mas, sim, inflexível, na qual as partes interessadas visam impor seus próprios interesses aos demais, sem se preocupar com as necessidades e os interesses alheios. 
Diferente da técnica integrativa, esta técnica utiliza estratégias de ganha-perde, que dependerá das habilidades de convencimento acerca dos interesses de um em detrimento dos demais.  
Pode-se utilizar a técnica de negociação firme, sem receio de negociar e pedir concessões. Ganhará o jogo aquele interessado que conseguir ocultar informações importantes sobre seus anseios, que possam prejudicar outras partes, fazer concessões lentamente e analisando todos os pormenores, além de utilizar o tempo a seu favor.  
Dilema estratégico 
As duas estratégias anteriormente descritas, a distributiva e a integrativa, se mostram conflituosas, uma vez que o objetivo da última é buscar um consenso de forma amigável e agradando a todas as partes, enquanto a primeira busca apenas reclamar valor. 
Sendo assim, as técnicas integrativas sempre serão vulneráveis às distributivas, uma vez que, mesmo que se busque uma amistosidade entre as partes durante o processo de negociação de requisitos, é possível que, em alguns momentos, os interessados apenas queiram reclamar o valor de seus interesses, negociando seus interesses em prol de concessões de outras partes. 
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática.  
Bons estudos!
Requisitos mal especificados: causas e efeitos
O processo de elicitação de requisitos é o momento no qual o cliente deverá apresentar o negócio ao analista de requisitos responsável, explicando as regras específicas do domínio envolvidas e suas necessidades e expectativas para a aplicação que será construída. 
Para projetos que se baseiam na metodologia tradicional cascata para a construção do software, esta fase será a única na qual o cliente e o analista de requisitos terão a oportunidade de conversar, negociar requisitos e compreender como o sistema deverá se comportar após a sua codificação. Desta forma, uma falha no entendimento de uma funcionalidade ou do contexto no qual a aplicação está inserida poderá comprometer, de forma negativa, todo o sucesso do projeto. 
Muitas vezes, o cliente tem um grande conhecimento e ambientação com o domínio do negócio da aplicação, o que o leva a crer que todas as demais pessoas também conhecem as regras de negócio intrínsecas a este domínio e, por conta disso, não é necessária nenhuma explicação. Quando o projeto tem a fase de codificação iniciada, após a elicitação de requisitos, estas regras de negócio omitidas podem ocasionar falhas na implementação, gerando descontentamento ao usuário e a inutilização do sistema criado. 
Quando a metodologia de desenvolvimento de softwares adotada pela equipe é ágil, em contraste com o que acontece com a metodologia cascata, é possível ajustar o entendimento e alterar a escrita do detalhamento dos requisitos ao longo do processo de codificação, antes que a funcionalidade tenha sido implementada, sem prejuízos para o processo. Essas dúvidas podem surgir a partir da própria equipe de desenvolvimento, que irá saná-las junto ao cliente. 
Para minimizar os riscos de retrabalho e insucesso do projeto, é necessário que a escrita dos requisitos reflita a real necessidade do cliente e que o entendimento das regras de negócio consiga ser claro e sólido o suficiente pelo analista de requisitos responsável pela elaboração do documento de especificação de requisitos.  
Uma outra causa da má elaboração das especificações de requisitos é a falta de experiência do analista na aplicação das técnicas necessárias para a fase de elicitação dos requisitos do projeto, ou até o desconhecimento das técnicas utilizadas. Dificilmente, apenas com entrevistas, um cliente destrinchará todas as funcionalidades e suas nuances de maneira desejável, de forma que, através da utilização das técnicas corretas nos momentos corretos da fase de elicitação, será possível obter informações importantes que não foram mencionadas em um primeiro momento. 
Quando um projeto possui diferentes partes interessadas, com eventuais conflitos de interesses, saber ouvir todas as partes e chegar à etapa de concordância dos requisitos e à priorização destes de maneira adequada evitará que o projeto, no momento de sua finalização, seja invalidado, já que atenderá às necessidades de todos (ou pelo menos da maioria) dos stakeholders de forma satisfatória. 
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos! 
Saiba mais
Para saber mais detalhes sobre o processo de especificação de requisitos e sua importância para a metodologia tradicional cascata, recomendo a leitura do artigo ESPECIFICAÇÃO DE REQUISITOS: UMA INTRODUÇÃO
Para metodologias ágeis, você poderá saber mais sobre o processo de engenharia de requisitos através do artigo ENGENHARIA DE REQUISITOS EM METODOLOGIAS ÁGEIS 
Referências
RAMIRES, J. J. da C. V. Negociação de Requisitos no Processo de Desenvolvimento de Software. 2004. Dissertação (Mestrado em Informática) – Universidade de Lisboa, Lisboa, 2004. Disponível em: https://repositorio.ul.pt/handle/10451/13961.Acesso em: 19 ago. 2022.  
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011. 
Compreender e reconhecer os principais requisitos de software
Para que um novo projeto de construção de software aconteça, é fundamental que as necessidades do cliente sejam traduzidas para requisitos funcionais e não funcionais. Este processo de entendimento e escrita dos requisitos amadurecerá com o andamento do projeto e conhecimento do negócio pelo analista de requisitos responsável. 
Os requisitos da aplicação ainda podem ser classificados como requisitos de usuário, que representam as funcionalidades que serão utilizadas pelos usuários e suas respectivas restrições, sem muito detalhamento de como a aplicação executará cada função, sendo escritos em linguagem natural, podendo, também, utilizar diagramas; ou como requisitos de sistema, que descreverão os requisitos de usuário com riqueza de detalhes técnicos, para que possam ser implementados pela equipe de desenvolvimento.  
Engenharia de Software e Engenharia de Requisitos 
A Engenharia de Software tem o objetivo de aplicar métodos, ferramentas e teorias para sistematizar o processo de construção de uma nova aplicação, de modo que ela possa atender às necessidades do cliente em termos de qualidade, manutenibilidade e boas práticas. Um ramo da Engenharia de Software é a Engenharia de Requisitos, que se preocupa com o processo de desenvolvimento da aplicação, englobando as fases da elicitação de requisitos (estudo de viabilidade, levantamento e análise de requisitos, especificação de requisitos, validação de requisitos e gerenciamento de requisitos). 
O papel do analista de sistemas, em um projeto de software, será garantir que as questões de negócio e de infraestrutura do projeto sejam feitas conforme a necessidade da aplicação que será construída, englobando o projeto de banco de dados, implantação da aplicação em um servidor de produção, por exemplo. Porém, é possível que o analista também se envolva com a codificação da aplicação, auxiliando o engenheiro de software, que se preocupará em aplicar as técnicas necessárias para as fases da elicitação de requisitos e garantia da qualidade do produto.  
Escopo da aplicação 
O escopo da aplicação compreende os requisitos funcionais e não funcionais do software, assim como as regras de negócio envolvidas nos requisitos. O escopo do projeto, por sua vez, englobará as premissas do projeto, suas restrições de negócio, seu prazo e seus recursos.  
Como o escopo do projeto representa uma fronteira entre o que será e o que não será considerado no software que será construído, sua delimitação precisa ser definida e acordada com o cliente antes que o processo de implementação se inicie. Caso alguma alteração seja feita após a fase de codificação da aplicação ter sido iniciada, todo o projeto será impactado, podendo ser cancelado ou, caso o produto seja finalizado mesmo assim, não atender às reais necessidades do cliente.  
Negociação de requisitos e conflitos de interesses 
Durante as fases do processo de elicitação de requisitos, em projetos com muitos interessados, é comum que ocorram conflitos de interesses a respeito de quais funcionalidades devem compor a aplicação e suas priorizações. A fim de se obter uma concordância sobre os requisitos que podem atender à maior parte de interessados, senão todos, técnicas de negociação podem ser aplicadas. 
As técnicas de negociação podem ser classificadas em duas categorias distintas e opostas: as integrativas e as distributivas. A primeira está relacionada às técnicas de ganha-ganha, buscando se alcançar um consenso de forma amigável entre todas as partes. A segunda, por sua vez, se baseia em técnicas de ganha-perde, em que cada interessado tentará convencer os demais sobre seus próprios interesses, sem se preocupar em contemplar as necessidades dos demais. 
Resumo visual
Fonte: elaborada pela autora.Fonte: elaborado pela autora.Fonte: elaborada pela autora.
Referências
PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. 9. ed. Porto Alegre, RS: AMGH, 2021.  
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011.  
TURINE, M. A. S.; MASIERO, P. C. Especificação de Requisitos: uma introdução. São Carlos, SP: Universidade de São Carlos, 1996. Disponível em: http://www2.unemat.br/rhycardo/download/engenharia_de_requisitos.pdf. Acesso em: 15 ago. 2022.