Questões de Concurso
Sobre engenharia de requisitos em engenharia de software
Foram encontradas 1.321 questões
I. Fontes de informações durante a fase de obtenção de requisitos incluem documentação, stakeholders de sistema e especificações de sistemas similares.
II. A interação com os stakeholders neste processo de dá por meio de entrevistas e observações, podendo ser utilizado cenário e até mesmo protótipos para auxiliar nesta obtenção.
III. Os stakeholders variam de usuários finais do sistema a gerentes e envolvidos externos.
IV. Fontes de requisitos como stakeholders, domínios e outros sistemas podem ser representados como pontos de vista do sistema, em que cada ponto de vista apresenta um subconjunto de requisitos do novo sistema.
A rastreabilidade bidirecional ocorre tanto de forma horizontal quanto vertical: a vertical estabelece a dependência entre os requisitos ou produtos de trabalho em um mesmo nível, podendo ocorrer em relação aos requisitos entre si ou entre códigos de unidades dependentes; a horizontal estabelece um rastreamento a partir de um requisito fonte, passando pelos requisitos de mais baixo nível, até atingir o nível de decomposição mais baixo do produto.
I. “Requisitos funcionais” são declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações.
II. “Requisitos não funcionais” se aplicam à propriedades do sistema como um todo e podem definir restrições como tempo de resposta, espaço de armazenamento e perfis de acesso ao sistema.
III. “Requisitos de domínio” são regras de negócio, como uma fórmula de cálculo, que podem estar associadas somente a “requisitos funcionais” do sistema.
Assinale a alternativa CORRETA:
I - O sistema deverá permitir ao representante do posto solicitar uma entrega de combustíveis.
II - O sistema deverá utilizar JAVA.
III - O sistema deverá suportar pedidos em português e espanhol.
É(São) requisito(s) funcional(is) APENAS o(s) descrito(s) em
São considerados facilitadores para uma reunião: direcionar a discussão, encerrar a conversação e preparar um histórico, à medida que a reunião acontece, que vai ajudar na consolidação dos resultados e na identificação das próximas etapas.
As entrevistas podem ser classificadas como abertas ou fechadas. Nas entrevistas fechadas, não há roteiro predefinido. Na prática, é possível implementar uma combinação de entrevistas abertas e fechadas, visando obter uma compreensão mais ampla das necessidades dos stakeholders com relação ao sistema.
A coleta inicial dos requisitos ocorre normalmente em reunião que participam os stakeholders, gerentes, desenvolvedores e todas as pessoas envolvidas com o projeto. As regras e agenda da reunião devem ser comunicadas para todos os participantes. Os tópicos a serem discutidos nessa coleta inicial incluem identificação do problema, necessidade e justificativa do novo produto de software.
Verificações de realismo buscam averiguar se os requisitos não estão conflitantes, enquanto verificações de consistência, considerando a tecnologia existente, visam analisar a viabilidade de implementação desses requisitos.
Na prototipação, um modelo executável do sistema é apresentado aos usuários e clientes finais, que podem verificar se o modelo atende as suas necessidades reais.
A revisão de requisitos objetiva verificar o documento de requisitos em busca de anomalias ou omissões; é um processo manual que envolve cliente e fornecedor.
Os requisitos funcionais descrevem o que o sistema deve fazer; dependem do tipo de software que está sendo desenvolvido, dos usuários e da abordagem geral utilizada pela organização para redigir os requisitos.
A frase a seguir é um exemplo de descrição de requisito funcional: A interface de usuário do sistema xxx deve ser implementada como simples HTML, sem frames ou applets Java.
Os requisitos não funcionais não estão relacionados diretamente às funções específicas fornecidas pelo sistema. Definições de desempenho, espaço e portabilidade são exemplos de requisitos não funcionais.
A rastreabilidade bidirecional ocorre tanto de forma horizontal quanto vertical: a vertical estabelece a dependência entre os requisitos ou produtos de trabalho em um mesmo nível, podendo ocorrer em relação aos requisitos entre si ou entre códigos de unidades dependentes; a horizontal estabelece um rastreamento a partir de um requisito fonte, passando pelos requisitos de mais baixo nível, até atingir o nível de decomposição mais baixo do produto.
No desenvolvimento de um software, ocorrem atividades associadas à rastreabilidade em quatro momentos: nos artefatos definidos na gerência de requisitos; no relatório de solicitação de mudança; na elaboração dos protótipos; e na codificação do software.
A rastreabilidade dos requisitos, além de documentar as solicitações de mudança, indicando o solicitante, o motivo e a sua propriedade, ajuda a estimar os recursos de hardware e software necessários ao desenvolvimento do produto de software, permitindo um adequado gerenciamento de requisitos.