19-ENGENHARIA DE REQUISITOS-Prova

Prévia do material em texto

Questão 1
Respondida
O Manifesto Ágil, escrito em 2001, foi tido como base para a difusão das metodologias ágeis e mudança de paradigma no processo de desenvolvimento de softwares. O principal objetivo com as metodologias ágeis era dar uma maior transparência ao cliente, interessado e patrocinador do produto, em relação ao que estava sendo elaborado e seria entregue, garantindo assim que seus anseios com o produto pudessem ser efetivamente alcançados.
 
A mudança de foco, que nas metodologias tradicionais estava em desenvolver uma sólida e complexa documentação, foi alterada para o produto em funcionamento, minimizando o nível de complexidade da documentação, que ainda precisa existir.
  
Com base em seus conhecimentos sobre o levantamento de requisitos em metodologias ágeis, analise as afirmações a seguir:
 
I.   Product backlog são os requisitos já refinados e prontos para o desenvolvimento.
II.  Os requisitos da Sprint Backlog são extraídos do conjunto do Product backlog e detalhados.
III. As Histórias de Usuário são utilizadas para detalhamento dos requisitos e seus critérios de validação.
Considerando o contexto apresentado, é correto o que se afirma em:
· I e II, apenas.
· II e III, apenas.
· I e III, apenas.
· I, II e III.
· III, apenas.
Sua resposta
II e III, apenas.
Alternativa correta: II e III, apenas.     Quando utilizamos metodologias ágeis, os requisitos macro do produto irão compor o product backlog (ou backlog do produto), representando as principais funcionalidades do sistema. Estes requisitos, por sua vez, precisarão ser priorizados conforme a necessidade do cliente, podendo esta priorização ser alterada a qualquer momento, durante o processo de desenvolvimento.   Quando a equipe de desenvolvedores seleciona as tarefas já detalhadas, conforme a prioridade, para implementar e entregar no próximo pacote, falamos que o sprint backlog foi definido.   Toda a documentação que os desenvolvedores irão ter para se basear deve estar escrita nas Histórias de usuário, que precisam ser mantidas atualizadas, ao longo do projeto, para eventuais necessidades de consulta por qualquer membro do time de desenvolvimento.     I.   Product backlog são os requisitos já refinados e prontos para o desenvolvimento. Incorreta. Product backlog é composto pelos requisitos do produto, ainda em sua forma macro, sem refinamento. II.  Os requisitos da Sprint Backlog são extraídos do conjunto do Product backlog e detalhados. Correta. Quando há o refinamento dos requisitos do conjunto do product backlog e a equipe de desenvolvimento irá trabalhar neles para a entrega no próximo ciclo, então estes requisitos refinados irão compor o sprint backlog.    III. As Histórias de Usuário são utilizadas para detalhamento dos requisitos e seus critérios de validação. Correta. As Histórias de Usuário são utilizadas para destrinchar o requisito, suas regras de negócio e seus critérios de validação.
,
Questão 2
Respondida
Requisitos não funcionais são tão importantes quanto os requisitos funcionais, porém suas implementações acontecem de forma a não serem percebidas pelo usuário final, o que acaba não sendo capaz de realizar priorização, como acontece nos requisitos funcionais.
 
Por estarem espalhados em uma ou mais funcionalidades do sistema, esta categoria de requisitos também é considerada como requisitos transversais.
 
