Nome: Jhonatan Viana Felix

Engenharia de Software I – 3° semestre – Noturno

1.1 - Às vezes, os documentos de requisitos podem incluir informações sobre o design do

sistema para garantir que as especificações atendam às necessidades do usuário e possam
ser implementadas de forma eficiente. Além disso, essas informações podem ajudar a
garantir que o sistema atenda aos padrões de qualidade e usabilidade exigidos pelos
usuários.

1.2 - Os possíveis stakeholders de um sistema de catalogação bibliotecária incluem

bibliotecários, usuários da biblioteca, gerentes de biblioteca, fornecedores de sistemas de
gerenciamento de biblioteca e desenvolvedores de software.

1.3 - Os stakeholders mencionados podem usar um documento de especificação de

requisitos do sistema de catalogação para entender os recursos e funcionalidades que o
sistema oferece, bem como para avaliar se o sistema atende às suas necessidades
específicas. Isso pode ajudá-los a tomar decisões informadas sobre a seleção de um sistema
de gerenciamento de biblioteca e também pode ser usado como uma referência para
garantir que o sistema seja mantido e atualizado adequadamente.

1.4 - (a) Requisito reescrito: O sistema bibliotecário deve permitir que os usuários
completem uma tarefa comum em menos de 5 minutos em média.
(b) Requisito reescrito: O sistema deve ter um tempo médio de atividade de 99,9% em um
período de um mês.
(c) Requisito reescrito: O sistema deve fornecer uma resposta a todos os pedidos de
informação em menos de 2 segundos em média.

2.1 - Há um grande grau de variabilidade nos processos de engenharia de requisitos usados

em diferentes organizações por causa de várias razões, como:
• Diferentes tipos de sistemas e projetos exigem diferentes abordagens e técnicas de
engenharia de requisitos.
• As organizações têm diferentes objetivos, requisitos, restrições, recursos e cultura,
o que pode afetar a forma como elas abordam a engenharia de requisitos.
• As equipes de desenvolvimento de software têm diferentes habilidades,
experiências, preferências e visões sobre a engenharia de requisitos, o que pode
levar a abordagens diferentes.
• As normas, regulamentos e práticas recomendadas do setor podem variar entre as
organizações, países e setores, o que pode influenciar a abordagem adotada.

2.2 - O modelo em cascata do processo de software não é uma reflexão precisa dos
processos de software na maioria das organizações porque assume que as etapas do
processo de software são executadas em sequência, com cada etapa produzindo artefatos
que são entregues à próxima etapa. Isso significa que o modelo em cascata pressupõe que
todos os requisitos são conhecidos e estáveis antes do início da fase de desenvolvimento, o
que muitas vezes não é realista na prática, especialmente em projetos complexos e
dinâmicos.
Por outro lado, o modelo em espiral é mais realista porque reconhece que a engenharia de
requisitos é um processo iterativo e incremental que envolve a exploração, análise,
especificação e validação de requisitos em ciclos sucessivos. Isso significa que o modelo em
espiral permite a adaptação e evolução dos requisitos à medida que o conhecimento e a
compreensão dos requisitos e do sistema aumentam. Além disso, o modelo em espiral
também inclui atividades de gerenciamento de riscos e avaliação contínua do processo e
produto de software, o que ajuda a garantir a qualidade e a eficácia do processo de
engenharia de requisitos.

3.1 - O conhecimento do domínio é importante para o processo de elicitação de requisitos

porque permite aos analistas entenderem o contexto em que o sistema será utilizado e as
necessidades dos utilizadores e stakeholders. Sem esse conhecimento, os requisitos podem
ser mal interpretados ou incompletos, resultando em um sistema que não atende às
expectativas dos utilizadores. Por exemplo, ao desenvolver um sistema de gestão de saúde,
os analistas precisam entender os processos clínicos, regulamentos, terminologia médica,
necessidades dos pacientes e dos profissionais de saúde, etc. para garantir que o sistema
seja útil e eficaz.

3.2 - (a) Possíveis stakeholders para um sistema de proteção de comboios podem incluir os
operadores de comboio, os passageiros, os gestores de transporte público, as empresas
ferroviárias, os reguladores de segurança ferroviária, entre outros.
(b) Possíveis stakeholders para um sistema de gestão de stock para companhias petrolíferas
podem incluir os gerentes de vendas e distribuição, os gerentes de armazenamento, os
compradores, os motoristas de entrega, os contadores financeiros, entre outros.

3.3 - (a) Cenários plausíveis para a atividade de matrícula em um curso universitário podem
incluir:
• Um aluno do ensino médio que visita o site da universidade, pesquisa os cursos
disponíveis, preenche um formulário de candidatura e envia os documentos
necessários.
• Um estudante internacional que entra em contato com o escritório de admissões
para obter informações sobre os requisitos de visto, testes de língua, etc.
(b) Cenários plausíveis para a atividade de transferência de dinheiro de uma conta para
outra podem incluir:
• Um cliente que visita o site do banco, faz login em sua conta, seleciona a opção de
transferência, insere os detalhes da conta de destino e confirma a transação.
• Um cliente que usa um aplicativo móvel para escanear um código QR e fazer uma
transferência instantânea para outra conta.

3.4 - A combinação entre etnografia e prototipagem é útil para a elicitação de requisitos

porque permite que os analistas compreendam a forma como as pessoas usam o sistema
em seu contexto natural, o que pode levar a insights valiosos sobre suas necessidades e
comportamentos. A etnografia envolve a observação dos usuários em seu ambiente natural,
enquanto a prototipagem permite aos usuários experimentar e fornecer feedback sobre as
soluções propostas. Juntos, esses métodos podem ajudar a criar um sistema que seja mais
eficaz e adequado às necessidades dos usuários.
3.5 - Duas razões pelas quais os requisitos podem ser ambíguos são:
• Falta de clareza ou especificidade nos requisitos: por exemplo, um requisito que
afirma que um sistema bibliotecário deve ser capaz de "pesquisar livros" pode ser
ambíguo, pois não especifica quais critérios de pesquisa devem ser incluídos.
• Diferentes interpretações dos requisitos: por exemplo, um requisito que afirma que
um sistema de gestão de stock petrolífero deve "gerir o stock com eficácia" pode ser
ambíguo, pois diferentes stakeholders podem ter diferentes interpretações do que
significa "eficácia”.