Prévia do material em texto
Inserir Título Aqui Inserir Título Aqui Engenharia de Requisitos Análise e Gestão de Requisitos Responsável pelo Conteúdo: Prof. Me. Afonso Maria Luiz Rodrigues Pavão Revisão Textual: Prof.ª Me. Sandra Regina F. Moreira Nesta unidade, trabalharemos os seguintes tópicos: • Análise de Requisito; • Verificação de Requisitos; • Validação de requisitos; • Gestão de Requisitos; • Gerência de Escopo. Fonte: iStock/Getty Im ages Objetivos • Compreender as etapas necessárias para a determinação de requisitos de software com qualidade. Caro Aluno(a)! Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o último momento o acesso ao estudo, o que implicará o não aprofundamento no material trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas. Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns dias e determinar como o seu “momento do estudo”. No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões de materiais complementares, elementos didáticos que ampliarão sua interpretação e auxiliarão o pleno entendimento dos temas abordados. Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e aprendizagem. Bons Estudos! Análise e Gestão de Requisitos UNIDADE Análise e Gestão de Requisitos Contextualização Para iniciarmos os estudos sobre a gestão de requisitos, quero propor-lhe uma reflexão sobre as falhas e erros que você já viu (ou ouviu) acontecerem. A partir desta reflexão, convido você a analisar quantas ações poderiam ter sido executadas de modo a evitar que ocorressem as falhas e os prejuízos identificados. E não apenas quanto à coleta de requisitos, como também relativas a seus controles e gerenciamento. Observe quanto desperdício ocorre no processo de desenvolvimento de um software, mesmo com a utilização de técnicas consagradas ou identificadas como as melhores práticas, e com a aplicação de ferramentas de controle e de gestão de requisitos. Acesse os sites e assista aos vídeos que sugerimos no item “material complementar” e tome conhecimento de alguns s disponíveis no mercado que colaboram com a gestão de requisitos (indicados nesse mesmo item). A área de tecnologia de informação vem tentando trazer valor agregado aos negócios, mas ainda hoje, uma “simples” modificação em um requisito, ou um requisito mal compreendido, ganha tamanha relevância e gera inúmeros prejuízos a uma empresa. É tempo mais que suficiente para buscarmos reverter esta situação. 6 7 Análise de Requisitos A análise de requisitos é fundamental para o processo de desenvolvimento de siste- mas porque visa descobrir as necessidades do usuário e identificar as operações que o sistema deverá realizar, além das restrições destas operações. Após a obtenção (ou elicitação) dos requisitos, é necessário que seja feita sua análise para averiguação da coleta de dados e atualizar-se sua documentação. Alguns autores consideram a análise de requisitos como sendo o processo de des- cobrir, analisar, documentar e verificar serviços requeridos para um sistema e suas restrições operacionais. Sommerville (2011) afirma que engenheiros de software, clientes, usuários finais e demais envolvidos (stakeholders) devem entender com exatidão os requisitos sobre: • O domínio da aplicação; • Quais serviços e funcionalidades o sistema deve fornecer; • O desempenho esperado; e • As restrições de hardware, do ambiente e do negócio. Como se sabe, muitas dificuldades surgem durante a coleta de dados, e as origens são diversas: • Stakeholders não sabem ou não expressam o que querem do sistema; • Stakeholders expressam requisitos usando seus próprios termos (domínio); • Diferentes stakeholders têm diferentes requisitos; • Fatores políticos podem influenciar (ex.: mais poder a um gerente); • Ambiente é dinâmico e muda frequentemente; e • Novos requisitos podem surgir de novos stakeholders. Entende-se que a engenharia de requisitos deva ser um processo interativo, cíclico e que envolve as seguintes atividades: • Obtenção de requisitos (coleta de dados); • Classificação e organização de requisitos; • Priorização e negociação de requisitos; e • Documentação de requisitos. A análise de requisitos tem como pressuposto básico identificar: • Problemas, inconsistência ou requisitos incompletos; • Descobrir interações entre os requisitos; e • Apresentar e informar conflitos e sobreposições. 7 UNIDADE Análise e Gestão de Requisitos Um aspecto importante é verificar se realmente aquele requisito é necessário, pois em alguns casos, alguns requisitos podem não contribuir com os objetivos de negócio da organização, ou para o problema específico que será tratado pelo sistema. Também se deve verificar se, apesar de válido, é viável manter aquele requisito. Isto visa garantir sua permanência (ou não) conforme tecnologia, orçamento e tempo disponível para o desenvolvimento do sistema. Os requisitos também devem ser verificados entre si para se identificar sua consis- tência, e se contêm todos os elementos necessários e, portanto, se sua integralidade está garantida. A consistência significa que os requisitos não podem ser contraditórios entre si. Ou seja, se uma informação não fica invalidada por qualquer motivo, ou ainda, por outra informação, de outro stakeholder, por exemplo. Quanto à completude, a análise de requisito visa identificar se nenhum serviço (ou restrição) está incompleto ou foi esquecido ao longo do tempo. Caso sejam identificadas, as divergências devem retornar aos stakeholders para esclarecimentos e solução (chamada também de negociação). A atividade de análise de requisitos deve ser normalmente praticada simultaneamente com sua obtenção. A figura abaixo ilustra esse processo. Análise de Requisitos Checagem da Necessidade Checagem de Viabilidade Requisitos Inviáveis Requisitos Desnecessários Discussão de Requisitos Priorização de Requisitos Acordo de Requisitos Requisitos Incompletos e Con�itantes Checagem de Consistência e Completude Negociação de Requisitos Figura 1 – Análise e Negociação de Requisitos Note que, na prática, a “negociação” – termo utilizado para designar se o(s) requisitos(s) deverá(ão) ou não permanecer no projeto de software – é com frequência aplicada, pois questões técnicas ou comportamentais estarão sempre envolvidas. 8 9 Independente disto, pode-se preparar uma lista de verificação para ser usada na análi- se dos requisitos. A partir dessa lista, e não necessariamente com ela, é possível identifi- car se todo conhecimento acumulado na pesquisa está correto, completo ou consistente, conforme se vê na sequência. Busca-se verificar se: • O projeto é prematuro, ou seja, se os requisitos têm informação imatura para o projeto ou para a implementação; • Há requisitos combinados: se a descrição do requisito é única, ou o mesmo pode ser desmembrado em mais requisitos; • Os requisitos são realmente e, de fato, necessários; • Será necessário o uso de hardware não padronizado – e os requisitos implicam em algum hardware diferenciado. Essa decisão pode exigir outro tipo de conhecimento; • Os requisitos estão em conformidade, ou estão consistentes com os objetivos de negócio; • Há ambiguidade nos requisitos, ou se o mesmo o requisito pode ter interpretação diferente por diferentes pessoas – stakeholders ou usuários. • Os requisitos são realísticos com a tecnologia disponível, e se esta é adequada para a implementação daquele requisito. • Os requisitos foram escritos de forma a poderem ser testados para determinar se o sistema irá satisfazê-los. Em outras palavras, a nível macro os revisoresdevem garantir que a especificação esteja completa, consistente e precisa. Então deve ser questionado se: • As metas e objetivos do software são consistentes e coerentes com as metas e os objetivos da empresa; • O fluxo e a estrutura de informação estão adequadamente definidos para o domínio da informação necessária; • A modelagem, em casos de uso ou em outra representação, está clara; • Todas as interfaces importantes foram adequadamente descritas para todos os elementos do sistema; • As funções consideradas essenciais e importantes ainda permanecem no escopo; • Essas funções foram escritas adequada e corretamente; • O comportamento esperado do software está consistente com os dados a serem processados e as funções que o mesmo deve executar; • As restrições encontradas e definidas para o projeto são realistas; • Há – e, se houver, qual é o risco tecnológico para o desenvolvimento do software; • Os requisitos de software alternativos foram considerados até serem esgotadas todas as possibilidades; • Os critérios de validação foram declarados detalhadamente; 9 UNIDADE Análise e Gestão de Requisitos • Esses critérios são adequados para descrever um sistema bem sucedido; • Existem inconsistências, omissões ou redundâncias; • As estimativas do plano de projeto de software foram afetadas, e como foram. Já no nível detalhado, os revisores devem se preocupar com o enunciado da especi- ficação. Esta etapa deve descobrir problemas que podem estar ocultos na especificação. Suas diretrizes devem ser para: • Estar alerta para perceber conectivos persuasivos (certamente, claramente, obvia- mente) e perguntar por que eles estão presentes; • Procurar termos vagos e pedir esclarecimento (algum, às vezes, usualmente, frequentemente); • Evitar o uso de “etc.”, “tal como” ou “assim por diante”, quando houver listas que não estejam completas; • Ter certeza de que limites declarados não contenham pressuposições não declaradas do tipo “os códigos válidos variam de 0 a 100” - números inteiros ou reais; • Evitar verbos vagos, pois há muitas formas de interpretá-los: manuseado, rejeitado, pulado; • Evitar pronomes “pendentes” ou dúbios, como por exemplo: o módulo I/O se comunica com o de validação de dados e seu sinal de controle está ligado (qual módulo?); • Procurar declarações que impliquem certeza (sempre, cada, todos, nunca) e depois queira-se prova disto; • Evitar usar outros conceitos para um mesmo termo, ou seja, se um termo for de- finido num lugar, deve-se evitar usar outro que possa ter o mesmo sentido, como documento ou arquivo; • Verificar se há gráficos ou figuras que possam auxiliar a compreensão caso uma estrutura descrita em palavras não seja suficiente para seu entendimento; • Elaborar ao menos dois exemplos com algoritmos, caso seja especificado um cálculo. A análise de requisitos deverá evitar os tão conhecidos erros de projeto. Sua impor- tância alcança até o gerenciamento de projetos, pois na engenharia de requisitos ela (a análise) é a responsável por obter os dados indispensáveis para solucionar os problemas dos usuários e ajudá-los a alcançar seus objetivos. Para o IEEE (1990), a análise de requisitos é o processo que estuda as necessidades do usuário para validar o produto final, estabelecendo o elo final de ligação entre o cliente e o fornecedor do software. É ela que vai determinar o sucesso ou o fracasso do projeto, já que a comunicação e o envolvimento constante com os usuários irão influen- ciar no resultado final do produto. 10 11 Verificação de Requisitos A equipe de interessados e envolvidos no projeto de software lê, analisa os requisitos e procura problemas, erros, omissões, incongruências, falhas ou situações descritas que não estejam de acordo com o escopo do projeto, se reúne, discute estas situações, negocia e concorda com as ações para tratá-las. As atividades de obtenção, análise, verificação e validação de requisitos estão intima- mente ligadas. Por isso alguns autores tratam desses conceitos de forma simultânea, e consideram que a revisão contem as atividades de análise, de verificação e de validação. Para Pfleeger (2004), a revisão de requisitos deve: • Rever metas e objetivos estabelecidos para o sistema; • Descrever o ambiente operacional; • Examinar: » interfaces » fluxo de informações » funções • Comparar requisitos, metas e objetivos; • Verificar omissões, imperfeições e inconsistências; • Documentar riscos; e • Discutir sobre como o sistema será testado. Para a verificação, as seguintes atividades devem ser executadas: • Planejar a revisão, selecionando a equipe, a hora e o local para sua ocorrência; • Distribuir os documentos de requisitos para todos os membros participantes; • Os revisores devem preparar-se para a revisão, lendo os requisitos e assinalando suas dúvidas e suas observações sobre conflitos, omissões, inconsistências, desvios, e todo questionamento que se queira esclarecer; • Realizar a reunião de forma que todas as dúvidas individuais sejam discutidas e que seja gerada concordância para o conjunto de ações que irá tratá-las; • Ações para acompanhamento das revisões sugeridas, de forma que seu respon- sável possa verificar se estas foram executadas conforme todas as ações que foram acordadas; • Revisar o documento de requisitos para refletir as ações acordadas, podendo ou não ocorrer nova revisão. 11 UNIDADE Análise e Gestão de Requisitos A coordenação do projeto deve convocar para a(s) reunião(ões) os colaboradores e envolvidos de forma que: • Dentre os revisores se incluam stakeholders com backgrounds diferentes, porque seus conhecimentos e habilidades contribuem para a revisão; • A participação dos stakeholders que se envolvem no processo possa ajudar no entendimento das necessidades de outros stakeholders; • Existam no time de revisores ao menos um especialista no domínio e um usuário final independente. Os critérios mais adequados para a atividade de revisão devem exigir que nos requisitos sejam verificadas a existência de: • Ambiguidade • Completude • Conformidade a padrões • Consistência • Entendimento • Organização • Rastreamento • Redundância Isto é importante porque, por mais cuidado que os desenvolvedores tenham com as especificações dos requisitos, não há garantias de que estas estejam completas e corretas. Além disso, elas pode ser por eles revistas diversas vezes e não se identificar falha alguma. Principalmente por esse motivo, é que as especificações devem ser revisadas por outras pessoas – inclusive por aquelas não envolvidas no projeto, para maior isenção em sua opinião. Validação de Requisitos Quanto à validação de requisitos, seus objetivos devem ser para certificar-se de que o documento de requisitos é uma descrição correta e aceitável do sistema a ser desenvol- vido, verificando-se suas propriedades. Estudo da viabilidade Relatório de viabilidade Modelos de sistema Requisitos de usuários e de sistema Elicitação e análise de requisitos Especi�cação de requisitos Validação de requisitos Documentação de requisitos Figura 2 – Validação de Requisitos 12 13 Observe a figura 2 e note que a análise de viabilidade também está incluída no ciclo de validação. Note que também na figura 1 a análise de viabilidade é citada. A verificação de requisitos, assim como sua validação, envolvem antes uma profunda análise de seu teor, e apesar de alguns autores colocarem a verificação e a validação num mesmo patamar, resolvemos separá-las, pois entendemos que validar é mais importante que verificar, conforme explicamos na sequência com o que identificamos em alguns dicionários eletrônicos disponíveis. A verificação é, de acordo com “Aurélio”, o ato ou efeito de verificar, averiguação, enquanto que para “Michaelis”, é a realização de algo previsto. O dicionário de “Sinônimos” caracteriza verificação como sendo uma averiguação, investigação, ou uma apuração, e o outro dicionário – o “Dicio”, define que verificação,trata de averiguação ou comprovação. A validação, por sua vez, para “Aurélio”, é tornar ou declarar algo válido, e para “Michaelis” é uma declaração de validade. O “Sinônimos” conceitua validação como sendo aceitação, aprovação ou confirmação, e o “Dicio” a caracteriza como aceitação, aprovação, confirmação, ou tornar algo válido. A verificação usa dados obtidos dos stakeholders do sistema e sua questão básica é saber se a equipe tem os requisitos certos. A validação usa uma versão menos informal e mais final do documento de requisitos que foram negociados e acordados e, nesta fase, a questão chave é saber se os requisitos disponíveis estão certos. Para a validação dos requisitos são utilizados: • O documento oficial de requisitos, que deve estar na sua versão completa, formatada e organizada conforme os padrões da instalação; • O conhecimento organizacional, que é o conhecimento frequentemente implícito, da organização, e que poderá ser usado para julgar o realismo dos requisitos; e • Os padrões organizacionais, usados para organizar oficialmente o documento de requisitos. Igualmente, na verificação, são gerados alguns artefatos: • A lista de problemas, com a relação dos problemas descobertos no documento de requisitos; e • As ações acordadas, que é uma lista de ações que ficaram acertadas em resposta aos problemas detectados. Alguns destes problemas podem gerar várias ações corretivas, e outros podem não ter qualquer ação associada. As atividades devem ainda ser para a: • Verificação de validade; • Verificação de consistência; 13 UNIDADE Análise e Gestão de Requisitos • Verificação de clareza; • Verificação de realismo; e • Facilidade de verificação. Por outro lado, as validações podem ser feitas por meio de técnicas, tais como: • Geração de casos de teste, com testes específicos, análise de consistência automática ou avaliar apenas uma especificação; • Prototipação, incluindo um modelo “executável” (ou interfaces) do sistema; • Revisão de requisitos, com a análise manual sendo sistemática; • Reusando domínios já conhecidos e efetivos; • Usando o princípio de “pontos de vista” de stakeholders; ou • Validação mediante o uso de outros modelos. Para Vazquez (2016), as validações podem ser feitas mediante a utilização de: • Casos dos usuários; • Modelagem de processos; • Decomposição funcional; • Modelagem de domínio; • Modelagem dos Casos de Uso; • Listas de verificação; ou • Prototipação. Outra técnica usada durante as revisões técnicas formais – RTF – é o checklist e visa garantir a qualidade do software mediante: • A descoberta de erros de função, lógica ou codificação; • A verificação de que o software atende aos requisitos especificados; • A garantia de que o software foi representado conforme padrões previamente definidos; • A garantia de que o software foi desenvolvido uniformemente; e • O desenvolvimento de projetos mais facilmente gerenciáveis. A etapa de validação pode ocorrer em momentos específicos durante o desenvolvi- mento e apoia-se no conhecimento dos avaliadores naquele momento. Durante a engenharia de requisitos, os stakeholders adquirem novos conhecimentos sobre o sistema em projeto, sendo exímios colaboradores nessa etapa. Mas não significa, de fato, que uma validação positiva de requisitos garanta que os mesmos continuarão sendo válidos posteriormente. 14 15 Entendemos que a validação de requisitos poderia ser feita diversas vezes se: • No projeto houver muitas ideias e tecnologias inovadoras; • Durante a fase de engenharia de requisitos houver acréscimo significativo no conhe- cimento dos envolvidos; • O projeto tiver longa duração; • A validação de requisitos anterior foi realizada muito cedo; • O domínio do problema seja desconhecido; e • Houver a reutilização de requisitos. Portanto, a validação de requisitos visa demonstrar que eles definem o sistema que realmente o cliente deseja, e que estão conforme foi definido. Vale lembrar novamente que, os custos resultantes de erros em requisitos são muito altos, o que torna sua validação muito importante. Estimam-se que o custo da reparação de um erro após a entrega de um software pode chegar a cem vezes mais que o custo de reparação de um erro na fase de implementação. Gestão de Requisitos A gestão de requisitos refere-se a um processo de gerenciamento de suas mudanças durante o processo de engenharia de requisitos e o desenvolvimento de sistema. Os requisitos de um software inevitavelmente são incompletos e inconsistentes pois novos requisitos surgem: • Durante o processo de sua elicitação; • À medida que as necessidades de negócio mudam; • Conforme é desenvolvida uma melhor compreensão do projeto; • Quando os diferentes pontos de vista têm requisitos diferentes e estes são contraditórios. A partir daí, é necessário de seja feita uma boa gestão de mudanças de requisitos, pois: • A priorização dos requisitos muda em decorrência das mudanças de pontos de vista durante o processo de desenvolvimento; • O ambiente técnico e o de negócio do sistema mudam durante o desenvolvimento; • Os clientes do sistema podem especificar requisitos a partir de perspectiva de negócio que conflite com os requisitos do usuário final. 15 UNIDADE Análise e Gestão de Requisitos Devido a esses principais motivos, a utilização de um processo formal para a gestão de mudanças deve garantir que todas as propostas de alterações de requisitos sejam tratadas consistentemente, e que as alterações no documento de requisitos sejam controladas. Analogamente, deve permitir também a análise do impacto dessas mudanças. São três os estágios do processo de gerenciamento de requisitos: • Fazer-se a análise do problema e a especificação da mudança; • Efetuar a análise da mudança e a estimativa do custo para realizá-la; • Executar a implementação da mudança. A figura 3 apresenta a amplitude da engenharia de requisitos e a figura 4, da gestão de requisitos. Produção de Requisitos • Levantamento • Registro • Validação • Veri�cação • Controle de Mudanças • Gerência de Con�guração • Rastreabilidade • Gerência da Qualidade de Requisitos Gerência de Requisitos Engenharia de Requisitos Figura 3 – Engenharia de Requisitos Ge re nc ia m en to do s R eq ui sit os Elicitação dos Requisitos Veri cação dos Requisitos Validação dos Requisitos Análise e Negociação dos Requisitos Documentação dos Requisitos Figura 4 – Gestão de Requisitos 16 17 A figura 4 apresenta claramente que, na prática, a gestão de requisitos é um processo cíclico e ininterrupto, que se inicia já na fase de obtenção de dados. Uma mudança em requisitos pode implicar em alterações em um ou mais modelos subsequentes do software. Por isso, apenas aquelas autorizadas podem ser efetua- das, ainda que a gestão de mudanças nos requisitos deva ocorrer em todas as que forem propostas. O gerenciamento das mudanças para se controlar as etapas acima envolve fazer a: • Identificação da baseline de requisitos; • Restrição de mudanças; • Auditoria das mudanças. Uma baseline, ou linha base, é uma “imagem” de uma versão de cada artefato no re- positório do projeto e funciona como um padrão oficial básico para os demais trabalhos subsequentes. Uma baseline de requisitos é uma versão de sua especificação e contém um conjunto definido de itens de configuração, que poderão servir, inclusive, como mar- cos no processo de desenvolvimento do software. Esses itens também irão colaborar com outra gestão – a de configuração de software, para que esta possa definir critérios que permitam realizar as modificações solicitadas, mantendo-se a consistência e a integridade do software com as novas especificações. Gerência de Escopo O gerenciamento de escopo do projeto deve considerar a: • Própria mudança, pois deverá ser feito um planejamento para sua acomodação, e isto tem um custo, e precisa ter um prazo; • Revisão de requisitos para se evitar conflitos. Os stakeholders devem ser questionados,para se obter sua concordância se eles especificaram qualquer alteração em um requisito. O escopo de um projeto é definido pelo conjunto de requisitos a ele alocados, e, portanto, para que esse projeto se adeque aos recursos disponíveis (tempo, pessoas e dinheiro) é primordial o gerenciamento eficaz do escopo. Isso significa garantir que o projeto não excederá os requisitos necessários, o orça- mento planejado e o prazo estabelecido. A gerência de escopo é feita com os detalhes do fluxo de trabalho que visam: • Priorizar e refinar informações fornecidas para a seleção das características e dos requisitos a incluir; • Listar os casos de uso (ou cenários) representativos de alguma funcionalidade; • Definir quais atributos, requisitos e rastreabilidades serão mantidos. 17 UNIDADE Análise e Gestão de Requisitos A rastreabilidade é definida como sendo a habilidade para se acompanhar a vida de um requisito, seja partindo do requisito e chegando ao projeto, ou vice-versa, e durante todo seu ciclo de vida. A dificuldade da rastreabilidade é o grande volume de informações que é gerado. Estas informações relativas ao processo de requisitos devem ser catalogadas e associadas a outros elementos, de forma a serem referenciadas através dos diversos itens de informação registrados. Para facilitar, pode-se elaborar um artefato, a matriz de rastreabilidade, junto com a es- pecificação de requisitos, cujo objetivo é mapear os requisitos descritos na sua especificação. A rastreabilidade dos requisitos, e de suas mudanças, referem-se aos relacionamentos entre os requisitos, suas fontes e o projeto de sistema, podendo ser rastreabilidades: • Da fonte, ou seja, onde se associam os requisitos aos stakeholders que os propuseram; • Dos requisitos, que trata da ligação dos requisitos dependentes; e • De projeto, pois associam os requisitos aos módulos de projeto. A gestão do escopo – e a gestão de requisitos – devem atuar durante todo o processo da engenharia de requisitos porque deve(m) ser planejados(as): • A identificação dos requisitos, e como deverão ser identificados individualmente; • O gerenciamento das mudanças e qual deverá ser o processo a seguir a partir da análise de uma mudança em requisitos; • As políticas de rastreabilidade, a qualidade e a quantidade de informações a serem mantidas sobre os relacionamentos de requisitos; e • Avaliar e, preferencialmente, fazer o uso do apoio de ferramentas CASE. Assim, esse conjunto de técnicas denominadas gestão possibilita minimizar os efeitos negativos das alterações tão comuns nos requisitos de um software durante o processo de seu desenvolvimento. 18 19 Material Complementar Indicações para saber mais sobre os assuntos abordados nesta Unidade: Sites Engenharia de Software - introdução à engenharia de requisitos DEVMEDIA. Engenharia de Software - introdução à engenharia de requisitos. https://goo.gl/8msNxk Requirements management GODA, Software. Requirements management https://goo.gl/6GDPmD What is requirements management? https://goo.gl/t7FUd7 The most affordable, flexible & powerful requirements management tools https://goo.gl/89YJer Modern Requirements4TFS – easy, eficiente, essential https://goo.gl/RKQe8C Open source Requirements management. https://goo.gl/SNjHsd Vídeos Requirements management - meaning, definition, explanation. https://youtu.be/QVVuCj4GTWE Agile Requirements Management Best Practices https://youtu.be/HQizMS04A7s Requirements Management https://youtu.be/RyafVhLHNxs Controle de Versão de Requisitos de Software https://youtu.be/uZdXQe-NYFQ Requirements Management https://youtu.be/t4PRpQ5xAC4 19 UNIDADE Análise e Gestão de Requisitos Referências AUDIOPEDIA. Requirements management - meaning, definition, explanation. Disponível em: https://www.youtube.com/watch?v=QVVuCj4GTWE, último acesso em 09/04/2018. DEVMEDIA. Engenharia de Software - introdução à engenharia de requisitos. Disponível em: https://www.devmedia.com.br/artigo-engenharia-de-software- introducao-a-engenharia-de-requisitos/8034, último acesso em 10/04/2018. GODA, Software. Requirements management. Disponível em: http://analysttool. com/requirementsmanagement, último acesso em 09/04/2018. HÖRÖMPÖLY, Bem. Agile requirements management best practices. Disponível em: https://www.youtube.com/watch?v=HQizMS04A7s, último acesso em 09/04/2018. IT METRICS & PRODUCTIVITY INSTITUTE. Requirements management best practices. Disponível em: https://www.youtube.com/watch?v=RyafVhLHNxs, último acesso em 09/04/2018. VENTURA, Plinio. Engenharia de requisitos na real. Disponível em: https://www. youtube.com/watch?v=uZdXQe-NYFQ, último acesso em 09/04/2018. Requirements management. Disponível em: https://www.youtube.com/ watch?v=t4PRpQ5xAC4. último acesso em 09/04/2018. 20