Em sistemas que são construídos com base em metodologias ágeis, como o framework SCRUM, os requisitos não funcionais são validados nos critérios de validação de cada História de usuário, enquanto em equipes que adotam a metodologia de desenvolvimento em cascata, podem ser validados nas regras de negócio ou nos fluxos alternativos.
Assinale a alternativa que apresenta um tipo de requisito não funcional de uma aplicação.
· Cadastro de usuários.
· Agendamento de consultas com um médico.
· Autenticação de usuários no sistema.
· Extração de relatório de vendas em um período.
· Download de arquivos de uma pasta.
Sua resposta
Autenticação de usuários no sistema.
Os requisitos funcionais são representados pelas ações concretas que serão executadas pelo sistema e que irão atender às expectativas do usuário, como cadastro de entidades, alterações, exclusões, extração de relatório, dentre outras.   Requisitos não funcionais, por sua vez, são todos aqueles que, apesar de não serem perceptíveis ao usuário final, precisam estar implementados, garantindo o suporte necessário ao pleno desenvolvimento dos requisitos funcionais, como a parte de segurança e autenticação, auditorias, dentre outros que podem estar englobando um ou mais requisitos funcionais no sistema.   Por estarem englobando um ou vários requisitos funcionais, os requisitos não funcionais também são considerados como transversais no sistema, como, por exemplo, a necessidade de estar devidamente logado no sistema para ter acesso a determinadas funcionalidades (é preciso verificar, em todas as partes que necessitem de autenticação, se o usuário está devidamente logado para que o acesso seja liberado).   Todo requisito que represente uma ação concreta, realizada por um usuário, é considerado como requisito funcional. Desta forma, apenas a opção de Autenticação de usuários no sistema representa um requisito não funcional.
Questão 3
Respondida
Ao longo da realização das entrevistas com o cliente, voltadas para a especificação inicial dos requisitos de uma aplicação, é comum que a priorização destes requisitos não aconteça, já que podem existir muitas partes interessadas no sistema, com necessidades e expectativas diferentes para o produto.
 
Após a definição inicial dos requisitos, será preciso utilizar técnicas de priorização, com o objetivo de que todas as partes interessadas cheguem a um consenso, a respeito de suas expectativas, e que as funcionalidades que possam agregar mais valor possam ser definidas.
 
Uma das técnicas de priorização que podem ser utilizadas é a Matriz de Priorização, que visa definir, através de uma ferramenta visual, qual o consenso de prioridade das tarefas, entre todas as partes interessadas.
 
Com base no texto acima, e em seus conhecimentos sobre técnicas de priorização, faça a associação da descrição do tipo de matriz de priorização, apresentada na Coluna A, com a respectiva nomenclatura, apresentada na Coluna B.
 
	Coluna A
	Coluna B
	I. Cada critério recebe uma pontuação, numa escala de 1 a 5, executando a operação de soma ao final do processo.
	1.    BASICO
	II. Considera os critérios de esforço, impacto e confidência para chegar a um consenso sobre o nível de prioridade do requisito.
	2.    4x4
	III. Considera dois critérios, escolhidos aleatoriamente pelo analista que está elaborando a tabela, de modo a atribuir notas que variam em uma escala de 1 a 4.
	3.    RICE
Assinale a alternativa que apresenta a associação CORRETA entre as colunas.
· I – 2; II – 3; III - 1.
· I – 3; II – 1; III - 2.
· I – 1; II – 2; III - 3.
· I – 2; II – 1; III - 3.
· I – 1; II – 3; III - 2.
Sua resposta
I – 1; II – 3; III - 2.
Alternativa correta: I – 1; II – 3; III - 2.   As matrizes de priorização visam obter um resultado visual, através da atribuição de pesos e operações matemáticas, tentando atribuir um número de prioridade para cada tarefa, buscando sempre um consenso entre as diversas partes interessadas.   Existem diferentes tipos de matriz de priorização, sendo algumas das mais comuns:   BASICO – Estabelece critérios, em uma escala de 1 a 5, para as funcionalidades, executando uma operação de soma ao final do processo, para atribuir uma nota final para cada requisito e ordenar da maior para a menor nota;   RICE – Se baseia nos critérios de esforço, impacto e confidência para estabelecer quais as funcionalidades mais importantes; 4 x 4 – Se baseia em dois critérios aleatórios, conforme definição de quem estiver elaborando a matriz, para atribuir uma nota em uma escala de 1 a 4.
Questão 4
Respondida
O processo de levantamento de requisitos precisa ser feito com muito cuidado e atenção, a fim de evitar retrabalhos e insatisfaçãopor parte do cliente. Um dos motivos pelo qual a equipe que será responsável pelo projeto precisará se atentar é garantir que as funcionalidades acordadas para a aplicação estejam completas e sem inconsistências.
 
