非功能性需求的解读与分类
我们有时会遇到一些描述不太明确的需求，这些需求看似属于“非功能性”，实则往往隐藏着更为具体的功能性需求或质量需求。在对这些需求进行理解和分析时，需要特别留意。以下是一个例子，描述了系统中所谓的“安全性需求”。
描述：系统应该是安全的（R12）。对于这个看似简单的非功能性需求，我们可能会产生以下疑问：
① “安全”这个词具体指的是什么？它包含了哪些细节和要素？
② 为了确保系统的安全性，我们需要设计哪些特定的功能或属性？例如数据加密、权限管理等。
③ 如何验证系统是否真正安全？是否有具体的评估标准和测试方法？
如果这样的不明确需求在需求分析阶段没有得到充分的澄清和细化，那么不同的利益相关者可能会以完全不同的方式理解这一需求，从而引发潜在的风险和误解。我们需要对这类看似“非功能性”的需求进行精化和细化。具体到上述的安全性需求（R12），我们可以这样细化：
R12.1：用户在使用系统前，必须完成用户名和密码的登录验证。这是确保系统安全的基础措施之一。
R12.2：系统应定期提醒用户更换密码，例如每四周提醒一次，以保持账号安全并减少密码被的风险。这也是提升系统安全性的一项重要措施。同时设置更强大的密码要求策略以提升账户安全。比如说……后面自行补写！我们的强烈建议在此出现——即在书写需求和系统规格说明书的时候，尽量清晰地界定每一个功能的特性和需求是避免非功能性需求泛滥的好方法。对于那些看起来像非功能性但实际上却包含了具体的、功能性细节的表述要仔细鉴别并进行充分细化分析；对这些笼统、隐多种含义的非功能性需求必须时刻警醒并加以精细梳理！为此推荐详细审核并确保对所有需要完成的任务和目标做到深入而充分的把握才能稳步地推动项目前行实现我们最终的开发目标并创造出具有真实价值的项目产品以供客户使用和参考。明确化的、具有可执行性的文档化需求是所有开发活动的基础和根本保障！希望大家在日后工作中能够有所收获和成长！
