UNIDADE 2 - Classificacao de Requisitos de Software Ampli

Prévia do material em texto

Introdução
Olá, estudante! 
Nesta aula, você aprenderá como realizar a especificação dos requisitos de software, classificando os requisitos em funcionais e não funcionais e identificando-os de forma correta. 
Apresentaremos métodos de levantamento destes requisitos e como você poderá definir os requisitos necessários para a sua aplicação de forma assertiva. É preciso ter em mente que esta fase é a mais importante em todo processo de desenvolvimento de uma aplicação, de modo que um requisito não especificado corretamente poderá levar a graves consequências para o seu projeto, até mesmo podendo não satisfazer corretamente às necessidades dos patrocinadores (clientes), culminando no fracasso do produto criado. 
Bons estudos!  
Processos de especificação de requisitos
A primeira parte de um projeto de software é o processo de especificação dos requisitos de um sistema, independentemente da metodologia de desenvolvimento adotada pela equipe. 
Todo o processo de especificação de requisitos requer entrevistas com o cliente (ou seus representantes, que denominamos de parte interessada no produto), com o intuito de escrever um artefato descrevendo o requisito, sua importância para o sistema e a sua prioridade no desenvolvimento do produto. Porém, nem sempre o cliente consegue descrever com clareza como a aplicação que será construída deverá funcionar, ou seja, como os requisitos da aplicação precisarão estar especificados e construídos e como será a interação entre eles. 
O objetivo do processo de levantamento de requisitos é auxiliar a equipe de desenvolvimento na construção da aplicação. Portanto, precisará conter as regras de negócio, as regras de validação (aceitação) e as respostas esperadas para a ação (requisito ou funcionalidade) realizada no sistema. 
Requisitos podem ser classificados como sendo de usuário ou de sistema. Requisitos de usuário são especificados em linguagem natural, sem muito detalhamento (ou seja, nível macro), muitas vezes utilizando diagramas auxiliares para representação da funcionalidade aos usuários finais. Requisitos de sistema, por sua vez, são descrições detalhadas de como os requisitos do usuário devem funcionar e interagir entre si, representando o nível de entendimento necessário para a equipe de desenvolvimento poder implementar o produto desejado. 
É importante que você tenha mais de uma visão de um mesmo requisito (a macro e a detalhada), tendo em vista que cada visão será apresentada a pessoas diferentes (cliente ou desenvolvedor) e precisará ter o entendimento comum para todas elas. 
A escrita de um requisito pode ser feita, a princípio, em linguagem natural, ou seja, em linguagem simples e concisa, que expresse a necessidade do usuário. Cada requisito precisa especificar apenas uma função do sistema ou produto que será desenvolvido. 
A linguagem natural estruturada, conforme menciona Sommerville (2011), também pode ser utilizada, na qual um formulário padrão pode ser preenchido com os campos que estarão envolvidos no requisito e suas respectivas descrições, fornecendo informações técnicas sobre a funcionalidade que está sendo especificada. 
Para auxiliar no processo de especificação de um requisito, alguns diagramas ou documentos podem ser construídos, como os diagramas de caso de uso ou o documento da história (ou estória) de usuário.  
Caso de uso 
Um caso de uso terá, por objetivo, descrever, de forma visual, um cenário que represente a interação do usuário com o sistema. Desse modo, é possível conhecer quais os atores que estarão envolvidos em cada interação e quais funcionalidades o sistema provê. 
A Figura 1 apresenta um exemplo de como um caso de uso pode ser elaborado. 
Fonte: elaborada pela autora.
A Figura 1 apresenta, para um exemplo de manipulação de livros através de um sistema, as operações básicas que um usuário externo poderá fazer, como a inserção de um novo livro, a alteração de um livro já cadastrado e a consulta a livros.  
História (ou estória) de usuário 
Em times que adotaram metodologias ágeis para o desenvolvimento de novos produtos, como a SCRUM, as histórias de usuário são escritas como documentos que substituirão o documento de especificação de requisitos e diagramas auxiliares (como os casos de uso), apresentando como a interação acontecerá entre o usuário final e a funcionalidade do sistema, qual a resposta esperada e quais os critérios de aceitação para que o requisito possa ser dado como pronto (ou seja, que satisfaça a necessidade do usuário). 
Um exemplo de história de usuário para o cenário de inclusão de novo livro, apresentado na Figura 1, ficaria como exibido no Quadro 1. 
Fonte: elaborado pela autora.
Requisitos funcionais
Os requisitos funcionais representam as ações do sistema que serão utilizadas pelo usuário final, ou seja, como o sistema (ou aplicação) deverá reagir às interações do usuário. Em suma, será toda função disponível ao usuário final e que se espera que o sistema forneça (seu propósito). 
É importante que, ao realizar o mapeamento das funcionalidades que o sistema deve prover, a escrita englobe apenas um único requisito por vez. Além de facilitar o desenvolvimento pela equipe de programação, facilitará o entendimento do usuário final e a validação dos requisitos com as reais necessidades das partes interessadas (stakeholders). 
Estes requisitos precisam estar mapeados no documento de especificação de requisitos, elaborado pela equipe de levantamento das especificações do produto, e precisam estar em linguagem clara e com o detalhamento adequado para que os desenvolvedores possam realizar a codificação. 
Quando os requisitos de um sistema são mapeados, é fundamental que o cliente defina quais devem ser priorizados, ou seja, quais agregarão mais valor ao produto que será entregue ao final do projeto. Essa priorização, caso o time esteja trabalhando em cima de metodologias ágeis para desenvolvimento de sistemas, poderá ser alterada ao longo do projeto. Para metodologias tradicionais, como a cascata, é fundamental que todo o processo de especificação de requisitos seja totalmente definido antes do projeto começar de fato, sem a possibilidade de alteração após o início da construção. 
Alguns exemplos de requisitos funcionais são: 
· Cadastro de dados de entidades mapeadas (livro, carro, pessoa, jogo etc.). 
· Alterações de dados. 
· Consultas. 
· Extração de relatórios. 
· Remoção de dados. 
Muitas vezes, o cliente que está auxiliando a equipe de desenvolvimento a mapear os requisitos funcionais não tem total clareza sobre como a funcionalidade deve ser provida pelo sistema, deixando dubiedades ou até detalhes técnicos do negócio (como as regras de validação) ocultos até o momento da implementação.  
Para sanar qualquer eventual dúvida ou falta de clareza na especificação de requisitos, é importante a utilização de recursos que auxiliem a parte interessada na validação deles, como a prototipação. Protótipos funcionais, que apresentarão o layout da tela e uma funcionalidade simulada através de linguagens voltadas para a camada de apresentação (como a Javascript), darão uma maior clareza ao usuário final, o qual, por sua vez, poderá realizar ajustes para atender às suas expectativas. 
Todos os protótipos construídos na fase do levantamento de requisitos e da validação dos requisitos funcionais serão reaproveitados na fase de implementação do sistema pela equipe de desenvolvedores. 
Uma questão importante, quando se trata de requisitos funcionais, é que eles precisam estar definidos de forma completa e consistente, ou seja, o usuário precisa definir todas as funcionalidades necessárias para o sistema, e estas funcionalidades não podem ter critérios contraditórios. Como critérios contraditórios, entende-se que uma funcionalidade não pode ter um critério que é desfeito por outra funcionalidade.
Requisitos não funcionais
Requisitos não funcionais, por sua vez, são aqueles que servem como suporte aos funcionais, mas que não são percebidos (ou visíveis) ao usuário final. Exemplo desta categoria de requisitosão os requisitos de performance, segurança, auditoria de informações (logs) e os demais requisitos que servem de suporte para o correto funcionamento dos requisitos visíveis (funcionais). 
Esta categoria de requisitos é mais crítica para o sistema que os requisitos funcionais, tendo em vista que, caso aconteça alguma ação indevida do usuário final, como conseguir entrar no sistema sem ter passado pelas etapas de validação de autenticação, todo o sistema estará comprometido, podendo até mesmo ser invalidado. 
É comum que requisitos não funcionais estejam espalhados por várias partes do sistema, englobando, inclusive, mais de um requisito funcional, até mesmo pela sua natureza (performance, segurança etc.). 
O mapeamento dos requisitos não funcionais acontece através do entendimento de quais são as necessidades de restrição das partes interessadas, como restrição de segurança, orçamento, interoperabilidade com outros sistemas, políticas organizacionais, legislação de privacidade e segurança ou normas de segurança interna. 
Conforme apresentado por Sommerville (2011) e Pressman e Maxim (2021), a origem dos requisitos não funcionais podem ser: 
· Requisitos de produto: restringem o comportamento da aplicação, como questões de desempenho, taxa aceitável de falhas, proteção e usabilidade do sistema. 
· Requisitos organizacionais: originados de políticas empresariais ou do cliente, como os processos operacionais, processo de desenvolvimento (como a definição de uma linguagem de programação específica), ambiente de desenvolvimento ou normas de processo que precisam ser utilizadas. 
· Requisitos externos: abrangendo todo requisito externo ao sistema e seu desenvolvimento, como leis, interoperabilidade com sistemas externos, ética etc. 
Fonte: adaptada de Sommerville (2011).
A Figura 2 apresenta um resumo dos tipos de requisitos não funcionais, de acordo com as categorias anteriormente apresentadas. 
É relativamente comum que as partes interessadas ditem os requisitos não funcionais como metas ou objetivos do sistema, como a facilidade de uso ou performance. Um ponto importante é que, caso sejam especificados desta forma, os requisitos não funcionais podem ser difíceis de serem testados, tornando-se um ponto subjetivo do sistema e abrindo brechas para diversos entendimentos. 
A forma ideal para que um requisito não funcional seja especificado é quantitativamente, ou seja, da forma mais objetiva possível (de preferência com números), a fim de que possam ser validados ou mensurados. Porém, nem todo requisito não funcional poderá ser medido quantitativamente, o que indica que métricas precisam ser adotadas para justificar ou validar a implementação correta destes requisitos. 
Outro ponto importante de ser destacado é que, no documento de especificação de requisitos, é difícil realizar a separação entre os requisitos funcionais dos não funcionais, tendo em vista que, em muitos casos, requisitos não funcionais podem englobar um ou mais dos requisitos funcionais. Caso não se deixe clara a delimitação entre a funcionalidade provida pelo sistema e os requisitos não funcionais que estão envolvidos nesta funcionalidade, o entendimento poderá ficar confuso para a equipe de desenvolvimento. Portanto, quando se tem um requisito não funcional interligado a um requisito funcional, você deverá fazer o destaque na parte que engloba o requisito não funcional.
Saiba mais
O artigo Como escrever requisitos de software de forma simples e garantir o mínimo de erros no sistema/app?? apresenta como especificar requisitos de uma aplicação de forma simplificada, minimizando os erros. 
A ferramenta OpenReq é gratuita e voltada para o gerenciamento de requisitos. 
A ferramenta SIGERAR também é gratuita e voltada para o gerenciamento e a rastreabilidade dos requisitos durante todo o ciclo de vida da aplicação.
Referências
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. 9. ed. Nova Iorque: Mc Graw Hill Education, 2021.  
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011.  
Introdução
Olá, estudante! 
Nesta aula, você aprenderá quais critérios podem ser levados em consideração no momento de priorizar os requisitos de uma aplicação para seu desenvolvimento, assim como as técnicas que podem ser utilizadas para auxiliar o processo de priorização e as ferramentas que podem auxiliar no processo de priorização.  
A priorização dos requisitos especificados é fundamental para que as funcionalidades mais importantes, ou seja, aquelas que agregam mais valor ao negócio do cliente e, consequentemente, ao produto construído, sejam antecipadas em relação àquelas menos prioritárias (que agregam menos valor ao produto). 
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!  
Critérios de priorização e negociação de requisitos
Após a fase de entrevistas para o levantamento de requisitos junto ao cliente, é preciso priorizar os requisitos, de modo a começar a construção do produto pelos requisitos que agregam mais valor ao produto, ou seja, que sejam mais importantes ao usuário final. 
Esta priorização dos requisitos levantados deve acontecer após os requisitos terem sido agrupados em grupos com requisitos similares. A conclusão desta etapa resulta num modelo de arquitetura do produto que será desenvolvido, apresentando onde cada requisito se encaixa no modelo. 
Quando um produto envolve diferentes áreas e, consequentemente, possui diferentes patrocinadores, cada qual com seus respectivos requisitos, é comum ocorrerem conflitos de interesses. Estes conflitos podem ser resolvidos com a priorização dos requisitos, após reuniões de alinhamento entre estas diferentes partes interessadas e analisando a relação entre benefício do desenvolvimento versus custo para implementação. 
Muitas vezes, algumas funcionalidades dependem da implementação de outras, o que ocasiona na priorização destes pré-requisitos, para que as demais funções dependentes possam ser codificadas. 
Quando um consenso não é alcançado, através de reuniões com os stakeholders (partes interessadas), fica muito difícil para o analista de requisitos ou o líder de projetos indicar para a equipe de desenvolvimento quais funcionalidades agregam mais valor, tendo em vista que isso dependerá do negócio do cliente e de todas as questões que envolvem o projeto, como prazo e limitação de orçamento.  
Quando nos referimos às metodologias tradicionais de desenvolvimento de projetos, como a cascata, a priorização dos requisitos deverá estar concluída antes que a fase de implementação do produto seja iniciada e não poderá ser alterada após este início. Sendo assim, um erro no planejamento desta priorização poderá ocasionar em invalidação do produto pelo cliente, no momento da entrega e validação, causando prejuízo tanto para o cliente quanto para a empresa que desenvolveu o produto. 
Em equipes que seguem as metodologias de desenvolvimento ágeis, como a SCRUM, para cada ciclo de entrega deverá ser feita a priorização dos requisitos que serão detalhados e implementados pela equipe. Estes requisitos detalhados são provenientes de uma lista com os requisitos macros, priorizados de acordo com a necessidade do cliente. Ao longo do processo de desenvolvimento, é possível alterar a prioridade dos requisitos, conforme as necessidades forem mudando, de modo a sempre adequar o que será entregue ao cliente com a sua real necessidade do momento.  
A priorização não dependerá do detalhamento dos requisitos para acontecer, de modo que tornar o processo mais simples, até mesmo ainda utilizando o nível macro de especificação, poderá facilitar o entendimento das partes interessadas e, consequentemente, o processo como um todo. 
Uma outra questão importante a ser levada em consideração no momento da priorização dos requisitos é a complexidade técnica e a dificuldade de implementação. Esta percepção é tida pela equipe de desenvolvimento, que pode, junto ao cliente, auxiliara resolução de conflitos de interesses das partes interessadas e definir quais funcionalidades estarão presentes na próxima entrega do produto.
Técnicas de priorização de requisitos
Para realizar o processo de priorização de requisitos, é fundamental a utilização de técnicas de priorização, tendo em vista que muitos conflitos de interesses podem existir entre os patrocinadores, resultando em diferentes pontos de vista em termos de quais requisitos devem ser antecipados em sua implementação. 
Nem sempre é algo trivial para a equipe de desenvolvimento, principalmente ao analista de requisitos, ao líder técnico ou ao product owner (dono do produto, na metodologia SCRUM) inferir quais as funcionalidades que mais agregam valor ao sistema que está sendo desenvolvido e atendem às principais necessidades do cliente. Sendo assim, é imprescindível a participação do cliente neste processo de priorização, mas este, por sua vez, pode também ter dificuldades em definir o grau de importância dos requisitos levantados. 
Para auxiliar na classificação dos requisitos, em termos de priorização, existem as técnicas de priorização, como a utilização de escalas de priorização, similares às apresentadas na Tabela 1. Conhecida como Nominal Scale, esta técnica considera que requisitos que estejam organizados dentro do mesmo grupo possuem o mesmo nível de importância e, consequentemente, a mesma prioridade.  
Fonte: adaptado de Generoso (2019).
O Quadro 1 apresenta a classificação pelo nível de criticidade do requisito, agrupado na escala alto, médio ou baixo. A partir desta priorização, busca-se entrar em consenso com as partes interessadas sobre quais requisitos serão implementados em cada entrega do produto. 
Requisitos que sejam mandatários para a implementação de outras funcionalidades tendem a ser classificados como de maior prioridade, tendo em vista que a interdependência com outros requisitos é alta. 
Uma escala semelhante, que agrupa os requisitos em termos de quão essencial este o é para agregar valor ao produto, é apresentada no Quadro 2. 
Fonte: adaptado de Generoso (2019).
O Quadro 2 apresenta uma classificação por obrigatoriedade dos requisitos para o produto, de modo que se tem como essencial aquele requisito obrigatório no sistema/aplicação; condicional para os requisitos que agregam melhorias, mas que a falta não implica invalidação do produto; por último, os requisitos tidos como opcionais, que podem ou não ser implementados, não fazendo falta caso não estejam presentes. 
Uma técnica amplamente utilizada para priorização dos requisitos junto aos stakeholders se baseia na quantidade de dependências de uma funcionalidade em relação às demais e na preferência das partes interessadas em termos do que pode estar agregando mais valor ao produto. Essa técnica depende muito do fator humano para sua aplicação, tendo em vista que as dependências são informadas pela equipe de desenvolvimento, com base em experiências anteriores dos membros da equipe. 
A técnica Ordinal Scale, por sua vez, realiza a comparação entre dois requisitos para avaliar qual dos dois será mais importante ao produto. O objetivo será montar uma lista ordenada com as funcionalidades listadas por ordem de implementação. 
Existe também a técnica Ratio Scale, que utiliza uma escala de decisão para decidir pela priorização dos requisitos de forma mais precisa que as outras duas técnicas (ordinal e nominal), já que identifica a diferença relativa entre os requisitos. As técnicas ordinal e nominal auxiliarão apenas na classificação dos requisitos.
Ferramentas na engenharia de requisitos
Não somente técnicas de priorização de requisitos são importantes para ordenar, de forma coerente com as necessidades do usuário final, as funcionalidades especificadas para o produto. Existem também ferramentas que podem auxiliar no processo de priorização. 
Com as ferramentas, é possível enxergar com mais precisão os relacionamentos entre os requisitos, assim como fatores que podem classificá-los como mais ou menos prioritários, em relação às outras funcionalidades. 
A primeira ferramenta que apresentaremos é a Matriz de Priorização. Com ela, é possível estabelecer quais funcionalidades precisam ser implementadas em qual ordem, de acordo com critérios claros e bem definidos, evitando descumprimento de prazos e garantindo foco naquilo que realmente precisa estar pronto. Ela é construída em formato de tabela, gráfico ou quadrante, ficando a cargo da equipe qual a melhor forma de representação. 
Um benefício da utilização da Matriz de Priorização é que as partes interessadas estarão cientes dos prazos estabelecidos para construção de cada funcionalidade, se acontecerá algum atraso ou imprevisto, sendo possível renegociar prazos ou alterar a ordem de prioridade de algum requisito de forma mais consciente. 
Para montar sua tabela, os seguintes passos precisam ser seguidos: 
1. Listagem das funcionalidades que precisarão ser priorizadas. 
2. Estabelecimento de critérios de seleção, representando quais condições serão levadas em consideração para a seleção dos requisitos. Podem ser considerados critérios a urgência, gravidade, tendência, benefício, satisfação do cliente etc. 
3. Atribuir uma pontuação para cada critério especificado, utilizando-se uma escala (como de 1 a 5), onde 1 representa pouco importância para o critério e 5 muita importância para o critério. Esta escala deverá ser utilizada para todos os requisitos envolvidos. 
4. Montar uma tabela com as informações levantadas, na qual as linhas conterão as funcionalidades (requisitos), e as colunas, os critérios especificados, preenchendo qual a “nota” atribuída para cada critério, conforme a funcionalidade. 
5. Associar as pontuações para cada funcionalidade, executando operações, como soma, multiplicação ou divisão, que serão aplicadas conforme o método de matriz escolhido. O resultado desta etapa será o ranqueamento de cada demanda, que expressará a ordem de prioridade que deverá ser seguida pela equipe de desenvolvimento. 
Matrizes de Priorização podem ser, conforme apresenta Justo (2019), dos seguintes tipos: 
· GUT: considerará critérios, como a urgência, a gravidade e a tendência, realizando a operação de multiplicação ao final do processo de atribuição de pesos (na escala de 1 a 5 para cada critério). 
· BASICO: considera os seguintes critérios: benefícios para a empresa, abrangência dos resultados, satisfação do cliente, investimento requerido, cliente externo satisfeito e operacionalidade simples. Cada critério receberá uma pontuação, obedecendo à escala de 1 a 5, aplicando a operação de soma em vez da multiplicação. 
· RICE: considera os critérios reach (quantidade de pessoas impactadas pela funcionalidade); impact (impacto da demanda, que pode ser classificado em massivo (3 pontos), grande (2 pontos), médio (1 ponto), baixo (0,5 ponto) e mínimo (0,25 ponto)); confidence (nível de confiança no resultado, também classificado em escala, que pode ser alto (100%), médio (80%), baixo (50%) e mínimo (20%)); effort (esforço ou tempo necessário para implementar a demanda). O resultado é feito através da operação de multiplicação das pontuações atribuídas para os critérios de reach, impact e confidence, dividindo o resultado pelo effort. 
· 4X4: considera dois critérios, que podem ser escolhidos como os mais importantes por quem estiver montando a matriz. A partir daí, um gráfico cartesiano pode ser construído com notas atribuídas aos dois critérios, variando na escala de 1 a 4.
· Saiba mais
· 
· Para exemplos de utilização de Matriz de Priorização, recomendo a explicação deste artigo Matriz GUT (Matriz de Priorização), que também possui um modelo para construção da Matriz de Priorização GUT. 
· Referências
· 
· GENEROSO, M. A. P. Dependency Rank: método de priorização de requisitos baseado nas relações de dependência identificadas por PLN. 2019. Dissertação (Mestrado em Informática) – Universidade Federal do Paraná, Curitiba, 2019. Disponível em: https://www.prppg.ufpr.br/siga/visitante/trabalhoConclusaoWS?idpessoal=54589&idprograma=40001016034P5&anobase=2019&idtc=1424.Acesso em: 28 maio 2022.  
· JUSTO, A. S. Matriz de Priorização: Como organizar e selecionar projetos, processos e chamados em 6 passos. Euax, 2019. Disponível em: https://www.euax.com.br/2019/06/matriz-de-priorizacao/. Acesso em: 28 maio 2022.  
· SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011.  
· Introdução
· 
· Olá, estudante! 
· Nesta aula, você aprenderá como um requisito é mantido e gerenciado ao longo do ciclo de vida de um projeto, assim como sobre os cenários de uso dos requisitos e como elaborar casos de uso para os requisitos elucidados.  
· Você verá exemplos práticos de elaboração do diagrama de casos de uso e o nível de abordagem que deverá adotar para escrever seus requisitos funcionais e não funcionais. 
· 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!  
Requisitos no ciclo de vida do projeto
Após a fase de coleta inicial dos requisitos funcionais e não funcionais de um sistema, do processo de validação dos requisitos junto ao cliente e, por fim, da priorização conforme a necessidade das partes interessadas, é chegada a hora da implementação do produto. 
Ao dar início à fase de codificação, a equipe de desenvolvimento poderá ter dúvidas quanto ao que está escrito no documento de especificação de requisitos, ou história de usuário, sendo necessário perguntar ao analista que realizou as entrevistas com o cliente, evitando retrabalhos e codificação errada pela falha no entendimento. 
Muitas vezes, durante o processo de construção da aplicação, o cliente se dá conta de que o que está sendo desenvolvido não irá, de fato, satisfazer suas expectativas com o produto, solicitando mudanças nos requisitos previamente levantados. Em metodologia tradicional de desenvolvimento, como a cascata, que os requisitos precisam estar totalmente levantados e validados antes do início da fase de construção da aplicação, uma alteração posterior de qualquer requisito pode representar a invalidação do projeto ou, em casos menos drásticos, causar atraso no prazo de entrega acordado, com reflexos no orçamento, que será maior. 
Já para projetos que utilizem metodologias ágeis ou que permitam modificações após a fase de especificação de requisitos inicial, é possível alterar o documento de especificação e/ou história de usuário, para que se adeque às novas necessidades apontadas pelo cliente. O time de desenvolvedores, por sua vez, precisará adequar a aplicação que está sendo construída ao que foi solicitado como ajustes, garantindo que a entrega de valor ao usuário será feita. 
A priorização dos requisitos é um outro fator que também pode ser alterado a qualquer momento do ciclo de vida do projeto, sempre buscando respeitar o nível de importância de cada requisito, definido pelas partes interessadas.  
Durante as fases de testes e entrega, após a apresentação ao cliente do que foi construído, ainda podem ser solicitados ajustes, que precisarão ser negociados com o analista de requisitos (ou product owner, em caso de utilização da metodologia ágil SCRUM), para que o time de desenvolvedores possa fazer o melhor para atender às solicitações, respeitando o orçamento e o prazo acordados. 
Uma vez que a aplicação seja entregue ao cliente final, novos requisitos e necessidades ainda podem surgir, o que precisará realizar um gerenciamento de mudanças, por parte do analista responsável pela fase de levantamento de requisitos iniciais, para garantir que, mesmo após a solicitação das alterações nos requisitos já levantados (e, muitas vezes, até já implementados), o histórico das alterações possa ser mantido.  
Garantir que o documento de requisitos esteja de acordo com a realidade do código construído auxiliará o entendimento de novos integrantes da equipe de desenvolvedores, da mesma forma que dirimir eventuais dúvidas futuras sobre as regras de negócio pelos membros da equipe de desenvolvimento e/ou manutenção (sustentação). 
Alguns fatores podem desencadear alterações ou surgimento de novas funcionalidades. Sommerville (2011) e Pressman e Maxim (2021) destacam, como sendo os principais, os seguintes: 
· Alteração nos equipamentos de hardware disponíveis, em legislações ou prioridades do negócio. 
· Diferença de interesses entre os patrocinadores e os usuários finais do sistema que está em desenvolvimento. 
· Conflito de interesses em sistemas com muitos interessados, gerando necessidades e prioridades diferentes e, em muitos casos, até contraditórias. 
	Cenários de uso de requisitos