Completude de um requisito se refere à especificação de todas as regras de negócio necessárias para a implementação deste, de modo que a equipe de desenvolvimento não tenha dúvidas quanto as regras acordadas. Consistência, por sua vez, representa a inexistência de conflitos entre regras de negócio, seja no pré-requisito para a funcionalidade ou na dependência entre diferentes requisitos.
Considerando o contexto apresentado, é um fator que pode acarretar inconsistência nos requisitos
· a ausência de regras de negócio para validação.
· a inexistência de um plano de testes para o requisito.
· o escopo da aplicação.
· os conflitos de interesse entre diferentes partes interessadas.
· regras que podem ter duplo entendimento.
Sua resposta
os conflitos de interesse entre diferentes partes interessadas.
Para que um requisito possa ser considerado pronto para o processo de codificação, é preciso que ele esteja completo, ou seja, com todas as suas regras de negócio especificadas e devidamente documentadas, de forma que a equipe de desenvolvimento não tenha dúvidas, e consistente, ou seja, suas premissas (ou pré-requisitos) não podem estar em conflito com outros requisitos existentes na aplicação.   Nas fases iniciais do projeto, quando ainda o objetivo é elencar todas as funcionalidades necessárias para a aplicação, sem muita preocupação em manter a consistência, é comum que, em projetos com muitas partes interessadas, haja conflitos de interesse que ocasionem requisitos conflitantes, ditos inconsistentes. Neste caso, será necessário chegar a um consenso com as partes interessadas, de modo a dirimir estas inconsistências.   A inconsistência está relacionada com as premissas e relação com os demais requisitos do sistema, de modo que um requisito ou premissa não poderá conflitar com outro requisito existente (não podem ser contraditórios).
Questão 5
Respondida
Toda funcionalidade de um sistema tem, por objetivo, ser utilizado por um ator, que deverá disparar esta ação através de algum tipo de interação com a aplicação.
 
Os diagramas UML, que visam modelar visualmente os atores e as interações entre estes e as funcionalidades do sistema, são denominados de diagramas de caso de uso. Mas não somente este tipo de diagrama serve como apresentação visual.
 
Diagramas de sequência, que visam apresentar o sequenciamento de passos, a partir do evento inicial que disparará a ação no sistema até a resposta final retornada, também utilizam a imagem dos atores, para definir quem irá utilizar a funcionalidade.
 
Na metodologia ágil, com as Histórias de usuário, também se deve definir e especificar claramente quem será a persona que irá fazer uso do requisito, detalhando como aquela ação deverá ocorrer no sistema e com qual propósito.
 
Todos esses diagramas e documentos mencionados serão apresentados às partes interessadas na aplicação, para que possam validar e/ou corrigir eventuais falhas de entendimento, adequando a funcionalidade ao real interesse do cliente, fazendo com que o sistema de fato agregue valor e tenha uma vida útil longa.
 
