我需要一些关于如何解决应用程序规范中的歧义的建议。 举个简单的例子，
如果用户多次验证失败，请向IT发送通知。
在上面的例子中，不清楚“多次”是多少次。 目前尚不清楚，我不能简单地设置1000次随机限制。
您将如何解决任何规格中不清楚的部分？ （不只是我提到的那个）
此外，我应该在Google上搜索哪种主题或针对这类情况的书籍？ 软件工程？敏捷开发？我不知道从哪里开始。
非常感谢任何有用的诀窍和提示。
答案 0 :(得分：9)
如果您以正式方式跟踪您的要求，您可以做出假设并将其记录为衍生要求：
用户要求：
要求1：当用户多次验证失败后，向IT发送通知。
派生要求：
Req 1.1如果用户在三（3）次尝试后无法进行身份验证，系统将暂停该帐户并向IT支持中心发送电子邮件。
Req 1.1.1帐户暂停电子邮件将指定以下内容：
如果客户不可用，请让客户或利益相关者审核并批准派生的要求。
有关详细信息，请参阅Google“需求管理”或“需求工程”。国防工业部门加载包含示例和模板，可能太多了;）
我收藏了一些书签：
答案 1 :(得分：6)
根据您可能遇到的确切问题回复客户。如果有的话，那是最好的选择。如果没有，则由最终用户（客户端）进行配置。
答案 2 :(得分：3)
与（最好按此顺序）沟通：
答案 3 :(得分：3)
构建或原型化，然后将其显示给编写规范的人员。
通过谈论实际的事情，而不是一篇说明事情将如何起作用的论文，更容易澄清歧义。答案 4 :(得分：2)
你过分思考这个。
如果每个其他应用通知都是电子邮件（这不是不现实的），则可以假设规范的通知部分。否则请在做任何事之前询问。
我并不反对要求澄清当然。但是，我发现如果可以用很少或没有下行做出假设，那么最好这样做。毕竟他们雇用你解决问题而不是带来更多。 ;-)
奇怪的是;你可能会发现你的大部分假设都是正确的。
答案 5 :(得分：1)
从那个例子中，我会回到客户端，询问他们是否希望“可以配置”次数。它也可能导致诸如以下问题：
1）谁将保持配置的次数。 2）他们是否需要UI来查看这些设置并进行更改。
采用更敏捷的开发过程也会有所帮助。例如，向他们展示允许三次登录的示例将演示功能，并可能提示他们告诉您该号码。
澄清要求的重要性会在问题的答案会影响项目的时间，复杂性和成本的情况下发生变化。
答案 6 :(得分：1)
根据可用人员的不同，我会对模糊性采取一些不同的路径：
1）项目经理/业务分析师 - ＆gt;这些可能是最接近项目的，可能有助于快速解决规范问题。这可能涉及到问别人并稍后再回复你，但这应该是可以接受的。
2）专家分析员/官员 - ＆gt;例如，在您提及存在安全隐患的情况下，如果有安全官员可能有一个政策要对此强制执行并且应该在讨论中。另一个例子可能是让网络分析师从硬件角度查看架构，这在某些情况下可能很有用。
3）产品负责人 - ＆gt;谁负责定义应用程序。请注意，这不是技术人员，因此如果您遇到“您知道，我没有想到......”的回复，那么具体并提出建议可能会有用。
4）集团经理/团队负责人 - ＆gt;如果一切都失败了，请去找老板并要求澄清。
“需求收集”或“需求分析”是“软件开发生命周期”或“系统开发生命周期”这一部分的常用术语，可以删除一些您可以搜索并找到大量文章的术语。 / p>
答案 7 :(得分：1)
最好的方法是编写简短的备用用户故事（用例），描述不同选项如何影响用户，并要求客户选择需要支持的用户。
规范中的歧义通常反映了客户心中的模糊性 - 他们根本就没有想出来，所以这种方法可以帮助你们。 （使用书面说明 - 没有任何技术说明 - 用他们的术语来描述事物。）
答案 8 :(得分：1)
如果规格不准确，也许它无所谓？其他任何工作都不重要吗？拨打电话，让它为1000.确保它不是硬编码的。一个好主意是将它放在一些配置文件中（但不要暴露给最终用户界面，因为用户通常比你更不了解）。
如果这是一个互操作性的问题，那么其他人会做些什么呢？在Windows中它 200？比它200.现在你匹配Windows和规格 - 不错： - ）
如果你发现你的通话不好而且它应该是1500，至少你可以告诉你的用户如何修复它而无需重新安装你的软件。
答案 9 :(得分：1)
在企业企业中，这确实意味着它遵循一般公司政策。
事实上，当我自己编写规范时，我并不打扰这些一般规范，我只是说参考策略并直接进入特定业务需求的核心。
答案 10 :(得分：1)
为此您可以成为焦点小组，或者您可以与客户/适当的利益相关者进行沟通。