A especificação de um requisito se inicia pela sua forma macro, ou seja, pela descrição simples da funcionalidade que deve ser provida pela aplicação. Deste modo, em um primeiro momento, o cliente não especificará detalhes de quais regras de negócio a funcionalidade implementará, nem quais os tipos de campos existentes que serão manipulados ou até quais os perfis que terão acesso e quais não terão. 
Para garantir que a equipe de desenvolvimento possa entender, de forma técnica, o que está sendo solicitado pelo cliente, é preciso que ocorra um detalhamento de como o requisito deverá funcionar, com suas regras de negócio, interações com outras telas (ou módulos do sistema e até de outros sistemas, caso ocorra), permissões de acesso ou utilização da funcionalidade, mensagens de erro que devem ser apresentadas, em caso de alguma inconsistência na entrada de dados, entre outras questões técnicas. 
A este detalhamento de um requisito damos o nome de cenários de caso de uso. Os tipos de cenários de caso de uso existentes podem ser classificados como: 
· Principal: fluxo considerado esperado para a funcionalidade mapeada, ou seja, o “caminho feliz” com as entradas esperadas e a resposta esperada para o requisito. 
· Alternativos: fluxos que podem estar mapeando ações adversas que o usuário pode estar executado, que foge do caminho principal a ser percorrido, como ausência de preenchimento de campos obrigatórios, escolhas de opções que não sejam a opção para o fluxo principal etc. São ações que alteram o comportamento da aplicação, ao ponto de desviar as respostas fornecidas como padrão. 
· Exceção: um fluxo de exceção compreende erros ou bugs que podem acontecer durante a execução de uma funcionalidade. Por exemplo: se você está executando uma funcionalidade de pagamento de uma compra e a máquina do cartão não consegue estabelecer uma conexão com o banco responsável pelo cartão que está sendo utilizado, então aconteceu um fluxo de exceção. 
Os cenários de caso de uso se aplicam somente aos requisitos funcionais do sistema, já que estes representam as ações que devem ser implementadas e providas ao usuário final. Os requisitos não funcionais acabam fazendo parte do detalhamento dos casos de uso funcionais, tendo em vista que são considerados transversais e acabam englobando uma ou mais funcionalidades do sistema. 
Quanto mais fluxos alternativos forem levantados e documentados, assim como as possíveis exceções que podem acontecer, melhor será a resposta do sistema ao comportamento do usuário e mais “blindada” sua aplicação estará contra os mais variados tipos de comportamento de seus usuários finais. As exceções serão úteis para apresentar mensagens amigáveis ao usuário final, em caso de alguma falha acontecer. 
Um fluxo alternativo aparece no diagrama de caso de uso como uma ação estendida, utilizando a indicação <<extend>>. Um exemplo está apresentado na Figura 1
Fonte: elaborada pela autora.
Conforme ilustrado na Figura 1, o ator Usuário RH poderá utilizar a funcionalidade Cadastrar aluno, que deverá ter, como fluxo alternativo, a situação na qual um aluno já está cadastrado. Então, Aluno já cadastrado estende da funcionalidade Cadastrar aluno. 
Caso de uso de requisitos
Para escrever um requisito, de forma que seja validado pelo cliente e possa, posteriormente, ser implementado pela equipe de desenvolvimento, é preciso que haja uma concordância em relação a como o sistema deve se comportarentre todos os envolvidos (stakeholders) como patrocinadores. 
É preciso, para que a validação do requisito possa ocorrer, que várias visões de um mesmo requisito sejam elaboradas, iniciando-se pela especificação em linguagem natural, que se converterá em diagramas de casos de uso, para traduzir, visualmente, as interações entre os diferentes papéis na aplicação e as funcionalidades por ela providas. 
Um diagrama de caso de uso apresentará, segundo Larman (2000), de forma visual e clara, todas as interações entre um determinado ator (usuário final, por exemplo) e as funções por ele usadas, conforme apresentado na Figura 2. 
Fonte: elaborada pela autora.
A Figura 2 apresenta um exemplo de diagrama de caso de uso para uma aplicação de cadastro de alunos. Neste caso, o ator (usuário do RH) poderá executar as funções de cadastrar aluno, alterar cadastro de aluno e desativar cadastro de aluno. Para outros atores, outras funcionalidades podem ser associadas, deixando claro para os stakeholders envolvidos quais papéis de usuário poderão fazer que tipo de ação no sistema. 
Um caso de uso possui alguns elementos visuais básicos para sua construção: 
· Ator: usuário ou sistema que realizará uma funcionalidade na aplicação. 
· Casos de uso: ações que representarão os requisitos funcionais e que serão executadas pelo ator. 
· Relacionamentos: setas que indicam o fluxo de quem executará qual ação. Poderão representar uma resposta (quando o sistema fornece um retorno para o ator ou outra funcionalidade) ou uma requisição (quando o ator executa alguma ação). 
Um ator pode ser também um outro sistema ou módulo, que possua algum tipo de interação com a aplicação que será construída. Um bom exemplo é a integração entre diferentes sistemas, em uma mesma organização, para compartilhamento de informações e/ou utilização de APIs, tanto para realização de consultas como cadastros de dados. 
Após a construção de todos os casos de uso, mapeando a interação entre os diferentes atores e as funcionalidades providas pela aplicação, será necessário detalhar os casos de uso mapeados, ou seja, especificar os fluxos do caso de uso, seja um fluxo principal (entradas e respostas esperadas) ou fluxos alternativos (entradas faltantes, com caracteres não permitidos, sequência de comandos inadequada etc.). 
Os fluxos alternativos servirão como critérios de validação da correta implementação do caso de uso, da mesma forma que acontece com o fluxo principal. Caso algum problema seja encontrado pela equipe que está realizando os testes na funcionalidade, o fluxo no qual o desvio de comportamento foi notado será apontado para que a equipe de desenvolvimento possa realizar as devidas correções. 
Além dos diagramas de casos de uso, outros diagramas UML podem ser utilizados para dar mais clareza aos interessados, em termos de entendimento das funcionalidades especificadas, como os diagramas de sequência.  
Saiba mais
Uma boa ferramenta gratuita para gerenciamento de requisitos e acompanhamento do trabalho do time de desenvolvimento é a Trello ou a Ummense. 
Para criar seus diagramas de caso de uso gratuitamente, você poderá utilizar a Yuml, a Ceately ou a Visual Paradigm.
Referências
LARMAN, C. Utilizando UML e Padrões: uma introdução à análise e ao projeto orientado a objetos. Porto Alegre, RS: Bookman, 2000.  
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. 9. ed. Nova Iorque: Mc Graw Hill Education, 2021.  
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011
Introdução
Olá, estudante! 
Nesta aula, você aprenderá quais são os artefatos gerados no processo de levantamento de requisitos, além da forma como o levantamento de requisitos acontece com metodologias ágeis e quais artefatos são construídos e mantidos com estas metodologias. Abordaremos também os requisitos voltados para sistemas autoadaptativos, voltados para sistemas que podem alterar seu comportamento em tempo de execução, conforme sua necessidade, refletida pelo ambiente no qual estão inseridos, sem nenhuma intervenção humana. 
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! 
Artefatos do levantamento de requisitos
Artefatos são produtos gerados como resultados de uma fase (ou processo). Quando nos referimos à fase da especificação de requisitos, os artefatos gerados são elaborados como resultado das entrevistas com o cliente, para levantamento das funcionalidades da aplicação que será desenvolvida, assim como do refinamento destes requisitos e das eventuais mudanças que, eventualmente, podem ocorrer nos requisitos já especificados. 
O documento de especificação de requisitos é tido como o principal documento que conterá os requisitos (funcionais e não funcionais) necessários para que a equipe de desenvolvimento possa construir a aplicação. Este documento precisa ser criado e mantido, com as devidas atualizações, ao longo de todo projeto, tendo em vista que é por ele que os desenvolvedores se basearão e, em caso de dúvidas em regras de negócio, consultar. 
Ainda neste documento, é importante constar os diagramas que foram construídos para as diferentes visões dos requisitos, facilitando o processo de validação pelo cliente (e demais partes interessadas). Então, diagramas de caso de uso e diagramas de sequência podem fazer parte do texto que precede os requisitos especificados. 
A Figura 1 apresenta um exemplo de um diagrama de sequência para o cadastro de um paciente no sistema. 
Fonte: elaborada pela autora.
Conforme apresentado na Figura 1, o ator usuário interagirá com a tela de cadastro de pacientes para que um paciente seja inserido no banco de dados da aplicação. O objetivo deste diagrama é apresentar uma sequência de passos que serão executados e/ou retornados pelo/ao cliente. O cliente, então, iniciará a interação com o sistema a partir do preenchimento dos dados da tela do cadastro de paciente que terão os dados validados (ou não) pela classe paciente. Caso os dados não sejam validados corretamente, seguindo as regras de negócio, mensagens de dados inválidos ou paciente já cadastrado poderão ser retornadas ao ator (usuário), interrompendo o fluxo. Se o processo de validação for concluído com sucesso, então os dados serão inseridos no banco de dados e uma mensagem de paciente cadastrado com sucesso será retornada ao usuário que criou a requisição. 
Os diagramas de caso de uso apresentarão as interações entre os atores e as funcionalidades do sistema, enquanto os diagramas de sequência apresentarão a sequência de passos para uma determinada funcionalidade, desde a criação da requisição pelo usuário final até a resposta entregue pelo sistema, após o processamento da requisição, numerando a ordem dos passos. 
Outro artefato importante são as requisições de mudança, geradas sempre que um requisito já especificado precisa sofrer alterações (apenas para se adequar à necessidade do usuário final) ou quando uma nova funcionalidade será implementada no sistema (caracterizando a manutenção evolutiva). 
Quando se utiliza a prototipação como ferramenta auxiliar para validação das funcionalidades pelo cliente, os protótipos construídos também são considerados artefatos de saída desta fase, já que serão repassados à equipe de desenvolvimento para que o design já acordado para o sistema possa ser mantido. 
A Figura 2 apresenta um exemplo de diagrama de caso de uso para o cenário apresentado na Figura 1.
Fonte: elaborada pela autora.
Conforme apresentado na Figura 2, a visão do caso de uso tende a ser mais macro que a visão apresentada no diagrama de sequência, que detalhará, para cada item de caso de uso, os passos necessários para executar a ação. Sendo assim, o diagrama de caso de uso visa apresentar, de forma resumida, todas as interações possíveis de um ator no sistema.  
Outro ponto importante, que também gera um artefato da fase de especificação de requisitos, é o documento contendo o glossário dos termos do negócio, queserão aplicados ao longo da construção do sistema. Muitas vezes, um mesmo termo pode ter diferentes significados, dependendo do contexto no qual é utilizado. O glossário servirá como nivelamento para que todos, independentemente de qual setor pertençam, possam ter o mesmo entendimento a respeito dos conceitos utilizados pelo negócio. 
Após o acordo a respeito do design do sistema e dos demais documentos já mencionados, é importante que você especifique o modelo de arquitetura que servirá de base para a construção do sistema, com os elementos de rede que serão utilizados, suas interconexões, a conexão com outros sistemas (caso ocorra), entre outros pontos importantes para que, tanto os componentes de hardware sejam visíveis quanto, em termos de sistema, a disposição das camadas da aplicação e suas respectivas classes possam ser especificadas. O modelo de arquitetura de classes do sistema servirá como base para a equipe de desenvolvimento, enquanto o modelo de arquitetura de hardware poderá ser apresentado e validado pelos stakeholders.
Levantamento ágil de requisitos
As metodologias ágeis de desenvolvimento têm por objetivo simplificar o processo de construção de software, de modo a atender de forma efetiva às necessidades do cliente. Isso é possível devido às constantes entregas parciais do produto, o que faz com que o cliente dê feedbacks constantes e não precise esperar tanto tempo (meses até) para utilizar o produto, uma vez que as partes entregues já podem ser implantadas em produção e já podem ser utilizadas pelo usuário final. 
Conforme Beck et al. (2001), é mais importante uma aplicação em funcionamento que manter uma documentação abrangente e detalhada, o que implica a necessidade de simplificar o processo de documentação da aplicação somente ao essencial. Comentários de código e o documento contendo as histórias ou estórias (fica a cargo do time escolher a melhor denominação) de usuário serão, talvez, as únicas documentações disponíveis em um projeto que seja construído através destas metodologias. 
Diferente do processo tradicional, no qual todos os requisitos (funcionais e não funcionais) precisam ser especificados antes do início do processo de codificação, com a metodologia ágil é possível especificar apenas um conjunto de requisitos logo no começo, tidos como os mais importantes para o negócio e para a necessidade dos patrocinadores, porém essa lista pode crescer ao longo do andamento do projeto. 
Para times que utilizam o framework SCRUM, um dos mais adotados pelas equipes de desenvolvimento na atualidade para desenvolvimento de projetos ágeis, os requisitos podem ter níveis de especificação e detalhamento diferentes, conforme apresenta Schwaber e Sutherland (2013), a depender da fase na qual eles se encontram: 
· Backlog do produto: nesta fase, os requisitos estão especificados em sua forma macro, sem nenhum tipo de detalhamento, ainda não se encontrando prontos para que a equipe de desenvolvimento possa codificá-los. Antes do início do projeto, os requisitos levantados se encontram nesse estágio, podendo ser inseridos novos requisitos à medida que se dá o andamento do projeto. 
· Backlog da sprint: nesta fase, um conjunto de requisitos macro, retirados do conjunto que compõe o backlog do produto, serão refinados junto ao cliente e, após todos os detalhes de suas regras de negócio, serão julgados pela equipe de desenvolvedores, conforme suas experiências passadas e o tempo disponível para o próximo ciclo de desenvolvimento (sprint), que definirão quais tarefas serão entregues ao final da próxima sprint. Tudo que tiver definido como compondo o conjunto do backlog da sprint deverá ser entregue ao cliente para homologação ao final do ciclo. 
O refinamento de um requisito retirado do conjunto do backlog do produto é feito através de um documento denominado história (ou estória) de usuário, que deverá conter todas as regras de negócio envolvidas na implementação do requisito, os papéis que utilizarão a funcionalidade, assim como as regras de validação (chamadas de critérios de aceitação). 
É importante que um membro da equipe de desenvolvimento esteja com sólidos conhecimentos do negócio e tenha contato direto com o cliente, sendo sua “voz” dentro da equipe, sanando qualquer dúvida que, eventualmente, os desenvolvedores possam ter acerca dos detalhes de implementação do requisito. Este papel, dentro de uma equipe ágil, é denominado product owner (ou dono do produto). Deverá ser a primeira pessoa a quem os desenvolvedores deverão recorrer em caso de dúvidas. Caso este não saiba ou precise esclarecer algo sobre o negócio com o cliente, de forma direta, então somente esta pessoa realizará este contato. 
Requisitos autoadaptativos
Conforme Batista (2022), aplicações autoadaptáveis são aquelas capazes de moldar seu comportamento, alterando-o conforme necessário, para se adequar ao meio que está inserido. Sendo assim, é possível realizar avaliações que, como resultado, podem acarretar melhoria de desempenho da aplicação ou até modificar um comportamento tido como errado (ou que estejam causando falhas), sem que ocorra intervenção humana para esta adaptação. 
O intuito pelo qual existem aplicações autoadaptáveis é a necessidade de se gerenciar aplicações complexas, necessidade de tratamento de condições inesperadas e, inclusive, a incerteza acerca dos requisitos da aplicação. 
Aplicações com as características de adaptação possuem propriedades, dentro de conjuntos bem definidos e conhecidos, caracterizadas por self-*. Cada categoria de propriedade self-* definirá um tipo de comportamento adaptável, como apresenta Batista (2022): 
· Autoconfiguração: capacidade de responder a mudanças através da autoconfiguração, podendo instalar, atualizar, integrar, compor e decompor entidades de software. 
· Autocura: capacidade de se recuperar de interrupções, podendo, inclusive, se antecipar a problemas, tomando as medidas necessárias para evitar uma falha. 
· Auto-otimização: capacidade de gerenciamento de desempenho e alocação de recursos, satisfazendo os requisitos não funcionais dos diversos stakeholders da aplicação. 
· Autoproteção: capacidade de detectar problemas com segurança e se recuperar de possíveis falhas. Tanto pode defender a aplicação contra-ataques maliciosos como pode mitigar os efeitos de um ataque e tomar as precauções necessárias para proteção. 
Requisitos autoadaptáveis, por comporem aplicações que podem ajustar seu comportamento em tempo de execução, conforme as diversas variáveis que são analisadas, passam a ser analisadas em tempo de execução. 
Quando nos referimos ao processo de levantamento de requisitos para aplicações autoadaptáveis, é importante mencionar o nível de incerteza destes requisitos, o que torna o processo de elucidação das funcionalidades parcialmente incompleto. Em uma aplicação tradicional, sem a característica de adaptação, as funcionalidades precisam ser mapeadas logo no princípio do projeto, com um alto grau de certeza, ou seja, para cada requisição de entrada, uma resposta esperada já é conhecida ainda na fase de especificação. 
Uma forma apresentada por Batista (2022) para a elucidação de requisitos para aplicações autoadaptáveis é a utilização do método de perguntas para os requisitos essenciais de autoadaptação: 
· Onde: perguntas relacionadas com pontos onde ocorrem a necessidade de mudança. O que será alterado e em qual camada? Auxilia na localização do problema a ser resolvido com a adaptação. 
· Quando: perguntas relacionadas ao tempo no qual adaptações precisam ocorrer, como a decisão de quando uma mudança será possível ser realizada, se existe algum momento específico para aplicação, conforme necessidade do sistema, e qual a frequência de alteração. 
· O quê: definem quais atributos ou artefatos do sistema serão alterados por conta da adaptação. 
· Por quê: apresenta a motivação para a construção do sistema adaptativo. 
· Quem: definem o nível de integração humana e automação da aplicação. 
· Como: define como os requisitos adaptáveis serão configuradose quais as condições mais adequadas para a adaptação.  
· Saiba mais
· 
· O guia para o SCRUM foi atualizado em 2020. Para conferir as atualizações e conhecer mais sobre o framework ágil SCRUM, acesse O Guia Definitivo para o Scrum: As Regras do Jogo
· Uma ferramenta gratuita para auxiliar na escrita de histórias de usuário é a Miro. Você poderá também contar com a ferramenta Trello, gratuita, para a escrita das histórias de usuário e o acompanhamento do progresso do time de desenvolvimento.
· Referências
· 
· BATISTA, A. P. Decomposição de requisitos de confiabilidade para sistemas autodaptativos utilizando o NFR framework. 2022. Trabalho de Conclusão de Curso (Graduação em Engenharia de Software) – Universidade Federal do Ceará, Quixadá, 2022. Disponível em: https://repositorio.ufc.br/bitstream/riufc/65416/1/2021_tcc_apbatista.pdf. Acesso em: 6 jun. 2022.  
· BECK, K. et al. Manifesto para desenvolvimento ágil de software. [S. l.]: [s. n.], 2001. Disponível em: https://agilemanifesto.org/iso/ptbr/manifesto.html. Acesso em: 6 jun. 2022. 
· SCHWABER, K.; SUTHERLAND, J. Um guia definitivo para o SCRUM: as regras do jogo. Scrum, 2013. Disponível em: https://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf. Acesso em: 6 jun. 2022.
Analisar e ser capaz de classificar os principais tipos de requisitos de software
Nesta unidade, você aprendeu que a fase de especificação de requisitos é considerada a mais importante para o processo de desenvolvimento de uma nova aplicação. É nesta fase, a partir das entrevistas feitas com o cliente, que as funcionalidades da aplicação serão levantadas em sua forma inicial. 
Após a necessidade das partes interessadas no produto (stakeholders) ser mapeada em requisitos funcionais (que representam as ações que, de fato, o sistema proverá) e não funcionais (que representam as necessidades secundárias, como segurança, autenticação, auditorias etc.), o documento de especificação de requisitos será criado e repassado para a equipe de desenvolvedores, que dará início à fase de codificação da aplicação. 
Ao longo do ciclo de vida do projeto, é possível que os requisitos mapeados, inicialmente, sofram alterações, que deverão ser refletidas no documento de especificação de requisitos, mantendo-o sempre atualizado. Essas alterações podem surgir oriundas da percepção do cliente que alguma regra importante faltou ou está incompleta, até mesmo após a validação dos artefatos gerados como resultado da fase de levantamento de requisitos. 
Artefatos são os produtos gerados como resultado de uma fase, que servirão de subsídios para a próxima fase do projeto. Para a fase da especificação de requisitos, os artefatos resultantes mais comuns são: 
· Documento de especificação de requisitos: contendo o mapeamento de todos os requisitos do sistema, sejam funcionais ou não funcionais. 
· Diagramas de caso de uso ou outros tipos de diagramas UML: por serem um recurso visual, é comum que diagramas UML sejam criados, como os de caso de uso (que apresentarão a relação entre os atores do sistema e os requisitos por eles utilizados) e diagramas de sequência (que apresentarão o fluxo de uma funcionalidade, desde a interação inicial do usuário até a resposta retornada). 
· Protótipos das telas do sistema: mostrarão ao cliente uma prévia de como o sistema se apresentará visualmente, com disposição de campos na tela, esquema de cores, estilização e demais recursos visuais. 
Durante o processo de levantamento de requisitos, é importante que o cliente indique quais as funcionalidades que agregarão maior valor ao produto, conforme suas expectativas. Dessa forma, é feita a priorização dos requisitos, que pode ser alterado ao longo do andamento do projeto. Caso o produto tenha muitos interessados e, consequentemente, conflito de interesses naquilo que deverá ser prioridade, é importante a utilização de técnicas de priorização, com a finalidade de se chegar a um consenso de benefício comum. 
Com o advento das metodologias ágeis, principalmente do framework SCRUM, o processo de desenvolvimento foi otimizado para que o cliente pudesse estar mais próximo ao produto, fornecendo feedbacks constantes e validando as entregas com suas reais necessidades. Um ponto que ficou enxuto com o SCRUM foram os artefatos resultantes da fase de levantamento de requisitos. O documento de especificação de requisitos, complexo e demorado de ser elaborado, foi substituído pelas histórias de usuário, mais simples e rápido de ser escrito. 
Você também aprendeu sobre os requisitos voltados para aplicações autoadaptáveis, que são especificados de forma incompleta, tendo em vista a incerteza da aplicação, que, em tempo de execução, pode alterar seu comportamento de acordo com análises do ambiente ou interações do usuário.
Resumo visual
Fonte: elaborada pela autora.Fonte: elaborada pela autora.
Referências
AGUIAR, F. Product Backlog Building: um guia prático para criação e refinamento de backlog para produtos de sucesso. Porto Alegre, RS: Caroli, 2021.    
PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. 9. ed. São Paulo, SP: AMGH, 2021