Com base no contexto e em seus conhecimentos sobre o conceito de ator, analise as afirmativas a seguir:
I.   Ator pode ser tanto um usuário do sistema, quanto outro sistema que possa disparar uma ação;
II.  Ator é apenas o usuário humano do sistema, não sendo considerado ator um outro sistema que faça interação com a aplicação que será construída;
III. Ator pode ser um serviço WEB, desde que este dispare uma ação no sistema que será construído.
Considerando o contexto apresentado, é correto o que se afirma em:
· I, apenas.
· I e II, apenas.
· I e III, apenas
· I, II e III.
· III, apenas.
Sua resposta
I e III, apenas
Alternativa correta: I e III, apenas.   O ator, ou persona, de uma aplicação poderá ser representado tanto por uma pessoa (usuário do sistema), quanto por outro sistema ou serviço, contanto que estes disparem alguma ação na aplicação que será construída.   Dessa forma, é importante identificar e mapear quais as funcionalidades que irão compor a aplicação e quem irá utilizar este requisito, de modo a mapear esta relação através dos diagramas de caso de uso ou de sequência, facilitando a compreensão do todo pelas partes interessadas (stakeholders) da aplicação.   Então, se uma aplicação externa irá executar alguma solicitação para uma funcionalidade da aplicação que está sendo construída, esta aplicação externa é o ator que irá disparar tal função, da mesma forma que um usuário humano faria, através da interação com uma tela e clicando em algum botão, por exemplo.   Então, no caso de serviços WEB, como são considerados aplicações externas, caso estes interajam de alguma forma com a aplicação que será implementada de modo a disparar uma ação e esperar por uma resposta desta, será sim considerado um ator para a funcionalidade que irá depender deste gatilho.   I.   Ator pode ser tanto um usuário do sistema, quanto outro sistema que possa disparar uma ação; Correto. Ator não é representado apenas por um humano, mas sim por tudo que possa estar interagindo com a aplicação, seja outra aplicação ou uma pessoa. II.  Ator é apenas o usuário humano do sistema, não sendo considerado ator um outro sistema que faça interação com a aplicação que será construída; Incorreto. Ator não é representado apenas por um humano, mas sim por tudo que possa estar interagindo com a aplicação, seja outra aplicação ou uma pessoa.   III. Ator pode ser um serviço WEB, desde que este dispare uma ação no sistema que será construído. Correto. No caso de serviços WEB, como são considerados aplicações externas, caso estes interajam de alguma forma com a aplicação que será implementada de modo a disparar uma ação e esperar por uma resposta desta, será sim considerado um ator para a funcionalidade que irá depender deste gatilho.
Questão 6
Sem resposta
Sistemas precisam prever situações adversas em termos de utilização de suas funcionalidades pelo usuário final. Quanto mais cenários de utilização forem previstos, mais será a assertividade da aplicação em lidar com os mais diversos comportamentos dos usuários, fornecendo-lhes as respostas corretas, até mesmo evitando brechas de segurança (ou que possam comprometer a segurança do sistema).
 
Nem sempre é fácil (ou intuitivo) prever todas estas situações em um primeiro momento, tendo em vista que é difícil prever todos os cenários de interação do usuário que podem acontecer. Sendo assim, é necessário, em grande parte dos casos, que ajustes nos requisitos sejam feitos ao longo do andamento do projeto, para acrescentar as situações que não foram inicialmente previstas.
Considerando o texto apresentado e seus conhecimentos sobre os cenários de especificação de requisitos, assinale a alternativa CORRETA sobre o tipo de cenário abordado no texto.
· Fluxo principal.
· Fluxo de exceção.
· Fluxo alternativo.
· Fluxo híbrido.
· Fluxo de antecipação.
Sua resposta
Fluxo de exceção.
Fluxos alternativos são definidos como aquelas situações que fogem ao caminho principal, quando acontece uma interação do usuário com a funcionalidade, como, por exemplo, validações de campos de forma geral, validação de regras de negócio, seleção de opções, em tela, que levem a respostas diferentes da aplicação, dentre outras situações.   Sendo assim, quanto mais se conseguir mapear as situações alternativas que podem acontecer na utilização de uma funcionalidade, maior será a previsibilidade do sistema em retornar respostas, evitando que erros e brechas de segurança estejam presentes na aplicação.   Nem sempre é possível elencar todas as situações alternativas possíveis, para uma determinada funcionalidade, em um momento inicial, o que pode acarretar em alterações dos requisitos, ao longo do projeto, para alterar ou inserir as novas situações percebidas.   Fluxo principal é consideradoo cenário ideal escolhido pelo usuário.   Fluxo de exceção representa o tratamento de eventuais erros (como de comunicação com servidores remotos) que possam acontecer na execução da funcionalidade, de modo a apresentar uma mensagem amigável ao usuário final, na ocorrência do problema.   Não existe a definição de fluxo híbrido para o processo de gerenciamento de requisitos.   Não existe o conceito de fluxo de antecipação para o gerenciamento de requisitos.
Questão 7
Sem resposta
Aplicações autoadaptáveis possuem a característica de adaptação do comportamento, em tempo de execução, conforme análises periódicas do ambiente no qual estão inseridas ou através das interações com os usuários.
 
