-
Se alguém puder comentar... Eu vejo 3 alternativas para cenário "potencialmente" dificultador, letras A, D e E. Fui na D por achar o PIOR cenário possível...
-
a) os usuários e desenvolvedores fazerem uso de vocabulários distintos e os usuários possuírem a mesma visão sobre todos os requisitos
b) o usuário saber com precisão o que esperar do software e novos envolvidos poderem vir a participar do processo
c) os requisitos não mudarem com o tempo e os usuários possuírem percepções conflitantes sobre os requisitos
e) as mudanças nos requisitos possuírem frequência diária e os usuários possuírem a mesma visão sobre todos os requisitos.
usuários de um mesmo sistema possuem visões diferentes, não sabem nem a hora que estão com fome e requisitos mudam. Na intro do cap de engenharia de requisitos do livro do sommerville tem todas essas ideias mais tecnicamente explanadas.
-
d)o escopo do software não poder ser definido e as mudanças nos requisitos ocorrerem diariamente.
musashi, creio que o objetivo da questao era justamente este; ver qual das opções é a pior de todas. As outras sempre têm algo de positivo.
-
Dá pra resolver por operação lógica:
a) V & F = F
b) F & V = F
c) F & V = F
d) V & V = V
e) V & F = F
-
Christel e Kang [Cri92] identificam uma série de problemas que são encontrados durante o levantamento:
- Problemas de Escopo: os limites do sistema são definidos de forma precária ou os clientes/usuários especificam detalhes técnicos desnecessários que podem confundir, em vez de esclarecer, os objetivos globais do sistema
- Problemas de entendimento: os clientes/usuários não estão completamente certos do que é preciso, não possuem um entendimento completo do dominio do problema, tem problemas para transmitir suas necessidades ao engenheiro de sistemas, omitem informações que acreditam ser "óbvias", especificam requisitos que conflitam com as necessidades de outros clientes/usuários ou especificam requisitos que são ambíguos ou impossíveis de serem testados.
- Problemas de volatilidade: os requisitos mudam com o tempo. Para ajudar a superar esses problemas, devemos abordar o levantamento de requisitos de forma organizada.
Pressman, 7ª ediçao Engenharia de Sw, pág 128.