Engenharia de software 9 IAN SOMMERVILLE

métricas que possam ser usadas. Em outros casos, mesmo quando a especificação quantitativa é possível, os clientes podem não ser capazes de relacionar suas necessidades com essas especificações. Eles não entendem o que significa um número definindo a confiabilidade necessária (por exemplo), em termos de sua experiência cotidiana com os sistemas computacionais. Além disso, o custo de verificar requisitos objetivamente não funcionais mensuráveis pode ser muito elevado, e os clientes, que pagam pelo sistema, podem não achar que os custos sejam justificados. Os requisitos não funcionais frequentemente conflitam e interagem com outros requisitos funcionais ou não funcionais. Por exemplo, o requisito de autenticação no Quadro 4.1 certamente exige a instalação de um leitor de cartão em cada computador conectado ao sistema. No entanto, pode haver outro requisito que solicite acesso móvel ao sistema, pelos laptops dos médicos ou enfermeiras. Estes não são geralmente equipados com leitores de cartão, assim, nessas circunstâncias, algum método de autenticação alternativo deve ser criado. Na prática, no documento de requisitos, é difícil separar os requisitos funcionais dos não funcionais. Se são apresentados separadamente, os relacionamentos entre eles podem ficar difíceis de serem entendidos. No entanto, os requisitos claramente relacionados com as propriedades emergentes do sistema, como desempenho ou confiabilidade, devem ser explicitamente destacados. Você pode fazer isso…