O processo de levantamento de requisitos, nesta categoria de aplicações, também se mostra de forma diferenciada, tendo em vista que os requisitos são parcialmente definidos, uma vez que é difícil prever todos os estados para os quais a aplicação poderá alterar seu comportamento.
 
Requisitos que podem sofrer alterações em tempo de execução são considerados como self-¸ indicando a auto capacidade da aplicação de adaptação, configuração, cura, etc. A partir de decisões tomadas pela aplicação, em tempo de execução, é possível definir, inclusive, o nível de interação entre um humano e a aplicação ou a capacidade de auto adaptação pela própria aplicação, sem intervenção humana.
 
Com base em seus conhecimentos sobre as aplicações autoadaptáveis e sua especificação de requisitos, analise as afirmativas a seguir:
I. O POR QUE apresenta a motivação para construção do sistema autoadaptativo;
II. O QUANDO representam perguntas relacionadas ao tempo no qual as adaptações devem acontecer;
III.O COMO irá definir como os requisitos adaptáveis serão configurados e quais as condições mais adequadas para a adaptação.
Considerando o contexto apresentado, é correto o que se afirma em:
· I, apenas.
· II, apenas.
· III, apenas.
· I e II, apenas.
· I, II e III.
Sua resposta
I, II e III.
Para as aplicações autoadaptáveis, os requisitos precisam responder a determinadas perguntas, para que a especificação aconteça de forma mais fácil, tendo em vista que é difícil conseguir prever e especificar todas as alternativas possíveis de mudança de comportamento que a aplicação poderá executar.   As perguntas a serem respondidas incluem: Onde – Deve especificar em quais pontos as mudanças poderão ocorrer, como o que será alterado e em qual camada da aplicação; Quando – Em qual tempo as modificações deverão acontecer e qual a frequência de alteração; O que – Quais atributos ou artefatos deverão ser alterados por conta da adaptação; Por quê – Qual o motivo da construção da aplicação autoadaptativa; Quem – Quem deverá realizar a alteração e qual o nível da integração humana ou automação da aplicação; Como – Como os requisitos autoadaptáveis serão configurados e quais as condições mais adequadas para a adaptação.
Questão 8
Sem resposta
Quando uma lista contendo todos os requisitos funcionais e não funcionais é elaborada, como fruto das entrevistas com o cliente, pode-se construir dois documentos com ela: o documento de Especificação de Requisitos, para metodologias tradicionais de desenvolvimento, ou documento de Histórias de usuário, para metodologias ágeis.
 
Na maior parte dos casos, é difícil, até mesmo para o cliente, que deveria conhecer bem o seu negócio, estabelecer uma ordem de prioridade para o desenvolvimento destas funcionalidades, garantindo que aquelas que irão agregar maior valor ao produto sejam construídas primeiro.
 
É preciso, então, que o Analista de Requisitos, Líder técnico ou o membro da equipe de desenvolvimento responsável pelo levantamento de requisitos junto ao cliente tenha experiência e conhecimento de técnicas que auxiliem no processo de definição da priorização das tarefas, uma vez que pode haver conflitos de interesse entre as mais diversas partes interessadas no projeto.
 
Uma das técnicas utilizadas para tentar resolver o impasse do conflito de interesses, tentando chegar a um consenso comum, é a Matriz de priorização, que deverá ser construída na presença de todas as partes interessadas.
Levando em consideração o texto acima e seus conhecimentos sobre a Matriz de priorização e técnicas de negociação de requisitos, é correto afirmar que o objetivo da Matriz é:
· atribuir pesos para critérios importantes, mostrando de forma objetiva a importância de cada requisito.
· apresentar, de forma empírica, a importância dos requisitos a partir de critérios subjetivos.
· otimizar o tempo de desenvolvimento do sistema, calculando qual a produtividade da equipe por tarefa.
· acompanhar o andamento do time, evitando atrasos na entrega das tarefas acordadas.
· evitar que novas tarefas atrapalhem o andamento da implementação das tarefas atuais pelo time de desenvolvedores.
Sua resposta
atribuir pesos para critérios importantes, mostrando de forma objetiva a importância de cada requisito.
Técnicas de negociação e priorização de requisitos têm, por objetivo, tentar resolver impasses, a respeito dos conflitos de interesses, entre as mais diversas partes interessadas. Sendo assim, uma das formas é atribuir notas aos requisitos, de modo que aqueles com a maior nota teriam maior prioridade no desenvolvimento.   A Matriz de priorização (e seus subtipos) tem, como objetivo, a atribuição de pesos e o cálculo de uma nota final para cada requisito, a partir de critérios importantes definidos pelo time ou pelo subtipo da Matriz escolhido como o que melhor irá representar os interesses do cliente.   A partir de uma ordenação decrescente das notas atribuídas para cada requisito, será então definido o conjunto daquelas funcionalidades que mais irão agregar valor, de forma geral para todos os interessados, tentando-se chegar a um denominador comum entre as mais diversas expectativas dos clientes.   A depender do tipo de Matriz de priorização utilizado, operações como soma ou multiplicação podem ser utilizadas para que a nota final seja atingida para cada requisito. Pode-se, caso necessário, utilizar-se de mais de um tipo de Matriz de priorização, caso o consenso não seja alcançado com apenas um tipo de Matriz.
Questão 9
Sem resposta
O conceito de pronto, em equipes que utilizam as metodologias ágeis, é de fundamental importância para garantir que o objetivo da tarefa foi alcançado. Pronto significa que toda a parte funcional de uma tarefa, individualmente, foi implementada, seus critérios de aceitação foram testados e validados e a tarefa está disponível para ser entregue ao cliente, em ambiente de produção.
 
A partir do momento que os requisitos funcionais e não funcionais são definidos, o membro da equipe de desenvolvimento responsável pela escrita das Histórias de usuário (denominado product owner – dono do produto) irá definir o conjunto de tarefas do product backlog.
 
As metodologias ágeis se baseiam em ciclos, com entregas periódicas (que são os incrementos do sistema), que deverão contar com a homologação do cliente, ou seja, com a validação do resultado do ciclo que será entregue.
 
Para definir quais serão as tarefas a serem implementadas e entregues no próximo ciclo, os membros do time de desenvolvimento irão escolher, dentre as tarefas disponíveis no conjunto do backlog do produto. Essas tarefas selecionadas, então, irão compor a meta de entrega do time, ou seja, o próximo incremento do produto.
Com base no contexto apresentado, assinale a afirmativa CORRETA a respeito dos critérios de aceitação.
· Irão compor o conceito de pronto, tendo em vista que são as regras de negócio e requisitos não funcionais que se relacionam com a funcionalidade implementada.
· Não fazem parte do conceito de pronto, tendo em vista que apenas a funcionalidade principal precisa estar implementada.
· Critérios de aceitação só irão servir para que a equipe de desenvolvimento realize testes em suas máquinas locais, não importando se são validados pelo usuário final.
· O conceito de pronto, conforme apresentado no texto, não requer testes nem validaçãopor parte da equipe, mas apenas do usuário final.
· O conceito de pronto deverá englobar todas as tarefas que compõem a meta do ciclo, sendo que se apenas uma das tarefas não estiver completa, nenhuma estará.
Sua resposta
Irão compor o conceito de pronto, tendo em vista que são as regras de negócio e requisitos não funcionais que se relacionam com a funcionalidade implementada.
O conceito de pronto, para uma tarefa de um produto que está sendo construído com base em metodologias ágeis, representa a completa implementação da parte funcional e não funcional da tarefa, assim como sua validação (muitas vezes em um ambiente de testes ou homologação e feita por um outro membro da equipe) e disponibilização para o cliente.   Os requisitos não funcionais, em metodologias ágeis, se encaixam como critérios de aceitação das tarefas (que representam os requisitos funcionais). Então, para que uma tarefa possa ser dada como “pronta”, é imprescindível que sua implementação tenha sido concluída, como a de todos seus critérios de aceitação, da mesma forma que testes tenham sido realizados, tanto pelo desenvolvedor responsável quanto por um outro membro da equipe.   Com a tarefa dada como “pronta”, é possível, então, gerar um novo incremento para o produto, que já poderá ser colocado para uso em ambiente de produção.   Caso alguma tarefa, dentre as selecionadas pela equipe de desenvolvimento para comporem a meta do ciclo, não tenha atingido sua conclusão com sucesso (não tenha ficado pronta), ainda assim será possível entregar um incremento ao cliente, sendo este composto pelas demais tarefas acordadas e que atingiram seus objetivos finais.
Questão 10
Sem resposta
Em metodologias tradicionais, como a cascata, cada fase do processo de desenvolvimento só inicia quando a fase anterior finaliza. Com a finalização de uma fase, artefatos são gerados e utilizados pela fase subsequente, dando continuidade ao projeto até sua finalização.
 
O sucesso ou fracasso de um projeto de software irá depender, dentre outros fatores, da forma como os requisitos foram especificados e detalhados, refletindo as necessidades do cliente. Caso um requisito seja especificado de forma confusa, ambígua ou não condizente com a real necessidade do usuário, sua devida implementação será feita de forma equivocada, ocasionando retrabalhos e/ou desuso da aplicação, a longo prazo.
 
Requisitos representam todas as ações que precisam ser providas pelo sistema a seus usuários (atores), de forma que podem ser classificados em funcionais (quando representam ações) e não funcionais (quando representam características de suporte aos requisitos funcionais).
 
Muitas vezes, os requisitos funcionais podem ser classificados em categorias, para definir suas devidas prioridades no sistema. Como exemplo, podemos categorizar requisitos em obrigatórios ou desejáveis, indispensáveis ou importantes, dentre outras escalas de classificação.
 
Existem diferentes origens de requisitos, visando atender aos mais variados tipos de necessidades das partes interessadas no projeto.
Com base em seus conhecimentos sobre as origens dos requisitos de uma aplicação, é correto afirmar que os requisitos externos são
· requisitos que restringem o comportamento da aplicação.
· requisitos originados de políticas empresariais ou do cliente.
· requisitos originados da relação entre o sistema e outros sistemas da Organização.
· requisitos relacionados com a maturidade do sistema que está sendo migrado de plataforma e/ou linguagem de programação.
· requisitos relacionados com pesquisas feitas em sistemas do mesmo domínio, que tenham o mesmo propósito.
Sua resposta
requisitos originados da relação entre o sistema e outros sistemas da Organização.
Requisitos visam englobar todas as ações e funcionalidades que devem ser providas pelo sistema ou aplicação, de modo que deve ser especificada em conjunto com o cliente, em rodadas de entrevistas.   Em projetos grandes, podem existir diversos tipos de partes interessadas, cada um com seus objetivos e expectativas em relação ao produto, que pode se refletir em requisitos com prioridades diferentes.   Considerando as origens dos tipos de requisitos de uma aplicação, podemos mencionar:   Requisitos do produto – Compreendem as necessidades dos usuários com o produto que está sendo desenvolvido; Requisitos organizacionais – São os requisitos originados das políticas Empresariais ou do cliente, como a definição da linguagem de programação na qual o produto será desenvolvido; Requisitos externos – Todos os requisitos que são provenientes de fontes externas à aplicação, como a interoperabilidade dela com outras aplicações da Organização e/ou fora dela, Leis, dentre outros fatores.   A partir dessa classificação, é possível explorar mais situações que auxiliem aos envolvidos na análise de requisitos da aplicação a encontrarem situações anteriormente não previstas e que são importantes para o andamento do projeto. Ferramentas como tempestade de ideias e a matriz de priorização podem ser utilizadas, também, para que os requisitos levantados possam ser priorizados.